三、数据库系统原理

三、数据库系统原理

• 这部分内容较重要，上午的综合题和下午的案例分析题和论文都可能涉及到与数据库相关的知识。
• 主要是数据库模式即分级模式，数据库的设计（涉及到ER模型、关系代数、元组演算、规范化理论，其中规范化理论和关系代数在上午题中每次都会出现），并发控制和数据库完整性约束（讲的较简单），分布式数据库、数据仓库与数据挖掘以及数据库较新的理念和应用（主要是下午的案例分析题和论文里面涉及到）。

---

3.1 数据库模式

• 三级模式——两级映射
  考试一般以选择题出现。这种设计属于层次型架构设计，以便更好的应用数据库，提高了整个体系的可维护性，灵活性。示意图如下：
  
  物理数据库：处于最底层，在系统或计算机上面的表现形式往往是文件。

  内模式：与物理层次的数据库直接关联，管的是如何去存储这一系列的数据。把数据存到物理的文件上要按什么格式来存储，如何去优化它。它的主要关注点在数据的存放。

  概念模式：其实就是平常用数据库时的表这一级别，数据库里面有很多表。相当于把数据分成了若干张表，是根据业务或应用划分出来的，表之间会有相应的关联。
  外模式：对应的是数据库里面的视图，它的应用让我们对这些数据的控制有了更进一步的手段，更加灵活的处置方式。

  比如在概念模式中的用户信息的表，包含用户的用户名等很多信息，在应用过程中，如果任何一个功能模块都能够直接去调用用户的所有的信息，这样显得不够安全；如果概念模式里面的表发生了变化，应用程序直接调用这些表，应用程序也要变。而加了外模式后，可以把原来的数据表处理之后形成相应的视图，比如登录时不用调很多信息，就把用户名和密码调出来形成一个视图给登录模块；内部处理时只调用用户的一些基本信息，不需要密码，就建一个不包含密码的视图。这就增加了安全性和灵活性。概念模式的表这一级发生变化，比如原来的所有用户信息都是一张表存储的，现在要把某个字段分成一个表，某个字段分成另一个表，也可通过视图把这些表整合起来，选择表里面的哪些列组成一个视图，这样就增加了灵活性。

  外模式——概念模式映射：把表通过相应的操作得到视图， 其实是表和视图之间有一种映射关系。如果数据库的表发生变化时只要改映射不需要改应用程序。

  概念模式——内模式映射：主要是内部存储机制和表的情况之间的一种映射关系。存储的结构改变之后，只调整这种映射关系，不需要修改用户的应用程序。

  注： 内模式层次对应的是物理级数据库。概念层次对应的是概念级数据库。用户的应用程序这个层次对应的是用户级数据库。

3.2 数据库设计

• 数据库的设计过程
  主要了解数据库整个设计过程的流程，并掌握每个阶段不同的产物。数据库整个设计流程如图：
  
  1.需求分析：就是看整个系统对数据部分有什么要求，有从用户那里收集来的，还有转换过程中产生的一些需求（比如一些关联性需求）。严格来讲，需求分析是属于上一个需求阶段的任务，数据库设计具体来讲是从概念结构设计算起。

  阶段产物：数据流图、数据字典、需求说明书。

  2.概念结构设计：主要是做 E-R 模型，它与数据库管理系统无关，一般在 E-R 模型这一层次往往与物理数据库还没有直接的关系。只是数据的一种表达，看数据实体的属性及其之间的联系。

  阶段产物：E-R 模型。

  3.逻辑结构设计：把 E-R 模型转成关系模式。（它的基本流程就是转成文字表达的一个一个表的形式，在转换过程会用到规范化理论等知识，这都在后面会讲到。）

  阶段产物：关系模式。

  4.物理设计：把 DBMS 即数据库的一些特性加入进来。比如不同的数据库管理系统设计时要考虑到它们之间类型的细小差异，还有一些约束差异等。这就是数据库的物理层次的设计。

