Normalización Preparó: Ismael Castañeda Fuentes MAGIS Ltda Versión 2.1 Normalización Preparó: Ismael Castañeda Fuentes Fuente principal: Database Systems – A Practical Approach to Design, Implementation, and Management. Thomas Connolly, Carolyn Begg Universidad Nacional de Colombia Facultad de Ingeniería UML aplicado a análisis y diseño orientado a objetos

Objetivos Terminología Propósito de la normalización MAGIS Ltda Objetivos Versión 2.1 Terminología Propósito de la normalización Uso de la normalización en diseño de bases de datos relacionales Problemas potenciales relacionados con datos redundantes Dependencias funcionales Uso de las dependencias funcionales en la normalización Identificación de dependencias funcionales en una relación Dependencias funcionales para identificar la llave primaria Dependencias funcionales para agrupar atributos en relaciones Identificar 1FN, 2FN, 3FN, BCFN,4FN, 5FN Dependencias multivaluadas Axiomas de Armstrong UML aplicado a análisis y diseño orientado a objetos

TÉRMINOS EQUIVALENTES MAGIS Ltda Terminología Versión 2.1 TÉRMINOS EQUIVALENTES FORMAL (Codd) COMÚN FÍSICO Relación Tabla Archivo Tupla Fila Registro Atributo Columna Campo Dominio Tipo de dato UML aplicado a análisis y diseño orientado a objetos

Propósito de la normalización MAGIS Ltda Propósito de la normalización Versión 2.1 La normalización es una técnica para obtener un conjunto de relaciones que soporten apropiadamente los requerimientos de datos de una empresa Características del conjunto de relaciones Mínimo número de atributos necesarios para soportar los requerimientos de datos Atributos correlacionados están en la misma relación Redundancia mínima, excepto para atributos que son parte de llaves foráneas Beneficios Acceso y mantenimiento más sencillo Mínimo uso de espacio en memoria de los computadores UML aplicado a análisis y diseño orientado a objetos

Normalización y diseño de bases de datos MAGIS Ltda Normalización y diseño de bases de datos Versión 2.1 UML aplicado a análisis y diseño orientado a objetos

Redundancia de datos y anomalías en la actualización MAGIS Ltda Redundancia de datos y anomalías en la actualización Versión 2.1 El objetivo principal del diseño de base de datos relacional, es agrupar los atributos en relaciones para minimizar la redundancia de datos Beneficios potenciales al hacer la implementación Actualizaciones a la base de datos se hacen con el mínimo de operaciones, reduciendo la posibilidad de datos inconsistentes Reducción del espacio requerido en almacenamiento persistente, reduciendo costes UML aplicado a análisis y diseño orientado a objetos

Redundancia de datos y anomalías en la actualización MAGIS Ltda Redundancia de datos y anomalías en la actualización Versión 2.1 La relación StaffBranch tiene datos redundantes Al hacer operaciones en la base de datos se pueden presentar anomalías Inserción Actualización Borrado UML aplicado a análisis y diseño orientado a objetos

Descomposición - Solución a la Redundancia de datos MAGIS Ltda Descomposición - Solución a la Redundancia de datos Versión 2.1 UML aplicado a análisis y diseño orientado a objetos

Propiedades de la Descomposición MAGIS Ltda Propiedades de la Descomposición Versión 2.1 Dos propiedades importantes de la descomposición: La propiedad Lossless-join nos permite encontrar cualquier instancia de la relación original en instancias correspondientes en relaciones más pequeñas La propiedad de Preservación de dependencia nos permite imponer una restricción en la relación original mediante la imposición de una restricción en cada una de las relaciones más pequeñas. UML aplicado a análisis y diseño orientado a objetos

