IUTEPAL​

BASE DE DATOS​
ING. PAULO GONZÁLEZ

El Poder de la Cardinalidad - ¡Definiendo las Conexiones!

Anteriormente, estudiamos los pilares del Diagrama Entidad-Relación (DER): entidades,
atributos y relaciones. Aprendimos que el DER es como un mapa de nuestra información, y que las
relaciones son los lazos que unen a nuestras "cosas" importantes.

Pero no todos los lazos son iguales, algunas relaciones son "uno a uno", otras "uno a muchos", y
algunas "muchos a muchos". Aquí es donde entra en juego la cardinalidad. La cardinalidad es, sin
duda, uno de los conceptos más importantes y a veces el más confuso en el diseño de bases de datos.
Por eso quise que lo estudiaramos de forma separada.

2.5. ¿Qué es la Cardinalidad en un DER? ¡La Medida de la Conexión!

En el mundo de las bases de datos (y en la programación en general), una instancia es un

ejemplo concreto y específico de una entidad. Si una entidad es una categoría o un "tipo de cosa",
una instancia es un "ejemplar" individual y real de esa categoría.

Piensa en esto con una analogía:

●​ Si la Entidad es como el molde para galletas (por ejemplo, el molde con forma de estrella),
entonces una instancia es cada galleta individual que creas con ese molde. Todas son galletas
de estrella, pero cada una es una galleta única, con sus propias particularidades (quizás una es
un poco más grande, otra tiene un poco más de azúcar).​

●​ Aplicado a nuestras bases de datos:​

○​ Si la Entidad es ESTUDIANTE, entonces una instancia de ESTUDIANTE podría ser:

■​ (Ana Pérez, 15/03/2000, 0412-1234567)
■​ (Luis Gómez, 20/07/2001, 0414-9876543)
■​ (Sofía Martínez, 01/11/1999, 0424-1122334)
○​ Cada una de estas filas o registros que guardamos en nuestra "tabla" conceptual de
ESTUDIANTE es una instancia diferente de la entidad ESTUDIANTE.

Teniendo en cuenta lo anterior, ya en el contexto de un Diagrama Entidad-Relación, la

cardinalidad (o también conocida como multiplicidad) define cuántas instancias de una entidad se
pueden relacionar con cuántas instancias de otra entidad a través de una relación. Es la "regla de
negocio" que rige la participación de las entidades en una relación.

Piensa en la cardinalidad como el número máximo y mínimo de "participantes" que se permiten

en cada lado de la relación. Nos responde a preguntas como:
 ●​ "¿Un cliente puede tener uno o muchos pedidos?"
●​ "¿Un pedido es hecho por uno o muchos clientes?"

Entender la cardinalidad es vital porque determina cómo se traducirá el diseño conceptual a la

estructura real de tablas en nuestra base de datos relacional. Un error en la cardinalidad puede llevar a
problemas serios de diseño, como la redundancia de datos o la incapacidad de representar
correctamente la información.

2.6. Tipos Principales de Cardinalidad (y Cómo Representarlas)

Existen tres tipos básicos de cardinalidad que se representan en un DER. En general, se usa la
notación Crow's Foot (Pata de Cuervo) porque es muy intuitiva y ampliamente adoptada, aunque
también puede usarse la notación simple (1, N).

2.6.1. Relación Uno a Uno (1:1)

Concepto: En una relación Uno a Uno, una instancia de la Entidad A se relaciona con como
máximo una instancia de la Entidad B, y viceversa. Es una correspondencia exclusiva.

Ejemplos Comunes:

●​ Un PAÍS tiene una CAPITAL. (Un país tiene solo una capital, y una ciudad es capital de un solo
país).
●​ Un EMPLEADO es asignado a una TAQUILLA_DE_PAGO (en un estacionamiento) exclusivo.
●​ Una ESCUELA tiene un DIRECTOR .

Notación en DER (Pata de Cuervo): Se representa con una línea recta con una barra vertical (|) en
cada extremo, indicando "uno".

