Database

Week 4 – Entity Relationship (ER) Modeling I

Dr. Hasan TINMAZ
Woosong University
Endicott College of International Studies
 This week, you 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.

2
 Entity Relationship Model (ERM)
 Data modeling is the first step in the database design journey, serving as a
bridge between real-world objects and the database model that is implemented
in the computer.
 Therefore, the importance of data-modeling details, expressed graphically
through entity relationship diagrams (ERDs), cannot be overstated.
 Basis of an entity relationship diagram (ERD)
 ERD depicts the:
 Conceptual database as viewed by end user
 Database’s main components; Entities – Attributes – Relationships.

3
 Entities
 An entity is an object of interest to the end user.
 That is why sometimes an entity could be called as an object.
 An entity actually refers to the entity set and not to a single entity
occurrence.
 In other words, an entity in the ERM corresponds to a table - not
to a row - in the relational environment.
 The ERM refers to a table row as an entity instance or entity
occurrence.
 In the Chen, Crow’s Foot, and UML notations, an entity is
represented by a rectangle that contains the entity’s name.
 The entity name, a noun, is usually written in all capital letters.

4
 Attributes
 Attributes are the 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.
 For example, the domain for a grade point average (GPA) attribute
is written (0,4) because the lowest possible GPA value is 0 and the
highest possible value is 4.

5
 The Attributes of the Student Entity:
Chen and Crow’s Foot

Because the Chen representation consumes more space, software vendors have adopted the
Crow’s Foot attribute display.

These boldfaced attributes in the Crow’s Foot notation

However, students might not have a middle name, and
indicate that data entry will be required.
perhaps they do not yet have a phone number and an
STU_LNAME and STU_FNAME require data entries
email address. Therefore, those attributes are not
because all students are assumed to have a last name
presented in boldface in the entity box.
and a first name.
6
 Identifiers (Primary Keys)
 The ERM uses identifiers - one or more attributes that uniquely identify
each entity instance.
 In the relational model, entities are mapped to tables, and the entity
identifier is mapped as the table’s primary key (PK).
 Key attributes are also underlined in a frequently used shorthand
notation for the table structure, called a relational schema, that uses the
following format:
 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)
 Each car is identified by a unique vehicle identification number, or
CAR_VIN.
7
 Composite Identifiers

 An entity identifier is composed of only a single attribute.

 For example, the table in the figure uses a single-attribute primary key named CLASS_CODE.
 However, it is possible to use a composite identifier, a primary key composed of more than one
attribute.
 For instance, the Tiny College database administrator may decide to identify each CLASS entity
instance (occurrence) by using a composite primary key of CRS_CODE and
CLASS_SECTION instead of using CLASS_CODE.
 Either approach uniquely identifies each entity instance.
8
 Composite Identifiers

9
 Composite and Simple Attributes
 Attributes are classified as simple or composite.
 A composite attribute is an attribute that can be further
subdivided to yield additional attributes.
 For example, the attribute ADDRESS can be subdivided into
street, city, state, and zip code.
 Similarly, the attribute PHONE_NUMBER can be subdivided into
area code and exchange number.
 A simple attribute is an attribute that cannot be subdivided.
 For example, age, gender, and marital status would be classified as
simple attributes.
 To facilitate detailed queries, it is wise to change composite
attributes into a series of simple attributes.
10
 Single-Valued Attributes
 A single-valued attribute is an attribute that can have only a single
value.
 For example, a person can have only one Social Security number,
and a manufactured part can have only one serial number.
 Keep in mind that a single-valued attribute is not necessarily a simple
attribute.
 For instance, a part’s serial number (such as SE-08-02-189935) is
single-valued, but it is a composite attribute because it can be
subdivided into the region in which the part was produced (SE),
the plant within that region (08), the shift within the plant (02),
and the part number (189935).

11
 Multivalued Attributes
 Multivalued attributes are attributes that can 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.
 Similarly, a car’s color may be subdivided into many colors for the roof, body, and
trim.
 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.

12
 Derived Attributes
 A derived attribute is an attribute whose value is calculated (derived)
from other attributes.
 The derived attribute need not be physically stored within the
database; instead, it can be derived by 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.
 If you use Microsoft Access, you will use the formula INT((DATE() –
EMP_DOB)/365).
 In Microsoft SQL Server, you would use
 DATEDIFF(“DAY”, EMB_DOB, GETDATE())/365, where
DATEDIFF is a function that computes the difference between dates.
13
 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.
The Crow’s Foot notation does not have a method for
distinguishing the derived attribute from other attributes.
14
 Relationships
 A relationship is an association between entities that always
