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

Question

我有一些问题需要回答。要求是为大学入学系统建立一个数据库：  ＆＃34;申请人可以申请5所大学，每所大学可能会或可能不会与申请人面谈，然后向申请人提出申请。要约可能是也可能不是是有条件的（有条件/无条件），如果要约是有条件的，则存储条件。申请人需要选择他/她希望接受的有条件要约，最多为3个。如果在年终时满足任何条件，则要约变为无条件，然后，申请人可以接受该要约。＆＃34 ;

有一些值得注意的要点：

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

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

• 在APPLICATION实体中使用代理时，我是否正确？或者使用University_ID和Applicant_ID的复合是主键吗？
• APPLICATION实体可以成为关联实体吗？如果是，它可能有一些子类型？
• 在ERD_2中，如何显示APPLICANT和OFFER实体之间的ACCEPT关系？如何显示大学与优惠之间的MAKE关系？

ERD_1
ERD_2
我将不胜感激任何帮助。

Answer 1

我无法想到为什么弱实体不能被分析成亚型（也就是子类又称为特化）。但是，您的两个ERD表明您对案例的分析并非专业化。特别是，在您的第一个ERD中，您使用“has”一词来描述应用程序与面试或要约之间的关系。

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

当涉及到用于实现模型的表，列和约束时，这里存在完全不同的问题。这是一个设计问题而不是分析问题。

我不完全理解你的情况，不同意或不同意你对案件的分析。