SICI-4030 Base de Datos

Prof. Nelliud D. Torres Data Modeling - Avanzado

OBJETIVOS
Normalizacin Relaciones recursivas M:M Roles Subtipos y supertipos Entity Clusters Relaciones excluyentes Modelando datos histricos

NORMALIZACIN

Volver a los Objetivos

NORMALIZACIN
DEFINICIN - Es una herramienta para validar y mejorar un diseo lgico de modo tal que satisfaga ciertas limitaciones (constraints). Debe evitar duplicacin innecesaria de los datos. Es un proceso de descomponer relaciones con anomalas para producir relaciones pequeas 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 diseo normalizado de una base de PAG. 211 datos automticamente.

NORMALIZACIN - METAS (goals)

Algunas metas que buscamos al normalizar son:
Minimizar la redundancia de datos y por lo tanto, evitar las anomalas y conservar espacio de almacenamiento. Simplificar las limitaciones (constraints) que fuerzan la referencia de integridad. Que sea fcil mantener los datos (insertar, actualizar y eliminar). Proveer un mejor diseo el cual es una representacin mejorada del mundo real y con bases slidas para permitir un futuro crecimiento. Sin embargo la normalizacin crea lentitud al acceder los datos (vase Data Warehouse)
PAG. 211

 Son relaciones que contienen una redundancia de datos mnimos y permite a los usuarios insertar, eliminar y actualizar filas sin causar inconsistencia de los datos. La meta es evitar anomalas, las cuales son:
Insertion Anomaly Aadir nuevas filas que fuerzen al usuario a crear datos duplicados. Deletion Anomaly Eliminar filas que pudieran causar una perdida de datos que fuesen necesrios para otras filas futuras. Modification Anomaly Cambiar datos en una fila que fuerze cambios en otras filas debido a duplicacin.

NORMALIZACIN - Relaciones Bien Estructuradas

Examine Cuidadosamente Esta Tabla

QuestionIs this a relation?

AnswerYes: Unique rows and no multivalued attributes AnswerComposite: Emp_ID, Course_Title

QuestionWhats the primary key?

ExampleFigure 5-2b
PAG. 190

Anomalas 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 informacin sobre la existencia de un curso titulado: Tax Acc Modification Al drsele un aumento de salario al empleado 100, nos fuerza a actualizar mltiples 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

NORMALIZACIN - REGLAS
Las primeras tres reglas de normalizacin 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.

NORMALIZACIN - REGLAS - 2
El libro menciona seis reglas de normalizacn 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 anomalas sobrantes que resultan de los mltiples candidatos a key. 4NF (Cuarta forma normal) - Remover dependencias con multivalores. 5NF (Quinta forma normal) - Remover anomalas que hayan quedado.
PAG. 211

Rara vez utilizamos ms de las primeras 3 formas al normalizar.

Figure 5.22 Steps in normalization

OJO El libro menciona por lo menos 6 formas de normalizacin

PAG. 212

NORMALIZACIN - 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. Adems:
No deben existir grupos repetitivos (repeating groups) en la relacin (un single fact es la interseccin de cada fila y columna de la tabla) Un PK debe estar definido, el cual identifica nicamente cada fila en la relacin.

Veamos los siguientes ejemplos:

PAG. 214

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

Anomalas 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 duplicacin. Deletion Si eliminamos el Dining Table de la orden 1006, perdemos informacin relacionada a ese tem en trminos de las terminaciones (finish) y del precio. Update Cambiar el precio del producto con ID 4, requiere la actualizacin de varios rcords.

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?
CLIENTE #* cdigo * nombre * direccin * fecha_contacto * telfono_casa

Todos los atributos cumplen con la condicin de no tener mltiples valores?

EJEMPLO - B - 1NF (Cont.)

El atributo fecha_contacto puede tener ms de un valor ya que uno puede contactar a un cliente en ms de una ocasin. Por lo tanto el atributo fecha_contacto tiene mltiples valores (aunque slo puede almacenar la ltima fecha de contacto) Solucin: Crear una entidad adicional llamada CONTACTO que permita almacenar todos los contactos que se tengan con el cliente.

EJEMPLO - B - 1NF (Cont.)

SOLUCIN

CLIENTE
#* cdigo * nombre * direccin * telfono_casa

de

CONTACTO
#* fecha de contacto o lugar * resultado

el sujeto de

NORMALIZACIN - SOLUCIN - 1NF

1NF SOLUCIN: Si un atributo tiene mltiples valores, cree una entidad adicional y relacinela con la entidad original usando una relacin M:1

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