(Es decir, una barra vertical | indica exactamente uno, o un círculo y una barra o| indica cero o uno.
Para 1:1, ambas partes suelen ser | por defecto si la participación es obligatoria).

Notación Simple: 1 en ambos lados de la relación.

2.6.2. Relación Uno a Muchos (1:N o 1:M)

Concepto: En una relación Uno a Muchos, una instancia de la Entidad A se puede relacionar
con una o muchas instancias de la Entidad B. Sin embargo, una instancia de la Entidad B solo puede
relacionarse con como máximo una instancia de la Entidad A.

Esta es la cardinalidad más común en las bases de datos relacionales y es la base de las claves
foráneas.

Ejemplos Comunes:

●​ Un DEPARTAMENTO tiene muchos EMPLEADOS. (Un departamento puede tener varios

empleados, pero cada empleado pertenece a un solo departamento).
●​ Un CLIENTE realiza muchos PEDIDOS. (Un cliente puede hacer muchos pedidos, pero cada
pedido es realizado por un solo cliente).
●​ Un PROFESOR imparte muchos CURSOS. (Un profesor puede enseñar varios cursos, pero cada
curso es impartido por un único profesor principal).

Notación en DER (Pata de Cuervo):

●​ En el lado del "uno", se coloca una barra vertical (|).

●​ En el lado del "muchos", se coloca una línea con una "pata de cuervo" (tres líneas saliendo de un
punto).

Notación Simple: 1 en el lado del "uno" y N (o M) en el lado del "muchos".

2.6.3. Relación Muchos a Muchos (N:M o M:N)

Concepto: En una relación Muchos a Muchos, una instancia de la Entidad A se puede

relacionar con una o muchas instancias de la Entidad B, y viceversa. Es decir, ambos lados de la
relación pueden tener múltiples conexiones.

Esta cardinalidad es muy importante en el diseño de bases de datos porque no puede implementarse
directamente en una base de datos relacional con una clave foránea simple. Requiere la creación de
una tabla intermedia (que en el DER se representa como una Entidad Asociativa).
Ejemplos Comunes:

●​ Un ESTUDIANTE se inscribe en muchos CURSOS. Un CURSO tiene muchos ESTUDIANTES

inscritos.
●​ Un LIBRO puede tener muchos AUTORES. Un AUTOR puede escribir muchos LIBROS.
●​ Un PRODUCTO aparece en muchos PEDIDOS. Un PEDIDO contiene muchos PRODUCTOS.

Notación en DER (Pata de Cuervo): Se coloca la "pata de cuervo" en ambos extremos de la relación.

Notación Simple: N (o M) en ambos lados de la relación.

2.7. Participación Mínima y Máxima (Detallando la Cardinalidad)

Aparte de los tipos básicos (1:1, 1:N, N:M), la cardinalidad se puede especificar con más detalle,
indicando la participación mínima y máxima de una entidad en una relación. Esto se representa con
pares de números (mínimo, máximo) o con símbolos específicos en la notación de Pata de Cuervo.

●​ Participación Mínima (obligatoria/opcional):​

○​ 0 (Cero): La participación es opcional. Una instancia de la entidad no necesita estar

relacionada. Se representa con un círculo o en el extremo de la línea.
○​ 1 (Uno): La participación es obligatoria. Una instancia de la entidad debe estar
relacionada con al menos una instancia de la otra entidad. Se representa con una barra
vertical | en el extremo de la línea.
●​ Participación Máxima:​

○​ 1 (Uno): Como máximo una instancia. Se representa con una barra vertical |.
○​ N (Muchos): Una o muchas instancias. Se representa con la "pata de cuervo".
Combinando esto, las notaciones más comunes en Pata de Cuervo son:

Ejemplos con Participación Mínima y Máxima:

●​ CLIENTE REALIZA PEDIDO:​

