0

我正在努力为场景建模并遇到一个问题，在规范化表的同时，我们是否应该将 FK 也视为确定字段是否应该在同一个表或其他表中的关键？

例如，我有用户和团队表（一个用户可能零个或多个考虑不同运动的团队）。

Owner                                       Teams

 -----                                    -------- 
OwnerID ---PK                              TeamID  ---PK
OwnerName                                  OwnerID    ---FK  
                                          TeamManager
                                          TeamLogo

如果我们观察到这种关系，TeamManager 和 TeamLogo 完全（在功能上）仅依赖于 TeamID，而不依赖于 UserID（我理解这一点是否正确？）。我们是否应该为 UserID 和 TeamID 建立另一个表来建立关系？

任何建议都会非常有帮助。

这不是家庭作业。我正在为一个网站建模并提高我对范式的知识，以获得最佳的可扩展数据库设计。

谢谢，

4

2 回答 2

2

...我们是否应该将 FK 也视为确定字段是否应该在同一个表或其他表中的关键？

作为参照完整性的子端点与作为密钥正交（即，FK 子节点可能是也可能不是密钥）。名称“外键”仅指父端点，它必须是键（在大多数 DBMS 中）。

因此，在您的示例中，Teams.OwnerID不一定是键（根据您的描述，实际上不是）。

如果我们观察到这种关系，TeamManager 和 TeamLogo 完全（在功能上）仅依赖于 TeamID，而不依赖于 UserID（我理解这一点是否正确？）。

是的，你是对的。

在Teams3NF 中，因为所有属性在功能上都依赖于键、整个键，而只有键（所以帮助我 Codd ;)）。

原因如下：

  • 没有任何东西依赖于密钥子集，所以这是 2NF（事实上，没有“密钥子集”，因为密钥只是一个属性）。
  • 正如您已经指出的那样，TeamManager并且在功能上TeamLogo不依赖，因此您没有传递依赖，因此这是 3NF。OwnerID

我们是否应该为 UserID 和 TeamID 建立另一个表来建立关系？

对于像这样简单的 1:N 关系建模：不。

建模 M:N 将是另一回事。

所以除非有一些你没有提到的额外细节，这个模型对我来说看起来很好标准化。

于 2012-04-26T19:43:06.403 回答
0

II 没有理由为 UserId 和 TeamId 提供第三个表。现在，如果您有更多关于 TeamManager 的信息，我将创建一个经理表。每个团队只有一个用户吗？用户可以成为经理吗？

于 2012-04-26T19:14:59.077 回答