NORMALIZACIN - Second Normal Form

Debe cumplir con la 1NF y adems 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

NORMALIZACIN-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 relacin con la 2NF?

CUENTA
#* nmero * balance * fecha apertura * direccin sucursal

manejada por

SUCURSAL
#* nmero * nombre

manejadora de

EJEMPLO - B - 2NF (Cont.)

Debe cotejar cada atributo y ver si tiene una relacin directa con el primary key (UID). Haga este cotejo en ambas entidades. En el caso del atributo direccin sucursal, nos percatamos de que pertenece a la entidad SUCURSAL y no a la entidad CUENTA

EJEMPLO - B - 2NF (Cont.)

SOLUCIN

CUENTA
#* nmero * balance * fecha apertura

manejada por

SUCURSAL
#* nmero * nombre * direccin sucursal

manejadora de

Pasar el atributo fecha apertura a la entidad SUCURSAL.

NORMALIZACIN - SOLUCIN
2NF SOLUCIN: Si un atributo no depende del UID completo de la entidad, est mal localizado y debe mudarse a otra entidad.

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

NORMALIZACIN - Third Normal Form

Debe estar en 2NF y adems 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. Solucin: 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.

NORMALIZACIN -3NF - Ejemplo A

Getting it into Third Normal Form

PASOS: Transitive dependencies are removed 1. Por cada atributo non-key que es determinante en una relacin, crear una nueva relacin utilizando ese atributo como el primary key de la relacin. 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 relacin, como un foreign key de la relacin anterior. PAG. 219

Figure 5-28 Removing partial dependencies

EJEMPLO - B - 3NF
Hay algn atributo que no sea UID dependiendo de otro que no pueda servir como UID alterno en la entidad ORDEN?

ORDEN

#* nmero * fecha * id_cliente * nombre_cliente * direccin_cliente

EJEMPLO - B - 3NF (Cont.)

Los atributos nombre_cliente y direccin_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.)

SOLUCIN

ORDEN #* nmero * fecha para

CLIENTE
#* id * nombre * direccin

originador de

Pasar los atributos del cliente a la entidad CLIENTE.

NORMALIZACIN - SOLUCIN
3NF SOLUCIN: Si un atributo no depende del UID completo de la entidad, est mal localizado y debe mudarse a otra entidad.

EJEMPLOS DE NORMALIZACIN
Los dos ejemplos a continuacin le puede dar ideas al estudiante sobre los procesos de normalizacin. Fueron preparados por el profesor Alberto Prado de la Interamericana metro Estos ejemplos son solo para referencias del curso

EJEMPLO - 1 - A

EJEMPLO - 1 - B

EJEMPLO - 1 - C

EJEMPLO - 2 - A

EJEMPLO - 2 - B

EJEMPLO - 2 - C

EJEMPLO - 2 - D

EJEMPLO - 2 - E

EJEMPLO - 2 - F

EJEMPLO - 2 - G

RELACIONES RECURSIVAS

Volver a los Objetivos

RELACIONES RECURSIVAS
Una relacin recursiva es una relacin entre una entidad y ella misma.
EMPLEADO #* cdigo * nombre * fecha contratado * salario o comisin
jefe de

bajo la jefatura de

EJEMPLO DE UNA RELACIN RECURSIVA M:M

Cmo podemos resolver esta relacin recursiva M:M?

PERSONA
progenitor de

#* seguro_social * nombre
hijo de

EJEMPLO DE UNA RELACIN RECURSIVA M:M - 2

SOLUCIN
PERSONA #* seguro_social * nombre
con hijo de con progenitor de

PARENTESCO

RELACIONES RECURSIVAS M:M (Cont.)

Las relaciones recursivas M:M se tienen que resolver tambin.
COMPONENTE #* id

parte de

compuesto de

Por ejemplo, un abanico de una pc est compuesta de tornillos y a su vez la pc est compuesta de abanicos.

RELACIONES RECURSIVAS M:M (Cont.-2)

Esta relacin se puede resolver de la siguiente manera.
ENSAMBLAJE o cantidad

para para

compuesto de
#* id

parte de

COMPONENTE

RELACIONES RECURSIVAS M:M (Asig.) atendido por

AREA VENDEDOR

Asignacin Cmo se puede mejorar este diseo utilizando relaciones recursivas?

#* codigo * nombre

a cargo de

#* id * nombre * cuota

en compuesto por
MUNICIPIO #* codigo * nombre

atendido por a cargo de

GERENTE #* id * nombre

en compuesto por
REGION #* CODIGO * nombre