• E-R 模型
  E-R 图示例如下：
  
  以矩形方框表示实体，椭圆表示属性，菱形表示联系。在上面的图中，学生这一个实体包含学号、姓名、性别、年龄4个属性；课程这个实体也包含了课程号、课程名、任课教师3个属性；学生和课程之间有一层联系就是选课，学生与课程之间是多对多的关系，就是一个学生可以选多个（N）课程，一个课程可以供多个（M）学生来选择。

  E-R 模型的设计：相应 E-R 模型的设计过程中，要分析每一个局部的 E-R 图如何绘制及相应的建模设计，一个大的系统如果从整体一次性来绘制 E-R 图，难度和风险较高，一般都是先画局部的，最后再集成整个的 E-R 图。

  • E-R 图集成的方法：
    （1）多个局部 E-R 图一次集成；
    （2）逐步集成，用累加的方式一次集成两个局部 E-R 图。简单不易错但耗时。

  • E-R 图集成产生的冲突：
    （1）属性冲突：包括属性域冲突和属性取值冲突；
    （2）命名冲突：包括同名异义和异名同义；
    （3）结构冲突：包括同一对象在不同应用中具有不同的抽象，以及同一实体在不同局部 E-R 图中所包含的属性个数和排列次序不完全相同。

  E-R 模型转关系模式

  基本原则：
  1. 一个实体型转换为一个关系模式，有一对一、一对多、多对多的联系。不同的联系转关系模式也不同。

  一对一：两个一对一的实体分别转成两个关系模式，它们之间的联系可以单独转成一个关系模式，也可以合并到与之关联的任一实体中记录下来。这样最少能转成2个关系模式，最多3个。

  一对多：每一个实体还是转成一个关系模式，可以单独把它们之间的联系转成一个关系模式，也可把联系记录到多（N）对应的实体中。这样最少还是能转成2个关系模式，最多也是3个。

  多对多：每一个实体还是转成一个关系模式，它们之间的联系必须转成一个关系模式。这种最少转成3个关系模式。

  2. 三个以上实体间的一个多元联系。每一个实体还是转成一个关系模式，一个多元联系就必须转成一个关系模式。

  实例： 在数据库逻辑结构的设计中，将 E-R 模型转换为关系模型应遵循相关规则。对于三个不同实体集和它们之间的多对多联系 m : n : p如下图，最少可转换为 4 个关系模式。
  
  3个实体转成3个关系模式，1个联系转成1个关系模式，最少共转成 4 个关系模式。

• 关系代数
  主要是在上午题中考察。一般是给一个关系表达式，找出与之等价的关系表达式；还有给出一个业务场景，要实现什么职能，写出相应的关系表达式。

  基本运算：包含并、交、差、笛卡尔积、投影、选择、联接。其中并、交、差是非常典型的集和运算，考察的主要是后面几个，特别是笛卡尔积和联接间的差异（找等价的主要就是这两种表达形式）。

  并 ：把两个集和的内容并到一起，重复的数据的只显示一次。（符号∪）
  交：把公共部分找出来形成一个新的关系。（符号∩）
  差：就是我有的你没有，在第一个集和里去掉两个的公共部分。（符号–）

  例如：
  笛卡尔积：S1$\times$S2，结果中前面的字段是 S1 的字段，后面是 S2 的字段，S1 中的每一条记录和 S2 的每一条记录组合形成结果中新的记录。结果集属性个数是参与操作的两个关系的属性数之和，记录数是两个的记录数之积。（符号 $\times$）

  投影：对关系表中的哪个属性做了投影（选择指定列），结果集中就只有这个字段的内容。（符号 π）

  选择：根据指定的记录的属性值选的是记录和行。（符号 σ）
  注： 投影和选择在写属性名时也可写成数字编码代号。比如下图中的 π_1,2(S1)，σ_1=No0003(S1)。

  例如：
  
  联接：把 S1、S2 共有的字段保留一个，如果在 ▷◁ 下面没有写条件就是自然联接，默认就是相同的字段，比如下图中的也可在 ▷◁ 下面写 S1.Sno = S2.Sno 。（符号 ▷◁）

  例如：
  

