0% found this document useful (0 votes)
9 views

Module 3.1 DBMS PDF

Uploaded by

Nitya
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
9 views

Module 3.1 DBMS PDF

Uploaded by

Nitya
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 13

DATABASE MANAGEMENT SYSTEM

MCA 104
Module–5
Func onal Dependencies
In the field of database management systems (DBMS), func onal
dependencies are a fundamental concept used to describe the
rela onships between a ributes (or columns) in a database table. They
play a crucial role in database design, normaliza on, and ensuring data
integrity.

Func onal dependencies are rules that specify how the values of certain
a ributes determine the values of other a ributes in the same table. In
other words, given a set of a ributes in a table, a func onal dependency
states that the value of one or more a ributes uniquely determines the
value of another a ribute. This rela onship helps us understand the
dependencies and constraints within the data, allowing for the crea on
of well-structured and organized databases.
A func onal dependency is denoted by an arrow (->) and can be
represented as follows:
A -> B

Here, "A" is the determinant or set of a ributes, and "B" is the


determined a ribute. The func onal dependency "A -> B" means that for
every value of "A," there is only one corresponding value of "B."

In the process of database normaliza on, the understanding and


iden fica on of func onal dependencies are essen al. Normaliza on
involves organizing the database tables in such a way that data
redundancy is minimized, and data integrity is maximized. By analysing
and elimina ng func onal dependencies, we can achieve a more efficient
and well-structured database design, reducing the risk of data anomalies
and inconsistencies.

Armstrong’s axioms/proper es of func onal dependencies:

Armstrong's axioms, also known as Armstrong's proper es, are a set of


inference rules used to derive addi onal func onal dependencies from a
given set of func onal dependencies in a rela onal database. These
axioms were formulated by William W. Armstrong and are fundamental
in the process of database normaliza on and reasoning about func onal
dependencies. There are three axioms, and they are as follows:

 Reflexivity (Augmenta on):

If "B" is a subset of "A," then "A" -> "B." In other words, if a func onal
dependency holds for a set of a ributes, it also holds for any of its
subsets.
Example: If we have a func onal dependency "EmployeeID, Department"
-> "EmployeeID," then we can deduce "EmployeeID" -> "EmployeeID" by
applying the reflexivity axiom.

 Augmenta on (Addi on):

If "A" -> "B," then "A, C" -> "B, C." This axiom allows us to add the same
a ributes to both sides of an exis ng func onal dependency.

Example: If we have a func onal dependency "StudentID" -> "Name,"


then we can infer "StudentID, Age" -> "Name, Age" by applying the
augmenta on axiom.

 Transi vity (Composi on):

If "A" -> "B" and "B" -> "C," then "A" -> "C." This axiom allows us to
combine two func onal dependencies to deduce a new func onal
dependency.

Example: If we have func onal dependencies "CourseID" ->


"CourseName" and "CourseName" -> "Department," then we can
conclude "CourseID" -> "Department" by applying the transi vity axiom.

These three axioms form the basis of inference rules used in Armstrong's
closure algorithm, which is used to compute the closure of a set of
a ributes with respect to a given set of func onal dependencies. The
closure of an a ribute set is the set of all a ributes that are func onally
determined by the given a ribute set.

By repeatedly applying these axioms and closure proper es, we can


iden fy all the implied func onal dependencies from a given set of
func onal dependencies. This process is crucial in the design and
normaliza on of rela onal databases to ensure that the database
schema is free of data anomalies, redundancy, and inconsistencies.

Types of func onal dependencies:

In a rela onal database management system (DBMS), there are several


types of func onal dependencies that describe the rela onships
between a ributes (columns) in a table. Understanding these types is
essen al for proper database design and normaliza on. Let's explore
each type of func onal dependency in detail:

1. Unary Func onal Dependency (Trivial Dependency):

A unary func onal dependency occurs when an a ribute is func onally


dependent on itself. It is considered trivial because it doesn't provide any
new informa on about the rela onships between a ributes. The unary
func onal dependency is represented as "A -> A," where "A" is the
a ribute in ques on.

Example: In a table of employees, where "EmployeeID" is the primary


key, the func onal dependency "EmployeeID -> EmployeeID" is a trivial
unary func onal dependency.

2. Mul valued Dependency:

A mul valued dependency occurs when a table contains mul ple


independent sets of data, and changing the value of one a ribute doesn't
affect the values of other a ributes.

