ĐẠI HỌC FPT CẦN THƠ

Chapter 4
High-level Database Models - ER model
 Objectives

1 Understand the Database Design Process

2 Understand what is the high-level design (or Conceptual Design)

3 Understand why must use Conceptual Design (or Logical Design)

4 Understand the purpose of a ERD

5 Know what are Entity, Entity Set, Entity Instances, Attributes & others

6 Know what is a relationship and how to realize it

7 Know how to draw an ERD

 Contents

1 Database design process

2 Entity relationship model

3 What are entity, entity set, attribute, relationship?

4 ERD

5 Attributes on Relationships

6 Weak Entities

7 Sub-class
 Data Model

The ANSI-SPARC
Architecture (American
National Standards Institute,
Standards Planning And
Requirements Committee), is
an abstract design standard
for a database management
system (DBMS), first
proposed in 1975.
 Data Model

- The lowest level

- It describes how data is
stored in the database
- The data is stored in the
external hard drives (in files
and folders)
- It includes compression and
encryption techniques.
 Data Model

- It is also known as the logical

level
- It describes how the database
appears to the users
conceptually and the
relationships between various
data tables
 Data Model

- The highest level - closest to users

- It is known as the view level.
- It only shows the relevant
database content to the users in
the form of views and hides the
rest of the data
- So different users can see the
database as a different view as per
their individual requirements.
 The database modeling and
implementation process

Why do we use the relational model?

 The database modeling and
implementation process

It has only one concept – the relation

It is useful when we begin with a high-level design model
 The database modeling and
implementation process

Why do we need a database design?

 Why doing database design

Good application programs can't overcome bad

database designs
The existence of a DBMS does not guarantee
good data management, nor does it ensure that
the database will be able to generate correct and
timely information
The end user and the designer decide what data
will be stored in the database
 Steps in Database Design

ERD -
Entity
Relationship
Diagram
Steps in Database Design
 4.1. Entity Relationship Model

Entity Relationship Diagram (ERD) is a graphical

representation of the database structure
Also known as ER Model or ER Diagram
An ERD using 3-principal element types:

1. Entity sets
2. Attributes
3. Relationships
4.1. Entity Relationship Model

How many types of

shapes does the ERD
have?

https://creately.com
4.1. Entity Relationship Model

3 types of shape:
- Rectangle
- Diamond
- Ellipse/Oval

Determine:
1. Entity Sets
2. Attributes
3. Relationships

https://creately.com
4.1. Entity Relationship Model

1. Entity Sets:
Shopper
Item

2. Attributes:
item_type
item_price
item_source

3. Relationships:
Buys

https://creately.com
4.1. ERD - Notation
 4.1.1 ERD - Entity sets

Entity:
Can be a person, place, event, or object that is
relevant to a given system
Named using singular nouns
A collection of similar entities forms an entity set

Weak entity:
Is an entity that depends on the existence of
another entity
Uses a foreign key combined with its attributed to form
the primary key
ODER and ORDER_ITEM
https://creately.com
 4.1.1 ERD - Entity sets

Entity:
Can be a person, place, event, or object that is
relevant to a given system
Named using singular nouns
A collection of similar entities forms an entity set

Weak entity:
Is an entity that depends on the existence of
another entity
Uses a foreign key combined with its attributed to form
the primary key

https://creately.com
 4.1.1 ERD - Entity sets
A specific example of an entity is called an entity
instance
Instances Entities

A B
PERSON Bill Clinton, Obama
PRODUCT Chair, Table, Motor
JOB Violinist, Programmer
SKILL LEVEL Fluent

https://creately.com
 4.1.1 ERD - Entity sets

A specific example of an entity is called an entity

instance

Entities Instances
PERSON Bill Clinton, Obama
PRODUCT Chair, Table, Motor
JOB Violinist, Programmer
SKILL LEVEL Fluent

https://creately.com
 4.1.2 ERD - Attributes
Attributes are properties or characteristics of
an entity, relationship, or another attribute

https://creately.com
 4.1.2 ERD - Attributes

No. City

Street
 4.1.2 ERD - Attributes
Attributes are properties or characteristics
of an entity, relationship, or another
attribute

Ex: Suggest the attributes for each entity:

1. Office
2. Job
3. Deparment
4. Skill
5. Project
 4.1.2 ERD - Attributes
Attributes are properties or characteristics
of an entity, relationship, or another
attribute

Ex: Suggest the attributes for each entity:

1. Office
2. Job
3. Deparment
4. Skill
5. Project
 4.1.2 ERD - Attributes
Attributes are properties or characteristics
of an entity, relationship, or another
attribute

Ex: Suggest the attributes for each entity:

