Relaciones y Cardinalidades en Diagramas Entidad–Relación

Relación: el vínculo con semántica de negocio

En un diagrama Entidad–Relación (ER), una relación expresa cómo interactúan dos (o más) entidades dentro del negocio. No es solo una línea que conecta cajas: debe capturar una regla o hecho del dominio con un significado verificable. Por eso, una relación se entiende mejor si puede leerse como una frase con verbo: Cliente realiza Pedido, Empleado pertenece a Departamento.

Una relación bien definida responde a dos preguntas: (1) qué significa el vínculo y (2) cuántas ocurrencias pueden participar (cardinalidad) y si la participación es obligatoria u opcional (total/parcial).

Representación en ER

• Entidades: se conectan mediante una relación (en notación Chen puede ser un rombo; en notaciones modernas suele ser una línea con etiquetas).
• Nombre de la relación: idealmente un verbo o frase verbal en presente (realiza, pertenece, asigna, contiene).
• Cardinalidades: se anotan en los extremos (por ejemplo 1, N, 0..1, 1..N).
• Participación: indica si una entidad debe participar siempre (total) o puede no participar (parcial).

Cardinalidades: 1:1, 1:N, N:M

La cardinalidad describe cuántas instancias de una entidad pueden asociarse con instancias de la otra. Es una regla del negocio, no una preferencia técnica.

Uno a uno (1:1)

Una instancia de A se relaciona con como máximo una instancia de B, y viceversa.

Ejemplo típico (cuando aplica): Empleado tiene Credencial (si cada empleado tiene una única credencial y cada credencial pertenece a un único empleado).

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

Señal de alerta: muchos 1:1 en realidad esconden atributos que podrían estar en una sola entidad, o reglas que cambiarán (por ejemplo, si luego hay múltiples credenciales por empleado).

Uno a muchos (1:N)

Una instancia de A puede relacionarse con muchas instancias de B, pero cada instancia de B se relaciona con una sola instancia de A.

Ejemplo aplicado: Cliente realiza Pedido.

• Un cliente puede realizar muchos pedidos.
• Un pedido pertenece a un único cliente (según la regla de negocio).

Muchos a muchos (N:M)

Una instancia de A puede relacionarse con muchas instancias de B y una instancia de B con muchas de A.

Ejemplo aplicado: Empleado trabaja en Proyecto (un empleado puede estar en varios proyectos y un proyecto tiene varios empleados).

En bases de datos relacionales, una relación N:M normalmente se implementa con una entidad asociativa (tabla intermedia) para representar el vínculo.

Participación: total vs parcial (obligatoria vs opcional)

La participación indica si una entidad debe estar relacionada al menos una vez (total) o puede existir sin relación (parcial). En notaciones con rangos, suele expresarse como mínimo 0 u 1.

Ejemplo: Cliente–Pedido

Relación: Cliente realiza Pedido.

• Participación de Pedido: normalmente total (un pedido no puede existir sin cliente). Se modela como mínimo 1 del lado de Cliente para cada Pedido: Pedido -> Cliente (1).
• Participación de Cliente: suele ser parcial (puede haber clientes registrados sin pedidos). Se modela como mínimo 0 del lado de Pedido para cada Cliente: Cliente -> Pedido (0..N).

Ejemplo: Empleado–Departamento

Relación: Empleado pertenece a Departamento.

• Si la política dice “todo empleado debe estar asignado a un departamento”, la participación de Empleado es total: Empleado -> Departamento (1).
• Si puede haber departamentos aún sin empleados (por ejemplo, recién creados), la participación de Departamento es parcial: Departamento -> Empleado (0..N).

Nota práctica: participación y cardinalidad se deciden con reglas explícitas. Si el negocio no lo tiene claro, se documenta como decisión pendiente y se valida con stakeholders.

Guía práctica paso a paso para definir una relación correctamente

