Database Systems

Chapter Four

Logical Database Design

The whole purpose of the data base design is to create an accurate representation
of the data, the relationship between the data and the business constraints
pertinent to that organization. Therefore, one can use one or more technique to
design a data base. One such a technique was the E-R model. In this chapter we
use another technique known as “Normalization” with a different emphasis to the
database design---- defines the structure of a database with a specific data model.

Logical design is the process of constructing a model of the information used in an

enterprise based on a specific data model (e.g. relational, hierarchical or network
or object), but independent of a particular DBMS and other physical
considerations.

The focus in logical database design is the Normalization Process

 Normalization process
 Collection of Rules (Tests) to be applied on relations to
obtain the minimal, non redundant set or attributes.
 Discover new entities in the process
 Revise attributes based on the rules and the discovered
Entities
 Works by examining the relationship between attributes
known as functional dependency.

The purpose of normalization is to find the suitable set of relations that supports
the data requirements of an enterprise.
A suitable set of relations has the following characteristics;

 Minimal number of attributes to support the data requirements of the

enterprise
 Attributes with close logical relationship (functional dependency) should
be placed in the same relation.
 Minimal redundancy with each attribute represented only once with the
exception of the attributes which form the whole or part of the foreign key,
which are used for joining of related tables.

Itec 222 1
Database Systems

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.

Converting ER Diagram to Relational Tables

Three basic rules to convert ER into tables or relations:
Rule 1: Entity Names will automatically be table names
Rule 2: Mapping of attributes: attributes will be columns of the respective tables.
 Atomic or single-valued or derived or stored attributes will be
columns
 Composite attributes: the parent attribute will be ignored and the
decomposed attributes (child attributes) will be columns of the table.
 Multi-valued attributes: will be mapped to a new table where the
primary key of the main table will be posted for cross referencing.

Rule 3: Relationships: relationship will be mapped by using a foreign key

attribute. Foreign key is a primary or candidate key of one relation used to create
association between tables.

 For a relationship with One-to-One Cardinality: post the primary or

candidate key of one of the table into the other as a foreign key. In cases
where one entity is having partial participation on the relationship, it is
recommended to post the candidate key of the partial participants to the
total participant so as to save some memory location due to null values
on the foreign key attribute. E.g.: for a relationship between Employee
and Department where employee manages a department, the
cardinality is one-to-one as one employee will manage only one
department and one department will have one manager. here the PK of
the Employee can be posted to the Department or the PK of the
Department can be posted to the Employee. But the Employee is having
partial participation on the relationship "Manages" as not all employees
are managers of departments. thus, even though both way is possible, it
is recommended to post the primary key of the employee to the
Department table as a foreign key.

 For a relationship with One-to-Many Cardinality: Post the primary key

or candidate key from the “one” side as a foreign key attribute to the
“many” side. E.g.: For a relationship called “Belongs To” between
Employee (Many) and Department (One) the primary or candidate key
of the one side which is Department should be posted to the many side
which is Employee table.

Itec 222 2
Database Systems

 For a relationship with Many-to-Many Cardinality: for relationships

having many to many cardinality, one has to create a new table (which
is the associative entity) and post primary key or candidate key from the
participant entities as foreign key attributes in the new table along with
some additional attributes (if applicable). The same approach should be
used for relationships with degree greater than binary.

 For a relationship having Associative Entity property: in cases where

the relationship has its own attributes (associative entity), one has to
create a new table for the associative entity and post primary key or
candidate key from the participating entities as foreign key attributes in
the new table.

Itec 222 3
Database Systems

Example to illustrate the major rules in mapping ER to relational schema:

The following ER has been designed to represent the requirement of an

organization to capture Employee Department and Project information. And
Employee works for department where an employee might be assigned to manage
a department. Employees might participate on different projects within the
organization. An employee might as well be assigned to lead a project where the
starting and ending date of his/her project leadership and bonus will be
registered.

FNam LNam
ee ee

EI Salar DI DLoc
D Nam y Manag D
e es
1 1
Employee Department
M 1 M WorksFo 1
r
Tel DNam
e

StartDate
Leads
EndDate
Participa
te
PBonu
s

M
M
Project

PFund
PID PNam
e

Itec 222 4
Database Systems

After we have drawn the ER diagram, the next thing is to map the ER into
relational schema so as the rules of the relational data model can be tested for each
relational schema. The mapping can be done for the entities followed by
relationships based on the rule of mapping. the mapping has been done as follows.

 Mapping EMPLOYEE Entity:

There will be Employee table with EID, Salary, FName and LName being
the columns. The composite attribute Name will be ignored as its
decomposed attributes (FName and LName) are columns in the Employee
Table. The Tel attribute will be a new table as it is multi-valued.
Employee
EID FName LName Salary
Telephone
EID Tel

 Mapping DEPARTMENT Entity:

There will be Department table with DID, DName, and DLoc being the
columns.
Department
DID DName DLoc

 Mapping PROJECT Entity:

There will be Project table with PID, PName, and PFund being the
columns.
Project
PID PName PFund

 Mapping the MANAGES Relationship:

As the relationship is having one-to-one cardinality, the PK or CK of one of
the table can be posted into the other. But based on the recommendation,
the Pk or CK of the partial participant (Employee) should be posted to the
total participants (Department). This will require adding the PK of
Employee (EID) in the Department Table as a foreign key. We can give the
foreign key another name which is MEID to mean "managers employee id".
this will affect the degree of the Department table.
Department
DID DName DLoc MEID

 Mapping the WORKSFOR Relationship:

As the relationship is having one-to-many cardinality, the PK or CK of the
"One" side (PK or CK of Department table) should be posted to the many

Itec 222 5
Database Systems

side (Employee table). This will require adding the PK of Department (DID)
in the Employee Table as a foreign key. We can give the foreign key another
name which is EDID to mean "Employee's Department id". this will affect
the degree of the Employee table.
Employee
EID FName LName Salary EDID

 Mapping the PARTICIPATES Relationship:

As the relationship is having many-to-many cardinality, we need to create
a new table and post the PK or CK of the Employee and Project table into
the new table. We can give a descriptive new name for the new table like
Emp_Partc_Project to mean "Employee participate in a project".
Emp_Partc_Project
EID PID

 Mapping the LEADS Relationship:

As the relationship is associative entity, we are supposed to create a table
for the associative entity where the PK of Employee and Project tables will
be posted in the new table as a foreign key. The new table will have the
attributes of the associative entity as columns. We can give a descriptive
new name for the new table like Emp_Lead_Project to mean "Employee
leads a project".
Emp_Lead_Project
EID PID PBonus StartDate EndDate

At the end of the mapping we will have the following relational schema (tables)
for the logical database design phase.

Department
DID DName DLoc MEID

Project
PID PName PFund
Telephone
EID Tel

Employee
EID FName LName Salary EDID
Emp_Partc_Project
EID PID
Emp_Lead_Project

Itec 222 6
Database Systems

EID PID PBonus StartDate EndDate

After converting the ER diagram in to table forms, the next phase is implementing
the process of normalization, which is a collection of rules each table should
satisfy.

Normalization
A relational database is merely a collection of data, organized in a particular
manner. As the father of the relational database approach, Codd created a series
of rules (tests) called normal forms that help define that organization

One of the best ways to determine what information should be stored in a database
is to clarify what questions will be asked of it and what data would be included in
the answers.

Database normalization is a series of steps followed to obtain a database design

that allows for consistent storage and efficient access of data in a relational
database. These steps reduce data redundancy and the risk of data becoming
inconsistent.

NORMALIZATION is the process of identifying the logical associations between

data items and designing a database that will represent such associations but
without suffering the update anomalies which are;

1. Insertion Anomalies
2. Deletion Anomalies
3. Modification Anomalies

Normalization may reduce system performance since data will be cross referenced
from many tables. Thus denormalization is sometimes used to improve
performance, at the cost of reduced consistency guarantees.

Normalization normally is considered “good” if it is lossless decomposition.

All the normalization rules will eventually remove the update anomalies that may
exist during data manipulation after the implementation. The update anomalies
are;

The type of problems that could occur in insufficiently normalized table is called
update anomalies which includes;
(1) Insertion anomalies

Itec 222 7
Database Systems

An "insertion anomaly" is a failure to place information about a new database

entry into all the places in the database where information about that new entry
needs to be stored. Additionally, we may have difficulty to insert some data. In a
properly normalized database, information about a new entry needs to be
inserted into only one place in the database; in an inadequately normalized
database, information about a new entry may need to be inserted into more
than one place and, human fallibility being what it is, some of the needed
additional insertions may be missed.
(2) Deletion anomalies
A "deletion anomaly" is a failure to remove information about an existing
database entry when it is time to remove that entry. Additionally, deletion of one
data may result in lose of other information. In a properly normalized database,
information about an old, to-be-gotten-rid-of entry needs to be deleted from
only one place in the database; in an inadequately normalized database,
information about that old entry may need to be deleted from more than one
place, and, human fallibility being what it is, some of the needed additional
deletions may be missed.
(3) Modification anomalies
A modification of a database involves changing some value of the attribute of
a table. In a properly normalized database table, what ever information is
modified by the user, the change will be effected and used accordingly.

