数据库系统学习-week2-01：概念设计-ER实体关系建模

实体关系模型

基础的 ER 建模概念

实体：

• 某类事物，区别于其他事物。实体具有属性（attribute）。一个人可以是一个实体，一只猫也可以是一个实体，人之所以区别于猫，是因为人具有很多猫不具有的属性

实体集：

• 一类实体的集合。10 个人放在一起就是 “人” 的实体集。
  • 在同一个实体集里面的实体都有着相同的属性，
  • 每一个实体集中的实体都有一个 key 来唯一标识（这是为了以后设计出来数据库之后能够唯一搜索到这个条目而设计的）
  • 通常我们使用 ER 图来完成对实体集的抽象（概念设计阶段），我们会用 “椭圆” 来表示这个实体集中所有实体都具有的性质；唯一标识的 key 在图中使用下划线标出（SSN）
    

关系：

• 关系是用来表示两个或多个实体之间的关系的，关系也有属性（attributes）

关系集：

• 关系集和实体集类似，也是有许多表示同样类型的关系组成的。
  

  • 在这张图中，since 是关系的属性。works in 是一个关系集，每个关系集里面的关系都把两个或多个实体进行一一映射，下图表示的更加详细：
  • 在这张图有个地方很微妙，那就是虽然 employee 这个实体集合中的实体 和 department 这个实体集合中的实体存在多对多（many to many） 的关系（图中 works in 中的每一个黑色的方框都是一个关系）。

  一个实体集中的不同实体可以：

  • 和 其他实体集（other entitie set through relationship sets） 中的实体建立关系
  • 和 本实体集 中的实体建立关系
    
  • 例如在本图中：实体集 employee 中的实体们既可以通过关系集 works in 和实体集 department 中的实体们建立关系，又可以通过 reports to 去和 employee 中的其他实体们建立关系，也就是在本实体集中扮演不同“角色”。

约束

key constraints (键约束)：

• 一个实体集与另外一个实体集建立关系的时候，两边的实体集分别有多少实体参与到这个关系中。实体集与实体集之间的关系，完全取决于一个实体集中的某个实体最多可以和另外一个实体集中的实体建立多少关系，

  • 如果 A 实体集中的单个实体 a1 最多可以和 B 实体集中的 1 个实体建立联系，而 B 中的单个实体也最多与 A 中的 1 个实体建立联系，那就是 一对一 的关系。
  • 如果 A 实体集中的单个实体 a1 最多可以和 B 实体集中的 n 个实体建立联系，而 B 中的单个实体也最多与 A 中的 1 个实体建立联系，那这就叫 一对多 的关系，也叫 多对一的关系，主要是视角不同，以 A 中之 1 对 B 中之多，成为一对多，以 B 中之多对 A 中之一则是多对一。
    
  • 从图中可以看出，一个实体集和另外一个实体集存在的关系有三种 1v1，1v 多，多v多

  key constraints --> many to many：
  

  • 这是一个多对多的例子，一个部门里面可以有很多个职工，一个职工也可以在多个部门任职

  key constraints --> one to many：
  

  • 这是一个一对多的例子，一个职工可能同时是多个部门的领导，管理着多个部门，但是一个部门却只能被一个人管理。

participation constraint(参与约束)：

• 参与约束用来表示一个实体集中的所有实体是否参加到一个关系中去。如果所有实体都参与了这种关系，那么我们成为实体集“完全参与 total participation”某一种关系，否则的话我们成为实体集“部分参与 partial participation”

  完全参与：指的是所有实体至少参与一种关系；用 加粗的直线 来表示，如下图所示：
  

  • 从图中可以看出，完全参与这种描述针对的是某个实体集。
  • 左下角的这个图中， employee 实体集完全参与 works in 这个关系；同样地，department 这个实体集也完全参与 work in 这个关系，因此在 Employee 实体集、department 实体集 和 work in 之间使用的都是粗实线
  • 右下角的这个图有鲜明对比，employee 实体集部分参与 manages 这个关系，而 Department 实体集完全参与 manages 关系，因此在图中表现出来只有 manages 和 department 之间是粗实线。

