数据库系统概论学习2-《关系数据库与 E/R 模型》

-----------------------------一直更新学习内容------------------------------------

建立一个关系数据库需要几步？

2.关系数据库与 E/R 模型

• 外键：
  不同的表中会有相同的属性。如果一个关系r1的属性中，包含了其他关系r2的主键，我们就将这个属性称为r1上的外键（foreign key）。例如选课信息表中的ID属性，是学生信息表中的主键，那么ID属性就是这个选课信息表上的外键（注意：在选课信息表中，{ID,CourseID}是主键，而{ID}不是）。
  为什么我们要提出外键的概念呢？在关系r2中它是主键，我们会对它进行唯一性的检查，在关系r1中，我们并不会这么做，而从整个数据库的角度而言，它们实际上是同一个属性，这样的区别对待势必有潜在的风险。

选取主键是一项非常重要的任务,如果选取不当会对数据库造成意想不到的麻烦。以下哪些说法是正确的：

2.8 由外键引发的联想

• 参照完整性约束

在介绍外键时，我们提出了一个问题。位于不同关系中的同一个属性，可能会被给予不同的重视程度或优先级。我们在对待主键时，会考虑它是否具有排他性，是否不容易改变，而对于普通的属性我们没有，当然也没有必要有，这样的考虑。

解决这一问题的办法，就是在数据库中增加 参照完整性约束（Referential Integrity Constraint），提升我们对这个普通属性的关注度。参照完整性约束要求我们保证这个普通属性的值，如果不是一个空值，那么必须是在主键属性或候选键属性中出现过的。

例如在 Student (ID, Name, Age, Gender, YearofEnroll, Dept) 中，属性 Dept 的所有值有两种可能性，一是空值，二是 Department (Dept, Intructor, Office) 中属性 Dept 已有的值中的某一个。

除了参照完整性约束，数据库中还有实体完整性约束和用户定义完整性约束。

• 实体完整性约束

相对于参照完整性约束，实体完整性约束（Entity Integrity Constraint）容易理解得多，它是针对主键而言的。它要求，如果一个关系中的一个或多个属性是这个关系的主键，那么这个或这些属性必须可以作为区分不同元组的依据的值，且不能为空值。简而言之，就是作为主键的属性一定要有内容，因为主键是我们识别和区分元组的唯一途径，这样的要求是合理且必要的。
例如在 Student (ID, Name, Age, Gender, YearofEnroll, Dept) 中，属性 ID 不能为空值，在 Takes (ID, CourseID, Teacher, Semester, Year, Grade) 中，属性 ID 和 Course_ID 都不能为空值。
在任何关系数据库中，都要满足实体完整性约束和参照完整性约束。这被称作关系的两个不变性，是由关系系统支持的。在之后学习建立关系数据库的过程中，会涉及如何用代码来实现这两个完整性约束。

2.9 设计一个数据库之一

• 这是一个简单的回顾和总结

我们先来小小地复习一下，前面我们详细地讲解了关于实体/联系模型的内容，从什么是实体和关系，到关系的数学定义，又通过如何识别一个元组这个关乎数据库生死存亡的问题，说明了各类键和完整性约束的重要性。在讲解的过程中，我们实际上已经大体构建起了一个学生选课管理系统的框架了，下面我们把它整理一下。

1. 学生选课管理系统有以下几类实体：学生，教师，课程，学院。实体有各自的属性和主键。
2. 实体之间的联系有以下几种：学生、教师参与课程，教师就职于学院。实体之间的联系也有各自的属性和主键。
3. 实体与实体之间的联系用关系表示，以上的内容可以表示为：
   Student (ID, Name, Age, Gender, YearofEnroll, Dept)
   Teacher (TeacherID, Name, Age, Gender, Major, Dept)
   Course (CourseID, Name, RoomID, StartTime, Duration)
   Department (Dept, Instructor, Office)
   Takes (CourseID, ID, Semester, Year, Grade)
   Teaches (CourseID, TeacherID, Capacity)
   Works (TeacherID, Dept, YearofWorking)

请牢记这一页的内容，我们建立数据库的基础就在于此。

• 实体/联系图

