Database Management System

and
ER Modelling

Keshan
Consultant/Lecturer at NIBM
MBA in MOT (Gold Medal & Top of the Batch) University of Moratuwa
BSc in MIS (First Class Honours with Two Gold Medals) University College of Dublin
 Work Hard!!!
Study Hard!!!!
Target A+ for each Subject!!!!
Become a Champion and Make yourself
Proud!!!!
 Introduction
• A database is an integrated collection of logically related records
and files.

• Data are known facts

• Database management system is software package that can use to

create and maintain a database.
 File-Based Data Processing
• Each application has data files that correspond to only that application

Checking Checking Auto Loan Auto

Account Account Data Loan
Data Programs Files
Files Programs

Savings
Savings
Account Account
Data Programs
Files
Example
Programs to print a student's
Student
transcript and to enter new
Details
grades into the
+
file are implemented as part of
Student
the application.
Grades
User 1: Grade
Reporting Officer

Student's Although both users are

Fees interested in data
+ about students, each user
Student maintains separate files-and
Payments programs to manipulate these
+ file
User 2:Accounting Student
Officer Details
 Problems with File-Based Processing
• Data redundancy and inconsistency.
The same data may be duplicated in each application’s file.

• Data inconsistency
The various copies of the same data may no longer agree.

• Difficulty in accessing data.

• Data isolation.
 Database Processing
• All applications interface with the same data in a central database

Checking
Account
Database Programs
Auto
Management Loan
Database
System Programs Savings
Account
Programs
 Why DBMS?
a) Sharing of data
b) Controlling of Redundancy
A multi-user DBMS allows multiple users to access the database at the
same time.
c) Security restrictions
User access to the Database is restricted by account numbers and passwords.
d) Backup and recovery
A DBMS must provide facilities for recovering from hardware and software
failures.
e) Flexibility
Allows changes to the structure of the database without effecting most of the
application programs.
f) Enforcing integrity constraints (accuracy of data)

g) Reduced application development time

Designing a new database may take time.
 DBMS Disadvantages
• High initial investment in hardware, software and training.

• Unnecessary overhead costs in providing security, concurrent control

and recovery as compared to traditional file processing systems.

• A DBMS is a large program which requires more disk space and a

more powerful computer than for a traditional file system.

• Greater impact on system failure.

Hierarchical Structure of Database
DATA BASE
FILE (TABLE)
RECORD (ROW)
FIELD (COLUMN)
CHARACTERS
 Flat File System
A relatively simple database system in which each data item is stored in a single table.
 Entity Relationship Model
• ER model is a high level logical data model which can be used in designing a
database.

• The ER model uses 3 main constructs:

Entities:
An “entity” is an object with a physical existence.
Eg : person, car, house, employee, course.

Attributes:
Each entity has properties called “Attributes” that describes the entity.
A person has attributes like : Name, height, weight, nationality
A car has attributes like : Color, model, make
 Relationships :
A relationship is an association (connection) between two or more
entities.

There are two types of Entities.

1. Strong entity
It has it’s own key attribute (primary key).
Eg : Empno can take as a key attribute for the employee entity.
Therefore employee is a strong entity.

2. Weak entity
Entity types that do not have key attributes of their own are called
weak entities.
 Key attributes (Primary key)
An Entity can be uniquely identified by a key attribute.
Eg: EmpNo, NIC

A weak entity has a partial key which can be used to distinguished two
weak entities belongs to the same owner entity.
Eg : Consider the entity : DEPENDENT
It has attributes : Dependent name, DOB, Relationship

If we take two entries of the dependent entity it is possible to have same values for the above 3
attributes.

Therefore to separate two weak entities the key attribute of the weak entity is develop with the
help of the owner (strong) entity.

The full primary key of a weak entity is the combination of Empno & Dependent name.
 Types of Attributes

1. Simple or Atomic Attributes

An attribute that is not divisible (broken down into smaller
components). Eg: Salary

2. Composite Attributes
Composite attributes can divide in to more basic attributes.
House no

Street name Basic (atomic)

Address
attributes
City
3. Single valued & multi valued attributes
Most attributes have a single value.
Eg: age
Some attributes can have more than one value.
Eg: “location” attribute of a department
“college degree” attribute of a person

