Modelo entidad-relación (MER): guía completa con ejemplos

Antes de escribir una sola línea de CREATE TABLE, hay una pregunta que decide si tu base de datos va a funcionar bien o va a ser un dolor de cabeza durante años: ¿qué datos existen realmente en este negocio y cómo se relacionan entre sí?Responder eso es lo que llamamos modelado de datos. Y aunque suene abstracto, en la práctica es lo más parecido a hacer los planos antes de construir una casa. Nadie levanta paredes y después decide dónde va el baño.En este post vamos a recorrer todo el camino: qué es el modelado de datos, sus tres niveles, cómo se construye un modelo entidad-relación, y las dos notaciones más usadas para dibujarlo. Al final, resolvemos un caso completo de un taller mecánico con ambas notaciones.

1. ¿Qué es el modelado de datos?

El modelado de datos ayuda a definir y estructurar los datos en el contexto de los procesos empresariales a los que sirven. No es un ejercicio académico: es lo que sostiene activamente el desarrollo del software.Además, modelar te obliga a tomar decisiones que después son carísimas de cambiar:Cómo se van a almacenar los datosCómo se van a compartir entre módulos, sistemas o equiposCómo se van a actualizarCómo se van a aprovechar para generar valor

Los tres niveles del modelado

El proceso no se hace de un solo golpe. Se descompone en tres modelos que se encadenan: la salida de uno es la entrada del siguiente.

2. El modelo conceptual

El modelo conceptual, también llamado entidad-relación (MER), fue expuesto por Peter P. Chen en 1976. Es una técnica de representación gráfica de un conjunto de datos (las entidades) y las relaciones existentes entre ellos.Sus características principales:Refleja solo la existencia de los datos, no sus transformaciones. Dice qué hay, no qué se hace con ello. Ojo con esto: es la confusión número uno de quien viene de diagramas de flujo.Incluye todos los datos del sistema en estudio, por lo que está orientado a cualquier tipo de aplicación.Es independiente del sistema operativo donde vaya a convivir la base de datos.No es restrictivo respecto al espacio, al almacenamiento ni al tiempo de ejecución.Es fácil de mantener y está abierto a la evolución del sistema.Esa independencia es justo lo que lo hace valioso: un buen MER sigue siendo válido si mañana cambias de MySQL a PostgreSQL, o si migras de un servidor local a la nube.

3. Las piezas del MER

El modelo entidad-relación está formado, como su nombre indica, por entidades y relaciones. Vamos pieza por pieza.

3.1 Entidad

Una entidad es un ente real o irreal que existe y del cual se desea almacenar información.Que sea "irreal" no es un capricho: un pedido, una matrícula o una reserva no son objetos que puedas tocar, pero existen conceptualmente y necesitas guardar información sobre ellos.Una entidad es un conjunto de ocurrencias, es decir, un conjunto de datos de un determinado individuo, objeto o cosa. Y a cada uno de los diferentes datos de la ocurrencia se le llama atributo.

Entidades regulares (fuertes o propias)

Son aquellas que tienen existencia por sí mismas y cuyas ocurrencias son identificables por sí mismas. Se representan con un rectángulo y su nombre, que suele ser un sustantivo.CLIENTE, PRODUCTO, PROVEEDOR: todas existen sin depender de nadie.

Entidades débiles

Son aquellas cuyas ocurrencias solo son identificables por estar asociadas a otra u otras entidades: alguno de los atributos que las identifican se refiere a otra entidad.El ejemplo clásico: una LÍNEA DE PEDIDO no significa nada por sí sola. "Línea número 3" no identifica nada; necesitas saber línea 3 de qué pedido.

En Oracle Data Modeler las entidades débiles se representan igual que las regulares, pero con peculiaridades propias de la herramienta.

3.2 Relación

Una relación es una asociación o correspondencia entre diferentes entidades. Se representa mediante un rombo con un nombre que es un verbo.Ese detalle del verbo importa más de lo que parece. Si no puedes nombrar la relación con un verbo claro (compra, suministra, notifica, imparte), probablemente no tienes clara la regla de negocio que estás modelando.

3.3 Grado de una relación

