Functional dependencies and normalization for relational databases.pptx

1. DATABASE MANAGAMENT SYSTEM
Dr. Gopinath D
Assistant Professor
Department of Computer Science
Kristu Jayanti College
Bengaluru
NORMALIZATION AND RELATIONAL DATA MODEL
Functional dependencies and normalization for relational
databases

2. No. DBMS RDBMS
1) DBMS applications store data as file. RDBMS applications store data in a tabular form.
2) In DBMS, data is generally stored in either a
hierarchical form or a navigational form.
In RDBMS, the tables have an identifier called
primary key and the data values are stored in the form
of tables.
3) Normalization is not present in DBMS. Normalization is present in RDBMS.
4) DBMS does not apply any security with
regards to data manipulation.
RDBMS defines the integrity constraint for the
purpose of ACID (Atomocity, Consistency, Isolation
and Durability) property.
5) DBMS uses file system to store data, so there
will be no relation between the tables.
in RDBMS, data values are stored in the form of
tables, so a relationship between these data values
will be stored in the form of a table as well.
6) DBMS has to provide some uniform methods to
access the stored information.
RDBMS system supports a tabular structure of the
data and a relationship between them to access the
stored information.
7) DBMS does not support distributed
database.
RDBMS supports distributed database.
8) DBMS is meant to be for small organization
and deal with small data. it supports single
user.
RDBMS is designed to handle large amount of
data. it supports multiple users.
9) Examples of DBMS are file systems, xml etc. Example of RDBMS are mysql, postgre, sql
server, oracle etc.

3. Database design
• Database design
• Bottom up - breaking down a big problem into smaller
• Top down - solving the smaller problems at the fundamental level and then
integrating them into a whole and complete solution.
Grouping of attributes to form
relational schema

4. Design guideline for Evaluating relation DB
schemas
Chp
5
4
• Schema – design a structure for database
• Two levels of relation schemas
• The logical or conceptual view
• How users interpret the relation schemas and
the meaning of their attributes.
• Implementation or storage view or physical
view
• How the tuples in the base relation are stored
and updated.

5. Pitfalls in relational database
design
Chp
5
5
1. Poor semantics of the attributes
2. Redundant values in tuples
3. Null values in tuples
4. Possibility of generating spurious
tuples.

6. 1.Semantics of the Relation Attributes
Semantic data is data that has been structured to add meaning to the data.)
• GUIDELINE 1: Informally, each tuple in a relation should
represent one entity or relationship instance. (Applies to
individual relations and their attributes).
• Attributes of different entities (EMPLOYEEs,
DEPARTMENTs, PROJECTs) should not be mixed in
the same relation
• Only foreign keys should be used to refer to other entities
• Entity and relationship attributes should be kept apart as
much as possible.
• Bottom Line: Design a schema that can be explained easily
relation by relation. The semantics of attributes should be easy
to interpret. 7

7. A Simplified COMPANY relational database schema
Chp
5
7

8. 2.Redundant Information in Tuples and Update Anomalies(inconsistency in
the pattern from the normal form)
Chp
5
8
• Goal of schema design is to minimize the storage space used by the
base relations.
• Information is stored redundantly
• Wastes storage
• Causes problems with update anomalies
• Insertion anomalies
• Deletion anomalies
• Modification anomalies

10. Two relation schemas suffering from update anomalies
Chp
5
1
0
ENAM
E
SSN BDATE ADDRE
SS
DNUMB
ER
DNAM
E
DMGRS
SN
SSN PNUMB
ER
HOUR
S
ENAM
E
PNAM
E
PLOCA
TI
O
N
EMP_DEPT
EMP_PROJ

11. Chp
5
1
1

12. EXAMPLE OF AN INSERT ANOMALY
Chp
5
1
2
• Consider the relation:
• EMP_PROJ(Emp#, Proj#, Ename, Pname,
No_hours)
• Insert Anomaly:
• Cannot insert a project unless an employee is
assigned to it.
• Conversely
• Cannot insert an employee unless an he/she is
assigned to a project.

