弱实体的数据库建模

Question

我在我的数据库表2 orders和orderHistory.

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

现在一个order可以有多个history lines.但是,一个history line不可能自己存在.我听说这个被称为弱实体,因此PK从orders必须的一部分PK台orderHistory.

问题

1. 这真的是一个正确的弱实体关系吗？有没有其他方法来识别它们？
2. 我应该将表的PK添加order到表中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确实有孩子,这可能是也可能不是最佳解决方案,具体取决于几个因素.

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

这不是 - 或者.字段可以是FK和(主要或备用)键的一部分,如上所示.

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

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