El grado se define como el número de entidades que participan en la relación:Grado 1 (reflexiva): una entidad se relaciona consigo misma. Ejemplo: un EMPLEADO supervisa a otro EMPLEADO.Grado 2 (binaria): intervienen dos entidades. Es el caso más frecuente con diferencia.Grado 3 (terciaria): intervienen tres entidades. Y así sucesivamente.

3.4 Tipo de correspondencia

El tipo de correspondencia representa la participación en la relación de cada una de las entidades afectadas, es decir, el número máximo de ocurrencias de cada entidad que pueden intervenir en una ocurrencia de la relación.Hay tres tipos:1:1 (una a una). A cada ocurrencia de una entidad le corresponde no más de una de la otra, y viceversa. Ejemplo: un país tiene una capital y una capital pertenece a un país.1:N (una a muchas). A cada ocurrencia de la primera entidad le corresponden varias de la segunda, y a la de la segunda le corresponde una de la primera. Ejemplo: un cliente realiza muchos pedidos, pero cada pedido es de un solo cliente.M:N (muchas a muchas). A cada ocurrencia de la primera entidad pueden corresponderle más de una ocurrencia de la segunda, y viceversa. Ejemplo: un alumno cursa varias asignaturas y una asignatura tiene varios alumnos.

3.5 Cardinalidad

Aquí está la parte que más se atraganta, así que vamos despacio.La cardinalidad de una entidad en una relación mide el máximo y el mínimo de ocurrencias de una entidad que pueden estar relacionadas con una ocurrencia de otra u otras entidades que participan en la relación. Se pone una a cada lado de la relación.La clave para no perderse: la cardinalidad se escribe como (mínimo, máximo).El mínimo responde a: ¿es obligatorio? → 0 = no, 1 = síEl máximo responde a: ¿cuántos como mucho? → 1 = uno, n = muchos

Tabla: diferentes tipos de cardinalidades existentes en el análisis de datos.

Truco de examen: cuando dudes, tradúcelo a una frase con "al menos" y "como mucho". (0,n) = "al menos ninguno y como mucho muchos". Si la frase suena rara para tu caso, la cardinalidad está mal.

3.6 Relaciones débiles: dos tipos de dependencia

Cuando una entidad débil se relaciona con la fuerte de la que depende, esa relación puede ser de dos tipos:Dependencia de existencia. Las ocurrencias de la entidad débil no pueden existir si desaparece la ocurrencia fuerte de la que dependen. Estas se tratan como si fueran una relación entre dos entidades regulares.Dependencia de identificación. Se cumple la dependencia de existencia y además la entidad débil no puede identificarse únicamente con sus atributos propios: necesita añadir la clave de la entidad regular de la que depende.La diferencia práctica: en la de existencia el problema es sobrevivir; en la de identificación, además, el problema es tener nombre propio.

3.7 Identificadores y claves

Aquí cerramos el vocabulario básico:Ocurrencia: conjunto de atributos de un determinado elemento de una relación o entidad. (Una fila, para entendernos.)Atributo: la unidad indivisible de una entidad o relación. Sirve para identificar y definir a la entidad o la relación.Identificador (superclave o determinante): conjunto de uno o más atributos que permiten identificar de forma única una ocurrencia de una entidad dentro de un conjunto de ellas.Claves candidatas: aquellas que pueden ser claves primarias. De entre las claves candidatas, una de ellas será la clave principal, la cual identifica unívocamente a cada ocurrencia.Clave ajena (foránea): el atributo o conjunto de atributos de una entidad que son clave primaria en otra entidad. Es el pegamento que une las tablas.

4. Generalización: supertipos y subtipos

A veces varias entidades comparten tantos atributos que separarlas es absurdo... pero unirlas del todo tampoco funciona. Ahí entra la generalización.Una entidad o supertipo puede descomponerse en subentidades o subtipos; a esto se le conoce como jerarquías entre entidades. Los atributos del supertipo son heredados por el subtipo, pero no al revés. Una generalización se anota en el modelo mediante un triángulo invertido.Si has visto herencia en programación orientada a objetos, es exactamente la misma idea.Para trabajar con jerarquías hay que manejar dos pares de conceptos:

4.1 Totalidad y parcialidad