13. EXAMPLE OF AN DELETE ANOMALY
Chp
5
1
3
• Consider the relation:
• EMP_PROJ(Emp#, Proj#, Ename, Pname, No_hours)
• Delete Anomaly:
• When a project is deleted, it will result in deleting all the
employees who work on that project.
• Alternately, if an employee is the sole employee on a
project, deleting that employee would result in
deleting the corresponding project.

14. EXAMPLE OF AN UPDATE ANOMALY
Chp
5
1
4
• Consider the relation:
• EMP_PROJ(Emp#, Proj#, Ename, Pname,
No_hours)
• Update Anomaly:
• Changing the name of project number P1
from “Billing” to “Customer-Accounting”
may cause this update to be made for all 100
employees working on project P1.

15. Guideline to Redundant InformationinTuples and
UpdateAnomalies
Chp
5
1
5
• GUIDELINE 2:
• Design a schema that does not suffer from the insertion,
deletion and update anomalies.
• If there are any anomalies present, then note
them so that applications can be made to take
them into account.
• In general, it is advisable to use anomaly free base
relations and to specify views that include the joins for
placing together the attributes frequently referenced in
important queries.

16. Problems with Nulls
Chp
5
1
6
• If many attributes are grouped together as a
fat relation, it gives rise to many nulls in the
tuples.
• Waste storage
• Problems in understanding the meaning of
the attributes
• Difficult while using Nulls in aggregate
operators like count or sum

17. 3. Null Values in Tuples
Chp
5
1
7
• Interpretations of nulls:
a. The attribute does not apply to this tuple.
b. The attribute value for this tuple is not known.
c. The value is known but has not been recorded yet.

18. • GUIDELINE 3:
• void placing attributes in a base relation whose values may
frequently be null.
• Relations should be designed such that their tuples will
have as few NULL values as possible
• Attributes that are NULL frequently could be placed in
separate relations (with the primary key)
• Example:-
• if only 10% of employees have individual offices, it is
better not to include office_number as an attribute in the
employee relation.
• Better create a new relation emp_offices(essn,
office_number)
Chp
5
1
8

19. Example of Fake Tuples
Chp
5
1
9

20. Generation of spurious tuples
Chp
5
2
0
• The two relations EMP_PROJ1 and EMP_LOCS as the
base relations of EMP_PROJ, is not a good schema
design.
• Problem is if a Natural Join is performed on the above two
relations it produces more tuples than original set of tuples in
EMP_PROJ.
• These additional tuples that were not in EMP_PROJ are called
spurious tuples because they represent spurious or wrong
information that is not valid.
• This is because the PLOCATION attribute which is used for
joining is neither a primary key, nor a foreign key in either
EMP_LOCS AND EMP_PROJ1.

21. Example of Spurious Tuples
contd
Chp
5
2
1

22. 4. Spurious Tuples
Chp
5
2
2
• Bad designs for a relational database may result in
erroneous results for certain JOIN operations
• The "lossless join" property is used to guarantee
meaningful results for join operations
• GUIDELINE 4:
• Design relation schemas so that they can be joined
with equality conditions on attributes that are either
primary keys or foreign keys in a way that guarantees
that no spurious tuples are generated.
• Non-additive or losslessness of the corresponding
join
• Preservation of the functionaldependencies.

23. Summary and Discussion of Design
Guidelines
2
3
Problems pointed out:
• Anomalies cause redundant work to be done during
• Insertion
• Modification
• Deletion
• Waste of storage space due to nulls and difficulty of
performing aggregation operations and joins due to null
values
• Generation of invalid and spurious data during joins on
improperly related base relations.

24. Functional dependencies - normalization
• A functional dependency is a constraint between two sets of
attributes from the database.
• Normalization is the process of organizing the data in the
database.
Normalization:
• Normalization is used to minimize the redundancy from a relation
or set of relations. It is also used to eliminate the undesirable
characteristics like Insertion, Update and Deletion Anomalies.
• Normalization divides the larger table into the smaller table and
links them using relationship.
• The normal form is used to reduce redundancy from the
database table

25. TYPES:
Boyce-codd NF

26. NF
• 1NF – Not allowed multivalued attribute
• 2NF – No partial dependency
• 3nf – no transitive dependency
• BCNF – Remove non trivial functional dependency
• Multivalued – more than one value for single attribute value
• Dependency – one attribute depend on other
• Partial – one attribute partially depend on other attribute
• Transitive – x->y and y->z = x->z [ no intermediate]
• Trivial -

34. 1NF
• A relation is in first normal form if every attribute in that relation
is single valued attribute.
• Not allowed multi value attributed
• Example 1:

35. • Example 2:
• I NF
ID Name Courses
1 A C1,C2
2 E C3
3 M C2,C3
ID Name Courses
1 A C1
1 A C2
2 E C3
3 M C2
3 M C3

36. 2nf
• No partial dependency
• A relation must be in first normal form and relation must not contain
any partial dependency.
• Partial Dependency – If the proper subset of candidate key
determines non-prime attribute, it is called partial dependency.
2NF
Stud_no Course_no Courses_Fee
1 C1 1000
2 C2 1500
1 C4 2000
4 C3 1000
4 C1 1000
2 C5 2000
 COURSE_FEE cannot alone decide the value of
COURSE_NO or STUD_NO;
 COURSE_FEE together with STUD_NO cannot
decide the value of COURSE_NO;
 COURSE_FEE together with COURSE_NO cannot
decide the value of STUD_NO;
COURSE_FEE would be a non-prime attribute, as it
does not belong to the one only candidate key
{STUD_NO, COURSE_NO} ;
To convert the above relation to 2NF,
we need to split the table into two tables such as :
Table 1: STUD_NO, COURSE_NO
Table 2: COURSE_NO, COURSE_FEE
Stud_no Course_no
1 C1
2 C2
1 C4
4 C3
4 C1
2 C5
Course_no Courses_Fee
C1 1000
C2 1500
C4 2000
C3 1000
C1 1000
C5 2000
 NOTE: 2NF tries to reduce the redundant data getting stored in memory. For instance, if there are 100
students taking C1 course, we don’t need to store its Fee as 1000 for all the 100 records, instead once we
can store it in the second table as the course fee for C1 is 1000.

37. 3nf
• no transitive dependency
• A relation will be in 3NF if it is in 2NF and not contain any transitive
partial dependency.
• 3NF is used to reduce the data duplication. It is also used to achieve
the data integrity.
• If there is no transitive dependency for non-prime attributes, then
the relation must be in third normal form.
• A relation is in third normal form if it holds atleast one of the
following conditions for every non-trivial function dependency X → Y.
• X is a super key.
• Y is a prime attribute, i.e., each element of Y is part of some candidate key.

38. 3nf
• Transitive dependency – If A->B and B->C are two FDs then A->C is called transitive dependency. No intermediate.
STUDENT
•
Example 1 – In relation STUDENT given in Table,
FD set: {STUD_NO -> STUD_NAME, STUD_NO -> STUD_STATE,
STUD_STATE -> STUD_COUNTRY, STUD_NO -> STUD_AGE}
Candidate Key: {STUD_NO}
 For this relation in table , STUD_NO -> STUD_STATE and
STUD_STATE -> STUD_COUNTRY are true. So STUD_COUNTRY
is transitively dependent on STUD_NO. It violates the third
normal form. To convert it in third normal form, we will
decompose the relation STUDENT (STUD_NO, STUD_NAME,
STUD_STATE, STUD_COUNTRY_STUD_AGE) as:
STUDENT (STUD_NO, STUD_NAME, STUD_STATE, STUD_AGE)
STATE_COUNTRY (STATE, COUNTRY)

STUD_NO STUD_NAME STUD_AGE STUD_STATE
1 RAM 20 HARYANA
2 RAM 19 PUNJAB
3 SURESH 21 PUNJAB
STUD_STATE STUD_COUNR
Y
HARYANA INDIA
PUNJAB INDIA
PUNJAB INDIA

39. BCNF
• BCNF is the advance version of 3NF. It is stricter than 3NF.
• A table is in BCNF if every functional dependency X → Y, X is the
super key of the table.
• For BCNF, the table should be in 3NF, and for every FD, LHS is
super key.
• Example: Let's assume there is a company where employees
work in more than one department.

41. • EMPLOYEE table:
In the above table Functional dependencies are as follows:
• EMP_ID → EMP_COUNTRY
• EMP_DEPT → {DEPT_TYPE, EMP_DEPT_NO}
Candidate key: {EMP-ID, EMP-DEPT}
The table is not in BCNF because neither EMP_DEPT nor EMP_ID alone are keys.
MP_ID EMP_COUNTRY EMP_DEPT DEPT_TYPE EMP_DEPT_NO
264 India Designing D394 283
264 India Testing D394 300
364 UK Stores D283 232
364 UK Developing D283 549

42. BCNF
• Remove the non trivial functional dependency.
• Make a separate table for the determinants.
• To convert the given table into BCNF, we decompose it
into three tables:
• EMP_COUNTRY table:
• EMP_DEPT table:
• EMP_DEPT_MAPPING table:
• Functional dependencies:
EMP_ID → EMP_COUNTRY
EMP_DEPT → {DEPT_TYPE, EMP_DEPT_NO}
Candidate keys:
• For the first table: EMP_ID
For the second table: EMP_DEPT
For the third table: {EMP_ID, EMP_DEPT}
• this is in BCNF because left side part of both the functional dependencies is a key.
EMP_ID EMP_COUNTRY
264 India
264 India
EMP_DEPT DEPT_TYPE EMP_DEPT_NO
Designing D394 283
Testing D394 300
Stores D283 232
Developing D283 549
EMP_ID EMP_DEPT
D394 283
D394 300
D283 232
D283 549

44. Example -1 nf