PDF de programación - Tema 5 - Normalización 2

28/04/2012

1

2

Antes de entrar a definir la forma normal de Boyce-Codd, necesitamos conocer qué se
entiende por determinante.



Empecemos extrayendo las claves candidatas presentes en este gráfico de dependencias
funcionales. Recuérdese que tenemos que buscar conjuntos de atributos de los que
dependan todos los demás atributos. Si elijo B, solo puedo llegar a G. Si Elijo (D,B) solo
puedo llegar a G y A. Pero si elijo (D,B,C) puedo llegar a A (por D) y como “ya tengo”
(A,B,C) ya puedo llegar al resto, a E y a F.

3

Determinante es todo “de lo que salen flechas”, puesto que las dependencias funcionales
las estamos representando con esas flechas.

4

Aquí, como en ocasiones precedentes, se supone que debíamos decir que “…si la tabla está
en 3FN y…”. Lo que pasa es que si en una tabla todos los determinantes son claves
candidatas ya estamos diciendo que cumple con la 2FN y la 3FN.



Lo que no es cierto es que una tabla en 3FN esté necesariamente en FNBC, y es lo que
vamos a ver.

5

Este es el caso, en su formulación más simple, que resuelve la FNBC.

6

Algo que ya se ha utilizado anteriormente, o se debería haber hecho, es el concepto de
atributo primo. Es por eso que ciertas dependencias que parecen transitivas, en realidad, no
lo son.

7

En el caso que nos ocupa ni hay dependencias funcionales incompletas ni transitivas. Para
que haya DDFF incompletas debe existir un atributo no primo que dependa de forma
parcial de alguna clave candidata. Para que haya dependencias transitivas, ha de haber un
atributo no primo que dependa de otro atributo no primo.



Y en esta relación todos los atributos son primos, nadie puede incumplir esas formas
normales.



8

Lo que ya falla es la correspondencia entre determinantes y claves candidatas. De hecho el
determinante A no es CC: la dependencia A>C no es correcta.

9

Esto se soluciona como siempre: la dependencia errónea forma una nueva tabla y se
eliminan de la tabla inicial todos los atributos no primos de esa nueva tabla.



Aquí ya tenemos algún problema derivado de qué hemos elegido, al principio, como clave
primaria y qué como alternativa. Pensemos en que hubiéramos intercambiado en la tabla
inicial primaria y alternativa. Evidentemente, si C desaparece de la tabla inicial, ya no
tiene sentido ninguna definición de clave candidata que la contenga, y simplemente se
elimina esa restricción. Si se elimina, precisamente, la clave primaria, se cambia la
alternativa a primaria y ya está.

10

T(conductor, tipoVeh, carga) CP(conductor, tipoVeh, carga)



Este ejemplo muestra una tabla que no presenta dependencias funcionales ya que todos los
atributos pertenecen a la clave primaria. Sin embargo, hay ciertas dependencias especiales,
o no vistas hasta ahora: las dependencias multivalor. Con el ejemplo se verá más claro.



Partimos de un sistema de información que tiene los siguientes requisitos:

Los conductores conducen siempre el mismo conjunto de vehículos.

Cada carga se transporta siempre en el mismo conjunto de vehículos.



De hecho, lo que estamos diciendo es que un conductor determina un conjunto de tipos
de vehículos, o que carga determina un conjunto de tipos de vehículos. Ahí radica la
diferencia con las dependencias funcionales vistas con anterioridad. También estamos
expresando que una carga se transporta en un conjunto de vehículos. Podemos
resumirlo en



CONDUCTOR >> TIPOVEH << CARGA



En la tabla anterior venimos a decir que Juan conduce furgonetas y camiones, lo mismo
que Marcos. También estamos diciendo que los perecederos se llevan en furgoneta, pero
los muebles se pueden llevar en furgoneta o en camión. Puesto que hemos establecido esas
dependencias multivalor, cada vez que insertemos, digamos, muebles, estamos obligados a
insertar tantas filas como vehículos se usan para ellos, y por cada vehículo, tantas filas
como conductores. Pero no estamos diciendo que Juan está transportando muebles, tan
solo que puede transportar muebles.