Un supertipo es jerárquico total si los subtipos cubren todos los posibles estados del supertipo. Si solo cubrieran parte de los estados, sería parcial.Si es total, se pone un círculo encima del triángulo invertido.Si es parcial, no se pone nada.Caso de totalidad: un supertipo PERSONA con los subtipos infancia, adolescencia, adulto y tercera edad. No existen otros subtipos que cubran la vida de una persona, así que la jerarquía es total. Si faltara uno o varios de esos subtipos, sería parcial.

Nota: en Data Modeler esta situación no se contempla.

4.2 Exclusiva o solapada

Un supertipo es jerárquico solapado si puede haber ocurrencias que pertenezcan a más de uno de los subtipos. Si las ocurrencias fueran disjuntas, sería exclusiva.Si es exclusiva, se representa mediante un arco.Caso de solapada: un supertipo PERSONA con dos subtipos, trabajador y estudiante. Puede haber personas que solo estudien, personas que solo trabajen, o personas que hagan ambas cosas. Si no se cumpliera el caso de "ambas cosas", sería exclusiva.

4.3 Las cuatro combinaciones

Combinando ambos criterios salen cuatro jerarquías posibles en notación de Chen:

Regla mnemotécnica para memorizarlo:

🔵 Círculo = Total (cubre todo, por eso se "cierra" el círculo) 🌙 Arco = Exclusiva (el arco separa, no deja que se mezclen)

5. Metodologías para confeccionar el MER

Ya sabemos qué hay que representar. Falta el cómo dibujarlo. Existen dos notaciones dominantes.

5.1 Metodología de Chen

La notación de Chen suele resultar muy efectiva a la hora de modelar conceptos del mundo real: representa las entidades que intervienen y las relaciones entre ellas.Los diagramas de Chen son un primer paso para comprender la estructura de la base de datos y son muy adecuados para la realización de tormentas de ideas y diagramas rápidos.Existen muchas herramientas capaces de desarrollar esta metodología. Una de las más efectivas, gratuita y online, es ERDPlus.

Simbología de Chen

Tabla: simbología de la metodología de Chen.Hay una lógica muy elegante detrás: lo doble es lo débil o lo complejo. Rectángulo doble = entidad débil. Rombo doble = relación M:N.

5.2 Metodología de Martin

La metodología de Martin también es bastante efectiva a la hora de modelar el mundo real en entidades y las interrelaciones sobre estas. Los diagramas de Martin son una primera aproximación para entender cómo será la base de datos futura.Es una metodología más simple que la anterior: además de la entidad regular y la débil, las relaciones están basadas en líneas. Toda la información de cardinalidad viaja en la propia línea:Si la línea es discontinua → indica opcionalidad: el valor mínimo de la cardinalidad es 0.Si la línea es continua → indica obligatoriedad: el mínimo es 1.La cardinalidad máxima se detecta con el símbolo < al final de la línea (la famosa "pata de gallo"): si tiene el símbolo indica muchos; si no lo tiene, uno.Y ya está. Con esas tres reglas lees cualquier diagrama de Martin.

Simbología de Martin

5.3 ¿Cuál uso?

En la práctica: Chen para pensar, Martin para trabajar.

6. Caso práctico resuelto: el taller de reparaciones

Nada de esto se asienta hasta que lo aplicas. Vamos con un caso completo.

El enunciado

