1. Chapter 4: Logical Database Design and the Relational Model
Modern Database Management
11th Edition, International Edition
Jeffrey A. Hoffer, V. Ramesh,
Heikki Topi
© 2013 Pearson Education

2. Chapter Outline The Relational (關聯式的) Data Model
Integrity Constraints (完整性限制)
Transforming EER Diagrams into Relations
Introduction to Normalization
Normalization Example
Merging Relations

3. Learning Objectives Understand definitions of terms
Properties of relations
Properties of candidate keys
Define first, second, and third normal form
Describe problems from merging relations
Transform E-R and EER diagrams to relations
Create tables with entity and relational integrity constraints
Use normalization to convert anomalous (異常的) tables to well-structured relations

4. Components of relational model
Data structure
Tables (relations), rows, columns
Data manipulation
Powerful SQL operations (操作、運算) for retrieving and modifying data
Data integrity
Mechanisms for implementing business rules that maintain integrity of manipulated data

5. NOTE: All relations are in 1st Normal form.
A relation is a named, two-dimensional table of data.
A table consists of rows (records) and columns (attribute or field).
Requirements for a table to qualify as a relation:
It must have a unique name.
Every attribute value must be atomic (not multi-valued, not composite).
Every row must be unique (can’t have two rows with exactly the same values for all their fields).
Every attribute (column) in a same table must have a unique name.
The order of the columns must be irrelevant.
The order of the rows must be irrelevant.
NOTE: All relations are in 1st Normal form.

6. Example of Relation with Sample Data
Figure 4-1 Employee1 Relation with Sample Data. 6

7. Relation with Multi-valued Attribute
Figure 4-2(a) Table with repeating groups. 7

8. Correspondence (相當性) with E-R Model
A relation (table) corresponds to an entity type and to a many-to-many relationship type.
A row corresponds to an entity instance and to a many-to-many relationship instance.
A column corresponds to an attribute.
NOTE: The word relation (in relational database) is NOT the same as the word relationship (in E-R model).

9. Relational KEYS (索引、鍵)
Keys are special attributes that serve two main purposes:
Primary key is a unique identifier of a relation. Examples include employee numbers, social security numbers, etc. This guarantees that all rows are unique.
Foreign key is an identifier that enables a dependent (依附 的、附屬的) (child) relation (on the many side of a relationship) to refer to its parent relation (on the one side of the relationship).
Keys can be simple (a single attribute) or composite (more than one attribute).
Keys usually are used as indexes to speed up the response to user queries (more on this in Chapter 5).

10. Figure 4-3 Schema for four relations (Pine Valley Furniture Company)
Primary Key
Foreign Key
(implements a 1:M relationship between customer and order)
Composite Primary Key
(uniquely identifies the order line)
Composed from 2 foreign keys
Implements a M:N relationship between order and product
© 2013 Pearson Education
Chapter 4 10

11. Integrity Constraints 1/2
To facilitate maintaining the accuracy and
integrity of data in the database.
Three Types :
Domain (值域) Constraints
Allowable values for an attribute (See Table 4-1)
Entity Integrity Constraint
Every relation has a primary key.
All primary key attributes MUST have data.
No primary key attribute may be null.
A null is not a value, but rather it indicates the absence of a value.

12. Domain definitions enforce domain integrity constraints.
12/35/15
invalid
13/01/15
Domain definitions enforce domain integrity constraints.
© 2013 Pearson Education
Chapter 4 12

13. Integrity Constraints 2/2
Referential (參照的) Integrity Constraint :
Referential integrity constraint : a rule states that
either, each foreign key (FK) value (in the relation of the many side) MUST match a primary key (PK) value in the relation of the one side
or, the foreign key must be null
Association between tables are defined through the uses of FKs.
3 choices for DELETE RULE (of a parent record) to enforce referential integrity constraint
Restrict : don’t allow delete a record in “parent” side if its related records exist in “child” side
Cascade : automatically delete child-side rows when their related parent- side row is deleted
Set-to-Null : if deleting a record from the parent side, set the foreign key of the related records in the child side to null
(This choice is not allowed for weak entities, why ?)

14. Creating Relational Tables with SQL
Figure 4-6 Example of SQL table definitions
Table schema
reference
Entity Integrity
Referential Integrity 14

15. Figure 4-5
Referential integrity constraints (Pine Valley Furniture)
Referential integrity constraints are drawn via arrows from dependent to parent table
Corresponding
SQL
© 2013 Pearson Education
Chapter 4 15