In order to avoid the update anomalies we in a given table, the solution is to

decompose it to smaller tables based on the rule of normalization. However,
the decomposition has two important properties

a. The Lossless-join property insures that any instance of the original

relation can be identified from the instances of the smaller relations.

b. The Dependency preservation property implies that constraint on the

original dependency can be maintained by enforcing some constraints
on the smaller relations. i.e. we don’t have to perform Join operation to
check whether a constraint on the original relation is violated or not.

The purpose of normalization is to reduce the chances for anomalies to

occur in a database.

Itec 222 8
Database Systems

Example of problems related with Anomalies

EmpID FName LName SkillID Skill SkillType School SchoolAdd Skill

Level
12 Abebe Mekuria 2 SQL Database AAU Sidist_Kilo 5
16 Lemma Alemu 5 C++ Programming Unity Gerji 6
28 Chane Kebede 2 SQL Database AAU Sidist_Kilo 10
25 Abera Taye 6 VB6 Programming Helico Piazza 8
65 Almaz Belay 2 SQL Database Helico Piazza 9
24 Dereje Tamiru 8 Oracle Database Unity Gerji 5
51 Selam Belay 4 Prolog Programming Jimma Jimma 8
City
94 Alem Kebede 3 Cisco Networking AAU Sidist_Kilo 7
18 Girma Dereje 1 IP Programming Jimma Jimma 4
City
13 Yared Gizaw 7 Java Programming AAU Sidist_Kilo 6

Deletion Anomalies:
If employee with ID 16 is deleted then ever information about skill C++ and
the type of skill is deleted from the database. Then we will not have any
information about C++ and its skill type.

Insertion Anomalies:
What if we have a new employee with a skill called Pascal? We can not
decide weather Pascal is allowed as a value for skill and we have no clue
about the type of skill that Pascal should be categorized as.

Modification Anomalies:
What if the address for Helico is changed from Piazza to Mexico? We need
to look for every occurrence of Helico and change the value of School_Add
from Piazza to Mexico, which is prone to error.

Database-management system can work only with the information that we put
explicitly into its tables for a given database and into its rules for working with those
tables, where such rules are appropriate and possible.

Itec 222 9
Database Systems

Functional Dependency (FD)

Before moving to the definition and application of normalization, it is important
to have an understanding of "functional dependency."

Data Dependency
The logical associations between data items that point the database designer in the
direction of a good database design are refered to as determinant or dependent
relationships.

Two data items A and B are said to be in a determinant or dependent relationship

if certain values of data item B always appears with certain values of data item A.
if the data item A is the determinant data item and B the dependent data item then
the direction of the association is from A to B and not vice versa.

The essence of this idea is that if the existence of something, call it A, implies that
B must exist and have a certain value, then we say that "B is functionally
dependent on A." We also often express this idea by saying that "A functionally
determines B," or that "B is a function of A," or that "A functionally governs B."
Often, the notions of functionality and functional dependency are expressed
briefly by the statement, "If A, then B." It is important to note that the value of B
must be unique for a given value of A, i.e., any given value of A must imply just
one and only one value of B, in order for the relationship to qualify for the name
"function." (However, this does not necessarily prevent different values of A from
implying the same value of B.)

However, for the purpose of normalization, we are interested in finding 1..1 (one
to one) dependencies, lasting for all times (intension rather than extension of the
database), and the determinant having the minimal number of attributes.

X  Y holds if whenever two tuples have the same value for X, they must have the
same value for Y

The notation is: AB which is read as; B is functionally dependent on A

In general, a functional dependency is a relationship among attributes. In
relational databases, we can have a determinant that governs one or several other
attributes.

FDs are derived from the real-world constraints on the attributes and they are
properties on the database intension not extension.

Itec 222 10
Database Systems

Example
Dinner Type of Wine
Course
Meat Red
Fish White
Cheese Rose

Since the type of Wine served depends on the type of Dinner, we say Wine is
functionally dependent on Dinner.
Dinner  Wine

Dinner Type of Wine Type of Fork

Course
Meat Red Meat fork
Fish White Fish fork
Cheese Rose Cheese fork

Since both Wine type and Fork type are determined by the Dinner type, we say
Wine is functionally dependent on Dinner and Fork is functionally dependent on
Dinner.
Dinner  Wine
Dinner  Fork

Partial Dependency
If an attribute which is not a member of the primary key is dependent on some
part of the primary key (if we have composite primary key) then that attribute is
partially functionally dependent on the primary key.

Let {A,B} is the Primary Key and C is no key attribute.

Then if {A,B}C and BC

Then C is partially functionally dependent on {A,B}

Full Functional Dependency

If an attribute which is not a member of the primary key is not dependent on some
part of the primary key but the whole key (if we have composite primary key) then
that attribute is fully functionally dependent on the primary key.

Itec 222 11
Database Systems

Let {A,B} be the Primary Key and C is a non- key attribute

Then if {A,B}C and BC and AC does not hold

Then C Fully functionally dependent on {A,B}

Transitive Dependency
In mathematics and logic, a transitive relationship is a relationship of the following
form: "If A implies B, and if also B implies C, then A implies C."

Example:
If Mr X is a Human, and if every Human is an Animal, then Mr X must be an Animal.

Generalized way of describing transitive dependency is that:

If A functionally governs B, AND

If B functionally governs C
THEN A functionally governs C
Provided that neither C nor B determines A i.e. (B / A and C / A)
In the normal notation:

{(AB) AND (BC)} ==> AC provided that B / A and C / A

Itec 222 12
Database Systems

Steps of Normalization:
We have various levels or steps in normalization called Normal Forms. The level
of complexity, strength of the rule and decomposition increases as we move from
one lower level Normal Form to the higher.

A table in a relational database is said to be in a certain normal form if it satisfies

certain constraints.

A normal form below represents a stronger condition than the previous one

Normalization towards a logical design consists of the following steps:

UnNormalized Form(UNF):
Identify all data elements
First Normal Form(1NF):
Find the key with which you can find all data i.e. remove any repeating group
Second Normal Form(2NF):
Remove part-key dependencies (partial dependency). Make all data dependent on the
whole key.
Third Normal Form(3NF)
Remove non-key dependencies (transitive dependencies). Make all data dependent on
nothing but the key.
For most practical purposes, databases are considered normalized if they adhere
to the third normal form (there is no transitive dependency).

First Normal Form (1NF)

Requires that all column values in a table are atomic (e.g., a number is an
atomic value, while a list or a set is not).
We have tow ways of achiving this:
1. Putting each repeating group into a separate table and connecting
them with a primary key-foreign key relationship
2. Moving these repeating groups to a new row by repeating the non-
repeating attributes known as “flattening” the table. If so then Find
the key with which you can find all data

Definition: 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.

Itec 222 13
 Database Systems

Example for First Normal form (1NF )

UNNORMALIZED
EmpID FirstName LastName Skill SkillType School SchoolAdd SkillLevel
12 Abebe Mekuria SQL, Database, AAU, Sidist_Kilo 5
VB6 Programming Helico Piazza 8
16 Lemma Alemu C++ Programming Unity Gerji 6
IP Programming Jimma Jimma 4
City
28 Chane Kebede SQL Database AAU Sidist_Kilo 10
65 Almaz Belay SQL Database Helico Piazza 9
Prolog Programming Jimma Jimma 8
Java Programming AAU City 6
Sidist_Kilo
24 Dereje Tamiru Oracle Database Unity Gerji 5
94 Alem Kebede Cisco Networking AAU Sidist_Kilo 7

FIRST NORMAL FORM (1NF)

Remove all repeating groups. Distribute the multi-valued attributes into different
rows and identify a unique identifier for the relation so that is can be said is a
relation in relational database. Flatten the table.

EmpID FirstName LastName SkillID Skill SkillType School SchoolAdd SkillLevel

12 Abebe Mekuria 1 SQL Database AAU Sidist_Kilo 5
12 Abebe Mekuria 3 VB6 Programming Helico Piazza 8
16 Lemma Alemu 2 C++ Programming Unity Gerji 6
16 Lemma Alemu 7 IP Programming Jimma Jimma 4
City
28 Chane Kebede 1 SQL Database AAU Sidist_Kilo 10
65 Almaz Belay 1 SQL Database Helico Piazza 9
65 Almaz Belay 5 Prolog Programming Jimma Jimma 8
City
65 Almaz Belay 8 Java Programming AAU Sidist_Kilo 6
24 Dereje Tamiru 4 Oracle Database Unity Gerji 5
94 Alem Kebede 6 Cisco Networking AAU Sidist_Kilo 7

Itec 222 14
 Database Systems

Second Normal form 2NF

