Kroenke10 ch03

David M.
Kroenkes
Database Processing:
Fundamentals, Design, and Implementation
Chapter Three: The Relational Model and Normalization

DAVID M. KROENKES DATABASE PROCESSING, 10th Edition 2006 Pearson Prentice Hall 3-1
Objetivos
Comprender terminologa relacional Comprender caractersticas de RELACIONES Comprender alternativas para describir el modelo relacional Identificar DEPENDENCIAS FUNCIONALES, DETERMINANTES y ATRIBUTOS DEPENDIENTES Identificar llaves candidato, primarias, compuestas, y surrogate
Objetivos
Identificar posibles anomalias de Insercin, Borrado, y Actualizacin en una Relacin Poner una relacin en la forma normal BCNF Comprender la importancia de la forma normal Dominio/Llave (DK) Identificar dependencias multivaluadas Poner una relacin en su 4ta forma normal
Chapter Premise
We have received one or more tables of existing data The data is to be stored in a new database QUESTION: Should the data be stored as received, or should it be transformed for storage?
DAVID M. KROENKES DATABASE PROCESSING, 10th Edition 2006 Pearson Prentice Hall
3-4
How Many Tables?
Should we store these two tables as they are, or should we combine them into one table in our new database?
But first Comprender:

El modelo relacional Terminologa del modelo relacional
3-6
The Relational Model

Introduced in 1970 Created by E.F. Codd
He was an IBM engineer The model used mathematics known as relational algebra
Now the standard model for commercial DBMS products
3-7
Important Relational Model Terms

Entity - Entidad Relation - Relacin Functional Dependency Dependencia funcional Determinant -determinante Candidate Key llave candidato Composite Key llave compuesta Primary Key llave primaria Surrogate Key llave Surrogate Foreign Key llave foranea Referential integrity constraint restriccin de Integridad Referencial Normal Form Forma Normal Multivalued Dependency Dependencia multivaluada
3-8
Entity - Entidad
An entity is some identifiable thing that users want to track:
Customers Computers Sales
3-9
Relation - Relacin
Relational DBMS products store data about entities in relations, which are a special type of table A relation is a two-dimensional table that has the following characteristics:
Rows contain data about an entity Columns contain data about attributes of the entity All entries in a column are of the same kind Each column has a unique name Cells of the table hold a single value The order of the columns is unimportant The order of the rows is unimportant No two rows may be identical
3-10
A Relation
EMPLOYEE
La relacin Employee cumple con todas las caractersticas que definen una relacion
3-11
Relation - Relacin
Una relacin es un caso especial de una tabla Todas las relaciones son tablas, pero no todas las tablas son relaciones
3-12
A Relation with Values of Varying Length
No caer en la trampa de pensar que dado que una celda debe tener valor nico Significa que todos los valores deben tener la misma longitud, al contrario, la relacion mostrada tiene en la columna Comment un solo comentario por celda aunque de longitud diferente entre s.
3-13
Tables That Are Not Relations: Multiple Entries per Cell
En esta tabla Caruthers y Bandalone tienen mltiples valores de Phone
3-14
Tables That Are Not Relations: Table with Required Row Order
Las entradas de Caruthers y Bandalone requieren un arreglo particular de renglones, si se reacomodan los renglones se sabra con precisin a quien corresponden los nmeros de fax y home
Relation - Relacin
Columnas en diferentes relaciones podran tener el mismo nombre, en ejemplos previos hemos visto que dos relaciones contienen una columna con el mismo nombre: SKU. Para evitar confusiones se antepone al nombre de una columna el nombre de la relacin seguida por un punto: SKU_DATA.SKU
3-16
Alternative Terminology
Although not all tables are relations, the terms table and relation are normally used interchangeably The following sets of terms are equivalent:
3-17
Functional Dependency
A functional dependency occurs when the value of one (a set of) attribute(s) determines the value of a second (set of) attribute(s):
StudentID StudentName StudentID (DormName, DormRoom, Fee)

The attribute on the left side of the functional dependency is called the determinant
Functional Dependency -Ejemplo

Si compramos cajas de galletas a $5 y queremos saber costo total de las galletas CookieCost = NumberOfBoxes x $5 Se dice entonces que el costo de galletas depende funcionalmente del nmero de cajas compradas NumberOfBoxes CookieCost
Functional dependencies may be based on equations: ExtendedPrice = Quantity X UnitPrice ExtendedPrice es funcionalmente dependiente de Quantity y de UnitPrice (Quantity, UnitPrice) ExtendedPrice
Functional Dependencies Are Not Equations

Se sabe que un saco contiene objetos color, peso y forma de acuerdo a la tabla La dependencia funcional existe aun cuando no se exprese como una ecuacin.
ObjectColor Weight ObjectColor Shape ObjectColor (Weight, Shape)

