如何处理E-R图中的“关系的属性”【关系代数骚操作】

在E / R图中，关系是否具有属性？

在ER模型中，实体具有可以是各种类型的属性，如单值，多值，复合，简单，存储，派生和复杂。但是关系也可以具有与之相关的属性。通常，如果不需要，不建议为关系提供属性，因为在将ER模型转换为关系模型时，事情可能会变得复杂，我们可能需要创建一个单独的表来表示关系。让我们看看各种情况，以及何时需要借助示例为关系赋予属性：

1.一对一关系：

在一个组织中，员工管理一个部门，每个部门由一些员工管理。因此，em> Department实体全部参与，并且给定实体之间存在一对一的关系。现在，如果我们想要存储员工开始管理部门的Start_Date，那么我们可能会认为我们可以将Start_Date属性赋予关系管理。但是，在这种情况下，我们可以通过将Start_Date属性与Employee或Department实体相关联来避免它。

假如有n个一对一关系，也就是有n个数据对象需要存储（寄生），这时候正好有n个员工和n个部门，所以2个反向都可以寄生。

2.一对多关系：

在一个组织中，许多员工可以为一个部门工作，但每个员工只能在一个部门工作。因此，实体之间存在一对多的关系。现在，如果我们想在员工开始为部门工作时存储Start_Date，那么我们应该将其分配给Employee实体，而不是将其分配给关系。将其分配给员工实体是有道理的，因为每个员工只能为单个部门工作，但另一方面，一个部门可以让很多员工在其下工作，因此，如果我们将Start_Date属性分配给Department，则没有意义。

这时候，假设有n个员工，则有n个一对多关系需要寄生，而部门的数量<n，所以只能将start date数据存在n个员工身上。

 

3.多对多的关系：

在一个组织中，员工可以同时处理许多项目，每个项目都可以让很多员工参与其中。因此，这是一个多对多的关系。因此，将Number_of_Working_hours分配给员工将无法工作，因为问题是它将存储哪个项目的工作时间，因为单个员工可以处理多个项目。与项目实体的情况类似。因此，我们被迫将Number_of_Working_hours属性分配给关系。

这时候，假设有m个员工和n个项目，关系数最多的情况是两两都有关系，即总关系数为m*n，但是现在总共能存储的位置只有m+n个，根本不够存放，所以两边都不能移动。

 

结论：仅在多对多关系的情况下为关系提供属性。

实例（多对多）

如果两个实体之间的关系是多对多，我们将需要一个额外的关系表，新表应该至少有两个属性（外键）来自每个表（它们各自的主键）。但是，我们可以根据要捕获的数据的需求和深度添加更多属性。

让我们举两个实体玩家和游戏的例子。

场景：许多玩家玩很多游戏

这两个表之间的关联将是多对多的。表格player仅包含player详细信息（PlayerID，Name，...），表格game仅包含游戏详细信息（GameID，Name，Venue，...）。

要知道哪个玩家玩哪个游戏以及何时玩，我们构建一个新表（Plays），其中包含来自任一表的属性。

还要注意的是PlayerID上播放是一个外键和引用玩家表。游戏ID上播放是一个外键和引用的游戏表。但是，GameID和PlayerID的组合在Plays表中形成一个复合主键。

 

注意：该图是使用ERDPlus创建的

如果多对多关系没有属性

那么就不用第三张表，可以利用json列表来存放这种关系。