1. Chapter 4 Entity Relationship (E-R) Modeling
Database Systems: Design, Implementation, and Management
Peter Rob & Carlos Coronel

2. In this chapter, you will learn:
How relationships between entities are defined and refined, and how such relationships are incorporated into the database design process
How ERD components affect database design and implementation
How to interpret the modeling symbols for the four most popular ER modeling tools
That real-world database design often requires that you reconcile conflicting goals

3. The Entity Relationship (E-R) Model
ER model forms the basis of an ER diagram
ERD represents the conceptual database as viewed by end user
Main Components
Entities
In E-R models an entity refers to the entity set.
An entity is represented by a rectangle containing the entity’s name.
Attributes
Attributes are represented by ovals and are connected to the entity with a line.
Each oval contains the name of the attribute it represents.
Attributes have a domain -- the attribute’s set of possible values.
Attributes may share a domain.
Relationships

4. Entities Refers to entity set and not to single entity occurrence
Corresponds to table and not to row in relational environment
In both Chen and Crow’s Foot models, entity is represented by rectangle containing entity’s name
Entity name, a noun, is usually written in capital letters

5. Attributes Characteristics of entities In Chen model,
attributes are represented by ovals and are connected to entity rectangle with a line
Each oval contains the name of attribute it represents
In Crow’s Foot model, attributes are written in attribute box below entity rectangle

6. The Attributes of the STUDENT Entity

7. Domains Attributes have domain Attributes may share a domain
Domain is attribute’s set of possible values
Attributes may share a domain

8. Primary Keys Underlined in the ER diagram
Key attributes are also underlined in frequently used table structure shorthand
Ideally composed of only a single attribute
Possible to use a composite key :
Primary key composed of more than one attribute

9. Composite Primary Keys (continued)
Primary Keys (CLASS_CODE) Another possible Composite Primary Key (CRS_CODE + CLASS_SECTION)

10. Classes of Attributes A simple attribute cannot be subdivided.
Examples: Age, Sex, and Marital status
A composite attribute can be further subdivided to yield additional attributes.
Examples:
ADDRESS Street, City, State, Zip
PHONE NUMBER  Area code, Exchange number

11. Classes of Attributes Multivalued attributes can have many values.
A single-valued attribute can have only a single value.
Examples:
A person can have only one social security number.
A manufactured part can have only one serial number.
Multivalued attributes can have many values.
A person may have several college degrees.
A household may have several phones with different numbers
Multivalued attributes are shown by a double line connecting to the entity.

12. Multivalued attributes in an Entity

13. Resolving Multivalued Attribute Problems
Although conceptual model can handle M:N relationships and multivalued attributes, you should not implement them in relational DBMS.
Possible courses of action for the designer
Within the original entity, create several new attributes, one for each of the original multivalued attribute’s components ( Figure 4.4).
Create a new entity composed of the original multivalued attribute’s components ( Figure 4.5).

14. Splitting the Multivalued Attribute into New Attributes

15. A New Entity Set Composed of Multivalued Attribute’s Components

16. A New Entity Set Composed of Multivalued Attribute’s Components

17. Derived Attributes A derived attribute
may be calculated (derived) from other attributes
Need not be physically stored within the database
Can be derived by using an algorithm
Example: AGE can be derived from the data of birth and the current date.

18. Depiction of a Derived Attribute

19. Derived Attributes (continued)

20. The Entity Relationship (E-R) Model
Relationships
A relationship is an association between entities.
Relationships are represented by diamond-shaped symbols.

21. Relationships Association between entities
Participants are entities that participate in a relationship
Relationships between entities always operate in both directions
Relationship can be classified as 1:M
Relationship classification is difficult to establish if know only one side of the relationship

22. Connectivity
The term connectivity is used to describe the relationship classification (e.g., one-to-one, one-to-many, and many-to-many).

23. Cardinality
Cardinality expresses the specific number of entity occurrences associated with one occurrence of the related entity.
The minimum and maximum number of entity occurrences
(0,3) for PROFESSOR : a professor may teach 0-3 classes.
(0,35) for CLASS : a class may enroll up to 35 students,
but it is possible for a class to have no currently enrolled students initially.

