The document provides an overview of relational database design, focusing on anomalies, functional dependencies, and normalization processes. It discusses various types of anomalies such as modification, insertion, and deletion, and introduces normalization stages including first, second, and third normal forms, as well as Boyce-Codd Normal Form (BCNF). It emphasizes the importance of organizing data to minimize redundancy and dependency issues in databases.

1. PRESENTATION
Members :
KRISHNA GUPTA

2. DATE :2071/04/2
Relational Database Design

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

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

5. • 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:

6.  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:

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

8. 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 xy 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.

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

10. 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: “AC” is a transitive dependency when it is true only because
both “AB’’ and “BC’’ 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.

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

12. 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: ABC, CDE,BD, EA.
Then,
R1∩R2=A; (ABC)=>(AABC)=>(R1∩R2R1) is a lossless
decomposition.

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

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

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

16. TABLE: STUDENTS
Name 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.

17. Forms :

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

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

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

21. TABLE: STUDENTS
Name Age
Ram 15
Krishna 21
Priyanka 14
Bikash 21
Pet Name Type Owner
Puppy Dog Ram
Tara Cat Ram
Hunter Tiger Krishna
susmu Cat Priyanka
Bhusiya Dog Bikash
TABLE: PETS

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

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

24. 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 ssn bdate address dnumber dname Dmgr-ssn
ename ssn bdate address dnumber dnumber dname Dmgr-ssn

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

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

27.  Mr Anil Yadav
 All the Viewes
 And all the Group members