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

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

Examine Cuidadosamente Esta Tabla

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 - REGLASLas 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 - 2El 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 fact es 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

Table with multivalued attributes, not in 1st normal form

NORMALIZACIÓN-1NF - Ejemplo A

PAG. 215

Table with no multivalued attributes and unique rows, in 1st normal form

Note: this is relation, but not a well-structured one

PAG. 216

Repeating groups que deben ser eliminados para cumplir con la primera forma normal

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

CLIENTE

#* código* nombre* dirección* teléfono_casa

CONTACTO

#* fecha de contactoo lugar* resultado

de

el sujeto de

NORMALIZACIÓN - SOLUCIÓN - 1NF1NF

• 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

Order_ID Order_Date, Customer_ID, Customer_Name, Customer_Address

Therefore, NOT in 2nd Normal Form

Customer_ID Customer_Name, Customer_Address

Product_ID Product_Description, Product_Finish, Unit_Price

Order_ID, Product_ID Order_Quantity

Figure 5-27 Functional dependency diagram for INVOICE

PAG. 216

NORMALIZACIÓN-2NF - Ejemplo A

Partial dependencies are removed, but there are still transitive dependencies

Getting it into Getting it into Second Normal Second Normal FormForm

Figure 5-28 Removing partial dependencies

PAG. 218

EJEMPLO - B - 2NF

¿Cumple esta relación con la 2NF?

CUENTA

#* número* balance* fecha apertura* dirección sucursal

SUCURSAL

#* número* nombre

manejadora de

manejada por

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.

CUENTA

#* número* balance* fecha apertura

SUCURSAL

#* número* nombre* dirección sucursalmanejadora de

manejada por

NORMALIZACIÓN - SOLUCIÓN2NF

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

Transitive dependencies are removed

Figure 5-28 Removing partial dependencies

Getting it into Getting it into Third Normal Third Normal FormForm

PAG. 219

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 foreign key de la relación anterior.

NORMALIZACIÓN-3NF - Ejemplo A

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ónoriginador de

paraORDEN

#* número* fecha

NORMALIZACIÓN - SOLUCIÓN3NF

• 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

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 relación recursiva es una relación entre una entidad y ella misma.

bajo la jefatura de

jefe de

EMPLEADO

#* código* nombre* fecha contratado* salarioo comisión

EJEMPLO DE UNA RELACIÓN RECURSIVA M:M

• ¿Cómo podemos resolver esta relación recursiva M:M?

progenitor de

hijo de

PERSONA

#* seguro_social* nombre

EJEMPLO DE UNA RELACIÓN RECURSIVA M:M - 2

SOLUCIÓN

PERSONA

#* seguro_social* nombre

PARENTESCO

progenitor de

hijo de con

con

RELACIONES RECURSIVAS M:M (Cont.)

• Las relaciones recursivas M:M se tienen que resolver también.

COMPONENTE

#* id

compuesto de

parte 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 relación se puede resolver de la siguiente manera.

compuesto de

parte de

ENSAMBLAJE

o cantidad

COMPONENTE

#* id

para para

RELACIONES RECURSIVAS M:M (Asig.)

Asignación

¿Cómo se puede mejorar este diseño utilizando relaciones recursivas?

AREA

#* codigo* nombre

VENDEDOR

#* id* nombre* cuota

MUNICIPIO

#* codigo* nombre

GERENTE

#* id* nombre

REGION

#* CODIGO* nombre

DIRECTOR

#* id* nombre

atendido por

a cargo de

compuesto por

en

en

compuesto por

atendido por

atendido por

a cargo de

a cargo de

RELACIONES RECURSIVAS M:M (Asig. - Solución)

ROLES

Volver a los

Objetivos

ROLES

• Son entidades que representan papeles diferentes de una misma instancia.

• A continuación vamos a ver un ejemplo de entidades de un proceso de matrícula

• En este caso tanto la entidad ESTUDIANTE como la entidad INSTRUCTOR tienen los mismos atributos

• Este es un buen ejemplo de Roles ya que serían papeles diferentes (estudiante/profesor) como instancias de una sola entidad

ROLES - Cont. - 1

MATRÍCULA

* fecha matriculadoo fecha completadoo nota

ESTUDIANTE

#* id* nombreo teléfono

CURSO

#* código* nombreo duracióno costo

INSTRUCTOR

#* id* nombreo teléfono

parte de

para

para

parte de

enseñado por

el maestro

de

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 más de un papel.

• La solución sería crear una nueva entidad tal vez llamada PERSONA que una las instancias de ESTUDIANTE y de PROFESOR

ROLES - Cont. - 3 (Solución)MATRÍCULA

* fecha matriculadoo fecha completadoo nota

CURSO

#* código* nombreo duracióno costo

PERSONA

#* id* nombreo teléfono

parte de

para

para

parte de

enseñado por

el maestro

de

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 genérico que tiene una relación 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 también una instancia

del supertipo.

Figure 4-1 Basic notation for supertype/subtype notation

a) EER notation

EJEMPLO DE LA NOTACIÓN DE LOS SUBTIPOS DEL LIBRO - 1

PAG. 141

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

b) Microsoft

Visio Notation

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

EJEMPLO DE LA NOTACIÓN DE LOS SUBTIPOS DEL LIBRO - 2

