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的联结表.但是,我想在将关系模式[back]映射到ER图时,联结表成为一种关系？

• 关系术语是关联表.

• 是.如果它是一个纯n :: n表(只包含两个FK到父表的PK),则在ERD级别(仅逻辑),它是一个Relation.

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