Resumen

Cuando un modelo de datos crece hasta nueve tablas interconectadas, explicar con palabras cómo se relacionan deja de ser práctico. La solución profesional es convertir ese mapa de relaciones en un diagrama Entidad-Relación (ER) usando la notación Crow's Foot, el estándar que utilizan los equipos de bases de datos para documentar estructuras de forma visual y sin ambigüedades.

¿Para qué sirve un diagrama ER antes de crear tablas reales?

El diagrama ER no es solo un dibujo bonito; cumple tres funciones concretas [0:44]:

  • Permite ver la estructura completa de un vistazo y detectar si algo falta antes de escribir una sola línea de código.
  • Facilita la comunicación con otras personas: un gerente puede mirar el diagrama y preguntar si debería existir una tabla de proveedores, y esa conversación ocurre cuando corregir significa borrar una línea, no reestructurar millones de registros.
  • Hace visibles los errores de diseño: si falta la tabla intermedia entre Pedidos y Productos, en el diagrama se nota de inmediato.

En otras palabras, el diagrama funciona como un plano arquitectónico que se valida antes de levantar paredes.

¿Qué componentes forman la notación Crow's Foot?

El diagrama se arma con tres piezas fundamentales [1:29]:

  • Entidades: rectángulos que representan cada tabla, con sus atributos listados adentro. La clave primaria se marca con PK y las claves foráneas con FK.
  • Relaciones: líneas que conectan los rectángulos. No son líneas simples, porque en cada extremo llevan símbolos que indican cuántos registros participan de cada lado.
  • Símbolos de la notación: son los que dan nombre al sistema.

¿Qué significa cada símbolo?

Crow's Foot significa "pata de cuervo" en inglés, y el nombre viene de uno de sus símbolos que se parece a la huella de un pájaro [2:00]. La notación usa tres símbolos básicos [2:24]:

  • Línea vertical: exactamente uno.
  • Pata de cuervo (tres líneas que se abren): muchos.
  • Círculo: cero, es decir, opcional.

Estos símbolos siempre aparecen en parejas en cada extremo de la línea [2:42], y cada combinación describe una regla distinta. La cardinalidad indica cuántos registros pueden participar, mientras que la opcionalidad indica si esa participación es obligatoria o no [2:13].

¿Cómo se leen las combinaciones de símbolos?

  • Dos líneas verticales juntas: siempre participa exactamente un registro [2:48].
  • Círculo junto a línea vertical: puede haber uno o ninguno [2:54].
  • Línea vertical junto a pata de cuervo: siempre hay al menos uno [3:00].
  • Círculo junto a pata de cuervo: puede haber muchos o ninguno [3:06].

Con esas cuatro combinaciones se puede describir cualquier tipo de relación entre tablas.

¿Cómo se construye el modelo completo de TiendaLatam?

El ejemplo práctico aplica estos símbolos a la relación entre Países y Sucursales [3:17]. Del lado de Países va una línea vertical porque un país puede tener muchas sucursales; del lado de Sucursales va la pata de cuervo porque muchas sucursales pertenecen a un solo país. Para la opcionalidad: un país puede existir sin sucursales (círculo del lado de Sucursales = cero o muchos), pero una sucursal siempre está en algún país (línea vertical obligatoria del lado de Países = exactamente uno) [3:33].

Una regla clave conecta esto con lo aprendido sobre claves foráneas: la FK siempre vive en el lado de la pata de cuervo [3:59]. Sucursales carga PaisID porque es el lado de muchos; Pedidos carga ClienteID por la misma razón.

El punto de partida del modelo son las tres entidades independientes: Países, Categorías y Tipos de Cliente [4:19]. Son catálogos puros, sin claves foráneas. Desde ahí se forman cadenas: Sucursales se conecta con Países, Empleados con Sucursales, Clientes con Tipos de Cliente y con Países, y Productos con Categorías [4:37].

Pedidos es la tabla donde converge toda la operación del negocio [5:06], con tres claves foráneas que apuntan a Clientes, Empleados y Sucursales. Cada venta registra quién compró, quién atendió y en qué sucursal ocurrió [5:19].

La relación entre Pedidos y Productos es muchos a muchos, y se resuelve con la tabla Detalle de Pedidos como tabla intermedia [5:39]. En el diagrama se ve como dos líneas separadas, cada una con línea vertical en un extremo y pata de cuervo en el otro. Detalle de Pedidos además tiene atributos propios: cantidad, precio unitario y subtotal [5:17], datos que pertenecen a esa combinación específica.

Una regla para memorizar: en Crow's Foot nunca deberían ver pata de cuervo en ambos extremos de una misma línea directa entre dos tablas [6:05]. Si eso aparece, falta la tabla intermedia.

¿Cuáles son los errores más comunes al dibujar el diagrama?

  • Poner la clave foránea en el lado equivocado: colocar SucursalID en Países implica que un país solo tiene una sucursal [6:38].
  • Olvidar la tabla intermedia en una relación muchos a muchos [6:53].
  • Dibujar una entidad sin clave primaria, lo que hace imposible distinguir un registro de otro [6:59].
  • Dejar conexiones incompletas: si Pedidos tiene tres FK y solo dibujan dos, están dejando fuera una regla del negocio [7:07].

¿Ya dibujaste tu propio diagrama ER de TiendaLatam? Compártelo en los comentarios para comparar cómo lo resolvieron otros estudiantes y verificar que el diagrama ya habla tu idioma.