PAG. 142

Figure 4-2 Employee supertype with three subtypes

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

Each employee subtype will also have its own attributes

EJEMPLO DE LA NOTACIÓN DE LOS SUBTIPOS DEL LIBRO - 3

PAG. 143

MODELANDO SUBTIPOS (EJ. EN NUESTRA NOTACIÓN)

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

MODELANDO SUBTIPOS (SOLUCIÓN)

EMPLEADO#* número* nombre

EXENTO* salario

NO_EXENTO* hora regular* hora extra

DEPARTAMENTO#* id* nombre

UNION#* id* nombre

compuesto por compuesto por

miembro deasignado a

Supertipo

SuptipoSuptipo

Relaciones y Subtipos

• Relaciones a nivel de supertype indica que todos los subtipos van a participar en la relación

• Las instancias de un subtype pueden participar en una relación única a ese subtipo. En esta situación, la relación se muestra a nivel de subtipo.

SUBTIPOS DE SUBTIPOS

Un subtipo se puede descomponer en otros subtipos

AEROVEHÍCULO

AVIÓN PROPULSADO

HÉLICE

CHORROPLANEADOR

HELICÓPTERO GLOBO OTRO

Generalization and Specialization

• Generalization: El proceso de definir un tipo de entidad más general de un conjunto de tipos de entidades más especializados.

• Specialization: El proceso de definir uno o más subtipos del supertipo y formar una relación supertipo/subtipo TOP-DOWN.

Figure 4-4 Example of generalization

a) Three entity types: CAR, TRUCK, and MOTORCYCLE

All these types of vehicles have common attributes

EJEMPLO DE TRES TIPOS DE ENTIDADES QUE TIENEN ATRIBUTOS COMUNES

PAG. 145

Figure 4-4 Example of generalization (cont.)

So we put the shared attributes in a supertype

Note: no subtype for motorcycle, since it has no unique attributes

b) Generalization to VEHICLE supertype

COMO SE PODRÍAN REPRESENTAR ESOS TRES TIPOS DE ENTIDADES QUE TIENEN ATRIBUTOS COMUNES

PAG. 145

Figure 4-5 Example of specialization

a) Entity type PART

Only applies to manufactured parts

Applies only to purchased parts

EJEMPLO DE ESPECIALIZACIÓN

PAG. 147

b) Specialization to MANUFACTURED PART and PURCHASED PART

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

Created 2 subtypes

Figure 4-5 Example of specialization (cont.)

EJEMPLO DE ESPECIALIZACIÓN (Cont.)

PAG. 147

ENTITY CLUSTER

Volver a los

Objetivos

Entity Clusters

• Los ERD son difíciles de leer cuando existen demasiadas entidades y relaciones.

• Solución: Agrupar entidades y relaciones en entity clusters

• Entity cluster: Conjunto de uno o más tipos de entidades y relaciones asociadas, agrupadas en un tipo sencillo de entidad abstracto

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

Related groups of entities could become clusters

ERD DIFÍCIL DE LEER

PAG. 156

Figure 4-13b EER diagram of PVF entity clusters

More readable, isn’t it?

ERD CONVERTIDO EN CLUSTER

PAG. 159

Figure 4-14 Manufacturing entity cluster

Detail for a single cluster

CLUSTER DE LA PARTE DE MANUFACTURA

PAG. 159

Packaged data models provide generic models that can be customized for a particular organization’s business rules

CLUSTER GENÉRICO

PAG. 162

RELACIONES EXCLUYENTES

Volver a los

Objetivos

RELACIONES EXCLUYENTES

• Ocurren cuando una entidad tiene relación 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 relación excluyente

RELACIONES EXCLUYENTES (cont.)

CUENTA_BANCARIA

PERSONA

COMPAÑÍA

dueña deposeída por

dueña de

poseída por

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 múltiples arcos, pero una relación específica puede participar solamente en un solo arco.

MODELANDO DATOS HISTÓRICOS

Volver a los

Objetivos

MODELANDO DATOS HISTÓRICOS

• Añada entidades adicionales al diagrama ER para poder acomodar datos a través del tiempo

• Se debe preguntar al usuario:– ¿Se necesitan los datos históricos para los

auditores?– ¿Pueden cambiar los valores de los atributos

a través del tiempo? Por ejemplo el precio– ¿Se necesita sacar información de datos

pasados?

MODELANDO DATOS HISTÓRICOS (cont.)

¿Cómo podemos alterar este diseño de modo que pueda almacenar un historial de empleo?

PERSONA

#* id* nombre

PUESTO

#* código* descripción

COMPAÑÍA

#* código* nombre

poseedora de

incluidoen

ocupadora de

ocupado por

empleadora de

empleado por

MODELANDO DATOS HISTÓRICOS (cont.)

• Este diagrama muestra una relación 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 posición o en cuales fechas el empleado ha cambiado de compañías.•La solución al diseño es:

PERSONA

#* id* nombre

PUESTO

#* código* descripción

COMPAÑÍA

#* código* nombre

HISTORIAL_EMPLEO

#* fecha_desde* fecha_hasta

MODELANDO DATOS HISTÓRICOS SOLUCIÓN

incluidaen

para para

incluido enpara

incluidoen

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