.
.
Ahí está el problema, debería, si el modelo fuera
adecuado solo modificar una tupla, pero en lugar de ello, debe modificar en
este caso 3 tuplas, a pesar que los Carros son asignados todo el día a un
empleado.
Veamos paso a paso el proceso de normalización para la
tabla RevisionVivienda y así solucionar la anomalía.
1FN:
La tabla
RevisionVivienda ya está en primera forma normal, posee una llave primaria,
compuesta por el ID_Vivienda + Fecha y no tiene campos repetidos, importante es
mencionar que una vivienda solo puede ser revisada una vez el mismo día, por
ello se escogió esta llave primaria.
2FN:
Veamos,
esta cita que todos los campos que no son llave primaria, deben depender
funcionalmente de toda la llave primaria, y no de una parte de ella, los campos
ID_empleado, Observacion y Id_Carro, cumplen con esta condición, pues dependen
de toda la llave primaria, no de una parte de ella.
3FN:
Esta
cita que aquellos campos que dependan transitivamente de la llave primaria por
medio de otro campo, deben ser eliminados, veamos nuevamente los últimos 3
campos, ¿dependen transitivamente de otro campo? La respuesta es que NO, esta
tabla si cumple la tercera forma normal.
Bueno y entonces qué pasa con nuestra anomalía, paso las
primeras 3 formas normales. Para ello existe una solución, y es aplicar una
tercera forma normal más fuerte, que se conoce como Boyce-Cod.
Forma
Normal de Boyce-Codd:
En forma
sencilla cita, que debemos cumplir la condición que todo determinante en la
tabla debe ser llave candidata, pues entonces veamos los determinantes que
existen, y si alguno de ellos NO puede identificar de forma única una tupla,
dicha dependencia funcional debe eliminarse de la tabla.
1. Id_Vivienda
+ Fecha -> Id_empleado, Observacion, Id_Carro (llave
primaria OK)
2. Id_Vivienda
+ Id_Empleado + Fecha -> Observacion, Id_Carro (llave
candidata OK)
3. Id_Empleado
+ Fecha -> Id_Carro ( Problema)
Observemos la tercera dependencia funcional, el Carro es
asignado a un empleado en un día especifico, dicho empleado tendrá asignado
todo el día ese carro para realizar sus visitas a las viviendas, pero esta
dependencia funcional NO es una llave candidata de la relación, y ahí está el
problema.
Para solucionarlo debemos tomar esta dependencia funcional
y convertirla en otra tabla, de la cual será la llave primaria el determinante
de la dependencia. La solución se muestra en la siguiente figura:
Noten que se quitó el campo Id_carro de la tabla
RevisionVivienda, y se creó la nueva tabla AsignacionCarro.
Espero esta explicación les haya servido de mucho
provecho, y como ven se ha explicado de manera sencilla y muy al grano,
evitándonos horas y horas de leer páginas de un libro con muchos modelos
matemáticos enredados. Esperamos en próximamente explicar la siguiente forma
normal en otra dosis de normalidad.
Saludos...