11e Database Systems

Design, Implementation, and Management

Coronel | Morris

Chapter 4
Entity Relationship (ER)
Modeling
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
 Learning Objectives
§ In this chapter, students will learn:
§ The main characteristics of entity relationship
components
§ How relationships between entities are defined, refined,
and incorporated into the database design process
§ How ERD components affect database design and
implementation
§ That real-world database design often requires the
reconciliation of conflicting goals

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 2
 Entity Relationship Model (ERM)
§ Basis of an entity relationship diagram (ERD)
§ ERD depicts the:
§ Conceptual database as viewed by end user
§ Database’s main components
§ Entities
§ Attributes
§ Relationships
§ Entity - Refers to the entity set and not to a single
entity occurrence

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 3
 Attributes
§ Characteristics of entities
§ Required attribute: Must have a value, cannot be left empty
§ Optional attribute: Does not require a value, can be left
empty
§ Domain - Set of possible values for a given attribute
§ Identifiers: One or more attributes that uniquely identify
each entity instance
§ TABLE NAME (KEY_ATTRIBUTE 1, ATTRIBUTE 2,
ATTRIBUTE 3, … ATTRIBUTE K)
§ For example, a CAR entity may be represented
by:CAR (CAR_VIN, MOD_CODE, CAR_YEAR,
CAR_COLOR)
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 4
 Figure 4.1 - The Attributes of the Student
Entity: Chen and Crow’s Foot

The two boldfaced attributes in the Crow’s Foot notation indicate that data entry will be required.
STU_LNAME and STU_FNAME require data entries because all students are assumed to have
a last name and a first name.

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 5
 Attributes
§ Composite identifier: Primary key composed of more than
one attribute
§ Composite attribute: Attribute that can be subdivided to
yield additional attributes
§ For example, the attribute ADDRESS can be subdivided into
street, city, state, and zip code.
§ Simple attribute: Attribute that cannot be subdivided
§ Single-valued attribute: Attribute that has only a single
value
§ Multivalued attributes: Attributes that have many values
§ For instance, a person may have several college degrees, and a
household may have several different phones, each with its own
number.

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 6
 The CLASS Table (Entity)
PK Components and Contents

Composite Identifier (Composite Primary Key) – Candidate Key

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
 Notation
§ If the CLASS_CODE in previous slide is used as the primary
key, the CLASS entity may be represented in shorthand form
as follows:
CLASS (CLASS_CODE, CRS_CODE, CLASS_SECTION,
CLASS_TIME, ROOM_CODE, PROF_NUM)

§ If CLASS_CODE is deleted, and the composite primary key is

the combination of CRS_CODE and CLASS_SECTION, the
CLASS entity may be represented as follows:
CLASS (CRS_CODE, CLASS_SECTION, CLASS_TIME,
ROOM_CODE, PROF_NUM)

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
 Figure 4.3 - A Multivalued Attribute in an
Entity

In the Chen ERM, multivalued attributes are shown by a double line connecting the attribute to the
entity. The Crow’s Foot notation does not identify multivalued attributes.

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 9
 Attributes
§ Multivalued attributes: Attributes that have many
values and require creating:
§ Several new attributes, one for each component of the
original multivalued attribute
§ A new entity composed of the original multivalued
attribute’s components
§ Derived attribute: Attribute whose value is calculated
from other attributes
§ Derived using an algorithm
§ For example, an employee’s age, EMP_AGE, may be found
by computing the integer value of the difference between
the current date and the EMP_DOB.
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 10
 Implementing Multivalued
Attributes
§ Splitting the Multivalued Attribute into New
Attributes (leading to major structural problems in
the table)

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
 Create a new entity composed of the original
multivalued attribute’s components.
§ This new entity allows the designer to define color
for different sections of the car. (See Table 4.1.)
Then, this new CAR_COLOR entity is related to the
original CAR entity in a 1:M relationship.

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
 A New Entity Set Composed of a
Multivalued Attribute’s Components
§ The preferred way to deal with multivalued attributes.
Creating a new entity in a 1:M relationship with the
original entity yields several benefits: it is a more
flexible, expandable solution, and it is compatible
with the relational model!

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
 Figure 4.6 - Depiction of a Derived
Attribute

A derived attribute is indicated in the Chen notation by a dashed line that connects the attribute
and the entity. (See Figure 4.6.) The Crow’s Foot notation does not have a method for
distinguishing the derived attribute from other attributes.

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 14
Table 4.2 - Advantages and Disadvantages of
Storing Derived Attributes

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 15
 Relationships
