确定函数依赖

Question

我在第一范式（1NF）下面的架构 - 这是所有细胞都含有原子值：

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

的大致轮廓是，客户可以从让代理租的许多特性。每个属性有一个所有者。对于那些熟悉这本书的人来说，它是Connolly从数据库系统中提取的一个例子& Begg。

我试图找出函数依赖 - >候选键，部分依赖和传递依赖等

我下面一本教科书，但有建议是有些解释不清。可能有人向我解释，是否我的建议是正确的：

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

大概有4间关系应查明：

• 客户
• 所有者
• 物业
• 租赁

然后，考虑到ClientRental的属性，我们可以有理由：

• 客户：{clientNo}⟶ {clientName}
• 业主：{ownerNo}⟶{OWNERNAME}
• 属性：{propertyNo}⟶{propertyAddress，ownerNo}
• 租赁：{rentStart，propertyNo}⟶{clientNo，propertyNo，rentFinish，租金}

对于给定的属性，开始日期是唯一的，所以组合可以提供一个键（行列式）;你也可以争辩说rentFinish和propertyNo会提供一个关键。

租金可能是物业和租赁的属性;在前者中，租金是后者获得的租金。更现实的要求租金可能会随着时间的不同而有所不同 - 在夏季，该房产可能比冬季更有价值。

对于传递性依赖关系，请考虑原始的ClientRental关系。propertyNo标识ownerNo（和ownerName），所以存在潜在的传递依赖关系。

Answer 2

要提高到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。在现实世界中，物业通常由多个人或企业拥有，而且他们也经常租赁给多个人或企业。但是这种问题与标准化没有任何关系。 （直到你决定支持现实世界的情况，就是这样）。

还有什么？