What do you mean by functional dependency in dams? Functional dependencies are constraints on the set of authorized relations.

2>In a particular relation say R attribute X is a functional dependant on attribute Y if every value in X in the relation has exactly one value of Y in the given relation. 3>The functional dependany is represented by: X->Y 4>Which, implies that Y is functional dependent on X, or we say that X attribute functionally determines the attribute Y. A key is a set of attributes that uniquely identifies an entire tuple, a function dependency allow us to express constraints that uniquely identify the values of certain attribute. What is Functional dependency and normalization for database? A functional dependency occurs between two attributes in a database, A and B, if there exists a relationship such that for each value of A there is only one corresponding value of B (A -> B). This can be extended to a functional dependency where A may be a set of tuples (x, y, z) that correspond to a single value B ([x, y, z] -> B). In simple mathematical terms the functional dependency must pass the vertical line test for proper functions. Normalization of a relational database means that the relations (tables) in the database conform to a set of rules for a certain normal form (First - Sixth Normal Form [1-6NF] and/or Boyce-Codd Normal Form [BCNF]). The higher the normal form of a table the less vulnerable it is to data inconsistency and data anomalies formed during updates, inserts, and deletes. Normalization often reduces data redundancy in a database which reduces data inconsistency and anomaly risks. Normalizing a database requires analysis of the closure of the set of functional dependencies to ensure that the set complies with the rules for the given normal form. If the table does not comply with the rules then the table is split following specific procedures to achieve the desired normal form. Every table in a database has a normal form and to make a statement that a database is in a certain normal form (ex. 3NF) means that every table complies with the rules for 3NF.

What is 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. Source :http://www.mahipalreddy.com/dbdesign/dbqa.htm

What is non trivial functional dependency?

non trivial functional dependency is totally opposite to the trivial functional dependency. --> non trivial dependency means X-->Y that is if Y is not proper subset of X table or relation with X then it said to be non trivial functional dependency.

How many types of functional dependencies in DBMS? In DBMS there is three type of functional dependency 1 FULL FUNCTION DEPENDENCY. 2 PARTIALLY FUNCTION DEPENDENCY. 3 TRACIENT FUNCTION DEPENDENCY. Functional Dependency can be classified as follows:

Full Functional dependency Indicates that if A and B are attributes(columns)of a table, B is fully functionally dependent on A if B is functionally dependent on A ,but not on any proper subset of A. 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. Transitive Functional Dependency: A condition where A , B and C are attributes of a table such that if A is functionally dependent on B and B is functionally dependent on C then C is Transitively dependent on A via B

The normalization theory is based on the fundamental notion of fundamental dependency. First, lets examine the concept of functional dependency. Given a relation R, attribute A is functionally dependent on attribute B if each value of A in R is associated with precisely one value of B. In other words, attribute A is functionally dependent on B if and only if, for each value of B, there is exactly one value of A.. Atrribute B is called the determinant. Consider the following table EMPLOYEE.

Given a particular value of CODE, there is precisely one corresponding value for NAME. For example, for CODE E1, there is exactly one value of NAME, Mac. Hence, NAME is functionally dependent on CODE. Similarly. There is exactly one value of CITY for each value of CODE. Hence, the attribute CITY is functionally dependent on the attribute CODE. The attribute CODE is the determinant. You can also say that CODE determines CITY and NAME.

What is Functional Dependency? what are the different types of Functional Dependencies?
Functional Dependencies are fundamental to the process of Normalization Functional Dependency describes the relationship between attributes(columns) in a table. For example, if A and B are attributes of a table, B is functionally dependent on A, if each value of A is associated with exactly one value of B (so, you can say, 'A functionally determines B').

Functional dependency between A and B

Attribute or group of attributes on the left hand side of the arrow of a functional dependency is refered to as 'determinant' Simple example would be StaffID functionally determines Position in the above tables.

Functional Dependency can be classified as follows:

Full Functional dependency Indicates that if A and B are attributes(columns)of a table, B is fully functionally dependent on A if B is functionally dependent on A ,but not on any proper subset of A. E.g. StaffID---->BranchID 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. Transitive Functional Dependency: A condition where A , B and C are attributes of a table such that if A is functionally dependent on Band B is functionally dependent on C then C is Transitively dependent on A via B. Say for Ex, consider the following functional dependencies that exists in the Tbl_Staff_Branch table: StaffID---->Name,Sex,Position,Sal,BranchID,Br_Address BranchID----->Br_Address So, StaffID attribute functionally determines Br_Address via BranchID attribute.

Tbl_Staff_Branch

Tbl_Staff

Tbl_Branch

What are update Anomalies

The Problems resulting from data redundancy in an un-normalized database table are collectively known as update anomalies. So any database insertion, deletion or modification that leaves the database in an inconsistent state is said to have caused an update anomaly. They are classified as