我们已经通过文字的形式将学生选课管理系统的各个要素表示出来了，但是这样的方式仍然不够直观，不能清楚明了地反映实体之间的联系。这里我们就要给大家介绍另一个利器，实体/联系图（Entity/Relation Diagram），简称 E/R 图。
在 E/R 图中，我们使用不同的图形来表示实体、实体间的联系、属性等内容，通过图形间的连线确定它们的对应关系。

• 实体和属性的表示方法

我们用方角矩形表示实体，方角矩形框内是实体的名称。

用特殊的圆边矩形来表示属性，由于属性是隶属于实体或实体间的联系的，所以我们用直线将属性与其对应的内容连接起来。

在图上我们可以看到，有一个属性是加了下划线的。没错，这就是我们表示主键的方法。

2.10 E/R图初步

• 实体和属性的E/R图
  

2.11 设计一个数据库之二

• 别忘了还有实体之间的联系
  

实体及其属性我们已经会表示了，但是别忘了还有实体之间的联系。在 E/R 图中，我们用菱形来表示实体之间的关系。
很显然实体之间的关系是不能单独出现的，它的存在必然伴随着一对实体。图中为了演示方便，我们把实体的属性省略掉了。

• 实体之间的联系完整版

我们知道实体间的联系也是有它本身的属性的，它的属性同样也用特殊的圆边矩形表示。与实体属性不同的是，我们在表示关系的属性时，只写出它独有的属性，如果它的属性在与它连接的实体之中已经出现过，我们就忽略掉这个属性。因此，上图的完整形态应该是这样的：

• 实体之间联系的属性

从图中我们可以看到，Takes 中的属性 ID 和 CourseID，在学生和课程实体之中已经出现过了，所以在标明属性的时候就没有列出来。为什么我们要这样做呢？因为一般来说，实体和实体之间联系的主键是两个实体主键的并集，同时两个实体的一些非键属性也会被继承，这些属性我们已经在各自实体中明确表示出来了。所以在表示实体与实体之间联系的属性时，只列出由于联系而产生的属性，也就是它独有的属性。

2.12 教师与课程发生了什么关系？

2.13 学生上课，教授授课

2.14 设计一个数据库之三

• 实体之间联系是有对应关系的
  在现实生活中，实体和实体之间的联系也是有区别的。比如对于仓库和零件来说，它们之间有存放的联系，但是一个仓库可以存放多个零件，一个零件却只能在一个仓库存放；一个学生可以选择多门课程，一门课程也可能被多个学生选择。这种数目的对应关系也是值得我们关注的。那么在我们的学生选课管理系统中，这种对应关系是什么样的呢？
  
  
  

2.15 “一对一”的表示方法

2.16 设计一个数据库之进阶

• 实体之间联系的细化
  
  
  同样的，我们如果要求一门课必须有 2020 到 3030 人参加，学生与课程之间的多对多联系可以表示为：
  
  其中，*∗ 表示正无穷，在上图中表示一个学生理论上来说可以选择无数门课程。如果我们限制一个学生一学期至少选择 55 门课，最多选择 2020 门课，那么连接 Course 和 Takes 的直线上应该标注 5...205...20。
  还有一对多的情况与上面是类似的，我们留在练习中做好了，下面我们再介绍一个设计数据库的进阶方法。

2.16 设计一个数据库之进阶

• ISA 联系
  学过 C++ 的同学应该知道，C++ 里面有一项我们经常用到的神奇技能——继承。我们有一个父类名叫学生，它有学号、姓名、年龄、性别、年级等属性。它有两个子类，本科生和研究生。根据 父债子还 继承的原则，它已有的属性都会被继承，另外本科生还有其他诸如学院的属性，研究生还有研究方向、导师信息等属性等。这时候，我们就可以使用 ISA（is a）联系来表示，在 E/R 图中，是这样的：
  
  ISA 联系用三角形表示，三角形的“尖”连接着的是父类，底部连接的是继承属性的子类。注意，ISA 联系是没有属性的，它只用来表示父类和子类的继承关系。在列举属性的时候，父类中已经出现的属性，在子类中不必重复列出，只列出子类特有的属性即可。

  2.17 数据库设计终极练习 Part1

  

  2.18 做数据库也是要讲规矩的 —— 规范化

• 函数依赖
  
  
• 把函数依赖传递下去
  
• 1NF和2NF
  
• 3NF
  

• BCNF
  

• 各类范式之间的层级关系
  

  2.19 数据库设计终极练习-Part2