ERD 中弱/关联实体的超类型/子类型

Question

我有一些问题需要回答。需求是为高考系统建立一个数据库： "申请人可能申请5所大学，每所大学可能会或可能不会面试申请人，然后向申请人发出offer。offer可能会或可能不会 是有条件的（有条件的/无条件的），如果offer是有条件的，则存储条件。申请人需要选择他/她希望接受的有条件的offer，最多3个。如果任何一个条件是年底满足，offer变成无条件的，那么申请人就可以接受了。”

有一些值得注意的点：

• 课程作业需要使用一些增强的 ER 功能，例如超类型/子类型。
• 无论offer是有条件的还是无条件的，申请人都可以接受offer。我说的对吗？
• 在我的 ERD 中，APPLICATION 实体是一个弱实体，使用代理键，并在 University_ID 和申请人 ID 上使用 UNIQUE_CONSTRAINT。

在我的 ERD（工作中）中，有 2 个版本。 ERD_1 是我朋友的建议。但我认为，我在 ERD_2 上的工作更准确。我有问题：

• 在 APPLICATION 实体中使用代理时是否正确？或者使用 University_ID 和申请人 ID 的组合是主键？
• APPLICATION 实体可以是关联实体吗？如果是，它可能有一些子类型？
• 在 ERD_2 中，如何显示 APPLICANT 和 OFFER 实体之间的 ACCEPT 关系？以及如何显示 UNIVERSITY 和 OFFER 之间的 MAKE 关系？

ERD_1
ERD_2
我将不胜感激。

Answer 1

我想不出为什么不能将弱实体分析为子类型（又名子类​​，又名特化）。但是，您的两个 ERD 表明您对案件的分析不是专业领域之一。特别是，在您的第一个 ERD 中，您使用“有”一词来描述申请与面试或报价之间的关系。

“具有”关系通常不是泛化-专业化关系。 “Is-a”关系通常是。示例：汽车是车辆，卡车是车辆。

这里有一个完全不同的问题，即您将使用哪些表、列和约束来实现您的模型。这是一个设计问题，而不是分析问题。

我对你的情况不够了解，无法同意或不同意你对你的情况的分析。