ICT200

INTRODUCTION TO DATABASE
MANAGEMENT SYSTEM

By :
Miss Noorfadzilah Arifin

Chapter 4 Entity Relationship (ER) Modeling

The Entity Relationship (ER) Model

 ER model forms the basis of an ER diagram

(ERD)

 ERD represents conceptual database as viewed

by end user

 ERDs depict database’s main components:

➢ Entities (object)

➢ Attributes

➢ Relationships
 Entities

 Refers to entity set and not to single entity

occurrence

 Corresponds to table

 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
 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
 Attributes (continued)

 A required attributes is an attribute that have a

value – it cannot be left empty

 An optional attribute is an attribute that does not

require a value – it can be left empty
Attributes (continued)
 Domains

 Attributes have domain

➢ A domain is the set of possible values for a

given attribute

 Attributes may share a domain

 Identifiers (Primary Keys)

 ERM uses identifiers – one or more attributes that uniquely identify

each entity instance

 In the relational model, such identifiers are mapped to PKs in

tables

 Underlined in the ERD

 Key attributes are also underlined in frequently used table

structure shorthand notation using the format :
✓ TABLE NAME (KEY_ATTRIBUTE 1, ATTRIBUTE 2, ATTRIBUTE 3,
……………….. ATTRIBUTE K)

✓ For example, a CAR entity may be represented by:

✓ CAR (CAR_VIN, MODE_CAR, CAR_YEAR, CAR_COLOR)

(Each car is identified by unique vehicle identification number, or CAR_VIN)
 Composite Identifiers

 Entity identifier ideally is composed of only

single attribute

 It is possible to use a composite key

➢ Primary key composed of more than one

attribute
Composite Identifiers (continued)
Composite Identifiers (continued)

 If CLASS_CODE is used as primary key, the CLASS

entity may be represented in shorthand form by:

✓ CLASS (CLASS_CODE, CRS_CODE, CLASS_SECTION,

CLASS TIME, ROO_CODE. PROF_NUM)

 If CLASS_CODE is deleted and the composite key is

the combination of CRS_CODE and
CLASS_SECTION, the CLASS entity may be
represented:

✓ CLASS (CRS_CODE, CLASS_SECTION, CLASS TIME,

ROO_CODE. PROF_NUM)
Composite and Simple Attributes

 Attributes are classified as:

✓ Composite attribute - can be further subdivided to yield
additional attributes
• Ex: the attribute ADDRESS can be subdivided into street, city,
state, and zip code.
• Ex: the attribute PHONE_NUMBER can be subdivided into area
code and exchange number
✓ Simple attribute - cannot be subdivided
• Ex: age, sex and marital status would classified as simple
attributes
 Single-Valued Attributes

 Single-value attribute can have only a single

value
 Ex: A student can have only one student number, a
manufacturer part can have only one serial number

 Note that a single-valued attribute is not

necessarily a simple attribute.
 Ex: A part’s serial number such as SE-08-02-618154, 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 the region (08)
 Multivalued Attributes

 Multivalued attributes can have many values

✓ Ex: A person may have several college degree and a
household may have several different phones, each its
own number

 In the Chen ERM, the multivalued attributes

are shown by a double line connecting
attributes

 The Crow’s foot notation does not identify

multivalued attributes
Multivalued Attributes (continued)
Resolving Multivalued Attribute Problems

 Although conceptual model can handle M:N

relationships and multivalued attributes, you
should not implement them in relational DBMS

➢ Within original entity, create several new attributes,

one for each of the original multivalued attribute’s
components

◼ Can lead to major structural problems in table

➢ Create new entity composed of original multivalued

attribute’s components
Resolving Multivalued Attribute Problems
(continued)
Resolving Multivalued Attribute Problems
(continued)
Resolving Multivalued Attribute Problems
(continued)
 Derived Attributes

 An attribute may be classified as a derived attribute

(compute attribute)

 Attribute whose value may be calculated (derived) from

other attributes

 Need not be physically stored within database

 Can be derived by using an algorithm

 Ex: An employee’s age, EMP_AGE, maybe found by

