Hey everyone, welcome back to topic number two in our database class. In this video part nine of topic two, we're going to take a look at functional dependencies. All right, now we can turn our attention to this notion of dependencies. And we'll start by talking about functional dependencies. And a functional dependency is a relationship between the attributes in the same table in which if we know the value of one attribute, we can use that to determine the value of another attribute. So for example, this is a completely unrelated example. If we know the price of one cookie, we can use that to determine the price of a box of 12 cookies. And so if one cookie costs 10 cents, we know that the box of 12 cookies should cost $1.20 assuming that there aren't any advantages of bulk purchasing or anything like that. So we have here then is this functional dependency. That is the price of the box of cookies. In this example, depends on the price of an individual cookie and the number of cookies in the box. Right, so it's a function. Right, if you want to link this back to some basic math concepts, we could say something like, I don't know, X equals Y times Z or Z if you learn British English. Right, I'll make that a better color. So it's a function, right? The box price in this example is a function of the cookie price multiplied by the quantity. This is a functional dependency. The value of the box price is functionally dependent on the values of these other two attributes. Right, so what we do then is we call the attribute or attributes, in this case on the left side of the equation. Determinants, because their values can be used to determine the value of another attribute in the same table, in this case the box price. So if I know the cookie price and I know the quantity I can use those values to determine the box price, thus cookie price and quantity are determinants. Now with these ideas in mind, we can revisit briefly this concepts of candidate and primary keys in the context of functional dependencies by definition, any candidate key that we have in a table. It can only be a candidate key if it functionally determines all other attributes in the row. So what that means is that a candidate key is only a candidate key, because if we know the value of the candidate key, we can identify the values of all of their attributes for that row. Remember, a candidate key is something that can uniquely identify each row in the table. So hopefully this makes sense. If I know the value of the candidate key, I should be able to figure out the values of all other attributes in the row. If our key is employee ID, if I know that employee ID, I should be able to use that knowledge to figure out all the other information about that employee. And of course, because a primary key is a candidate key that has been elevated to the status of candidate key or primary key, all primary keys also follow this rule. That is a primary key can only be a primary key if it functionally determines all other attributes in the row. All right, so just some examples of these functional dependencies, if I know an employee ID. This is my primary key knowing what that is. I should be able to figure out the employees last name and phone number. Similarly, if project ID is my primary key, I should be able to figure out just with that piece of information alone, the name of the project and the start date for the project.