1. Office
2. Job
3. Deparment
4. Skill
5. Project
 4.1.2 ERD - Attributes
Attributes are properties or characteristics
of an entity, relationship, or another
attribute

Ex: Suggest the attributes for each entity:

1. Office
2. Job
3. Deparment
4. Skill
5. Project
 4.1.2 ERD - Attributes
Attributes are properties or characteristics
of an entity, relationship, or another
attribute

Ex: Suggest the attributes for each entity:

1. Office
2. Job
3. Deparment
4. Skill
5. Project
 4.1.2 ERD - Attributes
Attributes are properties or characteristics
of an entity, relationship, or another
attribute

Ex: Suggest the attributes for each entity:

1. Office
2. Job
3. Deparment
4. Skill
5. Project
 4.1.3 ERD - Relationships

Exp:
 4.1.3 ERD - Relationships

Relationships are connections among two or

more entity sets
Are labeled using verbs
Sometimes associate with attributes
 4.1.3 ERD - Relationships
Weak entity Relationship:
is relationship between a weak entity and
another entity
 4.1.3 ERD - Relationships
Weak entity Relationship:
is relationship between a weak entity and
another entity
 4.1.3 ERD - Relationships
Binary Relationships:
relationships between two entities

The arrow (from Movies to Studios)

indicates that each entity in set Movies is
related to at most one entity in set Studios
 4.1.3 ERD - Relationships
Multiway Relationships:
relationships involve more than two entities
 4.1.3 ERD - Relationships

Recursive Relationships:
If the same entity participates more than once in
a relationship it is known as a recursive relationship
 4.1.3 ERD - Relationships
Multiplicity of Binary E/R Relationships
(Cardinality and Ordinality)
 4.1.3 ERD - Relationships
Multiplicity of Binary E/R Relationships
(Cardinality and Ordinality)
 4.1.3 ERD - Relationships
Roles in Relationships:
One entity set appears two or more times in a single
relationship → each relationship line has a different role
 4.1.4 Subclasses
A certain special-case entity sets, each with its
own special attributes and/or relationships
Using a relationship called isa (“an A is a B”)
 4.1.4 Subclasses
Exp: Among the special kinds of movies are cartoons
and murder mysteries (with some special properties)
4.1.5 Comparision of ERD notation
 Summary
Database design process has …A… phases: …B……..
E/R model has used in …C… phase to …D… of applications.
Main concepts in E/R model are: …E..
Relationship Cardinality: …F…
Others concepts are: weak entity, multi-way relationship, sub-
class
 Summary

Database design process has three phases:

conceptual, logical and physical design.
E/R model has used in conceptual design phase to
capture requirements of applications.
Main concepts in E/R model are: entity, entity
instances, entity set, attribute, relationship (many-many,
one-many, one-one, mandatory, optional)
Others concepts are: weak entity, multi-way
relationship, sub-class
ERD - Homework
 ĐẠI HỌC FPT CẦN THƠ

Chapter 4
High-level Design Principles
& convert E/R diagram to relational model
 Objectives

1 Understand design principles

2 Understand constraints in ERDs

3 Know how to convert from ERD to relational designs

 Contents

1 Design Principles

2 From ERDs to relational designs

 4.2. Design Principles

Faithfulness
Avoiding Redundancy
Simplicity Counts
Choosing the Right Relationships
Picking the Right Kind of Element
Limit the use of weak entity sets.
Don’t use an entity set when an attribute will do.
 4.2.1. Faithfulness

First and Foremost, the design should be faithful to

the specifications of the application:
Entity sets and their attributes should reflect
the reality
Whatever relationships are asserted should make
sense given what we know about the part of the
real world being modeled
 4.2.1. Faithfulness

Exp: Which can we attach an attribute number-of-

cylinders to?
A. Stars
B. Automobiles
 4.2.1. Faithfulness

Exp: Which can we attach an attribute number-of-

cylinders to?
A. Stars
B. Automobiles
 4.2.2. Avoiding Redundancy

Redundancy and anomalies are typical of problems in

ERD
Redundancy = repetition of a fact = duplicate data
= the same parts of data exist in multiple locations.
Resulting to
waste space,
be difficult database update (update anomaly),
encourage inconsistency,
be slow and inefficient in retrieval of data
 4.2.2. Avoiding Redundancy

An update anomoly potential

Data inconsistency
 4.2.2. Avoiding Redundancy
An update anomoly potential
Two representations of the same fact become
inconsistent if we change one and forget to change
the other.
Recall anomalies due to FD’s.

Data inconsistency
The same data exists in different formats in
multiple tables
This can cause unreliable and meaningless
information
 4.2.2. Avoiding Redundancy - Exp

name name addr

Beers ManfBy Manfs

manf

