Tarea IV: Algoritmos de descomposición & Formas normales superiores.

7.4 descomposición

Dentro del diseño de bases de datos relacionales, puntualmente en la aplicación de la primera forma normal, podemos encontrar anomalías en el diseño, tales como la redundancia de datos, por lo que se debe replantar el diseño haciendo algunas modificaciones que eliminen dichas redundancias.

Partiendo de este echo, debemos modificar nuestro esquema de relación en el que tenemos redundancias descomponiéndolo en sub-esquemas con menor cantidad de atributos; esta descomposición debe ser cuidadosa, debido a que una mala descomposición nos lleva a otra modalidad de mal diseño.

Tras descomponer el esquema principal en sub-esquemas debemos tener en cuenta que entre estos debe haber solo un atributo en común mediante el cual relacionaremos nuestros esquemas, sin embargo debemos ser cuidadosos con este atributo ya que a su vez este debe ser la única forma en que se puedan generar las relaciones entre sub-esquemas, es decir, que cumpla con la dependencia funcional.

De ser así decimos que tenemos una descomposición de reunión sin pérdida caso contrario si no se cumple decimos que tenemos una descomposición de reunión con pérdida lo que significa un mal diseño de base de datos.

Para ejemplificar lo anterior, partamos del siguiente esquema de una compañía de telefonía:

nombre_tienda	ciudad_tienda	capital	nombre_cliente	num_contrato	mensualidad
Galerías	Pachuca	250000	Vargas	tel-01	1000
Gran patio	Pachuca	150000	Escamilla	tel-13	560
Satélite	DF	300000	Muñoz	tel-31	320
Centro Histórico	DF	350000	Pérez	tel-22	560
Tulancingo Centro	Tulancingo	100000	Juárez	tel-14	1500
Galerías	Pachuca	250000	Escamilla	tel-99	540
Satélite	DF	300000	Muñoz	tel-29	2000
Centro Histórico	DF	350000	Cortes	tel-95	1700
Satélite	DF	300000	Gutiérrez	tel-43	360
Tulancingo Centro	Tulancingo	100000	Cerón	tel-70	850

Esquema renta_equipos

A partir de aquí pudiésemos descomponerlo en los siguientes esquemas:

nombre_tienda	ciudad_tienda	capital	nombre_cliente
Galerías	Pachuca	250000	Vargas
Gran patio	Pachuca	150000	Escamilla
Satélite	DF	300000	Muñoz
Centro Histórico	DF	350000	Pérez
Tulancingo Centro	Tulancingo	100000	Juárez
Galerías	Pachuca	250000	Escamilla
Satélite	DF	300000	Muñoz
Centro Histórico	DF	350000	Cortes
Satélite	DF	300000	Gutiérrez
Tulancingo Centro	Tulancingo	100000	Cerón

Tienda-cliente

nombre_cliente	num_contrato	mensualidad
Vargas	tel-01	1000
Escamilla	tel-13	560
Muñoz	tel-31	320
Pérez	tel-22	560
Juárez	tel-14	1500
Escamilla	tel-99	540
Muñoz	tel-29	2000
Cortes	tel-95	1700
Gutiérrez	tel-43	360
Cerón	tel-70	850

Cliente-renta

De esta descomposición podemos observar que para el caso de que un cliente tenga contratos en más de una tienda, las tuplas no permiten determinar que préstamo es de qué sucursal provocando una perdida de información que nos lleva a una descomposición de reunión con pérdida.

Sin embargo podemos descomponer nuestro esquema en los siguientes sub-esquemas:

nombre_tienda	ciudad_tienda	capital
Galerías	Pachuca	250000
Gran patio	Pachuca	150000
Satélite	DF	300000
Centro Histórico	DF	350000
Tulancingo Centro	Tulancingo	100000

Esquema-tienda

nombre_tienda	nombre_cliente	num_contrato	mensualidad
Galerías	Vargas	tel-01	1000
Gran patio	Escamilla	tel-13	560
Satélite	Muñoz	tel-31	320
Centro Histórico	Pérez	tel-22	560
Tulancingo Centro	Juárez	tel-14	1500
Galerías	Escamilla	tel-99	540
Satélite	Muñoz	tel-29	2000
Centro Histórico	Cortes	tel-95	1700
Satélite	Gutiérrez	tel-43	360
Tulancingo Centro	Cerón	tel-70	850

Esquema-contrato

De aquí observamos que se tiene en común el atributo nombre_tienda y este atributo si cumple la dependencia funcional:

Nombre_tienda→capital, ciudad_tienda

Asi pues podemos decir que tenemos una descomposición de reunión sin pérdida.

7.5 propiedades deseables de la descomposición

