在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列表来存放这种关系。