No partial dependency of a non key attribute on part of the primary key. This
will result in a set of relations with a level of Second Normal Form.
Any table that is in 1NF and has a single-attribute (i.e., a non-composite) key is
automatically also in 2NF.

Definition: 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. no partial dependency.

Example for 2NF:

EMP_PROJ
EmpID EmpName ProjNo ProjName ProjLoc ProjFund ProjMangID Incentive

EMP_PROJ rearranged
EmpID ProjNo EmpName ProjName ProjLoc ProjFund ProjMangID Incentive

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

As we can see, some non key attributes are partially dependent on some part of
the primary key. This can be witnessed by analyzing the first two functional
dependencies (FD1 and FD2). Thus, each Functional Dependencies, with their
dependent attributes should be moved to a new relation where the Determinant
will be the Primary Key for each.

Itec 222 15
 Database Systems

EMPLOYEE
EmpID EmpName
PROJECT
ProjNo ProjName ProjLoc ProjFund ProjMangID
EMP_PROJ
EmpID ProjNo Incentive

Third Normal Form (3NF)

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.
This level avoids update and deletes anomalies.

Definition: a Table (Relation) is in 3NF

If
 It is in 2NF and
 There are no transitive dependencies between a primary key and
non-primary key attributes.

Example for (3NF)

Assumption: Students of same batch (same year) live in one building or
dormitory
STUDENT
StudID Stud_F_Name Stud_L_Name Dept Year Dormitary
125/97 Abebe Mekuria Info Sc 1 401
654/95 Lemma Alemu Geog 3 403
842/95 Chane Kebede CompSc 3 403
165/97 Alem Kebede InfoSc 1 401
985/95 Almaz Belay Geog 3 403

This schema is in its 2NF since the primary key is a single attribute and
there are no repeating groups (multi valued attributes).

Let’s take StudID, Year and Dormitary and see the dependencies.

StudIDYear AND YearDormitary

Itec 222 16
 Database Systems

AndYear can not determine StudID and Dormitary can not 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 Key
relationship.

STUDENT DORM
StudID Stud Stud Dept Year Year Dormitary
F_Name L_Name 1 401
125/97 Abebe Mekuria Info Sc 1
3 403
654/95 Lemma Alemu Geog 3
842/95 Chane Kebede CompSc 3
165/97 Alem Kebede InfoSc 1
985/95 Almaz Belay Geog 3

Generally, eventhough there are other four additional levels of Normalization, a

table is said to be normalized if it reaches 3NF. A database with all tables in the
3NF is said to be Normalized Database.

Mnemonic for remembering the rationale for normalization up to 3NF could be

the following:

1. No Repeating or Redunduncy: no repeting fields in the table.

2. The Fields Depend Upon the Key: the table should solely depend on the key.
3. The Whole Key: no partial keybdependency.
4. And Nothing But the Key: no inter data dependency.
5. So Help Me Codd: since Codd came up with these rules.

Itec 222 17
 Database Systems

Other Levels of Normalization

Boyce-Codd Normal Form (BCNF):

BCNF is based on functional dependency that takes in to account all the candidate
keys in a relation.
So, table is in BCNF if it is in 3NF and if every determinant is a candidate key.
Violation of the BCNF is very rare. The potential sources for violation of this rule are
1. The relation contains two (or more) composite candidate keys
2. The candidate keys over lap i.e. have common attribute.

The issue is related to:

Isolating Independent Multiple Relationships - No table may contain two or more 1:N
or N:M relationships that are not directly related.

The correct solution, to cause the model to be in 4th normal form, is to ensure that all
M:M relationships are resolved independently if they are indeed independent, as
shown below.

Forth Normal form (4NF)

Isolate Semantically Related Multiple Relationships - There may be practical
constrains on information that justify separating logically related many-to-many
relationships.
MVD(Multi-Valued Dependency ) : represents a dependency between attributes( for
example A, B,C) in a relation such that for every value of A there is a set of values
for B and there is a set of values for C but the sets B and C are independent to each
other.

MVD between attributes A, B, and C in a relation is represented as follows

A------>>B
A------->>C

Def: A table is in 4NF if it is in BCNF and if it has no multi-valued dependencies.

Fifth Normal Form (5NF)

Sometimes called the Project –Join –Normal Form (PJNF)
5NF is based on the Join dependency.
Join Dependency: a property of decomposition that ensures that no spurious are
generated when rejoining to obtain the original relation

18
 Database Systems

Def: A table is in 5NF, also called "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 model free from all modification anomalies.

Def: A table is in DKNF if every constraint on the table is a logical consequence

of the definition of keys and domains.

The underlying ideas in normalization are simple enough. Through normalization

we want to design for our relational database a set of tables that;
(1) Contain all the data necessary for the purposes that the database is to serve,
(2) Have as little redundancy as possible,
(3) Accommodate multiple values for types of data that require them,
(4) Permit efficient updates of the data in the database, and
(5) Avoid the danger of losing data unknowingly.

19
Database Systems

Pitfalls of Normalization

Problems associated with 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

20
Database Systems

Chapter Five

Physical Database Design Methodology

for Relational Database
We have established that there are three levels of database design:

 Conceptual design: producing a data model which accounts for the relevant
entities and relationships within the target application domain;
 Logical design: ensuring, via normalization procedures and the definition
of integrity rules, that the stored database will be non-redundant and
properly connected;
 Physical design: specifying how database records are stored, accessed and
related to ensure adequate performance.

It is considered desirable to keep these three levels quite separate -- one of

Codd's requirements for an RDBMS is that it should maintain logical-
physical data independence. The generality of the relational model means
that RDBMSs are potentially less efficient than those based on one of the
older data models where access paths were specified once and for all at the
design stage. However the relational data model does not preclude the use
of traditional techniques for accessing data - it is still essential to exploit
them to achieve adequate performance with a database of any size.

We can consider the topic of physical database design from three aspects:
 What techniques for storing and finding data exist
 Which are implemented within a particular DBMS
 Which might be selected by the designer for a given application knowing
the properties of the data

Thus the purpose of physical database design is:

1. How to map the logical database design to a physical database design.

2. How to design base relations for target DBMS.
3. How to design enterprise constraints for target DBMS.
4. How to select appropriate file organizations based on analysis of
transactions.
5. When to use secondary indexes to improve performance.
6. How to estimate the size of the database
7. How to design user views

21
Database Systems

8. How to design security mechanisms to satisfy user requirements.

9. How to design procedures and triggers.

Physical database design is the process of producing a description of the

implementation of the database on secondary storage.
Physical design describes the base relation, file organization, and indexes
used to achieve efficient access to the data, and any associated integrity
constraints and security measures.

 Sources of information for the physical design process include global

logical data model and documentation that describes model. Set of
normalized relation.
 Logical database design is concerned with the what; physical database
design is concerned with the how.
 The process of producing a description of the implementation of the
database on secondary storage.
 Describes the storage structures and access methods used to achieve
efficient access to the data.

Steps in physical database design

1. Translate logical data model for target DBMS
1.1. Design base relation
1.2. Design representation of derived data
1.3. Design enterprise constraint
2. Design physical representation
2.1. Analyze transactions
2.2. Choose file organization
2.3. Choose indexes
2.4. Estimate disk space and system requirement
3. Design user view
4. Design security mechanisms
5. Consider controlled redundancy
6. Monitor and tune the operational system

22
Database Systems

1. Translate logical data model for target DBMS

This phase is the translation of the global logical data model to produce a
relational database schema in the target DBMS. This includes creating the
data dictionary based on the logical model and information gathered.
After the creation of the data dictionary, the next activity is to understand
the functionality of the target DBMS so that all necessary requirements are
fulfilled for the database intended to be developed.

Knowledge of the DBMS includes:

 how to create base relations
 whether the system supports:
o definition of Primary key
o definition of Foreign key
o definition of Alternate key(Unique keys)
o definition of Domains
o Referential integrity constraints
o definition of enterprise level constraints

1.1. Design base relation

To decide how to represent base relations identified in global logical
model in target DBMS.
Designing base relation involves identification of all necessary requirements
about a relation starting from the name up to the referential integrity
constraints.
For each relation, need to define:
 The name of the relation;
 A list of simple attributes in brackets;
 The PK and, where appropriate, AKs and FKs.
 A list of any derived attributes and how they should be computed;
 Referential integrity constraints for any FKs identified.
For each attribute, need to define:
 Its domain, consisting of a data type, length, and any constraints on
the domain;
 An optional default value for the attribute;
 Whether the attribute can hold nulls.

23
Database Systems

 Whether the attribute can be derived , if do how it should be

computed

The implementation of the physical model is dependent on the target DBMS

since some has more facilities than the other in defining database
definitions.
The base relation design along with every justifiable reason should be fully
documented.

1.2. Design representation of derived data

While analyzing the requirement of users, we may encounter that there are
some attributes holding data that will be derived from existing or other
attributes. A decision on how to represent any derived data present in the
global logical data model in the target DBMS should be devised.

