Reglas de Transformación del Modelo E/R al Relacional

El objetivo final del diseño conceptual es servir de base para la construcción del diseño lógico relacional. Para convertir un diagrama Entidad-Relación (E/R) en un conjunto de tablas relacionales normalizadas con claves primarias (PK) y claves foráneas (FK), se aplican un conjunto de reglas algorítmicas formales y sistemáticas.

1. Transformación de Entidades #

A. Entidades Fuertes (Regulares) #

Cada entidad fuerte se transforma en una tabla relacional:

• Las columnas de la tabla corresponden a los atributos simples de la entidad.
• El atributo identificador principal de la entidad se convierte en la Clave Primaria (PK) de la tabla.

1Entidad E/R: CLIENTE (id_cliente, nombre, email, telefono)
2Tabla:       CLIENTE (PK id_cliente, nombre, email, telefono)

B. Entidades Débiles #

Una entidad débil no tiene clave propia completa y depende de una entidad fuerte:

• Se transforma en una tabla propia.
• Su Clave Primaria (PK) estará compuesta por:
  1. La clave primaria de la entidad fuerte de la que depende (que actúa además como FK).
  2. Su propio discriminador local (clave parcial).

1Entidad Débil: EJEMPLAR (num_copia, estado_conservacion) dependiente de LIBRO (isbn)
2Tabla:         EJEMPLAR (PK/FK isbn, PK num_copia, estado_conservacion)

2. Transformación de Relaciones Binarias #

Regla 1: Relaciones de Conectividad $1:N$ (Uno a Muchos) #

Es el caso más frecuente en bases de datos:

• Regla de la propagación de clave: La clave primaria de la entidad del lado $1$ se propaga como Clave Foránea (FK) dentro de la tabla de la entidad del lado $N$.
• Si la relación tiene atributos propios, estos viajan también a la tabla del lado $N$.

1E/R:   DEPARTAMENTO (1, 1) ─── TIENE ─── (0, N) EMPLEADO
2Tabla: DEPARTAMENTO (PK id_depto, nombre_depto)
3Tabla: EMPLEADO     (PK id_empleado, nombre, salario, FK id_depto)

Regla 2: Relaciones de Conectividad $N:M$ (Muchos a Muchos) #

Ninguna de las dos entidades puede absorber la clave de la otra sin generar repetición de datos:

• Regla de la tabla intermedia (asociativa): Se crea obligatoriamente una nueva tabla.
• Su Clave Primaria (PK) es compuesta, formada por las claves primarias de ambas entidades (que son FK hacia sus respectivas tablas).
• Todos los atributos propios de la relación pasan a ser columnas de esta nueva tabla.

1E/R:   ESTUDIANTE (0, N) ─── MATRICULA (fecha, calif) ─── (0, N) CURSO
2Tabla: ESTUDIANTE (PK id_estudiante, nombre)
3Tabla: CURSO      (PK id_curso, titulo, creditos)
4Tabla: MATRICULA  (PK/FK id_estudiante, PK/FK id_curso, fecha, calif)

Regla 3: Relaciones de Conectividad $1:1$ (Uno a Uno) #

Depende de la obligatoriedad (participación total o parcial) de los extremos:

1. Participación obligatoria en un lado y opcional en el otro ($1:1$ con $(1,1)$ y $(0,1)$):
   • Se propaga la clave del lado opcional hacia el lado obligatorio como FK (con restricción UNIQUE y NOT NULL), evitando la presencia de valores NULL.
2. Ambos lados con participación obligatoria ($(1,1)$ en ambos):
   • Se recomienda fusionar ambas entidades en una única tabla, ya que siempre coexisten juntas.
3. Ambos lados con participación opcional ($(0,1)$ en ambos):
   • Se puede propagar la clave a cualquiera de las dos tablas (con UNIQUE), o crear una tabla intermedia con las dos claves.

1E/R:   CIUDADANO (0, 1) ─── POSEE ─── (1, 1) PASAPORTE
2Tabla: CIUDADANO (PK dni, nombre, apellidos)
3Tabla: PASAPORTE (PK num_pasaporte, fecha_emision, FK/UNIQUE dni NOT NULL)

3. Transformación de Atributos Especiales #

A. Atributos Compuestos #

No se crea una columna para el atributo padre; en su lugar, se desglosa en tantas columnas individuales como subatributos simples tenga.

1Atributo compuesto: DIRECCIÓN (calle, numero, codigo_postal, ciudad)
2Columnas en tabla:  dir_calle, dir_numero, dir_cp, dir_ciudad

B. Atributos Multivalorados #

Una celda relacional nunca puede almacenar una lista o conjunto de valores (Primera Forma Normal / 1FN):

• Se crea una tabla separada.
• La clave primaria de la tabla será compuesta: (PK/FK id_entidad, PK valor_atributo).

1Entidad: EMPLEADO (id_empleado, nombre, {telefonos})
2Tablas:  EMPLEADO (PK id_empleado, nombre)
3         TELEFONO_EMPLEADO (PK/FK id_empleado, PK telefono)

4. Transformación de Jerarquías de Herencia (Especialización / Generalización) #

Para transformar una jerarquía (ej. Superclase VEHÍCULO con subclases COCHE y MOTO), existen tres estrategias:

1┌─────────────────────────────────────────────────────────────────────────────┐
2│ 1. Opción de Tabla Única (Una sola tabla para toda la jerarquía)             │
3│    VEHICULO (PK id_vehiculo, marca, precio, tipo_vehiculo, num_puertas, cc) │
4│    - Recomendada para jerarquías con pocos atributos específicos.           │
5│    - Requiere columnas con valores NULL para atributos de otras subclases.  │
6├─────────────────────────────────────────────────────────────────────────────┤
7│ 2. Opción de Tablas por Subclase (Una tabla por superclase y por subclase) │
8│    VEHICULO (PK id_vehiculo, marca, precio)                                 │
9│    COCHE    (PK/FK id_vehiculo, num_puertas)                                │
10│    MOTO     (PK/FK id_vehiculo, cilindrada)                                 │
11│    - La más limpia y normalizada; evita valores NULL.                       │
12├─────────────────────────────────────────────────────────────────────────────┤
13│ 3. Opción de Tablas solo para Clases Hoja (Eliminar la superclase)         │
14│    COCHE (PK id_coche, marca, precio, num_puertas)                          │
15│    MOTO  (PK id_moto, marca, precio, cilindrada)                            │
16│    - Solo válida si la especialización es TOTAL y DISJUNTA (Exclusiva).     │
17└─────────────────────────────────────────────────────────────────────────────┘

5. Resumen de Reglas de Transformación #