24. Connectivity and Cardinality in an ERD

25. Connectivity and Cardinality

26. Existence Dependence Existence Dependent Existence independent
Entity exist in database only when it is associated with another related entity occurrence
If an entity’s existence depends on the existence of one or more other entities, it is said to be existence-dependent.
CLASS is existence-dependent on COURSE (parent entity)
EMPLOYEE claims DEPENDENT— DEPENDENT is existence-dependent on EMPLOYEE
Existence independent
Entity can exist apart from one or more related entities
Example:
some of parts are produced “in-house” and other parts are bought from vendors. At least some of the parts are not supplied by a vender.
PART is existence-independent from VENDOR

27. Relationship Strength
針對Existence Dependence再進一步分析：
Weak (non-identifying) relationship
exist if the PK of the related entity doesn’t contain a PK component of the parent entity
COURSE( CRS_CODE, …)
CLASS( CLASS_CODE, …)
Strong (identifying) relationship
PK of the related entity contains a PK component of the parent entity
CLASS( CRS_CODE, CLASS_SECTION, …)
一樣都是existence-dependent
但要分辨出 existence-dependent 的強弱程度

28. A Weak Relationship Between COURSE and CLASS
PK :
PK :

29. A Strong (Identifying) Relationship Between COURSE and CLASS
PK :
PK :

30. Relationship Strength and Weak Entities
A weak entity is an entity that
Is existence-dependent and
Has a primary key that is partially or totally derived from the parent entity in the relationship.
The existence of a weak entity is indicated by a double rectangle.
The weak entity inherits all or part of its primary key from its strong counterpart.

31. A Weak Entity in an ERD
EMPLOYEE( EMP_NUM, EMP_LNAME, EMP_FNAME, EMP_INITIAL, EMP_DOB )
DEPENDENT( EMP_NUM, DEP_NUM, DEP_FNAME, DEP_DOB ) Primary Key
DEP_NUM

32. Weak entity in a Strong Relationship Between DEPENDENT and EMPLOYEE
( EMP_NUM )
( EMP_NUM + DEP_NUM )

33. Weak Entities (continued)

34. Weak entity in a Strong Relationship
Weak relationship
PK of related entity doesn’t contain PK component of parent entity
COURSE( CRS_CODE, …)
CLASS( CLASS_CODE, …)
Strong relationship
PK of related entity contains PK component of parent entity
CLASS( CRS_CODE, CLASS_SECTION, …)
In any case, CLASS is always existence-dependent on COURSE, whether or not it is defined to be weak.
Not Weak entity

35. Weak Entities (continued)

36. Relationship Participation
Optional participation
One entity occurrence does not require a corresponding entity occurrence in a particular relationship.
An optional entity is shown by a small circle on the side of the optional entity.
Mandatory participation
One entity occurrence requires corresponding occurrence in related entity
If no optionality symbol is shown on ERD, it is mandatory

37. Relationship Participation (continued)
CLASS is Optional to PROFESSOR
PROFESSOR is Mandatory to CLASS

38. CLASS is Optional to COURSE
COURSE is Mandatory to CLASS
COURSE and CLASS in a Mandatory Relationship

39. Relationship Participation (continued)
CLASS is Optional to COURSE
COURSE is Mandatory to CLASS

40. Relationship Participation (continued)
COURSE and CLASS in a Mandatory Relationship

41. Relationship Participation (continued)

42. Relationship Degree
A relationship’s degree indicates the number of associated entities or participants.
A unary relationship exists when an association is maintained within a single entity.
A binary relationship exists when two entities are associated.
A ternary relationship exists when three entities are associated.
DOCTOR
DRUG
PATIENT
PRESCRIPTION

43. Relationship Degree (continued)

44. Relationship Degree (continued)
( DRUG_CODE )
( PAT_NUM )
( DOC_ID )

45. Relationship Degree
A ternary relationship exists when three entities are associated.

