ER图，这是允许的吗？

Question

我必须根据关系模式创建ER图。

有一张球员桌和一张区域表。玩家可以在许多区域“生活”，每个区域由一个或多个玩家拥有。

我想出了这个简单的ER图，但我不确定是否允许每种方式都有关系？

干杯

Answer 1

是的，这是一个非常好的实体关系图。 （我没有回答是否有意义：你仍然需要解决关系和基数。）

使用正确的术语有助于人们准确理解您正在讨论的内容以及您正在讨论的级别。松散的谈话会导致讨论的数量增加，并且浪费时间来澄清你对哪个术语的含义。不利于高效的技术工作。

1. 在这个早期阶段，对实体和关系（非属性）进行建模是正常的，这就是为什么它被称为ER图;我们远不及数据建模。关系是相关的，这就是为什么你要详细描述和评估它们在钻石和基数中的性质。目标是澄清真实的实体及其相互之间的关系。多对多关系仍然是关系。 ERD纯粹是逻辑的，没有物理。

2. 一旦你对此有了信心，你已经获得了实体和关系，你就转到数据模型（包括属性）。仍然处于逻辑级别，n :: n关系仍然是关系。

   • 随着您的进步，您可能会显示更多详细信息，例如每个属性的域。这是DataType，但在逻辑层面，正如术语是Entity = Table和Attribute = Column，Domain = DataType。

3. 当您进入物理级别时，数据模型会有表格;列;数据类型。

   • 和n :: n关系表现为 Associative 表
4. 这个想法是，只要你正在通过规定的步骤，在（1），钻石中的内容将确定（暴露）是否需要存储，钻石因此被提升为实体;否则它仍然是一个关系。

在我给出的关系模式中有一个名为lives-in的联结表。但是，我想在将关系模式[back]映射到ER图时，联结表成为一种关系？

• 关系术语是关联表。

• 是。如果它是纯n :: n表（只包含父表的PK的两个FK），则在ERD级别（仅逻辑），它是一个关系。

• 如果它有两个FK以外的列，则它是一个实体。

Answer 2

由于[玩家]和[区域]之间存在多对多关系，因此您必须添加联结表（例如[PlayersZones]）。符号本身是正确的（Chen符号），虽然我更喜欢Crow's Foot Notation。

Answer 3

我无法看到您的图像（被屏蔽！）所以我只想尝试描述“正确”的设计。如果生活在某个区域的玩家并不一定意味着他们拥有它，那么您应该有四个表格：

PLAYER (playerid, <other fields>)
ZONE (zoneid, <other fields>
PLAYER_ZONE(playerid, lives_in_zoneid)
ZONE_OWNER (zoneid, owner_playerid)

否则三个表就足够了。