Normalización -...

NormalizaciónCurso Bases de Datos

PorElizabeth León Guzmán, Ph.D.

Profesora Ingeniería de Sistemas

Grupo de Investigación MIDAS

Universidad Nacional – Prof. Elizabeth León Bases de Datos - Normalización

Agenda

1. Diseño de Bases de Datos

2. Normalización

3. Dependencia Funcional

4. Primera Forma 1FN

5. Segunda Forma 2FN

6. Tercera Forma 3FN

7. Forma Normal de Boyce Codd BCFN

8. Cuarta Forma 4FN


Diseño de Bases de Datos

Por diseño se entiende el generar un conjunto de esquemas de relaciones que permitan almacenar información con un

mínimo de redundancia de datos y una fácil recuperación de la información.

Universidad Nacional – Prof. Elizabeth León Bases de Datos - NormalizaciónUniversidad Nacional – Prof. Elizabeth León Bases de Datos - Normalización

Objetivos

• Mantener la Integridad de los datos.

• Eliminar información redundante siempre que sea posible.

• Mantener el número de relaciones al mínimo entre los componentes de la base de datos (fácil programación y uso por parte del usuario).

• Minimizar problemas de actualización y borrado.


Normalización

La Normalización es la descomposición o subdivisión de una relación en dos o mas relaciones para evitar la redundancia.

También se puede ver como una serie de reglas que ayudan a los diseñadores de bases de datos a desarrollar un esquema que minimice los problemas de lógica.

Universidad Nacional – Prof. Elizabeth León Bases de Datos - NormalizaciónUniversidad Nacional – Prof. Elizabeth León Bases de Datos - Normalización

DEPENDENCIA FUNCIONAL: DF

La Normalización se basa en la dependencia funcional:

Dependencia funcional se define como: Dados dos atributos A y B de una relación R, se dice que B es funcionalmente dependiente de A si para cada valor de A existe un valor de B, y sólo uno, asociado con él. Se denota como

A B

Las DF se determinan al estudiar las propiedades de todos los atributos de la relación y deducir cómo están relacionados los atributos entre si.


DEPENDENCIA FUNCIONAL: DF

La DF está ligada con el concepto de clave.

Clave candidata: Conjunto de uno o más atributos que podría ser utilizado como clave principal de una relación.

Superclave: Conjunto de uno o más atributos que juntos, permiten identificar de forma única una entidad dentro de una relación.

Clave principal: Es una clave candidata en la que ningún componente puede tomar el valor de nulo.


Normalización

El proceso de normalización es definido por una serie de fases cada una con una serie de reglas específicas.

Veamos un ejemplo…


Se desea implantar en una base de datos las ventas de una papelería por la relación ORDENES-VENTA

ClienteID Nombre Localidad CostoTransporte ArtículoID Artículo Cantidad Fecha

11 Luis Suba 50.000 A1 Papel 100 3/5

11 Luis Suba 50.000 A3 Cinta 50 5/5

11 Luis Suba 50.000 A9 Lápiz 200 7/5

44 Ana Centro 65.000 A1 Papel 100 10/5

55 José Puente Aranda

70.000 A4 Grapas 3050

3/55/5

Relación ORDENES-VENTA


Primera Forma 1FN

Una relación está en primera forma normal si todo atributo contiene un valor indivisible, atómico.

En una relación sin normalizar como la anterior se encuentra por ejemplo lo siguiente:

Se puede normalizar con la creación de un registro nuevo por cada uno de los distintos valores de un campo



70.000 A4 Grapas 3050

3/55/5


70.000 A4 Grapas 30 3/5


70.000 A4 Grapas 50 5/5

Primera Forma 1FN

Hecho lo anterior aún se presentan una serie de anomalías de almacenamiento a la hora de realizar las actualizaciones por la información redundante.

Estás anomalías se deben a la presencia de campos no clave en la relación.


Primera Forma 1FN

Las anomalías pueden subsanarse de la siguiente forma:

– Dividiendo la relación universal en nuevas relaciones.

– Eligiendo una clave primaria que represente de forma única a cada registro de las nuevas relaciones. Cada nueva relación tiene la propiedad de que su clave es necesaria para definir cada uno de los campos no clave.

Veamos como resulta el diseño de nuestra base de datos al aplicar la 1FN en su totalidad


Segunda Forma 2FN

ClienteID Nombre Localidad CostoTransporte

11 Luis Suba 50.000

44 Ana Centro 65.000


70.000ArtículoID Artículo

A1 Papel

A3 Cinta

A4 Grapas

A9 Lápiz

ClienteID ArtículoID Cantidad Fecha

11 A1 100 3/5

11 A3 50 5/5

11 A9 200 7/5

44 A1 100 10/5

55 A4 30 3/5

55 A4 50 5/5

Relación CLIENTES

Relación ARTÍCULOS

Relación VENTAS


Segunda Forma Normal 2FN

Una relación está en segunda forma normal si, y sólo si:

– Está en 1FN

– Todo atributo que no pertenezca a la clave debe depender de la clave en su totalidad. Es decir, los registro no deben depender de nada aparte de su clave primaria.


Segunda Forma 2FN

– Las relaciones CLIENTES, ARTICULOS y VENTAS pertenecen ya a la 2FN. Sin embargo, la relación CLIENTES presenta anomalías de almacenamiento debido a que el atributo CostoTransporte es funcionalmente dependiente de la Localidad, que a su vez depende de ClienteID.

Hay una dependencia transitiva

que ocasiona problemas a la

hora de hacer actualizaciones

ClienteID Nombre Localidad CostoTransporte

11 Luis Suba 50.000

44 Ana Centro 65.000


70.000

Relación CLIENTES


Dependencia Transitiva

Se tiene la relación R(A,B,C). Si

A B

