1. Developing Data Models for Business Databases (Part II)
Welcome to Chapter 6 on developing data models for business databases
- Extends your knowledge of the notation of ERDs
- Data modeling practice on narrative problems
- Convert from ERD to table design
- Data modeling is challenging
- Ambiguity: part science, part art
- Opportunity for some creative problem solving
Objectives:
- Data modeling practice:
- Strategies for analyzing a narrative problem
- Transformations for considering alternative designs
- Avoidance of common design errors
- Master data modeling with lots of practice
- Apply conversion rules to transform ERD into a table design

2. Finalizing (完成) an ERD Data model is not complete without
Adequate design documentation
Careful consideration of design errors

3. Documenting an ERD
Important for resolving questions and communicating a design
Identify inconsistency and incompleteness in a specification
Identify situations when more than one feasible alternative exists
Do not repeat the details of the ERD
Incorporate documentation (文件) into the ERD
A large specification typically contains many points of inconsistency and incompleteness. Recording each point allows systematic resolution through additional requirements gathering activities.
An information system can undergo a long cycle of repair and enhancement before there is sufficient justification to redesign the system. Good documentation enhances an ERD by communicating the justification for important design decisions.
If you are using an ERD tool that has a data dictionary, you should include design justifications in the data dictionary. The ER Assistant supports design justifications as well as comments associated with each item on a diagram. You can use the comments to describe the meaning of attributes.

4. Documentation Example : Data Dictionary (Employee Entity)
Attributes
Description
Data type and length
Domain characteristics
Keys
Nulls
Default
EmpNo
員工編號
VARCHA(5)
S ；如：S0001 PK N
FName
員工的名
VARCHAR(20)
LName
員工的姓
Address
員工的
通訊地址
VARCHAR(50)
Sex
員工的姓別
CHAR(1)
‘ M’或 ‘F ’
‘M’
HireDate
雇用日期
Date
Date()
Position
員工的職位
‘Manager’,
‘Supervisor’,
or ‘Assistant’
‘Assistant’
Salary
員工的薪資
NUMBER(8)
員工的 AK Y

5. Documentation with the ER Assistant
Documented in Comment
Entity type comments
Attribute comments
Relationship comments 2
Comments
Enter in the editing window for entity types, attributes, and relationships
Attribute comments are most useful: units of measure, descriptive sentence, uniqueness
Entity type comments: combined candidate keys; descriptive sentence 1 3

6. Documentation with the ER Assistant
Design Justifications (設計的理由)
Numbered
Arrange in the diagram so that the numbers indicate the applicable part of the ERD
Explain choice among feasible alternatives
Explain design subtleties (微妙處)
Subtleties are very small details or differences which are not obvious.

7. Documentation with the ER Assistant
Click New to create a new Design Justification 1 3
Drag-and-drop to move the symbols 5 4 2

8. Common Design Errors
More difficult to detect and resolve than diagram errors
Design errors involve the meaning (semantics) of ERD components, not just the structure (notation) of components
Types of Common Design Errors
Misplaced Relationships
In a large ERD, it is easy to connect the wrong entity types.
Design Errors:
More difficult to detect and resolve than diagram errors
Design errors involve the meaning (semantics) of ERD components, not just the structure of components
Misplaced Relationships:
In a large ERD, it is easy to connect the wrong entity types.
To help focus, you can look for clusters of entity types in which an entity type in the center is connected to other entity types.
Missing relationships:
Sometimes the requirements do not directly indicate a relationship
Consider indirect implications to detect whether a relationship is required.

9. Types of Common Design Errors
Missing relationships
Sometimes the requirements do not directly indicate a relationship
Consider indirect implications (間接的隱含意義) to detect whether a relationship is required.
Example:
The requirements for Water Utility Database do not directly indicate the need for a relationship from Bill to Reading.
Design Errors:
More difficult to detect and resolve than diagram errors
Design errors involve the meaning (semantics) of ERD components, not just the structure of components
Misplaced Relationships:
In a large ERD, it is easy to connect the wrong entity types.
To help focus, you can look for clusters of entity types in which an entity type in the center is connected to other entity types.
Missing relationships:
Sometimes the requirements do not directly indicate a relationship
Consider indirect implications to detect whether a relationship is required.

