Database Design

Outline
▪ Database System Development Life Cycle
▪ Database Design

2
 Database Planning

System Definition

Requirement Collection
and analysis

Database Design
Conceptual DB
design
DBMS Selection
Logical DB design Application Design

physical DB design

Prototyping Implementation

Data conversion and

loading
Database System Development Life 3
Testing
Cycle
Operational maintanance
Phases of Database Design

1. 2.
Conceptual Logical Design 3.
Design e.g Relational Physical Design
e.g ER Model Model

4
ER Modeling
▪ One of the most difficult aspect of database design
is :
The fact that designers, programmers, and end-
user tend to view data and its use in different ways
▪ To ensure that we get a precise understanding of
the nature of the data and how it is used by the
enterprise, we need a model for communication
that is non technical and free of ambiguities, the
Entity-Relationship (ER)model is one of
example.
5
ER Modeling (Cont.)
▪ ER Modeling is a top-down approach to database
design
□ Begin by identifying the important data called
entities and relationship between the data that
must be represented in the model
□ Then add some more details, such as:
▫ The information we want to hold about the
entities and relationship called attributes
▫ Any constraint

6
Basic Concept of
ER Modeling
Basic Concept of ER Modeling
▪ Entities
▪ Relationship
▪ Attributes
▪ Identifier (key)
▪ Multiplicity (cardinality and participation)

8
Entity
▪ An entity is something that users want to
track
▪ Example:
□ Student
□ Course
□ Lecture

9
Attributes
▪ Entities have attributes that describe the entity’s
characteristics
▪ Example:
□ Attributes for Student entity:
▫ ID
▫ Name
▫ DoB
▫ Class
□ Attributes for Course entity :
▫ ID
▫ Course Name
10
Attributes(Cont.)
▪ Single-valued attribute : an attribute that holds a
single value for each occurrence of an entity
▪ Multi-valued attribute: an attribute that holds
multiple value for each occurrence of an entity,
example :

▪ Derived-attribute : Can be computed from other

attributes, example : Age
11
Identifiers (primary key)
▪ (Why?) Every instance of an entity must be uniquely identified
□ Entity: Student
□ Instances (Name attribute only):
▫ John Smith, Jane Doe, John Smith, …
▫ We need some attribute other than the Name to differentiate the
first John Smith from the second John Smith
▪ (What?) An identifier can be one attribute or a collection of
attributes
□ One attribute as an identifier of the entity called STUDENT: student_no
□ A collection of attributes as an identifier of the entity called
REGISTRATION: student_no +course_no
▪ (How to denote an identifier) An underlined attribute (or a leading
asterisk) denotes an identifier: student_no or * student_no

Composite key = primary key that consists of two or more

12
attribute
Relationship
▪ Entities can be associated with one another in
relationships.
▪ Relationship is a set of meaningful
associations among entity.
▪ Relationship degree defines the number of
entity classes participating in the relationship
– Degree 2 is a binary relationship – Degree 3
is a ternary relationship
13
Relationship (Cont.)

Degree of Relationship

14
Relationship (Cont.)
Example of Degree of Relationship

15
 minimum cardinality Maximum cardinality

Multiplicity (participation, cardinality)

Cardinality
Participation
describe the maximum number of
possible relationship occurrence for determines whether all or only
an entity participating in a given some entity occurrences
relationship participate in a relationship. It
Menunjukkan jumlah maksimum appears on minimum values of
entitas yang dapat berelasi dengan the multiplicity
entitas pada himpunan entitas yang □ 0 (optional
lain participation)
- 1 to 1 (one to one) □ 1 (mandatory
- 1 to N (One to many) participation)
- M to N (Many to many)

16
Example : One-to-one binary
relationship

17
Example : One-to- many binary
relationship

18
Example : many-to- many binary
relationship

19
Example : One-to-one binary relationship with
participation (minimum cardinality)

20
Example : One-to-one binary relationship with
participation (minimum cardinality)

cardinality
One branch is managed by one member of staff managed
one member of staff one branch

All branches are managed Not all staff manage branches

(mandatory participation for branch) (optional participation for staff)

participation 21
Weak Entity
▪ A weak entity is an entity that cannot exist in the
database without the existence on another entity
▪ For example, an employee’s dependents cannot
exist in a database without the employee existing
in the database

22
ID-Dependent Weak Entities
▪ An ID-Dependent weak entity is a weak
entity that must include the identifier of its
parent entity as part of its composite
primary key