• 规范化理论
  函数依赖是规范化理论的基础知识，在后面都会用到。

  1.函数依赖：数学上面的函数中给定一个 x ，就能确定唯一一个 y 的值，这就是函数依赖。在数据库体系中，如在学生信息数据表中一个学号就唯一确定一个姓名，这也是函数依赖，能从学号确定姓名，反过来一般不行，因为姓名有可能同名。
  函数依赖两种特殊形式：
  在后面范式部分都会用到，如下：
  
  部分函数依赖：部分体现在主键是两个属性（A，B）的组合键，主键中的一部分（A）可以确定某一个属性（C），这就是部分函数依赖。
  传递函数依赖：A可以确定B，B可以确定C，那么A就能够确定C，但B不能确定A。

  2.价值与用途
  非规范化的关系模式，可能存在的问题包括：数据冗余更新异常、插入异常、删除异常。 如图中的计算机系就是冗余数据，D01 系号决定了系名，多个记录就记录了多遍计算机系，这是不必要的，位置几号楼也是能根据系号确定的，多次存储记录也是不必要的，这就存在着严重的数据冗余问题；更新异常，就是把前面两个计算机系改成计算机科学系，第三个没有改，就会出现更新异常问题；还有插入异常、删除异常在后面会详细讲到。

  规范化理论的价值与用途：主要是解决这些问题。而规范化理论本身也有许多问题，所以后面还有反规范化理论。

  3.键
  要知道什么是候选键，怎么求候选键，候选键与主键的关系，外键怎么求。重点是求候选键的问题。

  超键：能唯一标识元组的键。可以是单个属性，也可以是多个属性的组合。
  候选键：也是唯一标识元组的键，但是它不存在冗余的属性。超键消除了它的多余的属性就成了候选键。
  主键：候选键可以有多个，在候选键中任选一个就是主键，但主键只能有一个。
  外键：是别的关系的主键，很多时候在对表做关联时用到。（比如一个员工表通过部门号与部门表关联，这个部门号对于员工表就是外键）
  
  求候选键——图示法
  （1）将关系模式的函数依赖关系用 “有向图” 的方式表示；
  （2）找入度为0的属性，并以该属性集和为起点，尝试遍历有向图。若能正常遍历图中所有结点，则该属性集即为关系模式的候选键；
  （3）若入度为0的属性集不能遍历图中所有结点，则需要尝试性的将一些中间结点（既有入度，也有出度的结点）并入入度为0的属性集中，直至该集和能遍历所有结点，集和为候选键。

  实例：
  
  右边是对应的函数依赖关系的“有向图”的表示。

  例1中，有向图中只有 A1 的入度为0，从 A1 开始遍历可以遍历所有结点，所以 A1 就是所求的候选键。

  例2中，ABD–>E，在画“有向图”时是先把A、B、D汇聚成一个点，再指向 E ，不能3个都单独指向E，那就变成了 A–>E，B–>E，D–>E。 ABD 的组合键只能遍历到 H、G、E、F，C 只能遍历到 J、I。所以所求的候选键是 ABCD 的组合键。

  例3中，“有向图”中没有入度为0的结点，就看既有入度，也有出度的结点。只有 A 和 B ，再看从 A 可以遍历到 B、C，同样从 B 开始也可以遍历到 A、C。所以关系 R 的候选关键字为 A和B。

  4.范式
  这个知识点几乎是必考的，还要用到前面讲的函数依赖和候选键的内容。范式的基本结构如下：
  范式分为第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、BC范式（BCNF）等。范式级别越高，规范化程度也会越来越高，但是数据的密度会越小，提高范式级别的基本方式都是数据表的拆分，级别越高，拆分的越细，数据拆分的越细就又会出现性能的问题，所以一般会用较折中的方法，就是把范式做到第三范式左右就差不多了，不要求再深入。第一范式级别最低，其次是第二、第三；要达到第二范式，就必须达到第一范式，要达到第三范式，就必须达到第二范式，同理依次类推。

  原子值：这个属性不能再拆分几个属性。
  主属性：属于候选键的一部分。
  范式之间的关系：第一范式，属性值都是不可分的原子值。在第一范式的基础上消除非主属性对候选键的部分依赖关系就到了第二范式；在第二范式的基础上消除了非主属性对候选键的传递依赖关系就到了第三范式，第三范式消除主属性对候选键的传递依赖就到了 BC范式。

  注：范式级别越高，规范程度越高，就更可能解决插入异常、删除异常、数据冗余的问题。比如把数据表从第一范式规范到第二范式，解决了一些问题，但还是会存在这三个问题，继续规范到第三范式也还是可能会存在这三个问题，其实不同的范式规范了不同的情况，随着范式级别的提高，还是不能彻底解决这三个问题。只能是逐步优化。

  第一范式：在关系模式 R 中，当且仅当所有域只包含原子值，即每个分量都是不可再分的数据项，则称 R 是第一范式。

  例： 下表所示的关系 R 是否满足1 NF，如果不满足，应如何调整？

  
  去掉高级职称人数这个属性，教授和副教授就成了原子值。这样就成了第一范式。

  第二范式：当且仅当 R 是1 NF，且每个非主属性完全依赖主键（不存在部分依赖）时，则称 R 是第二范式。

  思考题： 请思考该关系模式会存在哪些问题（从数据冗余、。更新异常、插入异常、删除异常这几个方面来考虑），解决方案是什么？
  
  SNO 表示学号，CNO 是课程号，后面两个是成绩和学分。在这个数据表中，主键是学号和课程号的组合键。课程号单独就可以确定学分，而课程号又是主键的一部分，这就是部分依赖。这样就有问题了，比如学分为4的学分存了4次，这是不必要的，应该只存一次就可以了，这就是数据冗余；更新学分为4的记录时只更新了两个记录是不行的，要更新4条记录，更新时只更新一部分就会导致更新异常；现在如果要在表中插入课程号C08，学分6的新的课程，但如果这个课程还没有人选，就没有学号，因为表中的主键是学号和课程号的组合键，系统是不允许录入的，就不能插入，这就是插入异常；如果这些学生毕业了，就要删除他们的信息，但这样连学分信息也会删除，这就是删除异常。

  解决方案： 将课程号和学分这两个字段提取出来做一个新的关系模式，在原关系模式里去掉学分这一列。

  第三范式：当且仅当 R 是2NF，且E中没有非主属性传递依赖于码时，则称 R 是第三范式。

  思考题： 请思考该关系模式会存在哪些问题（从数据冗余、更新异常、插入异常、删除异常这几个方面考虑），解决方案是什么？
  
  主键只有 SNO 这一个属性，单属性是不可能有部分依赖的，这个表虽然已经达到第二范式，但是依旧还是存在一些问题。很明显表中计算机系和1号楼有重复多个，同上的思考题的分析过程还是会存在数据冗余、更新异常、插入异常、删除异常问题。

  解决方案： 将后面三个字段独立出来成为一个关系模式，原来的关系模式就只有前三个字段，这样就消除了传递依赖。

  BC 范式： 设 R 是一个关系模式，F 是它的依赖集，R 属于BCNF 当且仅当其中 F 中每个依赖的决定因素必定包含 R 的某各候选码（把所有函数依赖写出来，函数依赖的左边即决定因素必须是候选键）。

  例： 关系模式STJ（S,T,J）中，S 表示学生，T 表示老师，J 表示课程，每一老师只教一门课，每门课有若干老师，某一学生选定某门课，就对应一个固定老师。
  
  ST 和 SJ 都是候选键，没有非主属性，就是第三范式，函数依赖有 SJ–>T，T–>J。第二个函数依赖左边部分不是候选键，所以可以判断这不是 BCNF。

  例题：
  
  解： 选择答案：C、D、A。
  第一空中不属于第三范式的原因，一般只可能有两个，属于第二范式但不属于第三范式或者连第二范式都没达到，不可能是连第一范式都没达到，不然这题就不需要分析了。题目的部门关系中，单一的部门号是可以充当主键的，所以就不存在部分函数依赖。

  第二空意思是在1、2、3这三个表中加部门号或者职工号（1、2、3表中已有的属性字段）得到表4，现在职工号与部门号之间没有关联，而一般是多个职工对应一个部门，应该把这种联系保存在多个这一端，就是在职工表中加部门号。

  第三个空是还要加个关系模式销售，有了职工号就不需要再加部门号，因为在第二空中已经建立了它们之间的关系，所以排除 C、D；有了商品号可以查到商品名，如果再加商品名称就造成了数据冗余的问题，所以就选择 A。

  5.模式分解

  模式进行分解之后级别就提高了，需要注意分解的机制和原则，主要讲保持函数依赖分解和无损分解。

  保持函数依赖分解： 分解之前有哪些函数依赖，分解之后这些函数依赖还是不变。具体定义如下：
  
  例如：有函数模式 R（A，B，C），函数依赖有 A–>B，B–>C，把它分成两个关系模式，R1（A，B），R2（B，C）。这样分解是保持函数依赖的。R1 中包含属性 A，B，这就保持了 A–>B 的函数依赖；R2 中包含属性 B，C，这就保持了 B–>C 的函数依赖。两个函数依赖都被保存下来了，所以分解是保持函数依赖的。如果有冗余性质的函数依赖不必保留。

  无损分解： 无损是可以还原的，有损是无法还原的。无损联接分解：指的是将一个关系模式分解成若干个关系模式后，通过自然连接和投影等运算仍能还原成原来的关系模式。

  思考题如下：
  判别无损分解的方法： 列表法和公式法。

  判别无损分解的例题——列表法：
  
  构造初始表及相关操作： 初始表中第一行是原关系模式中的所有属性字段，第一列是拆分成的子关系模式，a 代表当前的关系模式中（子关系模式）有当前的属性（原关系模式），下标代表当前属性所在的列，例如：a₁ 表示拆分后的成绩关系模式拥有学号字段。b 代表当前关系模式没有包含当前字段，下标表示当前关系模式所在的行和当前属性所在的列，例如：b₁₂ 表示拆分后的成绩关系模式不包含姓名字段。

  根据每一个函数依赖对表进行更新：
  
  更新时，根据函数依赖就能通过其中左边的决定属性字段确定右边的属性字段。比如：通过学号能确定姓名，成绩表中有学号就能确定姓名，相当于成绩表中包含了姓名（联接）。处理完之后最终得到上图中的新表，表中只要有一行全部为a（说明把原来的表还原了），就表示模式分解是无损联接分解。

  判别无损分解的例题——公式法：
  这种方法局限性较强，只适合一分为二的情况。
  
  6.反规范化技术

  规范化的逆过程，提出规范化主要是因为数据表规范化程度不高就会有数据冗余、插入异常、修改异常这一系列问题。但规范化程度过高时又出现了新的问题，在规范化的过程中对表不断的拆分，导致数据表过多。这样虽然减少了数据冗余，提高了增、删、改的速度，但会增加查询的工作量（关联多表查询），影响系统性能。所以就提出了反规范化技术。

  技术手段：增加派生性冗余列、增加冗余列、重新组表、分割表。这些其实是对应的规范化技术的逆过程。反规范化技术的核心其实是以牺牲一些空间和规范程度为代价来提高查询的速度。

