钻石形状的关系 - 识别还是不识别？

Question

我的问题与此问题有关：How to keep foreign key relations consistent in a "diamond-shaped" system of relationships

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

我想强制执行 event_seat 中的每一行必须引用属于同一<的事件和席位的限制场地即可。我考虑过转换事件 - ＆gt;将venue_id的{​​{1}}部分作为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)不是最小的超级密钥。这是否违反了关于主键的一些基本原则？我还有其他选择吗？

Answer 1

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

如果你想要一个简单的＆＃34;如果字段本身是唯一的，您可以随时将surrogate key 添加到由识别关系生成的复合键。

---

或者，您可以将seat_id单独作为密钥，但引入涵盖{venue_id, seat_id}的冗余 UNIQUE约束，仅用于＆＃34引用的目的;底部＆＃34;钻石。