Apuntes > Informática >Normalización de Bases de Datos
La Quinta Forma Normal (5FN)
Teoría:
R se encuentra en 5FN si y sólo si toda dependencia de reunión en R es una consecuencia de claves candidatas. def. Dependencia de Reunión (DR).Se dice que la relación R satisface la dependencia de reunión (DR), notada como *(R1,R2,...,Rn), si y sólo si, R es igual a la reunión de sus proyecciones R1,R2,...,Rn donde Ri se compone de un subconjunto de atributos de R. |
En la práctica:
Si hemos llegado a la obtención de unas relaciones en 4FN es más que probable que éstas se encuentren ya en 5FN. Es sumamente raro encontrar relaciones en 4FN que no estén en 5FN. Los casos en los que esto ocurre son muy pocos y en ellos las restricciones son muy fuertes y muy concretas. Para ejemplificar esto veamos un caso práctico como hemos ido haciendo hasta ahora.
- Suministro total de piezas a proyectos contratados: relación SPJR*(S#,P#,J#).
"Un proveedor contratado para suministrar a un proyecto cualquier tipo de pieza, se verá obligado a suministrar las piezas que se usen en dicho proyecto si las suministra ya a algún otro proyecto."
A nivel de tuplas, el significado de esta relación es el siguiente:
- La tupla (Si,Pi,Ji) significa que: "Un determinado proveedor Si suministra la pieza Pi al proyecto Ji.".
- Se cumple la siguiente restricción: Si se dan las tuplas (S1,P1,Jx) y (Sx,P1,J1) y (S1,Px,J1) entonces debe aparecer la tupla (S1,P1,J1) en SPJR*.
La restricción refleja la condición inicial, es decir, si:
- Un proveedor S1 suministra la pieza P1
- Y la pieza P1 se usa en el proyecto J1
- Y además S1 tiene un contrato de suministro con J1
Entonces S1 está obligado a suministrar la pieza P1 a J1.
Deberían darse las siguientes tuplas (para x=2)
|
¿Cuál es el problema?
El problema:
En este caso la relación se encuentra ya en 4FN, no existen DMVs. Quiero, a riesgo de ser pesado, volver a hacer notar que el cálculo de las dependencias multivaluadas va estrechamente asociado a la semántica de la relación. En este caso en la aserción: "un determinado proveedor suministra la pieza Pi al proyecto Ji", no hay restricciones que ocasionen dependencias multivaluadas, no existe ningún dato o parejas de datos que puedan determinar el valor de otro; igualmente las restricción de "suministro total de piezas" sólo influye en las tuplas que deberán aparecer y no conlleva dependencia multivaluada alguna. Así, un proyecto puede ser suministrado por cualquier proveedor, un proyecto puede utilizar cualquier pieza y, finalmente, los proveedores pueden suministrar las piezas que quieran (o que puedan).
El problema que tenemos es consecuencia de la restricción de "suministro total de piezas" impuesta.
- Si se inserta la tupla (Si,Pi,Jj) y ya se encontraban en la relación tuplas (Sj,Pi,Ji) y (Si,Pj,Ji), según la restricción deberemos insertar la tupla (Si,Pi,Ji). Lo mismo ocurre para cualquier combinación de tuplas que hagan cumplir el antecedente de la regla que define la restricción.
- Si se elimina la tupla (Si,Pi,Ji) deberemos entonces eliminar alguna de las tuplas que hacen cierta la restricción, ya que si no lo hacemos la relación quedará en un estado incoherente. Tendríamos las tres tuplas de la forma (Si,Pi,Jj) y (Sj,Pi,Ji) y (Si,Pj,Ji) y no aparecería la tupla (Si,Pi,Ji) tal y como establece la restricción con lo que la relación no representaría por tanto la información que queremos que contenga.
Estas inserciones y borrados añadidos suponen una carga para la base de datos, y hacen que la relación sea propensa a estados de incosistencia.
La solución:
Hasta ahora, cada vez que nos hemos encontrado ante una relación con propiedades no deseables hemos buscado la forma de pasarla a un par de relaciones equivalentes que conservaran la semántica de la relación y que en cierta medida solventaran los problemas presentes. Este caso no iba a ser diferente, la solución pasa por descomponer la relación en otras equivalentes y sin pérdidas de significado.
Hagámoslo entonces, las combinaciones posibles de descomposición son:
- SP(S#,P#) y PJ(P#,J#)
- PJ(P#,J#) y JS(J#,S#)
- PS(P#,S#) y SJ(S#,J#)
Tras tener las diferentes combinaciones debemos comprobar cuáles respetan el significado de la relación y cuáles no. Las que lo cumplan resultarán ser las descomposiciones adecuadas, luego nos guiaremos por criterios como la independencia o el espacio (de los que hemos hablado anteriormente) para seleccionar la que finalmente emplearemos.
Por ejemplo en el caso de las descomposición SP(S#,P#) y PJ(P#,J#) la conexión entre una tupla de una relación y la de otra vendrá determinada por el valor de la pieza (ya que este es el atributo en común), la pregunta es: ¿representa esta descomposición el significado de la relación original?. La respuesta es NO, existen pérdidas de información. Por ejemplo, en el caso en el que dos proveedores suministren la misma pieza, ¿cómo sabemos sin información adicional a qué proyecto pertenece dicho suministro?.
Las las tuplas (S1,P1,J2) y (S2,P1,J1) de la relación inicial según la descomposición SP-PJ se descompondría como las tuplas siguientes:
- (S1,P1) y (P1,J2)
- (S2,P1) y (P1,J1)
Según la distribución establecida conociendo (S1,P1) determinaríamos que S1 suministra la pieza P1 al proyecto J2 y al proyecto J1, lo cual es cierto. Sin embargo dada la tupla (S2,P1) se deduciría que los proyectos a los que S2 suministra la pieza P1 son tanto J1 como J2, algo que es totalmente falso. En el proceso de descomposición hemos perdido información, esto provoca inconsistencias e incoherencias en la información que mantiene nuestra base de datos, algo que tenemos que evitar a toda costa.
Hazlo tu mismo:
Teoría:
Teorema de Fagin de descomposición sin pérdidas con dependencias multivaluadas. R(A,B,C) satisface la DR *((A,B),(A,C)) si y sólo si |
En otras palabras, este teorema significa que la relación R(A,B,C) se podrá descomponer sin pérdidas en R1(A,B) y R2(A,C) (luego los pares (A,B) y (A,C) forman una dependencia de reunión) si y sólo si existe una dependencia multivaluada de A -->>B|C. En el ejemplo que hemos puesto esto no se verifica, no existe DMV alguna que nos permita dividir la relación en otras dos.
También podemos comprobar lo incorrecto de las descomposiciones de una forma más intuitiva. El problema que conlleva la descomposición se observa más claramente si nos detenemos a analizar los significados de las relaciones obtenidas. Como ya hemos comentado la relación principal SPJR*(S#,P#,J#) significa:
- Relación SPJR*(S#,P#,J#): "Un proveedor S# suministra la pieza P# para el proyecto J#"
- Restricción: Un proveedor Si suministra la pieza Pi
- Y la pieza Pi se usa en el proyecto Ji
- Y además Si tiene un contrato de suministro con Ji
- ENTONCES (Si,Pi,Ji) tiene que aparecer.
Analicemos ahora el significado de las relaciones obtenidas en la descomposición de SPJ en varios pares (sin entrar a valorar el cumplimiento de la restricción), de este modo:
- Descomposición 1: SP y PJ.
SP: el proveedor S# suministra piezas P#
PJ: las piezas P# se utilizan en el proyecto J#
- Descomposición 2: PJ y JS.
PJ: las piezas P# se utilizan en el proyecto J#
JS: el proyecto J# recibe piezas de S#
- Descomposición 2: PS y SJ.
PS: las piezas P# se suministran por S#
SJ: el proveedor S# suministra al proyecto J#
Como se observa en las descomposiciones ninguna llega a comprender el significado completo de la relación inicial. Todas estas descomposiciones producen pérdidas de información respecto de la relación original. Lo que tenemos que buscar es una descomposición que conserve toda la información reflejada en la expresión: "Un proveedor Si suministra la pieza Pi para el proyecto Ji", tras ver que se cumple esta máxima tendremos que verificar que se cumple la restricción.
Necesitamos por tanto la siguiente información:
- Que el proveedor Si vende la pieza Pi.
- Que dicha pieza Pi se utiliza en el proyecto Ji
- Luego el proveedor Si suministra al proyecto Ji
Se observa por tanto la necesidad de tres relaciones para conservar el significado de SPJR*, allí donde la descomposición en dos ha resultado insuficiente.Estas relaciones son: SP, PJ y JS.Si realizamos la reunión de las proyecciones sobre todos los atributos de las relaciones SP, PJ y JS obtenemos la relación SPJ en todo su significado. Pero, ¿y la restricción?. Veamos que esta también se cumple. Para ellos representaremos las 3 tuplas de la condición según la descomposición actual para luego comprobar que la tupla (S1,P1,J1) también aparece.Tomamos las tuplas:
- (S1,P1,J2) equivalente a (S1,P1) (P1,J2) (J2,S1)
- (S2,P1,J1) equivalente a (S2,P1) (P1,J1) (J1,S2)
- (S1,P2,J1) equivalente a (S1,P2) (P2,J1) (J1,S1)
- Como podemos apreciar aparecen: (S1,P1) (P1,J1) (J1,S1) que se corresponde con (S1,P1,J1)
La restricción se cumple.
UNA ACLARACIÓN: De hecho es esta restricción la que hace que la relación SPJR* pueda descomponerse en 3 relaciones. Si no se diera la restricción no podríamos descomponer la relación SPJ en otras relaciones sin perder el significado o darle otro muy diferente. ¿Qué quiere decir esto?, lo que queremos decir con esto es que: una relación se puede descomponer en otras n relaciones (para n > 2) si y sólo si se satisface alguna restricción cíclica como la que hemos visto . En este caso hemos añadidos la restricción a la relación SPJ para provocar la existencia de una Dependencia de Reunión de SPJR* para con las relaciones SP,PJ y JS.
¿Y la 5FN? Bien, supongo que la pregunta más importante a estas alturas es: "¿qué tiene que ver todo esto con la 5FN?"
Lo que tenemos en SPJR* con respecto a las relaciones SP,PJ y JS es lo que anteriormente definimos como Dependencia de Reunión (DR), y es aquí donde entra en juego la 5FN, ya que existe una DR, la formada por SP,PJ y JS, notada como *(SP,PJ,JS), que no es consecuencia de claves candidatas (la clave de la relación la constituye el grupo de los tres atributos: S#,P# y J#). Luego la relación SPJR* no está en 5FN. Los problemas consecuencia de esto son los que hemos visto anteriormente tanto para la inserción como para el borrado.Para pasar esta relación a 5FN utilizaremos la descomposición en las tres relaciones SP,PJ y JS. Todas estas relaciones están ya en 5FN y no tendremos problemas con ellas.
En la práctica:
Sin embargo, el calcular las dependencias de reunión puede ser un problema no trivial, es decir, que puede llegar a resultar muy complejo encontrarlas, lo que supondrá un coste extra en el tiempo de diseño de nuestra base de datos. Por eso en la práctica esto se hará siempre que las DR que no impliquen llaves candidatas puedan encontrarse de forma relativamente simple. De todos modos normalmente no deberemos preocuparnos demasiado, en contadas ocasiones una relación que esté en 4FN no se encontrará en 5FN (como en el caso tan enrevesado que hemos visto). De hecho, lo más frecuente será encontrarnos con bases de datos en las que será suficiente llegar hasta la 3FN para encontrarnos con que se cumplen la FNBC, la 4FN y la 5FN. Después de todo será nuestro criterio el que prevalezca, y serán la experiencia y la práctica los complementos perfectos a los métodos vistos para conseguir un resultado más que aceptable.
| Anterior | [1] | [2] | [3] | [4] | [5] | [6] | Siguiente |