Normalización Curso Bases de Datos Por Elizabeth León Guzmán, Ph.D. Profesora Ingeniería de Sistemas Grupo de Investigación MIDAS
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.
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 Nacional Prof. Prof. Elizabeth Elizabeth León León Bases de Bases Datos de Datos - Normalización - 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 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 30 50 3/5 5/5
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: 55 José Puente Aranda 70.000 A4 Grapas 30 50 3/5 5/5 Se puede normalizar con la creación de un registro nuevo por cada uno de los distintos valores de un campo 55 José Puente Aranda 55 José Puente Aranda 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 Relación CLIENTES ClienteID Nombre Localidad CostoTransporte 11 Luis Suba 50.000 44 Ana Centro 65.000 55 José Puente Aranda 70.000 Relación ARTÍCULOS ArtículoID Artículo Relación VENTAS 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 A1 A3 A4 A9 Papel Cinta Grapas Lápiz
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. Relación CLIENTES ClienteID Nombre Localidad CostoTransporte Hay una dependencia transitiva que ocasiona problemas a la hora de hacer actualizaciones 11 Luis Suba 50.000 44 Ana Centro 65.000 55 José Puente Aranda 70.000
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.
Tercera Forma Normal 3FN Aplicando la 3FN a la relación CLIENTES Relación CLIENTES Relación TRANSPORTE ClienteID Nombre Localidad Localidad CostoTransporte 11 Luis Suba 44 Ana Centro 55 José Puente Aranda Suba 50.000 Centro 65.000 Puente Aranda 70.000
Tercera Forma Normal 3FN 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
Forma Normal de Boyce Codd BCFN Como ejemplo veamos la relación: Un empleado puede trabajar en varios de partamentos y tiene máximo un asesor en cada departamento: Id_empleado id_departamento Id_asesor 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?
Forma Normal de Boyce Codd BCFN el asesor solo puede pertenecer a un departamento... Id_empleado id_departamento Id_asesor Aparece una dependencia funcional: id_asesor id_departamento Por lo tanto existe un determinante que NO es clave candidata. Genera redundancia: la repetición de id_asesor, id_departamento es evitable. Cómo?
Forma Normal de Boyce Codd BCFN el asesor solo puede pertenecer a un departamento... Id_empleado id_departamento Id_asesor Aparece una dependencia funcional: id_asesor id_departamento Por lo tanto existe un determinante que NO es clave candidata. Genera redundancia: la repetición de id_asesor, id_departamento es evitable. 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
Forma Normal de Boyce Codd BCFN 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
Dependencias de Valores Múltiples Consideremos la relación ESTUDIANTE (Num, Curso, Deporte) que indica su número, el curso donde está matriculado y los deportes que practica. ESTUDIANTE 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
Dependencias de Valores Múltiples 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 ESTUDIANTE Curso 10 Base de datos 20 Física Num PRACTICA Curso 10 Baloncesto 10 Natación 10 Tenis 20 Baloncesto 20 Esgrima
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
El Modelo ER y la Normalización En general, el diseño E-R tiende a generar diseños en 4FN Modelo E-R Normalización en 4FN
Desnormalización Por rendimiento Usan la reduncia por mejorar el rendimiento de aplicaciones concretas!. El problema es garantizar que los datos se mantengan consistentes!
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.