§ Association between entities that always operate in both directions
§ The relationship name is an active or passive verb
§ Participants: Entities that participate in a relationship
§ Connectivity: Describes the relationship classification
§ The relationship classification is difficult to establish if you know only
one side of the relationship. For example, if you specify that:
A DIVISION is managed by one EMPLOYEE.
§ You don’t know if the relationship is 1:1 or 1:M.
§ Cardinality: Expresses the minimum and maximum number of entity
occurrences associated with one occurrence of related entity
§ In the ERD, cardinality is indicated by placing the appropriate numbers
beside the entities, using the format (x,y). The first value represents the
minimum number of associated entities, while the second value
represents
©2015 the
Cengage Learning. All Rightsmaximum
Reserved. May not be number ofduplicated,
scanned, copied or associated entities.
or posted to a publicly accessible website, in whole or in part. 16
 Figure 4.7 - Connectivity and Cardinality in
an ERD the DBMS cannot handle the
implementation of the cardinalities
at the table level—that capability is
provided by the application software
or by triggers.

The cardinality (1,4) next to the CLASS entity in the “PROFESSOR teaches CLASS” relationship
indicates that each professor teaches up to four classes, which means that the PROFESSOR
table’s primary key value occurs at least once and no more than four times as foreign key values
in the CLASS table.
The cardinality (1,1) next to the PROFESSOR entity indicates that each class is taught by one and
only one professor. That is, each CLASS entity occurrence is associated with one and only one entity
occurrence in PROFESSOR.
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 17
 Existence Dependence

Existence dependence Existence independence

• Entity exists in the • Entity exists apart from

database only when it is all of its related entities
associated with another • Referred to as a strong
related entity occurrence entity or regular entity

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 18
 Cont.
§ In implementation terms, an entity is existence-
dependent if it has a mandatory foreign key—that is,
a foreign key attribute that cannot be null.
§ For example, if an employee wants to claim one or
more dependents for tax-withholding purposes, the
relationship “EMPLOYEE claims DEPENDENT”
would be appropriate. In that case, the DEPENDENT
entity is clearly existence-dependent on the
EMPLOYEE entity because it is impossible for the
dependent to exist apart from the EMPLOYEE in the
database.
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
 Existence-independent Example
§ Suppose that the XYZ Corporation uses parts to
produce its products.
§ Furthermore, suppose that some of those parts are
produced in-house and other parts are bought from
vendors.
§ In that scenario, it is quite possible for a PART to
exist independently from a VENDOR in the
relationship “PART is supplied by VENDOR,”
because at least some of the parts are not supplied by
a vendor. Therefore, PART is existence-independent
from VENDOR.
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
 Relationship Strength

Weak (non-identifying) relationship

• Primary key of the related entity does not contain a primary

key component of the parent entity

Strong (identifying) relationships

• Primary key of the related entity contains a primary key

component of the parent entity

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 21
Week (Non-Identifying) Relationships
§ For example, suppose the 1:M relationship between COURSE
and CLASS is defined as:
COURSE (CRS_CODE, DEPT_CODE,
CRS_DESCRIPTION, CRS_CREDIT)
CLASS (CLASS_CODE, CRS_CODE, CLASS_SECTION,
CLASS_TIME, ROOM_CODE, PROF_NUM)
§ A weak relationship exists between COURSE and CLASS
because CRS_CODE (the primary key of the parent entity) is
only a foreign key in the CLASS entity.
§ In this example, the CLASS primary key did not inherit a
primary key component from the COURSE entity.

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
Figure 4.8 - A Weak (Non-Identifying)
Relationship between COURSE and
CLASS
The Crow’s Foot notation depicts a weak
relationship by placing a dashed relationship
line between the entities.

FK

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
 Strong (Identifying) Relationships
§ For example, suppose the 1:M relationship between COURSE and CLASS
is defined as:
COURSE (CRS_CODE, DEPT_CODE, CRS_DESCRIPTION,
CRS_CREDIT)
CLASS (CRS_CODE, CLASS_SECTION, CLASS_TIME,
ROOM_CODE, PROF_NUM)
§ In this case, the CLASS entity primary key is composed of CRS_CODE
and CLASS_SECTION. Therefore, a strong relationship exists between
COURSE and CLASS because CRS_CODE (the primary key of the parent
entity) is a primary key component in the CLASS entity.
§ In other words, the CLASS primary key did inherit a primary key
component from the COURSE entity. (Note that the CRS_CODE in
CLASS is also the FK to the COURSE entity.)

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
 Figure 4.9 - A Strong (Identifying)