Examine logical data model and data dictionary, and produce list of all
derived attributes. Most of the time derived attributes are not expressed in
the logical model but will be included in the data dictionary. Whether to store
derived attributes in a base relation or calculate them when required is a decision
to be made by the designer considering the performance impact.
Option selected is based on:
 Additional cost to store the derived data and keep it consistent with
operational data from which it is derived;
 Cost to calculate it each time it is required.
Less expensive option is chosen subject to performance constraints.
The representation of derived attributes should be fully documented.

1.3. Design enterprise constraint

Data in the database is not only subjected to constraints on the database and
the data model used but also with some enterprise dependent constraints.
These constraint definitions are also dependent on the DBMS selected and
enterprise level requirements.
One need to know the functionalities of the DBMS since in designing the
enterprise constraints for the target DBMS some DBMS provide more
facilities than others.

24
Database Systems

All the enterprise level constraints and the definition method in the target
DBMS should be fully documented.

2. Design physical representation

This phase is the level for determining the optimal file organizations to
store the base relations and the indexes that are required to achieve
acceptable performance; that is, the way in which relations and tuples will
be held on secondary storage.
Number of factors that may be used to measure efficiency:
 Transaction throughput: number of transactions processed in given
time interval.
 Response time: elapsed time for completion of a single transaction.
 Disk storage: amount of disk space required to store database files.
However, no one factor is always correct.
Typically, have to trade one factor off against another to achieve a
reasonable balance.

2.1. Analyze transactions

The objective here is to understand the functionality of the transactions
that will run on the database and to analyze the important transactions.
Attempt to identify performance criteria, e.g.:
 Transactions that run frequently and will have a significant impact
on performance;
 Transactions that are critical to the business;
 Times during the day/week when there will be a high demand
made on the database (called the peak load).
Use this information to identify the parts of the database that may cause
performance problems.
To select appropriate file organizations and indexes, also need to know high-
level functionality of the transactions, such as:
 Attributes that are updated in an update transaction;
 Criteria used to restrict tuples that are retrieved in a query.
Often not possible to analyze all expected transactions, so investigate most
‘important’ ones.
To help identify which transactions to investigate, can use:
 Transaction/relation cross-reference matrix, showing relations that
each transaction accesses, and/or

25
Database Systems

 Transaction usage map, indicating which relations are potentially

heavily used.
To focus on areas that may be problematic:
1. Map all transaction paths to relations.
2. Determine which relations are most frequently accessed by
transactions.
3. Analyze the data usage of selected transactions that involve these
relations.

2.2. Choose file organization

The objective here is to determine an efficient file organization for each
base relation
File organizations include Heap, Hash, Indexed Sequential office Access
Method (ISAM), B+-Tree, and Clusters.

Most DBMSs provide little or no option to select file organization.

However, they prove the user with an option to select an index for every
relation

2.3. Choose indexes

The objective here is to determine whether adding indexes will improve
the performance of the system.
One approach is to keep tuples unordered and create as many secondary
indexes as necessary.
Another approach is to order tuples in the relation by specifying a primary
or clustering index.
In this case, choose the attribute for ordering or clustering the tuples as:
 Attribute that is used most often for join operations - this makes join
operation more efficient, or
 Attribute that is used most often to access the tuples in a relation in
order of that attribute.
If ordering attribute chosen is on the primary key of a relation, index will
be a primary index; otherwise, index will be a clustering index.
Each relation can only have either a primary index or a clustering index.
Secondary indexes provide a mechanism for specifying an additional key
for a base relation that can be used to retrieve data more efficiently.
Overhead involved in maintenance and use of secondary indexes that has to be
balanced against performance improvement gained when retrieving data.

26
Database Systems

This includes:
 Adding an index record to every secondary index whenever tuple is
inserted;
 Updating a secondary index when corresponding tuple is updated;
 Increase in disk space needed to store the secondary index;
 Possible performance degradation during query optimization to
consider all secondary indexes.
Guidelines for Choosing Indexes
(1) Do not index small relations.
(2) Index PK of a relation if it is not a key of the file organization.
(3) Add secondary index to a FK if it is frequently accessed.
(4) Add secondary index to any attribute that is heavily used as a
secondary key.
(5) Add secondary index on attributes that are involved in: selection or
join criteria; ORDER BY; GROUP BY; and other operations
involving sorting (such as UNION or DISTINCT).
(6) Add secondary index on attributes involved in built-in functions.
(7) Add secondary index on attributes that could result in an index-
only plan.
(8) Avoid indexing an attribute or relation that is frequently updated.
(9) Avoid indexing an attribute if the query will retrieve a significant
proportion of the tuples in the relation.
(10) Avoid indexing attributes that consist of long character strings.

2.4. Estimate disk space and system requirement

The objective here is to estimate the amount of disk space that will be
required by the database.
Purpose is to answer the following questions:
 If system already exists: is there adequate storage?
 If procuring new system: what storage will be required?

3. Design user view

To design the user views that was identified during the Requirements
Collection and Analysis stage of the relational database application
development lifecycle.
Define views in DDL to provide user views identified in data model
Map onto objects in physical data model
27
Database Systems

4. Design security mechanisms

To design the security measures for the database as specified by the users.
System security – Authentication
Data security-authorizations

5. Consider the Introduction of Controlled

Redundancy
The objective here is to determine whether introducing redundancy in a
controlled manner by relaxing the normalization rules will improve the
performance of the system. This is sometimes known as denormalization
Informally speaking, denormalization is merging of relations
Result of normalization is a logical database design that is structurally
consistent and has minimal redundancy.
However, sometimes a normalized database design does not provide
maximum processing efficiency.
It may be necessary to accept the loss of some of the benefits of a fully
normalized design in favor of performance.
Also consider that denormalization:
 Makes implementation more complex;
 Often sacrifices flexibility;
 May speed up retrievals but it slows down updates.
Denormalization refers to a refinement to relational schema such that the
degree of normalization for a modified relation is less than the degree of at least
one of the original relations.
Also use term more loosely to refer to situations where two relations are
combined into one new relation, which is still normalized but contains more
nulls than original relations. No fixed rule when to denormalize but ,
Consider denormalization in following situations, specifically to speed up
frequent or critical transactions:
 Step 1 Combining 1:1 relationships
 Step 2 Duplicating non-key attributes in 1:* relationships to reduce joins
 Step 3 Duplicating foreign key attributes in 1:* relationships to reduce joins
 Step 4 Introducing repeating groups
 Step 5 Merging lookup tables with base relations
 Step 6 Creating extract tables.

28
Database Systems

6. Monitoring and Tuning the operational system

The objective here is to monitor operational system and improve performance
of system to correct inappropriate design decisions or reflect changing
requirements.

Importance of monitoring and tuning the operational system

 Avoids procurement of additional hardware
 Down size the hardware configuration less and cheaper
hardware less expensive maintenance.
 Faster response time and high throughput more productive
 Faster response time good staff moral, customer satisfaction

29
Database Systems

Chapter Six
Relational Query Languages
In addition to the structural component of any data model equally important is
the manipulation mechanism. This component of any data model is called the
“query language”.

 Query languages: Allow manipulation and retrieval of data from a

database.
 Query Languages! = programming languages!
 QLs not intended to be used for complex calculations.
 QLs support easy, efficient access to large data sets.
 Relational model supports simple, powerful query languages.

Formal Relational Query Languages

 There are varieties of Query languages used by relational DBMS for
manipulating relations.

 Some of them are procedural

 User tells the system exactly what and how to manipulate the data
 Others are non-procedural
 User states what data is needed rather than how it is to be retrieved.

Two mathematical Query Languages form the basis for Relational Query
Languages
 Relational Algebra:
 Relational Calculus:

 We may describe the relational algebra as procedural language: it can be

used to tell the DBMS how to build a new relation from one or more
relations in the database.
 We may describe relational calculus as a non procedural language: it can
be used to formulate the definition of a relation in terms of one or more
database relations.
 Formally the relational algebra and relational calculus are equivalent to
each other. For every expression in the algebra, there is an equivalent
expression in the calculus.
 Both are non-user friendly languages. They have been used as the basis for
other, higher-level data manipulation languages for relational databases.

30
Database Systems

A query is applied to relation instances, and the result of a query is also a relation
instance.
 Schemas of input relations for a query are fixed
 The schema for the result of a given query is also fixed! Determined
by definition of query language constructs.

Relational Algebra
The basic set of operations for the relational model is known as the relational
algebra. These operations enable a user to specify basic retrieval requests.

The result of the retrieval is a new relation, which may have been formed from one
or more relations. The algebra operations thus produce new relations, which can
be further manipulated using operations of the same algebra.

A sequence of relational algebra operations forms a relational algebra expression,

whose result will also be a relation that represents the result of a database query
(or retrieval request).

 Relational algebra is a theoretical language with operations that work on

one or more relations to define another relation without changing the
original relation.
 The output from one operation can become the input to another operation
