Un diagrama entidad-relación comunica estructura y cardinalidad. Ayuda al diseño y la incorporación de personas, pero no sustituye las migraciones ejecutables. Úsalo para explicar restricciones importantes y conserva la definición de la base de datos como fuente de verdad.
Modela entidades y atributos
erDiagram
CUSTOMER ||--o{ ORDER : places
ORDER ||--|{ ORDER_ITEM : contains
PRODUCT ||--o{ ORDER_ITEM : appears_in
CUSTOMER { uuid id PK string email UK }
ORDER { uuid id PK uuid customer_id FK string status }
ORDER_ITEM { uuid order_id FK uuid product_id FK int quantity }
PRODUCT { uuid id PK string name decimal price }Los tipos de atributo son descriptivos. Usa el vocabulario del equipo, pero no asumas que el diagrama aplica precisión, índices, valores predeterminados o restricciones específicas del motor.
Lee la cardinalidad desde ambos extremos
CUSTOMER ||--o{ ORDER indica que cada pedido pertenece exactamente a un cliente y un cliente puede tener cero o muchos pedidos. Leer ambos extremos evita ocultar la opcionalidad. Etiquetas como places o contains documentan la relación; no son nombres de claves foráneas.
Muestra la cantidad adecuada de esquema
Columnas de auditoría, índices técnicos y campos de integración pueden saturar una vista general. Incluye solo claves y atributos necesarios para comprender el dominio y enlaza las migraciones o la documentación generada para el detalle completo.
Verifica las suposiciones con la base de datos
Comprueba que opcionalidad, unicidad y dirección coincidan con las restricciones reales. Una línea que afirma “exactamente uno” mientras la clave foránea admite nulos induce a error. Marca en texto las relaciones inciertas en vez de presentar conjeturas como reglas.
Usa la plantilla ER del editor Mermaid para validar la sintaxis y exportar un SVG escalable.