识别功能依赖性

Question

我在第一范式(1NF)中有以下模式 - 即所有单元格都包含原子值:

ClientRental (clientNo, propertyNo, clientName, propertyAddress, rent, 
              rentStart, rentFinish, ownerNo, ownerName)

总的概述是客户可以从租赁代理商租用许多房产.每个属性都有一个所有者.对于那些熟悉本书的人来说,这是Connolly&Begg从Database Systems中提取的一个例子.

我试图确定功能依赖 - >候选键,部分依赖和传递依赖等

我正在关注一本教科书,但有些建议的解释有些不足.有人可以向我解释我的建议是否正确:

FD1 -> clientNo -> clientName
FD2 -> propertyNo -> propertyAddress, rent, ownerNo, ownerName
FD3 -> ownerNo -> ownerName

我肯定错过了更多的功能依赖,但我缺乏经验阻止我识别它们.显然我无法确定部分依赖关系,因为我还没有为上述关系/模式分配主键.

有人可以帮助我识别其他功能依赖...我不清楚是什么决定某些东西作为传递依赖...

如果有任何需要更多说明,请告诉我.

编辑3NF:

我的3NF关系:

Client {clientNo(PK), clientName}
Owner {ownerNo(PK), ownerName}
Property {propertyNo (PK), propertyAddress, rent}
ClientRental {clientNo(PK), propertyNo(PK), rentStart, rentFinish, ownerNo(FK)}

Answer 1

要提高到2NF,请确定仅依赖于候选键的一部分而非所有候选键的非键属性.首先确定集合{clientName,propertyAddress,rent,rentStart,rentFinish,ownerNo,ownerName}中的任何属性是否仅依赖于clientNo或propertyNo.

现在,您将遇到的一个问题是,函数依赖性实际上是由值而不是列名确定的.如果没有代表性的样本值,我们必须猜一点.但可能

clientNo -> clientName
propertyNo -> propertyAddress, ownerNo, ownerName

所以我们可以通过这种方式分解ClientRental.

Relation "clients"         { (clientNo), clientName}
Relation "properties"      { (propertyNo), propertyAddress, ownerNo, ownerName}
Relation "ClientRental"    { (clientNo, propertyNo), rent, rentStart, rentFinish}

在美国,财产没有 - >租金.(您的FD2.除非租金是指要价.)在美国,租约确定租金,合法租赁必须包括地址和租户.(实际上是所有的租户.但这是一个不同的问题.)

由于"客户端"和"属性"在其候选键中只有一列,因此它们必须为2NF.我认为这三种关系都属于2NF.

你能自己处理3NF(删除传递依赖)的改进吗？

后来...

是的,这里至少有一个传递依赖:propertyNo - > ownerNo - > ownerName.通过引入所有者关系来消除该传递依赖性.

Relation "clients"         { (clientNo), clientName}
Relation "properties"      { (propertyNo), propertyAddress, ownerNo}
Relation "owners"          { (ownerNo), ownerName}
Relation "ClientRental"    { (clientNo, propertyNo), rent, rentStart, rentFinish}

关系"客户","财产"和"所有者"在3NF.在现实世界中,房产通常由多个人或企业所有,而且他们也经常租给多个人或企业.但是这种问题与规范化没有任何关系.(直到你决定支持现实世界的情况,那就是.)

还要别的吗？