B C

y A no depende funcionalmente de B, entonces se dice que C depende transitivamente de A y se puede formar la cadena

A B C


Tercera Forma Normal 3FN

Una relación está en 3FN si, y sólo si:

– Está en 2FN.

– Todo atributo que no pertenezca a la clave no depende de un atributo no clave.

La 3FN elimina las redundancias ocasionadas por las dependencias transitivas.



• Aplicando la 3FN a la relación CLIENTES

ClienteID Nombre Localidad

11 Luis Suba

44 Ana Centro


Relación CLIENTES

Localidad CostoTransporte

Suba 50.000

Centro 65.000

Puente Aranda 70.000

Relación TRANSPORTE


Deficiencias:● 1) hay varias claves candidatas

● 2) esas claves candidatas son compuestas

● 3) las claves candidatas se traslapan (tienen por lo menos un atributo en común)


Raramente!


Forma Normal de Boyce Codd BCFN

Una relación R está en forma normal Boyce Codd si, y sólo si, cada determinante de la

relación es una clave candidata.

“no existen dependencias funcionales no triviales de los atributos que no sean un

conjunto de la clave candidata”




Id_empleado id_departamento Id_asesor

Como ejemplo veamos la relación: Un empleado puede trabajar en varios de partamentos y tiene máximo un asesor en cada departamento:

La llave primaria es compuesta: id_empleado, id_departamento.

¿Está en 3FN?

Si añadimos un restricción: el asesor solo puede pertenecer a un departamento.

¿Qué sucede? ¿Sigue estando en 3FN?




el asesor solo puede pertenecer a un departamento...

Aparece una dependencia funcional:

Por lo tanto existe un determinante que NO es clave candidata.

Genera redundancia:

la repetición de id_asesor, id_departamento es evitable.

id_asesor id_departamento

¿Cómo?




el asesor solo puede pertenecer a un departamento...

Aparece una dependencia funcional:

Por lo tanto existe un determinante que NO es clave candidata.

Genera redundancia:

la repetición de id_asesor, id_departamento es evitable.

id_asesor id_departamento

Id_empleado id_asesor

Id_asesor id_departamento

Forma Normal de Boyce Codd BCFN Como ejemplo veamos la relación QUESOS (NOMBRE,PAIS,REGION). La clave candidata es (NOMBRE, PAIS) con las DF siguientes:

REGION PAIS

(NOMBRE,PAIS) REGION

La relación está en 3FN porqué ningún atributo no clave es transitivamente dependiente de atributos no clave. Sin embargo no es BCFN ya que REGION, un atributo no clave, es un determinante de país. Esto origina redundancia y puede resolverse formando dos relaciones nuevas:

QUESOS(NOMBRE,REGION) NOMBRE REGION

REGIONES(REGION,PAIS) REGION PAIS


Se dice que una tabla está en FNBC si y solo si :

- está en 3FN y

- cada dependencia funcional no trivial tiene una clave candidata como determinante. En términos menos formales, una tabla está en FNBC si está en 3FN y los únicos determinantes son claves candidatas.



Dependencias de Valores Múltiples

En la dependencia de valores múltiples (DMV), un valor atributo, A, determina un conjunto de valores múltiples, B. Se expresa con doble fecha:

A B


Consideremos la relación

ESTUDIANTE (Num, Curso, Deporte)

que indica su número, el curso donde está matriculado y los deportes que practica.

Num Curso Deporte

10 Bases de Datos Baloncesto

10 Bases de Datos Natación

10 Bases de Datos Tenis

20 Física Baloncesto

20 Física Esgrima


ESTUDIANTE


La relación anterior está en 3FN pero presenta redundancia de datos aún.

Los atributos Curso y Deporte son dependientes multivalores de Num, es decir, cualquier valor de Num determina una serie de valores de los atributos Curso y Deporte.



Cuarta Forma Normal4FN

La 4FN es una generalización de la BCFN para descomponer relaciones que posean dependencias multivaluadas.

Una relación R está en 4FN si, y sólo si:

– Es BCFN

– No contiene dependencias multivaludas


Cuarta Forma Normal 4FN

La relación R(A,B,C) con las dependencias multivaluadas :

Se puede descomponer sin pérdida en dos relaciones 4FN: R1(A,B) y R2(A,C).


Cuarta Forma Normal 4FN

Volviendo al ejemplo de la relación ESTUDIANTE, y aplicando la 4FN, se generan las siguientes relaciones:

Num Curso

10 Base de datos

20 Física

Num Curso

10 Baloncesto

10 Natación

10 Tenis

20 Baloncesto

20 Esgrima

ESTUDIANTE

PRACTICA


Más Formas Normales

● La 4FN no es definitiva● Dependencias de reunión: Forma

Normal de Reunión por Proyección FNRP o Quinta Forma Normal

● Forma Normal de Dominios y Claves FNDC

FNRP y FNDC se utilizan muy rara vez!


El Modelo ER y la Normalización

● Si el modelo E-R es identificado correctamente (entidades, relaciones, etc) los esquemas de relación generados a partir de él NO DEBEN necesitar mucha normalización

● Si se debe realizar mucha normalización es por que el diseño del diagrama fue mal realizado


● En general, el diseño E-R tiende a generar diseños en 4FN

El Modelo ER y la Normalización

Modelo E-RNormalización

en 4FN


● Por rendimiento● Usan la reduncia por mejorar el

rendimiento de aplicaciones concretas!.

● El problema es garantizar que los datos se mantengan consistentes!

Desnormalización

Bibliografía

• RODRÍGUEZ ALMEIDA, Miguel. Diseño de bases de datos. En: BASES DE DATOS. Madrid: Mc Graw Hill, 1992. Pág. 209-218.


Normalización -...

Documents

Transcript of Normalización -...