Diseño de BD II: del E/R al modelo relacional

Cómo traducir un diagrama E/R a tablas SQL: traspaso básico, entidades débiles, jerarquías isA, agregación, teoría de llaves, restricciones de integridad y las 5 reglas de oro del buen diseño.

Creado por

SebastianZ28

Valoración0 votos

-.-

schema

Traspaso básico: entidades y relaciones a tablas

Una vez que el diagrama E/R está listo, el paso lógico siguiente es traducirlo a un esquema relacional: tablas con columnas, llaves primarias y llaves foráneas. Esta traducción es casi mecánica —depende del tipo de elemento del diagrama— y es, junto con el modelamiento mismo, lo más evaluado del curso.

Entidades y relaciones N:M

Entidades: pasan a ser tablas. Sus atributos son las columnas.

Relaciones muchos a muchos (N:M): se crea una tabla intermedia (ejemplo del curso: Fabrica, entre Producto y Compañía).

Su llave primaria (PK) es la combinación de las llaves primarias de las entidades que conecta.
Se usan llaves foráneas (FK) para referenciar a las tablas de origen.

Relaciones 1:N (a lo más 1)

Si la relación tiene un lado "a lo más 1" (la flecha), no es necesario crear una tabla intermedia: basta con agregar la llave de la entidad "1" como llave foránea en la tabla de la entidad "N" —la que tiene la flecha—. Los atributos que tenía el rombo pasan también a esta misma tabla.

Si la relación tiene flecha, se fusiona: la llave del lado "uno" baja como FOREIGN KEY a la tabla del lado "muchos". Si no tiene flecha (N:M), necesita su propia tabla intermedia.

Regla rápida

Cargando Quiz...

architecture

Casos especiales: entidades débiles

Una entidad débil necesita dos cosas para volverse tabla: los atributos que la distinguen dentro de su dueño, y una forma de anclarla a ese dueño.

La regla de traspaso

La tabla de la entidad débil debe incluir:

Su llave parcial.
La llave primaria de su dueño (identifying owner), como llave foránea (FK).

La llave primaria (PK) de esta nueva tabla es la combinación (llave_owner, llave_parcial).

La restricción vital: ON DELETE CASCADE

Se recomienda agregar ON DELETE CASCADE en la FK para que, si se borra el dueño, se borre la entidad débil automáticamente. Ejemplo del curso: si borras un Curso, se borran sus Evaluaciones — una evaluación sin curso no tiene ningún sentido.

python

CREATE TABLE curso (
    codigo  TEXT PRIMARY KEY,
    nombre  TEXT NOT NULL
);
 
CREATE TABLE evaluacion (
    curso       TEXT NOT NULL,
    numero      INT  NOT NULL,        -- llave parcial
    ponderacion NUMERIC(4,2) NOT NULL,

psychology

Casos especiales: jerarquías isA y agregación

Jerarquías de clases (isA): tres opciones

El PPT da tres formas de pasar una jerarquía a tablas, y cada una tiene su costo.

Opción	Cómo	Problema o ventaja
Tablas solo para las subclases	Una tabla por cada subclase, repitiendo los atributos heredados	Problemático si hay solapamiento (repites datos) o si no hay cobertura total (no hay dónde guardar a la superclase pura)
Tabla superclase + tablas subclase	Una tabla para la superclase y una por subclase, unidas por FK	Requiere `JOIN`s para consultar, pero soluciona los problemas de cobertura y solapamiento. Suele ser la mejor opción cuando hay mucho solapamiento
Quitar la jerarquía	Una sola tabla gigante con un atributo `tipo`	Más sencillo, pero genera muchos atributos en `NULL`

Cargando Quiz...

Agregación

Para relacionar otra entidad a una agregación, la nueva tabla debe llevar como llaves foráneas (FK) todas las llaves primarias de la relación que fue "encapsulada". La agregación ya es una tabla —la de la relación que encierra— y esa tabla es la que se referencia.

python

data_object

Teoría de llaves

Categorías de llaves

Categoría	Definición
Superllave (superkey)	Conjunto de atributos que identifica de forma única a una tupla (fila). Incluir todos los atributos de una tabla siempre es una superllave
Llave candidata	Una superllave mínima: no le puedes quitar ningún atributo sin que deje de identificar de forma única ("no se puede achicar")
Llave primaria	La llave candidata que elegimos destacar y usar en el diseño
Llave sustituta (surrogate) vs. natural	Usar atributos propios del negocio (nombre, RUT) a veces genera llaves frágiles o muy largas. Suele ser mejor crear un ID único inventado por el motor de BD

Sustituta vs. natural, en código

python

-- Llave natural: frágil si el RUT cambia de formato
-- o si dos sistemas distintos lo escriben distinto.
CREATE TABLE persona_natural (
    rut     TEXT PRIMARY KEY,
    nombre  TEXT NOT NULL
);
 
-- Llave sustituta: corta, estable, y nunca cambia

tune

Restricciones de integridad

Un diagrama define qué debe cumplirse; SQL es donde esas reglas se declaran de verdad. Cinco restricciones cubren casi todo lo que se pide en el curso.

Restricción	Sintaxis	Qué hace
De valores nulos	`NOT NULL`	Impide que el dato quede vacío
Unicidad	`UNIQUE`	Impide valores repetidos en esa columna, sin ser PK
De llave	`PRIMARY KEY`	Identifica la tupla de forma única
De referencia	`FOREIGN KEY ... REFERENCES ...`	Asegura que el dato al que apuntas exista
De dominio	`CHECK (condición)`	Restringe valores con operadores lógicos

python

CREATE TABLE producto (
    id      SERIAL PRIMARY KEY,
    nombre  TEXT NOT NULL UNIQUE,
    precio  INT NOT NULL
        CHECK (precio BETWEEN 10000 AND 1000000),
    compania_id INT NOT NULL
        REFERENCES compania(id)
);
 
CREATE TABLE arriendo (
    id            SERIAL PRIMARY KEY,
    fecha_inicio  DATE NOT NULL,

lightbulb

Principios de diseño: las 5 reglas de oro

Cuando toca tomar decisiones de diseño y no hay una única respuesta correcta, el PPT da cinco reglas de oro.

Fidelidad al problema. Las entidades y relaciones deben tener sentido con el contexto real que se está modelando.
Evitar redundancia. No crear atributos que puedan generar anomalías —por ejemplo, repetir producido_por en cada fila si ya existe una relación que lo explica.
Elegir entidades y relaciones correctamente. A veces conviene transformar un atributo simple (RUN comprador) en una entidad real (Persona) conectada por un rombo.
No complicar más de lo necesario. A la inversa de la regla 3: no crear una entidad Fecha gigante si basta con que sea un atributo dentro del rombo Compra.
Buena elección de llave primaria. Privilegiar IDs sustitutos cortos y estables por sobre llaves compuestas enormes.

Las reglas 3 y 4 tiran para lados opuestos a propósito: no hay una respuesta universal de "siempre convertir en entidad" o "siempre dejar como atributo". La pregunta correcta es ¿este dato tiene vida propia y se relaciona con otras cosas, o es solo una propiedad?

Cómo usarlas en la prueba

Cargando Quiz...