Relationship between COURSE and
CLASS
The Crow’s Foot notation
depicts the strong (identifying)
relationship with a solid line
between the entities.

CLASS is a weak entity by definition.

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 25
 Table 4.3 - Crow’s Foot Symbols

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 26
 Weak Entity
§ Conditions
§ Existence-dependent
§ For example, a company insurance policy insures an employee and
any dependents. For the purpose of describing an insurance policy, an
EMPLOYEE might or might not have a DEPENDENT, but the
DEPENDENT must be associated with an EMPLOYEE. Moreover,
the DEPENDENT cannot exist without the EMPLOYEE; that is, a
person cannot get insurance coverage as a dependent unless the
person is a dependent of an employee.
§ Has a primary key that is partially or totally derived from parent entity
in the relationship
§ Database designer determines whether an entity is weak based on business
rules

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 27
Figure 4.10 - A Weak Entity in an ERD

DEPENDENT is the weak entity in the relationship “EMPLOYEE has DEPENDENT.”

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 28
Figure 4.11 - A Weak Entity in a Strong
Relationship

Jeanine J. Callifante claims two dependents, Annelise and Jorge.

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 29
 Relationship Participation

Optional participation
• One entity occurrence does not require a
corresponding entity occurrence in a particular
relationship

Mandatory participation
• One entity occurrence requires a corresponding entity
occurrence in a particular relationship

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 30
 Optional Participation Example
§ In the “COURSE generates CLASS” relationship, you noted that at
least some courses do not generate a class.
§ In other words, an entity occurrence (row) in the COURSE table
does not necessarily require the existence of a corresponding entity
occurrence in the CLASS table. (Remember that each entity is
implemented as a table.)
§ Therefore, the CLASS entity is considered to be optional to the
COURSE entity.
§ In Crow’s Foot notation, an optional relationship between entities is
shown by drawing a small circle (O) on the side of the optional
entity.
§ The existence of an optional entity indicates that its minimum
cardinality is 0.
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
 Table 4.3 - Crow’s Foot Symbols

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 32
 An Optional CLASS Entity in the
Relationship “PROFESSOR Teaches
CLASS”

Suppose that Tiny College employs some professors who conduct research without teaching classes. If you
examine the “PROFESSOR teaches CLASS” relationship, it is quite possible for a PROFESSOR not to teach
a CLASS. Therefore, CLASS is optional to PROFESSOR. On the other hand, a CLASS must be taught by a
PROFESSOR. Therefore, PROFESSOR is mandatory to CLASS.

The ERD model in Figure 4.12 shows the cardinality next to CLASS to be (0,3), indicating that a professor may
teach no classes or as many as three classes. Also, each CLASS table row references one and only one
PROFESSOR row—assuming each class is taught by one and only one professor—represented by the (1,1)
cardinality next to the PROFESSOR table.

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
 Figure 4.13 - CLASS is Optional to
COURSE

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 34
Figure 4.14 - COURSE and CLASS in a
Mandatory Relationship

Each COURSE generates one or more CLASSes.

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 35
 Relationship Degree
§ Indicates the number of entities or participants
associated with a relationship
§ Unary relationship: Association is maintained
within a single entity
§ Recursive relationship: Relationship exists between
occurrences of the same entity set
§ E.g. an employee within the EMPLOYEE entity is the
manager for one or more employees within that entity.
§ Binary relationship: Two entities are associated
§ Ternary relationship: Three entities are associated
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 36
Figure 4.15 - Three Types of Relationship
Degree

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
37
The Implementation of a Ternary
Relationship

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
 Explanation
§ The relationships and their consequences are
represented by the following business rules:
§ A DOCTOR writes one or more PRESCRIPTIONs.
§ A PATIENT may receive one or more
PRESCRIPTIONs.
§ A DRUG may appear in one or more
PRESCRIPTIONs. (To simplify this example, assume
that the business rule states that each prescription
contains only one drug. In short, if a doctor prescribes
more than one drug, a separate prescription must be
written for each drug.)
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
 Figure 4.17 - An ER Representation of
Recursive Relationships

A recursive relationship is one in which a relationship can exist between occurrences of the same entity set.

A 1:1 unary relationship may be expressed by “an EMPLOYEE may be married to one and only one other EMPLOYEE.”