Supongamos que las filas marcadas en rojo no existieran: queremos almacenar que los
muebles también se transportan en furgoneta. Estamos obligados, aparte de que la clave
primaria nos obliga a introducir un valor, a insertar 2 filas puesto que Juan y Marcos

11

Con esta descomposición se ve mejor qué es lo que realmente queremos almacenar, y es,
simplemente, quién conduce qué, y qué se transporta en qué.



La tabla inicial: T(conductor, tipoVeh, carga) CP(conductor, tipoVeh, carga)



La descomposición por la 4FN:



T1(conductor, tipoVeh) CP(conductor, tipoVeh)

T2(tipoVeh, carga) CP(tipoVeh, carga)



Una dependencia multivalor trivial se da en cada una de las tablas ya que si bien conductor
>> tipoVeh (conductor determina un conjunto de tipoVeh), son los únicos atributos de la
tabla (ya que hemos descompuesto la original).



Sin embargo, fijémonos en que no se declara ninguna clave ajena: no se pretendía
almacenar que una persona concreta transportaba una carga determinada. La carga es
independiente del conductor. Se habla de “descomponer” la tabla original en dos, pero no
de que se tengan que relacionar con claves ajenas.



No siempre es deseable esta descomposición.

12

T(propiedad, mueble, suministrador) CP(propiedad, mueble, suministrador)



Pensemos en que unos suministradores proveen de ciertos muebles a un conjunto de
inmuebles o propiedades nuestras. Cada propiedad (supongamos, locales de oficinas,
viviendas, tiendas, etc.) tiene unas características propias que hacen que se necesite un
determinado mobiliario, y cada mobiliario tiene un conjunto de posibles suministradores.



En esta tabla se está almacenando:

Cada propiedad, el mobiliario que necesita.

Cada suministrador, el mueble que provee.

Pero es que, además, cuando un proveedor suministra algo para una propiedad concreta,
suministra lo mismo para cualquier otra propiedad.



En la tabla:

S2 suministra sillas para P4.

S2 suministra camas para P16.

P4 necesita sillas y camas.

Luego S2 debe suministrar camas a P4.



Obsérvese que S1 no suministra a P16 y que P16 solo necesita camas.



13

En la tabla:

S2 suministra sillas para P4.

S2 suministra camas para P16.

P4 necesita sillas y camas.

Luego S2 debe suministrar camas a P4.



Obsérvese que S1 no suministra a P16 y que P16 solo necesita camas.



14

“...como S2 ya suministra a P4 y suministra CAMAS, es obligado que suministre CAMAS
a P4.”



Como en el caso de la 4FN, no es que la información repartida entre estas 3 tablas,
resultado de la descomposición de esa dependencia circular, esté relacionada.
Simplemente,



1. cada propiedad tiene sus necesidades de mobiliario,

2. cada mueble es suministrado por un conjunto de proveedores, y

3. cada propiedad es atendida por un conjunto de proveedores.



Dicho de otra forma, todas estas tablas tienen todos sus atributos dentro de la clave
primaria y no hay claves ajenas. El caso es que si hacemos un JOIN de todas estas tablas
obtenemos la tabla original, pero con esta descomposición hemos eliminado redundancia
(que P4 suministra camas, lo decimos una sola vez, por ejemplo).



La tabla inicial: T(propiedad, mueble, suministrador) CP(propiedad, mueble,
suministrador)



La descomposición por 5FN:



T1(propiedad, mueble) CP(propiedad, mueble)

T2(mueble, suministrador) CP(mueble, suministrador)

T3(propiedad, suministrador) CP(propiedad, suministrador)



15

Curiosamente, no siempre es deseable tener las tablas normalizadas, en ocasiones se
introduce cierta redundancia en el sistema porque ayuda a mejorar el rendimiento del
motor de base de datos o para sistemas de información especiales como son los de los
denominados almacenes de datos (data warehouse) y la minería de datos (data mining).

16

17