弱实体（weak entity）：

• 弱实体和弱实体集必须通过一种 “关系 relationship” 依附于强实体
• 弱实体依附的强实体是唯一的，即弱实体只能依附于一个强实体（key constraint），而不能单独存在
• 弱实体用加粗的矩形框来表示。
• 弱实体集中的每一个实体必须参与与强实体建立的 “关系”，也就是说 弱实体集 必须完全参与与强实体的关系
• 弱实体没有主键只有一个 “partial key （部分键）” 部分键只有依附于强实体的主键才能够被唯一标识，如果没有强实体的主键，则不能唯一区分弱实体。
• 弱实体的 partial key 用虚线下划线来表示
  

三 / n元关系 （Ternary / N-ary Relationship）

• 通常来说，我们可以有 n元关系，而且关系都可以具有各自不同的属性。
  
  • 这是一个 3 元关系，但是这个 contract 关系集只有一个属性 Quantity
• 比较一下下面两个关系图是否具有相同的意义？
  
  • 在第二个关系图中，D 和 P 没有直接关系，虽然能够从数据库中通过 D 一系列操作之后，可以查到 P 中的数据，但是完全没有必要，如果查 P 的数据，完全可以通过 S 查。
  • 在 E-R 图中，我们往往把关联的实体集直接通过实线和关系进行连接，没有直接连接的，我们认为没有直接关系。
  • 因此我们认为第二个图和第一个图完全不同

特殊属性类型（Special attribute）

• 多值属性（multi-valued attributes）
  • 多值属性指的是一个实体集中的某个属性可以有多于一个的值。和 “单值属性” 相对应
    
    • 在本图中，由于一个员工可能有多个电话号码，因此，电话号码是一个多值属性
• 复合属性（composite attributes）
  • 复合属性有隐藏的结构（structure hidden inside）
    
  • 如图所示，Address 是一个复合属性，它包含了一个独特的结构，Address 有 postcode，street name 和 street num 组成；这三个子属性，都是不同的类型。

牛刀小试

• 对于大学的数据库进行模式设计尝试：
• 实体包括：
  • 课程
  • 教授
• 每个课程都要有：
  • ID，
  • title，
  • name
• 教授的属性有：
  • name,
  • age,
  • phone number,
  • email address,
  • address…
• 实体之间的关系可以有：
  • 每个教授必须教一些课程
  • 每个教授只能教一门课程
  • 每个教授只能教一门课程，而且每门课程可以被几个教授参与教学

概念设计

设计选择

• 一个概念应该被设定成实体还是属性？
• 一个该你应该被设定为实体还是关系？
• 我们应该设计二元关系、三元关系还是 n-元关系？

E-R 图中的约束选择

• 应该在不同的实体之间选择什么样的约束？

实例：属性还是实体？

• 在 employee 中的 address 到底应该设计成一个属性还是一个实体？
• 这取决于如何使用 address 的信息，如果一个人拥有多个 address 信息，那么他就要被设计成实体，因为属性在实体集中是不可再分的。

E-R 设计中的注意事项

• ER 设计是主观的，通常给定一个场景可以有很多种设计的方法
• 分析备选方案是很棘手的，尤其是在一个大公司的数据库系统设计中
  • 选择概念作为实体还是属性
  • 选择实体作为实体还是关系
  • 到底选用几元的关系
• E-R 图没有一种特定的标准的符号表示，在这里我们选用的是 Peter Chen’s notation

概念设计的总结

• 概念设计紧贴于需求分析，对要存储的数据产生一种高级描述
• 在概念设计中我们通常选用 E-R 模型图来进行建模，因为 E-R 图的构造具有很强的表现力，而且接近于人们思考应用程序的方式；E-R 图首次被 peter chen 于 1976 年提出；E-R 图在多年的发展中产生了很多的变种
• E-R 图的基本组成部分：实体，关系，属性（包括实体属性和关系属性）
• 一些附加的结构：弱实体