Dependencias funcionales MAGIS Ltda Dependencias funcionales Versión 2.1 Concepto importante en la normalización Describen asociaciones entre atributos Si A y B son atributos de R, B es funcionalmente dependiente de A, si para cada valor de A en R está asociado exactamente con un valor de B en R Notación: A  B Representación gráfica: Determinante de una dependencia funcional Atributo o grupo de atributos al lado izquierdo de la flecha UML aplicado a análisis y diseño orientado a objetos

Dependencias funcionales MAGIS Ltda Dependencias funcionales Versión 2.1 Dependencia funcional basada en un solo dato staffNo  sName sName  staffNo Dependencia funcional considerando todos los datos UML aplicado a análisis y diseño orientado a objetos

Características de las dependencias funcionales MAGIS Ltda Características de las dependencias funcionales Versión 2.1 Dependencia Funcional completa Los determinantes deben tener el mínimo número de atributos necesarios para mantener la dependencia funcional con el (los) atributo(s) del lado derecho Si A y B son atributos de una relación, B es funcionalmente completa dependiente de A, si B es funcionalmente dependiente de A, pero no sobre cualquier propiedad del subconjunto A Ejemplo de dependencia parcial staffNo, sName  branchNo Verdadero, cada valor de (staffNo, sName) está asociado con un valor de branchNo Pero, branchNo también es funcionalmente dependiente de un subconjunto de (staffNo, sName), es decir de staffNo UML aplicado a análisis y diseño orientado a objetos

Características de las dependencias funcionales MAGIS Ltda Características de las dependencias funcionales Versión 2.1 Características principales de dependencias funcionales usadas en normalización Hay una asociación 1 a 1 entre el(los) atributo(s) del lado izquierdo (determinante) y aquellos que están en la mano derecha de la dependencia funcional Se cumple para todos los casos El determinante tiene el número mínimo de atributos necesarios para mantener la dependencia con el(los) atributo(s) de la mano derecha UML aplicado a análisis y diseño orientado a objetos

Dependencias transitivas MAGIS Ltda Dependencias transitivas Versión 2.1 Importante reconocer dependencias transitivas porque su existencia en una relación puede potencialmente causar anomalías al hacer actualizaciones Dependencia transitiva Si A, B y C son atributos de una relación tal que A  B y B  C Entonces C es dependiente transitivamente de A vía B (a condición de que A no es funcionalmente dependiente de B o C) Ejemplo staffNo  sName, position, salary, branchNo, bAddress branchNo  bAdress Dependencia transitiva: branchNo  bAddress existe sobre staffNo vía branchNo UML aplicado a análisis y diseño orientado a objetos

Proceso de normalización MAGIS Ltda Proceso de normalización Versión 2.1 Técnica formal para analizar una relación basada en su llave primaria y las dependencias funcionales entre los atributos de esa relación Se ejecuta a través de una serie de pasos. Cada paso corresponde a una forma normal específica, que tiene sus propiedades UML aplicado a análisis y diseño orientado a objetos

Identificación de dependencias funcionales MAGIS Ltda Identificación de dependencias funcionales Versión 2.1 Identificar todas las dependencias funcionales de un conjunto de atributos es relativamente simple, si el significado de cada atributo y las asociaciones entre atributos se conocen muy bien Esta información debe ser proporcionada por la empresa de charlas con los usuarios y/o documentación tal como los requerimientos de los usuarios Si los usuarios no están disponibles y/o la documentación está incompleta, dependiendo de la aplicación sobre la base de datos el diseñador de la base de datos debe utilizar el sentido común y/o experiencia para suministrar la información faltante UML aplicado a análisis y diseño orientado a objetos

Ejemplo de identificación de dependencias funcionales MAGIS Ltda Ejemplo de identificación de dependencias funcionales Versión 2.1 Se supone que position y branch determinan salary del staff Dependencias funcionales para la relación StaffBranch staffNo  sName, position, salary, branchNo, bAddress branchNo  bAddress bAddress  branchNo branchNo, position  salary bAddress, position  salary UML aplicado a análisis y diseño orientado a objetos