46. The Implementation of a Ternary Relationship
若 FUND(FUND_ID,FUND_NAME) ，透過 CFR 仍能將所有必要的關係聯繫起來， 但 FUND(FUND_ID,FUND_NAME,CONTRIB_ID,FUND_AMOUNT) 亦有意義， 例如：F2 接受 C3 $10,000 的捐款，還未撥給任何 RECIPIENT
若FUND(FUND_ID,FUND_NAME)亦可，透過CFR仍能將所有必要的關係聯繫起來，
但FUND(FUND_ID,FUND_NAME,CONTRIB_ID,FUND_AMOUNT)亦有意義，
如FIGURE 4.18中：F2接受C3 $10,000的捐款，還未撥給任何RECIPIENT
Researchers

47. Recursive relationship
A recursive relationship is one in which a relationship can exist between occurrences of the same entity set.
A recursive entity is found within a unary relationship.

48. Recursive Relationships

49. 1:1 Recursive relationship
EMPLOYEE is married to EMPLOYEE

50. Recursive Relationships

51. 1:M Recursive relationship PART contains PART
each part is used to create only one rotor assembly
C130 = 4× AA × AB …

52. Recursive Relationships (continued)

53. M:N Recursive relationship
PART Contains PART
A part_ can be used to create several different kinds of other parts
A part_ is itself composed of many parts.
PART
PART
contains
PART
contains
PART
PART
COMPONENT

55. Recursive Relationships

56. M:N Recursive relationship
COURSE Requires COURSE

57. Recursive Relationships

58. Implementation of the 1:M “EMPLOYEE Manages EMPLOYEE” Recursive Relationship

59. Recursive Relationships (continued)

60. The Entity Relationship (E-R) Model
Composite Entities
A composite entity is composed of the primary keys of each of the entities to be connected.
The composite entity serves as a bridge between the related entities.
The composite entity may contain additional attributes.

61. The Entity Relationship (E-R) Model
Composite Entities

62. Converting the M:N Relationship Into Two 1:M Relationships

63. Composite Entities

64. At the start of registration
A class may exist even though it contains no students at all
A student has not yet signed up for any classes.

65. Composite Entities

66. A Composite Entity in the ERD

67. Developing an E-R Diagram
The process of database design is an iterative rather than a linear or sequential process.
Iterative process - based on repetition of processes and procedures.
The process is repeated until the end users and designers agree that the E-R diagram is a fair representation of the organization’s activities and functions.
Narrative- 敘述,講述

68. Developing an ER Diagram
Building an ERD usually involves the following activities:
Create detailed narrative of organization’s description of operations
Identify business rules based on description of operations
Identify main entities and relationships from business rules
Develop initial ERD
Identify attributes and primary keys that adequately describe entities
Revise and review ERD

69. Developing an E-R Diagram
Tiny College Database
Tiny College (TC) is divided into several schools. Each school is administered by a dean.
A 1:1 relationship exists between DEAN and SCHOOL.
Each dean is a member of a group of administrators (ADMINISTRATOR).
Deans also hold professorial rank and may teach a class ( PROFESSOR).
Administrators and professors are also Employees.

70. Developing an E-R Diagram
Tiny College Database (1)
Each school is composed of several departments.
The smallest number of departments operated by a school is one,
and the largest number of departments is indeterminate (N).
Each department belongs to only a single school.

71. Developing an ER Diagram

72. Developing an E-R Diagram
Tiny College Database (2)
Each department offers several courses.
courses is optional to department. (Some departments are research only.)

73. Developing an ER Diagram

74. Developing an E-R Diagram
Tiny College Database (3)
A department may offer several classes of the same course.
A 1:M relationship exists between COURSE and CLASS.
CLASS is optional to COURSE

75. Developing an ER Diagram

76. Developing an E-R Diagram
Tiny College Database (4)
Each department has many professors assigned to it.
One of those professors chairs the department. Only one of the professors can chair the department.
DEPARTMENT is optional to PROFESSOR in the “chairs” relationship.

77. Developing an ER Diagram

78. Developing an E-R Diagram
Tiny College Database (5)
Each professor may teach up to four classes, each one a section of a course.
A professor may also be on a research contract and teach no classes.

79. Developing an ER Diagram

80. Developing an E-R Diagram
Tiny College Database (6)
A student may enroll in several classes, but (s)he takes each class only once during any given enrollment period.
Each student may enroll in up to six classes and each class may have up to 35 students in it.
STUDENT is optional to CLASS.

