Chapter five

Logical Database
Design

1
Introduction

 Logical design is the process of constructing a

relational model of the information used in an
enterprise based on a specific data model
 The first step before applying the rules in relational
data model is converting the conceptual design to
a form suitable for relational logical model, which
is in a form of tables.
2
Logical DB Design and Relational
Model

 Relational Data Model

 Transforming E-R Diagrams into Relations

 Normalization

3
Relation
 A relation is a named, two-dimensional table of data

 Requirements:
– Every relation has a unique name
– Every attribute value is atomic (not multi-valued, not
composite)
– Every row is unique (can’t have two rows with exactly the
same values for all their fields)
– Attributes (columns) in tables have unique names
– The order of the columns is irrelevant 4
Key Fields
 Keys are special fields that serve two main purposes:

• Primary key is an attribute that uniquely identifies each

row in a relation
• Foreign key is an attribute in a relation of a database
that serves as the primary key of another relation in the
same database
 Keys can be simple (a single attribute) or composite (more
than one attribute)
5
ERD to Relational Table(1)

1. Mapping Regular Entities to Relations

 Simple attributes

• E-R attributes map directly onto the relation

 Composite attributes

• use only their simple, component attributes

 Multi-valued attribute

• becomes a separate relation with a foreign key

taken from the original entity 6
Mapping a regular entity
(a) CUSTOMER entity type with simple attributes

(b) CUSTOMER relation

7
Mapping a composite attribute

(a) CUSTOMER entity type with composite attribute

(b) CUSTOMER relation with address detail

8
Mapping multi-valued attribute

Multi-valued attribute becomes a separate relation with foreign key

9
ERD to Relational Table(3)
2. Mapping Binary Relationships
 One-to-Many
– primary key on the one side becomes a foreign key on the
many side
 Many-to-Many
– create a new relation with the primary keys of the two entities
as its primary key
 One-to-One
– primary key on the mandatory side becomes a foreign key on
the optional side
– avoids the need to store null values in the foreign key
– any attributes associated with the relationship are also
included in the same relation as the foreign key
10
Mapping a 1:M relationship(1)
(a) Relationship between customers and orders

11
Mapping a 1:M relationship(2)
(b) Mapping the relationship

Foreign key

12
Mapping an M:N relationship(1)

(a) Supplies relationship (M:N)

Note: The Supplies relationship will become a separate relation

13
Mapping an M:N relationship(2)

(b) Three resulting relations

Composite primary key

Create new
relation
Foreign key
Foreign key

14
Mapping a binary 1:1 relationship(1)
(a) Binary 1:1 relationship

15
Mapping a binary 1:1 relationship(2)
(b) Resulting relations

Note:
• Nurse_in_Charge is another name for Nurse_ID.
• Attribute attached to relationship is stored with foreign key.

16
 Anomalies
 Types of anomalies

• Insertion anomaly
• adding new rows forces user to create duplicate data
• Deletion anomaly
• deleting rows may cause a loss of data that would be
needed for other future rows
• Modification/updating anomaly
• changing data in a row forces changes to other rows
because of duplication
17
 Normalization
 The purpose of normalization is to reduce the chances for anomalies
to occur in a database.
 Primarily a tool to validate and improve a logical design so that it
satisfies certain constraints that avoid unnecessary duplication of data
 Process of decomposing relations with anomalies to produce smaller,
well-structured relations
 Database Normalization is the process of removing redundant data
from the tables to improve storage efficiency, data integrity, and
scalability.
18
Functional Dependency (1)

 Partial dependency

• Let {A, B} is the Primary Key and C is non key

attribute.
• Then if it should be {A, B}C but BC or AC
• Then C is partially functionally dependent on {A,
B}.

19
Functional Dependency (2)

 Total dependency

• Let {A, B} is the Primary Key and C is non key

attribute.
• Then if {A, B}C and BC and AC does not hold (
if B cannot determine C and A cannot determine
C).
• Then C Fully functionally dependent on {A, B}.
20
Functional Dependency (3)

 Transitive dependency

• If A functionally governs B, AND

• If B functionally governs C

• THEN A functionally governs C.

If AB and if BC, Then AC

