Diseño de BD I: el modelo Entidad-Relación

El modelo Entidad-Relación (E/R) es el lenguaje con el que se diseña una base de datos antes de escribir la primera línea de SQL. No es un modelo de implementación: es un modelo de análisis, pensado para conversar con quien pide el sistema y dejar por escrito qué información existe, cómo se conecta y qué restricciones debe cumplir. Recién después se traduce a tablas.

Las tres piezas

La llave no es opcional

Toda entidad necesita un atributo —o un conjunto de atributos— que identifique de forma única a cada objeto del conjunto: su llave, que en el diagrama va subrayada.

Si no logras encontrarle llave a una entidad, hay dos explicaciones y ninguna es "da lo mismo": o te falta información del enunciado, o eso que estás modelando no es una entidad fuerte sino una entidad débil (lo ves en la sección 3).

El curso usa la convención de Ramakrishnan, que expresa las multiplicidades con la punta y el grosor de la línea que sale del rombo. Son cuatro casos y todos se leen igual: la línea dice cuántas veces participa cada instancia de la entidad del otro lado.

Las cuatro líneas

Atributos descriptivos

Una relación también puede tener atributos propios: información que no pertenece a ninguna de las entidades por separado, sino al hecho de que estén relacionadas. El desde de trabajaEn, o el valor-acción de un accionista en una empresa, no son del empleado ni del departamento: son del vínculo.

Y acá viene una regla que se evalúa mucho: los atributos de una relación nunca pueden formar parte de su llave. La llave de una relación se arma únicamente con las llaves de las entidades que participan.

Si necesitas que un atributo descriptivo sea parte de la llave —por ejemplo, para registrar que un empleado estuvo dos veces en el mismo departamento, en periodos distintos— la señal es clara: eso que llamaste atributo es en realidad una entidad.

Una entidad débil es una entidad que no puede identificarse sola: su llave depende de otra entidad, llamada su identifying owner (dueño identificador).

Cómo se reconoce en un enunciado

La señal es siempre la misma: el identificador de X se repite entre distintos Y.

• Las habitaciones de un hotel: la 101 existe en todos los hoteles de la cadena.
• Los ítems de una boleta: la línea 1 existe en todas las boletas.
• Las notas de un estudiante en una evaluación: un 6.2 no tiene identidad propia fuera del par evaluación–estudiante.

Las tres reglas que siempre se cumplen

1. Llave parcial: la entidad débil aporta atributos que la distinguen dentro de su dueño (el numero de la habitación). En el diagrama se subraya con línea punteada.
2. Llave completa = llave parcial + llave del owner. Esa es la llave real de la entidad débil.
3. La relación identificadora exige participación total de la entidad débil (línea gruesa) y lleva flecha hacia el owner (n a 1): toda instancia débil pertenece a exactamente un dueño.

El ejemplo del curso: la Nota

Es el mismo patrón del hotel, pero con dos owners en vez de uno.

Cómo se ve en SQL

Una jerarquía de clases (o herencia isA) modela subentidades que heredan los atributos de una superentidad. Vino y Cerveza son Bebida: heredan codigo y precio, y cada una agrega lo suyo (cepa, grados_alcohol).

Se dibuja con un triángulo que apunta hacia la superentidad. La llave siempre es la de la superentidad: las subentidades no inventan llave propia.

Las dos restricciones que se evalúan

Solapamiento

Pregunta si un mismo objeto puede pertenecer a dos subentidades a la vez.

• Hay solapamiento entre Vino y Ensamblaje: un ensamblaje es un vino, así que un mismo objeto aparece en las dos.
• No hay solapamiento entre Vino y Cerveza: ninguna bebida es las dos cosas. Se dice que son disjuntas.

Cobertura

Pregunta si toda instancia de la superentidad cae en alguna subentidad.

Si el local vende vino, cerveza, pisco y whisky, pero la jerarquía de Bebida solo declara Vino y Cerveza, la jerarquía no está cubierta: hay bebidas que no son ninguna de las dos. Para cubrirla habría que agregar las subentidades que faltan.

Relaciones n-arias

Una relación n-aria asocia más de dos entidades a la vez. El caso típico: un Empleado usa una Tecnología en un Proyecto — el hecho involucra a los tres al mismo tiempo.

Una relación ternaria no es lo mismo que tres relaciones binarias. Las binarias te dirían que el empleado está en el proyecto, que el proyecto usa la tecnología y que el empleado sabe la tecnología; pero nunca que ese empleado usó esa tecnología en ese proyecto. La información del trío se pierde.

Cuándo el vínculo pide ser una entidad

Si lo que quieres guardar del vínculo empieza a crecer —fecha, presupuesto, estado, responsable— y encima necesitas relacionarlo con otras cosas, esa relación está pidiendo ser una entidad propia.

La regla práctica: mientras sea un dato simple del vínculo, atributo descriptivo; cuando tiene vida propia, entidad.

El diagrama no se ejecuta. El paso final del diseño es traducirlo a tablas, y esa traducción es casi mecánica: tiene reglas fijas, y por eso se pregunta tanto.

La tabla de conversión

Una relación n a n