Ejemplo de identificación de dependencias funcionales MAGIS Ltda Ejemplo de identificación de dependencias funcionales Versión 2.1 Dependencias funcionales entre los atributos A hasta E A  C (fd1) C  A (fd2) B  D (fd3) A, B  E (fd4) Con las dependencias funcionales, identificar las restricciones de integridad que debe tener la relación Identificar llaves candidatas y una de ellas la llave primaria UML aplicado a análisis y diseño orientado a objetos

Ejemplo de identificación de dependencias funcionales MAGIS Ltda Ejemplo de identificación de dependencias funcionales Versión 2.1 Dependencias funcionales de StaffBranch staffNo  sName, position, salary, branchNo, bAddress branchNo  bAddress bAddress  branchNo branchNo, position  salary bAddress, position  salary Determinantes: staffNo, branchNo, bAddress, (branchNo, position) y (bAddress, position) Para identificar llaves candidatas: Identificar el(los) atributo(s) que identifican cada tupla en la relación Todos los atributos que no hacen parte de la llave candidata deben ser funcionalmente dependientes de la llave La única llave candidata y llave primaria de la relación StaffBranch es staffNo (los demás atributos de la relación son funcionalmente dependientes de staffNo) UML aplicado a análisis y diseño orientado a objetos

Ejemplo de identificación de dependencias funcionales MAGIS Ltda Ejemplo de identificación de dependencias funcionales Versión 2.1 Dependencias funcionales A  C (fd1) C  A (fd2) B  D (fd3) A, B  E (fd4) Determinantes A, B, C y (A,B) Único determinante que funcionalmente determina todos los otros atributos es (A, B) Entonces (A, B) es la llave primaria UML aplicado a análisis y diseño orientado a objetos

Proceso de normalización MAGIS Ltda Proceso de normalización Versión 2.1 A medida que avanza la normalización, las relaciones se vuelven cada vez más restringidas (más fuertes) en la forma y también menos vulnerables a las anomalías de actualización. UML aplicado a análisis y diseño orientado a objetos

Proceso de normalización MAGIS Ltda Proceso de normalización Versión 2.1 UML aplicado a análisis y diseño orientado a objetos

Forma desnormalizada (UNF) MAGIS Ltda Forma desnormalizada (UNF) Versión 2.1 UNF: Tabla que contiene uno o más grupos repetitivos Para crear una tabla sin normalizar Transformar los datos de la fuente de información (formulario, por ejemplo) en formato de tabla con columnas y filas UML aplicado a análisis y diseño orientado a objetos

Forma desnormalizada (UNF) MAGIS Ltda Forma desnormalizada (UNF) Versión 2.1 Grupo repetitivo dentro de columna CLIENTE ID Cliente Nombre Apellido Teléfono 123 Rachel Ingram 555-861-2025 456 James Wright 555-403-1659 555-776-4100 789 Maria Fernandez 555-808-9633 Grupo repetitivo a través de columnas CLIENTE ID Cliente Nombre Apellido Teléfono 1 Teléfono 2 Teléfono 3 123 Rachel Ingram 555-861-2025 456 James Wright 555-403-1659 555-776-4100 789 Maria Fernandez 555-808-9633 CLIENTE ID Cliente Nombre Apellido Teléfono 123 Rachel Ingram 555-861-2025 456 James Wright 555-403-1659 555-776-4100 789 Maria Fernandez 555-808-9633 UML aplicado a análisis y diseño orientado a objetos

MAGIS Ltda UNF a 1FN Versión 2.1 1FN: relación en la cual en cada intersección de una fila y una columna contiene uno y solo un valor, sin grupos repetitivos Seleccionar un atributo o conjunto de atributos para actuar como la llave para la tabla no normalizada Identificar el(los) grupo(s) de repetitivo(s) en la tabla no normalizada que se repite para el(los) atributo(s) llave(s) Quitar el grupo de repetitivo Introduciendo datos apropiados en las columnas vacías de filas que contienen los datos repetitivos ("aplanamiento" de la tabla) ó Colocando los datos repetitivos junto con una copia original del (de los) atributo(s) clave(s) en una relación aparte UML aplicado a análisis y diseño orientado a objetos

