1. No category

El problemas de los vuelos de C.J. Date
Fernando Cano Espinosa
Mayo de 2005
1.
Planteamiento
Partimos del esquema R(T, L), con
T = { VUELO, HORA, DEST, DIA, PILOTO, PUERTA }
L = { VUELO → DEST HORA,
DIA VUELO → PUERTA PILOTO,
DIA HORA PUERTA → DEST VUELO PILOTO,
DIA HORA PILOT → DEST VUELO PUERTA}
Vamos a utilizar el siguiente conjunto de dependencias que es un recubrimiento no redundante:
L = {VUELO → DEST HORA,
DIA VUELO → PUERTA PILOTO,
DIA HORA PUERTA → VUELO,
DIA HORA PILOT → VUELO }
Podemos ver que las claves candidatas son las siguientes:
(DIA VUELO)+ = DIA, VUELO, PUERTA, PILOTO, DEST, HORA
(DIA HORA PUERTA)+ = DIA, VUELO, PUERTA, PILOTO, DEST, HORA
(DIA HORA PILOTO)+ =DIA, VUELO, PUERTA, PILOTO, DEST, HORA
Con lo que obtenmos como atributos principales { DIA, VUELO, PUERTA,
PILOTO, HORA } y como atributos NO principales { DEST }
La siguiente tabla cumple con las dependencias impuestas anteriormente:
Vuelo
IB77
IB88
SP00
IB77
IB7
Hora
10:00
10:00
10:00
10:00
11:11
Destino
Oviedo
Oviedo
Oviedo
Oviedo
Oviedo
Día
Lunes
Lunes
Lunes
Martes
Miércoles
1
Piloto
Jesús
Paco
Pérez
Arturo
Pérez
Puerta
2
1
3
3
3
Al realizar el estudio de normalización vemos que el esquema está en 1FN
ya que todos los atributos son simples, pero no alcanza la 2FN puesto que
DEST depende de una parte de la clave (VUELO) y no de la clave completa
1a Descomposición
Utilizo la DF VUELO → DEST HORA. Se podría haber utilizado la dependencia funcional VUELO → DEST, creando una tabla con los dos atributos,
pero después nos veríamos en la necesidad de generar otra tabla con VUELO
y HORA, ambas con VUELO como clave primaria, por lo que optamos por
reunir los tres atributos en la misma tabla. Este aspecto es considerado en la
definición del algoritmo de descomposición en FNBC.
R1 (T1 , L1 ) :
T1 = {VUELO, DEST, HORA }
L1 = {VUELO → DEST HORA }
Clave (VUELO)
R2 (T2 , L2 ) :
T2 = {VUELO, DIA, PILOTO, PUERTA }
L2 = {DIA VUELO → PUERTA PILOT }
Clave (DIA VUELO)
La descomposición cumple la propiedad LJ, se generan dos esquemas en
FNBC pero se pierden las DF siguientes
DIA HORA PUERTA → VUELO PILOTO
DIA HORA PILOTO → VUELO PUERTA
Esto quiere decir que para comprobar que no hay dos vuelos ni dos pilotos
que salgan el mismo día, a la misma hora y por la misma puerta, debemos
consultar más de una tabla.
El mismo caso ocurre con la segunda dependencia, que traducida sería: asegurar que el mismo día y a la misma hora, un piloto sólo puede tener asociado
un único vuelo y una única puerta. Lógicamente al perder estas dependencias,
todas aquellas que se infieran de ellas también se perderán.
Para solucionar este tipo de problemas están los asertos (aunque también
se pueden implementar con otros mecanismos) pero hay que evaluar el coste
adicional de éstos así como los efectos colaterales que conllevan.
2
2a Descomposición
Ahora vamos a utilizar la DF VUELO → DEST, con lo que obtendremos la
descomposición:
R1 (T1 , L1 ) :
T1 = {VUELO, DEST }
L1 = {VUELO → DEST }
Clave (VUELO)
R2 (T2 , L2 ) :
T2 = {VUELO, DIA, HORA, PILOTO, PUERTA }
L2 = {VUELO → HORA,
DIA VUELO → PUERTA PILOTO,
DIA HORA PUERTA → VUELO PILOTO,
DIA HORA PILOTO → VUELO PUERTA }
Claves (DIA VUELO, DIA HORA PUERTA , DIA HORA PILOTO)
Esta descomposición cumple la propiedad LJ y mantiene las DF, pero R2
no está en FNBC, aunque si lo está en 3FN. La repetición de información viene
por la DF VUELO → HORA, ya que siempre que aparezca un determinado
vuelo se repite su hora. Por otro lado las otras restricciones se implementan
bien definiendo las claves candidatas como PRIMARY KEY o UNIQUE. Para
asegurar VUELO → HORA en esta tabla se puede implementar con un trigger
o con un check a nivel de tabla, cosa que nos evita consultar otras tablas.
Posiblemente, si el sistema debe hacer que se cumlan, inevitablemente, todas las restricciones, esta descomposición sea la más adecuada.
3