弱实体的数据库建模

Question

我的数据库orders和orderHistory有2个表。

 -----------------                    -----------------------
 |  orders       |                    |  orderHistory       |
 -----------------                    -----------------------
 | orderID  (PK) |                    | historyLineID  (PK) |
 | orderDate     |                    | status              |
 | price         |                    | quantity            |
 -----------------                    -----------------------

现在order可以有多个history lines 。 但是， history line不能单独存在。 我听说这个被称为弱实体，因此从PK orders必须是表的PK的一部分orderHistory 。

问题

1. 这真的是一个正确的弱实体关系吗？ 有没有其他方法来识别它们？
2. 我应该将表order的PK添加到表orderHistory并使其成为复合主键吗？
3. 如果我决定将新记录添加到orderHistory ，我将如何添加新的复合键？ （ orderID可从表orders ，但historyLineID应自动递增。）
4. 如果我决定来模拟这是其中一个正常的一对多关系orderID添加为外键而不是只 ？ 这样做的缺点是什么？
5. 如果所有表都处于第3范式，那么在设计的后期会忽略弱实体会导致任何问题吗？

注意

orderID和historyLineID都是代理键。 提前致谢。

Answer 1

一个实体并不弱，因为它不能独立存在，而是因为它无法独立识别 。 因此，“引导”到弱实体的关系称为“识别”关系。 在实践中，这意味着父母的主键被迁移到子PK的（通常是适当的 ）子集中（术语“弱实体”通常与主键相关地定义，但理论上它可以应用于任何键）。

拥有一个不能独立存在的实体是完全合法的，但可以独立识别 - 换句话说，就是与非NULL的非识别关系。

您必须要问： historyLineID可以单独使用 ，还是与orderID结合使用？ 我怀疑后者就是这种情况，这会使它成为一个弱势实体。

这真的是一个正确的弱实体关系吗？

你告诉我们的不是一个弱实体 - 父母的PK不会迁移到孩子的PK中。

有没有其他方法来识别它们？

你基本上有两个选择：

• orderHistory有一个复合PK： {orderID, historyLineID} ，其中orderID是FK。 顺便说一句，这个PK可以被认为是“自然的”：

  

• orderHistory有一个代理PK： {orderHistoryID} ，而orderID在PK之外。 您仍然需要备用密钥{orderID, historyLineID} ：

  

我应该将表顺序的PK添加到表orderHistory并使其成为复合主键吗？

是的，这是上面描述的第一个选项。 除非您在orderHistory本身拥有子关系， orderHistory这也是最佳解决方案。 如果orderHistory确实有孩子，那么这可能是也可能不是最佳解决方案，具体取决于几个因素。

如果我决定将其建模为正常的一对多关系，其中orderID被添加为外键，该怎么办？ 这样做的缺点是什么？

这不是 - 或者。 字段可以是FK和（主要或备用）键的一部分，如上所示。

如果所有表都处于第3范式，那么在设计的后期会忽略弱实体会导致任何问题吗？

除非您正确指定密钥，否则您将无法达到3NF，如果不考虑哪个实体可以独立识别，哪个不能独立识别，您将无法做到这一点。

Answer 2

1. 由于依赖，它是一种弱的实体关系，但它本质上是一种优柔寡断的例子。 订单可能包含一对多的历史记录行，但每个历史记录行必须具有orderID，对吗？

这听起来像是一种可选的强制性关系。 所以你的orderId在orderHistory中有“可选”属性...... 2.你可以通过使主键成为orderID和historyLineID 3的组合来部分解决问题。你必须在orderID表上做一个复杂的关系。 因此，您必须重新加入order.orderID，然后创建新的historyLineID，否则您无法创建尚未存在的内容。 这是应该的方式。 对于处理脚本的未来人员，以及可能是您自己，更容易理解这种方式。 使用外键创建具有多个historyLineID（子）的orderID（父），因为订单可以有多个订单行，这种方法可能是最好的。

链接： 在此输入链接说明