16. Figure 4-6 SQL table definitions
Table schema
Referential integrity constraints are implemented with foreign key to primary key references.
Important questions :
What attribute is a
FK?
What FK references
what table’s PK?
© 2013 Pearson Education
Chapter 4

17. Transforming EER Diagrams into Relations
Mapping Regular Entities to Relations
Simple attributes: E-R attributes map directly onto the relation
Composite attributes: Use only their simple, component attributes
Multi-valued Attribute: Becomes a separate relation with a foreign key taken from the parent entity

18. Figure 4-8 Mapping a regular entity
(a) CUSTOMER entity type with simple attributes
(b) The corresponding CUSTOMER relation of (a)
© 2013 Pearson Education
Chapter 4 18

19. Figure 4-9 Mapping a composite attribute
(a) CUSTOMER entity type with composite attribute
(b) The corresponding CUSTOMER relation of (a)
© 2013 Pearson Education
Chapter 4 19

20. Figure 4-10 Mapping an entity with a multi-valued attribute
A multi-valued attribute becomes a separate relation with a foreign key
The foreign key implementing a one–to–many relationship between
original entity and new relation
(b)
1:M
(a) EMPLOYEE entity type with a multi-valued attribute Skill FK
a composite PK

21. Transforming EER Diagrams into Relations (cont.)
Mapping Weak Entities
The weak entity becomes a separate relation with a foreign key (FK) taken from the primary key (PK) of the strong entity
Primary key is composed of:
The partial identifier of weak entity
The primary key of identifying entity (strong entity)
ERD
Table
Design

22. Identifying relationship
Figure 4-11 Example of mapping a weak entity
a) Weak entity DEPENDENT
Identifying relationship
Strong entity
Weak entity
© 2013 Pearson Education
Chapter 4 22

23. Figure 4-11 Example of mapping a weak entity
b) Relations resulting from weak entity
Foreign key
partial identifier of weak entity
PK of identifying entity
A composite primary key
NOTE: the domain constraint for the foreign key should NOT allow null value since DEPENDENT is a weak entity
© 2013 Pearson Education
Chapter 4 23

24. Transforming EER Diagrams into Relations (cont.)
Mapping a binary relationship
One-to-Many (1:M)
Primary key on the one side becomes a foreign key on the many side
Many-to-Many (M:M)
Create a new relation with the primary keys of the two related entities as its primary key
One-to-One (1:1)
Primary key on mandatory side becomes a foreign key on optional side

25. Figure 4-12 Example of mapping a 1:M relationship
a) Relationship between customers and orders
Note the mandatory one
b) The corresponding relationship PK FK
No null value in the foreign key. This is because of the mandatory minimum cardinality.
© 2013 Pearson Education
Chapter 4 25

26. Figure 4-13 Example of mapping an M:N relationship
a) Completes relationship (an M:N relationship)
The Completes relationship will need to become a separate relation.
Schema design
© 2013 Pearson Education
Chapter 4 26

27. Figure 4-13 Example of mapping an M:N relationship (cont.)
b) Three resulting relations PK
Composite primary key FK
new intersection relation FK PK
© 2013 Pearson Education
Chapter 4 27

28. Figure 4-14 Example of mapping a binary 1:1 relationship
a) In charge relationship (a 1:1 relationship)
Often in a 1:1 relationships, one direction is optional
Schema design
© 2013 Pearson Education
Chapter 4 28

29. Figure 4-14 Example of mapping a binary 1:1 relationship (cont.)
b) Resulting relations
Foreign key goes in the relation on the optional side,
matching the primary key on the mandatory side
© 2013 Pearson Education
Chapter 4 29

30. Transforming EER Diagrams into Relations (cont.)
Mapping An Associative Entity (2 cases)
PK is not assigned by end-users
Default primary key for the association relation is composed of the primary keys of the two entities (as in M:N relationship)
PK is assigned by end-users
It is natural and familiar to end-users
Note default identifier may not be unique

31. Figure 4-15 Example of mapping an associative entity
a) An associative entity
Schema design
© 2013 Pearson Education
Chapter 4 31

32. Figure 4-15 Example of mapping an associative entity (cont.)
b) Three resulting relations
A composite primary key formed from
the PKs of the two related entities
© 2013 Pearson Education
Chapter 4 32

33. Figure 4-16 Example of mapping an associative entity with
an identifier
a) SHIPMENT associative entity
Schema design
© 2013 Pearson Education
Chapter 4 33

34. Figure 4-16 Example of mapping an associative entity with
an identifier (cont.)
b) Three resulting relations
Primary key differs from foreign keys
© 2013 Pearson Education
Chapter 4 34

