P R E S E N TAT I O N

Members :

By Group
A

EKRAJ KOIRALA
KRISHNA GUPTA
SHIVCHANDRA
KARKI

DATE :
2071/04/2

Relational Database
Design

Contents:
1. Relational Database Design
1.1. Introduction to Anomalies
1.2. Functional dependencies
1.3. Decomposition
1.4. Introduction to Normalization
1.4.1. First Normal Form
1.4.2. Second Normal Form
1.4.3. Third Normal Form
1.4.4. BCNF

1.1. Introduction to
Anomalies:
Anomalies

are the problems that can occur in poorly

planned un-normalised database where all the data is
stored in one table( a flat-file database).
There are generally three types of anomalies:
Modification/Update
Insertion

anomalies

Deletion

anomalies

anomalies

These anomalies are very undesirable in any

database so, it can be avoided by the process of
normalization.

Modification Anomalies:

It is inconsistencies that results from data redundancy

or partial update.

Incorrect data may have to be changed, which could

involve many records to be changed leading to the
possibilities of some changes being made incorrectly.

In other word, anomalies occurred due to modification

in the data of database then, it is modification
anomalies also called update anomalies

Insertion Anomalies:

An insertion anomaly is the inability to

add data to the database due to absence
of other data.

It is the issue that come about when you

are inserting information into the
database for the first time.

To reduce this type of anomalies, we

must enter the correct details so that
they are consistent in values for the
other row.

Missing or incorrectly formatted entries

are two of the most common insertion
errors.

Deletion Anomalies:

A deletion anomalies are the unintended loss of data

due to deletion of other data.

A records of data can legitimately be deleted from a

database and the deletion can result in the deletion
of the only instance of other required data.

These are the least likely to be caught or to stop you

from proceeding because many deletion errors go
unnoticed for extended period of times, they could
be the most costly in terms of recovery.

1.2. Functional Dependencies:

A functional dependency is a constraint between two sets of

attributes from the database. It is denoted by FD or f.d.

A functional dependency, denoted by xy between two sets of

attributes x & y that are subset of relation schema R, specifies
a constraints a constraint on the possible tuples that can form a
relation state r of R. The constraints is that for any two tuples
t1 & t2 in r that have t1[x]=t2[x] they must also have
t1[y]=t2[y].

A f.d. is a property of semantics or meaning of the attributes.

Relation extension that satisfy the f.d. constraints are called

legal relation state or legal extension.

The main use of f.d. is to describe further a relation schema by

specifying constraints on its attributes that must hold at all time.

A f.d. is a property of the relation schema, not of a particular

legal relation or extension i.e., it cannot be inferred
automatically from a given relation extension but must be
defined explicitly by someone who knows the semantics of the
attributes.

Types of Functional Deficiencies:

Trivial functional dependencies

Full functional dependencies

Transitive functional dependencies

Multi-valued functional dependencies.

Trivial functional dependencies:

A trivial f.d. occurs when you describe a f.d. of an attribute on

a collection of attribute that includes the original attributes.
For example:{A,B}B is a trivial f.d., as is
{name,SSN}SSN. This type of f.d. is called trivial because it
can be derived from common sense. It is obvious that if the
value of B is already known the value of B can be uniquely
determined by that knowledge.

Full functional dependencies (FFD) :

A FFD occur when the requirement for a f.d. is already met and the set of
attributes on the left side of the f.d. statement cannot be reduced farther.
For example:{SSN,age}name , is a f.d. but is not a FFD because
age from the left side of the statement can be removed without impacting
the dependency relationships.

Transitive dependencies:

Transitive dependency occur when there is direct relationship that causes a

functional dependency.
For example: AC is a transitive dependency when it is true only
because both AB and BC are true.

Multi-valued dependencies:

Multi-valued dependency occur when the presence of one or more rows in a

table implies the presence of one or more other rows in the same table.
For example: Assume a bike company manufacture many models of
bike, but always makes both red and blue color of each model. If we have a
table that contains the model name, color, and year of each bike the
company manufactures, there is multi-valued dependency in that table. If
there is a roe for a certain model name and year in blue, there must also be
a similar row corresponding to the red version of same bike.

1.3. Decomposition:

Decomposition in database means breaking down of

table in multiple table for going in higher normal form.

In other words, decomposition is the process of breaking

down of universal relation schema into a set of relation
schema that will become the relational database
schema.
for example: If R={A1,A2,.......,An} is a universal
relation schema that includes all the attributes of
database and using f.d, if we decompose this into the
set of relation schema, D{R1,R2,..,Rn} then D is the
decomposition of R.

Property of Decomposition:

Lossless property of decomposition

Dependency preservation property

Lossless property of Decomposition:

This property of decomposition ensures that no spurious tuples

are generated when the PROJECT and NATURAL JOIN operation
is applied to the relations resulting from decomposition.

It is also known as the Non-additive Join property of a

decomposition.