3-21
La nica razn para tener RELACIONES es guardar instancias de dependencias funcionales No existe una frmula para que a partir de tu matricula de estudiante se determine Nombre, Apellidos, Promedio
3-22
Composite Determinants
Composite determinant: A determinant of a functional dependency that consists of more than one attribute
(StudentName, ClassName) (Grade)
3-23
Functional Dependency Rules

If A (B, C), then A B and A C If (A,B) C, then neither A nor B determines C by itself
3-24
Find Functional Dependency

Preguntarse Alguna columna determina el valor de otra columna?
3-25
Functional Dependencies in the SKU_DATA Table
Buyer determina Department porque Jerry Martin se apareja con un mismo departamento siempre, al igual que Cindi Lo y otros buyers. por tanto Buyer Department No ocurre as si tomamos Department para determinar un nico Buyer, pues un departamento puede tener ms de un Buyer Notar que Buyer no determina valores nicos de SKU ni SKU_Description

Notar que un cliente (buyer) puede aparecer ms de una vez en la tabla, pero que esto ocurre siempre aparejado con el mismo departamento. Esto es cierto para todas las dependencias funcionales Si A B entonces cada valor de A estar aparejado con uno y solo un valor de B Tambin sucede que lo inverso no es necesariamente cierto, si A B entonces un valor de B podra aparejarse con muchos valores de A.
3-27

Analizando otras columnas. Si se conoce el valor de SKU entonces conocemos los valores de todas las dems columnas SKU SKU_Description SKU Department SKU Buyer Tambin si se conoce el valor de SKU_Description entonces conocemos los valores de todas las dems columnas SKU_Description (SKU,Department,Buyer)
3-28

SKU (SKU_Description, Department, Buyer) SKU_Description (SKU, Department, Buyer) Buyer Department
3-29
Functional Dependencies in the ORDER_ITEM Table
3-30

Preguntas El campo OrderNumber determina otro campo? No determina SKU porque una orden tiene varios SKU asociados Tampoco quantity, Price, ni ExtendedPrice El campo SKU determina algn campo? No determina OrderNumber,Quantity, ni ExtendedPrice

SKU si parece determinar Price SKU Price Ms sucede que el precio puede cambiar una vez que se haya procesado la orden. Entonces para que se cumpla se debe asociar SKU a una orden especfica para que ambos fijen el precio (Order Number, SKU) Price
3-32

Los campos Price, Quantity, ExtendedPrice no determinan a ningun otro, Saber qeu algo costo $3,00 no indica nada, o que compre 3 unidades de producto no me dice que producto o su nmero de orden Si se analiza por pares de columnas, entonces se pueden descubrir ms determinantes
3-33

Una orden y un SKu particular determinan un nico Quantity, Price, y ExtendedPrice (OrderNumber, SKU) (Quantity, Price, ExtendedPrice) (Quantity, Price) (ExtendedPrice)
3-34
What Makes Determinant Values Unique? A determinant is unique in a relation if, and only if, it determines every other column in the relation You cannot find the determinants of all functional dependencies simply by looking for unique values in one column:
Data set limitations Must be logically a determinant
Determinantes nicos
Cada vez que un valor de la columna A parece coincidir con el mismo valor de la columna B, A puede ser determinante de B Una muestra de datos puede ser incompleta para hacer diicha afirmacin Pensar siempre en la naturaleza del negocio y en preguntar al usuario
Keys
A key is a combination of one or more columns that is used to identify rows in a relation A composite key is a key that consists of two or more columns
3-37
Candidate and Primary Keys

A candidate key is a key that determines all of the other columns in a relation A primary key is a candidate key selected as the primary means of identifying rows in a relation:
There is one and only one primary key per relation The primary key may be a composite key The ideal primary key is short, numeric and never changes
Surrogate Keys
A surrogate key as an artificial column added to a relation to serve as a primary key:
DBMS supplied Short, numeric and never changes an ideal primary key! Has artificial values that are meaningless to users Normally hidden in forms and reports
Surrogate Keys
NOTE: The primary key of the relation is underlined below:
RENTAL_PROPERTY without surrogate key:

RENTAL_PROPERTY (Street, City, State/Province, Zip/PostalCode, Country, Rental_Rate)
RENTAL_PROPERTY with surrogate key:

RENTAL_PROPERTY (PropertyID, Street, City, State/Province, Zip/PostalCode, Country, Rental_Rate)
Foreign Keys
A foreign key is the primary key of one relation that is placed in another relation to form a link between the relations:
A foreign key can be a single column or a composite key The term refers to the fact that key values are foreign to the relation in which they appear as foreign key values
3-41
Foreign Keys
NOTE: The primary keys of the relations are underlined and any foreign keys are in italics in the relations below:
DEPARTMENT (DepartmentName, BudgetCode, ManagerName) EMPLOYEE (EmployeeNumber, EmployeeName, DepartmentName)
3-42
The Referential Integrity Constraint

