ER图，允许这样做吗？

Question

我必须创建一个基于关系模式的ER图。

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

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

​

​

干杯

Answer 1

是的，这是一个非常好的实体关系图。(我没有回答它是否有意义:您仍然需要解决关系和基数。)

使用正确的术语可以帮助人们准确地理解您正在讨论的内容，以及您正在讨论的级别。松散的谈话会导致更多的讨论，并浪费时间来澄清你所说的术语是什么意思。不利于高效率的技术工作。

1. 在这个早期阶段，对实体和关系(而不是属性)进行建模是正常的，这就是为什么它被称为ER图；我们还远未对数据进行建模。这些关系是相关的，这就是为什么你要在方块和基数中详细描述和评估它们的性质。目标是澄清真实的实体，以及它们之间的关系。多对多关系仍然是关系。
2. 一旦你对此有了一些信心，你得到了正确的实体和关系，你就可以转向数据模型(包括属性)。仍然处于逻辑级别，n::n关系仍然是关系。

- As you progress, you may show further detail, such as Domain for each Attribute. That's the DataType, but at the Logical level, just as the terms are Entity = Table and Attribute = Column, Domain = DataType.

。

​

1. 转到Physical level时，数据模型包含表；列；DataTypes。

- And n::n Relations are manifested as the **Associative** Tables.

。

​

1. 这个想法是，只要你按照规定的步骤工作，在(1)，钻石中的内容将决定(暴露)它们是否需要存储，因此钻石被提升为一个实体；否则它仍然是一个关系。

在我得到的关系模式中，有一个名为lives-in的连接表。但是，我认为当将关系模式映射回ER图时，连接表变成了关系吗？

• 关系术语是关联表。
• 是。如果它是纯n::n表(只包含指向父表的PKs的两个FK)，则在ERD级别(仅在逻辑上)，它是一个关系。
• 如果它的列不是这两个FK，则它是实体。

Answer 2

由于玩家和区域之间存在多对多关系，因此您必须添加一个连接表(称为ex。PlayersZones)。符号本身是正确的(Chen符号)，尽管我更喜欢乌鸦脚符号。

Answer 3

我看不到你的图片(被屏蔽！)因此，我将尝试描述“正确的”设计。如果一个玩家生活在一个区域中并不一定意味着他们拥有它，你应该有四个表：

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

否则，三张表就足够了。