1. descomposicinDentro del diseo de bases de datos relacionales, puntualmente en la aplicacin de la primera forma normal, podemos encontrar anomalas en el diseo, tales como la redundancia de datos, por lo que se debe replantar el diseo haciendo algunas modificaciones que eliminen dichas redundancias.Partiendo de este echo, debemos modificar nuestro esquema de relacin en el que tenemos redundancias descomponindolo en sub-esquemas con menor cantidad de atributos; esta descomposicin debe ser cuidadosa, debido a que una mala descomposicin nos lleva a otra modalidad de mal diseo.

Tras descomponer el esquema principal en sub-esquemas debemos tener en cuenta que entre estos debe haber solo un atributo en comn 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 unadescomposicin de reunin sin prdidacaso contrario si no se cumple decimos que tenemos unadescomposicin de reunin con prdidalo que significa un mal diseo de base de datos.

Para ejemplificar lo anterior, partamos del siguiente esquema de una compaa de telefona:

nombre_tiendaciudad_tiendaCapitalnombre_clientenum_contratomensualidad

GalerasPachuca250000Vargastel-011000

Gran patioPachuca150000Escamillatel-13560

SatliteDF300000Muoztel-31320

Centro HistricoDF350000Preztel-22560

Tulancingo CentroTulancingo100000Jureztel-141500

GalerasPachuca250000Escamillatel-99540

SatliteDF300000Muoztel-292000

Centro HistricoDF350000Cortestel-951700

SatliteDF300000Gutirreztel-43360

Tulancingo CentroTulancingo100000Cerntel-70850

Esquema renta_equiposA partir de aqu pudisemos descomponerlo en los siguientes esquemas:nombre_tiendaciudad_tiendacapitalnombre_cliente

GalerasPachuca250000Vargas

Gran patioPachuca150000Escamilla

SatliteDF300000Muoz

Centro HistricoDF350000Prez

Tulancingo CentroTulancingo100000Jurez

GalerasPachuca250000Escamilla

SatliteDF300000Muoz

Centro HistricoDF350000Cortes

SatliteDF300000Gutirrez

Tulancingo CentroTulancingo100000Cern

Tienda-cliente

nombre_clientenum_contratomensualidad

Vargastel-011000

Escamillatel-13560

Muoztel-31320

Preztel-22560

Jureztel-141500

Escamillatel-99540

Muoztel-292000

Cortestel-951700

Gutirreztel-43360

Cerntel-70850

Cliente-renta

De esta descomposicin podemos observar que para el caso de que un cliente tenga contratos en ms de una tienda, las tuplas no permiten determinar que prstamo es de qu sucursal provocando una perdida de informacin que nos lleva a unadescomposicin de reunin con prdida.

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

nombre_tiendaciudad_tiendacapital

GalerasPachuca250000

Gran patioPachuca150000

SatliteDF300000

Centro HistricoDF350000

Tulancingo CentroTulancingo100000

Esquema-tiendanombre_tiendanombre_clientenum_contratomensualidad

GalerasVargastel-011000

Gran patioEscamillatel-13560

SatliteMuoztel-31320

Centro HistricoPreztel-22560

Tulancingo CentroJureztel-141500

GalerasEscamillatel-99540

SatliteMuoztel-292000

Centro HistricoCortestel-951700

SatliteGutirreztel-43360

Tulancingo CentroCerntel-70850

Esquema-contrato

De aqu observamos que se tiene en comn el atributonombre_tienday este atributo si cumple la dependencia funcional:

Nombre_tiendacapital, ciudad_tienda

Asi pues podemos decir que tenemosunadescomposicin de reunin sin prdida.

2. Propiedades deseables de la descomposicin.

Existen algunas ocasiones en las que es necesario descomponer relaciones en otras relaciones de menor tamao con el fin de obtener ciertas propiedades que son necesarias y que con una relacin concreta no se distinguan a la perfeccin.

2.1 descomposicin de reunin sin prdida

Dado un esquema de relacinRy seaFun conjunto de dependencias funcionales del esquema de relacinR, R1, R2se forma as una descomposicin enR,se dice que una descomposicin es una descomposicin de reunin sin prdida si al menos una dependencia deRse encuentra enF+, es decir, si las dependencias funcionales R1 o R2 forman una superclave ya sea de R1 o R2, la descomposicin de R es una descomposicin de reunin sin prdida.

Para ejemplificar la descomposicin de reunin 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 observarnombre_tienda ciudad_tienda, capital,esto nos implica que:

nombre_tienda nombre_tienda ciudad_tienda, capital

Podemos ver queEsquema-tiendaEsquema-contrato={nombre_tienda},demostrando as que la descomposicin inicial es una descomposicin sin perdida.

2.2 conservacin 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 continen 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 validacin de las actualizaciones sin necesidad de calcular los productos que reconstruyen las relaciones.