Taller Mecánico Nor Andino atiende reparaciones de vehículos livianos y quiere dejar atrás sus cuadernos de registro. El dueño le explica al analista cómo funciona el negocio:Cada cliente que llega al taller queda registrado con un código interno, su nombre completo, su DNI, un teléfono de contacto y su dirección. Un cliente puede traer al taller más de un vehículo, y de hecho varios clientes de flota traen tres o cuatro.De cada vehículo se anota la placa, la marca, el modelo y el año de fabricación. La placa es única, así que sirve para identificarlo.Cuando el mecánico revisa un vehículo, registra cada avería detectada por separado: le asigna un código, escribe una descripción, la fecha en que se detectó y el importe presupuestado de la reparación. Cada avería queda en estado notificada hasta que el cliente decide si la aprueba o la rechaza, porque nada se repara sin su visto bueno.Una vez terminados los trabajos, el taller emite una única factura que agrupa todas las averías aprobadas de ese vehículo. De la factura se guarda el número, la fecha de emisión y el total. Puede haber averías rechazadas que nunca lleguen a facturarse.Reparar una avería suele exigir cambiar repuestos. De cada repuesto se registra su código, descripción, precio de venta y stock disponible. Una misma avería puede consumir varios repuestos, y un mismo repuesto se usa en muchas averías distintas; por eso interesa saber cuántas unidades se consumieron en cada caso.Los repuestos llegan al almacén del taller por medio de proveedores, identificados por su código, razón social, teléfono y categoría. Un proveedor abastece varios repuestos y un mismo repuesto puede comprarse a más de un proveedor, así que conviene registrar de cada compra la cantidad, la fecha y el precio pactado.Se pide: diseñar el modelo entidad-relación con la metodología de Chen y con la de Martin.

Paso 1: identificar las entidades

Una técnica sencilla: subraya los sustantivos del enunciado y pregúntate de cuáles necesitas guardar información. Aquí salen seis: CLIENTE · VEHICULO · AVERIA · FACTURA · REPUESTO · PROVEEDOR

Atención a este detalle, que es el que más se falla. Sería tentador guardar la placa como un simple atributo de CLIENTE y ahorrarse una entidad. Pero el enunciado dice que un cliente puede traer más de un vehículo, y un atributo solo admite un valor. Si metes la placa dentro de CLIENTE, el modelo te obliga a duplicar el cliente entero por cada carro que traiga.La regla práctica: si algo puede repetirse para una misma ocurrencia y además tiene datos propios, no es un atributo, es una entidad.

Paso 2: identificar los atributos

De cada entidad extraemos los datos que el enunciado menciona. La clave primaria va en negrita:

Fíjate en la convención de nombres: tres letras del dato + guion bajo + nombre de la entidad. Cuando el modelo crece a cuarenta tablas, saber de un vistazo a qué entidad pertenece cada columna te ahorra muchísimo tiempo. Elige la convención que quieras, pero elige una y no la rompas nunca.Nota también que pla_vehiculo es clave primaria y no hemos inventado un código artificial: cuando el mundo real ya te da un identificador único y estable, úsalo.

Paso 3: identificar las relaciones y sus cardinalidades

Ahora los verbos. Y con cada verbo, la pregunta de la cardinalidad: ¿cuántos como mínimo y cuántos como máximo?

La cardinalidad que ponemos junto a cada entidad indica en cuántas ocurrencias de la relación participa cada ocurrencia de esa entidad. Leámoslas en voz alta, que es la única forma de validarlas:

CLIENTE (1,n) → un cliente registrado tiene al menos un vehículo y puede tener muchos.

VEHICULO (1,1) → cada vehículo pertenece a un único cliente, obligatoriamente.

AVERIA (0,1) → una avería puede no estar en ninguna factura (si el cliente la rechazó) o estar en una sola.

Aquí es donde el enunciado nos obligó a poner un cero, y por eso conviene leer el enunciado buscando las excepciones.FACTURA (1,n) → una factura no existe vacía: agrupa al menos una avería.

Paso 4: los atributos de las relaciones

Dos de las relaciones llevan atributos propios, y esto es importante:

¿Por qué no pueden ir dentro de una entidad? Porque no pertenecen ni a una ni a la otra. El precio al que un proveedor te vendió un repuesto no es un dato del repuesto (cada proveedor te lo cobra distinto) ni del proveedor (te vende cosas distintas a precios distintos): es un dato del hecho de la compra.Regla práctica: si un dato solo tiene sentido cuando existen las dos ocurrencias a la vez, pertenece a la relación. Y las relaciones M:N son las que más suelen tener atributos propios.

Paso 5: el diagrama de Chen

Paso 6: el diagrama de Martin

Caso práctico 2: control académico de una universidad

El enunciado