This ensures we can never get the situation where false tuples
are generated, as for any value on the join attributes there will
be a unique tuple in one of the relations.
For example : R=(A,B,C,D,E).we decompose into
R1=(A,B,C), R2(A,D,E). The set of function dependencies is:
ABC, CDE,BD, EA. Then,
R1R2=A;
(ABC)=>(AABC)=>(R1R2R1) is a lossless
decomposition.

Dependency Preservation Property:

This property preserves the dependencies because

each dependency in a set of dependency represents a
constraint on the database.

If one of the dependencies in some individual is not

represented in some individual relation Ri of the
decomposition, we cannot enforce this constraints by
dealing with an individual relation.

If a decomposition is not dependency-preserving,

some dependency is lost.

1.4. Introduction to Normalization

Database normalization is the process of
making the data in a database available in
the most organized way possible. When
youre normalizing a database, there are two
things you need to consider: whether the
information in the database has internal
redundancies,
and
whether
the
dependencies across the different tables in
the database are logically organized. The
term normalization comes from the concept
of normal forms, which describe just how
organized the information is in the database.

As an example
lets imagine were creating a database
of the children in a class, and the pets
they have. When starting to build this
database, the first approach might be
to create a simple table with all of the
information in one place, and one row
for each student.

TABLE: STUDENTS
Name

Age

Pet

Ram

15

Dog

Pet
Name
Puppy

Krishna

21

Tiger

Hunter

Priyanka

14

Cat

Susmu

Bikash

21

Dog

Bhusiya

This works until you realize that Ram might have two pets,
a dog and a cat. How would you represent that in this
table? In order to do that, we need to introduce first
normal form.

Forms :

1.4.1. First Normal Form

To achieve first normal form for a database, you need
to make sure that no table contains multiple columns
that you could use to get the same information. Each
table should be organized into rows, and each row
should have a primary key that distinguishes it as
unique. The primary key is usually a single column, but
sometimes more than one column can be combined to
create a single primary key.
Using the rules of first normal form, there may be
redundant information across multiple rows, but each
row will be unique.

TABLE: STUDENTS
Name

Age

Pet

Ram

15

Dog

Pet
Name
Puppy

Ram

15

Cat

Tara

Krishna

21

Tiger

Hunter

Priyanka

14

Cat

susmu

Bikash

21

Dog

Bhusiya

1.4.2. Second Normal Form

In this first example there are two rows for
Heather, with changes to the second row
to show the fact that there are multiple
pets. While this is searchable, and follows
first normal form, it is an inefficient use of
space. To achieve second normal form, it
would be helpful to split out the pets into
an independent table, and match them up
using the student names as foreign keys.

TABLE: STUDENTS
Name

Age
15
21
14
21

Ram
Krishna
Priyanka
Bikash

TABLE: PETS
Pet Name

Type

Owner

Puppy

Dog

Ram

Tara

Cat

Ram

Hunter

Tiger

Krishna

susmu

Cat

Priyanka

Bhusiya

Dog

Bikash

1.4.3. Third normal form

It is best of relational schema which makes testing of

updates cheaper when our aim is to find a lossless-join ,
dependency-preserving decomposition

There are slightly difference between 3NF and BCNF

,that is BCNF always requires that all non trivial
dependencies be of the shape -> , where is a
superkey.3NF relaxes this constraint slightly by allowing
non-trivial functional dependencies whose left side is not
a super key.

3 Normalization Form
A relational schema R is in 3NF if every
nonprime attribute of R meets both of the
following conditions:
1. it is fully functionally dependent on every
key of R.
2.it is non-transitively dependent on every
key of R.

Example of 3NF(normalization employee-department into

3NF relation)
Employee-department relation
Employee(ename, ssn, Bdate, address, dnumber)
Department(dnumber,dname,dmgr-ssn )
employee-department

ename

ename

ssn

ssn

bdate

bdate

address

address

dnumber

dnumber

dname

dnumber

Dmgr-ssn

dname

Dmgr-ssn

Test and
remedy(normalization) of 3NF
Test
Normalization
Relation should not have Decompose and set up a
a nonkey attribute
relation that includes
functionallydetermine
the non-key attributes
d by
that functionally
determine other nonanother nonkey
key attributes
attributes.that is ,
there should be no
transitive dependency
of a nonkey attribute
on the primary key

1.4.4. Boyce-Codd Normal Form (BCNF)

Boyce-Codd normal form (BCNF)
A relation is in BCNF, if and only if, every determinant is a
candidate key.
The difference between 3NF and BCNF
It is that for a functional dependency A B, 3NF
allows this dependency in a relation
if B is a primary-key attribute and A is not a candidate
key,
whereas BCNF insists that for this dependency to
remain in a
relation, A must be a candidate key.

Some of the features :-

It is a stronger form of 3NF.that is every

relation in BCNF is also in 3NF;however ,a
relation in 3NF is not necessarily in BCNF.

A relation schema R is in BCNF if

whenever a non-trivial functional
dependency X->A holds in R,then X is a
super key of R.

Our Hearties Thanks to

M r A n i l Ya d a v
A l l t h e Vi e w e s
A n d a l l t h e G r o u p m e m b e r s