SICI-4030 Base de Datos

1. SICI-4030Base de Datos Prof. Nelliud D. Torres Data Modeling - Avanzado

2. OBJETIVOS • Normalización • Relaciones recursivas M:M • Roles • Subtipos y supertipos • Entity Clusters • Relaciones excluyentes • Modelando datos históricos

3. NORMALIZACIÓN Volver a los Objetivos

4. 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

5. 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

6. 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.

7. 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

8. 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

9. 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.

10. 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

11. Figure 5.22 Steps in normalization OJO  El libro menciona por lo menos 6 formas de normalización PAG. 212

12. 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

13. NORMALIZACIÓN-1NF - Ejemplo A Table with multivalued attributes, not in 1st normal form PAG. 215

14. 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

15. 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

16. 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

17. 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.

18. 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

19. 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

20. 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

21. 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

22. 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

23. Figure 5-28 Removing partial dependencies Getting it into Second Normal Form Partial dependencies are removed, but there are still transitive dependencies PAG. 218

24. 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

25. 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

26. 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

27. 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.

28. 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

29. 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.

30. 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

31. 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

32. 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.

33. 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

34. 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.

35. 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

36. EJEMPLO - 1 - A

37. EJEMPLO - 1 - B

38. EJEMPLO - 1 - C

39. EJEMPLO - 2 - A

40. EJEMPLO - 2 - B

41. EJEMPLO - 2 - C

42. EJEMPLO - 2 - D

43. EJEMPLO - 2 - E

44. EJEMPLO - 2 - F

45. EJEMPLO - 2 - G

46. RELACIONES RECURSIVAS Volver a los Objetivos

47. RELACIONES RECURSIVAS • Una relación recursiva es una relación entre una entidad y ella misma. bajo la jefatura de jefe de

48. progenitor de hijo de EJEMPLO DE UNA RELACIÓN RECURSIVA M:M • ¿Cómo podemos resolver esta relación recursiva M:M?

49. EJEMPLO DE UNA RELACIÓN RECURSIVA M:M - 2 SOLUCIÓN progenitor de con con hijo de

50. 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.