La notación pata de gallo

La pata de gallo -propiamente, la notación Information Engineering- pone dos marcas en cada extremo de cada línea de relación. La que está más lejos de la entidad es el máximo, y la que está más cerca es el mínimo.

Combínalos y hay exactamente cuatro posibilidades, que son toda la notación:

Esto es lo único de la pata de gallo que va de verdad contra la intuición, y explica la mayoría de los diagramas mal leídos. Los símbolos de un extremo describen la entidad de ese extremo, y se leen al viajar hacia ella.

En la cuarta línea del diagrama de arriba, la pata de gallo está en el extremo de Order. No significa «muchos clientes». Significa: para un cliente hay cero o más pedidos. Dilo como un trayecto -«salgo de un cliente, sigo la línea y llego a cero o más pedidos»- y la dirección deja de ser ambigua.

Un hábito práctico que elimina el problema del todo: escribe la frase verbal en la línea en el sentido de lectura, y comprueba la lectura inversa en voz alta antes de seguir. Treinta segundos por relación, y caza errores que sobreviven meses en un documento.

El estilo de línea lleva una segunda información, y va de claves, no de cantidades.

La prueba es una pregunta: ¿podría identificarse esta fila sin conocer a su padre? Una línea de pedido número 3 no significa nada sin saber de qué pedido: eso es identificativa. Un pedido que pertenece al cliente 41 sigue siendo el pedido 8817 pase lo que pase: eso es no identificativa.

Una pata de gallo en ambos extremos dice «muchos a muchos», y ninguna base de datos relacional puede almacenar eso en dos tablas. La relación se convierte en una entidad propia -de unión, asociativa o de enlace- que mantiene una clave ajena hacia cada lado.

De ahí se siguen dos cosas, y la segunda es la razón de hacerlo pronto y no en el momento de implementar:

1. La entidad de unión suele tener atributos propios. Una matrícula tiene fecha, nota, estado. Esos atributos no tenían dónde vivir mientras la relación era una línea, y su ausencia escondía un hueco en el modelo.
2. La entidad de unión merece un nombre de verdad. Enrolment, Booking, Assignment, no StudentCourse. Un experto del dominio reconoce el primero y no puede revisar el segundo, y ese nombre suele ser una palabra que el negocio ya usa.

Fíjate en las claves de la entidad de unión de arriba: ambas claves ajenas juntas forman la clave primaria, y eso es lo que impide que el mismo estudiante se matricule dos veces en el mismo curso. Esa restricción salió gratis de modelarlo bien, y de otro modo habría sido una validación que alguien recordó escribir.

Nada de esto es excluyente. Muchísimos proyectos reales dibujan pata de gallo para la base de datos y un diagrama de clases para el modelo del dominio, y mantienen ambos, porque responden a preguntas distintas sobre los mismos sustantivos.

1. Símbolos en el extremo equivocado. El error más común de la notación. Lee las dos frases en voz alta.
2. Todo opcional. Un círculo en cada posición interior significa que el modelo no afirma ninguna regla, y cada una acaba siendo código de aplicación.
3. Muchos-a-muchos dejado en un modelo lógico. Bien conceptualmente, imposible físicamente. Resuélvelo y nombra la unión.
4. Entidades de unión nombradas por concatenación. OrderProduct no le dice nada a un revisor; OrderLine se lo dice todo.
5. Confiar solo en el estilo de línea para las relaciones identificativas. Las herramientas discrepan. Muestra también la clave compuesta en la caja.
6. Relaciones sin etiquetar. El verbo es lo que hace la línea legible en voz alta, y leerla en voz alta es la revisión.

Con la cardinalidad resuelta, la siguiente pregunta es qué tablas debería haber siquiera, y eso es el diseño de esquema: claves, normalización y el viaje de un modelo al DDL.