Paso 1: escribe la frase del negocio (verbo + sentido)

Evita nombres genéricos como “tiene”, “usa”, “relaciona”. Prefiere verbos que describan el proceso o la responsabilidad.

• Ambiguo: Cliente tiene Pedido
• Más claro: Cliente realiza Pedido o Cliente solicita Pedido
• Ambiguo: Empleado está en Departamento
• Más claro: Empleado pertenece a Departamento o Departamento asigna Empleado (según el enfoque del negocio)

Paso 2: define la cardinalidad máxima en ambos sentidos

Pregunta por el “máximo” realista y permitido por reglas:

• ¿Un cliente puede tener muchos pedidos? (sí) → Cliente a Pedido: máximo N.
• ¿Un pedido puede pertenecer a varios clientes? (normalmente no) → Pedido a Cliente: máximo 1.

Paso 3: define la participación (mínimo 0 o 1) en ambos sentidos

Ahora pregunta por el “mínimo”:

• ¿Puede existir un pedido sin cliente? (no) → mínimo 1 del lado Cliente para Pedido.
• ¿Puede existir un cliente sin pedidos? (sí) → mínimo 0 del lado Pedido para Cliente.

Paso 4: revisa si la relación necesita atributos propios

Si el vínculo tiene datos que no pertenecen a ninguna entidad por sí sola, esos datos son atributos de la relación y suelen indicar que necesitas una entidad asociativa.

Ejemplo: en Empleado trabaja en Proyecto, el vínculo puede tener fecha_inicio, rol, horas_asignadas. Esos atributos describen la asignación, no al empleado ni al proyecto en general.

Paso 5: valida ambigüedades y redundancias

Comprueba que no estás modelando dos veces el mismo hecho con nombres distintos o con caminos alternativos que se contradicen.

Identificación de relaciones ambiguas y cómo renombrarlas

Una relación es ambigua cuando su nombre no permite inferir reglas ni formular preguntas de negocio claras. Esto suele pasar con verbos comodín (tiene, pertenece, usa) o con sustantivos (“asignación”, “vínculo”) sin acción.

Patrones de ambigüedad comunes

• “Tiene” puede significar propiedad, creación, asignación, contención o historial. Ejemplo: Cliente tiene Pedido ¿lo creó? ¿lo pagó? ¿es el destinatario?
• “Pertenece” puede ser organizacional o físico. Ejemplo: Producto pertenece a Categoría ¿una o varias categorías?
• “Asociado a” no dice nada operativo. Ejemplo: Empleado asociado a Departamento ¿trabaja ahí, reporta ahí, está asignado temporalmente?

Técnica de renombrado con verbos claros

Reescribe la relación en formato: Sujeto + verbo + objeto y agrega contexto si hace falta.

• Cliente realiza Pedido (acción de compra)
• Cliente recibe Pedido (logística/entrega; podría ser otra relación distinta)
• Empleado reporta a Departamento (estructura organizacional)
• Empleado está asignado a Departamento (asignación administrativa, quizá temporal)

Si al renombrar aparecen dos significados distintos, probablemente necesitas dos relaciones diferentes (por ejemplo, “realiza” vs “recibe”).

Entidades asociativas: resolver N:M y modelar atributos de la relación

Cuando una relación es muchos a muchos (N:M) o cuando el vínculo tiene atributos propios, se introduce una entidad asociativa (también llamada entidad puente o intermedia). Conceptualmente, convierte una relación N:M en dos relaciones 1:N.

Ejemplo: Empleado–Proyecto con atributos en la relación

Relación conceptual: Empleado trabaja en Proyecto (N:M). Atributos del vínculo: fecha_inicio, fecha_fin, rol.

Solución: crear entidad asociativa Asignacion (o un nombre más específico del negocio).

• Empleado 1:N Asignacion
• Proyecto 1:N Asignacion

La entidad asociativa contiene las claves que identifican a ambas entidades y los atributos del vínculo.