A 1:M unary relationship can be expressed by “an EMPLOYEE may manage many EMPLOYEEs, and each EMPLOYEE is
managed by one EMPLOYEE.”

The M:N unary relationship may be expressed by “a COURSE may be a prerequisite to many other COURSEs, and each
COURSE may have many other COURSEs as prerequisites.”

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 40
 The 1:1 Recursive Relationship
“EMPLOYEE is Married to
EMPLOYEE”

Note that you can determine that James Ramirez is married to Louise Ramirez,
who is married to James Ramirez. Also, Anne Jones is married to Anton Shapiro,
who is married to Anne Jones.

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
 Another Unary Relationship: “PART
Contains PART”

A rotor assembly (C-130) is composed of many parts, but each part is used to create
only one rotor assembly.

Figure 4.19 indicates that a rotor assembly is composed of four 2.5-cm washers, two
cotter pins, one 2.5-cm steel shank, four 10.25-cm rotor blades, and two 2.5-cm hex nuts.

The relationship implemented in Figure 4.19 enables you to track each part within each
rotor assembly.
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
 Implementation of the M:N Recursive
Relationship “PART Contains PART”

If a part can be used to assemble several

different kinds of other parts and is itself
composed of many parts, two tables are
required to implement the “PART contains
PART” relationship.

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
 Implementation of the M:N Recursive
Relationship “COURSE Requires COURSE”

MATH-243 is a prerequisite to QM-261 and QM-362, while both MATH-243 and

QM-261 are prerequisites to QM-362.

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
 Implementation of the 1:M Recursive
Relationship “EMPLOYEE Manages
EMPLOYEE”

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
 Associative Entities
§ Also known as composite or bridge entities
§ Used to represent an M:N relationship between two
or more entities
§ Is in a 1:M relationship with the parent entities
§ Composed of the primary key attributes of each parent
entity
§ May also contain additional attributes that play no
role in connective process

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 46
Figure 4.23 - Converting the M:N Relationship
into Two 1:M Relationships

Note that the composite ENROLL entity in Figure 4.23 is

existence-dependent on the other two entities; the composition
of the ENROLL entity is based on the primary keys of the entities
that are connected by the composite entity.

The ENROLL table’s key (CLASS_CODE and STU_NUM) is

composed entirely of the primary keys of the CLASS and STUDENT
tables. Therefore, no null entries are possible in the ENROLL table’s
key attributes.

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 47
Figure 4.25 - A Composite Entity in an
ERD

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 48
 Developing an ER Diagram
§ Create a detailed narrative of the organization’s
description of operations
§ Identify business rules based on the descriptions
§ Identify main entities and relationships from the
business rules
§ Develop the initial ERD
§ Identify the attributes and primary keys that
adequately describe entities
§ Revise and review ERD

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 49
 Tiny College Business Rules
§ Tiny College (TC) is divided into several schools: business, arts and
sciences, education, and applied sciences. Each school is administered by a
dean who is a professor. Each professor can be the dean of only one school,
and a professor is not required to be the dean of any school. Therefore, a
1:1 relationship exists between PROFESSOR and SCHOOL. Note that the
cardinality can be expressed by writing (1,1) next to the entity
PROFESSOR and (0,1) next to the entity SCHOOL.
§ Each school comprises several departments. For example, the school of
business has an accounting department, a management/marketing
department, an economics/finance department, and a computer information
systems department. Note again the cardinality rules: The smallest number
of departments operated by a school is one, and the largest number of
departments is indeterminate (N). On the other hand, each department
belongs to only a single school; thus, the cardinality is expressed by (1,1).
That is, the minimum number of schools to which a department belongs is
one, as is the maximum number.
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
 Figure 4.26 - The First Tiny College ERD
Segment

It is worth repeating that the existence of 1:1 relationships

often indicates a misidentification of attributes as entities.

In this case, the 1:1 relationship could easily be eliminated

by storing the dean’s attributes in the SCHOOL entity.

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 51
 Tiny College Business Rules
§ Each department may offer courses. For example, the
management/marketing department offers courses
such as Introduction to Management, Principles of
Marketing, and Production Management.

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
Figure 4.27 - The Second Tiny College
ERD Segment

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 53
Figure 4.28 - The Third Tiny College ERD
Segment

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 54
 Figure 4.29 - The Fourth Tiny College ERD
Segment

One and only one of those professors chairs the department, and no professor is required to accept the chair position.
Therefore, DEPARTMENT is optional to PROFESSOR in the “chairs” relationship.

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 55
 Figure 4.30 - The Fifth Tiny College ERD