operate in both directions.
 Participants: Entities that participate in a relationship.
 Each relationship is identified by a name that describes the
relationship.
 The relationship name is an active or passive verb; for example;
 a STUDENT takes a CLASS,
 a PROFESSOR teaches a CLASS,
 a DEPARTMENT employs a PROFESSOR,
 a DIVISION is managed by an EMPLOYEE, and
 an AIRCRAFT is flown by a CREW.

15
 Connectivity and Cardinality
 We learned that entity relationships may be classified as
one-to-one, one-to-many, or many-to-many.
 We also learned how such relationships were depicted in
the Chen and Crow’s Foot notations.
 The term connectivity is used to describe the
relationship classification.
 Cardinality is a property that assigns a specific value to
connectivity and expresses the range of allowed entity
occurrences associated with a single occurrence of the
related entity.
16
 Connectivity and Cardinality in an ERD

For example, 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.
Knowing the minimum and maximum number of entity occurrences is very useful at the application
software level. For example, Tiny College might want to ensure that a class is not taught unless it has at least
17
10 students enrolled. Similarly, if the classroom can hold only 30 students, the application software should
use that cardinality to limit enrollment in the class.
 Existence Dependence
Existence dependence Existence independence
• Entity exists in the database only when • Entity exists apart from all of its related
it is associated with another related entities.Aka strong or regular entity.
entity occurrence. • For example, suppose that the XYZ
• For example, if an employee wants to Corporation uses parts to produce its
claim one or more dependents for tax- products.
withholding purposes, the relationship • Furthermore, suppose that some of those
“EMPLOYEE claims DEPENDENT” parts are produced in-house and other
would be appropriate. parts are bought from vendors.
• In that scenario, it is quite possible for a
• In that case, the DEPENDENT entity PART to exist independently from a
is clearly existence-dependent on the VENDOR in the relationship “PART is
EMPLOYEE entity because it is supplied by VENDOR” because at least
impossible for the dependent to exist some of the parts are not supplied by a
apart from the EMPLOYEE in the vendor.
database. • Therefore, PART is existence-
18 independent fromVENDOR.
 Relationship Strength
 The concept of relationship strength is not part of the original ERM.
 Instead, this concept applies directly to Crow’s Foot diagrams.
 Because Crow’s Foot diagrams are used extensively to design relational
databases, it is important to understand relationship strength as it affects
database implementation.
 The concept of relationship strength is based on how the primary key of a
related entity is defined.
 To implement a relationship, the primary key of one entity (the parent entity,
normally on the “one” side of the one-to-many relationship) appears as a foreign
key in the related entity (the child entity, mostly the entity on the “many” side
of the one-to-many relationship).
 Sometimes, the foreign key also is a primary key component in the related
entity.

19
 Weak (Non-Identifying) Relationships
 A weak relationship, also known as a non-identifying relationship, exists if the
primary key of the related entity does not contain a primary key component of
the parent entity.
 By default, relationships are established by having the primary key of the parent
entity appear as a foreign key (FK) on the related entity (also known as the child
entity).
 For example, suppose the 1:M relationship between COURSE and CLASS is
defined as:

20
 Weak (Non-Identifying) Relationships
Figure shows how the
Crow’s Foot notation
depicts a weak
relationship by placing a
dashed relationship line
between the entities.

The tables shown below

the ERD illustrate how
such a relationship is
implemented.
21
 Strong (Identifying) Relationships
 A strong (identifying) relationship exists when the primary key of the related entity
contains a primary key component of the parent entity.
 For example, suppose the 1:M relationship between COURSE and CLASS is
defined as:

 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.)

22
 Strong (Identifying) Relationships
The Crow’s Foot notation
depicts the strong
(identifying) relationship
with a solid line between
the entities, as shown in
Figure.

As you examine figure, you

might wonder what the O
symbol next to the CLASS
entity signifies.
You will discover the
meaning of this cardinality in
Relationship Participation.

23
 In summary,
 … whether the relationship between COURSE and
CLASS is strong or weak depends on how the CLASS
entity’s primary key is defined.
 Remember that the nature of the relationship is often
determined by the database designer, who must use
professional judgment to determine which relationship
type and strength best suit the database transaction,
efficiency, and information requirements.
 That point will be emphasized in detail!

24
 Weak Entity
 In contrast to the strong or regular entity mentioned
before, a weak entity is one that meets two conditions:
 The entity is existence-dependent; it cannot exist
without the entity with which it has a relationship.
 The entity has a primary key that is partially or totally
derived from the parent entity in the relationship.
 Database designer determines whether an entity is weak
based on business rules.