The mul valued dependency is represented as "A ->> B," where "A" is
the determinant or set of a ributes, and "B" is another set of a ributes.
Example: In a table of students and their courses, where "StudentID" is
the primary key and "CourseName" is an a ribute, the func onal
dependency "StudentID ->> CourseName" states that for each
"StudentID," there can be mul ple values of "CourseName."

3. Transi ve Dependency:

A transi ve dependency is a type of func onal dependency in which the


value of one a ribute is uniquely determined by the value of another
a ribute with the help of a third a ribute.

The transi ve dependency is represented as "A -> B" and "B -> C,"
implying "A -> C."

Example: In a table of orders, where "OrderID" is the primary key, and


"ProductID" and "ProductName" are a ributes, the func onal
dependencies "OrderID -> ProductID" and "ProductID -> ProductName"
together imply the transi ve dependency "OrderID -> ProductName."

4. Par al Dependency:

A par al dependency occurs when an a ribute is func onally dependent


on only part of a composite key (a combina on of a ributes that
uniquely iden fies a record in a table).

This type of dependency violates the principles of normaliza on,


par cularly the third normal form (3NF).

Example: In a table of employees, where "EmployeeID" and


"DepartmentID" together form the composite key, if "EmployeeID" is
func onally dependent on "DepartmentID" but not on the en re
composite key "EmployeeID, DepartmentID," it creates a par al
dependency.
5. Non-Trivial Func onal Dependency:

A non-trivial func onal dependency is a type of func onal dependency


where the determined a ribute (the right-hand side of the arrow) is not
a subset of the determinant (the le -hand side of the arrow).

In other words, a func onal dependency "A -> B" is non-trivial if "B" is
not included in the set of a ributes represented by "A."

Example: In a table of employees, where "EmployeeID" is the primary


key, the func onal dependency "EmployeeID -> EmployeeName" is non-
trivial because "EmployeeName" is not a subset of "EmployeeID."

6. Full Func onal Dependency:

A fully func onal dependency is a specific type of non-trivial func onal


dependency where removing any a ribute from the determinant would
result in the dependency becoming trivial.

In other words, a func onal dependency "A -> B" is a fully func onal
dependency if, for every a ribute "X" in "A," the dependency "A - {X} ->
B" becomes trivial (B is a subset of A - {X}).

Example 1: In a table of courses, where "CourseID" is the primary key and


"CourseName" is an a ribute, the func onal dependency "CourseID ->
CourseName" is a fully func onal dependency because "CourseName" is
fully dependent on "CourseID," and removing any a ribute from
"CourseID" would make the dependency trivial.

Advantages of func onal dependencies in DBMS:

Func onal dependencies play a cri cal role in the field of database
management systems (DBMS) and offer several advantages that
contribute to the effec veness, integrity, and efficiency of database
design and opera ons.

Here are some key advantages of func onal dependencies in DBMS:

 Data Integrity: Func onal dependencies help ensure data integrity


by defining and enforcing rules for the rela onships between
a ributes in a table. This helps prevent inconsistencies and data
anomalies, such as duplicate data or conflic ng informa on.

 Normaliza on: Func onal dependencies are essen al in the


process of database normaliza on. Normaliza on reduces data
redundancy and ensures that each piece of data is stored in the
most appropriate and non-repe ve manner. This results in a well-
organized and maintainable database structure.

 Efficient Query Op miza on: By understanding the func onal


dependencies, DBMS op mizers can improve query execu on
plans. Query planners can take advantage of these dependencies to
choose the most efficient query execu on strategy, resul ng in
faster and more accurate data retrieval.

 Consistency and Accuracy: By enforcing func onal dependencies,


DBMS ensures that the data remains consistent and accurate
throughout the database. Any modifica on to the data that violates
these dependencies would be automa cally rejected, maintaining
data integrity.

 Database Op miza on: Understanding func onal dependencies


enables database designers to make informed decisions about
index crea on, primary key selec on, and table rela onships. This
contributes to overall database performance and op miza on.
 Ease of Maintenance: With func onal dependencies explicitly
defined, future changes to the database schema become more
manageable. Developers can make modifica ons with confidence,
knowing that the established rela onships will remain consistent.

Mul -valued Dependencies


A mul valued dependency (MVD) is a type of func onal dependency in
the field of database management systems (DBMS) that describes a
rela onship between two sets of a ributes in a table. Unlike a regular
func onal dependency, where one a ribute uniquely determines
another a ribute, a mul valued dependency specifies that one set of
a ributes uniquely determines another set of a ributes, without any
considera on of the order or posi on of the a ributes within the sets.

