DFC20203
DATABASE DESIGN
CHAPTER 3
ENTITY RELATIONSHIP MODEL (ER)
MODEL & NORMALIZATION
3.1 Apply the normalization concept
3.2 Apply ER diagrams in database development
Course Learning Outcome (CLO)
Apply fundamental of DBMS, relational data model and normalization concepts
in database development process.
Show a well-structured database using the database query to manipulate a
database with an appropriate commercial Database Management System
(DBMS) in solving an organization’s requirements.
CHAPTER
3
3.1 Apply the normalization concept
INTRODUCTION
◎ The table is a basic building block in the database
design process.
◎ It is possible to create poor table structures even in a
good database design.
◎ So how do we recognize a poor table structure and
how to produce a good table?
◎ This where we need normalization.
NORMALIZATION
The goal of normal forms is to allow you to take a table or collection of tables and produce
a new collection of tables that represents the same information but is free of problems.
Enables you to identify the existence of potential problems called anomalies, in the design of
a relational database.
Normalization reduces data dependency and helps to eliminate the anomalies that result from
those redundancies.
Does not eliminate data redundancies, instead it produces controlled redundancy, which is
needed to link the tables in a database.
NORMALIZATION
Anomalies – unexpected results from an operation.
ANOMALIES
INSERTION MODIFICATION DELETION
THE OBJECTIVES OF NORMALIZATION
1 to free the collection of relations from undesirable insertion, update
and deletion dependencies.
to reduce the need for restructuring the collection of relations as new
2 of data are introduced and thus increase the life span of application
programs.
3 to make the relational model more informative to users.
4 to make the collection of relations neutral to the query statistics, where
these statistics are liable to change as times goes by.
Identify anomalies exist in this table.
NORMALIZATION PROCESS
The process of normalization is
accomplished in stages, each
corresponds to a normal form.
Normalization’s stages:
First normal form
Second normal form
Third normal form
Boyce-Codd normal form
NORMALIZATION PROCESS
To understand normalization, you
need to understand several concepts:
FUNCTIONAL
DEPENDENCY
PARTIAL
DEPENDENCY
TRANSITIVE
DEPENDENCY
RIDDLES
Which word in the dictionary is
spelled incorrectly?
Feed me and I live, yet give me
a drink and I die.
Take off my skin - I won't cry,
but you will! What am I?
NORMALIZATION PROCESS
1NF 2NF 3NF BCNF
BEFORE NORMALIZATION
AFTER NORMALIZATION
AFTER NORMALIZATION
RIDDLES
How many bananas can you eat if your
stomach is empty?
What is the most curious letter?
CHAPTER
3
3.2 Apply ER diagrams in database development
What Is An Entity Relationship Model?
◎ An entity relationship model (ER model) is a
detailed, logical representation of the data for an
organization or for a business area.
◎ The ER model is expressed in terms of entities in
the business environment, the relationships among
those entities and the attributes (properties) of
both entities and their relationships.
◎ E-R Diagram notation can be used are Chen and
Crow Feet.
Basic Elements Of E-R Model
• An entity is a person, a place, an object, an
event or a concept in the user environment
about which the organization wishes to
ENTITY maintain data.
• An entity has a noun name.
• A description or an entity characteristic is
ATTRIBUTE known as an attribute.
• Used to differentiate object in an entity.
• Relationship is the link between entities
RELATIONSHIP • Label = verb / conjunction
Example of ER Model: Chen
Example of ER Model: Crow
Foot
ENTITY: CATEGORY & EXAMPLE
ENTITY TYPE
• A strong entity is one
STRONG that exists
independently of
ENTITY other entity.
• Symbol = rectangle
• The existence of a
weak entity depends
WEAK on the existence of
strong entity.
ENTITY • Symbol = double
rectangle
EXAMPLE OF STRONG & WEAK ENTITY
Identifying relationship
http://techdifferences.com/difference-between-strong-and-weak-entity.html
TYPE OF ATTRIBUTE
SIMPLE Simple Attribute has only one component, exist independently and
cannot be broken up. Example: IC number, student ID
COMPOSITE Composite Attribute comprises of many components, each one
existing independently. Example: address with sub attributes such
as house_no, road_no, town, postcode, etc.
SINGLE-VALUE Single Valued Attribute is an attribute that consists of only a single
value. Example: IC number
MULTI-VALUE Multi-Valued Attribute is an attribute consisting of many values.
Example: phone number
DERIVED Derived Attribute is an attribute where its values is derived from
the value of related attributes or set of other attributes. Example:
age attribute derived from the date of birth
SYMBOL FOR EACH ATTRIBUTE’S TYPE
matricno
[ simple attribute]
studentname [ single attribute]
gender
houseno
STUDENT dateofbirth
road
[ composite attribute ]
address
garden
phoneno
postcode
specialty [ multi-valued
attribute]
age [ derived attribute]
Exercise: Identify entity and attribute.
◎ Customer
◎ Height
◎ Product
◎ Tomato
◎ Temperature
◎ manufactured part
◎ Account type
Exercise: Draw entity and attribute for the following
descriptions.
The local city youth league needs a database
system to help track children who sign up to play
soccer. Data needs to be kept on each team, the
children who will play on each team, and their
parents.
Also, data needs to be kept on the coaches for each
team.
RELATIONSHIP TYPE
Recursive / Unary
Recursive/Unary Relationship is a
relationship involving only one entity .
Binary
Binary Relationship is a relationship
between two entities.
Ternary
Ternary Relationship is a simultaneous
relationship between the three entities.
Recursive / Unary
Binary
Ternary
Example of relationship type
Draw an ER diagram (include entity, relationship and
cardinality) for the following statements:
1) Each student attends several classes. There are several students in
each class.
2) An author can write many books. A book may be written by many
authors.
3) A lecturer teaches, at most, one course. A course is taught by exactly
one lecturer.
4) A player plays for only one team. A team consists of many players.
5) Each lecturer is given at most one typist secretary.
A typist may be secretary for many lecturers.
Draw ER diagrams for the following business rules.
Show cardinality and participation.
• Every department is managed by one employee.
Some employees do not manage departments.
• Every car has at least one owner.
One person may own several cars or no cars.
• Each lecturer supervisor supervises several graduates.
Each student has only one lecturer supervisor.
• Each room is owned by at most one department.
A department owns at least one room.
COMPOSITE ENTITY
• The many-to-many relationship identified
in an E-R model shows a complex
relationship
• This can be simplified by transforming
relationship to an entity known as
Composite Entity.
• Eg: DOCTOR treat PATIENT.
N
M
DOCTOR
treat PATIENT
74
COMPOSITE ENTITY
a) M N
DOCTOR treat PATIENT
Treatment Treatment Patient_
Staff_no type date no
b)
M 1
DOCTOR 1 M
give TREATMENT involve PATIENT
• The M relationship is placed at the composite entity
75
76
Copyright © ODL Jan 2005 Open University Malaysia
77
Guideline and Steps In Construction An E-R Model
◎Do not insert the system environment which is
modeled as a component of the E-R model
Environment where
Application will be
The wrong model
constructed
CAR has BUSINESS
rent
The correct model
CAR rent CLIENT CLIENT
78
Guideline and Steps In Construction An E-R Model
◎ There are entities with two different keys (not composite key).
◎ EG: In the University Library, BORROWER may refer to student or staff. The key for BORROWER entity is metric
number or staff number. If the BORROWER is a student the key is his/her metric number and the staff number
will be left blank (null value).
The correct model
Metric_no Staff_no
STUDENT Name Name STAFF
The wrong model Borrowed by Borrow_date Borrow_date Borrowed by
student Return_date Return_date staff
BORROWER borrows BOOK
BOOK
Metric_no Borrow_date topic topic
Staff_no Return_date publisher publisher
name
79
Guideline and Steps In Construction An E-R Model
◎ How can we determine whether an object is an entity or an attribute?
Metric_no
a) name
STUDENT
college
An entity must contain description. As such, an object with only one characteristic is
referred to as attribute and not entity.
b)
STUDENT stay RES._COLLEGE
Metric_no Colege_name
name College_address
However, if the value of an attribute is important to the organization, the
attribute can be made into an entity
80
Guideline and Steps In Construction An E-R Model
◎Convert multiple value attributes as entities.
Staff_no
a) name
DOCTOR
specialty
b) M N
DOCTOR has SPECIALTY
Staff_no spec,._code
name description
Eg: if a DOCTOR has more than one specialty, SPECIALITY need to be made an
entity.
81
Guideline and Steps In Construction An E-R Model
◎Two entities can have more than one relationship.
register
STUDENT COURSE
drop
Eg. STUDENT can register for a COURSE and STUDENT can also
drop a COURSE
82
TOP-DOWN METHODOLOGY
Determine entity and relationship between them.
Start with main entity and followed by other entities
Determine the attributes related to the entities.
Determine the attributes related to the relationship (if
there are any).
Choose the keys for the entity.
Determine the domain for each attribute.
Combine the diagram of entity, relationship and
attribute to develop a complete E-R model. The must
be made without allowing entities to exist
independently. (hanging)
Thoroughly check and refined the E-R model if
necessary (discuss with user).
83
Exercise: Draw ERD for the following descriptions.
The local city youth league needs a database system to help track children who sign
up to play soccer. Data needs to be kept on each team, the children who will play on
each team, and their parents. Also, data needs to be kept on the coaches for each
team.
The following relationships must be defined:
Team is related to Player.
Team is related to Coach.
Player is related to Parent.
Connectivities and participations are defined as follows:
A Team may or may not have a Player.
A Player must have a Team.
A Team may have many Players.
A Player has only one Team.
A Team may or may not have a Coach.
A Coach must have a Team.
A Team may have many Coaches.
A Coach has only one Team.
A Player must have a Parent.
A Parent must have a Player.
A Player may have many Parents.
A Parent may have many Players.
Abstraction Of The Relationship Scheme From the
Logical Data Model
• We will abstract a relationship from a logical data model which is obtained
through the process of mapping from a conceptual data model.
• Each entity will abstract one table.
• The relationship between an entity and another entity is represents by the
mechanism of a primary key and a foreign key in the relationship scheme.
• In deciding where to place the attribute that represents the foreign key
attribute, we must first categorize the ‘parent’ and ‘child’ entities.
• A copy of the primary key attribute ‘parent’ entity will be placed in the
‘child’ entity and this attribute acts as a foreign key in the ‘child’ entity.
85
Abstraction Of The Relationship Scheme From the
Logical Data Model
• The process of abstracting the relationship scheme
requires several considerations as follows:
a. Strong Entity
b. Weak Entity
c. 1:M Relationship
d. 1:1 Relationship
86
Abstraction Of The Relationship Scheme
From the Logical Data Model
a) Strong Entity
• For each common entity (strong), you need construct a
relationship by inserting all the simple attributes of the
common entity into the relationship.
• In the case of composite attribute, you merely need to insert
simple attributes which form the composite attribute
mentioned.
87
a) Strong Entity
• Example, a Student relationship is produced and each attribute
of the Student entity will become a field for Student
relationship. The primary key of Student entity will become the
primary key of Student relationship.
name
no Student StudentNo
road address
DateOfBirth
city
postcode Student (StudentNo, name,DateOfBirth,
state
no, road, city, postcode, State)
88
b) Weak Entity
• For each weak entity, you need to produce a
relationship and insert all the simple attributes( or
simple attributes of the composite attribute) into the
relationship.
• Apart from that, an attribute representing the foreign
key is produced.
• This attribute is a copy of the primary key for the
common entity which is related to this weak entity.
89
b) Weak Entity
LiabilityNo
Name
DateOfBirth
WorkerNo
1 M
Name Worker has Liability
Address
DateOfBirth
Worker(WorkerNo, name, address, DateOfBirth)
Liability(LiabilityNo, name, DateOfBirth, WorkerNo)
90
c) 1:M Relationship
• For each 1:M relationship between entity E1 and Entity
E2, a copy of the primary key entity E1(parent) will be
placed in entity E2 (child) to represent a foreign key.
In this case, we represent the entity placed in
“position 1” as “parent” entity, whereas the entity
place in “many positions(M)” represent the child
entity.
91
d) 1:1 Relationship
• For each 1:1 binary relationship between Entity E1 and E2 in the
logical data model, a copy of a primary key for entity E1(parent)
will be placed in entity E2 (child) to represent the foreign key.
• The determination for parent entity and child entity depends on
the relationship participation between the entities involved.
• The entity with optional relationship participation is categorized as
the parent entity, and the entity with mandatory relationship
participation is categorized as child entity.
92
d) 1:1 Relationship
• As an example, consider the 1:1 relationship for Worker Manage
Department below, the Worker has optional participation in this
relationship. This mean not every Worker manage the Department,
whereas the Department has mandatory participation in the
relationship Manage :-
WorkerNo
DepartmentCode WorkerName
DepartmentName DateOfBirth
1 1
Department Manage Worker
Department(DepartmentCode, DepartmentName, WorkerNo)
Worker(WorkerNo, WorkerName, DateOfBirth)
93
d) 1:1 Relationship
• Whereas the Department has mandatory participation in the
relationship Manage. Department must be managed by Worker.
Because of this, the primary key attribute of the Worker entity is
copied into the Department entity as foreign key.
• However, if the involvement of both entities in the 1:1
relationship is optional or mandatory, the determination of parent
entity is the most frequently accessed or queried by users.
94
Write relationship schema for this ER diagram.
Exercise: Develop a logical ER diagram for this scenario and write
relationship schema from the new ER diagram.
The local city youth league needs a database system to help track children who sign
up to play soccer. Data needs to be kept on each team, the children who will play on
each team, and their parents. Also, data needs to be kept on the coaches for each
team.
The following relationships must be defined:
Team is related to Player.
Team is related to Coach.
Player is related to Parent.
Connectivities and participations are defined as follows:
A Team may or may not have a Player.
A Player must have a Team.
A Team may have many Players.
A Player has only one Team.
A Team may or may not have a Coach.
A Coach must have a Team.
A Team may have many Coaches.
A Coach has only one Team.
A Player must have a Parent.
A Parent must have a Player.
A Player may have many Parents.
A Parent may have many Players.
By using your answer from previous
exercise, create a database and
relationships between tables using MS
Access.
SUMMARY
◎ ELEMENTS IN ERD: ENTITY, ATTRIBUTE,
RELATIONSHIP.
◎ TYPE OF ENTITY
◎ TYPE OF ATTRIBUTE
◎ TYPE OF RELATIONSHIP
◎ RELATIONSHIP PARTICIPATION
◎ RELATIONSHIP CARDINALITY
◎ TRANSFORM ERD INTO PHYSICAL
DATABASE DESIGN.
“
“Do not wait; the time will never be ‘just right.’
Start where you stand, and work with whatever
tools you may have at your command, and better
tools will be found as you go along.”
—George Herbert
