数据库-计算机三级学习记录-从ER图到关系模型

ER图

  • 实体(矩形)
  • 属性(圆角矩形)
  • 联系(菱形)
    数据库-计算机三级学习记录-从ER图到关系模型_第1张图片
    数据库-计算机三级学习记录-从ER图到关系模型_第2张图片

ER图集成
1.合并(消除冲突*,生成初步整体ER图)
2.修改,重构
数据库-计算机三级学习记录-从ER图到关系模型_第3张图片

冲突*:

  • 1.属性冲突
  • (1.域冲突:属性范围,类型如整数与小数 2. 属性单位冲突:如斤与千克)
  • 2.命名冲突(1.同名异义 2.异名同义)
  • 3.结构冲突(1.同一队形在不同应用中有不同的抽象,如职工在一部分被应用中被当作实体,一部分应用中被当作属性2.同一实体在不同子系统中的属性与次序不完全相同实体间的联系在不同ER图中是不同的类型如E1和E2在ER图1中是多对多,但在ER图2中是一对一)
冗余数据与冗余联系

冗余数据:可以由基本数据推出来的数据
冗余联系:可以由其他联系推出来的联系

并不是所有冗余数据和冗余联系都必须加以消除,有时为了提高查询效率,不得不以冗余信息作为代价(如,一些数据的计算结果),越规范越牺牲效率

概念结构设计 ↑ \uparrow


分界线


逻辑结构设计 ↓ \downarrow
参考视频链接
转换原则

1.一个实体型转换为一个关系模式
  • 关系属性:实体属性
  • 关系的码:实体的码
    班级-班级号;班主任-班主任工号
2.实体型之间的联系
1.一个1:1联系可以转换为一个独立的关系模式,也可以与任意一端对应的关系模式相合并
  1. 独立关系模式

班级联系:管理班主任
数据库-计算机三级学习记录-从ER图到关系模型_第4张图片

两个实体先拆为两个关系模式

  • 班级(班级号)
    班主任(班主任工号)

关系模式拆表,这个表的名称叫管理()
将两个对象放入表中,提取出的独立关系模式如下

  • 管理(班级号,班主任工号)

若改变表为关系:
班级联系:管理(评价)班主任
数据库-计算机三级学习记录-从ER图到关系模型_第5张图片

可以看到关系多了属性(评价)
此时提取出的独立关系模式为:

  • 管理(班级号,班主任工号,评价)

即将关系的属性放到括号尾部

谁是主码呢,由于是一对一关系,选哪个实体都可以,在上述关系中表现为,选择班级号,班主任工号作为主码均可
2. 与某一端实体对应的关系模式合并
合并后的属性:加入对应关系的码和联系的属性
如:班级联系:管理(评价)班主任数据库-计算机三级学习记录-从ER图到关系模型_第6张图片
合并后为:

  • 班级(班级号,名字,班主任工号,评价)
2.一个1:n联系可以转换为一个独立的关系模式,也可以与n端对应的关系模式相合并
  1. 转换为一个独立的关系模式
    关系属性:与该联系相连的各个实体的码以及联系本身的属性
    关系的码:n端实体的码

班级 n联系:管理(评价)班主任
数据库-计算机三级学习记录-从ER图到关系模型_第7张图片

  • 管理(班级号,班主任工号,评价)
    在这个关系中,班级号(n端)当主码
  1. 与n端的关系模式合并
    合并后关系的属性:在n端关系中加入一端关系的码和联系本身的属性
    合并后关系的码:不变
    可以减少系统中的关系的个数,一般更倾向于该方法
  • 班级(班级号,名字,班主任工号,评价)
3. 多对多的关系m:n(必须拆分

班级 m联系:管理(评价)n班主任
数据库-计算机三级学习记录-从ER图到关系模型_第8张图片

  • 管理(班级号,班主任工号,评价)
    *班级号,班主任工号合并共同作为主码
  • 关系的属性:与该联系相连的各个实体的码以及联系本身的属性
  • 关系的码:各实体码的组合
4. 三个或三个以上实体间的一个多元联系转换为一个关系模式
  • 关系的属性:与该多元联系相连的各个实体的码以及联系本身的属性
  • 关系的码:各实体码的组合

你可能感兴趣的:(数据库,学习)