4. Stored attributes
An attribute whose value is fixed and cannot change.
Eg: Date of Birth, NIC

5. Derived attributes
An attribute whose value can be calculated from a stored attribute.
Eg: Age can be calculate using DOB
 Relationship Constraints
A relationship usually has certain constraints that limits the
possible combinations of entities that may participate in
relationship instance. There are two types of relationship
constraints.
• Cardinality ratio
• Participation
 Cardinality Ratio
The cardinality ratio specifies the number of relationship instances
that an entity can participate.

Common cardinality ratios for binary relationship types are:

• One-to-one (1:1)
• One-to-many (1:m)
• Many-to-many (m:n)
One-to-one (1:1)
An entity in A is associated with at most one entity in B, and an
entity in B is associated with at most one entity in A.

Eg. A department entity to the employee who manages that

department.
 Employee Department

Nimal Accounts

Sunil Admin

Mala HR

Amila Sales

1:1

Relationship: An employee manages a department

One-to-many (1:m)
An entity in A is associated with a number of entities in B. An
entity in B, however can be associated with at most one entity
in A.

Eg. An employee can work in one department but many

employees can work in a department.
Department Employee

E1

HR
E2

Sales E3

E4

E5

1:m
Many-to-many (m:n)
An entity in A is associated with a number of entities in B, and
an entity in B can be associated with any number of entities in
A.

Eg. If an employee can work in several projects and several

employees work on a project, then the cardinality ratio is m:n.
Employee Project

E1 P1

E2 P2

P3
E3

P4
E4

m:n
 Normalization

• It is a process of decomposing ‘unsatisfactory’ relations to smaller

relations.

• Normalization helps eliminate redundancy, organizes data efficiently

and reduces potential anomalies during data operations (insertion,
updating and deletion operations)

The main Normal forms are:

• First Normal Form (1 NF)
• Second Normal Form (2 NF)
• Third Normal Form (3 NF)
• Boyce Codd Normal Form (BCNF)
26
 First Normal Form (1NF)

• The first normal form states that domains of attributes must

include only atomic (simple, indivisible) values and the values of
any attribute in a tuple must be a single value.

• Composite attributes such as an attribute address with component

attributes street and city also have non-atomic domains.

• The 1NF also disallows composite attributes that are themselves

multi valued. These are called nested relations because each tuple
can have a relation within a relation.

27
Example 01

Department table

Dno Dname managerEno Dloc

1 HQ 100 Colombo
2 Marketing 200 Colombo
Kandy
3 Reserach 300 Galle
Gampaha
N’eliya
As this relation contains multi valued attributes,
it is not in 1 NF. Therefore, break the table into
two tables.

Dept_1
Dno Dname ManagerEno

Dept_2
Dno Dloc
Example 02

Emp-Project { Eno, Ename, { Pno, hours} }

• This relation is an example of a nested relation. Such relations are

said to be un-normalized. In order to represent the information in
a relational model, normalization must be carried out. This is done
by removing the repeating groups.

30
 After Normalization
Emp_proj
Project Employee_Project
Eno Ename
Pno Hours
100 Nimal 4 100 Eno Ename PNo Hours
100 Nimal 7 40
100 Nimal 2 150 Employee
200 Sunil 2 100
Eno Ename
200 Sunil 1 55

Emp_Proj

Repeating groups of data Eno Pno Hours

 Second Normal Form (2NF)

• Fully Functional Dependency

• ‘B’ is fully functionally dependent on ‘A’, if it is functionally
dependent on ‘A’ and not functionally dependent on any part of ‘A’.

• 2 NF is based on the concept of full functional dependency.

• A relational schema ‘R’ is in 2 NF if every non-key attribute A in ‘R’

is fully functionally dependent on the primary key of ‘R’.
Non key attributes
Example:
Student (Sno, sname, marks)

key attribute 32
Example:

Items (Invno, Itemno, Iname, Invdate, Qty)

Suppose the PK is {Invo, Itemno} and:

• Invno can be used to find Invdate

• Itemno can be used to find Iname

• Invo and Itemno can be used to find Qty.

33
 Items
Invno Itemno Iname Invdate Qty

Since non-key attributes Iname and Invdate are not fully