21
Steps of Normalization

 Unnormalized Form: Identify all data elements.

 First Normal Form: Find the key with which you can find all
data.
 Second Normal Form: Remove part-key dependencies.
Make all data dependent on the whole key.
 Third Normal Form: Remove non-key dependencies. Make
all data dependent on nothing but the key.
 Note: For most practical purposes, databases are considered
22
First Normal Form (1)
• a table (relation) is in 1NF ,If

 There are no duplicated rows in the table, Unique identifier.

 Each cell is single-valued (i.e., there are no repeating groups).

 Entries in a column (attribute, field) are of the same kind.

 All repeating groups are moved into a new table/ Distribute the multi-
valued attributes into different rows and identify a unique identifier for
the relation

 Foreign keys are used to link the tables

 When a relation contains no repeating groups, is in the first normal form

 Keys must be included to link the relations, tables 23

First Normal Form
Consider the following unnormalized database table.

24
First Normal Form

25
Second Normal Form (1)

 Remove any partial dependencies

 A partial dependency is when the data are only dependent on a

part of a key field
 A relation is created for the data that are only dependent on part
of the key and another for data that are dependent on both
parts
• a table (relation) is in 2NF ,If
• It is in 1NF and
• If all non-key attributes are dependent on the entire primary key i.e. if the
primary key is composite key.
• No partial dependency. 26
Second Normal Form(2)
EMP_PROJ

EMP_PROJ rearranged

Business rule: Whenever an employee participates in a project, he/she will be

entitled for an incentive.
This schema is in its 1NF since we don’t have any repeating groups or attributes
with multi-valued property. To convert it to a 2NF we need to remove all partial
dependencies of non key attributes on part of the primary key.
{EmpID, ProjNo} EmpName, ProjName, ProjLoc, ProjFund, ProjMangID,
Incentive
But in addition to this we have the following dependencies
FD1: {EmpID} EmpName
FD2: {ProjNo} ProjName, ProjLoc, ProjFund, ProjMangID
FD3: {EmpID, ProjNo} Incentive
27
Cont.…

28
Third Normal Form(1)
 Remove any transitive dependencies

 A transitive dependency is when a relation contains data that are not

part of the entity
 This level avoids update and delete anomalies. Eliminate columns
dependent on another non-primary key - If attributes do not
contribute to a description of the key, remove them to a separate
table.
 A single data item may be present on many records
• a table (relation) is in 3NF,If
• It is in 2NF and
• There are no transitive dependencies between a primary key and29non-
primary key attributes.
Third Normal Form (2)
• Example for Third Normal Form (3NF): Consider the following example: Students
of same batch (same year) live in one building or dormitory.
student

• This schema is in its 2NF since the primary key is a single attribute.
• Let’s take StudID, Year and Dormitary and see the dependencies.
• StudIDYear AND YearDormitary
• And Year can not determine StudID and Dormitary cannot determine StudID.
Then transitively StudIDDormitary.
• To convert it to a 3NF we need to remove all transitive dependencies of non
key attributes on another non-key attribute.
• The non-primary key attributes, dependent on each other will be moved to
another table and linked with the main table using candidate key- foreign
30 key
Cont.…

31
Other Forms of Normalization
 Boyce-Codd Normal Form (BCNF)
• A table is in BCNF if it is in 3NF and if every determinant is a
candidate key.
 Fourth Normal form (4NF)
• A table is in 4NF if it is in BCNF and if it has no multi-valued
dependencies
 Fifth Normal Form (5NF)
• Projection-Join Normal Form" (PJNF),
• if it is in 4NF and if every join dependency in the table is a
consequence of the candidate keys of the table.
 Domain-Key Normal Form (DKNF)
• A table is in DKNF if every constraint on the table is a logical
consequence of the definition of keys and domains.
• A model free from all modification anomalies.
32
Outcomes of Normalization
 Contain all the data necessary for the purposes that the
database is to serve.

 Have as little redundancy as possible.

 Accommodate multiple values for types of data that require

them

 Permit efficient updates of the data in the database, and

 Avoid the danger of losing data unknowingly.

33
Pitfalls of Normalization
 Requires data to see the problems

 May reduce performance of the system

 Is time consuming

 Difficult to design and apply and

 Prone to human error

34