(nesting is possible)

 There are different basic operations that could be applied on

relations on a database based on the requirement.
 Selection (  ) Selects a subset of rows from a relation.
 Projection (  ) Deletes unwanted columns from a relation.
 Renaming: assigning intermediate relation for a single operation
 Cross-Product ( x ) Allows to concatenate a tuple from one
relation with all the tuples from the other relation.
 Set-Difference ( - ) Tuples in relation R1, but not in relation R2.
 Union ( ) Tuples in relation R1, or in relation R2.
 Intersection () Tuples in relation R1 and in relation R1
 Join Tuples joined from two relations based on a condition
Join and intersection are derivable from the rest.
 Using these, we can build up sophisticated database queries.

31
 Database Systems

Table1:
Sample table used to illustrate different kinds of relational
operations. The relation contains information about employees, IT
skills they have and the school where they attend each skill.

Employee
EmpID FName LName SkillID Skill SkillType School SchoolAdd SkillLevel
12 Abebe Mekuria 2 SQL Database AAU Sidist_Kilo 5
16 Lemma Alemu 5 C++ Programming Unity Gerji 6
28 Chane Kebede 2 SQL Database AAU Sidist_Kilo 10
25 Abera Taye 6 VB6 Programming Helico Piazza 8
65 Almaz Belay 2 SQL Database Helico Piazza 9
24 Dereje Tamiru 8 Oracle Database Unity Gerji 5
51 Selam Belay 4 Prolog Programming Jimma Jimma City 8
94 Alem Kebede 3 Cisco Networking AAU Sidist_Kilo 7
18 Girma Dereje 1 IP Programming Jimma Jimma City 4
13 Yared Gizaw 7 Java Programming AAU Sidist_Kilo 6

32
Database Systems

1. Selection
 Selects subset of tuples/rows in a relation that satisfy selection condition.
 Selection operation is a unary operator (it is applied to a single relation)
 The Selection operation is applied to each tuple individually
 The degree of the resulting relation is the same as the original relation but
the cardinality (no. of tuples) is less than or equal to the original relation.
 The Selection operator is commutative.
 Set of conditions can be combined using Boolean operations ((AND), (OR),
and ~(NOT))
 No duplicates in result!
 Schema of result identical to schema of (only) input relation.
 Result relation can be the input for another relational algebra operation!
(Operator composition.)
 It is a filter that keeps only those tuples that satisfy a qualifying condition
(those satisfying the condition are selected while others are discarded.)

Notation:
<Selection Condition> <Relation Name>
Example: Find all Employees with skill type of Database.

< SkillType =”Database”> (Employee)

This query will extract every tuple from a relation called Employee with all the
attributes where the SkillType attribute with a value of “Database”.

The resulting relation will be the following.

EmpID FName LName SkillID Skill SkillType School SchoolAdd SkillLevel

12 Abebe Mekuria 2 SQL Database AAU Sidist_Kilo 5
28 Chane Kebede 2 SQL Database AAU Sidist_Kilo 10
65 Almaz Belay 2 SQL Database Helico Piazza 9
24 Dereje Tamiru 8 Oracle Database Unity Gerji 5

If the query is all employees with a SkillType Database and School Unity the
relational algebra operation and the resulting relation will be as follows.

< SkillType =”Database” AND School=”Unity”> (Employee)

EmpID FName LName SkillID Skill SkillType School SchoolAdd SkillLevel
24 Dereje Tamiru 8 Oracle Database Unity Gerji 5

33
Database Systems

2. Projection
 Selects certain attributes while discarding the other from the base relation.
 The PROJECT creates a vertical partitioning – one with the needed columns
(attributes) containing results of the operation and other containing the
discarded Columns.
 Deletes attributes that are not in projection list.
 Schema of result contains exactly the fields in the projection list, with the
same names that they had in the (only) input relation.
 Projection operator has to eliminate duplicates!
 Note: real systems typically don’t do duplicate elimination unless
the user explicitly asks for it.
 If the Primary Key is in the projection list, then duplication will not occur
 Duplication removal is necessary to insure that the resulting table is also a
relation.

Notation:
<Selected Attributes> <Relation Name>
Example: To display Name, Skill, and Skill Level of an employee, the query and
the resulting relation will be:

<FName, LName, Skill, Skill_Level> (Employee)

FName LName Skill SkillLevel
Abebe Mekuria SQL 5
Lemma Alemu C++ 6
Chane Kebede SQL 10
Abera Taye VB6 8
Almaz Belay SQL 9
Dereje Tamiru Oracle 5
Selam Belay Prolog 8
Alem Kebede Cisco 7
Girma Dereje IP 4
Yared Gizaw Java 6
If we want to have the Name, Skill, and Skill Level of an employee with Skill SQL
and SkillLevel greater than 5 the query will be:

<FName, LName, Skill, Skill_Level> ( (Employee))

<Skill=”SQL”  SkillLevel>5>
FName LName Skill SkillLevel
Chane Kebede SQL 10
Almaz Belay SQL 9

34
Database Systems

3. Rename Operation
 We may want to apply several relational algebra operations one after the
other. The query could be written in two different forms:
1. Write the operations as a single relational algebra expression by
nesting the operations.
2. Apply one operation at a time and create intermediate result
relations. In the latter case, we must give names to the relations
that hold the intermediate resultsRename Operation

If we want to have the Name, Skill, and Skill Level of an employee with salary
greater than 1500 and working for department 5, we can write the expression for
this query using the two alternatives:

1. A single algebraic expression:

The above used query is using a single algebra operation, which is:

<FName, LName, Skill, Skill_Level> ( (Employee))

<Skill=”SQL”  SkillLevel>5>

2. Using an intermediate relation by the Rename Operation:

Step1: Result1  <DeptNo=5  Salary>1500> (Employee)

Step2: Result <FName, LName, Skill, Skill_Level> (Result1)

Then Result will be equivalent with the relation we get using the first
alternative.

35
Database Systems

4. Set Operations
The three main set operations are the Union, Intersection and Set Difference. The
properties of these set operations are similar with the concept we have in
mathematical set theory. The difference is that, in database context, the elements
of each set, which is a Relation in Database, will be tuples. The set operations are
Binary operations which demand the two operand Relations to have type
compatibility feature.

Type Compatibility
Two relations R1 and R2 are said to be Type Compatible if:
1. The operand relations R1(A1, A2, ..., An) and R2(B1, B2, ..., Bn) have the
same number of attributes, and
2. The domains of corresponding attributes must be compatible; that is,
Dom(Ai)=Dom(Bi) for i=1, 2, ..., n.

To illustrate the three set operations, we will make use of the following two tables:
Employee
EmpID FName LName SkillID Skill SkillType School SkillLevel
12 Abebe Mekuria 2 SQL Database AAU 5
16 Lemma Alemu 5 C++ Programming Unity 6
28 Chane Kebede 2 SQL Database AAU 10
25 Abera Taye 6 VB6 Programming Helico 8
65 Almaz Belay 2 SQL Database Helico 9
24 Dereje Tamiru 8 Oracle Database Unity 5
51 Selam Belay 4 Prolog Programming Jimma 8
94 Alem Kebede 3 Cisco Networking AAU 7
18 Girma Dereje 1 IP Programming Jimma 4
13 Yared Gizaw 7 Java Programming AAU 6

RelationOne: Employees who attend Database Course

EmpID FName LName SkillID Skill SkillType School SkillLevel
12 Abebe Mekuria 2 SQL Database AAU 5
28 Chane Kebede 2 SQL Database AAU 10
65 Almaz Belay 2 SQL Database Helico 9
24 Dereje Tamiru 8 Oracle Database Unity 5

RelationTwo : Employees who attend a course in AAU

EmpID FName LName SkillID Skill SkillType School SkillLevel
12 Abebe Mekuria 2 SQL Database AAU 5
94 Alem Kebede 3 Cisco Networking AAU 7
28 Chane Kebede 2 SQL Database AAU 10
13 Yared Gizaw 7 Java Programming AAU 6

36
Database Systems

a. UNION Operation
The result of this operation, denoted by R U S, is a relation that
includes all tuples that are either in R or in S or in both R and S.
Duplicate tuple is eliminated.
The two operands must be "type compatible"

Eg: RelationOne U RelationTwo

Employees who attend Database in any School or who attend any course at AAU

EmpID FName LName SkillID Skill SkillType School SkillLevel

12 Abebe Mekuria 2 SQL Database AAU 5
28 Chane Kebede 2 SQL Database AAU 10
65 Almaz Belay 2 SQL Database Helico 9
24 Dereje Tamiru 8 Oracle Database Unity 5
94 Alem Kebede 3 Cisco Networking AAU 7
13 Yared Gizaw 7 Java Programming AAU 6

b. INTERSECTION Operation
The result of this operation, denoted by R ∩ S, is a relation that
includes all tuples that are in both R and S. The two operands must
be "type compatible"
Eg: RelationOne ∩ RelationTwo
Employees who attend Database Course at AAU

