Cuando un Excel de mil filas repite el nombre del cliente en cada pedido y actualizar un teléfono obliga a modificar trescientas celdas a mano, el problema no es la hoja de cálculo: es un problema de diseño. El diagrama Entidad-Relación (diagrama ER) es la herramienta que lo resuelve, funcionando como un plano arquitectónico que muestra qué cosas almacena una base de datos, qué se sabe de cada una y cómo se conectan entre sí [0:22].

¿Cuáles son los tres componentes de un diagrama ER?

Todo diagrama ER se construye con tres piezas fundamentales [0:56]:

• Entidades: son los sustantivos del negocio —Cliente, Producto, Pedido— y se dibujan como rectángulos.
• Atributos: son las características de cada entidad —nombre del cliente, precio del producto, fecha del pedido— y van listados como columnas dentro del rectángulo.
• Relaciones: son las líneas que conectan rectángulos y representan los verbos del sistema. Un cliente coloca pedidos; un pedido contiene productos.

En la clase previa se revisaron las claves primarias y las claves foráneas. Ahora esas claves cobran sentido dentro del dibujo completo [0:48].

¿Qué niveles de detalle existen en un diagrama ER?

No todos los diagramas ER muestran la misma profundidad. Existen tres niveles, y cada uno sirve para una conversación distinta [1:43].

¿Para qué sirve el nivel conceptual?

Es el más simple: solo cajas con nombres y líneas entre ellas, sin atributos ni tipos de datos. Funciona como un boceto en servilleta que se muestra al gerente para confirmar que ambos hablan de lo mismo [1:49]. Si están en una reunión con el director comercial validando que el sistema manejará clientes, pedidos y productos, este es el nivel indicado [2:48].

¿Qué agrega el nivel lógico?

Aquí aparecen los atributos, las claves primarias, las claves foráneas y los símbolos de cardinalidad. Es independiente de cualquier motor de base de datos, como el plano técnico del arquitecto que muestra habitaciones y puertas, pero todavía no especifica el material [2:37].

¿Cuándo se necesita el nivel físico?

En el nivel físico se definen los tipos de datos exactos —entero, texto de cien caracteres, decimal— junto con restricciones e índices específicos de un motor como SQL Server o PostgreSQL [3:23]. Este nivel va dirigido al desarrollador que escribirá código.

¿Cómo leer la notación pata de gallo en un diagrama ER?

La notación Crow's Foot utiliza solo tres símbolos al final de cada línea de relación [3:01]:

• Rayita vertical: como una barrera de peaje cerrada, significa exactamente uno; es obligatorio [3:33].
• Pata de gallo: la carretera se abre en tres carriles al llegar al rectángulo, indicando muchos registros posibles [3:45].
• Circulito: como un semáforo apagado, representa cero; la relación es opcional [3:57].

Cada extremo de la línea lleva dos símbolos apilados. El pegado al rectángulo indica el mínimo (obligatorio u opcional) y el de atrás señala el máximo (uno solo o muchos) [4:08].

Por ejemplo, entre Cliente y Pedido: del lado del cliente, dos rayitas significan exactamente un cliente; del lado del pedido, un circulito más una pata de gallo significan cero o muchos pedidos [4:24]. La lectura completa dice: un cliente puede tener cero o muchos pedidos, y cada pedido pertenece a exactamente un cliente [4:58].

Cuando la relación es de muchos a muchos —un pedido contiene muchos productos y un producto aparece en muchos pedidos— las bases de datos relacionales necesitan una tabla puente. En el ejemplo de TiendaLatam, esa tabla se llama DetallePedido y almacena su propia clave primaria más dos claves foráneas: una apuntando a Pedidos y otra a Productos [5:45]. Además, guarda el precio unitario en el momento de la compra, porque si el precio cambia mañana, los pedidos históricos deben reflejar lo que el cliente realmente pagó [6:00].

¿Cómo construir un diagrama ER desde cero en seis pasos?

El proceso completo sigue esta secuencia [5:33]:

• Paso uno: identificar las entidades escuchando los sustantivos del negocio.
• Paso dos: definir los atributos de cada entidad —nombre, correo, teléfono, fecha de registro.
• Paso tres: asignar claves primarias, un identificador único por entidad.
• Paso cuatro: trazar las relaciones entre entidades.
• Paso cinco: resolver las relaciones muchos a muchos con tablas puente.
• Paso seis: dibujar todo en notación Crow's Foot y validar.

Un truco práctico para el paso uno: si un sustantivo puede existir por sí solo en el mundo real, probablemente es una entidad. Un cliente existe aunque nunca compre nada, pero la fecha de un pedido no existe sin el pedido; la fecha es atributo, no entidad [7:17].

Validar consiste en tomar preguntas reales del negocio y trazar el camino en el diagrama como si fuera un mapa de rutas [7:39]. Por ejemplo: ¿qué compró María López en marzo? Se parte de Clientes, se sigue la línea a Pedidos, se filtra por fecha, se salta a DetallePedido y se llega a Productos. Si el camino se completa sin interrupciones, el modelo funciona [7:47]. Si hay un callejón sin salida, falta una relación o un atributo.

Es infinitamente más barato corregir un diagrama en papel que reestructurar una base de datos en producción [8:31]. ¿Ya identificaron las entidades de su propio trabajo y las cardinalidades entre ellas? Compartan su diagrama y discútanlo con el equipo antes de escribir una sola línea de código.