10. Types of Common Design Errors
Incorrect Cardinalities
A typical error involves the usage of a 1-M relationship instead of a M-N relationship.
This error can be caused by an omission in the requirements.
Reversed cardinality
1-M instead of M-1
Errors on minimal cardinality
0 or 1
Incorrect Cardinality:
Typical error involves the usage of a 1-M relationship instead of a M-N relationship.
This error can be caused by an omission in the requirements.

11. Types of Common Design Errors
Overuse of specialized modeling constructs: Generalization hierarchies and M-way associative entity type are specialized modeling constructs.
Generalization hierarchies should not be used just because an entity can exist in multiple states.
Example:
A project task can be started, in process, or complete
An M-way associative entity type should be used when the database is to record combinations of three (or more) entity types rather than just combinations of two entity types.
Overuse of specialized modeling tools:
A typical novice mistake is to use them inappropriately.
Generalization hierarchies should not be used just because an entity can exist in multiple states.
Example: A project task can be started, in process, or complete does not indicate the need for a generalization hierarchy.
If there is an established classification and specialized attributes and relationships for subtypes, a generalization hierarchy is an appropriate tool.
An associative entity type representing an M-way relationship should be used when the database should record combinations of three (or more) objects rather than just combinations of two objects. In most cases, only combinations of two objects should be recorded.

12. Common Design Errors Redundant Relationships
Connection cycles in an ERD may indicate redundant relationships.
A relationship is redundant if it can be derived from other relationships.
Redundant relationships:
Cycles in an ERD may indicate redundant relationships. A cycle involves a collection of relationships arranged in a loop starting and ending with the same entity type.
In a cycle, a relationship is redundant if it can be derived from other relationships.

13. Redundant Relationships Example
Cycle relationships: Customer, Bill, Reading, and Meter
For the SentTo relationship, the bills associated with a customer can be derived from the relationships Uses1, ReadBy2, and Includes3. In the opposite direction, the customer associated with a bill can be derived from the Includes1, ReadBy2, and Uses3.      

14. Final Water Utility ERD
Entity type cluster:
Star pattern with an entity type in the center with 1-M relationships
Simplifies connections among entity types
Reading is hub (center) or a cluster connecting Bill, Meter, and Employee
Other cluster examples:
Order entry database with Order connected to Customer, Employee, and Supplier
Hospital database with Visit connected to Patient, Physician, and Care Facility

15. Converting an ERD to Relational Tables
Understanding the conversion rules improves the understanding of the ER Model, particularly the difference between the ER Model and Relational Model (關聯式模型).
Some typical errors by novice (新手) data modelers are due to confusion between these two models.
Most commercial DBMSs use the Relational Model.
For more details see textbook Chapter 6 (section 6.4.1)
Apply rules in order: all applications of rule 1, then rule 2, then rule 3, and rule 4.
Second rule: fundamental difference between models
M-N relationship becomes an associative table with a combined PK.

16. The Example of University D/B for Table Conversion
Entity type rule:
- Two applications
- Convert PK and attributes in the table
1-M relationship rule:
- 1 application
- Offering.CourseNo becomes a FK in the child (M) table (Offering)
6-16

17. Basic Conversion Rules
Entity Type Rule
Each entity type becomes a table.
1-M Relationship Rule
Each 1-M relationship becomes a foreign key in the table corresponding to the child entity type (the entity type near the crow’s foot symbol).
If the minimum cardinality on the parent side of the relationship is one, the foreign key cannot accept null values  mandatory
If it is zero, FK can accept null  optional
For more details see textbook Chapter 6 (section 6.4.1)
Apply rules in order: all applications of rule 1, then rule 2, then rule 3, and rule 4.
Second rule: fundamental difference between models
M-N relationship becomes an associative table with a combined PK.