UNF a 1FN MAGIS Ltda Versión 2.1 Relación no normalizada CLIENTE ID Cliente Nombre Apellido Teléfono 1 Teléfono 2 Teléfono 3 123 JOSE ALFREDO Ingram 555-861-2025 456 ALEX Wright 555-403-1659 555-776-4100 789 MARTIN Fernandez 555-808-9633 Relación no normalizada CLIENTE ID Cliente Nombre Apellido Teléfono 123 Rachel Ingram 555-861-2025 456 James Wright 555-403-1659 555-776-4100 789 Maria Fernandez 555-808-9633 Diseño en 1FN CLIENTE ID Cliente Nombre Apellido 123 Rachel Ingram 456 James Wright 789 Maria Fernandez Teléfono del cliente ID Cliente Teléfono 123 555-861-2025 456 555-403-1659 555-776-4100 789 555-808-9633 UML aplicado a análisis y diseño orientado a objetos

UNF a 1FN MAGIS Ltda Versión 2.1 Relación no normalizada Relación no normalizada Diseño en 1FN UML aplicado a análisis y diseño orientado a objetos

Primera Forma Normal (1NF) MAGIS Ltda Primera Forma Normal (1NF) Versión 2.1 Dependencias funcionales UML aplicado a análisis y diseño orientado a objetos

Segunda Forma Normal (2NF) MAGIS Ltda Segunda Forma Normal (2NF) Versión 2.1 2NF Basada en el concepto de dependencia funcional completa Dependencia funcional completa indica que si A y B son los atributos de una relación B es totalmente dependiente de A si B es funcionalmente dependiente de A, pero no en un subconjunto de A Segunda Forma Normal (2NF) Una relación que está en 1FN y todo atributo no llave primaria es totalmente dependiente funcionalmente de la llave primaria Una relación que está en 1FN y cada atributo no llave primaria tiene dependencia funcional total de cualquier llave candidata UML aplicado a análisis y diseño orientado a objetos

1FN a 2NF Identificar la llave primaria de la relación 1NF MAGIS Ltda 1FN a 2NF Versión 2.1 Identificar la llave primaria de la relación 1NF Identificar las dependencias funcionales en la relación Si existen dependencias parciales en la llave primaria eliminarlas colocándolas en una nueva relación junto con una copia de su determinante Dependencias funcionales UML aplicado a análisis y diseño orientado a objetos

Tercera Forma Normal (3NF) MAGIS Ltda Tercera Forma Normal (3NF) Versión 2.1 3NF Basada en el concepto de dependencia transitiva La dependencia transitiva es una condición donde A, B y C son los atributos de una relación tal que si A  B y B C, Entonces C es transitivamente dependiente de A a través de B (condición: A no es funcionalmente dependiente de B o C) Tercera forma Normal 3FN Relación que está en 1FN y 2FN y en la que ningún atributo no llave primaria es transitivamente dependiente de la llave primaria Relación que está en primera y en segunda forma normal y en el que ningún atributo no llave primaria es transitivamente dependiente de cualquier llave candidata UML aplicado a análisis y diseño orientado a objetos

2FN a 3NF Identificar la llave primaria en la relación 2FN MAGIS Ltda 2FN a 3NF Versión 2.1 Identificar la llave primaria en la relación 2FN Identificar las dependencias funcionales en la relación Si existen dependencias transitivas de la llave primaria, eliminarlas reemplazándolas por una nueva relación, junto con una copia de su dominante UML aplicado a análisis y diseño orientado a objetos