EmpID FName LName SkillID Skill SkillType School SkillLevel

12 Abebe Mekuria 2 SQL Database AAU 5
28 Chane Kebede 2 SQL Database AAU 10

c. Set Difference (or MINUS) Operation

The result of this operation, denoted by R - S, is a relation that includes
all tuples that are in R but not in S.
The two operands must be "type compatible"
Eg: RelationOne - RelationTwo
Employees who attend Database Course but didn’t take any course at AAU
EmpID FName LName SkillID Skill SkillType School SkillLevel
65 Almaz Belay 2 SQL Database Helico 9
24 Dereje Tamiru 8 Oracle Database Unity 5

37
Database Systems

Eg: RelationTwo - RelationOne

Employees who attend Database Course but didn’t take any course at AAU

EmpID FName LName SkillID Skill SkillType School SkillLevel

12 Abebe Mekuria 2 SQL Database AAU 5
94 Alem Kebede 3 Cisco Networking AAU 7
28 Chane Kebede 2 SQL Database AAU 10
13 Yared Gizaw 7 Java Programming AAU 6

The resulting relation for; R1  R2, R1  R2, or R1-R2 has the same attribute
names as the first operand relation R1 (by convention).

Some Properties of the Set Operators

Notice that both union and intersection are commutative operations; that is
R  S = S  R, and R  S = S  R

Both union and intersection can be treated as n-nary operations applicable

to any number of relations as both are associative operations; that is
R  (S  T) = (R  S)  T, and (R  S)  T = R  (S  T)

The minus operation is not commutative; that is, in general

R-S≠S–R

5. CARTESIAN (cross product) Operation

This operation is used to combine tuples from two relations in a combinatorial
fashion. That means, every tuple in Relation (R) will be related with every other
tuple in Relation (S).
x
 In general, the result of R(A1, A2, . . ., An) S(B1,B2, . . ., Bm) is a relation
Q with degree n + m attributes Q(A1, A2, . . ., An, B1, B2, . . ., Bm), in that
order.
 Where R has n attributes and S has m attributes.
 The resulting relation Q has one tuple for each combination of
tuples—one from R and one from S.
 Hence, if R has n tuples, and S has m tuples, then | R x S | will have
n* m tuples.

38
 Database Systems

Example:

Employee
ID FName LName
123 Abebe Lemma
567 Belay Taye
822 Kefle Kebede

Dept
DeptID DeptName MangID
2 Finance 567
3 Personnel 123

Then the Cartesian product between Employee and Dept relations will be of the
form:

Employee X Dept:
ID FName LName DeptID DeptName MangID
123 Abebe Lemma 2 Finance 567
123 Abebe Lemma 3 Personnel 123
567 Belay Taye 2 Finance 567
567 Belay Taye 3 Personnel 123
822 Kefle Kebede 2 Finance 567
822 Kefle Kebede 3 Personnel 123

Basically, even though it is very important in query processing, the Cartesian

Product is not useful by itself since it relates every tuple in the First Relation with
every other tuple in the Second Relation. Thus, to make use of the Cartesian
Product, one has to use it with the Selection Operation, which discriminate tuples of
a relation by testing whether each will satisfy the selection condition.
In our example, to extract employee information about managers of the departments
(Managers of each department), the algebra query and the resulting relation will be.

<ID, FName, LName, DeptName > ( <ID=MangID> (Employee X Dept))

ID FName LName DeptName
123 Abebe Lemma Personnel
567 Belay Taye Finance

39
Database Systems

6. JOIN Operation
The sequence of Cartesian product followed by select is used quite commonly to
identify and select related tuples from two relations, a special operation, called
JOIN. Thus in JOIN operation, the Cartesian Operation and the Selection
Operations are used together.
JOIN Operation is denoted by a symbol.
This operation is very important for any relational database with more than a
single relation, because it allows us to process relationships among relations.
The general form of a join operation on two relations
R(A1, A2,. . ., An) and S(B1, B2, . . ., Bm) is:

R S
<join condition> is equivalent to (R X S)
<selection condition>

where <join condition> and <selection condition> are the same

Where, R and S can be any relation that results from general relational algebra
expressions.
Since JOIN is an operation that needs two relation, it is a Binary operation.

This type of JOIN is called a THETA JOIN ( - JOIN)

Where  is the logical operator used in the join condition.
 Could be { <,  , >, , , = }

Example:
Thus in the above example we want to extract employee information about
managers of the departments, the algebra query using the JOIN operation will
be.

Employee < ID=MangID>Dept

a. EQUIJOIN Operation
The most common use of join involves join conditions with equality comparisons
only (=). Such a join, where the only comparison operator used is the equal sign is
called an EQUIJOIN. In the result of an EQUIJOIN we always have one or more
pairs of attributes (whose names need not be identical) that have identical values
in every tuple since we used the equality logical operator.
For example, the above JOIN expression is an EQUIJOIN since the logical
operator used is the equal to operator (=).

40
Database Systems

b. NATURAL JOIN Operation

We have seen that in EQUIJOIN one of each pair of attributes with identical values
is extra, a new operation called natural join was created to get rid of the second
(or extra) attribute that we will have in the result of an EQUIJOIN condition.
The standard definition of natural join requires that the two join attributes, or each
pair of corresponding join attributes, have the same name in both relations. If this
is not the case, a renaming operation on the attributes is applied first.

R1R S represents a natural join between R and S. The degree of R 1 is

degree of R plus Degree of S less the number of common attributes
c. OUTER JOIN Operation
OUTER JOIN is another version of the JOIN operation where non matching tuples
from a relation are also included in the result with NULL values for attributes in
the other relation.
There are two major types of OUTER JOIN.
1. RIGHT OUTER JOIN: where non matching tuples from the second (Right)
relation are included in the result with NULL value for attributes of the first
(Left) relation.
2. LEFT OUTER JOIN: where non matching tuples from the first (Left)
relation are included in the result with NULL value for attributes of the
second (Right) relation.

Notation for Left Outer Join:

R <Join Condition > S theta left outer Join

R S  natural left outer join

When two relations are joined by a JOIN operator, there could be some tuples in
the first relation not having a matching tuple from the second relation, and the
query is interested to display these non matching tuples from the first or second
relation. Such query is represented by the OUTER JOIN.

d. SEMIJOIN Operation
SEMI JOIN is another version of the JOIN operation where the resulting Relation
will contain those attributes of only one of the Relations that are related with tuples
in the other Relation. The following notation depicts the inclusion of only the
attributes form the first relation (R) in the result which are actually participating
in the relationship.

41
Database Systems

R <Join Condition> S
Aggregate functions and Grouping statements
Some queries may involve aggregate function (scalar aggregates
like totals in a report, or Vector aggregates like subtotals in
reports)

a) AL(R): Scalar aggregate functions on relation R with AL

as a list of (<aggregate function > ,<attribute >) pairs

b) GA AL (R):
Vector aggregate functions on relation R with
AL as list of (<aggregate function >, <attribute >) pairs with
a grouping attribute GA.

Example (a): the number of employees in a an organization

(assume you have an employee table)
This is a scalar aggregate

PR(Num_Employees) Count EmpId (Employee) , where PR =

Produce relation R

Example (b): the number of employees in each department of

an organization (assume you have an employee table)
This is a vector aggregate

PR (DeptId, Num_Employees) DeptId Count EmpId

(Employee) , where PR = Produce relation R

42
Database Systems

Relational Calculus
A relational calculus expression creates a new relation, which is specified in
terms of variables that range over rows of the stored database relations (in
tuple calculus) or over columns of the stored relations (in domain calculus).

In a calculus expression, there is no order of operations to specify how to

retrieve the query result. A calculus expression specifies only what
information the result should contain rather than how to retrieve it.

In Relational calculus, there is no description of how to evaluate a query;

this is the main distinguishing feature between relational algebra and
relational calculus.

Relational calculus is considered to be a nonprocedural language. This

differs from relational algebra, where we must write a sequence of
operations to specify a retrieval request; hence relational algebra can be
considered as a procedural way of stating a query.

When applied to relational database, the calculus is not that of derivative

and differential but in a form of first-order logic or predicate calculus, a
predicate is a truth-valued function with arguments.

When we substitute values for the arguments in the predicate, the function
yields an expression, called a proposition, which can be either true or false.

If a predicate contains a variable, as in ‘x is a member of staff’, there must

be a range for x. When we substitute some values of this range for x, the
proposition may be true; for other values, it may be false.

If COND is a predicate, then the set of all tuples evaluated to be true for the
predicate COND will be expressed as follows:
{t | COND(t)}
Where t is a tuple variable and COND (t) is a conditional
expression involving t. The result of such a query is the set of all tuples
t that satisfy COND (t).

43
Database Systems

If we have set of predicates to evaluate for a single query, the predicates can
be connected using (AND), (OR), and ~(NOT)

A relational calculus expression creates a new relation, which is

