Relación universal
Un diseño inicial guarda las matrículas de estudiantes en cursos en una sola
relación:
MATRICULA(id_est, nombre_est, id_curso, nombre_curso, creditos, id_prof, nombre_prof, nota)
| id_est | nombre_est | id_curso | nombre_curso | creditos | id_prof | nombre_prof | nota |
|---|
| S1 | Ana | C1 | Bases de Datos | 3 | P1 | García | 4.5 |
| S1 | Ana | C2 | Redes | 4 | P2 | López | 3.8 |
| S2 | Beto | C1 | Bases de Datos | 3 | P1 | García | 4.0 |
| S3 | Caro | C1 | Bases de Datos | 3 | P1 | García | 3.2 |
Dependencias funcionales
id_est → nombre_est
id_curso → nombre_curso, creditos, id_prof
id_prof → nombre_prof
(id_est, id_curso) → nota
Enunciado
- Indique la clave primaria de la relación
MATRICULA.
- Explique por qué no está en 2FN (segunda forma normal) e identifique las
dependencias parciales.
- Explique por qué la descomposición 2FN todavía no está en 3FN e identifique
la dependencia transitiva.
- Proponga el esquema final en 3FN, indicando en cada relación su clave
primaria y sus claves ajenas.
Solución rápida — la idea clave sin formalismo
La idea clave
La regla de oro: cada dato debe depender de la clave, de toda la clave y de nada
más que la clave.
La clave de MATRICULA es el par {id_est, id_curso}. Vamos quitando lo que no
cumple la regla:
-
2FN — quita lo que depende de media clave. El nombre del estudiante depende
solo de id_est; el nombre y los créditos del curso, solo de id_curso. Los
sacamos a tablas propias ESTUDIANTE y CURSO. En MATRICULA queda lo único
que necesita las dos partes: la nota.
-
3FN — quita lo que depende de otro atributo que no es clave. En CURSO, el
nombre del profesor depende de id_prof, no del curso (id_curso → id_prof → nombre_prof). Sacamos PROFESOR a su propia tabla.
Resultado: cuatro tablas — ESTUDIANTE, PROFESOR, CURSO (con FK a profesor)
y MATRICULA (con FK a estudiante y a curso). Así el nombre de un curso o de un
profesor se guarda una sola vez.
Solución formal — lista para entregar en un parcial
1. Clave primaria. {id_est, id_curso} (es la única que determina nota).
2. Violación de 2FN — dependencias parciales:
id_est → nombre_est
id_curso → nombre_curso, creditos, id_prof
Descomposición a 2FN:
- ESTUDIANTE(id_est, nombre_est)
- CURSO(id_curso, nombre_curso, creditos, id_prof)
- MATRICULA(id_est, id_curso, nota)
3. Violación de 3FN — dependencia transitiva en CURSO:
id_curso → id_prof → nombre_prof
Descomposición: separar PROFESOR(id_prof, nombre_prof).
4. Esquema final en 3FN.
- ESTUDIANTE(id_est, nombre_est)
- PROFESOR(id_prof, nombre_prof)
- CURSO(id_curso, nombre_curso, creditos, id_prof → PROFESOR)
- MATRICULA(id_est, id_curso, nota); id_est → ESTUDIANTE, id_curso → CURSO
(Clave primaria en negrita, claves ajenas en cursiva.) ■
Explicación completa — paso a paso, con visualizaciones
1. Clave primaria de MATRICULA
La única dependencia que determina el atributo nota es
(id_est, id_curso) → nota. Ningún atributo por sí solo identifica una fila (un
estudiante tiene varias matrículas; un curso tiene varios estudiantes). Por lo
tanto:
Clave primaria: (id_est, id_curso).
Los atributos no primos (no forman parte de ninguna clave candidata) son:
nombre_est, nombre_curso, creditos, id_prof, nombre_prof, nota.
2. ¿Por qué no está en 2FN?
Una relación está en 2FN si está en 1FN y ningún atributo no primo depende de
una parte de la clave (no hay dependencias parciales). Aquí la clave es compuesta
y sí existen dependencias parciales:
id_est → nombre_est (depende solo de media clave)id_curso → nombre_curso, creditos, id_prof (dependen solo de la otra mitad)
Solo nota depende de la clave completa. Estas dependencias parciales provocan
redundancia (el nombre “Bases de Datos” y sus 3 créditos se repiten en cada
matrícula de C1) y anomalías de actualización.
Descomposición a 2FN
Separamos cada parte de la clave con lo que depende de ella:
- ESTUDIANTE(id_est, nombre_est)
- CURSO(id_curso, nombre_curso, creditos, id_prof)
- MATRICULA(id_est, id_curso, nota)
3. ¿Por qué la 2FN todavía no está en 3FN?
Una relación está en 3FN si está en 2FN y ningún atributo no primo depende
transitivamente de la clave (todo atributo no primo depende directamente de la
clave). En CURSO aparece una dependencia transitiva:
id_curso → id_prof → nombre_prof
nombre_prof no depende directamente de la clave id_curso, sino a través del
atributo no primo id_prof. Esto vuelve a generar redundancia: el nombre “García”
se repite en cada curso que dicte P1.
Descomposición a 3FN
Extraemos el determinante id_prof con su atributo dependiente a una relación nueva:
- CURSO(id_curso, nombre_curso, creditos, id_prof)
- PROFESOR(id_prof, nombre_prof)
4. Esquema final en 3FN
| Relación | Clave primaria | Claves ajenas |
|---|
| ESTUDIANTE(id_est, nombre_est) | id_est | — |
| PROFESOR(id_prof, nombre_prof) | id_prof | — |
| CURSO(id_curso, nombre_curso, creditos, id_prof) | id_curso | id_prof → PROFESOR |
| MATRICULA(id_est, id_curso, nota) | (id_est, id_curso) | id_est → ESTUDIANTE, id_curso → CURSO |
Ahora cada atributo no primo depende de la clave, de toda la clave y de nada más
que la clave (regla mnemotécnica de Codd). Se elimina la redundancia: el nombre y
los créditos de cada curso se guardan una sola vez, igual que el nombre de cada
profesor.
Verificación con los datos
CURSO
| id_curso | nombre_curso | creditos | id_prof |
|---|
| C1 | Bases de Datos | 3 | P1 |
| C2 | Redes | 4 | P2 |
PROFESOR
| id_prof | nombre_prof |
|---|
| P1 | García |
| P2 | López |
MATRICULA
| id_est | id_curso | nota |
|---|
| S1 | C1 | 4.5 |
| S1 | C2 | 3.8 |
| S2 | C1 | 4.0 |
| S3 | C1 | 3.2 |
“Bases de Datos”, sus créditos y el profesor “García” ya no se repiten en cada
matrícula: se referencian por id_curso e id_prof.