El área de registros académicos de una universidad quiere reemplazar sus hojas de cálculo por una base de datos. Esto es lo que le explican al analista:De cada alumno se registra un código interno, su nombre completo, su DNI, el correo institucional y la fecha en que ingresó.Todo alumno pertenece a una única carrera, y una carrera reúne a muchos alumnos. De cada carrera se guarda su código, su nombre y la duración en ciclos.Una asignatura se identifica por su código, y de ella se anota el nombre, el número de créditos y el ciclo en que se dicta. Cada asignatura pertenece a una sola carrera, mientras que una carrera ofrece muchas asignaturas.Cada asignatura tiene un docente responsable, y un mismo docente puede tener varias asignaturas a su cargo. Del docente se registra su código, nombre, especialidad y correo institucional.Un alumno se matricula en muchas asignaturas y una asignatura reúne a muchos alumnos matriculados. De cada matrícula interesa saber la nota obtenida, la fecha en que se matriculó y el número de intento, porque un alumno puede llevar la misma asignatura más de una vez.Se pide: diseñar el modelo entidad-relación con la metodología de Chen y con la de Martin.

Paso 1: identificar las entidades

ALUMNO · CARRERA · ASIGNATURA · DOCENTE

La trampa de este caso. Casi todo el mundo crea una entidad CALIFICACION o NOTA. Y es un error.Pregúntate: ¿existe una nota por sí sola? No. Una nota solo existe cuando hay un alumno concreto y una asignatura concreta a la vez. No es un ente del que queramos guardar información: es el dato que produce el cruce de dos entidades.Por eso la nota es un atributo de la relación matricula, no una entidad. Fíjate en que es la trampa exactamente inversa a la del taller mecánico: allí sobraba un atributo que debía ser entidad (VEHICULO); aquí sobra una entidad que debe ser atributo.

Paso 2: identificar los atributos

Misma convención que en el caso anterior: tres letras del dato + guion bajo + nombre de la entidad.

Paso 3: identificar las relaciones y sus cardinalidades

Leídas en voz alta:ALUMNO (1,1) → todo alumno estudia una carrera, y solo una.CARRERA (1,n) → una carrera tiene al menos un alumno y puede tener muchos.ASIGNATURA (1,1) en ofrece → cada asignatura pertenece a una sola carrera. Es la restricción que pedía el enunciado.ALUMNO (0,n) en matricula → el cero importa: un alumno recién ingresado todavía no se matriculó en nada.

Paso 4: los atributos de la relación

La relación matricula lleva tres atributos propios:

Aquí está la ventaja de haber resistido la tentación de crear la entidad CALIFICACION: los tres datos caen de forma natural en el mismo sitio.

Paso 5 y 6: los diagramas

Caso práctico 3: empleados de un departamento (con generalización)

El enunciado

El departamento comercial de una empresa quiere ordenar la información de su personal. El jefe de área lo describe así:De todo empleado se registra su DNI, nombre completo, dirección, teléfono y sueldo. Cada empleado pertenece a un solo departamento, y un departamento tiene varios empleados a su cargo. Del departamento interesa su código, su nombre y su ubicación.Los empleados se agrupan en tres perfiles: desarrolladores, vendedores y compradores — aunque hay personal que no encaja en ninguno de los tres, como el equipo administrativo. Nadie desempeña dos perfiles a la vez.De los desarrolladores se anota la metodología con la que trabajan.De los vendedores se anota su comisión. Cada vendedor atiende a determinados clientes y un mismo cliente puede ser atendido por varios vendedores; interesa saber desde qué fecha se le asignó cada cliente. Del cliente se guarda su código, nombre y teléfono.De los compradores se anota la información de compra y el presupuesto asignado. Un comprador negocia con varios proveedores, pero cada proveedor tiene asignado un único comprador como contacto. Del proveedor se guarda su código, nombre, dirección y teléfono.Se pide: diseñar el modelo entidad-relación con la metodología de Chen y con la de Martin.

Paso 1: identificar entidades, supertipo y subtipos

Entidades regulares: DEPARTAMENTO · EMPLEADO · CLIENTE · PROVEEDORSupertipo: EMPLEADO → subtipos: DESARROLLADOR · VENDEDOR · COMPRADOR