3.3 数据库的并发控制

• 了解事务的基本情况，并发是什么，并发过程中可能产生的问题，解决问题提出来的封锁协议，还有后面产生的死锁问题。
  

• 事务的基本概念
  把多个操作封装起来，把它看成一个整体来操作。由于很多操作之间有关联性，本身是一个整体，如果不一次性执行完就会产生一系列问题。所以就提出了这种机制，例如转账。要求事务当中的操作要么全做，要么全不做，以保持相应的正确的状态。它的特性如下：

  原子性：把这个事务看成一个原子值，不能再拆分来做。
  一致性：事务执行之前数据是保持一致的状态，执行之后也一致。
  隔离性：事务之间是独立进行，互不影响。
  持续性：事务执行之后结果的影响是持续的。

  事务是并行执行的前提，便于并行或并发的处理事情，提高操作的效率。

• 并发控制存在的问题
  
  丢失更新：并行执行：T1 读取A，T2 读取A；T1 写回A， T2 写回A。T1写回时就覆盖了A的值，所以得到A的结果是2，但实际是-3，这就产生了问题。

  不可重复读：重复读第二次时值已经变了。

  读 “脏” 数据：读到的结果值不是执行过程中应该产生的数据，而是临时值，没有起到真正作用的值。

  为了解决这些问题提出了封锁协议。

