Algoritmo de Descomposisión

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 quetenemos 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 embargodebemos 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 dedatos.
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 CentroTulancingo
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_tiendaciudad_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
Tulancingo100000
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 contratosen 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
CentroHistó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
Cortestel-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...