Capítulo 3 El modelo relacional y normalizaciónricardogzzl.000webhostapp.com/Cap3Rel.pdf · •...

Post on 25-Jul-2020

3 views 0 download

Transcript of Capítulo 3 El modelo relacional y normalizaciónricardogzzl.000webhostapp.com/Cap3Rel.pdf · •...

Procesamiento de base de datos:

Fundamentos, Deseño e Implementación

Capítulo 3

El modelo relacional y

normalización

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-1

Objetivos

• Comprender la terminología básica relacional.

• Conocer las características de las relaciones.

• Entender la terminología alterna utilizada para describir

el modelo relacional.

• Identificar dependencias funcionales, determinantes y

atributos dependientes.

• Identificar la clave primaria, candidato y claves

compuestas.

• Identificar la posible inserción, eliminación y

actualización de anomalías en una relación.

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-2

Objetivos

• Colocar a una relación en forma normal de BCNF.

• Comprender la importancia especial de la forma normal

de dominio/clave.

• Identificar las dependencias multivalor.

• Colocar a una relación en la cuarta forma normal.

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall 3-3

Premisas del capítulo

• Hemos recibido una o más tablas de datos

existentes.

• Los datos son almacenados en una base

de datos nueva.

• PREGUNTA: ¿Los datos son

alamacenados como recibidos , o deben

ser transformados para su

almacenamiento?

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-4

¿Cuántas tablas observa?

Deberíamos almacenar estas tablas como son, o debemos nosotros

combinarlas en una tabla en nuestra base de datos nueva?

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-5

Primero debemos—

• Entender:

– El modelo relacional

– Terminología del modelo relacional

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-6

Modelo relacional

• Introducido en 1970

• Creado por E.F. Codd

– Ingeniero de IBM

– El modelo utiliza las matemáticas conocida

como: ―algebra relacional‖

• Ahora el modelo estándar para los

productos comerciales de DBMS.

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-7

Términos importantes del modelo

relacional• Entity

• Relation

• Functional dependency

• Determinant

• Candidate key

• Composite key

• Primary key

• Surrogate key

• Foreign key

• Referential integrity constraint

• Normal form

• Multivalued dependency

• Entidad

• Relación

• Dependencia funcional

• Determinante

• Clave candidata

• Clave compuesta

• Clave primaria

• Clave sustituta

• Clave foránea

• Restricción de integridad

referencial

• Forma normal

• Dependencia multivalor

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition ©

2010 Pearson Prentice Hall

3-8

Entidad-‖Entity‖

• Una entidad es algo identificable que los

usuarios desean realizar dar seguimiento:– Clientes

– Computadoras

– Ventas

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-9

Relación-―Relation‖

• Los productos de DBMS relacionales almacenan datos acerca de las entidades en las relaciones, que son un tipo especial de tabla.

• Una relación es una tabla bidimensional que tiene las siguientes

características:

– Las filas contienen datos acerca de una entidad.

– Las columnas contienen datos acerca de los atributos de la entidad.

– Todas las entradas de una columna son del mismo tipo.

– Cada columna tiene un nombre único.

– Las celdas de la tabla mantienen un único valor.

– El orden de las columnas no es importante.

– El orden de las filas no tiene importancia.

– Ninguna de las dos filas puede ser idéntica..

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-10

Una relación

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-11

Las tablas que no relacionales:

―Multiple Entries per Cell‖

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-12

Tablas que no son relacionales:

―Table with Required Row Order‖

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-13

Una relación con valores de

longitud de variables

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-14

Terminología de alterna

• Aunque no todas las tablas son relacionales, la tabla de términos y la relación normalmente se utilizan indistintamente.

• Los siguientes conjuntos de términos son equivalente:

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition ©

2010 Pearson Prentice Hall

3-15

Dependencia Funcional

• Una dependencia funcional se produce cuando el valor

de un atributos (conjunto de atributos) determina el valor

de un segundo (conjunto de) atributo(s):

StudentID StudentName

StudentID (DormName, DormRoom, Fee)

• El atributo en el lado izquierdo de la dependencia

