database - 识别功能依赖

Question

我在 first normal form 中有以下架构(1NF) - 即所有包含原子值的单元格:

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

总的来说，客户可以从出租代理处租用许多特性。每个属性(property)都有一个所有者。对于那些熟悉这本书的人来说，这是从 Connolly & Begg 的 Database Systems 中提取的一个示例。

我正在尝试识别函数依赖 → 候选键、部分依赖和传递依赖等。

我在看一本教科书，但他们的建议解释得有些不好。我的建议是否正确？

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

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

如何识别其他功能依赖项？我也不清楚是什么决定了某些东西是传递依赖...

我的 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 -> rent 是不正确的。 (您的 FD2。除非您所说的租金指的是要价。)在美国，租约决定租金，从法律上讲，租约必须包括地址和租户。 (实际上是所有租户。但这是一个不同的问题。)

由于“client”和“properties”在它们的候选键中只有一列，所以它们必须在 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 中。在现实世界中，属性(property)通常由多人或企业所有，也经常出租给多人或企业。但是这种问题与规范化没有任何关系。 (直到你决定支持现实世界的情况。)

还有什么吗？