Problem
 4.2.2. Avoiding Redundancy - Exp

name name addr

Beers ManfBy Manfs

Solution
manf
This design states the manufacturer of a beer
Redundancy: a related entity set Manfs with the entity set
Beers via the relationship ManfBy, also an attribute manf of
entity set Beers
 4.2.2. Avoiding Redundancy - Exp

name name addr

Beers ManfBy Manfs

 4.2.3. Simplicity Counts

Avoid introducing more elements into your design

than is absolutely nessessary
Hodings: the ownership of
a single movie

Movies Represents Holdings

Studios Owns
 Example: A poor design with
an Un-necessary entity set
That diagram truly represents the real world, since it is
possible to go from a movie to its unique owning
studio via Holdings, however, Holdings serves no
useful purpose and we are better off without it. It
makes programs that use the Movie-Studio relationship
more complicated, waste space and encourages errors

Movies Represents Holdings

Studios Owns
 Example: A poor design with
an Un-necessary entity set

Movies Represents Holdings

Studios Owns

Movies Owns Studios

 4.2.4. Choosing
the Right Relationships

Adding to the design every possible relationship causes:

redundancy,
update anomalies,
deletion anomalies

deletion anomalies
 4.2.4. Choosing
the Right Relationships

Adding to the design every possible relationship causes:

redundancy,
update anomalies,
deletion anomalies

deletion anomalies: occurs when you delete

a record that may contain attributes that
shouldn't be deleted
 Example: Choosing
the Right Relationships

Salary
title year name addr

Movies Contracts Stars

length genre If a star can work on a movie

without there being a contract?
Studios if there is the possibility that a
studio owns a movie, yet has
no stars under contract for that
movie, or no such contract is
name addr known to our database?
 Example: Choosing
the Right Relationships

Salary
title year name addr

Movies Contracts Stars

length genre
Studios

name addr

Do we need the relationships between

Movies and Studios and Movies and
Stars directly?
 4.2.5. Picking
the Right Kind of Element

Sometimes we have many options regarding

the type of design element used to represent a
real-world concepts.
Many of these choices are between using
attributes and using Entity set /
Relationship combinations.
In general, an attribute is simpler to
implement than either an Entity set or a
Relationship
However, making everything an attribute
will usually get us into trouble.
 4.2.5. Picking
the Right Kind of Element

Entity Sets Versus Attributes

An entity set should satisfy at least one of the
following conditions should not be replaced by an
attribute:
Existing at least one nonkey attribute.
Existing the “many” in a many-one or many-many
relationship.
 4.2.5. Picking
the Right Kind of Element
Entity Sets Versus Attributes

name name

Beers ManfBy Manfs

Manfs should be an entity set or an attribute?

Why?
 4.2.5. Picking
the Right Kind of Element
Entity Sets Versus Attributes

name name

Beers ManfBy Manfs name manf

Beers
Since the Manfs has
•only one attribute (key),
•and only the “one” at end the relationship.

→ it should be replaced by an attribute.

 4.2.5. Picking
the Right Kind of Element
Entity Sets Versus Attributes
name name addr

Beers ManfBy Manfs

1. Manfs should be an entity set or an attribute?

Why?
2. Beers should be an entity set or an attribute?
Why?
 4.2.5. Picking
the Right Kind of Element
Entity Sets Versus Attributes
name name addr

Beers ManfBy Manfs

1. Manfs deserves to be an entity set because

of the nonkey attribute addr.
2. Beers deserves to be an entity set because
it has the “many” of the many-one
relationship ManfBy.
 4.2.6. Don’t
Over-use Weak Entity Sets

Beginning database designers often doubt that

anything could be a key by itself.
They make all entity sets weak, supported by all other
entity sets to which they are linked.

In reality, we usually create unique ID’s for entity

sets.
Examples include social-security numbers, automobile
VIN’s etc.
 4.2.7. When Do
We Need Weak Entity Sets?

The usual reason is that there is no global authority

capable of creating unique ID’s.
Sometimes, an Entity Set falls into a hierarchy
 4.3. From E/R diagrams
to Relational Designs

Step 1: A set of entities is transformed into a

relation (set of tuples)
Step 2: An attribute is transformed into an
attribute of the relation
Step 3: The identifier of the entity becomes the
primary key of the relation
Step 4: Representation the relationships of the
entity relationship model into the relational model
 4.3. From E/R diagrams