funcional se llama el determinante.

• La dependencias pueden estar basadas en ecuaciones:

ExtendedPrice = Quantity X UnitPrice

(Quantity, UnitPrice) ExtendedPrice

• Las dependencias de la función no son ecuaciones!

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-16

Las dependencias de la función no son

ecuaciones

ObjectColor Weight

ObjectColor Shape

ObjectColor (Weight, Shape)

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-17

Factores determinantes de la composición

―Composite Determinants‖

• Composite determinant = un factor

determinante de una dependencia

funcional que consiste en más de un

atributo.

(StudentName, ClassName) (Grade)

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-18

Reglas de dependencia

funcional

• If A (B, C), then A B and A C.

• If (A,B) C, then neither A nor B

determines C by itself.

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-19

Dependencias funcionales en la

tabla de SKU_DATA

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-20

Dependencias funcionales en la

tabla de SKU_DATA

SKU (SKU_Description, Department, Buyer)

SKU_Description (SKU, Department, Buyer)

Buyer Department

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-21

Dependencias funcionales en la

tabla de ORDER_ITEM

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition ©

2010 Pearson Prentice Hall

3-22

Dependencias funcionales en la

tabla de ORDER_ITEM

(OrderNumber, SKU)

(Quantity, Price, ExtendedPrice)

(Quantity, Price) (ExtendedPrice)

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-23

¿Qué hace los valores determinates únicos?

• Un factor determinante es único en una relación,

y sólo si, determina todas las columnas en la

relación.

• No se puede encontrar los factores

determinantes de todas las dependencias

funcionales simplemente mediante la búsqueda

de valores únicos en una columna:

– Limitaciones de conjunto de datos

– Debe ser lógicamente un factor determinante

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-24

Claves-‖Keys‖

• Una clave es una combinación de una o

más columnas que son utilizadas para

identificar filas en una relación

• Una clave compuesta es una clave que se

compone de dos o más columnas.

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-25

Clave candidata y

clave primaria • Una clave candidata es una clave que

determina todas las otras columnas en una relación.

• Una clave primaria es una clave de candidato seleccionada como el principal medio de identificación de filas en una relación– Hay sólo una clave primaria por relación.– La clave primaria puede ser una clave

compuesta.

– La clave primaria ideal es corto, numérica y

nunca cambia.

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-26

Clave de suplente

―Surrogate Keys‖• Una clave suplente es una columna

artificial agregada a una relación para

servir como una clave principal.

– Suministros de DBMS (DBMS supplied)

– Corto, numerica, y nunca cambio—es una

clave primaria ideal

– Tiene valores artificiales que no tienen

significaro para los usuarios.

– Normalmente está oculto en formularios e

informesKROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-27

Clave de suplente

―Surrogate Keys‖NOTA: La clave primaria de la relación se destaca a continuación:

• RENTAL_PROPERTY sin clave de suplente :

RENTAL_PROPERTY (Street, City,

State/Province, Zip/PostalCode, Country, Rental_Rate)

RENTAL_PROPERTY con clave de suplente :

RENTAL_PROPERTY (PropertyID, Street, City,

State/Province, Zip/PostalCode, Country, Rental_Rate)

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-28

Clave forénea

• Una clave foránea es la clave principal de

una relación que se coloca en otra

relación para formar un vínculo entre las

relaciones.

– Una clave foránea puede ser una sola

columna o una clave compuesta.

– The term refers to the fact that key values are

foreign to the relation in which they appear as

foreign key values .

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-29

Clave forénea

NOTA: En las relaciones a continuación la clave primaria

de estas están subrayadas y la clave foránea está en

cursiva:

DEPARTMENT (DepartmentName, BudgetCode, ManagerName)

EMPLOYEE (EmployeeNumber, EmployeeName, DepartmentName)

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-30

Las restricciones de integridad referencial

―Referential Integrity Constraint‖

• Una restricción de integridad referencial

es una declaración que limita los valores

de la clave forénea a las ya existentes

como los valores de clave primaria en la

relación correspondiente.

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-31