• 封锁协议
  一级封锁协议：事务T在修改数据R之间必须先对其加X锁，直到事务结束才释放。可防止丢失修改。（X锁是写锁，之上再不能加任何锁）

  二级封锁协议：一级封锁协议加上事务T在读取数据之前先对其加S锁，读完后即可释放S锁。可防止丢失修改和读“脏”数据。（S锁是读锁，之上只能加读锁）

  三级封锁协议：一级封锁协议加上事务T在读取数据R之间先对其加S锁，直到事务结束才释放。可防止丢失修改，读“脏”数据，数据重读。

  两段锁协议：可串行化的，可能发生死锁。有预防的方法，也可在死锁产生时加以甄别再进行解除处理。

3.4 数据库完整性约束和安全

• 数据库的完整性约束
  主要有如下三种：
  实体完整性约束：使用数据库时给数据表定义主键，约束的是主键，主键的值不能为空。

  参照完整性约束：与外键相关的完整性约束，填入的数据必须对应表中主键的内容，允许为空。

  用户自定义完整性约束：用户可以设置属性值的情况。

  完整性约束其实是提高数据可靠性的机制，如果数据有问题就不允许它录入进去，这三种只能应对简单的情况，复杂的不易应对。

  触发器：可以写脚本约束数据库的数据的要求，适用于复杂的情况。

