Chapter Extension 5 Database Design © 2008 Pearson Prentice Hall, Experiencing MIS, David Kroenke.
© 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.
-
Upload
jeffery-lang -
Category
Documents
-
view
224 -
download
3
Transcript of © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.
![Page 1: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/1.jpg)
© 2002 by Prentice Hall 1
Database Design
David
M.
Kro
enke
Database Concepts 1e Chapter 5
5
![Page 2: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/2.jpg)
© 2002 by Prentice Hall 2
Chapter Objectives• Learn how to transform E-R data
models into relational designs• Understand the nature and
background of normalization theory• Know how to use normalization
criteria to evaluate relational designs• Understand the need for
denormalization
![Page 3: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/3.jpg)
© 2002 by Prentice Hall 3
Chapter Objectives (continued)
• Learn how to represent weak entities with the relational model
• Know how to represent 1:1, 1:N, and N:M binary relationships
• Know how to represent 1:1, 1:N, and N:M recursive relationships
• Learn SQL statements for creating joins over binary and recursive relationships
![Page 4: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/4.jpg)
© 2002 by Prentice Hall 4
Representing Entities with the Relational Model
• Create a relation for each entity– A relation has a descriptive name and a
set of attributes that describe the entity
• The relation is then analyzed using the normalization rules
• As normalization issues arise, the initial relation design may need to change
![Page 5: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/5.jpg)
© 2002 by Prentice Hall 5
Anomalies
• Relations that are not normalized will experience issues known as anomalies– Insertion anomaly
• Difficulties inserting data into a relation
– Modification anomaly• Difficulties modifying data into a relation
– Deletion anomaly• Difficulties deleting data from a relation
![Page 6: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/6.jpg)
© 2002 by Prentice Hall 6
Solving Anomalies
• Most anomalies are solved by breaking an existing relation into two or more relations
![Page 7: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/7.jpg)
© 2002 by Prentice Hall 7
Normalization
• “…the determinant of every functional dependency is a candidate key”
![Page 8: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/8.jpg)
© 2002 by Prentice Hall 8
Definitions
• Determinant– The value of this attribute can be
used to find the value of another attribute in the relation
• Functional dependency– The relationship (within the relation)
that describes how the value of a determinant may be used to find the value of another attribute
![Page 9: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/9.jpg)
© 2002 by Prentice Hall 9
Definition
• Candidate key– The value of a candidate key can be
used to find the value of every other attribute in the relation
![Page 10: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/10.jpg)
© 2002 by Prentice Hall 10
Candidate Key Flavors
• A composite candidate key consists of more than one attribute
• A simple candidate key consists of only one attribute
![Page 11: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/11.jpg)
© 2002 by Prentice Hall 11
Normal Forms
• First Normal Form (1NF)• Second Normal Form (2NF)• Third Normal Form (3NF)• Boyce-Codd Normal Form (BCNF)• Fourth Normal Form (4NF)• Fifth Normal Form (5NF)• Domain/Key Normal Form (DK/NF)
![Page 12: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/12.jpg)
© 2002 by Prentice Hall 12
Domain/Key Normal Form (DK/NF)
• If– “…the determinant of every
functional dependency is a candidate key”
• The relation is in DK/NF
![Page 13: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/13.jpg)
© 2002 by Prentice Hall 13
Denormalization• Normalizing relations (or breaking
them apart into many component relations) may significantly increase the complexity of the data structure
• The question is one of balance– Trading complexity for anomalies
• There are situations where denormalized relations are preferred
![Page 14: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/14.jpg)
© 2002 by Prentice Hall 14
Weak Entities
• For an ID-dependent weak entity, the key of the parent becomes part of the key of the weak entity
![Page 15: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/15.jpg)
© 2002 by Prentice Hall 15
Representing Relationships
• The maximum cardinality determines how a relationship is saved
• 1:1 relationship– The key from one relation is placed in
the other as a foreign key– It does not matter which table
receives the foreign key
![Page 16: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/16.jpg)
© 2002 by Prentice Hall 16
A One-to-One Relationship Example
LOCKER EMPLOYEE1:1
![Page 17: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/17.jpg)
© 2002 by Prentice Hall 17
One Representation of a One-to-One Relationship
LockerDesc
Location
LockerID
Locker
LockerID
EmpName
EmpID
Employee
Foreign Key
Primary Key
![Page 18: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/18.jpg)
© 2002 by Prentice Hall 18
Another Representation of a One-to-One Relationship
EmpID
LockerDesc
Location
LockerID
Locker
EmpName
EmpID
Employee
Foreign Key
Primary Key
![Page 19: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/19.jpg)
© 2002 by Prentice Hall 19
Mandatory One-to-One Relationships
• A mandatory 1:1 relationship can easily be collapsed back into one relation. While there are times when the added complexity is warranted…– Added security– Infrequently accessed data components
• …very often these relations are collapsed into one
![Page 20: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/20.jpg)
© 2002 by Prentice Hall 20
One-to-Many Relationships
• Like a 1:1 relationship, a 1:N relationship is saved by placing the key from one table into another as a foreign key
• However, in a 1:N the foreign key always goes into the many-side
![Page 21: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/21.jpg)
© 2002 by Prentice Hall 21
A One-to-Many Relationship Example
DEPARTMENT EMPLOYEE1:N
![Page 22: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/22.jpg)
© 2002 by Prentice Hall 22
Representing a One-to-Many Relationship
DeptName
Location
DeptID
Department
DeptID
EmpName
EmpID
Employee
Foreign Key
Primary Key
![Page 23: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/23.jpg)
© 2002 by Prentice Hall 23
Representing Many-to-Many Relationships
• To save a M:N relationship, a new relation is created. This relation is called an intersection relation
• An intersection relation has a composite key consisting of the keys from each of the tables that formed it
![Page 24: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/24.jpg)
© 2002 by Prentice Hall 24
A Many-to-Many Relationship Example
SKILL EMPLOYEEN:M
![Page 25: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/25.jpg)
© 2002 by Prentice Hall 25
Representing a Many-to-Many Relationship
SkillDesc
SkillID
Skill
EmpName
EmpID
Employee
Foreign Key
EmpID
SkillID
Emp_Skill
Foreign Key
![Page 26: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/26.jpg)
© 2002 by Prentice Hall 26
Representing Recursive Relationships
• A recursive relationship is a relationship that a relation has with itself.
• Recursive relationships adhere to the same rules as the binary relationships.– 1:1 and 1:M relationships are saved using
foreign keys– M:N relationships are saved by creating
an intersecting relation
![Page 27: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/27.jpg)
© 2002 by Prentice Hall 27
A Recursive Relationship Example
EMPLOYEE 1:N
Manages
![Page 28: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/28.jpg)
© 2002 by Prentice Hall 28
Representing a Recursive Relationship
EmpID (FK)
EmpName
EmpID
Employee
Foreign Key isThe EmpID of the Manager
![Page 29: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/29.jpg)
© 2002 by Prentice Hall 29
Synonyms
• A synonym is created when the same attribute assumes 2 names
• Synonyms are often convenient when saving recursive relationships
![Page 30: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/30.jpg)
© 2002 by Prentice Hall 30
Representing a Recursive Relationship using a Synonym
ManagerID
EmpName
EmpID
Employee
Foreign Key isThe EmpID of the Manager
![Page 31: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/31.jpg)
© 2002 by Prentice Hall 31
Cascading Behavior
• Cascading behavior describes what happens to child relations when a parent relation changes in value
![Page 32: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/32.jpg)
© 2002 by Prentice Hall 32
Cascading Behaviors
• Cascading behaviors are defined by the type of operation– Cascade update– Cascade delete
![Page 33: © 2002 by Prentice Hall 1 Database Design David M. Kroenke Database Concepts 1e Chapter 5 5.](https://reader036.fdocuments.in/reader036/viewer/2022062408/56649eb55503460f94bbe35a/html5/thumbnails/33.jpg)
© 2002 by Prentice Hall 33
Database Design
David
M.
Kro
enke
Database Concepts 1e Chapter 5
5