atendido por a cargo de

DIRECTOR #* id * nombre

RELACIONES RECURSIVAS M:M (Asig. - Solucin)

ROLES

Volver a los Objetivos

ROLES
Son entidades que representan papeles diferentes de una misma instancia. A continuacin vamos a ver un ejemplo de entidades de un proceso de matrcula En este caso tanto la entidad ESTUDIANTE como la entidad INSTRUCTOR tienen los mismos atributos Este es un buen ejemplo de Roles ya que seran papeles diferentes (estudiante/profesor) como instancias de una sola entidad

ROLES - Cont. - 1
MATRCULA * fecha matriculado o fecha completado o nota

para parte de

CURSO #* cdigo * nombre o duracin o costo

para enseado por el maestro de

INSTRUCTOR #* id * nombre o telfono

parte de
ESTUDIANTE #* id * nombre o telfono

atributos comunes con la entidad ESTUDIANTE

ROLES - Cont. - 2
En este caso las relaciones entre entidades permiten que una sola instancia de una entidad asuma ms de un papel. La solucin sera crear una nueva entidad tal vez llamada PERSONA que una las instancias de ESTUDIANTE y de PROFESOR

ROLES - Cont. - 3 (Solucin)

MATRCULA * fecha matriculado o fecha completado o nota

para

CURSO #* cdigo * nombre parte de o duracin o costo

para enseado por el maestro de

PERSONA

parte de

#* id * nombre o telfono

SUBTIPOS y SUPERTIPOS

Volver a los Objetivos

SUBTIPOS y SUPERTIPOS
Subtype: Es un subgrupo de entidades bajo un tipo
de entidad que tiene atributos diferentes de los otros subgrupos. Son entidades mutuamente exclusivos, los cuales tienen atributos y relaciones comunes.

Supertype: Un tipo de entidad genrico que tiene

una relacin con uno o mas subtipos (subtype).

Attribute Inheritance:
Las entidades subtipo adquieren (inheritance) valores de todos los atributos del supertipo. Una instancia de un subtipo es tambin una instancia del supertipo.

EJEMPLO DE LA NOTACIN DE LOS SUBTIPOS DEL LIBRO - 1

a) EER notation

Figure 4-1 Basic notation for supertype/subtype notation

PAG. 141

EJEMPLO DE LA NOTACIN DE LOS SUBTIPOS DEL LIBRO - 2

b) Microsoft Visio Notation

Different modeling tools may have different notation for the same modeling constructs

Figure 4-1 Basic notation for supertype/subtype notation (cont.)

PAG. 142

EJEMPLO DE LA NOTACIN DE LOS SUBTIPOS DEL LIBRO - 3

All employee subtypes will have emp nbr, name, address, and date-hired

Each employee subtype will also have its own attributes

Figure 4-2 Employee supertype with three subtypes

PAG. 143

MODELANDO SUBTIPOS (EJ. EN NUESTRA NOTACIN)

Una empresa ha definido dos tipos de empleados: exentos y no exentos. Para todos los empleados hay que guardar su nmero, nombre y departamento. En adicin, los exentos necesitan almacenar el atributo salario y los no exentos la paga por hora (regular y extra) y si pertenece a una unin.

MODELANDO SUBTIPOS (SOLUCIN)

EMPLEADO #* nmero * nombre EXENTO * salario NO_EXENTO * hora regular * hora extra miembro de

Supertipo

Suptipo

asignado a

Suptipo

compuesto por DEPARTAMENTO #* id * nombre

compuesto por
UNION #* id * nombre

Relaciones y Subtipos
Relaciones a nivel de supertype indica que todos los subtipos van a participar en la relacin Las instancias de un subtype pueden participar en una relacin nica a ese subtipo. En esta situacin, la relacin se muestra a nivel de subtipo.

SUBTIPOS DE SUBTIPOS
Un subtipo se puede descomponer en otros subtipos
AEROVEHCULO AVIN PROPULSADO HLICE PLANEADOR CHORRO

HELICPTERO

GLOBO

OTRO

Generalization and Specialization

Generalization: El proceso de definir un
tipo de entidad ms general de un conjunto de tipos de entidades ms especializados.

Specialization: El proceso de definir

uno o ms subtipos del supertipo y formar una relacin supertipo/subtipo TOPDOWN.

EJEMPLO DE TRES TIPOS DE ENTIDADES QUE TIENEN ATRIBUTOS COMUNES a) Three entity types: CAR, TRUCK, and MOTORCYCLE

All these types of vehicles have common attributes Figure 4-4 Example of generalization
PAG. 145