to Relational Designs
Step 4: Representation the relationships of the entity
relationship model into the relational model
M:M Any many-to-many relationships between entities of the
diagram becomes a (new) relation in the relational model that we
have as the primary key the two primary keys of the entities
that it associates
1:M The parent relationship will be on the “cardinality 1“ side. The
child relationship will be on the “M” side. Represent each entity as a
relation. Copy the primary key of the parent into the child
relation as a foreign key
1:1 The primary key of one relation is stored in the second
relation. Look at example queries to determine which key is queried
most often. Or the relationship between entities of the diagram
becomes a (new) relation in the relational model that we have as
the primary key the two primary keys of the entities that it
associates
coursera
 Convert entity set

Entity set => table

PROF (pid, hkid, dept, rank, salary)

Where pid is set as a candidate key
 Convert one-one relationship

Table that has two candidate keys.

MARRY (mid, wid, year)

Where candidate key is mid, and another is wid

 Convert many-many relationship

STU (sid,…) - candidate key is sid

CLASS (cid, year,…) – candidate key is (cid, year)
TAKE (sid, cid, year, grade) – candidate key is (sid, cid,
year) and
- foreign key sid references to STU (sid)
- foreign key (cid, year) references to CLASS (cid, year)
 4.3. From E/R diagrams
to Relational Designs

M:M

coursera
4.3. From E/R diagrams
to Relational Designs

coursera
 Convert one-many relationship

PROF (pid, …) - candidate key is pid

CLASS (cid, year, pid…) – candidate key is (cid, year) and

pid is foreign key references to PROF (pid)

 4.3. From E/R diagrams
to Relational Designs

1:M

coursera
4.3. From E/R diagrams
to Relational Designs

coursera
 Convert multi-way relationship

MOVIES (title, year, length) - candidate key is (title, year)

STARS (sid, name) – candidate key is sid
STUDIOS (name, address) – candidate key is name
CONTRACTS (sid, title, year, studio-name, salary) – candidate key is
(sid, title, year, studio-name) and
- foreign key sid references to STARS(sid)
- foreign key (title, year) references to MOVIES(title, year)
- foreign key studio-name references to STUDIOS(name)
 Convert weak entity

name number name

Players Plays- Teams

on

TEAMS (name) - candidate key is name

PLAYERS (number, team-name, name) – candidate key is
(number, team-name) and
- foreign key team-name references to TEAMS(name)
 Convert sub-class structures

There are three strategy for conversion to relations:

- E/R style conversion
- An Object-oriented approach
- Using null values to combine relations
 Convert sub-class structures

E/R style conversion

MOVIES (title, year, length) – candidate key is (title, year)
MURDERMYSTERIES (title, year, weapon) – candidate
key is (title, year)
CARTOONS (title, year) – candidate key is (title, year)
• Movies relation has every movie.
• Movies that are murder mysteries have a tuple in both
Movies and Murdermysteries relations.
• Movies that are cartoons have a tuple in both Movies and
Cartoons relations.
• Movies that are both cartoons and murder mysteries have a
tuple in all three relations.
 Convert sub-class structures

An Object oriented approach

MOVIES (title, year, length)
MOVIESC (title, year, length)
MOVIESMM (title, year, length, weapon)
MOVIESCMM (title, year, length, weapon)
Candidate key of all relations are the same – (title, year)

• This approach enumerate all the possible sub-trees of

hierarchy.
• For each, create one relation that represents entities having
components in exactly those sub-trees.
 Convert sub-class structures
Using Null values to combine relations
• In this approach, there is only one relation that has
all attributes belonging to any entity set of the
hierarchy.
• Tuple has Null in each attribute that is not defined
for appropriate entity.

MOVIES (title, year, length, weapon)

Candidate key of all relations are the same – (title, year)
 The questions to Ensure that the
tables are in 3NF

Does the table contain any repeating groups?

If not, and the table has a primary key then it is
First normal form (1NF)

Does the table contain any partial dependencies?

If not, and it is in 1NF then it is in 2NF

Does the table contain any transitive dependencies

or derived attributes?
If not, and it is in 2NF then it is in 3NF
Example: Convert this ERD to
Relational Design (HW)
Example: Convert this ERD to
Relational Design (HW)
 Example: Convert this ERD to
Relational Design

There are 4 entities in above ERD, so we have 4

tables create with following names:
- PRESENTER
- AGENT
- SHOW
- PRODUCTION_COMPANY

There are 3 relationships in above ERD, so we have

more 3 tables:
- PRESENTER_AGENT (for “represent” relationship)
- PRESENTER_SHOW (for “present” relationship)
- SHOW_PROD_COMP (for “Pro-by” relationship)
 Example: Convert this ERD to
Relational Design

The table PRESENTER has following columns:

- SIN
- FNAME
- LNAME
- HAIR_COLOR
Exercise: Students must determine the attributes
for AGENT, SHOW, PRODUCTION_COMPANY…
Exercise: Students must decompose to make the
Relations 3NF
ĐẠI HỌC FPT CẦN THƠ