computing the integer value of the difference between the
current date and the EMP_DON.
✓ Access’s formula - INT((DATE() - EMP_DOB/365)

✓ Microsoft SQL server, use SELECT DATEDIFF(“YEAR”, EMP_DOB,

GETDATE());
Derived Attributes (continued)
Derived Attributes (continued)
 Relationships

 Association between entities

 Entities that participate in a relationship are also

known as participants

 Relationship name is an active or passive verb`

 Relationships between entities always operate in

both directions

 Relationship classification is difficult to establish

if know only one side of the relationship
 Connectivity and Cardinality

 Connectivity
➢ Used to describe the relationship classification

 Cardinality
➢ Expresses minimum and maximum number of entity
occurrences associated with one occurrence of related entity
➢ In ERD, cardinality is indicated by placing the appropriate
number beside the entities, using the format (x, y). x = min
number of associated entities, y = min number of associated
entities
➢ Cardinality (1, N) indicate there would be no upper limit

 Established by very concise statements known as

business rules
Connectivity and Cardinality (continued)
 Existence Dependence

 Existence dependence
➢ Exist in database only when it is associated with another
related entity occurrence

➢ 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

 Existence independence
➢ Entity can exist apart from one or more related entities

➢ Sometimes refers to such an entity as strong or regular

entity
 Relationship Strength

 Weak (non-identifying) relationships

✓ Exists if PK of related entity does not contain PK
component of parent entity

✓ Ex: COURSE(CRS_CODE, DEPT_CODE,

CRS_DESCRIPTION, CRS_CREDIT)

✓ CLASS(CLASS_CODE, CRS_CODE, CLASS SECTION,

CLASS_TIME, ROOM_CODE, PROF _NUM)

✓ Crow’s Foot notation depicts a weak relationship by

placing a dashed relationship line between the entities
Weak (Non-Identifying) Relationships
 Relationship Strength

 Strong (Identifying) Relationships

➢ Exists when PK of related entity contains PK component of parent
entity

✓ Ex : Ex: COURSE(CRS_CODE, DEPT_CODE,

CRS_DESCRIPTION, CRS_CREDIT)

✓ CLASS(CRS_CODE, CLASS_CODE, CLASS SECTION,

CLASS_TIME, ROOM_CODE, PROF _NUM)

✓ Crow’s Foot notation depicts the strong relationship with a solid

line between the entities

✓ Whether the relationship between COURSE and CLASS is strong

or week depends on how the CLASS entity’s primary key is
defined
Strong (Identifying) Relationships
 Weak Entities

 Weak entity meets two conditions

➢ Existence-dependent

◼ Cannot exist without entity with which it has a

relationship

➢ Has primary key that is partially or totally derived

from parent entity in relationship
 Weak Entities

 In Chen notation, the weak entity identifies by

using a double-walled entity rectangle

 In Crow’s Foot notation, uses the relationship

line

 A strong (identifying) relationship indicates that

the related entity is weak

 Database designer usually determines whether

an entity can be described as weak based on
business rules
Weak Entities (continued)
Weak Entities (continued)
 Relationship Participation

 Optional participation
 One entity occurrence does not require
corresponding entity occurrence in particular
relationship

 In Crow’s Foot notation, shown by drawing a

small circle (o) on the side of the optional entity

 Mandatory participation
 One entity occurrence requires corresponding entity
occurrence in particular relationship
Relationship Participation (continued)
Relationship Participation (continued)
Relationship Participation (continued)
Relationship Participation (continued)
 Relationship Degree

 Indicates number of entities or participants

associated with a relationship
 Unary relationship
➢ Association is maintained within single entity

 Binary relationship
➢ Two entities are associated

 Ternary relationship
➢ Three entities are associated
Relationship Degree (continued)
Relationship Degree (continued)
 Recursive Relationships

 Relationship can exist between occurrences

of the same entity set

 Naturally found within unary relationship

Recursive Relationships
(continued)
Recursive Relationships
(continued)
Recursive Relationships
(continued)
Recursive Relationships
(continued)
Recursive Relationships
(continued)
 Composite Entities

 Also known as bridge entities

 Composed of primary keys of each of the entities

to be connected

 May also contain additional attributes that play no

role in connective process
Composite Entities (continued)
Composite Entities (continued)
Composite Entities (continued)
 Developing an ER Diagram

 Database design is iterative rather than linear or

sequential process

 Iterative process

➢ Based on repetition of processes and procedures

Developing an ER Diagram (continued)

 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
Developing an ER Diagram (continued)

 During the review process, it is likely that

additional entities, attributes and relationships
will be uncovered.

 The process is repeated until the end users and

designers agree that the ERD is a fair
representation of the organization’s activities
and function.
 Developing an ER Diagram (continued)

Tiny College
- Tiny College is divided into several schools. Each school is
administered by a dean who is professor.

- Each school is composed of several department

 Developing an ER Diagram (continued)

Tiny College
- Each department may offer courses
 Developing an ER Diagram (continued)

Tiny College
- A department may offer several classes of the same database course.
- Each of those classes is taught by a professor at a given time in a given
place.
- Each professor may teach up to four classes, each class is a section of a
course.
- A professor may also be a research contract and teach no classes at all
 Developing an ER Diagram (continued)

Tiny College
- 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

- A class can initially exist even though no students have enrolled in it.
 Developing an ER Diagram (continued)

Tiny College
- Each student has only a single major and is associated with a single
department
 Developing an ER Diagram (continued)

Tiny College
- Each student has an advisor in his or her department
- Each advisor counsels several students
- An advisor is also a professor, but not all professor advise students
 Developing an ER Diagram (continued)

Tiny College
- The relationship between class is taught in a room and the room in the
building
Developing an ER Diagram (continued)
 EXERCISE 1
64

Given the following business rules, create the appropriate

Crow’s Foot ERD.

 A company operates many departments.

 Each department employs one or more employees.

 Each of the employees may or may not have one or more

dependents.

 Each employee may or may not have an employment history.

 EXERCISE 2
65

Create an ERD based on the Crow’s Foot model, using the

following requirements:

 A trainee can take more than one class, and each class contains
many trainees.

 A class is taught by only one instructor, but an instructor can teach

up to two classes.

 Finally, a COURSE may generate more than one CLASS, while

each CLASS is based on one COURSE.
 EXERCISE 3
66

Create an ERD using the following requirements:

 A department employs many employees, but each employee is
employed by one department.
 Some employees are not assigned to any department.
 A division operates many departments, but each department is
operated by one division.
 An employee may be assigned many projects, and a project may
have many employees assigned to it.
 A project must have at least one employee assigned to it.
 One of the employees manages each department, and each
department is managed by only one employee.
 One of the employees runs each division, and each division is run
by only one employee.
 EXERCISE 4
67

Create an ERD using the following requirements:

 An INVOICE is written by a SALESREP. Each sales representative
can write many invoices, but each invoice is written by a single
sales representative.

 The INVOICE is written for a single CUSTOMER. However, each

customer can have many invoices.

 An INVOICE can include many detail lines (LINE), which describe

the products bought by the customer.

 The product information is stored in a PRODUCT entity.

 The product’s vendor information is found in a VENDOR entity.

 EXERCISE 5
68

Base on the given figure below, write the business rules

that are reflected to it.
 Advanced Data Modeling

 Extended entity relationship (EER) model is a result

of adding more semantic constructs to original
entity relationship (ER) model

 Diagram using this model is called an EER diagram

(EERD)
 Entity Supertypes and Subtypes

 Entity supertype
 Generic entity type that is related to one or more
entity subtypes

 Contains common characteristics

 Entity subtypes
 Contains unique characteristics of each entity subtype
Entity Supertypes and Subtypes
 Specialization Hierarchy

 Depicts arrangement of higher-level entity supertypes

(parent entities) and lower-level entity subtypes (child
entities)
 Relationships sometimes described in terms of “is - a”
relationships
 Subtype can exist only within context of supertype
and every subtype can have only one supertype to
which it is directly related
 A specialization hierarchy can have many levels of
supertype/subtype relationships
Specialization Hierarchy
 Specialization Hierarchy

 Support attribute inheritance

 Define special supertype attribute known as

subtype discriminator

 Define disjoint/overlapping constraints and

complete/partial constraints
 Inheritance

 Enables entity subtype to inherit attributes and

relationships of supertype

 All entity subtypes inherit their primary key

attribute from their supertype

 At implementation level, supertype and its

subtype(s) depicted in specialization hierarchy
maintain a 1:1 relationship
Inheritance
 Subtype Discriminator

 The attribute in supertype entity that determines to

which entity subtype each supertype occurrence is
related
Disjoint and Overlapping Constraints

 Disjoint subtypes

 Also known as non-overlapping subtypes

 Subtypes that contain unique subset of supertype entity

set (each entity instance of the supertype can appear in
only one of the subtypes

 Overlapping subtypes

 Subtypes that contain nonunique subsets of supertype

entity set (each entity instance of the supertype may
appear in more than one subtype)
Disjoint and Overlapping Constraints
 Completeness Constraint

 Specifies whether each entity supertype occurrence

must also be member of at least one subtype
 Can be partial or total
 Partial completeness - not every supertype
occurrence is a member of a subtype
 There maybe some supertype occurrence that are not
members of any subtype
 Total completeness – every supertype occurrence
must be a member of at least one subtype
Completeness Constraint
 Specialization and Generalization

 Various approaches can be used to develop entity

supertype and subtype:

 Specialization
 Top-down process of identifying lower-level, more specific
entity subtypes from higher-level entity supertype

 Based on grouping unique characteristics and

relationships of the subtypes

 Ex: Specialization is used to identify multiple entity

subtypes from the original employee supertype
 Specialization and Generalization

 Generalization

 Bottom-up process of identifying higher-level, more

generic entity supertype from lower-level entity subtypes

 Based on grouping common characteristics and

relationships of the subtypes

 Ex: musical instruments; piano, violin and guitar. Using the

generalization approach, “string instrument” can be
indentified as entity supertype
 Exercise 1
Elite Corporation is a company specializing in the commercialization of
automotive parts.

 Elite has two types of customers: retail and wholesale. All customers have a
customer ID, a name, an address, a phone number, a default shipping address,
a date of last purchase, and a date of last payment.

 Retail customers have the credit card type, credit card number, expiration date,
and e-mail address.

 Wholesale customers have a contact name, contact phone number, contact e-

mail address, purchase order number and date, discount percentage, billing
address, tax status and tax identification number.

 A retail customer cannot be a wholesale customer and vice versa.

Given that information, create the ERD containing all primary keys, foreign
keys, and main attributes
 Exercise 2
❑ A company has five departments: administration, marketing, sales, shipping,
and purchasing. Each department employs many employees.

❑ Each employee has an ID, a name, a home address, a home phone number,
and a salary and tax ID.

❑ Some employees are classified as sales representatives, some as technical

support, and some as administrators.

❑ Sales representatives receive a commission based on sales. Technical

support employees are required to be certified in their areas of expertise.
For example, some are certified as drivetrain specialists; others, as
electrical systems specialists. All administrators have a title and a bonus.

Given that information, create the ERD containing all primary keys, foreign
keys, and main attributes.
 Exercise 3
The FlyRight Aircraft Maintenance (FRAM) division of the FlyRight Company
(FRC) performs all maintenance for FRC’s aircraft. Produce a data model
segment that reflects the following business rules:

 All mechanics are FRC employees. Not all employees are mechanics.

 Some mechanics are specialized in engine (EN) maintenance. Some mechanics

are specialized in airframe (AF) maintenance. Some mechanics are specialized
in avionics (AV) maintenance.

 All mechanics take periodic training courses to stay current in their areas of
expertise. FRC tracks all courses taken by each mechanic—date, course type,
certification (Y/N), and performance.

 FRC keeps a history of the employment of all mechanics. The history includes
the date hired, date promoted, date terminated, and so on.

Given those requirements, create the Crow’s Foot ERD segment.