Diagrama entidad-relación: qué es y cómo hacer uno paso a paso

Antes de escribir una sola línea de código, hay un paso que decide si un sistema será fácil o imposible de mantener: diseñar bien la base de datos. Y la herramienta para hacerlo es el diagrama entidad-relación.

En esta guía vas a ver qué es, cuáles son sus elementos, los tres tipos de relación que existen, un ejemplo completo resuelto y cómo convertir ese diagrama en tablas reales de MySQL.

¡Empecemos!

Qué es el diagrama entidad-relación

El diagrama entidad-relación (DER) es una representación gráfica de las entidades de un sistema, sus atributos y las relaciones que existen entre ellas. Es una herramienta visual que se utiliza durante la fase de diseño de una base de datos, antes de crear las tablas.

También lo vas a encontrar escrito como modelo E-R, o como ERD por sus siglas en inglés (entity relationship diagram).

Su utilidad es doble. Por un lado, te permite discutir la estructura de la información con otras personas —incluso con quien no programa— y detectar errores mientras corregirlos todavía es barato. Por otro, es el plano a partir del cual se crean las tablas.

Por qué se diseña antes de programar

Cambiar el diseño de una base de datos con el sistema ya en producción es de lo más costoso que existe en desarrollo: hay que migrar los datos, ajustar todas las consultas y comprobar que nada se rompió.

Corregir un diagrama en una hoja, en cambio, cuesta un borrón.

Un error en el modelo de datos descubierto después de seis meses de desarrollo cuesta muchísimo más que uno detectado en papel. Por eso el diagrama no es un trámite académico: es la etapa donde más se ahorra.

Los tres elementos de un diagrama entidad-relación

Un DER consta de tres elementos principales.

Entidades

Las entidades son objetos o conceptos del mundo real que se pueden distinguir entre sí y que tienen datos asociados. Clientes, productos, ventas: cada uno es una entidad, y con el tiempo cada una suele convertirse en una tabla de la base de datos.

Se representan mediante rectángulos.

Atributos

Los atributos son las propiedades o características de una entidad. En la entidad Cliente, sus atributos serían el nombre, la dirección o el teléfono. Terminan siendo las columnas de la tabla.

Se representan dentro de elipses, conectadas a su entidad mediante líneas.

Relaciones

Las relaciones describen cómo las entidades están conectadas entre sí: un cliente realiza una venta, un producto pertenece a una categoría.

Se representan dentro de un rombo, con líneas hacia las entidades involucradas y una etiqueta que indica la naturaleza de la relación.

Los tres tipos de relación

Antes del ejemplo conviene tener esto claro, porque es donde más se equivoca quien está empezando.

Uno a uno (1:1)

Un registro de una entidad se corresponde con un único registro de la otra.

Una persona tiene un solo carnet de identidad, y ese carnet pertenece a una sola persona.

Es la menos frecuente. Suele usarse para separar datos que se consultan poco o que son especialmente sensibles.

Uno a muchos (1:N)

Un registro de una entidad se relaciona con varios de la otra, pero no al revés.

Una categoría agrupa muchos productos, y cada producto pertenece a una sola categoría.

Es la relación más común de todas. Al llevarla a la base de datos, la clave foránea se guarda siempre en el lado «muchos».

Muchos a muchos (N:M)

Los registros de ambos lados se relacionan con varios del otro.

Una venta incluye varios productos, y cada producto aparece en varias ventas.

Aquí hay una regla importante: este tipo de relación no se puede representar directamente en una base de datos. Siempre exige una tercera tabla, llamada tabla intermedia o pivote.

El truco para no equivocarse

Enuncia siempre la relación en los dos sentidos.

Leer solo «un cliente realiza muchas ventas» podría hacerte pensar en un muchos a muchos. Al leer la vuelta —«una venta pertenece a un solo cliente»— queda claro que es uno a muchos.