• 数据库安全
  主要介绍数据库相关安全的措施，在后面还会详细讲到。在这只是与数据库相关的安全问题。
  

3.5 数据库备份与恢复

• 数据备份

  了解对常见的备份和稀释的优缺点及运作的方式。
  

• 数据库故障与恢复
  

3.6 数据仓库与数据挖掘

• 目前广泛应用于BI（商业智能）。

• 数据仓库
  数据库：根据业务的需求，处理哪项业务时要记录哪些数据，就把它记录下来。

  在使用过程中积累的历史数据会越来越多，这样会影响系统的性能，虽然对系统可能价值不大，但对企业决策而言是有价值的，所以又不能直接删除，对于这些数据的管理与普通业务系统也有较大差别，所以就提出了特殊的数据库即数据仓库专门用来保存这些数据。它的 特点 如下：

  面向主题：一般数据库按业务需求组织系统，数据仓库按主题组织（按类划分）。

  集成的：记录一些集成式的数据。

  相对稳定性（非易失的）：录入的数据就不再进行修改删除等操作。

  反映历史变化（随着时间变化）：隔一段时间会把一些新的数据录入。

  数据仓库建立的阶段如下：
  
  第一阶段就是在数据源里面抽取、清理、装载、刷新数据，清理就是做数据格式的统一和冗余数据的去除等；第二阶段是数据仓库，全局建立风险很高，所以就提出数据集市分期一步一步来先建部门级数据仓库，再整合成企业级数据仓库，这样就降低了风险。第三阶段就是 OLAP 服务器（联机分析处理服务器），专门做分析处理工作的，表层是数据的前端工具，比如查询工具、报表工具、分析工具、数据挖掘工具。

• 数据挖掘
  数据挖掘工具与查询工具是有区别的，比如在查询工具往往中有非常明确的目标去做的，而数据挖掘工具中就不是那么明确。因为数据挖掘可能会挖到人类未知的数据信息。

  数据挖掘方法分类
  方法：决策树、神经网络、遗传算法、关联规则挖掘算法。
  分类：

3.7 大数据

• 属于一项新的技术，其实是对一些海量数据处理的相关技术。

• 数据特点：数据量极大、要求处理的速度要快、数据多样性、价值密度低（大量数据有价值的少）。

• 了解与传统数据的区别：
  
  其中一个核心原因就是大数据的数据量极大，关系极其复杂。

  大数据处理系统应该具有的重要特征：高度可扩展性、高性能、高度容错、支持异构环境、较短的分析延迟、易用且开放的接口、较低成本、向下兼容性。要求高性能低成本，现在通常与云计算和虚拟化等技术结合起来利用一些闲置资源，提高资源的利用率。