识别功能依赖性

Question

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

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

总的概述是，客户可以从租赁代理商处租用许多房产。每个属性都有一个所有者。对于那些熟悉本书的人来说，这是一个由Connolly＆amp; Co.的数据库系统提取的例子。贝格。

我正在尝试识别功能依赖项 - ＆gt;候选键，部分依赖关系和传递依赖关系等

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

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}

在美国，不属于propertyNo - ＆gt;出租。 （您的FD2。除非租赁您的意思是要价。）在美国，租约确定租金，合法租赁必须包括地址和租户。 （实际上是所有的租户。但这是一个不同的问题。）

由于“客户”和“属性”在其候选键中只有一列，因此它们必须为2NF。我认为所有这三种关系都在2NF。

你可以自己处理改进3NF（删除传递依赖）吗？

稍后。 。

是的，这里至少有一个传递依赖：propertyNo - ＆gt; ownerNo - ＆gt; OWNERNAME。通过引入所有者关系来删除该传递依赖。

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

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

还有别的吗？

Answer 2

可能应该确定4种关系：

• 客户端
• 所有者
• 属性
• 租赁

然后，根据ClientRental中的属性，我们可以推理：

• 客户：{clientNo}⟶{clientName}
• 所有者：{ownerNo}⟶{ownerName}
• 属性：{propertyNo}⟶{propertyAddress，ownerNo}
• 租赁：{rentStart，propertyNo}⟶{clientNo，propertyNo，rentFinish，rent}

对于给定的属性，开始日期是唯一的，因此组合可以提供密钥（行列式）;你也可以争辩说，租金和财产都不会提供关键。

租金可能是物业和租赁的属性;在前者中，它是要求的租金，在后者中，是获得的租金。更实际的要价租金可能会随着时间的推移而变化 - 在夏季，房产可能比冬季更有价值。

对于传递依赖关系，请考虑原始的ClientRental关系。 propertyNo标识ownerNo（和ownerName），因此潜伏着依赖性。