Desarrollo de aplicaciones informáticas – Esquema sobre el Diseño de Bases de Datos Relacionales

DISEÑO DE BASES DE DATOS

Autor: Silberschatz, Abraham; Korth, Henry F. & Susarshan, S.

ISBN: 8448146441

OBJETIVOS DEL DISEÑO DE LAS BASES DE DATOS RELACIONALES:

a) La generación de un conjunto de tablas con restricciones y relaciones entre ellas
b) Que nos permita almacenar la información de la realidad con la que estamos
tratando (Cumple con las Dependencias Funcionales)
c) Sin redundancias innecesarias (Está en FNBC)
d) Pero que también nos permita recuperar esa información. (No hay pérdida de
información)

7.1. PRIMERA FORMA NORMAL. 1FN.

Cada atributo no puede tener más de un valor del dominio subyacente.

Es una restricción inherente al modelo relacional, por lo que su cumplimiento es

obligatorio.

Una tabla está en 1FN, cuando los dominios de todos los campos son “indivisibles”.

7.2. DIFICULTADES EN EL DISEÑO DE BASES DE DATOS RELACIONALES

Partiendo de un diseño realizado con todos los campos en una única tabla, nos
podemos encontrar con que:
a) Se produce Repetición de información
a. Desaprovecha espacio
b. Complica la actualización de la base de datos

Hechos independientes deben representarse en tablas independientes

b) Es Imposible representar cierta información

a. En ciertos casos tengo que permitir valores nulos.

Vamos a ver las técnicas que nos permiten solucionar estos errores de diseño.

7.3. DEPENDENCIA FUNCIONAL

7.3.1. Conceptos Básicos

- Desempeña un papel fundamental en la diferenciación de buenos y malos diseños
de bases de datos.
- Es un tipo de restricción que existe en el mundo real que queremos representar en
el modelo. Permite expresar hechos sobre la realidad que estamos modelando y
comprobar si las tablas que los representan cumplen con ellas.
- Unos atributos dan información sobre otros atributos.
- Unos atributos hacen depender su valor de otros atributos
- El valor de un campo de una columna determinada, siempre se corresponde con un
mismo valor en otra columna.
- Hay que distinguir entre que:
- en una tabla se satisface una dependencia funcional y
1
 Desarrollo de aplicaciones informáticas – Esquema sobre el Diseño de Bases de Datos Relacionales
- que una dependencia se cumpla con los datos que tiene la tabla en ese
momento.

- Una dependencia funcional trivial es aquella que se cumple en todas las tablas.

Estos es, si α → β y β ⊆ α Ejemplo: A→A, AB→B A⊆AB

- Una dependencia funcional está implicada lógicamente cuando existe una
dependencia “transitiva”: A→B, B→H, A→H

7.4. DESCOMPOSICIÓN

Un mal diseño en una tabla con muchos atributos se puede mejorar

descomponiéndola en otras tablas con menos atributos.
Esto puede generar dos tipos de problemas:
- Incapacidad para representar determinada información (descomposición con
pérdida de información).
- Repetición de información.

7.5. PROPIEDADES DESEABLES DE LA DESCOMPOSICIÓN

7.5.1. Descomposición sin pérdida de información:

Es una condición irrenunciable.

Podemos comprobarlo:
Si quedan uno o varios campos comunes a ambas tablas y estos son superclave
de una de ella, la descomposición es sin perdida.

7.5.2. Conservación de las dependencias:

Si cada una de las dependencias funcionales que definen la realidad a modelar, se

puede comprobar en alguna de las tablas resultante de la descomposición, se
conservan las dependencias.

7.5.3. NO repetición de información:

Que en la descomposición no se produzca redundancia de información es algo

deseable. El grado hasta el que se puede conseguir viene representado por la FORMAS
NORMALES.
Mediante las dependencias funcionales se pueden definir varias formas normales que
representan "buenos" diseños de bases de datos.

7.6. FORMA NORMAL DE BOYCE-CODD. FNBC

Una tabla está en FNBC dada una dependencia funcional no trivial, α → β, si α
es una superclave de la tabla.
Descomposición: Cuando para una dependencia funcional, no trivial, α → β
no se cumple, creo una nueva tabla en la que pongo el campo que está a la izquierda
de la dependencia funcional y todos los campos que están a la derecha. Mantengo en
la tabla original ese mismo campo, para que haga de clave externa y cumpla con la
norma de descomposición sin pérdida, que hemos visto antes.
Si para la dependencia funcional α → β, se cumple que α es una superclave
de la nueva tabla, la tabla está en FNBC. (Todos los campos dependen de la
superclave)
2
 Desarrollo de aplicaciones informáticas – Esquema sobre el Diseño de Bases de Datos Relacionales