specified in terms of variables that range over rows of the stored database
relations (in tuple calculus) or over columns of the stored relations (in
domain calculus).

Tuple-oriented Relational Calculus

 The tuple relational calculus is based on specifying a number of tuple
variables. Each tuple variable usually ranges over a particular
database relation, meaning that the variable may take as its value any
individual tuple from that relation.
 Tuple relational calculus is interested in finding tuples for which a
predicate is true for a relation. Based on use of tuple variables.
 Tuple variable is a variable that ‘ranges over’ a named relation: that
is, a variable whose only permitted values are tuples of the relation.
 If E is a tuple that ranges over a relation employee, then it is
represented as EMPLOYEE(E) i.e. Range of E is EMPLOYEE

 Then to extract all tuples that satisfy a certain condition, we will

represent it as all tuples E such that COND(E) is evaluated to be true.
{E  COND(E)}

The predicates can be connected using the Boolean operators:

 (AND),  (OR),  (NOT)

COND(t) is a formula, and is called a Well-Formed-Formula (WFF) if:

 Where the COND is composed of n-nary predicates (formula
composed of n single predicates) and the predicates are
connected by any of the Boolean operators.
 And each predicate is of the form A  B and  is one of the
logical operators { <,  , >, , , = }which could be evaluated

44
 Database Systems

to either true or false. And A and B are either constant or

variables.
 Formulae should be unambiguous and should make sense.

Example (Tuple Relational Calculus)

 Extract all employees whose skill level is greater than or equal to 8
{E | Employee(E)  E.SkillLevel >= 8}

EmpID FName LName SkillID Skill SkillType School SchoolAdd SkillLevel

28 Chane Kebede 2 SQL Database AAU Sidist_Kilo 10
25 Abera Taye 6 VB6 Programming Helico Piazza 8
65 Almaz Belay 2 SQL Database Helico Piazza 9
51 Selam Belay 4 Prolog Programming Jimma Jimma 8
City

 To find only the EmpId, FName, LName, Skill and the School where
the skill is attended where of employees with skill level greater than
or equal to 8, the tuple based relational calculus expression will be:

{E.EmpId, E.FName, E.LName, E.Skill, E.School | Employee(E)  E.SkillLevel >= 8}

EmpID FName LName Skill School

28 Chane Kebede SQL AAU
25 Abera Taye VB6 Helico
65 Almaz Belay SQL Helico
51 Selam Belay Prolog Jimma

 E.FName means the value of the First Name (FName) attribute for the
tuple E.

45
Database Systems

Quantifiers in Relational Calculus

 To tell how many instances the predicate applies to, we can use the
two quantifiers in the predicate logic.
 One relational calculus expressed using Existential Quantifier can
also be expressed using Universal Quantifier.

1. Existential quantifier  (‘there exists’)

Existential quantifier used in formulae that must be true for at
least one instance, such as:
An employee with skill level greater than or equal to 8 will be:
{E | Employee(E)  (E)(E.SkillLevel >= 8)}
This means, there exist at least one tuple of the relation employee
where the value for the SkillLevel is greater than or equal to 8

2. Universal quantifier  (‘for all’)

Universal quantifier is used in statements about every instance,
such as:
An employee with skill level greater than or equal to 8 will be:
{E | Employee(E)  (E)(E.SkillLevel >= 8)}

This means, for all tuples of relation employee where value for the
SkillLevel attribute is greater than or equal to 8.

Example:

Let’s say that we have the following Schema (set of Relations)

Employee(EID, FName, LName, EDID)

Project(PID, PName, PDID)
Dept(DID, DName, DMangID)
WorksOn(WEID, WPID)

To find employees who work on projects controlled by department 5 the

query will be:
{E | Employee(E)  (P)(Project(P)  (w)(WorksOn(w)  PDID =5  EID=WEID))}

46
Database Systems

Domain Relational Calculus

In tuple relational Calculus, we use variables that range over tuples of a relation, in
the case of domain relational calculus we use variables that range over domain
elements (field variables).
 An expression in the domain relational calculus has the following general form
{(x1,x2,x3,….xn)| P(x1,x2,x3,….xn,xm)}

Where (x1,x2,x3,….xn) represents the domain variables and P(x1,x2,x3,….xn,xm)

represents the formula
Formulas are of the form R(x1,x2,x3,….xn), x1 x2 or
xi C where  є {<,>,<=,>=,=,≠} and R is a relation of degree n and each xi is domain
variable
If f1 and f2 are formulas then so are
f1  f2 , f1  f2 ,~f1 , (x)f1 , (x)f1
 The Answer for such a query includes all tuples with attributes (x1,x2,x3,….xn)
that make the formula P(x1,x2,x3,….xn,xm) be true.
 Formula is recursively defined, starting with simple atomic formulas (getting
tuples from relations or making comparisons of values), and building bigger and
better formulas using the logical connectives. i.e the Predicate P can be set of
formula combined by Boolean operators

Example: Consider the schema of relations on page 102.