La clave de este caso está en dos frases del enunciado. Son las que deciden el tipo de jerarquía, y hay que cazarlas al leer:«hay personal que no encaja en ninguno de los tres» → la jerarquía es parcial. En Chen: sin círculo.«nadie desempeña dos perfiles a la vez» → la jerarquía es exclusiva. En Chen: con arco.Resultado: jerarquía exclusiva parcial. Si el enunciado no dijera nada, tendrías que preguntarle al cliente: no se puede adivinar.

Paso 2: identificar los atributos

Del supertipo (los heredan los tres subtipos)

De cada subtipo (solo los propios)

Un vendedor tiene seis atributos: los cinco de EMPLEADO más su comisión. Pero solo se dibuja la comisión, porque los demás ya están arriba. La herencia baja, nunca sube: EMPLEADO no tiene comisión.

Del resto de entidades

Paso 3: identificar las relaciones y sus cardinalidades

Fíjate en un detalle que se pasa por alto: las relaciones salen de los subtipos, no del supertipo. atiende cuelga de VENDEDOR, porque un desarrollador no atiende clientes. Colgarla de EMPLEADO sería un error de modelado: estarías afirmando que cualquier empleado puede tener clientes asignados.

Paso 4: los atributos de la relación

Como siempre, la M:N es la que trae atributos: la fecha de asignación no es del vendedor ni del cliente, sino del vínculo entre los dos.

Paso 5 y 6: los diagramas

Caso práctico 4: entidad bancaria (entidad débil y relación reflexiva)

El enunciado

Un banco quiere modelar la información de su red de oficinas. El área de sistemas describe el negocio así:De cada sucursal se registra su código, su nombre, su dirección y la ciudad. La red está organizada de forma jerárquica: algunas sucursales son principales y de ellas dependen otras sucursales, aunque hay oficinas que no dependen de ninguna.De cada cliente se guarda su código, nombre completo, DNI y teléfono.Una cuenta se identifica por su número, y de ella interesa el saldo, la fecha de apertura y la moneda. Un cliente puede tener varias cuentas y una misma cuenta puede tener varios titulares; de cada titularidad se anota desde qué fecha se registró y de qué tipo es (titular o mancomunado).Cada cuenta está abierta en una sola sucursal, y una sucursal custodia muchas cuentas.De cada transacción se anota su número, la fecha, la cantidad y el tipo de movimiento. El número de transacción se numera desde 1 dentro de cada cuenta, así que dos cuentas distintas pueden tener ambas una transacción número 1. Una cuenta recién abierta puede no tener todavía ninguna transacción.Se pide: diseñar el modelo entidad-relación con la metodología de Chen y con la de Martin.

Paso 1: identificar las entidades

SUCURSAL · CLIENTE · CUENTA · TRANSACCION (débil)

Este caso trae dos conceptos que los anteriores no tenían. Ambos salen de frases muy concretas del enunciado, y en los dos hay que estar atento al leer:1. TRANSACCION es una entidad débil. La pista es «se numera desde 1 dentro de cada cuenta». Eso significa que num_transaccion no identifica una transacción: la transacción número 1 existe muchas veces. Para identificarla hace falta añadir el número de cuenta. Es una dependencia de identificación, y en Chen el rombo lleva una I en la parte superior.2. depende es una relación reflexiva. Una sucursal se relaciona con otras sucursales, es decir, con su propia entidad. Al participar una sola entidad, el grado de la relación es 1. Y como las dos ramas salen del mismo sitio, hay que etiquetarlas con su rol (principal y dependiente) o el diagrama es ilegible.

Paso 2: identificar los atributos

En el diagrama de Chen num_transaccion va subrayado con línea discontinua, que es la forma habitual de señalar un identificador parcial. Su clave real es num_cuenta + num_transaccion.

Paso 3: identificar las relaciones y sus cardinalidades

Dos ceros que salen directamente del enunciado y conviene justificar:dependiente (0,1) → «hay oficinas que no dependen de ninguna».CUENTA (0,n) en registra → «una cuenta recién abierta puede no tener todavía ninguna transacción».

Paso 4: los atributos de la relación

El tipo de titularidad no es del cliente (puede ser titular de una cuenta y mancomunado de otra) ni de la cuenta (cada uno de sus titulares tiene un rol distinto). Es del vínculo.

Paso 5 y 6: los diagramas