ER图，这是允许的吗？

Question

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

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

我已经想出了这个简单的ER图，但我不确定每个方法都有关系吗？

干杯

Answer 1

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

使用正确的术语有助于人们准确理解您正在讨论的内容以及您正在讨论的级别。讨论中松散的谈话会产生更多的数量，并且浪费时间来澄清你的意思。对生产性技术努力不利。

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

2. 一旦您对此有信心，即您已获得实体和关系权，您将转到数据模型（其中包括属性）。仍然在逻辑级别，n :: n关系保持为关系。

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

3. 当你到达物理层，数据模型有表;列;数据类型。

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

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

• 关系项是关联表。

• 是的。如果它是一个纯粹的n :: n表（除父表的父表的PK之外只包含两个FK），那么在只有逻辑的ERD级别上，它是一个关系。

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

Answer 2

既然是你必须添加一个结表[玩家]和[区域]之间的许多一对多的关系（呼吁前。[PlayersZones]）。符号本身是正确的（陈符号），但我更喜欢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) 

否则三个表就足够了。