使用关联实体的正确方法是什么？

Question

这是描述：

为 Poke-Hospital 绘制实体关系图，该图提供 宠物小精灵的医疗服务。

每个口袋妖怪都与其中一位护士乔伊有约会。在 除了记录每个口袋妖怪的名称、类型和训练师外， 系统需要跟踪正在发生的多种疾病 被诊断为宝可梦。在预约期间，护士将 总是开药。需要记录日期、时间和 药物的剂量。一只口袋妖怪可能需要多只 一次吃药。每种药物都存储有其名称、品牌和 购买成本。药量没有限制 由任何护士开处方。

在约会期间，口袋妖怪可能需要经历以下程序 作为手术和/或诊断。每个过程需要不同的类型 房间和设备清单。日期、时间和实际房间 需要记录的过程。

一个程序可以由多名护士执行。护士是 根据她所拥有的培训技能参与该程序 完全的。并非所有护士都有资格执行手术。

每位护士的姓名、寻呼机号码以及办公室号码最重要 已知。您的图表应显示实体、关系及其 属性，以及任何关系的基数。标记最好的 每个实体的主键，加下划线。

这是我的解决方案：

这是我的问题：

1. 我应该使用 Have Appointment 作为关联实体吗？

2. 我是否应该删除 2 个关系 Undergo and Prescribe and connect 2 实体程序和预约医学直接拥有 任命关联实体？那时 ERD 还会正确吗？

3. 如果错了，和问题2一样，我转Have 将关联实体任命为关系？

我对使用关联实体和关系之间的区别感到非常困惑（就像在这篇文章中，与教师和教师一起注册：When to use Associative entities?）和使用三元关系（将教师直接连接到注册关系而不是将注册更改为关联实体）实体并具有 Teach 关系）。

Answer 1

1. 我应该使用 Have Appointment 作为关联实体吗？

不，我认为它应该是一个常规实体集。你给了它自己的身份 - ID 主键 - 我同意，但这应该与元素类型的变化相对应。关联实体集 (AES) 首先是关系，这意味着它们由它们相关的实体集的（键）标识。

这是一个被广泛混淆的话题，因为实体关系模型中的 AES 不同于网络数据模型中的 AES。后者对于开发人员来说直观上更熟悉，因为它本质上是一个基于记录和指针的模型，但是由于它只支持有向的二元关系，所以任何更复杂的东西——多对多关系以及三元和更高的关系——都需要表示为 AES。在此模型中，AES 由代理 ID 标识，因为通常也不支持复合键。

实体关系模型支持 n 元关系和复合键，因此几乎不需要 AES。常规实体集和 n 元关系无法表示的一种情况是关系需要成为进一步关系的主题。

例如，让我们看一下Procedure 和Nurse 之间的关系，以表示参与某个程序的护士。

我更喜欢基数指标的交叉约定 - 一个护士可以执行 0 个或多个程序，而一个程序需要 1 个或多个护士。反正这里Perform的关系是通过复合主键(ProcedureID, NurseID)来标识的。

现在，如果我们想跟踪每个护士在手术过程中使用的设备，我们可能会认为简单的三元关系就可以解决问题：

但这种关系将由 (ProcedureID, NurseID, EquipmentID) 识别，从而使我们无法记录在不使用任何设备的情况下协助手术的护士。我们需要的是两个独立的关系：

(ProcedureID, NurseID)
((ProcedureID, NurseID), EquipmentID)

从第二个到第一个有一个 FK 约束，以防止不协助手术的护士处理设备。

回到Have Appointment - 这不是口袋妖怪和护士之间的关系（一个口袋妖怪可以多次看到同一个护士），这是一个涉及口袋妖怪、护士、程序和药物的事件。最好将其作为与其他四个有关系的常规实体集来处理。至于身份，我想一个口袋妖怪或护士一次只能有一个约会，所以我们可以选择(PokemonID, DateTime)或(NurseID, DateTime)作为自然键。然而，在实践中，我们通常通过代理 ID 来识别事件，因为事件跨越了一个大多数 DBMS 无法有效地作为主键处理的时间间隔。

1. 我应该删除 2 个关系 Undergo 和 Prescribe 并将 2 个实体 Procedure and Appointment Medicine 直接连接到 Have Appointment 关联实体吗？那时 ERD 还会正确吗？

不，我认为您应该在将 AES 转换为常规实体集之后添加 Pokemon 和 Have Appointment 之间以及 Nurse 和 Have Appointment 之间的关系。

1. 如果错了，那和问题 2 一样，我把 Have Appointment 关联实体变成关系呢？

上面已经回答了。