The question you raise has to do with the definition of first normal form (1NF). Whether the answer directly involves functional dependencies depends in part on the definitions you accept. Wikipedia has a fairly simple article about 1NF.
title author year category
--
An Introduction to Database Systems CJ Date 2003 databases, modeling, storage, retrieval
If you look at the column "category" one way, it contains a single value. Depending on your dbms and your design, that value might be the string "databases, modeling, storage, retrieval", or it might be the array "{databases, modeling, storage, retrieval}".
If you look at the column "category" another way, it contains four values. Those values are the four strings "databases", "modeling", "storage", and "retrieval".
In database design, the solution is to use two tables. But I don't think you can decompose the "bad" table by projection (which CJ Date identifies as the decomposition operator), because projection doesn't split the content of a column into multiple rows. (Projection doesn't give you four rows from the single value "databases, modeling, storage, retrieval", which is what you need to do. "Join", the recomposition operator, doesn't yield a single value like "databases, modeling, storage, retrieval", either.)
The inability to decompose by projection suggests that the solution to this problem doesn't have to do with functional dependencies. The resulting table would have three attributes, {title, author, category}, the only key would also be {title, author, category}, and that table would be in 5NF.
Yes, it's in 1NF.
You can't side-step the often hard work of determining all the candidate keys by hanging a number off the end of the table and saying, "There. I've got a primary key." One natural candidate key for this table is {Name, Bought from, Date bought}. Consider using "Time bought" instead of "Date bought".
Your definition of 2NF is wrong. Instead of
Second Normal Form: A relation that is in First Normal Form and every
non-primary-key attribute is fully functionally dependent on the
primary key.
you need something more like this.
Second Normal Form: a relation that is in First Normal Form, and every non-prime attribute is fully functionally dependent on every candidate key.
The term non-prime attribute doesn't mean quite what non-primary-key attribute means.
Your definition of 3NF is wrong, and it's wrong for the same reasons as your definition for 2NF was wrong.
Instead of this
Third Normal Form: A relation that is in First and Second Normal Form
and in which no non-primary-key attribute is transitively dependent on
the primary key.
you need something closer to this.
Third Normal Form: A relation that is in Second Normal Form and in which every non-prime attribute is nontransitively dependent on every candidate key. (There isn't a really good way to express all those negative in one sentence.)
Best Answer
A functional dependency is exactly what the term implies - the output of the function is always determined by the input. If for example we have a function f(), and provide variable x, and we always receive output y, then y is functionally dependent on x. You can think of this like a simple graphing function
2x + 1 = yPlugging some sample values into the function we get:and so on. Thus we know that for every value of x, there is value of y that will always be that value of y for that x.
Codd adapted this to data management with respect to determining if one data element's value always results in a known value of a second data element as if it were the input and output of a function. So for example, if we find that each employee of a small company is given an employee number, and we create a simple list of employee numbers and names, we find that the name is functionally dependent on that employee number. Every time we see the employee number 7 for example, we see the name "Jim Brown." This represents in the database the proposition that is true in the real world - namely that employee number 7 is the person named "Jim Brown" that we can point to and say "that's him."
Functional dependency can be implemented as a unique constraint because there is a one to one relationship between the input to the function and the expected output. In the algebra example, when we plug 2 into the equation 2x + 1 we will always get 5. Applying that example to data management in the example above, each time we have the employee number 7 we need to have one and only one name and other characteristics that goes with it. We can't have employee number 7 associated with "Jim Brown" and "Bob Jones" anymore than we could say that plugging 7 into 2x + 1 can yield 15 and 25. This application of simple math to data management is the fundamental underpinning that allows the DBMS to be told how to protect data integrity without having to understand the semantics of the data.
Functional dependencies are by definition implemented when a unique constraint is placed on each table identifying each set of data elements that have a one to one relationship with another set of data elements and whose values always vary with that first set. The notation is typically:
This means that the value of A and B determines the value of C. Perhaps A is employee number and B is Dependent Number, and C is the dependent's name. So in this sense they apply to each and every table in each and every schema in each and every database.
Some good references on relational theory are Fabian Pascal's Practical Database Foundation Series and Chris Date's book Relational Theory for Computer Professionals.