COMO SE PODRAN REPRESENTAR ESOS TRES TIPOS DE ENTIDADES QUE TIENEN ATRIBUTOS COMUNES b) Generalization to VEHICLE supertype

So we put the shared attributes in a supertype

Note: no subtype for motorcycle, since it has no unique attributes PAG. 145 Figure 4-4 Example of generalization (cont.)

EJEMPLO DE ESPECIALIZACIN

a) Entity type PART

Only applies to manufactured parts

Applies only to purchased parts

Figure 4-5 Example of specialization

PAG. 147

EJEMPLO DE ESPECIALIZACIN (Cont.)

b) Specialization to MANUFACTURED PART and PURCHASED PART

Created 2 subtypes

Note: multivalued attribute was replaced by an associative entity relationship to another entity

Figure 4-5 Example of specialization (cont.)

PAG. 147

ENTITY CLUSTER

Volver a los Objetivos

Entity Clusters
Los ERD son difciles de leer cuando existen demasiadas entidades y relaciones. Solucin: Agrupar entidades y relaciones en entity clusters Entity cluster: Conjunto de uno o ms tipos de entidades y relaciones asociadas, agrupadas en un tipo sencillo de entidad abstracto

ERD DIFCIL DE LEER

Figure 4-13a
Possible entity clusters for Pine Valley Furniture in Microsoft Visio

Related groups of entities could become clusters

PAG. 156

ERD CONVERTIDO EN CLUSTER Figure 4-13b EER diagram of PVF entity clusters

More readable, isnt it?

PAG. 159

CLUSTER DE LA PARTE DE MANUFACTURA Figure 4-14 Manufacturing entity cluster

Detail for a single cluster

PAG. 159

CLUSTER GENRICO

Packaged data models provide generic models that can be customized for a particular organizations business rules

PAG. 162

RELACIONES EXCLUYENTES

Volver a los Objetivos

RELACIONES EXCLUYENTES
Ocurren cuando una entidad tiene relacin con otras dos relaciones en donde tiene que seleccionar una sola de ellas para una instancia en particular Se representa con un arco que incluya ambas relaciones Los nombres de relaciones deben ser los mismos en ambas entidades excluyentes Diagrama con un ejemplo de relacin excluyente

RELACIONES EXCLUYENTES (cont.)

PERSONA
poseda por duea de

CUENTA_BANCARIA

duea de

poseda por

COMPAA

RELACIONES EXCLUYENTES (cont.)

Las relaciones en un arco tienen que ser todas mandatorias u opcionales Un arco pertenece a una sola entidad y solo debe incluir relaciones que se originen de esa entidad Una entidad puede tener mltiples arcos, pero una relacin especfica puede participar solamente en un solo arco.

MODELANDO DATOS HISTRICOS

Volver a los Objetivos

MODELANDO DATOS HISTRICOS

Aada entidades adicionales al diagrama ER para poder acomodar datos a travs del tiempo Se debe preguntar al usuario:
Se necesitan los datos histricos para los auditores? Pueden cambiar los valores de los atributos a travs del tiempo? Por ejemplo el precio Se necesita sacar informacin de datos pasados?

MODELANDO DATOS HISTRICOS (cont.)

Cmo podemos alterar este diseo de modo que pueda almacenar un historial de empleo?
PERSONA #* id * nombre

ocupadora de ocupado por

PUESTO #* cdigo * descripcin

empleado por

incluido en

empleadora de COMPAA
#* cdigo * nombre

poseedora de

MODELANDO DATOS HISTRICOS (cont.)

Este diagrama muestra una relacin de muchos a muchos entre tres entidades. Esto se conoce como relaciones complejas. Aunque se rompan las relaciones M:M, no se puede llevar un seguimiento de eventos por fechas. Por ejemplo, no se puede saber en cuales fechas un empleado ha cambiado de posicin o en cuales fechas el empleado ha cambiado de compaas. La solucin al diseo es:

MODELANDO DATOS HISTRICOS SOLUCIN

para
HISTORIAL_EMPLEO #* fecha_desde * fecha_hasta

para incluido en

PUESTO #* cdigo * descripcin

para incluido en
PERSONA #* id * nombre

incluida en COMPAA
#* cdigo * nombre

Este formato es uno tipo estrella y es el que se utiliza para crear los Data Warehouses

REFERENCIAS
Modern Database Management 8th Edition, Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden Database Systems: Design, Implementation, and Management, Seventh Edition, Rob and Coronel

Profesor Alberto Prado - Universidad Interamericana, Recintro Metro