菱形关系——识别还是非识别？答案

【问题标题】：Diamond-shaped relationships - identifying or non-identifying?菱形关系——识别还是非识别？
【发布时间】：2013-12-18 04:29:27
【问题描述】：

我有一个非常相似的问题：一个场地包含许多座位。场地还举办许多活动。我需要跟踪每个活动中预订了哪些座位。此信息保存在 event_seat 表中，该表具有与 event 和 seat 的标识关系（即其主键标识一个事件和一个座位）。

我想强制限制 event_seat 中的每一行必须引用一个 event 和一个 seat 属于同一场地。我考虑通过使venue_id 成为event 的主键的一部分，将事件->场所 转换为识别关系，如下所示：

这样做可以让我为event_seat 定义两个外键，如下所示：

(venue_id, event_id) references event(venue_id, event_id)
(venue_id, seat_id) references seat(venue_id, seat_id)

此定义将保证所需的限制（活动必须在座位所属的同一场地举行）。但是venue_id实际上是event_id的一个函数，所以(venue_id, event_id)不是一个最小超键。这不违反一些关于主键的基本原则吗？我还有哪些其他选择？

【问题讨论】：

【解决方案1】：

seat_id 本身并不是唯一的，并且在功能上不依赖于venue_id（反之亦然）。这就是为什么你应该把它命名为seat_no。 event_id 同上。

如果您想要一个自身唯一的“简单”字段，您始终可以在标识关系生成的复合键之外引入surrogate key。

或者，您可以将seat_id 单独设置为键，但引入覆盖{venue_id, seat_id} 的冗余 UNIQUE 约束，仅用于被菱形的“底部”引用。

【讨论】：

感谢您的快速回答！你是对的seat_id。我可能应该重命名它。您对event_id 的看法是错误的，尽管：event_id 本身是独一无二的，应该足以识别事件。如果venue_id 独立于event_id，我不会对底部图有任何问题。我遇到的问题是event 和venue 之间的关系，而不是seat 和venue 之间的关系。
@RonInbar 我没有必须是独一无二的，仅基于您的模型。如果还有其他一些我不知道强制它是唯一的业务规则，那么只需将其设为代理键并使用单独的字段（例如event_no）来正确建模菱形依赖项。或者使用替代解决方案（冗余 UNIQUE）。