25
 A Weak Entity in an ERD
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.

DEPENDENT is the weak entity in the

relationship “EMPLOYEE has
DEPENDENT.”
The Chen notation identifies the weak entity by using a double-walled entity rectangle.
The Crow’s Foot notation generated by Visio Professional uses the relationship line and the PK/FK
26 designation to indicate whether the related entity is weak.
 Relationship Participation
Participation in an entity relationship is either optional or mandatory.
Recall that relationships are bidirectional; that is, they operate in both directions.

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. For example, an EMPLOYEE works in a
DIVISION. (A person cannot be an employee without being assigned
to a company’s division.)
27
 CLASS is Optional to COURSE

An entity occurrence (row) in the COURSE table does not necessarily require the
existence of a corresponding entity occurrence in the CLASS table.
For example, a course can be cancelled at any semester.

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, as
illustrated in figure.

The existence of an optional entity indicates that its minimum cardinality is

28 0.
 COURSE and CLASS in a Mandatory
Relationship

• If no optionality symbol is depicted with the entity, the entity is assumed

to exist in a mandatory relationship with the related entity.
• If the mandatory participation is depicted graphically, it is typically
shown as a small hash mark across the relationship line, like the Crow’s
Foot depiction of a connectivity of 1.
• The existence of a mandatory relationship indicates that the minimum
cardinality is at least 1 for the mandatory entity.
29
 Crow’s Foot Symbols

CLASS is optional. It is possible for the department to create

the COURSE entity first and then create the CLASS entity
after making the teaching assignments. In the real world, such
a scenario is very likely; there may be courses for which
sections (classes) have not yet been defined. In fact, some
courses are taught only once a year and do not generate classes
each semester.
CLASS is mandatory. This condition is created by the
constraint imposed by the semantics of the statement “Each
COURSE generates one or more CLASSes.” In ER terms, each
COURSE in the “generates” relationship must have at least one
CLASS. Therefore, a CLASS must be created as the COURSE
30
is created to comply with the semantics of the problem.
 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
 Binary relationship:Two entities are associated
 Ternary relationship:Three entities are associated

31
 Three Types of Relationship Degree
The existence of the “manages”
relationship means that
EMPLOYEE requires another
EMPLOYEE to be the manager—
that is, EMPLOYEE has a
relationship with itself.

“a PROFESSOR teaches one or

more CLASSes”

•A DOCTOR writes one or more

PRESCRIPTIONs.
•A PATIENT may receive one or
more PRESCRIPTIONs.
•A DRUG may appear in one or more
PRESCRIPTIONs.
32
 An ER Representation of Recursive
Relationships
A recursive relationship is one in which a relationship can exist between
occurrences of the same entity set.

• Since polygamy is not legal, 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
33 COURSEs as prerequisites.”
 An ER Representation of Recursive
Relationships

The 1:1 relationship shown in previous figure can be implemented in the single
table shown in figure above.
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.

34
 Associative Entities
 M:N relationships are a valid construct at the conceptual level, and
therefore are found frequently during the ER modeling process.
 However, implementing the M:N relationship, particularly in the
relational model, requires the use of an additional entity.
 Associative Entities also known as composite or bridge entities are
used to represent an M:N relationship between two or more
entities.
 When using the Crow’s Foot notation, the associative entity is
identified as a strong (identifying) relationship, as indicated by the
solid relationship lines between the parents and the associative
entity.

35
 Converting the M:N Relationship into Two
1:M Relationships

Composite ENROLL entity in this

figure 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.

36
 A Composite Entity in an ERD

As students begin to sign up for their classes, they will be entered into the ENROLL entity.
Naturally, if a student takes more than one class, that student will occur more than once in
ENROLL. On the other hand, each student occurs only once in the STUDENT entity.
Therefore, in Figure above, the relationship between STUDENT and ENROLL is shown to be
1:M, with the “M” on the ENROLL side.
As you can see in Figure above, a class can occur more than once in the ENROLL table.
However, CLASS_CODE = 10014 can occur only once in the CLASS table to reflect
that the relationship between CLASS and ENROLL is 1:M.
Note that in Figure above, the “M” is located on the ENROLL side, while the “1” is
37
located on the CLASS side.
 Explain the following ERM

38
 Draw a simple ERM of followings:
Develop an ERD of a small banking
management system with the following
entities
1. Customer (Name, ID, Amount, Loan)
2. Account (ID,Type)
3. Bank (ID, Name, Address)
4. ATM (ID, Address)

39
 Reference:
 Coronel, C. & Morris, S.
(2019). Database Systems
Design Implementation and
Management (13th ed.)
Cengage Learning.

40