DBMS 5 FDB Functional Dependency
DBMS 5 FDB Functional Dependency
Sultan Jenbo
email: sultanmettu@gmail.com
Functional Dependency
Data Dependency
Two data items A and B are said to be in a determinant or dependent
relationship if certain values of data item B always appears with
certain values of data item A.
The essence of this idea is that if the existence of something, call it A,
implies that B must exist and have a certain value, then we say that
“B is functionally dependent on A.“
Functional dependency(FD): is a set of constraints between two
attributes in a relation. Functional dependency says that if two tuples
have same values for attributes A1, A2,..., An, then those two tuples must
have to have same values for attributes B1, B2, ..., Bn.
In general, a functional dependency is a relationship among attributes. In
relational databases, we can have a determinant that governs one other
attribute or several other attributes.
Functional dependency is represented by an arrow sign → that is, X→Y,
where X functionally determines Y. The left-hand side attributes
determine the values of attributes on the right-hand side.
X Y holds if two tuples have the same value for X, they must have the
same value for Y .
AB is read as; B is functionally dependent on A
We also often express this idea by saying that
"A determines B," or that
"B is a function of A," or that
"A functionally governs B.“
Example
Partial Dependency
If an attribute which is not a member of the primary key is dependent on some
part of the primary key (if we have composite primary key) then that attribute
is partially functionally dependent on the primary key.
Let {A, B} is the Primary Key and C is no key attribute.
If
There are no duplicated rows in the table. Unique identifier
Each cell is single-valued (i.e., there are no repeating groups).
Entries in a column (attribute, field) are of the same kind.
Example for First Normal form (1NF )
Not normalized
IN FIRST NORMAL FORM (1NF)
Remove all repeating groups.
Distribute the multi-valued attributes into different rows and
identify a unique identifier for the relation so that is can be said is
a relation in relational database.
Second Normal form 2NF
No partial dependency of a non-key attribute on part of the primary key.
A relation schema R is in 2NF if every nonprime attribute A in R is fully
functionally dependent on the primary key of R.
This will result in a set of relations with a level of Second Normal Form.
Any table that is in 1NF and has a single-attribute (i.e., a non-composite)
primary key is automatically in 2NF.
Definition: a table (relation) is in 2NF
If
It is in 1NF and
If all non-key attributes are dependent on the entire primary key.
i.e. no partial dependency.
Example for 2NF:
This schema is in its 1NF since we don’t have any repeating groups or
attributes with multi-valued property.
To convert it to a 2NF we need to remove all partial dependencies of non
key attributes on part of the primary key.
{EmpID, ProjNo}EmpName, ProjName, ProjLoc, ProjFund,
ProjMangID, Incentive
But in addition to this we have the following dependencies
FD1: {EmpID}EmpName
FD2: {ProjNo}ProjName, ProjLoc, ProjFund, ProjMangID
FD3: {EmpID, ProjNo}Incentive
Third Normal Form (3NF)
Eliminate columns dependent on another non-Primary Key.
If attributes do not contribute to a description of the key, remove
them to a separate table.
This level avoids update and delete anomalies.
Definition: a Table (Relation) is in 3NF
If
It is in 2NF and
There are no transitive dependencies between a primary key and non-
primary key attributes.
Example for (3NF)
Assumption: Students of same batch live in one building or dormitory
This schema is in its 2NF since the primary key is a single attribute.
Let’s take StudID, Year and Dormitary and see the dependencies.
StudIDYear AND YearDormitary
And Year cannot determine StudID and Dormitary can not determine StudID
Then transitively StudIDDormitary
To convert it to a 3NF we need to remove all transitive dependencies of non key
attributes on another non-key attribute.
The non-primary key attributes, dependent on each other will be moved to another
table and linked with the main table using Candidate Key-Foreign Key
relationship.
Generally, even though there are other four additional levels of
normalization, a table is said to be normalized if it reaches 3NF.
The fields depend upon the key: the table should solely depend on the key.
The whole key: no partial key dependency.
…………………..