Más sobre dependencias funcionales MAGIS Ltda Más sobre dependencias funcionales Versión 2.1 El conjunto completo de dependencias funcionales de una relación dada puede ser muy grande Es importante encontrar un enfoque que reduzca el conjunto a un tamaño manejable UML aplicado a análisis y diseño orientado a objetos

Reglas de inferencia para dependencias funcionales MAGIS Ltda Reglas de inferencia para dependencias funcionales Versión 2.1 Identificar un conjunto de dependencias funcionales de una relación (representadas como X) que sea un conjunto más pequeño que el conjunto completo de dependencias funcionales para esa relación (representadas como Y) y que tengan la propiedad de que para cada dependencia funcional en Y está implícita por las dependencias funcionales en X El conjunto de todas las dependencias funcionales que están implícitas en un conjunto dado de dependencias funcionales X se llama el cierre de X, notado X+ Un conjunto de reglas de inferencia, denominados axiomas de Armstrong, especifican cómo las nuevas dependencias funcionales se pueden inferir de las dadas. UML aplicado a análisis y diseño orientado a objetos

Reglas de inferencia para dependencias funcionales MAGIS Ltda Reglas de inferencia para dependencias funcionales Versión 2.1 Sean A, B y C subconjuntos de los atributos de la relación R. Los axiomas de Armstrong son: (1) Reflexividad Si B es un subconjunto de A, entonces A  B (2) Incremento (augmentation) Si A  B, entonces A,C  B,C (3) Transitividad Si A  B y B  C, entonces A  C Reglas adicionales se pueden derivar de las tres primeras las cuales simplifican el cálculo de X+ Sea D otro subconjunto de atributos de la relación R, entonces: (4) Autodeterminación A  A (5) Descomposición Si A  B,C, entonces A  B y A  C (6) Unión Si A  B y A  C, entonces A  B,C (7) Composición Si A  B y C  D, entonces A,C  B,D UML aplicado a análisis y diseño orientado a objetos

Conjuntos mínimos de dependencias funcionales MAGIS Ltda Conjuntos mínimos de dependencias funcionales Versión 2.1 Un conjunto de dependencias funcionales Y está cubierta por un conjunto de dependencias funcionales X, si cada dependencia funcional de Y está también en X+, es decir, todas las dependencias en Y se pueden inferir de X. Un conjunto de dependencias funcionales X es mínima si satisface las siguientes condiciones: Cada dependencia en X tiene un solo atributo en su lado derecho No puede sustituir ninguna dependencia A  B en X con la dependencia C  B, donde C es un subconjunto propio de A, y aún así tener un conjunto de dependencias equivalentes a X. No se puede eliminar ninguna dependencia de X y conservar un conjunto de dependencias que equivalen a X. UML aplicado a análisis y diseño orientado a objetos

Forma normal de Boyce-Codd (BCFN) MAGIS Ltda Forma normal de Boyce-Codd (BCFN) Versión 2.1 Una relación está en Boyce-Codd (BCFN) si y solo si cada determinante es llave candidata Basada en las dependencias funcionales que tienen en cuenta todas las claves candidatas en una relación, sin embargo BCNF tiene restricciones adicionales con respecto a la definición general de 3FN La diferencia entre 3FN y BCFN es que para una dependencia funcional A  B, 3FN permite esta dependencia en una relación si B es un atributo de la llave primaria y A no es llave candidata. Mientras que, BCNF insiste en que para que esta dependencia permanezca en una relación, A debe ser una llave candidata Toda relación en BCFN también está en 3FN. Sin embargo, una relación en 3FN no necesariamente está en BCFN UML aplicado a análisis y diseño orientado a objetos

Forma normal de Boyce-Codd (BCFN) MAGIS Ltda Forma normal de Boyce-Codd (BCFN) Versión 2.1 Dependencias Funcionales de la relación ClientInterview UML aplicado a análisis y diseño orientado a objetos

