Apuntes > Informática >Normalización de Bases de Datos
La Cuarta Forma Normal (4FN)
Teoría:
R está en 4FN si y sólo si está en FNBC y no existen dependencias multivaluadas. def. Dependencia Multivaluada (DMV).Sea la tupla (X,Y,Z). Decimos que Y es multidependiente de X (X -->> Y) si y sólo si el conjunto de valores de Y correspondiente a un par (X,Z) depende sólo del valor de X y es independiente del valor de Z. Las dependencias multivaluadas sólo se presentan si existen tres atributos y cuando lo hacen es a pares, es decir ocurre que Y es multidependiente de X y Z es también multidependiente de X. |
En la práctica:
La 4FN es en cierto modo bastante compleja de identificar, hay que tener muy claro sobre todo el significado de lo que representa la relación analizada. Para verlo de forma práctica procederemos a definir una nueva relación para comprobar después si está en 4FN.
- Una nueva relación en nuestra base de datos: los Proyectos de Alta Disponibilidad (PAD).
Hemos recibido del cliente que encargó la base de datos de proveedores, piezas y proyectos unos nuevos requisitos, resulta que han establecido un nuevo tipo de proyectos, los proyectos de ALTA DISPONIBILIDAD. Estos proyectos tienen los siguientes requisitos o condiciones para con los proveedores:
- c1- Un proyecto puede ser suministrado por cualquiera de los proveedores aceptados como de alta disponibilidad para dicho proyecto.
- c2- Un proveedor aceptado debe suministrar TODAS las piezas del proyecto en el que ha sido admitido.
- c3- Un proveedor aceptado puede suministrar varios proyectos.
Consecuentemente nos han proporcionado una nueva tabla de Proyectos de Alta Disponibilidad tal que:
- PAD (J#,S#,P#)
Resulta que si se nos presenta la relación tal cual poco podemos hacer, tenemos que tener en cuenta todos los requisitos estipulados para que el problema tenga sentido. Esto es algo que quiero recalcar y que vale para cualquier estado de la normalización. Tenemos que tener siempre en cuenta el significado semántico de las relaciones. Si no lo hacemos así podemos caer en el error de descomponer o diseñar una base de datos que, aunque esté perfectamente normalizada y sea muy eficiente, no se corresponda con lo solicitado.
Pero detengámonos en esta nueva relación JAD más detenidamente, para ello trabajaremos con algunos ejemplos, principalmente procuraremos hacerlo según los datos reales que nos ha facilitado el cliente. Resulta que actualmente tienen 3 proyectos de ALTA DISPONIBILIDAD en ejecución: J1, J2 Y J3.
Las piezas requeridas por estos proyectos son:
- J1 -> Piezas: P1, P7 y P2
- J2 -> Piezas: P1 y P4
- J3 -> Piezas: P3, P5 y P6.
Los proveedores a los que se les ha permitido intervenir en los proyectos con la condición de suministrar todas las piezas requeridas han sido:
- Para J1: S1 y S2
- Para J2: S1
- Para J3: S3
Una descripción “más gráfica“ de todo esto:
A) Distribución de los datos conocidos |
||||||||||||
|
B) Tuplas resultantes |
||||||||||||||||||||||||||||||||||||
|
El problema:
Si observamos las tuplas generadas no nos cabe duda de que esta relación tiene algunas pegas, principalmente la redundancia (existen 3 pares (J1,S1), 3 pares (J3,S3), 2 pares (S1,p1), etcétera), con los problemas de actualización y matenimiento que eso conlleva.
La solución:
Analicemos la relación y veamos en qué forma normal se encuentra.
Inicialmente identificamos las claves candidatas, y seleccionamos la que será la clave primaria a partir de ahora. Tenemos pocos problemas, el único atributo o, mejor dicho, conjunto de atributos que puede ser tomado como clave es (S#,J#,P#) ya que sólo él cumple las condiciones de UNICIDAD (no puede repetirse) y MINIMALIDAD (no contiene subconjuntos de atributos que verifiquen la unicidad, es decir que no se repitan).
La clase primaria es consecuentemente (S#,J#,P#). Se cumple la 1FN, la 2FN también se cumple ya que sól está la clave primaria (no hay por tanto atributos determinados por otros que no sean la clave primaria). Igualmente, la 3FN se cumple debido a que no existen dependencias transitivas. Y para terminar también comprobamos que la FNBC se verifica, no hay ni tan siquiera determinantes. De hecho desde el principio no se encuentra dependencia funcional alguna excepto la que posee la clave primaria. Y es que este es el diagrama de dependencias funcionales:
Fig.4. Diagrama de dependencias de la relación PAD. |
Nos queda ahora analizar si la relación cumple la 4FN: " está en FNBC y no existen dependencias multivaluadas ". Las dependencias multivaluadas sólo se presentan si existen en R al menos tres atributos y cuando lo hacen es a pares, es decir ocurre que Y es multidependiente de X y Z es también multidependiente de X.
En nuestro caso la tupla sospechosa es (S#,P#,J#), y es que hemos visto con algunos datos cómo se repetían los valores de dos en dos. Tenemos concretamente dos dependencias multivaluadas (como se dice más arriba cuando aparecen “lo hacen a pares“), son las siguientes:
- Proyecto --->> Proveedor
- Proyecto --->> Piezas
Y es que cuando el valor de P# se corresponde con un par (J#,S#) depende sólo del valor de J# (es el proyecto el que determina las piezas a utilizar y no el proveedor, ya que este está obligado a suministralas todas). Igualmente cuando el valor de S# se corresponde con un par (J#,P#) será el proyecto el que determina qué proveedor es, esto es así porque:
- Una condición era que el proveedor suministrara TODAS LAS PIEZAS para J#, luego la pieza no aporta información alguna sobre el proveedor ya que todos los proveedores que suministren al proyecto J# entregan todas las piezas.
- Y, lo más importante, los proveedores sólo pueden suministrar aquellos proyectos J# para los que fueron admitidos.
- Como vemos las relaciones que no están en 4FN son un tanto especiales, en su forma porque deben tener al menos tres atributos, y también, fundamentalmente, en su significado y en las restricciones semánticas impuestas entre los atributos que la forman.
Ya para terminar nos queda ver cómo transformaríamos la relación PAD(J#,S#,P#,cantidad) que no está en 4FN en una que sí lo esté.
Teoría:
Teorema (FAGIN): Una relación R de atributos A,B y C se puede descomponer sin pérdidas en sus proyecciones R1(X,Y) y R2(X,Z) si y sólo si en R se cumple la DMV: X --->> Y y X --->> Z (también notado como X --->> Y | Z) |
En nuestro caso descompondríamos la relación en:
- (J#,S#)
- (J#,P#)
Veamos ahora si los datos del ejemplo siguen conservándose:
| PROYECTO | PROVEEDOR |
|---|---|
J1 |
S1 |
J1 |
S2 |
J2 |
S1 |
J3 |
S3 |
| PROYECTO | PIEZA |
|---|---|
J1 |
P7 |
J1 |
P2 |
J1 |
P1 |
J2 |
P4 |
J2 |
P1 |
J3 |
P3 |
J3 |
P5 |
J3 |
P6 |
Ahora ambas tablas están en FNBC y no presentan DMV (4FN).
Hazlo tu mismo:
Supón el mismo caso y las mismas condiciones que las expuestas al inicio de esta sección con un a&ñtilde;adido, además queremos conocer la cantidad suministrada de piezas por el proveedor para el proyecto en cuestión, de este modo la relación quedaría como:
- PAD(J#,S#,P#,cantidad).
- ¿En qué forma normal se encuentra?.
Procura normalizar la relación hasta llegar a 4FN si fuera posible. Tanto si es posible como si no expón los resultados de tu análisis y de la descomposición resultante de forma razonada.
Recuerda que aunque lo ideal es llegar lo más lejos posible en la normalización, lo realmente importante es hacerlo mientras se respete el significado semántico de la relación.
| Anterior | [1] | [2] | [3] | [4] | [5] | [6] | Siguiente |