A referential integrity constraint is a statement that limits the values of the foreign key to those already existing as primary key values in the corresponding relation
3-43
Foreign Key with a Referential Integrity Constraint

NOTE: The primary key of the relation is underlined and any foreign keys are in italics in the relations below:
SKU_DATA ORDER_ITEM (SKU, SKU_Description, Department, Buyer) (OrderNumber, SKU, Quantity, Price, ExtendedPrice)
Where ORDER_ITEM.SKU must exist in SKU_DATA.SKU
3-44
Modification Anomalies
Deletion Anomaly Insertion Anomaly Update Anomaly
3-45
Modification Anomalies
The EQUIPMENT_REPAIR table before and after an incorrect update operation on AcquisitionCost for Type = Drill Press:
3-46
Normal Forms
Relations are categorized as a normal form based on which modification anomalies or other problems that they are subject to:
3-47
Normal Forms
1NF A table that qualifies as a relation is in 1NF 2NF A relation is in 2NF if all of its nonkey attributes are dependent on all of the primary key 3NF A relation is in 3NF if it is in 2NF and has no determinants except the primary key Boyce-Codd Normal Form (BCNF) A relation is in BCNF if every determinant is a candidate key I swear to construct my tables so that all nonkey columns are dependent on the key, the whole key and nothing but the key, so help me Codd.
Eliminating Modification Anomalies from Functional Dependencies in Relations

Put all relations into Boyce-Codd Normal Form (BCNF):
3-49
Putting a Relation into BCNF: EQUIPMENT_REPAIR
3-50
Putting a Relation into BCNF: EQUIPMENT_REPAIR

EQUIPMENT_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
3-51
Putting a Relation into BCNF: New Relations
3-52
Putting a Relation into BCNF: SKU_DATA
3-53
Putting a Relation into BCNF: SKU_DATA

SKU_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
3-54
Putting a Relation into BCNF: New Relations
3-55
Multivaled Dependencies
A multivaled dependency occurs when a determinant determines a particular set of values:
Employee Degree Employee Sibling PartKit Part
The determinant of a multivaled dependency can never be a primary key

Multivaled Dependencies
3-57
Eliminating Anomolies from Multivaled Dependencies

Multivalued dependencies are not a problem if they are in a separate relation, so:
Always put multivaled dependencies into their own relation This is known as Fourth Normal Form (4NF)
3-58
David M. Kroenkes Database Processing

Fundamentals, Design, and Implementation (10th Edition) End of Presentation: Chapter Three
3-59

Kroenke10 ch03

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Kroenke10 ch03

Загружено:

Авторское право:

Доступные форматы

David M.

Chapter Three: The Relational Model and Normalization

How Many Tables?

But first Comprender:

The Relational Model

Now the standard model for commercial DBMS products

Important Relational Model Terms

A Relation with Values of Varying Length

Tables That Are Not Relations: Multiple Entries per Cell

En esta tabla Caruthers y Bandalone tienen mltiples valores de Phone

StudentID StudentName StudentID (DormName, DormRoom, Fee)

Functional Dependency -Ejemplo

Functional Dependencies Are Not Equations

ObjectColor Weight ObjectColor Shape ObjectColor (Weight, Shape)

Functional Dependency Rules

Find Functional Dependency

Functional Dependencies in the SKU_DATA Table

Functional Dependencies in the SKU_DATA Table

Functional Dependencies in the SKU_DATA Table

Functional Dependencies in the SKU_DATA Table

Functional Dependencies in the ORDER_ITEM Table

Functional Dependencies in the ORDER_ITEM Table

Functional Dependencies in the ORDER_ITEM Table

Functional Dependencies in the ORDER_ITEM Table

Functional Dependencies in the ORDER_ITEM Table

Candidate and Primary Keys

RENTAL_PROPERTY without surrogate key:

RENTAL_PROPERTY with surrogate key:

The Referential Integrity Constraint

Foreign Key with a Referential Integrity Constraint

Where ORDER_ITEM.SKU must exist in SKU_DATA.SKU

Eliminating Modification Anomalies from Functional Dependencies in Relations

Putting a Relation into BCNF: EQUIPMENT_REPAIR

Putting a Relation into BCNF: EQUIPMENT_REPAIR

Putting a Relation into BCNF: New Relations

Putting a Relation into BCNF: SKU_DATA

Putting a Relation into BCNF: SKU_DATA

Putting a Relation into BCNF: New Relations

The determinant of a multivaled dependency can never be a primary key

Eliminating Anomolies from Multivaled Dependencies

David M. Kroenkes Database Processing

Вам также может понравиться