functionally dependent on the PK, this relation is not in 2 NF.
Therefore we have to break the relation Items into three

relations to satisfy the Second Normal Form:

Table 1 (Invno, Invdate)

Table 2 (Itemno, Iname)

Table 3 (Invno, Itemno, Qty)

Example 2:

Emp_proj
Eno Pno Hours Ename Pname Ploc

Is this relation in 2NF? If not what is the

reason? Break down this to 2NF.
Example 3
Consider the relation Supplier = {Sno, Pno, Sname, City, Status,
Pname, Qty} and the functional dependencies:
{Sno, Pno} -> {Qty}
{Sno} -> {Sname, City}
{Pno} -> {Pname}
{City} ->{Status}

Assume that the primary key of Supplier is {Sno, Pno}.

Decompose R in to 2NF relations.
Supplier
Sno Sname City Status

Supplier_Project

Sno Pno Qty

Project
Pno Pname
 Third Normal Form (3NF)

Transitive Dependency

If X, Y and Z are attributes and if X ->Y and

Y->Z, then Z is transitively dependent on X.

(X ->Z)
Condition A:

A relation is in 3 NF if and only if it is in 2NF and every non key attribute is

non transitively dependent on the primary key.

Condition B:

Suppose in a relation R, a functional dependency X ->A exists, then the

following conditions must be satisfied:

X is a super key of R
OR
A is a prime attribute of R (when X is not a super key)
Super Key

• A super key is a set of one or more attributes (columns), which can uniquely
identify a row in a table. Often we get confused between super key and
candidate key.

• Candidate keys are selected from the set of super keys, the only thing we take
care while selecting candidate key is: It should not have any redundant
attribute. That’s the reason they are also termed as minimal super key.

Let’s take an example to understand this:

NIC Employee_Number Emp_Name
883200837V 226 Gayan
893245679V 227 Kasun
915478956V 228 Waruna

Super keys: The above table has following super keys. All of the following sets of super key are able to
uniquely identify a row of the employee table.

{NIC}
{Employee_Number}
{NIC, Employee_Number}
{NIC, Emp_Name}
{Employee_Number, Emp_Name}
{NIC, Employee_Number, Emp_Name}

Candidate Keys: A candidate key is a minimal super key with no redundant attributes. The following two set
of super keys are chosen from the above sets as there are no redundant attributes in these sets.
{NIC}
{Employee_Number}

Only these two sets are candidate keys as all other sets are having redundant attributes that are not
necessary for unique identification.
Example 1
Consider the relation Supplier = {Sno, Pno, Sname, City, Status,
Pname, Qty} and the functional dependencies:
{Sno, Pno} -> {Qty}
{Sno} -> {Sname, City}
{Pno} -> {Pname}
{City} ->{Status}

Assume that the primary key of Supplier is {Sno, Pno}.

Decompose R in to 3NF relations.
Supplier Supplier_Project
Sno Sname City Sno Pno Qty

Project City

Pno Pname City Status

Example 2:
Consider the relation R = {A, B, C, D, E, F, G,H, I} and the
functional dependencies,
{A, B} -> {E, F, H}
{A} ->{D}
{B} -> {C, G}
{G} -> {I}

Assume that the primary keys of R to be A and B. Decompose R into

2NF , then into 3NF relations.
Example 3:
Consider the relation R = {A, B, C, D, E, F, G,H, I} and the functional dependencies,
{A, B} -> {C}
{A} ->{D,E}
{B} ->{F}
{F}->{G,H}
{D} -> {H, I}
Assume that the primary keys of R to be A and B. Decompose R into 2NF, then into 3NF
relations.
Example 4:

Consider the relation which has attributes that hold schedules of courses and sections at a University.

R = { Courseno, Secno, Dept, Credithours, Clevel, Lectno, Sem, year, Days_hours, Roomno,
No_of_St}. Suppose that the following functional dependencies hold on R:
• {Courseno} -> {Dept, Credithours, Clevel}

• {Courseno, Secno, Sem, year} ->{Days_hours, Roomno,

No_of_St, Lectno}

• {Roomno, Sem, year, Days_hours} -> {Lectno, Courseno,

Secno}

Normalize this relation.