81. Developing an ER Diagram

82. Developing an E-R Diagram
Tiny College Database (8)
Each department has several students whose major is offered by that department.
Each student has only a single major and associated with a single department.
It is possible, at least for a while, for a student not to declare a major filed of study. DEPARTMENT is optional to STUDENT.

83. Developing an ER Diagram

84. Developing an E-R Diagram
Tiny College Database (8)
Each student has an advisor in his or her department; each advisor counsels several students.
An advisor is also a professor, but not all professors advise students.

85. Developing an ER Diagram

86. Developing an ER Diagram

87. Developing an ER Diagram

88. Diagram from 5th edit.
Not yet updated.

89. Developing an ER Diagram

90. The Challenge of Database Design: Conflicting Goals
Database design must conform to design standards
High processing speeds are often a top priority in database design
Conflicting Goals
Design standards (design elegance)
Processing speed (high-transaction-speed)
require design compromises
Example: 1:1 recursive relationship
Two tables (avoid nulls)
a single table (high speed)
Operational requirements 經營上的

91. MAR_DATE
MAR_PLACE
(1)
MAR_DATE
MAR_PLACE
(2)
(3)

92. The Challenge of Database Design: Conflicting Goals
A recursive 1:1 relationship yields many different solutions.
Your job as a database designer is to use your professional judgment to yield a solution that meets the requirements.
Operational requirements 經營上的

93. Summary Entity relationship (ER) model
Uses ER diagrams to represent conceptual database as viewed by the end user
Three main components
Entities
Relationships
Attributes
Includes connectivity and cardinality notations
Connectivities and cardinalities are based on business rules

94. Summary (continued)
ER symbols are used to graphically depict the ER model’s components and relationships
ERDs may be based on many different ER models
Entities can also be classified as supertypes and subtypes within a generalization hierarchy
Database designers are often forced to make design compromises

95. The Entity Relationship (E-R) Model
Entity Supertypes and Subtypes
Describing the different types of employees within a single entity would be awkward at best.
Example : Aviation business ( Figure 4.27) the special pilot characteristics (EMP_LICENCE, EMP_RATING, EMP_MED_TYPE) would cause a large number of nulls for other employees who are not pilots.

96. Nulls Created by Unique Attributes

97. The Entity Relationship (E-R) Model
Generalization hierarchy
Depicts relationships between higher-level supertype and lower-level subtype entities.
Supertype contains the shared attributes
Subtype contains the unique attributes.
A subtype entity inherits its attributes and its relationships from the supertype entity.

98. A Generalization Hierarchy
Disjoint relationships are indicated by G

99. The Entity Relationship (E-R) Model
Disjoint Supertypes
Also known as non-overlapping subtypes
Subtypes that contain a subset of the supertype entity set
Each entity instance (row) of the supertype can appear in only one of the disjoint subtypes.
The supertype and its subtype(s) maintain a 1:1 relationship.

100. The EMPLOYEE/PILOT Supertype/Subtype Relationship

101. A Generalization Hierarchy with Overlapping Subtypes
Overlapping relationships are indicated by Gs

102. A Comparison of ER Modeling Symbols

103. SUMMARY

104. The Chen Representation of the Invoicing Problem

105. The Crow’s Foot Representation of the Invoicing Problem

106. The Rein85 Representation of the Invoicing Problem

107. The IDEF1X Representation of the Invoicing Problem

108. A Supertype/Subtype Relationship

109. Developing an E-R Diagram
Tiny College Database (0)
Most DBMS do not support supertype/subtype relationship directly.
At the implementation level, designers convert it into a 1:1 relationship.
A PROFESSOR is an EMPLOYEE.
An EMPLOYEE is not required to be a PROFESSOR.
PROFESSOR is optional to EMPLOYEE.
PROFESSOR is existence-dependent on EMPLOYEE, and it inherits its PK from EMPLOYEE. Therefore the relationship between EMPLOYEE and PROFESSOR is strong, while is PROFESSOR a weak entity.

110. A Supertype/Subtype Relationship in an ERD