Query1: list Employees
{Fname, Lname| (Employee (EID,FName, LName)}
Query2: Find the list of Employees who work in the department of IS
Domain relational Calculus expression for the query
{EID,Fname,Lname|(DName,EDID,DID)(Employee(EID,FName,
LName)Department(DID,DName,DMangID)DID=EDIDDName=’IS’)}
, Where DName, EDID, DID DName, EDID, DID
Query3:List the names of employees that do not manage any department
{Fname,Lname|(EID)(Employee(EID,Fname,Lname)
(~(DMangId)(Dept(DID,Dname,DMangId) (EID=DMangId))))}

47
Database Systems

Chapter Seven

Advanced Concepts in Database

Systems

 Database Security and Integrity

 Distributed Database Systems
 Data warehousing

1. Database Security and Integrity

A database represents an essential corporate resource that should be
properly secured using appropriate controls.
 Database security encompasses hardware, software, people and
data

Multi-user database system - DBMS must provide a database security and

authorization subsystem to enforce limits on individual and group access
rights and privileges.

Database security and integrity is about protecting the database from being
inconsistent and being disrupted. We can also call it database misuse.

Database misuse could be Intentional or accidental, where accidental misuse

is easier to cope with than intentional misuse.
Accidental inconsistency could occur due to:
 System crash during transaction processing
 Anomalies due to concurrent access
 Anomalies due to redundancy
 Logical errors

Like wise, even though there are various threats that could be categorized
in this group, intentional misuse could be:
 Unauthorized reading of data

48
Database Systems

 Unauthorized modification of data or

 Unauthorized destruction of data

Most systems implement good Database Integrity to protect the system

from accidental misuse while there are many computer based measures to
protect the system from intentional misuse, which is termed as Database
Security measures.

 Database security is considered in relation to the following situations:

 Theft and fraud
 Loss of confidentiality (secrecy)
 Loss of privacy
 Loss of integrity
 Loss of availability

Security Issues and general considerations

 Legal, ethical and social issues regarding the right to access
information
 Physical control
 Policy issues regarding privacy of individual level at enterprise and
national level
 Operational consideration on the techniques used (password, etc)
 System level security including operating system and hardware
control
 Security levels and security policies in enterprise level

 Database security - the mechanisms that protect the database against

intentional or accidental threats. And Database security encompasses
hardware, software, people and data

 Threat – any situation or event, whether intentional or accidental, that

may adversely affect a system and consequently the organization

49
Database Systems

 A threat may be caused by a situation or event involving a person,

action, or circumstance that is likely to bring harm to an organization
 The harm to an organization may be tangible or intangible
Tangible – loss of hardware, software, or data
Intangible – loss of credibility or client confidence

Examples of threats:
 Using another persons’ means of access
 Unauthorized amendment/modification or copying of data
 Program alteration
 Inadequate policies and procedures that allow a mix of
confidential and normal out put
 Wire-tapping
 Illegal entry by hacker
 Blackmail
 Creating ‘trapdoor’ into system
 Theft of data, programs, and equipment
 Failure of security mechanisms, giving greater access than
normal
 Staff shortages or strikes
 Inadequate staff training
 Viewing and disclosing unauthorized data
 Electronic interference and radiation
 Data corruption owing to power loss or surge
 Fire (electrical fault, lightning strike, arson), flood, bomb
 Physical damage to equipment
 Breaking cables or disconnection of cables
 Introduction of viruses

50
Database Systems

Levels of Security Measures

Security measures can be implemented at several levels and for different
components of the system. These levels are:
1. Physical Level: concerned with securing the site containing the
computer system should be physically secured. The backup systems
should also be physically protected from access except for authorized
users.
2. Human Level: concerned with authorization of database users for access
the content at different levels and privileges.
3. Operating System: concerned with the weakness and strength of the
operating system security on data files. Weakness may serve as a means
of unauthorized access to the database. This also includes protection of
data in primary and secondary memory from unauthorized access.
4. Database System: concerned with data access limit enforced by the
database system. Access limit like password, isolated transaction and etc.
Even though we can have different levels of security and authorization on
data objects and users, who access which data is a policy matter rather than
technical.

These policies
 should be known by the system: should be encoded in the system
 should be remembered: should be saved somewhere (the catalogue)

 An organization needs to identify the types of threat it may be subjected

to and initiate appropriate plans and countermeasures, bearing in mind
the costs of implementing them

51
Database Systems

Countermeasures: Computer based controls

 The types of countermeasure to threats on computer systems range from
physical controls to administrative procedures
 Despite the range of computer-based controls that are available, it is worth
noting that, generally, the security of a DBMS is only as good as that of the
operating system, owing to their close association
 The following are computer-based security controls for a multi-user
environment:
 Authorization
 The granting of a right or privilege that enables a subject to have
legitimate access to a system or a system’s object
 Authorization controls can be built into the software, and govern not
only what system or object a specified user can access, but also what
the user may do with it
 Authorization controls are sometimes referred to as access controls
 The process of authorization involves authentication of subjects (i.e.
a user or program) requesting access to objects (i.e. a database table,
view, procedure, trigger, or any other object that can be created
within the system)

 Views
 A view is the dynamic result of one or more relational operations
operation on the base relations to produce another relation
 A view is a virtual relation that does not actually exist in the
database, but is produced upon request by a particular user
 The view mechanism provides a powerful and flexible security
mechanism by hiding parts of the database from certain users
 Using a view is more restrictive than simply having certain
privileges granted to a user on the base relation(s)
 Integrity
 Integrity constraints contribute to maintaining a secure database
system by preventing data from becoming invalid and hence giving
misleading or incorrect results
 Domain Integrity
 Entity integrity
 Referential integrity
 Key constraints

52
Database Systems

 Backup and recovery

 Backup is the process of periodically taking a copy of the
database and log file (and possibly programs) on to offline
storage media
 A DBMS should provide backup facilities to assist with the
recovery of a database following failure
 Database recovery is the process of restoring the database to a
correct state in the event of a failure
 Journaling is the process of keeping and maintaining a log file
(or journal) of all changes made to the database to enable
recovery to be undertaken effectively in the event of a failure
 The advantage of journaling is that, in the event of a failure, the
database can be recovered to its last known consistent state
using a backup copy of the database and the information
contained in the log file
 If no journaling is enabled on a failed system, the only means
of recovery is to restore the database using the latest backup
version of the database
 However, without a log file, any changes made after the last
backup to the database will be lost

 Encryption
 The encoding of the data by a special algorithm that renders the
data unreadable by any program without the decryption key
 If a database system holds particularly sensitive data, it may be
deemed necessary to encode it as a precaution against possible
external threats or attempts to access it
 The DBMS can access data after decoding it, although there is a
degradation in performance because of the time taken to
decode it
 Encryption also protects data transmitted over communication
lines
 To transmit data securely over insecure networks requires the
use of a Cryptosystem, which includes:

53
Database Systems

Authentication
 All users of the database will have different access levels and
permission for different data objects, and authentication is the process
of checking whether the user is the one with the privilege for the
access level.
 Is the process of checking the users are who they say they are.
 Each user is given a unique identifier, which is used by the operating
system to determine who they are
 Thus the system will check whether the user with a specific username
and password is trying to use the resource.
 Associated with each identifier is a password, chosen by the user and
known to the operation system, which must be supplied to enable the
operating system to authenticate who the user claims to be

Any database access request will have the following three major
components
1. Requested Operation: what kind of operation is requested
by a specific query?
2. Requested Object: on which resource or data of the database
is the operation sought to be applied?
3. Requesting User: who is the user requesting the operation on
the specified object?
The database should be able to check for all the three components before
processing any request. The checking is performed by the security
subsystem of the DBMS.

Forms of user authorization

There are different forms of user authorization on the resource of the database.
These forms are privileges on what operations are allowed on a specific data
object.

54
Database Systems

User authorization on the data/extension

1. Read Authorization: the user with this privilege is allowed only to read the
content of the data object.

2. Insert Authorization: the user with this privilege is allowed only to insert
new records or items to the data object.

3. Update Authorization: users with this privilege are allowed to modify

content of attributes but are not authorized to delete the records.

4. Delete Authorization: users with this privilege are only allowed to delete
a record and not anything else.

 Different users, depending on the power of the user, can have one or the
combination of the above forms of authorization on different data objects.

Role of DBA in Database Security

The database administrator is responsible to make the database to be as secure as
possible. For this the DBA should have the most powerful privilege than every
other user. The DBA provides capability for database users while accessing the
content of the database.

The major responsibilities of DBA in relation to authorization of users are:

1. Account Creation: involves creating different accounts for different USERS
as well as USER GROUPS.

2. Security Level Assignment: involves in assigning different users at different

categories of access levels.

3. Privilege Grant: involves giving different levels of privileges for different

users and user groups.

4. Privilege Revocation: involves denying or canceling previously granted

privileges for users due to various reasons.

5. Account Deletion: involves in deleting an existing account of users or user

groups. Is similar with denying all privileges of users on the database.

55
Database Systems

2. Distributed Database Systems

 Database development facilitates the integration of data available in an
organization and enforces security on data access. But it is not always the
case that organizational data reside in one site. This demand databases at
different sites to be integrated and synchronized with all the facilities of
database approach. This leads to Distributed Database Systems.
 In a distributed database system, the database is stored on several
computers. The computers in a distributed system communicate with each
other through various communication media, such as high speed buses or
telephone line.
 A distributed database system consists of a collection of sites, each of which
maintains a local database system and also participates in global transaction
where different databases are integrated together.
 Even though integration of data implies centralized storage and control, in
distributed database systems the intention is different. Data is stored in
different database systems in a decentralized manner but act as if they are
centralized through development of computer networks.
 A distributed database system consists of loosely coupled sites that share
no physical component and database systems that run on each site are
independent of each other.
 Transactions may access data at one or more sites
 Organization may implement their database system on a number of
separate computer system rather than a single, centralized mainframe.
Computer Systems may be located at each local branch office.

The functionalities of a DDBMS will include: Extended Communication Services,

Extended Data Dictionary, Distributed Query Processing, Extended Concurrency Control
and Extended Recovery Services.

Concepts in DDBMS
 Replication: System maintains multiple copies of data, stored in
different sites, for faster retrieval and fault tolerance.
 Fragmentation: Relation is partitioned into several fragments stored in
distinct sites
 Data transparency: Degree to which system user may remain unaware
of the details of how and where the data items are stored in a distributed
system

56
Database Systems

Advantages of DDBMS
1. Data sharing and distributed control:
 User at one site may be able access data that is available at another site.
 Each site can retain some degree of control over local data
 We will have local as well as global database administrator

2. Reliability and availability of data

 If one site fails the rest can continue operation as long as transaction does not
demand data from the failed system and the data is not replicated in other sites

3. Speedup of query processing

 If a query involves data from several sites, it may be possible to split the query
into sub-queries that can be executed at several sites which is parallel
processing

Disadvantages of DDBMS
1. Software development cost
2. Greater potential for bugs (parallel processing may endanger
correctness)
3. Increased processing overhead (due to communication jargons)
4. Communication problems

Homogeneous and Heterogeneous Distributed Databases

 In a homogeneous distributed database

 All sites have identical software
 Are aware of each other and agree to cooperate in processing user
requests.
 Each site surrenders part of its autonomy in terms of right to change
schemas or software
 Appears to user as a single system
 In a heterogeneous distributed database
 Different sites may use different schemas and software
 Difference in schema is a major problem for query processing
 Difference in software is a major problem for transaction
processing
 Sites may not be aware of each other and may provide only limited
facilities for cooperation in transaction processing

57
Database Systems

3. Data warehousing
 Data warehouse is an integrated, subject-oriented, time-variant,
non-volatile database that provides support for decision making.

 Integrated  centralized, consolidated database that integrates

data derived from the entire organization.

 Consolidates data from multiple and diverse sources with

diverse formats.
 Helps managers to better understand the company’s
operations.
 Subject-Oriented  Data warehouse contains data organized by
topics. Eg. Sales, marketing, finance, etc.

 Time variant: In contrast to the operational data that focus on

current transactions, the warehouse data represent the flow of data
through time.
 Data warehouse contains data that reflect what happened last
week, last month, past five years, and so on.
 Non volatile  Once data enter the data warehouse, they are never
removed. Because the data in the warehouse represent the
company’s entire history.

Differences between database and data warehouse

 Because data is added all the time, warehouse is growing.
 The data warehouse and operational environments are separated.
Data warehouse receives its data from operational databases.
 Data warehouse environment is characterized by read-only
transactions to very large data sets.
 Operational environment is characterized by numerous update
transactions to a few data entities at a time.
 Data warehouse contains historical data over a long time horizon.
 Ultimately Information is created from data warehouses. Such Information
becomes the basis for rational decision making.

 The data found in data warehouse is analyzed to discover previously

unknown data characteristics, relationships, dependencies, or trends.

58