910 likes | 1.18k Vues
SICI-4030 Base de Datos. Prof. Nelliud D. Torres Data Modeling - Avanzado. OBJETIVOS. Normalización Relaciones recursivas M:M Roles Subtipos y supertipos Entity Clusters Relaciones excluyentes Modelando datos históricos. NORMALIZACIÓN. Volver a los Objetivos. NORMALIZACIÓN.
E N D
SICI-4030Base de Datos Prof. Nelliud D. Torres Data Modeling - Avanzado
OBJETIVOS • Normalización • Relaciones recursivas M:M • Roles • Subtipos y supertipos • Entity Clusters • Relaciones excluyentes • Modelando datos históricos
NORMALIZACIÓN Volver a los Objetivos
NORMALIZACIÓN • DEFINICIÓN - Es una herramienta para validar y mejorar un diseño lógico de modo tal que satisfaga ciertas limitaciones (constraints). Debe evitar duplicación innecesaria de los datos. • Es un proceso de descomponer relaciones con anomalías para producir relaciones pequeñas y bien estructuradas. • Es un concepto de las bases de datos relacionales, pero estos principios se pueden aplicar al modelo conceptual de una base de datos. • En otras palabras cuando se normaliza un ERD, se convierte en un diseño normalizado de una base de datos automáticamente. PAG. 211
NORMALIZACIÓN - METAS (goals) • Algunas metas que buscamos al normalizar son: • Minimizar la redundancia de datos y por lo tanto, evitar las anomalías y conservar espacio de almacenamiento. • Simplificar las limitaciones (constraints) que fuerzan la referencia de integridad. • Que sea fácil mantener los datos (insertar, actualizar y eliminar). • Proveer un mejor diseño el cual es una representación mejorada del mundo real y con bases sólidas para permitir un futuro crecimiento. • Sin embargo la normalización crea lentitud al acceder los datos (véase Data Warehouse) PAG. 211
NORMALIZACIÓN - Relaciones Bien Estructuradas • Son relaciones que contienen una redundancia de datos mínimos y permite a los usuarios insertar, eliminar y actualizar filas sin causar inconsistencia de los datos. • La meta es evitar anomalías, las cuales son: • Insertion Anomaly – Añadir nuevas filas que fuerzen al usuario a crear datos duplicados. • Deletion Anomaly – Eliminar filas que pudieran causar una perdida de datos que fuesen necesários para otras filas futuras. • Modification Anomaly – Cambiar datos en una fila que fuerze cambios en otras filas debido a duplicación.
Example–Figure 5-2b Examine Cuidadosamente Esta Tabla Question–Is this a relation? Answer–Yes: Unique rows and no multivalued attributes Question–What’s the primary key? Answer–Composite: Emp_ID, Course_Title PAG. 190
Anomalías de la tabla anterior • Insertion – No se puede entrar un nuevo empleado si este no esta tomando una clase. • Deletion – Si eliminamos al empleado 140, perdemos información sobre la existencia de un curso titulado: Tax Acc • Modification – Al dársele un aumento de salario al empleado 100, nos fuerza a actualizar múltiples records. • Why do these anomalies exist? • Because there are two themes (entity types) in this one relation. This results in data duplication and an unnecessary dependency between the entities
NORMALIZACIÓN - REGLAS Las primeras tres reglas de normalización son: • 1NF (Primera forma normal) - Todos los atributos deben ser univalorados. • 2NF (Segunda forma normal) - Un atributo debe depender del UID completo de la entidad en la cual está. • 3NF (Tercera forma normal) - No puede haber un atributo que no sea UID dependiendo de otro atributo que tampoco sea UID.
NORMALIZACIÓN - REGLAS - 2 El libro menciona seis reglas de normalizacón las cuales son: • 1NF (Primera forma normal) - Remover atributos multivalorados. • 2NF (Segunda forma normal) - Remover dependencias parciales • 3NF (Tercera forma normal) - Remover dependencias transitivas. • (forma normal Boyce-Codd) - Remover anomalías sobrantes que resultan de los múltiples candidatos a key. • 4NF (Cuarta forma normal) - Remover dependencias con multivalores. • 5NF (Quinta forma normal) - Remover anomalías que hayan quedado. Rara vez utilizamos más de las primeras 3 formas al normalizar. PAG. 211
Figure 5.22 Steps in normalization OJO El libro menciona por lo menos 6 formas de normalización PAG. 212
NORMALIZACIÓN - Primera forma normal 1NF • Regla: Todos los atributos deben ser univalorados (remover atributos multivalorados). • Debemos cotejar que cada atributo tenga un solo valor para cada instancia de la entidad. • Además: • No deben existir grupos repetitivos (repeating groups) en la relación (un single factes la intersección de cada fila y columna de la tabla) • Un PK debe estar definido, el cual identifica únicamente cada fila en la relación. • Veamos los siguientes ejemplos: PAG. 214
NORMALIZACIÓN-1NF - Ejemplo A Table with multivalued attributes, not in 1st normal form PAG. 215
Table with no multivalued attributes and unique rows, in 1st normal form Repeating groups que deben ser eliminados para cumplir con la primera forma normal Note: this is relation, but not a well-structured one PAG. 216
Anomalías en esta Tabla • Insertion– Si un nuevo producto es ordenado para la orden 1007 de un cliente existente, los datos del cliente tienen que volverse a entrar, lo cual causa duplicación. • Deletion– Si eliminamos el Dining Table de la orden 1006, perdemos información relacionada a ese ítem en términos de las terminaciones (finish) y del precio. • Update– Cambiar el precio del producto con ID 4, requiere la actualización de varios récords. • Why do these anomalies exist? • Because there are multiple themes (entity types) in one relation. This results in duplication and an unnecessary dependency between the entities
EJEMPLO - B - 1NF ¿Cumple la entidad CLIENTE con la 1NF? ¿Todos los atributos cumplen con la condición de no tener múltiples valores? CLIENTE #* código * nombre * dirección * fecha_contacto * teléfono_casa
EJEMPLO - B - 1NF (Cont.) • El atributo fecha_contacto puede tener más de un valor ya que uno puede contactar a un cliente en más de una ocasión. • Por lo tanto el atributo fecha_contacto tiene múltiples valores (aunque sólo puede almacenar la última fecha de contacto) • Solución: Crear una entidad adicional llamada CONTACTO que permita almacenar todos los contactos que se tengan con el cliente.
EJEMPLO - B - 1NF (Cont.) SOLUCIÓN CONTACTO #* fecha de contacto o lugar * resultado CLIENTE #* código * nombre * dirección * teléfono_casa de el sujeto de
NORMALIZACIÓN - SOLUCIÓN - 1NF 1NF • SOLUCIÓN: Si un atributo tiene múltiples valores, cree una entidad adicional y relaciónela con la entidad original usando una relación M:1
NORMALIZACIÓN - Segunda forma normal 2NF • Regla: Un atributo debe depender del UID completo de la entidad en la cual está. (Remover dependencias parciales) • Debemos cotejar que un atributo no dependa de solamente parte del UID de una entidad. PAG. 217
NORMALIZACIÓN - Second Normal Form • Debe cumplir con la 1NF y además cada atributo que no sea UID debe ser completamente dependiente del primary key (UID). • Cada atributo que no es UID (non-key) debe estar definido por el UID por completo, no solo parte del UID (cuando es compuesto). • No debe haber dependencias funcionales parciales
NORMALIZACIÓN-2NF - Ejemplo A Figure 5-27 Functional dependency diagram for INVOICE Order_ID Order_Date, Customer_ID, Customer_Name, Customer_Address Customer_ID Customer_Name, Customer_Address Product_ID Product_Description, Product_Finish, Unit_Price Order_ID, Product_ID Order_Quantity Therefore, NOT in 2nd Normal Form PAG. 216
Figure 5-28 Removing partial dependencies Getting it into Second Normal Form Partial dependencies are removed, but there are still transitive dependencies PAG. 218
EJEMPLO - B - 2NF ¿Cumple esta relación con la 2NF? SUCURSAL #* número * nombre CUENTA #* número * balance * fecha apertura * dirección sucursal manejada por manejadora de
EJEMPLO - B - 2NF (Cont.) • Debe cotejar cada atributo y ver si tiene una relación directa con el primary key (UID). Haga este cotejo en ambas entidades. • En el caso del atributo dirección sucursal, nos percatamos de que pertenece a la entidad SUCURSAL y no a la entidad CUENTA
EJEMPLO - B - 2NF (Cont.) SOLUCIÓN Pasar el atributo fecha apertura a la entidad SUCURSAL. SUCURSAL #* número * nombre * dirección sucursal CUENTA #* número * balance * fecha apertura manejada por manejadora de
NORMALIZACIÓN - SOLUCIÓN 2NF • SOLUCIÓN: Si un atributo no depende del UID completo de la entidad, está mal localizado y debe mudarse a otra entidad.
NORMALIZACIÓN - Tercera forma normal 3NF • Regla: No puede haber un atributo que no sea UID dependiendo de otro atributo que no pueda servir como UID alterno. • Debemos cotejar que no haya un atributo que dependa de otro que no pueda ser UID alterno. PAG. 218
NORMALIZACIÓN - Third Normal Form • Debe estar en 2NF y además no debe tener dependencias transitivas (dependencias funcionales o atributos que no son primary-key) • Nota: Se llama transitivo debido a que el primary key es un determinante para otro atributo, el cual a su vez es un determinante de un tercero. • Solución: un determinante Non-key con dependencias transitivas va a una nueva tabla. Los determinantes non-keys vienen a ser primary key en la nueva tabla y se quedan con foreign key en la vieja tabla.
NORMALIZACIÓN-3NF - Ejemplo A Getting it into Third Normal Form Figure 5-28 Removing partial dependencies Transitive dependencies are removed PASOS: 1. Por cada atributo non-key que es determinante en una relación, crear una nueva relación utilizando ese atributo como el primary key de la relación. 2. Mover todos los atributos que son completamente dependientes de ese atributo a su nueva entidad. 3. Dejar el atributo que sirve ahora como el PK de la nueva relación, como un foreignkey de la relación anterior. PAG. 219
EJEMPLO - B - 3NF ¿Hay algún atributo que no sea UID dependiendo de otro que no pueda servir como UID alterno en la entidad ORDEN? ORDEN #* número * fecha * id_cliente * nombre_cliente * dirección_cliente
EJEMPLO - B - 3NF (Cont.) • Los atributos nombre_cliente y dirección_cliente dependen del atributo id_cliente. • id_cliente no es un UID alterno de la entidad ORDEN • Por lo tanto, se debe crear una entidad aparte llamada CLIENTE en la cual se ubican los atributos relacionados al cliente.
EJEMPLO - B - 3NF (Cont.) SOLUCIÓN Pasar los atributos del cliente a la entidad CLIENTE. CLIENTE #* id * nombre * dirección ORDEN #* número * fecha para originador de
NORMALIZACIÓN - SOLUCIÓN 3NF • SOLUCIÓN: Si un atributo no depende del UID completo de la entidad, está mal localizado y debe mudarse a otra entidad.
EJEMPLOS DE NORMALIZACIÓN • Los dos ejemplos a continuación le puede dar ideas al estudiante sobre los procesos de normalización. • Fueron preparados por el profesor Alberto Prado de la Interamericana metro • Estos ejemplos son solo para referencias del curso
RELACIONES RECURSIVAS Volver a los Objetivos
RELACIONES RECURSIVAS • Una relación recursiva es una relación entre una entidad y ella misma. bajo la jefatura de jefe de
progenitor de hijo de EJEMPLO DE UNA RELACIÓN RECURSIVA M:M • ¿Cómo podemos resolver esta relación recursiva M:M?
EJEMPLO DE UNA RELACIÓN RECURSIVA M:M - 2 SOLUCIÓN progenitor de con con hijo de
parte de compuesto de RELACIONES RECURSIVAS M:M (Cont.) • Las relaciones recursivas M:M se tienen que resolver también. • Por ejemplo, un abanico de una pc está compuesta de tornillos y a su vez la pc está compuesta de abanicos.