Segment

Each professor may teach up to four classes; each class is a section of a course.

A professor may also be on a research contract and teach no classes at all.

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 56
 Figure 4.31 - The Sixth Tiny College ERD
Segment

Each student may enroll in up to six classes, and each class may have up to 35 students, thus creating an M:N relationship between
STUDENT and CLASS.

Because a CLASS can initially exist at the start of the enrollment period even though no students have enrolled in it, STUDENT is
optional to CLASS in the M:N relationship.

If a class exists but has no students enrolled in it, that class does not occur in the ENROLL table. Note also that the ENROLL entity is
weak: it is existence-dependent, and its (composite) PK is composed of the PKs of the STUDENT and CLASS entities.

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 57
 Figure 4.32 - The Seventh Tiny College
ERD Segment

In the Tiny College environment, it is possible—at least for a while—for a student not to declare a major field of study. Such a student
would not be associated with a department; therefore, DEPARTMENT is optional to STUDENT. It is worth repeating that the
relationships between entities and the entities themselves reflect the organization’s operating environment. That is, the business rules
define the ERD components.

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 58
 Figure 4.33 - The Eighth Tiny College ERD
Segment

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. Therefore, STUDENT is optional to PROFESSOR in the “PROFESSOR advises STUDENT”
relationship.

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 59
 Figure 4.34 - The Ninth Tiny College ERD
Segment

Given the naming conventions, it is clear that ROOM_CODE is an FK to another entity.

In this ERD segment, it is clear that some buildings do not contain (class) rooms. For example, a storage building might not
contain any named rooms at all.

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 60
 Table 4.4 - Components of the ERM
Once you have discovered the relevant entities, you can define the initial set of relationships among them. Next, you describe the
entity attributes. Identifying the attributes of the entities helps you to better understand the relationships among entities.

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 61
 Connectivity and Cardinality
§ You must also define the connectivity and cardinality
for the just-discovered relations based on the business
rules. However, to avoid crowding the diagram, the
cardinalities are not shown.

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
The Completed Tiny College ERD

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
 Database Design Challenges:
Conflicting Goals
Database design must conform to design standards

Need for high processing speed may limit the number and
complexity of logically desirable relationships

Need for maximum information generation may lead to loss of

clean design structures and high transaction speed

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 64
The Conceptual UML Class Diagram
for Tiny College

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
The Implementation-ready UML Class
Diagram for Tiny College

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
Figure 4.38 - Various Implementations of
the 1:1 Recursive Relationship

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 67
 Problems
§ The EMPLOYEE_V1 table in Figure 4.38 is likely to yield data anomalies.
For example, if Anne Jones divorces Anton Shapiro, two records must be
updated—by setting the respective EMP_SPOUSE values to null—to
properly reflect that change. If only one record is updated, inconsistent data
occur. The problem becomes even worse if several of the divorced
employees then marry each other. In addition, that implementation also
produces undesirable nulls for employees who are not married to other
employees in the company.
§ Another approach would be to create a new entity shown as
MARRIED_V1 in a 1:M relationship with EMPLOYEE. (See Figure
4.38.) This second implementation does eliminate the nulls for employees
who are not married to other employees in the same company. (Such
employees would not be entered in the MARRIED_V1 table.) However,
this approach still yields possible duplicate values.

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
 Cont.
§ As you can see, the first two implementations yield several problems:
§ Both solutions use synonyms. The EMPLOYEE_V1 table uses
EMP_NUM and EMP_SPOUSE to refer to an employee. The
MARRIED_V1 table uses the same synonyms.
§ Both solutions are likely to produce redundant data. For example, it is
possible to enter employee 345 as married to employee 347 and to enter
employee 347 as married to employee 345.
§ Both solutions are likely to produce inconsistent data. For example, it is
possible to have data pairs such as 345,347 and 348,345 and 347,349,
none of which will violate entity integrity requirements because they are
all unique. However, this solution would allow any one employee to be
married to multiple employees.

©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
 Problem with the third approach
§ It requires the collection of additional data regarding
the employees’ marriage—the marriage date. If the
business users do not need this data, then requiring
them to collect it would be inappropriate. To ensure
that an employee occurs only once in any given
marriage, you would have to create a unique index on
the EMP_NUM attribute in the MARPART table.
Another potential problem with this solution is that
the database implementation would theoretically
allow more than two employees to “participate” in
the same marriage.
§ ©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.