No siempre se puede encontrar una descomposición que cumpla que sea:

1) Sin pérdida
2) Esté en FNBC
3) Y que además conserve las dependencias.

Como la reunión sin pérdida es una condición esencial para la

descomposición, hay que elegir entre que no se cumpla la FNBC o la conservación
de dependencias
.
La 3FN es una pequeña relajación de la FNBC que conserva las dependencias
y que puede tener una cierta redundancia en las tablas resultantes. Siempre hay una
descomposición en 3FN que conserva las dependencias.

7.7. TERCERA FORMA NORMAL. 3FN

Una tabla está en 3FN, si para cada dependencia funcional, no trivial, α → β, cada
atributo está contenido en alguna clave candidata de la tabla resultante de la
descomposición.
Observa que la condición NO dice que una sola clave candidata deba contener todos
los atributos de α → β. Cada atributo de α → β puede estar contenido en una clave
candidata diferente.

- Permite dependencias funcionales de otros campos que NO son superclave.

-Algunos atributos pueden depender de una clave candidata y otros de otra clave
candidata.

- Siempre es posible encontrar un diseño 3FN que conserve la Reunión sin

Perdida y Conserve las Dependencias.

- Como consecuencia de esto, puede necesitar valores nulos y repetir información.

7.7.3. Comparación entre FNBC y 3FN

· FNBC tiene la ventaja de que elimina la repetición de información y el inconveniente

de que no siempre se puede obtener un diseño en FNBC sin sacrificar la reunión sin pérdida
o la conservación de dependencias.
· 3FN tiene la ventaja de que siempre se puede obtener un diseño en FNBC sin
sacrificar la reunión sin pérdida o la conservación de dependencias. Su mayor inconveniente
es que si no se eliminan todas las relaciones transitivas, puede que se tengan que emplear
valores nulos para representar algunos campos y además se produce repetición de
información.

7.8. CUARTA FORMA NORMAL. 4FN

No todas las tablas están suficientemente normalizados (sin repetición), aunque estén
en FNBC. Por ejemplo:

Cliente →Dirección-cliente. Un cliente puede tener varias direcciones.

3
 Desarrollo de aplicaciones informáticas – Esquema sobre el Diseño de Bases de Datos Relacionales

Vamos a utilizar las dependencias multivaloradas para definir esta forma normal,
que es más restrictiva que FNBC.

α →→ β α puede determinar muchos valores de β

Una tabla está en 4FN con respecto a un conjunto de dependencias funcionales y

multivaloradas, si para todas las dependencias multivaloradas α →→ β, se cumple como
mínimo una de las dos condiciones siguientes:
- α →→ β es una dependencia multivalorada trivial
- α es una superclave de la tabla

Si la tabla no está en 4FN, la descomponemos.

Una descomposición será una descomposición sin pérdida si cumple la misma

condición que se exigía para las dependencias funcionales:
- Si quedan uno o varios campos comunes a ambas tablas y estos son
superclave de una de ella, la descomposición es sin pérdida.

7.9. OTRAS FORMAS NORMALES

- 2FN: solo tiene interés histórico
- 5FN / FNRP: Forma Normal de Reunión por Proyección
- FNDC: Forma Normal de Dominios y Claves

7.10. PROCESO GENERAL DEL DISEÑO DE BASES DE DATOS

Para el diseño de una base de datos, podemos partir de:

7.10.1. El modelo E-R y la normalización:

Si está bien hecho nos dará como resultados tablas bien normalizadas.

7.10.2. El enfoque de la relación universal: Una sola tabla que reúna todos los campos.
Aplicamos la descomposición según las técnicas que hemos visto hasta
obtener un diseño que esté lo más normalizado posible. Objetivo FNBC, alternativamente
3FN.

Un diseño hecho expresamente para ese problema.

Comprobamos en cada tabla la forma normal en la que está.
7.10.3. Desnormalización

A veces lo diseñadores de bases de datos escogen diseños que tienen información

redundante, es decir, que no está normalizada.
Puede desnormalizarse un base de datos por:

- Razones de rendimiento: Consultas frecuentes sobre muchas tablas con muchos

registros en cada una de ellas. Creamos una tabla que contenga solo los datos
requeridos.
- Los valores históricos no pueden cambiar con los valores actuales. El precio de los
productos tiene que estar repetido en las líneas de las facturas, no puede cambiar el
precio de las factura emitidas al actualizar el precio de un producto.
4