Si las dos frases dicen «muchos», entonces sí es N:M y necesitas tabla intermedia.

Entidad o atributo: cómo decidir

Esta duda aparece siempre, y hay una prueba sencilla:

¿Necesitas guardar más de un dato sobre eso?

• Si de la categoría solo guardas el nombre, podría ser un atributo del producto.
• Si además guardas descripción, y quieres poder listarlas y evitar que se escriban distinto, es una entidad.

En la práctica, cuando un dato se repite en muchas filas y tiene un conjunto limitado de valores, conviene que sea entidad. Evita errores de escritura y permite cambiar el nombre en un solo sitio.

Cómo identificar las entidades de un enunciado

Aquí va el truco más útil de esta guía: lee el enunciado del problema y subraya los sustantivos. Casi siempre son entidades. Los verbos suelen ser relaciones.

Veámoslo con un caso completo.

Ejemplo resuelto: sistema de ventas

El enunciado es este:

Desarrollar un sistema de ventas tomando en cuenta las necesidades del cliente. El cliente desea registrar todas las ventas realizadas de los productos que ofrece en su tienda. Los productos están clasificados por categorías y ubicaciones. Los clientes cuentan con un kardex que los identifica de forma única.

Sustantivos: ventas, productos, categorías, ubicaciones, clientes, kardex. Verbos: registrar, clasificar, identificar.

Paso 1: identificar las entidades y sus atributos

Cada entidad tiene atributos específicos, y entre todos representan cómo funciona el sistema:

• Kardex: código de cliente, fecha de registro.
• Clientes: nombre y apellido, zona, dirección, teléfono.
• Ventas: código de venta, fecha.
• Productos: nombre del producto, precio.
• Categorías: nombre de la categoría, detalle.
• Ubicaciones: nombre de la ubicación, detalle.

Dos recomendaciones al definir atributos:

Guarda los datos en su unidad mínima. Nombre y apellido separados, no «nombre completo». Siempre puedes unirlos al mostrar; separarlos después es un dolor de cabeza.

No guardes lo que se puede calcular. La edad no se guarda: se calcula a partir de la fecha de nacimiento. Si la guardas, mañana está desactualizada.

Paso 2: identificar las relaciones entre entidades

Ahora definimos qué relación existe entre cada par de entidades, clasificándolas y enunciándolas en los dos sentidos.

Relación uno a uno

• Un cliente tiene un único kardex, y un kardex pertenece a un solo cliente.

Relación uno a muchos

• Una categoría tiene muchos productos, y un producto pertenece a una sola categoría.
• Un cliente realiza muchas ventas, y una venta pertenece a un solo cliente.

Relación muchos a muchos

• Un producto se encuentra en muchas ubicaciones, y una ubicación tiene muchos productos.
• Una venta incluye muchos productos, y un producto aparece en muchas ventas.

Paso 3: crear el diagrama

La etapa final es dibujar el diagrama a partir del análisis anterior.

Observa las dos relaciones muchos a muchos —productos con ubicaciones, y ventas con productos—. Cuando este diagrama se convierta en tablas reales, cada una de esas dos va a necesitar una tabla intermedia. Es el punto donde más se traba quien pasa del diagrama a la base de datos por primera vez.

Del diagrama a las tablas de MySQL

Una vez dibujado, la traducción es mecánica.

1. Cada entidad se convierte en una tabla, con un id como clave primaria.

2. Cada atributo se convierte en una columna, con su tipo de dato.

3. Cada relación uno a muchos añade una clave foránea en el lado «muchos»:

CREATE TABLE categorias (
    id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    nombre VARCHAR(100) NOT NULL UNIQUE,
    detalle VARCHAR(255) NULL
) ENGINE=InnoDB;

CREATE TABLE productos (
    id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    nombre VARCHAR(150) NOT NULL,
    precio DECIMAL(10,2) NOT NULL,
    categoria_id INT UNSIGNED NOT NULL,
    CONSTRAINT fk_productos_categoria
        FOREIGN KEY (categoria_id) REFERENCES categorias(id)
) ENGINE=InnoDB;