23
Weak Entity Identifier: ID-Dependent
▪ An ID-dependent weak entity has a composite
identifier
□ The first part of the identifier is the identifier for
the strong entity
□ The second part of the identifier is the identifier
for the weak entity itself

24
Weak Entity Identifier: Non-ID-
dependent
▪ A non-ID-dependent weak entity may have
a single or composite identifier, and the
identifier of the parent entity will be a
foreign key

25
Weak Entity Relationships
▪ The relationship between a strong and
weak entity is termed an identifying
relationship if the weak entity is ID-
dependent
▪ The relationship between a strong and
weak entity is termed a nonidentifying
relationship if the weak entity is non-ID-
dependent
26
ER Model
Notation
ER Modeling Notation
▪ Diamond Notation (Chen)
▪ Crow’s foot notation (Martin)
▪ OMT-style notation (Rumbaugh)
▪ Oracle Notation
▪ UML Notation

28
Diamond Notation (Chen)

29
Crow’s foot notation (Martin)

30
OMT-style notation (Rumbaugh)

31
32
33
Exercise
Exercise 1: Complete the relationship

35
Exercise 2 : Complete the relationship

36
Exercise 3
▪ Create an ER Model of the following description
A customer can place an order for one or more
products. Customers that have not placed any
orders can be included in the customer database for
purposes of marketing research. Products that have
not been ordered can be part of the product
database. An order has to be associated with at
least one product but can be associated with many
products.
37
Exercise 4
▪ Create an ER Model for each of the following description
a) Each company operates four departments and each
department belongs to one company
b) Each department in part(a) employs one or more
employees, and each employee works for one department
c) Each of the employee in part (b) may or may not have one
or more dependents and each dependent belongs to one
employee
d) Each employee in part (c)may or may not have an
employment history
e) Represent all the ER model described in (a),(b),(c) and (d)
as a single ER Model
38
 40

ER Translation
▫ Lecture Objective:
- Learn how to transform E-R
data models into relational
designs
- Learn how to represent weak
entities with the relational
model
- Know how to represent 1:1,
1:N, and N:M binary
relationships
- Know how to represent 1:1,
1:N, and N:M recursive
relationships
 41

Representing Relationships
▪ The maximum cardinality determines how a relationship
is represented
▪ 1:1 relationship
□ The key from one relation is placed in the other as a
foreign key
□ It does not matter which table receives the foreign
key
 42

A One-to-One Relationship Example

1
:
LOCKER EMPLOYEE
1
 43
One Representation of a One-to-One
Relationship
Locker Employee
Primary Key
LockerID EmpID
LockerDe LockerID
sc Foreign Key
Location EmpName
 44
Another Representation of a One-to-One
Relationship
Locker Employee
Primary Key
LockerID EmpID
EmpID EmpName
LockerDes Foreign Key
c
Location
 45

One-to-Many Relationships
▪ Like a 1:1 relationship, a 1:N relationship is saved by
placing the key from one table into another as a foreign
key
▪ However, in a 1:N the foreign key always goes into the
many-side of the relationship
 46

A One-to-Many Relationship Example

1
:
DEPARTMENT EMPLOYEE
N
 47

Representing a One-to-Many Relationship

Departme Employee
nt Primary Key
DeptID EmpID
DeptName DeptID
Location Foreign Key EmpName
 48

Representing Many-to-Many Relationships

▪ To save a M:N relationship, a new relation is created.

This relation is called an intersection relation
▪ An intersection relation has a composite key consisting
of the keys from each of the tables that formed it
 49

A Many-to-Many Relationship Example

N
:
SKILL M EMPLOYEE
 50

Representing a Many-to-Many Relationship

Skill Employee
Primary Key
SkillID Primary Key EmpID
SkillDesc EmpName
Emp_Skill
Foreign Key SkillID
EmpID Foreign Key
 51

Representing Recursive Relationships

▪ A recursive relationship is a relationship that a
relation has with itself.
▪ Recursive relationships adhere to the same rules
as the binary relationships.
□ 1:1 and 1:M relationships are saved using foreign
keys
□ M:N relationships are saved by creating an
intersecting relation
 52

A Recursive Relationship Example

1
EMPLOYEE :
N
Manage
s
 53

Representing a Recursive Relationship

Employee
EmpID
ManagerID
ManagerID is a
EmpName Foreign Key
referencing
the Primary Key
EmpID
Thank You ☺

54