Functional dependencies is DBMS - key

Question

I am reading the book database management systems by Ramakrishnan, and in the chapter related to schema refinement and normal forms, i saw a sentence saying:

K is a candidate key for R means that K ----> R , where R is the relation.

We also have the decomposition rule:

If X ---->YZ, then X----->Y and X----->Z

Then, my question is, for example let R=XABCDE and X be the key. Then, since X--->XABCDE, using the second rule repeatedly, we can say X-->A, X--->B, and so on. Then that means X determines all of the attributes. But i am confused here:Then we cannot have a row in the table such that for the same X value, there is a different A value. For example, let X be the id number of a person attribute, and A be the model of the car that person has. Then a person cannot have two cars, but we do not have such a constraint, it must be able to have two or more cars.

What am i doing wrong here? Can anyone help?

Thanks

Answer 1

For example, let X be the id number of a person attribute, and A be the model of the car that person has. Then a person cannot have two cars, but we do not have such a constraint, it must be able to have two or more cars.

What am i doing wrong here? Can anyone help?

You went wrong before you started normalizing R.

Part of the job of a database designer is to decide what the database is supposed to store. This has nothing to do with normalization. In textbook problems, this part is done before the problem is presented to you.

If you start with R{XABCDE}, where "X" is a person's ID number, and "A" is a kind of car, sample data for R might look like this.

person_id   car_model      B  C  D  E
--
1           Buick Wildcat  ...
2           Toyota Corolla ...
3           Honda Accord   ...

Or it might look like this.

person_id   car_model                     B  C  D  E
--
1           Buick Wildcat, Nissan Sentra  ...
2           Toyota Corolla                ...
3           Honda Accord                  ...

Or it might look like this.

person_id   car_model      B  C  D  E
--
1           Buick Wildcat  ...
1           Nissan Sentra  ...
2           Toyota Corolla ...
3           Honda Accord   ...

The first example suggests that you want to store only one car per person. That's a defensible design decision (unless the database needs to know how many cars each person has). Universities rarely care how many cars you have; they just want to know which one is supposed to have a parking sticker.

Deciding what to store has nothing to do with normalization.

The other examples suggest that you want to store more than one car per person, in which case you need to do some normalization at the very least (in the second example) or reconsider your choice of primary key at the very least (in the third example).

Once you've decided what to store, you can start normalizing. Really, how could you start normalizing before you decide what to store? That would be impossible.

Answer 2

In relation R(XABCDE), if X is a key then for any value of X the relation only permits one value for A,B,C,D and E at any point in time. If that constraint doesn't match the reality you intended to model then maybe X was the wrong choice of key.