Insertion anomalies: To insert the details of a new member of staff located at branch B1 into the Tbl_Staff_Branch Table shown above, we must enter the correct details of branch numner B1 so that the branch details are consistent with the values for branch B1 in other rows. To insert the details of a new branch that currently has no members of staff into the Tbl_Staff_Branch table, it is necessory to enter nulls for the staff details which is not allowed as staffID is the primary key. But if you normalize Tbl_Staff_Branch, which is in Second Normal Form (2NF) to Third Normal Dorm (3NF), you end up with Tbl_Staff and Tbl_Branch and you shouldn't have the problems mentioned above. Deletion anomalies: If we delete a row from the Tbl_Staff_Branch table that represents the last member of staff located at that branch, (for e.g. row with Branch numbers B",B3 or B4) the detals about that branch are also lost from the Database. Modification anomalies: Should we need to change the address of a perticular branch in the Tbl_Staff_Branch table, we must update the rows of all staff located at that branch. If this modification is not carried out on all the relevent rows, the database will become inconsistent.

What is Database Normalization?

Database Normalization is a step wise formal process that allows us to decompose Database Tables in such a way that both Data Redundancy and Update Anomalies(see above for more info on update anomalies) are minimised. It makes use of Functional Dependencies that exist in a table (relation, more formally) and the primary key or Candidate Keys in analysing the tables. Three normal forms were initially proposed called First normal Form (1NF), Second normal Form (2NF), and Third normal Form (3NF). Subsequently R.Boyce and E.F.Codd introduced a stronger definition of 3NF called Boyce-Codd Normal Form(BCNF). With the exception of 1NF, all these normal forms are based on Functional dependencies among the attributes of a table. Higher normal forms that go beyond BCNF were introduced later such as Fourth Normal Form (4NF) and Fifth Normal Form (5NF). However these later normal forms deal with situations that are very rare.

First Normal Form (1NF) The only thing that is required for a table to be in 1NF is to contain only atomic values (intersection of each row and column should contain one and only one value).this is sometimes referred to as : Eliminate Repeating groups. Second Normal Form (2NF) A Table is said to be in 2NF if it is in 1NF and there are no partial dependencies i.e. every non primary key attribute of the Table is fully functionally dependent on the primary key. Third Normal Form (3NF) A Table that is in 1NF and 2NF and in which no non primary key attribute is transitively dependent on primary key. Boyce-codd Normal Form (BCNF) A Table is in BCNF if and only if every determinant(it is an attribute or a group of attributes on which some other attribute is fully functionally dependent, see functional dependency described above) is a candidate key. BCNF is a stronger form of 3NF. The difference between 3NF and BCNF is that for a Functional dependency A--->B, 3NF allows this dependency in a table if attribute B is a primary key attribute and attribute A is not a candidate key, where as BCNF insists that for this dependency to remain in a table, attributeA must be a candidate key.

Normalization Process

Fourth Normal Form (4NF) 4NF is a stronger normal form than BCNF as it prevents Tables from containing nontrivial Multi-Valued Dependencies (MVDs) and hence data redendancy. The Normalization of BCNF Tables to 4NF involves the removal of MVDs from the Table by placing the attribute(s) in a new Table along with the copy of the determinant(s). Fifth Normal Form(5NF) 5NF is also called Project-Join Normal Form(PJRF) and specifies that a 5NF Table has no Join dependency.

Database Dependencies/Functional Dependencies A dependency occurs in a database when information stored in the same database table uniquely determines other information stored in the same table. You can also describe this as a relationship where knowing the value of one attribute (or a set of attributes) is enough to tell you the value of another attribute (or set of attributes) in the same table. Saying that there is a dependency between attributes in a table is the same as saying that there is a functional dependency between those attributes. If there is a dependency in a database such that attribute B is dependent upon attribute A, you would write this as A -> B. For example, In a table listing employee characteristics including Social Security Number (SSN) and name, it can be said that name is dependent upon SSN (or SSN -> name) because an employee's name can be uniquely determined from their SSN. However, the reverse statement (name -> SSN) is not true because more than one employee can have the same name but different SSNs.
Trivial Functional Dependencies A trivial functional dependency occurs when you describe a functional dependency of an attribute on a collection of attributes that includes the original attribute. For example, {A, B} -> B is a trivial functional dependency, as is {name, SSN} -> SSN. This type of functional dependency is called trivial because it can be derived from common sense. It is obvious that if you already know the value of B, then the value of B can be uniquely determined by that knowledge. Full Functional Dependencies A full functional dependency occurs when you already meet the requirements for a functional dependency and the set of attributes on the left side of the functional dependency statement cannot be reduced any farther. For example, {SSN, age} -> name is a functional dependency, but it is not a full functional dependency because you can remove age from the left side of the statement without impacting the dependency relationship. Transitive Dependencies Transitive dependencies occur when there is an indirect 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. Multivalued Dependencies Multivalued dependencies occur when the presence of one or more rows in a table implies the presence of one or more other rows in that same table. For example, imagine a car company that manufactures many models of car, but always makes both red and blue colors of each model. If you have a table that contains the model name, color and year of each car the company manufactures, there is a multivalued dependency in that table. If there is a row for a certain model name and year in blue, there must also be a similar row corresponding to the red version of that same car. Importance of Dependencies Database dependencies are important to understand because they provide the basic building blocks used in database normalization. For example:

For a table to be in second normal form (2NF), there must be no case of a non-prime attribute in the table that is functionally dependendent upon a subset of a candidate key. For a table to be in third normal form (3NF), every non-prime attribute must have a non-transitive functional dependency on every candidate key. For a table to be in Boyce-Codd Normal Form (BCNF), every functional dependency (other than trivial dependencies) must be on a superkey. For a table to be in fourth normal form (4NF), it must have no multivalued dependencies.