Existen algunas ocasiones en las que es necesario descomponer relaciones en otras relaciones de menor tamaño con el fin de obtener ciertas propiedades que son necesarias y que con una relación concreta no se distinguían a la perfección.

7.5.1 descomposición de reunión sin pérdida 

Dado un esquema de relación R y sea F un conjunto de dependencias funcionales del esquema de relación R, R1, R2 se forma así una descomposición en R, se dice que una descomposición es una descomposición de reunión sin pérdida si al menos una dependencia de R se encuentra en F⁺, es decir, si las dependencias funcionales R1 o R2 forman una superclave ya sea de R1 o R2, la descomposición de R es una descomposición de reunión sin pérdida.

Para ejemplificar la descomposición de reunión sin perdida veamos el ejemplo siguiente:

Esquema-tienda=( nombre_tienda, ciudad_tienda, capital)

Esquema-contrato=(nombre_tienda, nombre_cliente, num_contrato, mensualidad)

Como se puede observar nombre_tienda→ ciudad_tienda, capital, esto nos implica que:

nombre_tienda→ nombre_tienda ciudad_tienda, capital

Podemos ver que Esquema-tienda⋂Esquema-contrato={nombre_tienda}, demostrando así que la descomposición inicial es una descomposición sin perdida.

7.5.2 conservación de las dependencias

Se dan algunos casos en los que se necesita actualizar la base de datos y con ello se requiere verificar que todas las relaciones continúen realizando su tarea y que no se realizaron relaciones que no satisfacen las necesidades del sistema.Para poder comprobar de manera eficiente las actualizaciones proporcionadas se necesitan elaborar esquemas de BD que permitan la validación de las actualizaciones sin necesidad de calcular los productos que reconstruyen las relaciones.

Para verificar si es necesario calcular las reuniones para comprobar una actualización se deben determinar las dependencias funcionales que hay que comprobar verificando cada relación una a una.

Partiendo de que F es un conjunto de dependencias funcionales del esquema R y R1, R2,...,Rn una descomposición de R, es posible comprobar el cumplimiento de la condición por una dependencia verificando sólo una relación.

Otra forma de ver que la descomposición conserva las dependencias es verificar si se puede comprobar cada miembro del conjunto de dependencias funcionales F para cada una de las relaciones de la descomposición, pero esto no siempre es así ya que hay casos en los que alguna dependencia de F no se puede comprobar con ninguna relación de la descomposición y por lo tanto se tendría que aplicar una prueba general.

Para que nos quede mas claro este término veamos el ejemplo siguiente:

nombre_tienda→ ciudad_tienda, capital utilizando el esquema-tienda=(nombre_tienda, ciudad_tienda, capital)

Como podemos ver cada miembro de de F pertenece a una descomposición de R demostrando así la conservación de dependencias.

7.5.3 Repetición de la información

Se dan algunos casos en los que es necesario introducir la misma información más de una vez todo esto con el fin de satisfacer las tuplas requeridas, pero una vez realizada la descomposición de relaciones se puede observar que los datos se separan eliminando así las redundancias que se presenten.

7.8 Cuarta Forma Normal

Aunque ya se tengan normalizados los esquemas de relación en la (3FN), pueden tener el problema de la redundancia de datos y ya no es suficiente solo tener dependencias funcionales, para tratar este problema se requiere implementar una nueva forma de restricción que se denomina dependencia multivalorada. Esta dependencia no impide la existencia de tulpas con el mismo valor, exigen que estén presentes en la relación. Se puede utilizar para especificar restricciones del conjunto de relaciones; sólo habrá que preocuparse de las relaciones que satisfagan un conjunto dado de dependencias funcionales y multivaloradas. Este tipo de normalización es igual que el FNBC pero en lugar de dependencias funcionales se encuentran las multivaloradas. En pocas palabras la 4FN consiste en descomponer una relación con dependencias funcionales a un esquema donde contenga dependencias multivaloradas  y a abordar algunas formas de repetición de la información que no pueden comprenderse en términos de las dependencias funcionales. Ejemplo:

Esquema-BC = (número-préstamo, nombre-cliente,

                                                                       calle-cliente, ciudad-cliente)

se emplea el algoritmo de descomposición con dependencias multivaloradas

Esquema-prestatario = (nombre-cliente,

                                          número-préstamo)

Esquema-cliente = (nombre-cliente, calle-cliente,

           ciudad-cliente).

7.9 Otras Formas Normales

Este tipo de normalización de utiliza mas raramente ya que no hay reglas o normas para razonar las restricciones a aplicar, es generalizar las dependencias multivaloradas con lo cual llevan a una forma normal de reunión por proyección.