对这些实体之间的关系进行建模的最有效方法是什么？
krs*_*stf 1 sql database database-design entity relational-database
我有一个包含实体的数据库，如下所示：
1. User entity
2. Event entity (musical concert etc.)
3. Ticket entity
3. Notification entity
- 通知实体与工单和事件都有直接关系（1:N [工单/事件：通知]）。
- 通知将存储在数据库中，用户可以通过通知选项卡访问它们。
- 用户可以收到与其门票相关的通知（例如“我们刚刚将您的门票发送给您！”）或有关某些活动的通知（例如“活动 xy 即将推出！预订您的位置！”）。
我一直在思考三种可能的解决方案：
a) 通知实体具有以下结构：
id serial PRIMARY KEY,
.
.
ticketId integer REFERENCES tickets(id),
eventId integer REFERENCES events(id))
userId integer REFERENCES users(id) // this is present in all three solutions;
这样，Notification 实体就拥有两个外键，但一次只填充其中一个（eventId 或 TicketId），另一个永远为空。
b) 通知实体仅具有与通知本身相关的列，它不包含任何外键（userId 除外）。
关系被提取到另外两个具有此结构的关系映射表中（对于通知-工单关系，同样适用于通知-事件，除了外键引用事件）：
id serial PRIMARY KEY,
notificationId integer REFERENCES notifications(id),
ticketId integer REFERENCES tickets(id));
这样，我们创建了类似接口的东西，并且不让通知实体知道任何有关关系的信息（它只有与通知本身和 userId 相关的属性），并且我们还有两个映射关系的附加表。
c) 将Notification实体分成两个不同的实体
（TicketNotification、EventNotification），每个实体具有相同的属性，但外键列不同。
- TicketNotification - foreign key references ticketId
- EventNotification - foreign key references eventId
这样，我们就有了两个具有相同属性的表，仅在一列中有所不同，这对我来说似乎不太干燥。
我将感谢任何形式的帮助和可能的解决方案，我可能完全离开并从一个坏的角度看待它。谢谢。
你没有意识到的是这一点。您声明的谓词是：
\n\n- \n
- 每个通知都与以下一项相关：{ 事件 | 门票 } \n
这需要一个独占子类型集群。当然，我们不想要可为空的外键，后果是可怕的。这是正确的解决方案。
\n\n参考
\n\n请检查这些答案，以便对问题和解决方案有一个概念性的理解：
\n\n\n\n关系数据模型
\n\n
注意 \xe2\x80\xa2 符号
\n\n- \n
我的所有数据模型均在IDEF1X中呈现，IDEF1X 是自 1993 年以来的关系数据库建模标准。
\n我的IDEF1X 简介是初学者的必备读物。
\n有关子类型的理解和实现的完整详细信息，请参阅子类型
\n
- @krstf。是的。如果做得正确，数据库就是一个逻辑图。而你是从下往上工作……我是从上往下解释的。请务必阅读[子类型](https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/Subtype.pdf)。 (2认同)