35. Transforming EER Diagrams into Relations (cont.)
Mapping Unary Relationships
Mapping a one-to-many relationship
Add a recursive foreign key in the same relation
Mapping a many-to-many relationship
Add an associative relation
The primary key of the relation has two attributes,
Each is taken from the PK of the entity associated with the unary relationship
Each attribute is a FK to the entity

36. Figure 4-17 Mapping a unary 1:M relationship
(a) EMPLOYEE entity with unary relationship
(b) EMPLOYEE relation with recursive foreign key
© 2013 Pearson Education
Chapter 4 36

37. Figure 4-18 Mapping a unary M:N relationship
(a) Bill-of-materials relationships (M:N)
(b) ITEM and COMPONENT
relations FK FK
Composite primary key

38. Transforming EER Diagrams into Relations (cont.)
Mapping a ternary (and n-ary) relationship
Convert the ternary relationship to an associative entity
Add one relation for the associative entity
The primary key of the relation has 3 attributes
Each is taken from the PK of each entity associated with the ternary relationship
Each attribute is a FK to each related entity

39. Figure 4-19 Mapping a ternary relationship
a) PATIENT TREATMENT ternary relationship denoted as an associative entity
Schema design
© 2013 Pearson Education
Chapter 4 39

40. Figure 4-19 Mapping a ternary relationship (cont.)
b) Mapping the ternary relationship PATIENT TREATMENT
Composite PK
Assume a patient may be treated by a same doctor multiple times
on a date.
Remember that the primary key MUST be unique.
This is why treatment date and time are included in the composite PK.
But this makes a very cumbersome PK.
It would be better to create a surrogate key (代用鍵) like Treatment#.
© 2013 Pearson Education
Chapter 4

41. Transforming EER Diagrams into Relations (cont.)
Mapping a supertype/subtype relationship
One relation for supertype and one for each subtype
Supertype attributes (including PK and subtype discriminator) go into supertype relation
Subtype attributes go into each subtype relation
PK of supertype relation also becomes PK of subtype relation
Establishing 1:1 relationship between supertype and each subtype, with supertype as primary table

42. Figure 4-20 Supertype/subtype relationships
Schema design
© 2013 Pearson Education
Chapter 4 42

43. These are implemented as one-to-one relationships.
Figure 4-21
Mapping supertype/subtype relationships to relations
These are implemented as one-to-one relationships.
© 2013 Pearson Education
Chapter 4 43

44. Data Normalization (正規化、標準化)
A process
(Purpose)
used to validate and improve the logical design of a relational database so that it satisfies certain data constraints that avoid unnecessary data duplication (重複)
(Step)
decomposing a relation with modification anomalies (更動的異常:資料更動時會發生的異常情形) into several smaller, well-structured relations

45. Main Goals of Data Normalization
Minimize data redundancy (重複) to avoid modification anomalies and conserve storage space.
Simplify the enforcement (執行) of referential integrity constraints.
Make it easier to maintain data (insert, update, and delete)
Provide a better database design that is an improved representation of an organization’s operations and a stronger basis for future growth.

46. A Well-Structured Relation
A relation that
contains minimal data redundancy, and
allows users to insert, update, and delete data rows without causing data inconsistency
Main design goal is to avoid modification anomalies
Insertion Anomaly–adding new data rows forces user to create redundant data
Deletion Anomaly–deleting data rows may cause a loss of data that would be needed
Update Anomaly–changing the data of a data row forces changes to other rows due to data duplication
General rule of thumb: A table should not pertain to more than one entity type.

47. Example–Figure 4-2b Question–Is this a relation?
Answer–Yes: Unique rows and no multivalued attributes
Question–What’s the primary key?
Answer–Composite: EmpID, CourseTitle

48. Anomalies in this Table
Insertion–can’t enter a new employee without having the employee take a class
Deletion–if we remove employee 140, we lose information about the existence of a Tax Acc class
Update–giving a salary increase to employee 100 forces us to update multiple records
Why do these modification anomalies exist?
Because there are two themes (entity types) in this one relation. This results in data duplication and an unnecessary data dependency between entity types.

49. Figure 4.22 Steps in normalization
3rd normal form is generally considered sufficient
© 2013 Pearson Education
Chapter 4 49

50. Functional Dependencies and Keys
Functional Dependency (函數性的依附)
A constraint between two attributes in which the value of one attribute is determined by the value of another attribute (the determinant (決定項) ).
Candidate Key:
An attribute, or a combination of attributes, that uniquely identifies a row in a relation. Example,
A table contains credit card number and SS#. In this case both are candidate keys.
The primary key is chosen from one of the candidate keys.
Each non-key field must be functionally dependent on one of the candidate keys.

