View Forum Topic

Forums
CS422
normalization and keys

Author	Message
mnava18 Posts: 86	Posted 20:58 Apr 15, 2016 \| i was confused with how this process works when i saw it in class. so we get the keys from the FDs we got from the table. so for example {faculty,room}--->{phone} from our exercise , to be a key it must functionally determines all attributes of R. does the mean it has to functionally determine all the columns in the whole table? or just in the relation {faculty,room}--->{phone}? so would the key for the FD be key:{faculty,room]? now that im thinking about that rule, we cannot infer any FDs except of the form A->B where B is a subset of A. I expect that you want us to infer other FDs, but if so they haven't communicated how and the question is ill-phrased Last edited by mnava18 at 00:08 Apr 16, 2016.
cysun Posts: 2935	Posted 12:02 Apr 16, 2016 \| 1. A key must functionally determine all the columns in the whole table. 2. FD is not "inferred". FD are "asserted" based on your assumptions about the system or application. For example, if we assume that a faculty has only one phone number and that number doesn't change and no two faculty share the same number, then {faculty}->{phone} and {phone}->{faculty}. If the assumption is that a faculty can have more than one phone number, then {faculty}->{phone} is no longer a FD but {phone}->{faculty} still is. Most assumptions are obvious and common-sense. For example, each student has a unique CIN, and a student only gets one grade for a particular assignment. You can include your assumptions in your answer if you think they are not obvious. Last edited by cysun at 12:03 Apr 16, 2016.

Author

Message

mnava18

Posts: 86

Posted 20:58 Apr 15, 2016 |

i was confused with how this process works when i saw it in class. so we get the keys from the FDs we got from the table. so for example

{faculty,room}--->{phone} from our exercise , to be a key it must functionally determines all attributes of R. does the mean it has to functionally determine all the columns in the whole table? or just in the relation {faculty,room}--->{phone}? so would the key for the FD be key:{faculty,room]?

now that im thinking about that rule, we cannot infer any FDs except of the form A->B where B is a subset of A. I expect that you want us to infer other FDs, but if so they haven't communicated how and the question is ill-phrased

Last edited by mnava18 at 00:08 Apr 16, 2016.

cysun

Posts: 2935

Posted 12:02 Apr 16, 2016 |

1. A key must functionally determine all the columns in the whole table.

2. FD is not "inferred". FD are "asserted" based on your assumptions about the system or application. For example, if we assume that a faculty has only one phone number and that number doesn't change and no two faculty share the same number, then {faculty}->{phone} and {phone}->{faculty}. If the assumption is that a faculty can have more than one phone number, then {faculty}->{phone} is no longer a FD but {phone}->{faculty} still is.

Most assumptions are obvious and common-sense. For example, each student has a unique CIN, and a student only gets one grade for a particular assignment. You can include your assumptions in your answer if you think they are not obvious.

Last edited by cysun at 12:03 Apr 16, 2016.