Scribd
Upload
297 views

Functional Dependency

A functional dependency (FD) exists between two sets of attributes in a relation where values of one set (the determinant set) determine the values of the other set (the dependent attribute). A partial FD exists when some but not all attributes of the determinant set are needed to determine the dependent attribute. A fully functional dependency exists when all attributes of the determinant set are needed to determine the dependent attribute. A transitive dependency is an indirect FD that exists due to other direct FDs.

Uploaded by

Sagar Chingali
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
297 views

Functional Dependency

A functional dependency (FD) exists between two sets of attributes in a relation where values of one set (the determinant set) determine the values of the other set (the dependent attribute). A partial FD exists when some but not all attributes of the determinant set are needed to determine the dependent attribute. A fully functional dependency exists when all attributes of the determinant set are needed to determine the dependent attribute. A transitive dependency is an indirect FD that exists due to other direct FDs.

Uploaded by

Sagar Chingali
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

Functional dependency

A functional dependency (FD) is a constraint between two sets of attributes in a relation from a database. Given a relation R, a set of attributes X in R is said to functionally determine another attribute Y, also in R, (written X Y) if and only if each X value is associated with precisely one Y value. Customarily we call X the determinant set and Y the dependent attribute. Thus, given a tuple and the values of the attributes in X, one can determine the corresponding value of the Y attribute.

Partial functional dependency


Partial Functional Dependency Indicates that if A and B are attributes of a table , B is partially dependent on A if there is some attribute that can be removed from A and yet the dependency still holds. Say for Ex, consider the following functional dependency that exists in the Tbl_Staff table: StaffID,Name -------> BranchID BranchID is functionally dependent on a subset of A (StaffID,Name), namely StaffID. {Employee Address} has a functional dependency on {Employee ID, Skill}, but not a full functional dependency, because it is also dependent on {Employee ID}.

Fully functional dependency


In a relation R , attribute B of R is fully functionally dependent on an attribute or set of attributes A of R , if B is functionally dependent on A, but not functionally dependent on any proper subset of A.

trivial functional dependency


A trivial functional dependency is a functional dependency of an attribute on a superset of itself. {Employee ID, Employee Address} {Employee Address} is trivial, as is {Employee Address} {Employee Address}.

Transitive dependency
A transitive dependency is an indirect functional dependency, one in which XZ only by virtue of XY and YZ.

Powered By www.technoscriptz.com

Diff b/t bcnf and 3nf :

A 3NF table which does not have multiple overlapping candidate keys is guaranteed to be in BCNF.[4] Depending on what its functional dependencies are, a 3NF table with two or more overlapping candidate keys may or may not be in BCNF

Boyce-codd normal form(BCNF) was proposed as a simpler form of 3NF,but it was found to be stricter than 3NF,because every relation in BCNF is also in 3NF. However a relation in 3NF is not necessarily in BCNF.

Join dependency
A join dependency is a constraint on the set of legal relations over a database scheme. A table T is subject to a join dependency if T can always be recreated by joining multiple tables each having a subset of the attributes of T. If one of the tables in the join has all the attributes of the table T, the join dependency is called trivial. The join dependency plays an important role in the Fifth normal form, also known as project-join normal form, because it can be proven that if you decompose a scheme R in tables R1 to Rn, the decomposition will be a lossless-join decomposition if you restrict the legal relations on R to a join dependency on R called * (R1,R2,...Rn).

Example
Given a pizza-chain that models purchases in table Customer = { order-number, customer-name, pizza-name, delivery-boy }. It is obvious that you can derive the following relations:
customer-name depends on order-number pizza-name depends on order-number delivery-boy depends on order-number

Powered By www.technoscriptz.com

You might also like