○​ Un CLIENTE puede realizar cero o muchos pedidos. (Un cliente puede existir sin haber
hecho un pedido aún, pero puede hacer muchos).
○​ Un PEDIDO debe ser realizado por exactamente un CLIENTE. (Un pedido no puede
existir sin estar asociado a un cliente).
○​ Cardinalidad completa: Cliente (0, N) : Pedido (1, 1). La relación sería de Uno a Muchos
del lado de Cliente (el "uno" es el cliente individual) hacia Pedido (los muchos pedidos).
●​ PROFESOR DIRIGE DEPARTAMENTO:​

○​ Un PROFESOR puede dirigir cero o un DEPARTAMENTO. (No todos los profesores son
directores).
○​ Un DEPARTAMENTO debe ser dirigido por exactamente un PROFESOR. (Un
departamento siempre tiene un director).
○​ Cardinalidad completa: Profesor (0, 1) : Departamento (1, 1). La relación sería de Uno a
Uno entre el profesor (que es director) y el departamento.

2.8. La Importancia de la Cardinalidad en el Diseño de Bases de Datos

Comprender y definir correctamente la cardinalidad es fundamental porque:

1.​ Define las Restricciones del Negocio: Captura las reglas y limitaciones del mundo real en tu
modelo de datos.
2.​ Guía la Implementación: La cardinalidad directamente te dice cómo se construirán las tablas y
cómo se establecerán las claves foráneas en la base de datos relacional.
○​ 1:1: A menudo, se puede combinar en una sola tabla o usar una clave foránea en una de
las tablas.
 ○​ 1:N: Se implementa colocando la clave primaria del lado "uno" como clave foránea en la
tabla del lado "muchos".
○​ N:M: SIEMPRE requiere una nueva tabla intermedia (la Entidad Asociativa) que contiene
las claves primarias de ambas entidades originales como claves foráneas (y a menudo
como clave primaria compuesta de la nueva tabla).
3.​ Previene Errores y Redundancia: Un diseño con cardinalidad incorrecta puede llevar a datos
duplicados, pérdida de información o dificultades para realizar consultas.
4.​ Mejora la Comunicación: Un DER con cardinalidades claras es un lenguaje universal que todos
los miembros del equipo de desarrollo pueden entender.

2.9. Atributos en las Relaciones: ¡Cuando la Conexión También Tiene Información!

Hasta ahora, hemos visto que las entidades tienen atributos. Pero, ¿qué pasa si la información
que queremos almacenar no es de una entidad en particular, sino de la conexión misma entre dos o
más entidades? Aquí es donde entran los atributos de las relaciones y las poderosas entidades
asociativas.

2.9.1. Atributos en las Relaciones (Símbolo en el Rombo)

A veces, una relación entre dos entidades puede tener características propias que describen esa
asociación y que no pertenecerían lógicamente a ninguna de las entidades individuales. Para entender
esto, es imprescindible saber que:

●​ Un atributo de una relación es una propiedad que sólo tiene sentido cuando se considera la
combinación de las instancias relacionadas, no de una instancia individual de las entidades que
la componen.
●​ Representación: En un DER básico, un atributo de una relación se dibuja como un óvalo
conectado al rombo que representa la relación.

Ejemplo:

●​ La relación entre las entidades entre PROFESOR y ASIGNATURA podria llamarse IMPARTE .
●​ Un PROFESOR IMPARTE ASIGNATURA (y viceversa).
●​ Un atributo de esta relación podría ser Fecha_Asignacion (la fecha en que un profesor
particular fue asignado a una asignatura particular). Esta fecha no es una característica del
PROFESOR ni de la ASIGNATURA aisladamente, sino de su asignación conjunta.

Limitación: Si bien conceptualmente las relaciones pueden tener atributos, esta representación se
vuelve problemática cuando la relación es de Muchos a Muchos (N:M), ya que no se puede
implementar directamente en una base de datos relacional. Aquí es donde surge la necesidad de las
entidades asociativas. Pero eso lo examinaremos luego.