🗄️ Mermaid

Diagrama entidad-relación

Diseña esquemas de base de datos con sentido

Abrir este ejemplo en el editor Generar uno con IA

¿Qué es un Diagrama entidad-relación?

Un diagrama ER muestra las entidades de una base de datos, sus atributos y la cardinalidad de las relaciones entre ellas (uno a muchos, muchos a muchos). Es el plano de toda base de datos relacional.

Los diagramas entidad-relación pertenecen al pull request que añade una migración y a la primera hora del onboarding, donde la forma más rápida de explicar un producto suele ser su modelo de datos. Hacen explícita la cardinalidad: que un cliente tenga una dirección o varias es una regla de negocio, no un detalle. Lo que no recogen es el diseño físico — ni índices, ni particionado, ni patrones de consulta. El fichero de migración sigue siendo la fuente de verdad.

Ejemplo en directo

Código Mermaid

erDiagram
    CUSTOMER ||--o{ ORDER : places
    ORDER ||--|{ ORDER_LINE : contains
    PRODUCT ||--o{ ORDER_LINE : "ordered in"
    CUSTOMER {
      string id PK
      string email UK
    }
    ORDER {
      string id PK
      date created_at
    }

Ejemplo en directo

Cuándo usarlo

Diseñar un nuevo esquema de base de datos antes de la primera migración

Documentar un esquema existente para los nuevos miembros del equipo

Debatir los modelos de datos con interlocutores no técnicos

Errores frecuentes

Cardinalidad leída del lado equivocado

En CUSTOMER ||--o{ ORDER : places, el || junto a CUSTOMER significa un cliente por pedido, y el o{ junto a ORDER, cero o más pedidos por cliente. Cada marcador cuenta su propia entidad vista desde el otro extremo.

Una relación sin etiqueta

CUSTOMER ||--o{ ORDER a secas es un error de análisis: Mermaid espera los dos puntos. Escribe : places, o : "" cuando la relación sea evidente. Es con diferencia el fallo más frecuente en erDiagram.

Nombres de entidad con espacios

ORDER LINE ||--o{ PRODUCT no crea una entidad llamada ORDER LINE: el nombre se parte en el espacio. Entrecomíllalo como "ORDER LINE", o usa el guion bajo que ya sigue el resto del esquema.

Sintaxis básica

.mmd

erDiagram
    USER ||--o{ POST : writes
    USER {
      string id PK
      string email
    }

CUSTOMER ||--o{ ORDER : places
Toda relación necesita una etiqueta tras los dos puntos; escribe : "" cuando no haya nada útil que decir. Entrecomilla las etiquetas con espacios, como en : "ordered in".
ORDER { string id PK decimal total "in cents" }
Los atributos son tipo y luego nombre, después marcadores de clave opcionales (PK, FK, UK, separados por comas) y un comentario entrecomillado. Los tipos son texto libre y no se valida nada.
ORDER ||--|{ LINE : contains CUSTOMER }o..o{ PROMO : uses
Una línea continua es una relación identificadora: el hijo no puede existir solo. Los puntos marcan una no identificadora, en la que la clave foránea es opcional.
erDiagram direction LR
La dirección por defecto es de arriba abajo. direction LR despliega en horizontal un esquema ancho, lo que suele encajar mejor en una página de documentación que una columna alta de entidades.

Preguntas sobre este diagrama

¿Cómo se leen los símbolos de cardinalidad como ||--o{ ?

|| significa exactamente uno, o| cero o uno, }| uno o más, }o cero o más. Así, CUSTOMER ||--o{ ORDER se lee «un cliente realiza cero o más pedidos».

¿Puedo generar un diagrama ER a partir de SQL?

Sí — pega tus sentencias CREATE TABLE o describe tus datos y la IA produce el diagrama ER correspondiente con claves y relaciones.

¿Puedo versionar un diagrama entidad-relación junto a mis migraciones?

Sí, y esa es la razón principal para escribirlo como texto. El diagrama vive junto a la migración, se compara línea a línea en la revisión y un cambio de esquema que nadie reflejó aparece como una edición que falta.

¿Puede un diagrama ER de Mermaid mostrar índices y restricciones?

No. Muestra entidades, tipos de atributo y marcadores PK, FK o UK, y nada más: ni índices, ni valores por defecto, ni restricciones CHECK, ni triggers. Tómalo como un mapa del esquema, no como una especificación a partir de la cual generar una base de datos.

¿Cómo modelo una relación de muchos a muchos?

O la dibujas directamente con }o--o{, o modelas de forma explícita la entidad intermedia: STUDENT ||--o{ ENROLMENT y COURSE ||--o{ ENROLMENT. Usa la segunda forma en cuanto la unión lleve columnas propias, como una fecha de matrícula.

¿Cuál es la diferencia entre PK, FK y UK?

PK marca la clave primaria, FK una clave foránea que apunta a otra entidad y UK una restricción de unicidad. Mermaid solo las dibuja como etiquetas: nunca comprueba que una FK corresponda a una clave primaria del diagrama.

¿Diagrama entidad-relación u otro tipo de diagrama?

¿Diagrama entidad-relación o diagrama de clases?

Elige según lo que vaya a hacer quien lee. Si va a escribir SQL o una migración, dale entidades, claves y cardinalidades. Si va a escribir código de aplicación, un diagrama de clases con métodos y herencia se parece más a lo que va a teclear.

¿Diagrama entidad-relación o diagrama de flujo?

El diagrama entidad-relación responde a «qué se almacena y cómo se relaciona»; el diagrama de flujo, a «qué ocurre y en qué orden». Las cajas que son sustantivos con atributos van en el primero; las que son verbos, en el segundo.

Explora otros tipos de diagramas

🔀 Diagrama de flujo 💬 Diagrama de secuencia 🧩 Diagrama de clases 🔄 Diagrama de estados 📅 Diagrama de Gantt 🥧 Gráfico circular 🧠 Mapa mental 🌿 Grafo Git 🕰️ Línea de tiempo 🚶 Recorrido del usuario 🎯 Gráfico de cuadrantes

Crea tu Diagrama entidad-relación ahora

Descríbelo en lenguaje natural — la IA escribe el código Mermaid por ti.

Abrir Mermaid Studio