PRESENTATION

By Group AMembers :

KRISHNA GUPTA

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 anomalies•Insertion anomalies•Deletion anomalies

These anomalies are very undesirable in any database so, it can be avoided by the process of normalization.

• 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

Modification 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.

Insertion 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.

Deletion Anomalies:

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,

R1∩R2=A; (ABC)=>(AABC)=>(R1∩R2R1) 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.

Database normalization is the process of making the data, available in database in the most organized way possible. When you’re 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.

1.4. Introduction to Normalization

As an example

let’s imagine we’re 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: STUDENTSName Age Pet Pet Name

Ram 15 Dog 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 Pet Name

Ram 15 Dog 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 AgeRam 15Krishna 21Priyanka 14Bikash 21

Pet Name Type OwnerPuppy Dog Ram

Tara Cat Ram

Hunter Tiger Krishna

susmu Cat Priyanka

Bhusiya Dog Bikash

TABLE: PETS

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 relationEmployee(ename, ssn, Bdate, address, dnumber)Department(dnumber,dname,dmgr-ssn ) employee-department

ename ssn bdate address

dnumber dname Dmgr-ssn

ename ssn bdate address

dnumber dnumber dname Dmgr-

ssn

Test and remedy(normalization) of 3NF TestRelation should not

have a nonkey attribute functionallydetermined by

another nonkey attributes.that is , there should be no transitive dependency of a nonkey attribute on the primary key

NormalizationDecompose and set

up a relation that includes the non-key attributes that functionally determine other non-key attributes

1.4.4. Boyce–Codd Normal Form

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.

Mr Anil Yadav

All the Viewes

And all the Group members

Our Hearties Thanks to