Formally, a mul valued dependency is denoted as "A ->> B," where "A"
and "B" are two sets of a ributes in the same table. The dependency
means that for every combina on of values in "A," there can be mul ple
combina ons of values in "B," and vice versa. It indicates that the sets
"A" and "B" are independent and can exist in various combina ons.

To understand mul valued dependencies, consider a table with


a ributes "A," "B," and "C." A mul valued dependency "A ->> B" means
that for each value of "A," there can be mul ple values of "B" associated
with it. However, "B" and "C" can be independently related without any
restric ons. This implies that "A" determines "B," but "B" and "C" are not
dependent on each other.

Example - Music Database:

Consider a table called "Ar sts" in a music database that stores


informa on about music ar sts and the genres they perform.
The table has the following a ributes:

 Ar stID (Primary Key)

 Ar stName

 Genres (a mul valued a ribute containing a list of genres the ar st


performs)

Let's assume that ar sts can perform mul ple genres, and the "Genres"
a ribute is a composite or nested a ribute that can hold a list of genres
for each ar st. For example:

Table – Mul valued Dependencies

Ar stID Ar stName Genres

1 John Smith Rock, Pop, Country

2 Jane Doe Jazz, Blues

3 Mike Johnson Pop, Hip-hop

In this example, the "Genres" a ribute is mul valued, represen ng a set


of values (genres) for each ar st. The mul valued dependency "Ar stID
->> Genres" means that for each ar st, there can be mul ple values in
the "Genres" set. In other words, the set of genres associated with each
ar st is independent of other ar sts' sets of genres.

Now, let's consider another a ribute called "Awards," which represents


the awards won by ar sts. Suppose that ar sts can win mul ple awards,
and the "Awards" a ribute is also a composite or nested a ribute,
capable of holding a list of awards for each ar st. For example:
Ar stID Ar stName Genres

1 John Smith Rock, Pop,


Country

2 Jane Doe Jazz, Blues

3 Mike Johnson Pop, Hip-hop

In this case, we have another mul valued dependency "Ar stID ->>
Awards." Each ar st can win mul ple awards, and the set of awards
associated with each ar st is independent of other ar sts' sets of awards.

Mul valued dependencies are relevant when dealing with databases


that store data in a non-atomic form, such as nested or composite
a ributes. Iden fying and handling mul valued dependencies is crucial
for database normaliza on and maintaining data integrity. Proper
normaliza on techniques, such as Boyce-Codd Normal Form (BCNF) and
Fourth Normal Form (4NF), help resolve mul valued dependencies,
ensuring that the database is well-structured and free from data
anomalies.

Decomposi on using mul valued dependencies:

Decomposi on using mul valued dependencies in database


management systems (DBMS) refers to the process of breaking down a
table into mul ple smaller tables to eliminate mul valued a ributes and
resolve data redundancy. The objec ve is to achieve a more efficient and
normalized database structure while ensuring data integrity and
elimina ng anomalies.

Example - Music Database:

Consider a table called "Ar sts" in a music database that stores


informa on about music ar sts, the genres they perform, and the awards
they have won.

The table has the following a ributes:

 Ar stID (Primary Key)

 Ar stName

 Genres (a mul valued a ribute containing a list of genres the ar st


performs)

 Awards (a mul valued a ribute containing a list of awards won by


the ar st)

Here's the ini al "Ar sts" table:

Ar stID Ar stName Genres

1 John Smith Rock, Pop, Country

2 Jane Doe Jazz, Blues

3 Mike Johnson Pop, Hip-hop

The presence of mul valued a ributes "Genres" and "Awards" violates


the principles of normaliza on, par cularly the Third Normal Form (3NF).
To resolve this, we can decompose the table into two separate tables,
elimina ng the mul valued a ributes.
Decomposed Tables:

1. Ar stsGenres Table:

Ar stID Ar stName Genres

1 John Smith Rock

1 John Smith Pop

1 John Smith Country

2 Jane Doe Jazz

2 Jane Doe Blues

3 Mike Johnson Pop

3 Mike Johnson Hip-hop

2. Ar stsAwards Table:

Ar stID Ar stName Awards

1 John Smith Grammy

1 John Smith Billboard Music


Awards

2 Jane Doe Grammy

3 Mike Johnson MTV Music Awards

3 Mike Johnson BET Awards

Now, the original "Ar sts" table has been decomposed into two smaller
tables, "Ar stsGenres" and "Ar stsAwards." Each table contains non-
repea ng data, and the mul valued a ributes have been resolved. The
"Ar stID" and "Ar stName" a ributes serve as the primary key in both
tables, maintaining the rela onship between ar sts, their genres, and
their awards.

You might also like