18. Summary of Basic Conversion Rules
M-N Relationship Rule
Each M-N relationship becomes an associative table with a combined primary key consisting of the primary keys of the two entity types participating in the M-N relationship.
identification Relationship Rule
Each identifying relationship adds a component to the primary key in the table corresponding to weak entity type.
For more details see textbook Chapter 6 (section 6.4.1)
Apply rules in order: all applications of rule 1, then rule 2, then rule 3, and rule 4.
Second rule: fundamental difference between models
M-N relationship becomes an associative table with a combined PK.

19. Application of Basic Rule 1
Each entity type becomes a table
CREATE TABLE Course
(CourseNo CHAR(6)
,CrsDesc VARCHAR(30) NOT NULL
,CrsUnits NUMBER(2) DEFAULT 3 NOT NULL
,CONSTRAINT Course_pk PRIMARY KEY (CourseNo) );
CREATE TABLE Offering
(OfferNo CHAR(6)
,OffLocation VARCHAR(10)
,OffTime Date
,CONSTRAINT Offering_pk PRIMARY KEY (OfferNo)
Entity type rule:
- Two applications
- Convert PK and attributes in the table
1-M relationship rule:
- 1 application
- Offering.CourseNo becomes a FK in the child (M) table (Offering)
Dictionary

20. Application of Basic Rule 2 (Converting a Mandatory 1-M Relationship )
Each 1-M relationship becomes a foreign key in the table corresponding to the child entity type
CREATE TABLE Course
(CourseNo CHAR(6)
,CrsDesc VARCHAR(30) NOT NULL
,CrsUnits NUMBER(2) DEFAULT 3 NOT NULL
,CONSTRAINT Course_pk PRIMARY KEY (CourseNo) );
CREATE TABLE Offering
(OfferNo CHAR(6)
,OffLocation VARCHAR(10)
,OffTime Date
,CourseNo CHAR(6) NOT NULL
,CONSTRAINT Offering_pk PRIMARY KEY (OfferNo)
,CONSTRAINT Offering_CourseNo_fk
FOREIGN KEY (CourseNo) REFERENCES Course (CourseNo)
Old
Entity type rule:
- Two applications
- Convert PK and attributes in the table
1-M relationship rule:
- 1 application
- Offering.CourseNo becomes a FK in the child (M) table (Offering)
If the minimum cardinality on the parent side of the relationship is one, the foreign key cannot accept null values.

21. Application of Basic Rule 2 (Converting an Optional 1-M Relationship)
Each 1-M relationship becomes a foreign key of child entity type.
If the minimum cardinality on the parent side is 0, FK can accept null
CREATE TABLE Faculty
(FacNo CHAR(6)
,FacName VARCHAR(30) NOT NULL
,CONSTRAINT Faculty_pk PRIMARY KEY (FacNo) );
CREATE TABLE Offering
(OfferNo CHAR(6)
,OffLocation VARCHAR(10)
,OffTime Date
,FacNo CHAR(6) NOT NULL
,CONSTRAINT Offering_pk PRIMARY KEY (OfferNo)
,CONSTRAINT Offering_FacNo_fk
FOREIGN KEY (FacNo) REFERENCES Faculty (FacNo)
CREATE TABLE Faculty
(FacNo CHAR(6)
,FacName VARCHAR(30) NOT NULL
,CONSTRAINT Faculty_pk PRIMARY KEY (FacNo) );
CREATE TABLE Offering
(OfferNo CHAR(6)
,OffLocation VARCHAR(10)
,OffTime Date
,FacNo CHAR(6)
,CONSTRAINT Offering_pk PRIMARY KEY (OfferNo)
,CONSTRAINT Offering_FacNo_fk
FOREIGN KEY (FacNo) REFERENCES Faculty (FacNo)
Entity type rule:
- Two applications
- Convert PK and attributes in the table
1-M relationship rule:
- 1 application
- Offering.CourseNo becomes a FK in the child (M) table (Offering)

22. Application of Basic Rule 3
Each M-N relationship becomes an associative table with a combined primary key.
Enrolls_In conversion:
- Enrollment table: name change not necessary; use noun for table name
- Foreign keys: StdSSN and OfferNo
CREATE TABLE Enrollment
(StdSSN CHAR(10)
,OfferNo CHAR(6)
,EnrGrade CHAR(1)
,CONSTRAINT Enrollment_pk PRIMARY KEY (StdSSN, OfferNo)
,CONSTRAINT Enrollment_StdSSN_fk
FOREIGN KEY (StdSSN) REFERENCES Student (StdSSN)
,CONSTRAINT Enrollment_OfferNo_fk
FOREIGN KEY (OfferNo) REFERENCES Offering (OfferNo) );

23. Application of Basic Rule 4 (Identification Relationship Rule)
Each identifying relationship adds a component to
the primary key in the table corresponding to weak
entity type.
Conversion process:
- Entity type rule: 3 applications
- 1-M relationship rule: 2 applications (FKs in the Enrollment table)
- Identifying relationship rule: 2 applications
- Each application of the identifying relationship rule adds a PK component
Corresponding to M-N
Same conversion result as the previous slide
Application of rule 3 vs. Application of rule 4

24. Application of Basic Rule 4
Each identifying relationship adds a component to the primary key in the table corresponding to weak entity type
Enrolls_In conversion:
- Enrollment table: name change not necessary; use noun for table name
- Foreign keys: StdSSN and OfferNo
CREATE TABLE Enrollment
(StdSSN CHAR(10)
,OfferNo CHAR(6)
,EnrGrade CHAR(1)
,CONSTRAINT Enrollment_pk PRIMARY KEY (StdSSN, OfferNo)
,CONSTRAINT Enrollment_StdSSN_fk
FOREIGN KEY (StdSSN) REFERENCES Student (StdSSN)
,CONSTRAINT Enrollment_OfferNo_fk
FOREIGN KEY (OfferNo) REFERENCES Offering (OfferNo) );
6-24

25. 1-M Self-Referencing Relationship (Converting a 1-M relationship)
CREATE TABLE Faculty
(FacSSN CHAR(11)
,FacName VARCHAR(30)
,FacSupervisor CHAR(11) ,…
,CONSTRAINT Faculty_pk PRIMARY KEY (FacSSN)
,CONSTRAINT Faculty_Supervisor_fk
FOREIGN KEY (FacSupervisor) REFERENCES Faculty (FacSSN) );
2.1-M Relationship Rule
Each 1-M relationship becomes a foreign key in the table corresponding to the child entity type

26. M-N Self-Referencing Relationship (Converting A M-N Relationship)
3.M-N Relationship Rule
Each M-N relationship becomes an associative table with a combined primary key. (similar to slide 22)
slide 22
CREATE TABLE Course
(CourseNo CHAR(6)
,CrsDesc VARCHAR(30)
,CONSTRAINT Course_pk PRIMARY KEY (CourseNo ) );
CREATE TABLE PrereqTo
(PrereqCNo CHAR(6)
,DependCNo CHAR(6)
,CONSTRAINT PrereqTo_pk PRIMARY KEY (PrereqCNo, DependCNo)
,CONSTRAINT PrereqTo_PrereqCNo_fk
FOREIGN KEY (PrereqCNo) REFERENCES Course (CourseNo)
,CONSTRAINT PrereqTo_DependCNo_fk
FOREIGN KEY (DependCNo) REFERENCES Course (CourseNo)

27. ERD with Two Weak Entity Types
4. identification Relationship Rule
Each identifying relationship adds a component to the primary key in the table corresponding to weak entity type.
Enrollment table
local key
CREATE TABLE Attendance
(StdSSN CHAR(11)
,OfferNo CHAR(6)
,AttDate Date
,Present CHAR(1)
,CONSTRAINT Attendance_pk PRIMARY KEY (StdSSN, OfferNo, AttDate)
,CONSTRAINT Attendance_OfferNo_StdSSN_fk
FOREIGN KEY (StdSSN, OfferNo) REFERENCES Enrollment (StdSSN, OfferNo) );
From Enrollment

28. Generalization Hierarchy Rule
Each entity type of a generalization hierarchy becomes a table
Each subtype table contains specific columns
Add a subtype column for the supertype table
Each subtype table uses the primary key of its supertype table as its primary key.
Add Foreign key constraints for subtype tables
ON DELETE CASCADE option for deletion of referenced rows
Reduce need for null values
Generalization hierarchy rule:
- Simulate generalization hierarchy with tables and foreign keys
- Minimize null values in the tables
- Little redundancy except for PK: repeated for each subtype table
- CASCADE DELETE: delete parent, automatically delete rows in subtype tables
Combining tables:
- Join: combine table and all of its parent tables
- Full Outer join: combine a table with its sibling tables
Other conversion possibilities:
- One table: many null values but no need for join and outer join operations
- Combine some subtype tables: fewer tables, more nulls, fewer join and outer joins

29. Converting Generalization Hierarchy
CREATE TABLE Employee
( EmpNo CHAR(6)
, EmpName VARCHAR(30)
, EmpHireDate DECIMAL(10,2)
, EmpType CHAR(1)
, CONSTRAINT Employee_pk PRIMARY KEY (EmpNo ) );
CREATE TABLE SalaryEmp
( EmpNo CHAR(6)
, EmpSalary NUMBER(7)
, CONSTRAINT SalaryEmp_pk PRIMARY KEY (EmpNo)
, CONSTRAINT SalaryEmp_fk FOREIGN KEY (EmpNo) REFERENCES Employee (EmpNo) ON DELETE CASCADE
CREATE TABLE HourlyEmp
, EmpRate NUMBER(8,2)
, CONSTRAINT HourlyEmp_pk PRIMARY KEY (EmpNo)
, CONSTRAINT HourlyEmp_fk FOREIGN KEY (EmpNo) REFERENCES Employee (EmpNo)
ON DELETE CASCADE
subtype column
Supertype’s PK
CASCADE DELETE for Foreign Keys
- SalaryEmp
- HourlyEmp
Supertype’s PK

30. Converting 1-1 Relationships
CREATE TABLE Employee
( EmpNo CHAR(6)
, EmpName VARCHAR(30)
, CONSTRAINT Employee_pk PRIMARY KEY (EmpNo) );
CREATE TABLE Office
( OffNo CHAR(6)
, OffAddress VARCHAR(30)
, OffPhone CHAR(4)
, EmpNo CHAR(6) NOT NULL
, CONSTRAINT Office_pk PRIMARY KEY (OffNo)
, CONSTRAINT Office_EmpNo_fk FOREIGN KEY (EmpNo) REFERENCES Employee (EmpNo)
, CONSTRAINT Office_EmpNo_uk UNIQUE (EmpNo)
1-1 relationship
Add a FK
Add unique constraint
1-1 relationships: not common
Use FKs in each mandatory 1-1 relationship:
- Can also use for optional 1-1 relationship but will have null values
- Office must have an employee: use FK in Office
- Employee must be assigned to an office: use FK in Employee
UNIQUE constraint:
- FK is unique because of the 1-1 relationship
- The same employee can be assigned to only one office.

31. Comprehensive Example of Water Utility ERD

32. Summary Data modeling is an important skill for database design
Use ERD notation precisely
Preference for simpler designs at first
Consider alternative designs later
Review design for common errors
Solve as many problems as possible
Data modeling
- Important skill
- Use notation precisely
- Problem solving requires careful consideration of alternatives
Advanced concepts:
- Avoid overuse: typical beginner's mistake
- Important when occur but not common

33. 分組專題 (Design Errors and Table Conversion Problems)
下一週上課前一天中午十二點整交
分組專題#6
第六章 頁 Data Modeling Problems 23
第六章 頁 Conversion Problems 4, 9