Para verificar si es necesario calcular las reuniones para comprobar una actualizacin se deben determinar las dependencias funcionales que hay que comprobar verificando cada relacin una a una.

Partiendo de queFes un conjunto de dependencias funcionales del esquemaRyR1, R2,...,Rnuna descomposicin deR, es posible comprobar el cumplimiento de la condicin por una dependencia verificando slo una relacin.

Otra forma de ver que la descomposicin conserva las dependencias es verificar si se puede comprobar cada miembro del conjunto de dependencias funcionalesFpara cada una de las relaciones de la descomposicin, pero esto no siempre es as ya que hay casos en los que alguna dependencia deFno se puede comprobar con ninguna relacin de la descomposicin y por lo tanto se tendra que aplicar una prueba general.

Para que nos quede mas claro este trmino veamos el ejemplo siguiente:

nombre_tienda ciudad_tienda, capitalutilizando elesquema-tienda=(nombre_tienda, ciudad_tienda, capital)

Como podemos ver cada miembro de deFpertenece a una descomposicin deRdemostrando as la conservacin de dependencias.

3. Cuarta Forma NormalAunque ya se tengan normalizados los esquemas de relacin 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 restriccin que se denomina dependencia multivalorada. Esta dependencia no impide la existencia de tulpas con el mismo valor, exigen que estn presentes en la relacin. Se puede utilizar para especificar restricciones del conjunto de relaciones; slo habr que preocuparse de las relaciones que satisfagan un conjunto dado de dependencias funcionales y multivaloradas. Este tipo de normalizacin es igual que el FNBC pero en lugar de dependencias funcionales se encuentran las multivaloradas. En pocas palabras la 4FN consiste en descomponer una relacin con dependencias funcionales a un esquema donde contenga dependencias multivaloradasy a abordar algunas formas de repeticin de la informacin que no pueden comprenderse en trminos de las dependencias funcionales. Ejemplo:

Esquema-BC= (nmero-prstamo, nombre-cliente,calle-cliente, ciudad-cliente)se emplea el algoritmo de descomposicin con dependencias multivaloradasEsquema-prestatario= (nombre-cliente,nmero-prstamo)Esquema-cliente= (nombre-cliente, calle-cliente,ciudad-cliente).

4 Integridad en las bases de datos.

Integridad de entidad.-Pretende que cada entidad que se guarda en la base de datos sea identificable de un modo nico, es decir, que evitemos la informacin redundante.La integridad de entidad define una fila como entidad nica para una tabla determinada. La integridad de entidad exige la integridad de las columnas de los identificadores o la clave principal de una tabla, mediante ndices y restricciones UNIQUE, o restricciones PRIMARY KEY.

Ejemplos:1.- Ninguna factura puede tener un nmero duplicado, ni puede ser nulo. En suma, todas las facturas estn identificadas de manera nica por sus nmeros.2.- En la siguiente relacin, puesto que la clave primaria est formada por edificio y nmero, no hay ningn despacho que tenga un valor nulo para edificio, ni tampoco para nmero.

5. Integridad de dominio.-La integridad de dominio viene dada por la validez de las entradas para una columna determinada. Puede exigir la integridad de dominio para restringir el tipo mediante tipos de datos, el formato mediante reglas y restricciones CHECK, o el intervalo de valores posibles mediante restricciones FOREIGN KEY, restricciones CHECK, definiciones DEFAULT, definiciones NOT NULL y reglas.Ejemplos:1.-Si en la relacin EMPLEADOS (DNI, nombre, apellido, edad_emp) hemos declarado que dominio(DNI) es el dominio predefinido de los enteros, entonces no podremos insertar, por ejemplo, ningn empleado que tenga por DNI el valor Luis, que no es un entero.

2.- Supongamos ahora que en la relacin EMPLEADOS(DNI, nombre, apellido, edad_emp) hemos declarado que dominio(edad_emp) es el dominio definido por el usuario edad. Supongamos tambin que el dominio edad se ha definido como el conjunto de los enteros que estn entre 16 y 65. En este caso, por ejemplo, no ser posible insertar un empleado con un valor de 90 para edad_emp.

6. Integridad referencial.-La integridad referencial protege las relaciones definidas entre las tablas cuando se crean o se eliminan filas. En SQL Server la integridad referencial se basa en las relaciones entre claves externas y claves principales o entre claves externas y claves exclusivas, mediante restricciones FOREIGN KEY y CHECK. La integridad referencial garantiza que los valores de clave sean coherentes en las distintas tablas. Para conseguir esa coherencia, es preciso que no haya referencias a valores inexistentes y que, si cambia el valor de una clave, todas las referencias a ella se cambien en consecuencia en toda la base de datos.

Ejemplos:1.-