4. Cada relación muchos a muchos se convierte en una tabla intermedia con las dos claves foráneas:

CREATE TABLE venta_producto (
    venta_id INT UNSIGNED NOT NULL,
    producto_id INT UNSIGNED NOT NULL,
    cantidad INT UNSIGNED NOT NULL,
    precio_unitario DECIMAL(10,2) NOT NULL,

    PRIMARY KEY (venta_id, producto_id),

    CONSTRAINT fk_vp_venta FOREIGN KEY (venta_id)
        REFERENCES ventas(id) ON DELETE CASCADE,
    CONSTRAINT fk_vp_producto FOREIGN KEY (producto_id)
        REFERENCES productos(id) ON DELETE RESTRICT
) ENGINE=InnoDB;

Fíjate en dos detalles de esa tabla intermedia:

La clave primaria compuesta impide que el mismo producto se registre dos veces en la misma venta.

Lleva datos propios: la cantidad y el precio unitario. No pertenecen ni a la venta ni al producto, sino a la combinación de ambos. Y guardar el precio_unitario es deliberado: el precio actual del catálogo y el precio al que se vendió son dos datos distintos.

Lo desarrollamos en detalle en la lección de claves primarias, foráneas y relaciones.

Cardinalidad y participación

Dos matices que conviene anotar en el diagrama:

Cardinalidad es lo que ya vimos: 1:1, 1:N o N:M.

Participación indica si la relación es obligatoria u opcional. ¿Un producto puede existir sin categoría? Si no puede, esa columna será NOT NULL. Si puede, admitirá NULL.

Decidirlo en el diagrama te ahorra tener que alterar tablas después.

Herramientas para dibujarlo

Puedes hacerlo con papel y lápiz —es perfectamente válido, y para diseñar suele ser hasta más rápido—, o con una herramienta:

• MySQL Workbench incluye un diseñador que además genera el SQL a partir del diagrama, y puede hacer el camino inverso desde una base existente.
• dbdiagram.io, que dibuja el diagrama a partir de texto.
• draw.io, gratuito y en el navegador.

Workbench es el más completo si vas a trabajar con MySQL, y lo instalamos en la lección de herramientas.

Errores frecuentes al hacer un DER

• Confundir una entidad con un atributo. Si «zona» solo necesita un nombre, es un atributo del cliente. Si además necesita responsable, horario y cobertura, es una entidad.
• Olvidar leer la relación en los dos sentidos, que es como se termina modelando un uno a muchos donde había un muchos a muchos.
• Modelar el Excel actual del cliente. Esa planilla es cómo se las arreglaron sin sistema, no cómo debería estructurarse la información.
• Una entidad gigante con treinta atributos. Casi seguro son dos o tres entidades disfrazadas.
• Guardar datos calculables, como la edad o el total de una factura que se puede sumar.
• Empezar a dibujar antes de entender el negocio. El diagrama es el resultado del análisis, no el análisis.

Para cerrar

El diagrama entidad-relación no es un requisito académico ni un trámite: es la conversación donde se decide cómo va a estar organizada la información de un sistema durante los años que dure. Bien hecho, ahorra meses. Mal hecho, se paga en cada nueva funcionalidad.

El método, resumido: subraya los sustantivos del enunciado, decide qué es entidad y qué es atributo, enuncia las relaciones en los dos sentidos, y recién entonces dibuja.

Con el diagrama listo, el siguiente paso es llevarlo a MySQL. Puedes seguir con cómo crear una base de datos o ver el curso completo de MySQL desde el principio.

Y si tu empresa necesita un sistema y no quieres construirlo tú, en Norvic Software desarrollamos software a medida partiendo del proceso real del negocio.

Saludos y éxitos.