Embed Size (px)
Citation preview
Diseño de bases de datos relacionales.
Objetivo:Objetivo:
Generar un conjunto de esquemas de relaciones que nos permitan almacenar información sin redundancia innecesaria, pero que a la vez nos permitan recuperar información fácilmente.
Peligros en el diseño de bases se datos relacionales.
Defectos que puede tener una base de datos mal diseñada:
Repetición de información.
Incapacidad para representar cierta información.
Pérdida de información.
Esquema-sucursal=(nombre-sucursal,activo,ciudad-sucursal)
Esquema-préstamo=(nombre-sucurasal,numero-prestamo,nombre-cliente,cantidad)
Brooklyn9000000Downtown
Ciudad-sucursalactivonombre-sucursal
1000Jones17Downtown
cantidadNombre-clienteNumero-préstamoNombre-sucursal
EJEMPLOS:
Representación de la información:Representación de la información:
Considérese un diseño alternativo, en el que sustituimos esquema-sucursal y esquema-préstamo por un solo esquema:
Esquema-prestar=(nombre-sucursal ,activo, ciudad-sucursal,numero-préstamo, nombre-cliente ,cantidad)
1000Jones17Brooklyn9 000 000Downtown
cantidadNombre-cliente
Numero-préstamo
Ciudad-sucursal
activoNombre-sucursal
Añadir un nuevo préstamo a la base de datos y que el préstamo lo hace la sucursal Downtown a Turner por la cantidad de 1500 dólares, sea 31 el numero-préstamo.
(Downtown,31,Turner,1500)
(Downtown, 9 000 000, Brooklyn, 31, Turner, 1 500)
Pérdida de informaciónPérdida de información
El ejemplo anterior de un mal diseño sugiere que debemos descomponer un esquema de relaciones con muchos atributos en varios esquemas con menos atributos, pero si la descomposición se hace sin cuidado puede llegarse a otra forma de diseño defectuoso.
1 00017Downtown
cantidadNumero-préstamo
Nombre-sucursal
Esquema-cant=(cantidad, nombre-cliente)
Esquema-prest=(nombre-sucursal, numero-préstamo, cantidad)
Jones1 000
Nombre-clientecantidad
Queremos encontrar aquellas sucursales de las que Jones tiene u préstamo, ninguna de las relaciones de la base de datos contiene este dato.
Esquema-prest y esquema-cant = {cantidad}
La única forma de representar una relación entre nombre-sucursal y nombre-cliente es a través de cantidad, lo cuál no es conveniente, ya que muchos clientes pueden tener préstamos por la misma cantidad, pero no necesariamente de la misma sucursal.
COMPARANDO:
Esquema-sucursal y esquema-préstamo ={nombre-sucursal}
La única forma en que podemos representar una relación entre, nombre-cliente y activo es a través de nombre-sucursal. La diferencia de este ejemplo y el anterior es que el activo de una sucursal es el mismo sin importar a que cliente nos estamos refiriendo, mientras que la sucursal asociada con la cantidad de un préstamo determinado depende del cliente al que nos estamos refiriendo.
Descomposición de producto con pérdida.
Normalización por medio de dependencias funcionales.
Puede utilizarse un conjunto dada de dependencias funcionales al diseñar una base de datos relacional en la que no ocurran la mayoría de las propiedades no deseables. En el diseño de tales sistemas puede llegar a ser necesario descomponer una relación en varias mas pequeña. Usando dependencias funcionales, podemos definir varis formas normales que representan diseños “Buenos” de bases de datos. Existen varias formas normales que veremos en este capitulo
Propiedades de una Propiedades de una descomposición.descomposición.
En esta sección ilustraremos los conceptos ilustrando el esquema-prestar:
Esquema-prestar=(nombre-sucursal, activo, ciudad-sucursal, numero-préstamo, nombre-cliente, cantidad)
El conjunto F de dependencias funcionales que es necesario que se cumpla en este esquema es:
Nombre-sucursal activo ciudad sucursalNumero-préstamo cantidad-nombre-sucursal
Si se descompone en las tres relaciones siguientes comprobamos que es un mal diseño de base de datos:
Esquema-sucursal=(nombre-sucursal), activo, ciudad-sucursal)
Esquema-info-préstamo=(nombre-sucursal, numero préstamo, cantidad)
esquema.-préstamo-cliente=(nombre-cliente, numero-préstamo)
Decimos que esta descomposición tiene varias propiedades deseables como veremos a continuación.
Descomposición de producto sin Descomposición de producto sin perdidaperdida
Al descomponer una relación en varias relaciones mas pequeñas que la descomposición sea sin perdida. La descomposición anterior es, de echo sin perdida. Para demostrar esto, debemos presentar un criterio para determinar si una descomposición tiene perdida.
Sea R jun esquema de relaciones y F un conjunto de dependencias funcionales en R. R1y R2 forman una descomposición R. esta es una descomposición de producto sin perdida de R si por lo menos una de las dependencias funcionales siguientes esta en F+:
• R1 R2 R1.• R1 R2 R2.
Ahora demostraremos que la descomposición de Esquema-prestar es una descomposición sin perdida mostrando una secuencia de pasos que generan la descomposición. Empezamos descomponiendo Esquema-prestar en dos esquemas:
Esquema-sucursal=(nombre-sucursal, activo, ciudad-sucursal)Esquema.-préstamo=(nombre-sucursal, numero-préstamo,
nombre-cliente, cantidad)
Puesto que nombre-sucursal activo ciudad-sucursal, la regla de aumento para dependencias funcionales implica que:
Nombre-sucursal nombre-sucursal activo ciudad-sucursalPuesto que esquema-sucursal Esquema-préstamo={nombre-
sucursal}, se sigue que la descomposición inicial es una descomposición de producto sin perdida.
A continuación descomponemos Esquema-préstamo en:
Esquema-info-préstamo= (nombre-sucursal, numero-préstamo, cantidad)
Esquema-préstamo-cliente=(nombre-cliente, numero-préstamo)Esto da como resultado una descomposición de un
producto sin perdida, ya que numero-préstamo es un atributo común y numero-préstamo cantidad nombre-préstamo
Conservación de las dependenciasConservación de las dependencias
Un objetivo mas al diseñar bases de datos relacionales: la conservación de dependencias.
Cuando la base de datos es actualizada, el sistema debe poder comprobar que la actualización no creara una relación ilegal, es decir que no satisfaga todas las dependencias funcionales dadas. Para comprobar las actualizaciones eficientemente es conveniente diseñar esquemas de bases de datos relacionales que permitan validar una actualización sin calcular los productos.
Para decidir si se deben calcular los productos necesitamos determinar que dependencias funcionales se deben probar mediante la comprobación de cada relación individualmente, sea f un conjunto de dependencias funcionales en el esquema R y sea R1,R2,…..,Rn una descomposición de R. La restricción de F a Ri es el conjunto F, de todas las dependencias funcionales en F+ que incluyen únicamente atributos de Ri. Puesto que todas las dependencias funcionales en una restricción implican atributos de solo un esquema de relaciones es posible probar que se satisface una dependencia de este tipo comprobando solo una relación.
ConservaciónConservación de las dependenciasde las dependencias
El conjunto de restricciones F1,F2,…..,Fn es el conjunto de dependencias que pueden comprobarse de manera eficiente. Ahora debemos preguntar si es suficiente probar solo las restricciones. sea F= F1 F2 … Fn. F1 es un conjunto de dependencias funcionales en el esquema R, pero en el original F1=F. sin embargo, aun cuando F1=F, puede ser que F1+=F+. Si esto es cierto, entonces F1 implica logicamente a todas las dependencias de F1 y si verificamos que se satisface F1, hemos verificado que se satisface F. Decimos que una descomposicion que tiene la propiedad F1+=F+ es una descomposicion que conserva las dependencias.
Conservación de las dependenciasConservación de las dependencias
REPETICION DE INFORMACION
la descomposicion de esquema-prestar no padece del problema de la repeticion de informacion. En esquema-prestar fue necesario repetir la ciudad y el activo de la sucursal para cada prestamo.
La descomposicion separa los datos de sucursal y de prestamo en relaciones distintas, eliminando esta redundancia.
La falta de redundancia que presenta la descomposicion es deseable. Las distintas formas normales representan los grados de eliminacion de redundancia que pueden lograrse.
FORMA NORMAL BOYCE-CODD
una de las formas normales mas deseables que podemos obtener es la forma boyce-codd (BCNF). Un esquema de relaciones R esta en BCNF con respecto a un conjunto de F de dependencias funcionales si para todas las dependencias funcionales en F+ de la forma x B Un diseño de base de datos esta en BCNF si cada uno de los miembros del conjunto de los esquemas de relacion que comprende el diseño esta en BCNF.
Para ilustarlo consideramos los esquemas de relacion siguientes y sus respectivas dependencias funcionales:
esquema-sucursal=(nombre-sucursal,activo,ciudad-sucursal)nombre-sucursal activo ciudad-sucursal
esquema-cliente=(nombre-cliente,calle,ciudad-cliente)nombre-cliente calle ciudad-cliente
TERCERA FORMA NORMAL
En aquellos casos en los que no pueden satisfacerse los tres criterios de diseño abandonamos BCNF y aceptamos una forma normal mas debil llamada Tercera forma normal (3nf).
Observaremos que siempre existe una posibilidad de encontrar una descomposicion.
BCNF requiere que todas las dependencias no triviales sean de la forma x B , donde x es una superclave. 3NF hace un poco menos estricta esta restriccion permitiendo las dependencias funcionales no triviales cuyo lado izquierdo no sea superclave.
La definicion de 3NF permite ciertas dependencias funcionales que no se permiten en BCNF. Una dependencia x B que satisface solo la tercera condicion de la definicion de 3NF no se permite en BCNF, aunque si se permite en 3NF. Estas dependencias se llaman dependencias transitivas.
Se observa que si un esquema de relaciones esta en BCNF, entonces todas las dependencias funcionales son de la forma <<la superclave determina un conjunto de atributos>>, o la dependencia es trivial. Asi un esquema BCNF no puede tener ninguna dependencia transitiva. Como resultado todo esquema, todo esquema BCNF esta tambien en 3NF, y por tanto BCNF es mas restrictiva que 3N.
En el ejemplo esquema-banquero en el esquema de relaciones no tiene una descomposicion en BCNF de producto sin perdida que conserve las dependencias, sin embargo, este esquema si esta en 3NF, observe que nombre-cliente, nombre-sucursal es una clave candidata de planificacion-banquera, asi el unico atributo que no esta contenido en una clave candidata de esquema-banquero es nombre-banquero. La unica dependencia funcional no trivial de la forma nombre-banquero es
nombre-cliente nombre-sucursal mombre-banquero
Puesto que nombre-cliente y nombre-sucursal es una clave candidata esta dependencia no viola la definicion d 3NF.
Aqui la principal diferencia es que incluimos el numero de oficina del banquero como parte de la informacion. Las dependencias funcionales para este esquema de relaciones son:
nombre sucursal nombre-sucursal numero-oficina nombre-cliente nombre-sucursal nombre-banquero
COMPARACION DE BCNF Y 3NF
3NF tiene la ventaja de que sabemos que siempre es posible obtener un diseño 3NF sin sacrificar un producto sin perdida o la conservacion de las dependencias. Su desventaja de 3NF si no eliminamos todas las dependencias transitivas, puede ser necesario utilizar valores vacios para representar algunas de las posibles relaciones significativas entre los datos, y esta el problema de la repeticion de la informacion.
En el esquema-banquero y sus dependencias funcionales asociadas. Puesto que nombre-banquero nombre-sucursal. Puede que queramos representar las relaciones entre los valores de nombre-banquero y los valores de nombre-sucursal en la base de datos. Sin embargo para hacer eso, bien debe haber un valor correspondiente para nombre-cliente o bien debemos utilizar un valor nulo para el atributo nombre-cliente.
La otra dificultad en el esquema-banquero es la repeticion de la informacion
nombre-cliente nombre-banquero nombre-sucursal
Jonessmithhayesjackson
Johnsonjohnsonjohnsonjohnson
Perryrideperryrideperryrideperryride
Si nos dieran a elegir entre BCNF y la conservacion de las dependencias con 3NF, generalmente es preferible optar por 3NF. Si no podemos probar la conservacion de las dependencias eficientemente, pagamos un alto precio en el rendimiento del sistema o un riesgo en la integridad de los datos de la base de datos, ninguna de estas alternativas resulta atractiva.
Con tales alternativas, la cantidad limitada de redundancia impuesta por las dependencias transitivas permitida en 3NF es la menos mala. Asi pues, normalmente elegimos asegurar la conservacion de las dependencias y sacrificar BCNF.
Dependencia MultivaluadaDependencia Multivaluada
Las dependencias multivaluadas son una generalización de las dependencias funcionales. En éstas un conjunto de valores del implicado, son determinados por un implicante. Esta situación aparece cuando existen grupos repetitivos.
La dependencia multivaluada se denota X->->Y, y se lee X multidetermina a Y, y significa que X implica un conjunto de valores de Y con independencia de los demás atributos de la relación.
Las dependencias multivaluadas dependen del contexto, es decir influye el resto de los atributos de la relación.
Definición
Un dependencia multivaluada (DMV) X ->>Y especificada sobre el esquema de relación R, donde X e Y son subconjuntos de R,
especifica la siguiente restricción sobre cualquier estado de relación r de R: Si existen dos tuplas t1 y t2 en r tales que t1[X] = t2[X], entonces deberán existir también dos tuplas t3 y t4 en r con las siguientes propiedades, en las que emplearemos Z para denotar (R - (X ∪ Y)):
t3[X]=t4[X]=t1[X]=t2[X]
t3[Y]=t1[Y] y t4[Y] = t2[Y]
t3[Z] = t2[Z] y t4[Z] = t1[Z]
Debido a la simetría de la relación si X ->>Y , entonces X ->>Z
Ejemplo
NOMBREE NOMBREP NOMBRED
Rojas X Ana
Rojas Y Pedro
Rojas X Pedro
Rojas Y Ana
El empleado Rojas trabaja en dos proyectos y tiene dos dependientes.
Ejemplo
NOMBREE NOMBREP NOMBRED
Rojas X Ana
Rojas Y Pedro
Rojas X Pedro
Rojas Y Ana
NOMBREE ->> NOMBREP y
NOMBREE ->> NOMBRED
Dependencias Multivaluadas
La definición formal especifica que, dado un cierto valor de X, el conjunto de valores de Y determinado por este valor de X está complementamente
determinado sólo por X, y no depende de los valores de los atributos restantes Z de R. Así pues, siempre que existan dos tuplas con distintos
valores de Y pero el mismo valor de X, estos valores de Y deberán repetirse en cada valor distinto de Z que ocurra con este mismo valor de X.
De manera informal, esto equivale a que Y sea un atributo multivaluado de las entidades representadas por las tuplas de R.
Cuarta forma Cuarta forma Normal.Normal.
Vimos anteriormente que, aunque esquema-BC esta en BCNF, no se un diseño ideal puesto que debemos repetir la información de la dirección de un cliente para cada préstamo. Veremos que podemos usar la dependencia multivaluada dada para mejorar el diseño de base de datos, descomponiendo esquema-BC en una descomposición de cuarta forma normal (4NF).
Un diseño de base de datos esta en 4NF si cada miembro del conjunto de esquema de relaciones que comprende el diseño esta en 4NF.
Obsérvese que la definición de 4NF es distinta de la definición de BCNF sólo en el uso de dependencias multivaluadas en vez de dependencias funcionales.
Todo esquema 4NF esta en BCNF.
Si aplicamos el algoritmo a esquema-BC, encontramos que
nombre-cliente>>numero-préstamo es una dependencia multivaluada no trivial y que nombre-cliente no es una superclave de esquema-BC.
Siguiendo el algoritmo, sustituimos esquema-BC por los dos esquemas:
Esquema-préstamo-cliente =(nombre-cliente, numero-préstamo)
Esquema-cliente =(nombre-cliente, calle, ciudad-cliente)
Este par de esquemas que están en 4NF elimina el problema de la redundancia de esquema-BC.
Al igual que en el caso en que se trataban únicamente dependencias funcionales, también estamos interesados en las descomposiciones de producto sin perdida y que conservan las dependencias.
• La cuestión de conservación de las dependencias cuando tenemos dependencias multivaluadas no es tan sencilla como en el caso en el que tenemos solamente dependencias funcionales. Sea R un esquema de relaciones y sea R1,R2,…Rn una descomposición de R.
Reacuérdese que para un conjunto F de dependencias funcionales, la restricción Fi de F a Ri en todas las dependencias funcionales en F+ que incluyen únicamente atributos de Ri.
Ahora considérese un conjunto D de dependencias funcionales y multivaluadas.
La restricción de D a Ri es el conjunto Di, que consta de:
Todas las dependencias funcionales en D+ que incluyen únicamente atributos de Ri,
Todas las dependencias multivaluadas de la forma:
• Hemos visto que si nos dan un conjunto de dependencias funcionales y multivaluadas, resulta provechoso encontrar un diseño de base de datos que se ajuste a los tres criterios siguientes:
4NF.
Conservación de las dependencias.
Producto sin pérdida.
Si todo lo que tenemos son dependencias funcionales, el primer criterio es justo el de BCNF.
También hemos visto que nos siempre es posible lograr estos tres criterios. Tuvimos éxito encontrando una descomposición así para el ejemplo bancario, pero fallamos con el ejemplo R = (A, B, C, G, H, I).
Cuando no se puedan lograr los tres objetivos, abandonamos 4NF, si es necesario para asegurar la conservación de las dependencias.
Normalización por medio de Normalización por medio de Dependencias de Intersección.Dependencias de Intersección.
• Hemos visto que la propiedad de producto sin perdida es una de las diversas características de un buen diseño de base de datos.
De echo, esta propiedad es esencial, ya que sin ella se pierde la información.
Debido a la importancia del concepto de producto sin pérdida, es útil poder limitar el conjunto de relaciones legales sobre u esquema R a aquellas relaciones para las que una descomposición dada es una descomposición de producto sin pérdida.
Dependencias de Intersección.Dependencias de Intersección.• Toda dependencia de producto de la forma
*(R1,R2) es, por tanto, equivalente a una dependencia multivaluada. Sin embargo, hay dependencias de producto que no son equivalentes a una dependencia multivaluada.
El ejemplo mas sencillo de una dependencia de este tipo está en el esquema R = (A, B, C).
La dependencia de producto *((A, B), (B, C), (A, C)) no es equivalente a ninguna colección de dependencias multivaluadas.
Así como una dependencia multivaluada es una forma de expresar la independencia de un par de relaciones, una dependencia de producto es una forma de expresar que todas las relaciones de u conjunto son independientes.
• Esta noción de independencia de relaciones s una consecuencia natural de la forma en la que generalmente definimos una relación. Considérese.
Esquema-préstamo = (nombre-sucursal, numero-préstamo, nombre-cliente, cantidad)
Del ejemplo bancario. Podemos definir una relación préstamo (esquema-préstamo) como el conjunto de todas las tuplas de esquema-préstamo tales como:
El préstamo representado por número-préstamo lo haga la sucursal llamada nombre-sucursal.
El préstamo representado por número-préstamo lo haga el cliente llamado nombre-cliente.
El préstamo representado por número-préstamo sea por la cantidad dada por cantidad.
Forma normal de Proyecto-Forma normal de Proyecto-Producto.Producto.
• La forma normal de proyecto-producto se define de manera similar a BCNF y 4NF, excepto que se usan dependencias de intersección.
Un diseño de base de datos está en PJNF si cada miembro del conjunto de esquema de relaciones que comprende el diseño está en PJNF. PJNF se llama quinta forma normal (5NF) en algunos textos sobre normalización de base de datos.
Puesto que cada dependencia multivaluada es también una dependencia de intersección, es fácil ver que cada esquema PJNF está también en 4NF.
Así, en general, no es posible encontrar una descomposición que conserve las dependencias para un esquema dado en PJNF.
COMENTARIOS.COMENTARIOS.
• La 5FN no difiere de la 4FN a menos de que exista una restricción de simetría, tal como la restricción del caso anterior. Si no existe una
restricción de este tipo, entonces una relación en cuarta forma normal también está en quinta
forma normal.
• Una ventaja de la quinta forma normal es la de que ciertas redundancias pueden ser
eliminadas.Debe observarse que aunque la forma normalizada involucra más relaciones, hay un
número menor de ocurrencias (esto no se aprecia con claridad cuando hablamos de pocos hechos).
Enfoques alternativos de diseño de bases de datos.
Tuplas colgantes: a la tupla con un valor de llave exterior que no aparezca en la relación referenciada se le llama tupla colgante (al igual que a las tuplas que no participan en una reunión); Las tuplas colgantes violan la integridad referencial de esta restricción de llaves exteriores
Relacion referenciante
Cve ext
cuentas
Nom-sucursal
Calle 12
fingoi
vite
Nom-sucursal
fingoi
vite
sucursales
Relacion referenciada
Cve principal
Las tuplas colgantes pueden presentarse en aplicaciones prácticas de bases de datos,representan información incompleta, por ejemplo si queremos almacenar datos sobre un préstamo que todavía se esta negociando, a esta relación se le conoce como “relación universal”.
Valores nulos.
La única forma enque podemos escribir una relación universal parael ejemplo anterior del préstamo, s incluir valores nulos en la relación universal
nom-suc num-prest
Round hill 58
num-prest cantidad
num-prest nom-cliente
Johnson58
No es posible introducir toda la información incompleta, sin recurrir al uso de valores nulos.
No podemos introducir un número de préstamo sin conocer:
●Nom-cliente.●nom-suc.●cantidad del prestamo.
Por ejemplo no quisieramos almacenar la siguiente información:
Existe un préstamo (cuyo número se desconoce) hecho a Jones por la cantidad de 100 dolares. Ya que la única forma en la que podemos relacionar nombre-cliente y cantidad es a través de número-préstamo, si no sabemos el número de préstamo, no podemos distinguir este préstamo de los otros con números desconocidos.
Otra consecuencia del enfoque del diseño de bases de datos es que los noimbres de los atributos deben ser únicos en la relación universal, no podemos usar “nombre” para referirnos tanto a nombre-cliente como a nombre-sucursal
