Modelado Relacional y Normalización

Al finalizar esta guía sabrás modelar jerarquías de generalización/especialización y convertirlas a tablas, identificar dependencias funcionales, reconocer anomalías de redundancia, y aplicar 1FN, 2FN, 3FN y BCNF sobre un esquema real.

Encontrarás actividades cortas y autocorregibles —selección múltiple, verdadero/falso, emparejamiento, clasificación y completar espacios— repartidas a lo largo de la guía, y una sección de ejercicios de razonamiento donde se te da un escenario y debes predecir el resultado correcto antes de comprobarlo. Cada actividad te da retroalimentación inmediata.

Vehículo (placa, marca, año) se especializa, de forma total y disjunta, en Auto (número de puertas) y Moto (cilindraje): todo vehículo registrado es un Auto o una Moto, y nunca ambos a la vez.

Cuando la clave es compuesta (más de una columna), un atributo tiene dependencia completa si depende de toda la clave, y dependencia parcial si depende solo de una parte de ella. Por ejemplo, en DETALLE_PEDIDO(pedido_id, producto_id, producto_nombre, cantidad), cantidad depende de la clave completa {pedido_id, producto_id}, pero producto_nombre depende solo de producto_id: es una dependencia parcial.

Si X → Y y Y → Z, entonces X → Z, pero de forma indirecta (a través de Y). Por ejemplo, si empleado_id → depto_id y depto_id → depto_nombre, entonces depto_nombre depende de empleado_id de forma transitiva, no directa.

La columna telefonos guarda varios valores en una sola celda. La solución es crear una tabla TELEFONO(cliente_id, numero) aparte, con una fila por número, relacionada por clave foránea.

producto_nombre depende solo de producto_id, no de la clave completa {pedido_id, producto_id}: es una dependencia parcial. Se corrige moviendo producto_nombre a una tabla PRODUCTO(producto_id, producto_nombre) aparte. cantidad sí depende de la clave completa, así que se queda en DETALLE_PEDIDO.

depto_nombre no depende directamente de empleado_id: depende de depto_id, que a su vez depende de empleado_id. Es una dependencia transitiva. Se corrige moviendo depto_nombre a una tabla DEPARTAMENTO(depto_id, depto_nombre) aparte, dejando depto_id como clave foránea en EMPLEADO.

Regla de negocio: cada profesor dicta un único curso (profesor → curso), pero un curso puede tener varios profesores en paralelo, y un estudiante puede inscribirse con cualquiera de ellos. Las claves candidatas son {estudiante, curso} y {estudiante, profesor}. La dependencia profesor → curso es válida, pero profesor por sí solo no es una superclave: viola BCNF. Sin embargo, sí cumple 3FN, porque curso es parte de una clave candidata (un "atributo primo"), y 3FN permite esa excepción.

Se separan tres tablas: PEDIDO(pedido_id, fecha, cliente_id, cliente_nombre), PRODUCTO(producto_id, producto_nombre, precio) y DETALLE_PEDIDO(pedido_id, producto_id, cantidad), esta última con clave foránea hacia las otras dos.

PEDIDO(pedido_id PK, fecha, cliente_id FK) · CLIENTE(cliente_id PK, cliente_nombre) · PRODUCTO(producto_id PK, producto_nombre, precio) · DETALLE_PEDIDO(pedido_id PK, FK, producto_id PK, FK, cantidad)

La tabla LIBRO(isbn, titulo, editorial_id, editorial_nombre, editorial_pais) tiene clave primaria isbn (una sola columna), y editorial_id → editorial_nombre, editorial_id → editorial_pais.

Un sistema de talleres mecánicos registra HORARIO(vehiculo_placa, dia_semana, mecanico_id), donde cada mecánico atiende un único vehículo por día, pero un mismo vehículo puede pasar por varios mecánicos en días distintos.