Diseño de base de datos Relacionales

1. Diseño de bases de datos relacionales.

2. 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.

3. 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.

4. 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:

5. 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)

6. 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.

7. 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.

8. 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

9. Propiedades de unaPropiedades 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 sucursal
Numero-préstamo cantidad-nombre-sucursal

10. 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.

11. Descomposición de producto sinDescomposició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.

12. 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)

13. Puesto que nombre-sucursal activo ciudad-sucursal, la
regla de aumento para dependencias funcionales implica
que:
Nombre-sucursal nombre-sucursal activo ciudad-sucursal
Puesto 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

14. 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.

15. 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

16. 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

17. 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.

18. 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.

19. 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

20. 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.

21. 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.

22. 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

23. 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

24. 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.

25. 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
Jones
smith
hayes
jackson
Johnson
johnson
johnson
johnson
Perryride
perryride
perryride
perryride

26. 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.

27. 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.

28. 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

29. 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.

30. Ejemplo
NOMBREE NOMBREP NOMBRED
Rojas X Ana
Rojas Y Pedro
Rojas X Pedro
Rojas Y Ana
NOMBREE ->> NOMBREP y
NOMBREE ->> NOMBRED

31. 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.

32. Cuarta formaCuarta 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).

33. 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.

34. 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.

35. • 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:

36. • 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.

37. Normalización por medio deNormalizació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.

38. 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.

39. • 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.

40. 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.

41. 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.

42. • 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).

43. 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

44. 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.

45. 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