Día 46 – Entidades, relaciones y más allá: lo esencial del modelado
📘 Referencia: Capítulo 5.1.3 – Essential Concepts
🎯 Arco narrativo: Acto VI – Del concepto al diseño: modelar con sentido
✨ Storytelling
Cristina dibujó tres cuadros en la pizarra: Cliente, Producto y Venta.
Era su intento por explicar cómo funcionaba la lógica del nuevo modelo de datos al equipo de marketing.
—“Entonces… ¿una venta tiene un cliente y un producto?” —preguntó alguien.
—“Exacto. Pero más que eso: cada cliente puede hacer muchas compras, y cada producto puede estar en muchas ventas.”
—“¿Eso es lo de las relaciones uno a muchos, no?”
—“Sí, y es clave para entender cómo queremos estructurar la base.”
Pero no todos lo veían claro.
Alguien preguntó si “Cliente” era lo mismo que “Usuario” del portal.
Otro confundió “Producto” con “SKU promocional”.
Y uno más… quería agregar directamente un campo para “Campañas activas”.
Cristina respiró hondo.
Ese momento no se trataba de enseñar modelado.
Se trataba de alinear mentalidades.
—“Un modelo de datos no es una base de datos. Es un lenguaje común entre todos. Si no acordamos el significado de una entidad… da igual cuántos ERD hagamos.”
Ese fue el punto de quiebre.
Por primera vez, dejaron de hablar de tecnología…
Y empezaron a hablar de cómo trabajan los datos que realmente importan.
🧠 Reflexión técnica
El DMBOK2 define el modelado de datos como la representación formal de estructuras de datos que capturan requisitos del negocio.
Pero entender sus componentes esenciales es lo que permite construir modelos duraderos:
🧩 Componentes Clave de un Modelo de Datos
| Elemento | Descripción |
|---|---|
| Entidades | Representan objetos o conceptos significativos (Cliente, Producto, Empleado). |
| Atributos | Características de las entidades (nombre, fecha de alta, precio). |
| Relaciones | Conexiones entre entidades (uno a muchos, muchos a muchos). |
| Cardinalidad | Define cuántas instancias de una entidad pueden estar asociadas con otra. |
| Llaves primarias y foráneas | Clave técnica para la integridad relacional. |
🎯 Buenas prácticas según el DMBOK2
- Modelar con propósito de negocio, no solo técnico.
- Mantener consistencia terminológica entre dominios.
- Documentar supuestos y reglas de negocio junto al modelo.
🛠 Ejemplo práctico
Si tu empresa tiene múltiples fuentes que definen “cliente” de forma distinta, no empieces con tablas ni scripts.
Empieza dibujando el modelo lógico.
Haz que todos vean y acuerden el significado de cada entidad.
Un modelo mal entendido es peor que no tener ninguno.