Asignacion(empleado_id, proyecto_id, fecha_inicio, fecha_fin, rol)

Regla práctica: si puedes decir “la asignación tiene fecha de inicio”, entonces “Asignación” es un buen candidato a entidad asociativa.

Ejemplo: Pedido–Producto (caso clásico)

Aunque aquí no se detallan entidades previas, es un patrón útil para entender atributos de relación: un pedido contiene productos y la relación suele tener cantidad y precio_unitario (al momento de la compra). Eso se modela con una entidad asociativa tipo DetallePedido.

Validaciones prácticas: preguntas de negocio para comprobar cardinalidades y participación

Antes de dar por “correcta” una relación, valida con preguntas concretas. Estas preguntas evitan suposiciones y detectan reglas ocultas.

Checklist de cardinalidad (máximos)

• Para cada Cliente, ¿cuántos Pedidos como máximo puede realizar? ¿Existe algún límite real (por periodo, por estado, por canal)?
• Para cada Pedido, ¿puede haber más de un Cliente asociado (copropietario, empresa y contacto, comprador y pagador)? Si sí, quizá no es 1:N.
• Para cada Empleado, ¿puede pertenecer a más de un Departamento (doble dependencia, matriz)? Si sí, la relación podría ser N:M o requerir una relación adicional (por ejemplo, “pertenece” y “colabora”).

Checklist de participación (mínimos)

• ¿Puede existir un Pedido sin Cliente? (si hay pedidos anónimos, cambia la participación).
• ¿Puede existir un Cliente sin Pedidos? (prospectos, registros incompletos).
• ¿Puede existir un Empleado sin Departamento? (altas en proceso, consultores externos).
• ¿Puede existir un Departamento sin Empleados? (departamentos nuevos o inactivos).

Preguntas para detectar atributos de relación (y justificar entidad asociativa)

• Cuando A se relaciona con B, ¿guardamos datos sobre ese vínculo? (fechas, estado, prioridad, cantidad, rol).
• ¿Esos datos cambian con el tiempo por cada par A–B? (por ejemplo, rol del empleado en un proyecto).
• ¿Necesitamos historial del vínculo? (múltiples periodos de asignación entre el mismo empleado y proyecto).

Detección de relaciones redundantes (y cómo evitarlas)

Una relación es redundante cuando el mismo hecho puede derivarse de otra(s) relación(es) ya modelada(s), lo que introduce inconsistencias. La redundancia no siempre es incorrecta, pero debe justificarse por una regla distinta o por una necesidad explícita (por ejemplo, auditoría o rendimiento en implementación, que se documenta fuera del modelo conceptual).

Señales típicas de redundancia

• Dos relaciones con el mismo significado: Cliente realiza Pedido y Pedido pertenece a Cliente no son dos relaciones distintas; son dos lecturas de la misma relación. En el diagrama conceptual se representa una sola relación con su cardinalidad.
• Relación derivable por un camino: si existe Empleado pertenece a Departamento y Departamento pertenece a Empresa, entonces Empleado pertenece a Empresa puede ser derivable. Solo modela la relación directa si el negocio la necesita como hecho independiente (por ejemplo, empleados contratados por la empresa pero asignados temporalmente a departamentos de otra filial).
• Relaciones que mezclan significados: Cliente asociado a Pedido puede estar intentando cubrir “comprador”, “pagador” y “destinatario”. Eso no es redundancia, es falta de desambiguación: sepáralas en relaciones distintas con nombres claros.

Preguntas rápidas para confirmar redundancia

• ¿Puedo obtener esta relación recorriendo otras relaciones sin perder información?
• Si guardo ambas, ¿qué pasa si se contradicen? ¿cuál manda?
• ¿La relación directa representa una regla diferente (por ejemplo, responsabilidad legal vs logística)? Si sí, no es redundante: son hechos distintos.