51. First Normal Form
No multivalued attributes (no repeating groups) in the relation, i.e., every attribute value is atomic.
A primary key has been defined, which uniquely identifies each row in the relation.
Fig is not in 1st Normal Form (having multivalued attributes).
 it is not a relation.
Fig is in 1st Normal form.
All relations are in 1st Normal Form.

52. Table with multivalued attributes, not in 1st normal form
Primary key
Note: This is NOT a relation.
© 2013 Pearson Education
Chapter 4 52

53. Note: This is a relation, but not a well-structured one.
INVOICE (發貨單) table in 1st normal form
no multivalued attributes
unique rows (primary key uniquely identifies each row)
Note: This is a relation, but not a well-structured one.
Not a relation
© 2013 Pearson Education
Chapter 4 53

54. Anomalies in FIGURE4-26 Table
Insertion– Not able to introduce a new product (say, Breakfast Table with ProductID 8) without adding the information OrderID. (PK : ProductID + OrderID)
Deletion–if we delete the Dining Table from Order 1006, we lose information concerning this product (description, finish (拋光), and price).
Update–changing the price of product ID 4 (Entertainment Center) requires update in multiple records
Why do these anomalies exist?
Because there are multiple themes (entity types) in one relation. This results in data duplication and an unnecessary data dependency between the entity types.

55. Second Normal Form A relation in 1NF, and
Every non-key attribute of the relation is fully functionally dependent on the ENTIRE primary key, i.e.,
No partial functional dependencies
Every non-key attribute must not be dependent on a part of the PK.

56. Figure 4-27 Functional dependency diagram for INVOICE
PK = OrderID + ProductID
(on OrderID & ProductID)
(on OrderID)
(on ProductID)
OrderID  OrderDate, CustomerID, CustomerName, CustomerAddress : P.D.
CustomerID  CustomerName, CustomerAddress
ProductID  ProductDescription, ProductFinish, ProductStandardPrice : P.D.
OrderID, ProductID  OrderQuantity
Therefore, INVOICE is NOT in 2nd Normal Form

57. CONVERTING to 2NF
Create a new relation by using the PK attribute(s) (determinant) of each partial dependency.
This attribute(s) is the
PK of the new relation
FK of the old relation
Find the nonkey attributes that are dependent on this PK attribute(s).
Move them from the old relation to the new relation.

58. Figure 4-28 Result after removing partial dependencies
Figure 4-28 Result after removing partial dependencies (Converting to 2NF)
Before removing PDs
Partial dependencies are removed, but there are still transitive dependencies.

59. Third Normal Form A relation that
is in 2NF, and
has no transitive dependencies
Transitive dependency (AC due to AB & BC)
A functional dependency between the PK and a non-key attribute that depends on the PK via another non-key attribute.
Converting to 3NF
Create a new relation for the non-key determinant (example : B of BC) causing a transitive dependency.
The non-key determinant
becomes PK in the new table, and
stays as FK in the old table .
Find all the attributes that are functionally dependent on the non-key determinant .
Move them from old relation to new relation.

60. Transitive dependencies are removed.
Figure 4-29 Result after removing transitive dependencies
The relation schem Before transitive dependencies are removed.
Transitive dependencies are removed.
Getting it into Third Normal Form

61. Merging (整併) Relations
Merging relations is also called view integration
(In a large project) combining relations transformed from multiple ER models into common relations
Issues to watch out for when merging entities from different ER models in a large project :
Synonyms (同義字) – two or more attributes with different names but same meaning
Homonyms (同形異義字) – attributes with same name but different meanings
Transitive dependencies–even if relations are in 3NF prior to merging, they may not be in 3NF after merging
Supertype/subtype relationships–may be hidden prior to merging

62. Enterprise Keys A primary key whose value is
unique across all the relations in a database,
not just unique in a single relation
Corresponds to the concept of object ID in object-oriented systems

63. Figure 4-31 Enterprise keys
a) Relations with enterprise key
b) Sample data with enterprise key
EMPLOYEE and CUSTOMER are subtypes of the OBJECT supertype.
© 2013 Pearson Education
Chapter 4 63

64. 作業 下一次上課時交 作業 : 第四章 Problems and Exercises (227~235頁) 學號單號: 6 : a
7 : a, b, d, f
學號雙號:
8 : a, b, c, d

65. Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall65