数据库系统学习-week2-02：关系模型，键&完整性约束，ER 模型设计-逻辑和物理设计

关系模型

数据模型

• 构建数据模型，就是将现实世界的事物进行结构化，方便计算机进行存储。因为计算机就是为结构化的数据存储而设计的，因此我们针对不同的需要，需要将不同的结构化数据选择合适的数据模型进行建模，然后把数据存到计算机中。
• 数据模型有很多种：
  • 关系模型
  • ER 模型
  • 面向对象模型（O-O（object-oriented））
  • 网状模型
  • 层次模型，等

关系模型

• 关系模型是数据模型很重要的一个分支，它包括如下结构：
  • 行 & 列： 每一行代表一个元组（tuple），即一条数据，也可以叫一个纪录（record）；一列代表一个属性（attributes）或者一个字段（filed）。其实一行同时也代表了一个 ER 图中一个实体，所有的行就是一个实体的集合–实体集
  • 键（keys）& 外键（foreign keys）： 来连接不同的关系表（to link relations）
• 关系模型中，一个关系（relation）对应的就是一张表。
  

关系数据库（relational database）

• 关系数据库： 是一系列关系的结合（a set of relations）
• 关系（relation）： 有两部分组成
  • 关系模式（schema）：关系的描述称为关系模式（Relation Schema）它可以形式化地表示为：R（U，D，dom，F） 例如，Student(sid:string, name:string, login:string, age:integer, gpa: real) 就是一种关系模式。
  • 关系实例（instance）：一个由行和列（rows&columns）组成的**表（table）**称为一个实例。比如以上述的关系模式为基础产生的一张描述 student 的表，这个表里面涉及到 10 个student 的各种信息，这张表就称为关系实例:
    • 行（rows）= 基数（cardinality）= 行的数量
    • 字段（fields）= 度（degree or arity）= 列的数量
    • 关系（relation）可以细化地表示为：R(A1:D1,A2:D2,…,An:Dn)，可简记为R(A1,A2,…,An)，这种描述被称为关系模式；其实其中的 A1… An 就是表示不同的列（属性），而 D1…Dn 表示的则是域 （domain）（域，即：一种属性的表示范围，例如学生的性别属性，性别属性的域就是 男，女；而年龄属性的域则是 0~x(x是表中年龄的最大值)，n是关系的度或目（degree）表示的是属性的数量自然也就是域的数量，关系中 元组的数目 称为关系的基数（Cardinality）
• 可以认为，关系是一张表，是一些行（元组）的集合；所有的行都是独特的，而且是乱序的
  
  • 通过这张表可以得出：
    • 它有五个列，所以 degree（度）= 5，
    • 有三个行，所以 tuple 数量 = 3，基数（cardinality = 3）
    • 所有的行都是乱序的，而且都是独特的

ER概念模型设计–> 逻辑 + 物理设计

逻辑设计（Logical Design）：ER to Relatioinal Model

• 通过逻辑设计，把 ER 图中的 实体集 转变成逻辑设计中的 “关系图”
  

• 逻辑设计阶段要注意将多值属性 和 复合属性 进行拆分和展开：
  
  

• 将 E-R 图中 多对多（many to many） 的关系转化到逻辑设计中的 “关系图” 时，新关系图 的 “属性（attributes）” 需要具有以下重要部分：

  • 对于每个参与的实体集，都要具有 （keys），即最小超键（作为外键）。这个属性集构成了这个关系图的超键
  • 所有描述性的属性
    
  • works_ in 中的两个下划线加粗的键称为：主外键（primary foreign key）；works_in 称为联合实体

• 在从 逻辑设计→ 物理设计 的过程中，我们给数据分配具体的 数据类型；如下：
  

物理设计（Physical Design）

• 在物理设计阶段，我们选用 合适的数据类型
  

数据库设计整体流程回顾

使用 SQL 语言来创建关系（Relation）

• 每个字段(filed)的类型(域)由DBMS指定并强制执行

键&完整性约束

键（key）、超键（superkey）、主键（primary key）、候选键（candidate key）

• 键是一种将不同 relations（关系表）中的 tuple（条目）建立起关系的方式。
• 键是完整性约束的一种形式（integrity constraint）
  
  • 从上图的两张表中可以看出：右边的表内，每一行的 student 都通过 sid 这个标识进行区别，因此 sid 可以作为 student 的 主键（primary key）
  • 但是从左边的图可以看到，enrolled 这个图中，sid 有重复的条目，因此他不能作为 enrolled 的主键，但是由于可以通过它来访问 student 表，因此 enrolled 表中的 sid 称为 students 表的 外键（foreign key），外键必须依附于其他 relation 的主键而存在。
  • 在关系中能唯一标识元组的属性集称为关系模式的 超键（super key）。一个属性可以为作为一个超键，多个属性组合在一起也可以作为一个超键。
    • 主键是一个特殊的超键
    • 除了主键之外，其他的键如果能唯一标识所有 tuples 也可以作为超键
    • 如果多个属性联合起来作为一个共同的键来唯一标识每个 tuples 也可以作为超键
  • 在关系中，如果一个超键是这个关系表中的最小的超键（它的子集字段都不能唯一标识 tuples），那么我们称这种超键为一个字段集的 键（key）；也就是说，“键（key）” 是最小的超键，是没有冗余字段的超键。
  • 对于上一条中的 “键（key）”，从其中随便挑出一个作为主键（primary key）；其他的键作为候选键（candidate keys）
    
  • 从这张图可以看出来，所有字段中，能够唯一标识每一个 tuple 的字段的集合就是超键。超键可以有很多；以超键为基础找出最小的超键，即可以唯一标识出来 tuple 的最小超键。当然很多情况下，最小的超键可能就是简单的一个字段。比如 student 关系中，如果包含身份证（id number）和 学号（sid）那么这两个都可以唯一标识所有的 tuples ，所以他们都是最小超键；然后，他们两个中选出一个作为主键，另外一个就是候选键。

例子

• 对于下述 student 和 course 的 relation 表；哪个描述更加贴切？
  
  
  • 左边的贴切，因为如果采用右边的代码，那么 enrolled 这个 relation 表的 sid 作为主键，那么对于 enrolled 表，所有的行将会被这个主键唯一标定，也就是说，所有的学生只能选择一门课程（即学生的 sid 只在 enrolled 表中出现一次）。而且，使用了 UNIQUE 语句，将 cid 和 grade 联合字段设置成了唯一标识，这进一步限制了，每个课程里面的所有分数只能出现一次，因此这样是不合理的。
  • 按照左边的叙述，sid 和 cid 联合作为 enrolled 表的主键，这样学生可以选多门课，而且由于没有 UNIQUE 限制，每门课的成绩也可以重复，符合现实世界的情况。

外键

• 外键是一个字段的集合，可以通过 外键 用来引用其他关系（relation）的元组。外键必须与其他某个关系的主键共同使用，而不能单独使用。
• 如果在DBMS中强制实行所有的 外键约束，我们就说实现了引用完整性。
• 举例来说，在下图中，只有在 Student 表中列出的 student 才可以在 Erolled 表中注册课程
  
  • 在 Enrolled 表中，sid 是一个外键，他被用来引用 student 表中的实例
  • 如果 Enrolled 表中要插入一个记录，而这个记录没有在 Student 表中拥有 sid，那么这个过程会被拒绝
  • 当 Student 中的一条记录被删除时，下面哪些情况应该发生？

完整性约束

• 完整性约束（integrity constraint（IC））：对数据库的任何实例必须为真的条件；例如，域约束。
  • 当一个模式 schema 被定义的时候，完整性约束就应该被指定
  • 当一个关系 relation 被修改时，应该检查完整性约束
• 一个关系中所有合法的实例都应该满足给定的完整性约束
  • DBMS 不应该允许有非法的实例存在

结合实例总体展示：概念设计 → 逻辑设计 → 物理设计 → 实现过程

• 逻辑设计 → 物理设计
  
• 再到实现（implementation）通过编写代码实现 “表”：
  
  • 表 works_in 里面采用了联合主键，而且 ssn 和 did 分别引用了一张关系表（student、department）

【实例演示】

• 因为在 works 中引用不同的表，所以可能出现单个列中重复的字段，因此，我们选择使用 ssn 和 did 两个字段来作为 works_in 表的联合主键

ER 图中的多元关系在逻辑设计图中的表示

• 在前面的逻辑设计中讲过：把 ER 图的多元关系转变成逻辑设计中关系图的时候，关系的属性必须包含以下条件：
  • 所有参与实体集的外键；这组成了这个关系的超键
  • 所有可描述性的属性
    
  • 这个 contract 是一个多元的关系实体，因此，contract 必须包含 suppler、department、parts 中的每一个主键，他们联合起来作为 constracts 的超键；而且 constracts 通过这些键作为外键来引用这三个实体集中的实体数据，下面的图是具体的实现代码（implement过程）
    

逻辑设计中的键约束规则，如何在 SQL 编程中使用 key constraint

• 在 ER 模型图中，我们通常把 key constraint 表示为 → 或者是 —— ，如下图，我们在 Department 和 manages 之间的约束关系为：一个部门只能有一个 employee 来 manage 这个部门：
  

• 为了表示 department 拥有的键约束，我们在 department 的属性中添加了 Employee 的主键作为 department 的外键，并且加入了 since 这个 manages 的属性；从而表示 department 所拥有的键约束（key constraint）。

• 因为每个 department 只有一个 employee 来管理，所以对于一个 department 来说，那个 employee 就是唯一的，所以可以设置通过 department 的 ssn 外键唯一确定 employee；

• 但是对于 employee 来说，一个 employee 可能管理着几个部门；因此，通过一个 employee 不能唯一确定一个 department ，因此不能在 employee 中设置 department 的外键！

• 值得注意的是，右图的表示方法，其实是将 manage 这个实体关系中的属性进行了合并，从而实现了通过 department 实体集直接指向了 employee 实体（通过 ssn 外键），并且因此拥有了本该属于 manage 的属性（since）

• 多边的主键作为某一边的外键，这是一种确保实体之间键约束的方法

逻辑设计中的参与约束（participation constraint）以及如何在 SQL 中使用

• 参与约束指的是一个实体集的全部实体都参与某种关系，很显然，上图中的 department 中，每个部门都要被一个 employee 管理，因此 department 实体集是 total participation；在下图中使用粗线来表示
  
  • 在 SQL 编程中，我们把全部参与的实体集使用 NOT NULL 语句来限定，限定其不能为空。即，必须参与到某种关系中。
    
  • 注意，在 SQL 编程中，一定要在数据类型后面加上 NULL 或 NOT NULL 的约束；这个很重要

逻辑设计中的弱实体，以及如何在 SQL 中设计弱实体语句

• 弱实体只能依附于强实体存在，一旦强实体被销毁，弱实体也会跟着被销毁
  

- 在这段代码中可以看出，由于将 policy 关系集合与 department 实体进行了合并，因此，现在的实体集 department 依附于 employee 实体集而存在，一旦 employee 实体集被销，department 也会被销毁，因此给 department 引用 employee 的外键 ssn 加一个约束 ON DELETE CASCADE 这是对于弱实体而添加的约束。