使用关联实体的正确方法是什么？
What is the right way to use Associative Entity?
这是描述：
Draw an Entity-Relationship diagram for Poke-Hospital which provides
medical service to pokemon.
Each pokemon has an appointment with one of the nurse Joys. In
addition to recording the name, type and trainer of each pokemon, the
system needs to keep track of the multiple types of sickness being
diagnosed for the pokemon. During an appointment, the nurse will
always prescribe medicine. It is required to record the date, time and
dosage of the medicine. A pokemon may need to take more than one
medicine at a time. Each medicine is stored with its name, brand and
cost of purchase. There is no restriction on the amount of medicine to
be prescribed by any nurse.
Within an appointment, a pokemon may need to undergo procedures such
as a surgery and/or diagnosis. Each procedure requires different type
of rooms and a list of equipment. The date, time and the actual room
of the procedure need to be recorded.
A procedure may be performed by more than one nurse. A nurse is
involved in the procedure based on the training skills that she has
completed. Not all nurses are qualified to perform procedures.
Name, pager number as well as office number for each nurse most be
known. Your diagram should show the entities, relationships and their
attributes, and the cardinality of any relationships. Mark the best
primary key for each entity by underlining it.
这是我的解决方案：
这是我的问题：
我应该使用 Have Appointment 作为关联实体吗？
我应该删除 2 个关系 Undergo and Prescribe and connect 2
实体程序和预约医学直接有
约会关联实体？届时ERD还会好吗？
如果错了，和问题2一样，我转Have
约会关联实体转化为关系？
我对使用关联实体与关系（如 post Enrollment with Teach 和 Teacher：）和使用三元关系（将 Teacher 直接连接到 Enrollment）之间的区别感到非常困惑关系而不是将 Enrollment 更改为关联实体并具有 Teach 关系）。
- Should I use Have Appointment as associative entity?
不，我认为它应该是一个规则的实体集。你给了它自己的身份——ID 主键——我同意这一点，但这应该与元素类型的变化相对应。关联实体集 (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 无法作为主键有效处理的时间间隔。
- Should I remove 2 relationships Undergo and Prescribe and connect 2 entities Procedure and Appointment Medicine directly to Have Appointment associative entity? Will the ERD still right then?
不，我认为您应该在将 AES 转换为常规实体集后添加 Pokemon 和 Have Appointment 之间以及 Nurse 和 Have Appointment 之间的关系。
- If it's wrong, what about the same as question 2 and I turn the Have Appointment associative entity into a relationship?
上面已经回答了。
这是描述：
Draw an Entity-Relationship diagram for Poke-Hospital which provides medical service to pokemon.
Each pokemon has an appointment with one of the nurse Joys. In addition to recording the name, type and trainer of each pokemon, the system needs to keep track of the multiple types of sickness being diagnosed for the pokemon. During an appointment, the nurse will always prescribe medicine. It is required to record the date, time and dosage of the medicine. A pokemon may need to take more than one medicine at a time. Each medicine is stored with its name, brand and cost of purchase. There is no restriction on the amount of medicine to be prescribed by any nurse.
Within an appointment, a pokemon may need to undergo procedures such as a surgery and/or diagnosis. Each procedure requires different type of rooms and a list of equipment. The date, time and the actual room of the procedure need to be recorded.
A procedure may be performed by more than one nurse. A nurse is involved in the procedure based on the training skills that she has completed. Not all nurses are qualified to perform procedures.
Name, pager number as well as office number for each nurse most be known. Your diagram should show the entities, relationships and their attributes, and the cardinality of any relationships. Mark the best primary key for each entity by underlining it.
这是我的解决方案：
这是我的问题：
我应该使用 Have Appointment 作为关联实体吗？
我应该删除 2 个关系 Undergo and Prescribe and connect 2 实体程序和预约医学直接有 约会关联实体？届时ERD还会好吗？
如果错了，和问题2一样，我转Have 约会关联实体转化为关系？
我对使用关联实体与关系（如 post Enrollment with Teach 和 Teacher：
- Should I use Have Appointment as associative entity?
不，我认为它应该是一个规则的实体集。你给了它自己的身份——ID 主键——我同意这一点，但这应该与元素类型的变化相对应。关联实体集 (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 无法作为主键有效处理的时间间隔。
- Should I remove 2 relationships Undergo and Prescribe and connect 2 entities Procedure and Appointment Medicine directly to Have Appointment associative entity? Will the ERD still right then?
不，我认为您应该在将 AES 转换为常规实体集后添加 Pokemon 和 Have Appointment 之间以及 Nurse 和 Have Appointment 之间的关系。
- If it's wrong, what about the same as question 2 and I turn the Have Appointment associative entity into a relationship?
上面已经回答了。