Forma normal de Boyce-Codd (BCFN) MAGIS Ltda Forma normal de Boyce-Codd (BCFN) Versión 2.1 Relaciones BCNF Interview y StaffRoom UML aplicado a análisis y diseño orientado a objetos

Forma normal de Boyce-Codd (BCFN) MAGIS Ltda Forma normal de Boyce-Codd (BCFN) Versión 2.1 Son muy raras las violaciones a BCNF Potenciales violaciones a BCNF pueden ocurrir en una relación que: Contiene dos (o más) llaves candidatas compuestas Las llaves candidatas se superponen, es decir, tienen al menos un atributo en común UML aplicado a análisis y diseño orientado a objetos

Repaso de Normalización (UNF a BCNF) MAGIS Ltda Repaso de Normalización (UNF a BCNF) Versión 2.1 UML aplicado a análisis y diseño orientado a objetos

Repaso de Normalización (UNF a BCNF) MAGIS Ltda Repaso de Normalización (UNF a BCNF) Versión 2.1 UML aplicado a análisis y diseño orientado a objetos

Repaso de Normalización (UNF a BCNF) MAGIS Ltda Repaso de Normalización (UNF a BCNF) Versión 2.1 UML aplicado a análisis y diseño orientado a objetos

Repaso de Normalización (UNF a BCNF) MAGIS Ltda Repaso de Normalización (UNF a BCNF) Versión 2.1 UML aplicado a análisis y diseño orientado a objetos

Cuarta Forma Normal (4NF) MAGIS Ltda Cuarta Forma Normal (4NF) Versión 2.1 A pesar de que BCNF elimina anomalías debidas a dependencias funcionales, otro tipo de dependencias, llamadas dependencias multi-valuadas (MVD), pueden causar redundancia de datos La posible existencia de dependencias multi-valuadas en una relación se debe a 1NF y que puede resultar en redundancia de datos Dependencia multi-valuada (MVD) Dependencia entre atributos de una relación (por ejemplo: A, B y C), tal que para cada valor de A hay un conjunto de valores para B y un conjunto de valores para C. Sin embargo, el conjunto de valores de B y C son independientes uno del otro. Notación MVD entre atributos A, B y C de una relación: A ->> B A ->> C UML aplicado a análisis y diseño orientado a objetos

Cuarta Forma Normal (4NF) MAGIS Ltda Cuarta Forma Normal (4NF) Versión 2.1 Una dependencia multi-valuada se puede definir como trivial o no trivial Una MVD A ->> B en una relación R se define como trivial si (a) B es un subconjunto de A ó (b) A U B = R Una MVD se define como no trivial si ni (a) ni (b) se satisfacen Una MVD trivial no especifica una restricción en una relación, mientras que una MVD no trivial especifica una restricción 4FN es una relación que está en forma normal Boyce-Codd y no contiene dependencias no triviales multi-valuadas UML aplicado a análisis y diseño orientado a objetos

Cuarta Forma Normal (4NF) - Ejemplo MAGIS Ltda Cuarta Forma Normal (4NF) - Ejemplo Versión 2.1 UML aplicado a análisis y diseño orientado a objetos

Quinta forma normal (5NF) MAGIS Ltda Quinta forma normal (5NF) Versión 2.1 5FN es una relación descompuesta en dos relaciones que tienen la propiedad lossless-join, la que asegura que no se generan tuplas no válidas cuando las relaciones se reúnen a través de una operación natural join Sin embargo, hay requisitos para descomponer una relación en más de dos relaciones. Aunque raros, esos casos se manejan por dependencia join y quinta forma normal (5NF) 5FN es una relación que no tiene dependencias join UML aplicado a análisis y diseño orientado a objetos

Quinta forma normal (5NF) - Ejemplo MAGIS Ltda Quinta forma normal (5NF) - Ejemplo Versión 2.1 UML aplicado a análisis y diseño orientado a objetos