Clave foránea con una

―Referential Integrity Constraint‖

NOTA: En las relaciones a continuación la clave primaria

de la relación está subrayada y cualquier clave foránea

está en cursiv:

SKU_DATA (SKU, SKU_Description, Department, Buyer)

ORDER_ITEM (OrderNumber, SKU, Quantity, Price,

ExtendedPrice)

Where ORDER_ITEM.SKU must exist in SKU_DATA.SKU

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-32

Modificación Anomalias

• Anomalía de eliminación

• Anomalía de inserción

• Anomalía de actualización

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-33

Modificación Anomalias

• La tabla EQUIPMENT_REPAIR antes y después de una operación de actualización incorrecta sobre AcquisitionCost de Type = Drill Press

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition ©

2010 Pearson Prentice Hall

3-34

Forma Normal

• Las relaciones se clasifican como forma normal basado en qué modificación de anomalías u otros problemas que están sujetos a:

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition ©

2010 Pearson Prentice Hall

3-35

Forma Normal

• 1NF—una tabla que califica como una relación que seencuentra en primera forma normal-1NF.

• 2NF— una relación en segunda forma normal-2NF se dasi todos los atributos ―nonkey‖ son dependientes de todas las claves primarias.

• 3NF— una relación está en tercera forma normal-3NF siestá en 2NF y no tiene determinantes excepto la clave primaria.

• Boyce-Codd Normal Form (BCNF)—a relation is in BCNF- Si cada determinante es una clave de candidato

(if every determinant is a candidate key).

“I swear to construct my tables so that all nonkeycolumns are dependent on the key, the whole key and nothing but the key, so help me Codd.”KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-36

Eliminación de anomalías de modificación

de dependencias funcionales en relaciones:

Put All Relations into BCNF

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition ©

2010 Pearson Prentice Hall

3-37

Poniendo una relación en BCNF:

EQUIPMENT_REPAIR

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-38

Poniendo una relación en BCNF:

EQUIPMENT_REPAIREQUIPMENT_REPAIR (ItemNumber, Type, AcquisitionCost,

RepairNumber, RepairDate, RepairAmount)

ItemNumber (Type, AcquisitionCost)

RepairNumber (ItemNumber, Type, AcquisitionCost,

RepairDate, RepairAmount)

ITEM (ItemNumber, Type, AcquisitionCost)

REPAIR (ItemNumber, RepairNumber, RepairDate, RepairAmount)

Where REPAIR.ItemNumber must exist in

ITEM.ItemNumber

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-39

Poniendo una relación en BCNF:

New Relations

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-40

Poniendo una relación en BCNF:

SKU_DATA

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition ©

2010 Pearson Prentice Hall

3-41

Poniendo una relación en BCNF:

SKU_DATASKU_DATA (SKU, SKU_Description, Department, Buyer)

SKU (SKU_Description, Department, Buyer)

SKU_Description (SKU, Department, Buyer)

Buyer Department

SKU_DATA (SKU, SKU_Description, Buyer)

BUYER (Buyer, Department)

Where BUYER.Buyer must exist in SKU_DATA.Buyer

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-42

Poniendo una relación en BCNF:

New Relations

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-43

Dependencias de multivalor

―Multivalued Dependencies‖• Una dependencia multivalor se produce

cuando un determinante coincide con un

conjunto específico de valores:

Employee Degree

Employee Sibling

PartKit Part

• El determinante de una dependencia

multivalor nunca puede ser una clave

primaria.

• .KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-44

Dependencias de multivalor

―Multivalued Dependencies‖

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition ©

2010 Pearson Prentice Hall

3-45

Eliminación de anomalías de

dependencias multivalor

• Las dependencias multivalor no son un

problema si se encuentran en una relación

independiente, por lo tanto:

– Siempre poner las dependencias multivalor

en su propia relación.

– Esto se conoce como cuarta forma normal-

4NF-Fourth Normal Form (4NF).

KROENKE AND AUER - DATABASE PROCESSING, 11th Edition

© 2010 Pearson Prentice Hall

3-46