数据库课堂笔记8 数据库设计理论

本章节主要讲解了以下方面

关系模式设计问题

问题需求的提出：假设我们要构建一个医院医生和病人记录的管理数据库模式，思考以下问题：

• 应该构造几个关系模式
• 每个关系模式会有哪些属性构成
  引入以下概念

关系模式的五元组表示： R(U, D, DOM, F)
- R：关系名
- U：组成该关系的属性名集合
- D：属性组U中属性所来自的域
- DOM：属性向域的映象集合
- F：属性间数据的依赖关系集合

更常用的，我们采用以下三元组模式
关系模式的简化三元组表示： R（U, F）

假设个医院医生和病人记录的管理数据库模式如下：

可以确定以下函数依赖：
F = { {Dname,Pname}→Fsum，
Dname→Dlevel，
Dlevel→Dsal }

可以观察到，该关系模式实例存在冗余现象，医生姓名和级别等重复存储较多，这不是一个良好的关系模式。
数据冗余一方面浪费空间，另一方面会引发异常。

• 插入异常：加入我们插入一个还没有患者到他那里就诊的新医生，患者信息等就会为控制，产生插入异常。
• 更新异常：假设某医生职位发生了变化，在更新时应该更新所有的该医生记录。且薪水也应该同步更新，否则就会引发更新异常。
• 删除异常：假设某医生退休或离职删除了该医生的所有记录，但是该医生所在职位上只有他一个人，则对应职位也会被删除，就会产生删除异常。

基于以上，我们可以将关系模式分解如下：
R1（Dname，Dlevel）
R2（Dlevel，Dsal）
R3（Dname，Pname，Fsum）

可以发现，该关系模式是良好的，不存在数据冗余现象。

函数依赖

在复习具体的模式分解前，回顾一下函数依赖。

• 函数依赖是指一个关系表中属性（列）之间的联系。
• 函数依赖关注一个属性或属性集与另外一个属性或属性集之间的依赖，亦即两个属性或属性集之间的约束。
• 函数依赖是关系中属性之间在语义上的关联特性。
• 数据库设计者根据对关系R中的属性的语义理解确定函数依赖，确定约束R的所有元组r的函数依赖集，并获知属性间的语义关联。
  这些都不重要，看看就行。
  符号说明如下
• R表示一个关系的模式；
• U＝{A1，A2，…，An}是R的所有属性的集合；
• F是R中函数依赖的集合；
• r是R所取的值；
• t[X]表示元组t在属性X上的取值。例如 t[Dname] = ‘杨勋’

平凡函数依赖

平凡函数依赖必然成立，它不反映新的语义。例如：{Dname,Pname}→{Pname}。
平常所指的函数依赖一般都指非平凡函数依赖。

完全函数依赖

属性集Y完全函数依赖于属性集X，如果满足下列条件：
Y函数依赖于X。
Y不函数依赖于X的任何真子集。

部分函数依赖

传递函数依赖

逻辑蕴含

函数依赖中需要解决的问题：从一些已知的函数依赖去判断另外一些函数依赖是否成立。
例如，如果A→B和B→C在某个关系中成立，记F={ A→B，B→C}，那么A→C在该关系中是否成立的问题称为逻辑蕴涵问题，若A→C成立，则说F逻辑蕴涵A→C，记作F╞ A→C。
如果一个函数依赖能够由集合中的其他函数推出，则该函数依赖是多余的。

函数闭包

函数依赖集的闭包（也成为完备集）定义了由给定函数依赖集所能推导出的所有函数依赖。
通过F得到F＋的算法可以由Armstrong公理推导出来。
无冗余的函数依赖集和函数依赖的完备集（闭包）是好的关系设计。
根据已知函数依赖集，推导其它函数依赖时所依据的规则称为推理规则。
Armstrong公理定义如下：

• 自反性
• 增广性
• 传递性
  拓展结论：
  
  求属性集闭包
  
  函数依赖集等价
  
  函数最小依赖集满足的条件：
  
  求函数的最小依赖集
  算法
  
  实例
  
  注意：每个FD至少存在一个Fmin ，但不一定唯一。

模式分解

了解一下模式分解的意义

• 由函数依赖可以引起的更新异常问题，同样，多值依赖和连接依赖也会引起类似的问题。解决这些问题的途径就是按照“一事一地”的原则，对关系模式进行分解，使之表达的语义概念单纯化。
• 关系模式R的分解就是用两个或两个以上关系来替换R，分解后的关系模式的属性集都是R中属性的子集，其并集与R的属性集相同。
• 模式分解帮助消除不良设计中的一些问题，如冗余、不一致或异常。

关系模式分解的两个特性实际上涉及两个数据库模式的等价问题，这种等价包括数据等价和依赖等价两个方面。
数据等价是指两个数据库实例应表示同样的信息内容，用“无损分解”衡量。如果是无损分解，那么对关系反复的投影和连接都不会丢失信息。
依赖等价是指两个数据库模式应有相同的依赖集闭包。在依赖集闭包相等情况下，数据的语义是不会出错的。
违反数据等价或依赖等价的分解很难说是一个很好的设计模式。
但是要同时达到无损分解和保持函数依赖的分解也不是一件容易的事情，需要认真对待。

无损分解

一个关系表被分解成两个或两个以上的小表，通过连接被分解后的小表可以获得原始表的内容，则称为无损连接分解。
例如：将R（X，Y，Z）分解成R1（X，Y）和R2（X，Z），如果X是R1和R2的共同属性或属性集，且存在函数依赖集F={X→Y，X→Z}，则该分解是无损的。

无损分解测试算法：Chase追逐法

Chase是一个普遍的算法，无论一个关系模式分解为多少个关系模式，都可以用此算法进行检验。
如果一个关系模式一分为二，可以简化检验。

例如

综上
所有的模式分解必须是无损的。
无损连接分解总是关于特定函数依赖集F定义的。
模式分解能消除数据冗余和操作异常现象。
但是分解以后，检索操作需要做笛卡尔积或连接操作，这将付出时间代价。
一般认为，为了消除冗余和异常现象，对模式进行分解是值得的。

保持函数依赖

模式分解的另一个特性是分解的过程中能否保持函数依赖集，如果不能保持函数依赖，那么数据的语义就会出现混乱。
模式分解要保持函数依赖，因为函数依赖集F中的每一个函数依赖都代表数据库的一个约束。
如果某个分解能保持函数依赖集，那么在数据输入或更新时，只要每个关系模式本身的函数依赖约束被满足，就可以确保整个数据库中的语义完整性不被破坏。显然这是一种良好的特性。

例如
设医生关系模式R（Dno，Dlevel，Dsal）。假设每个医生只有一个职称级别，每个职称级别只有一个工资数目。那么R上函数依赖集F={Dno→Dlevel，Dlevel→Dsal}。
如果将R分解成ρ={R1(Dno,Dlevel)，R2(Dno,Dsal)}，可以验证这个分解是无损分解。
R1上的函数依赖是F1={Dno→Dlevel}，R2上的函数依赖是F2={Dno→Dsal}。但是从这两个函数依赖推导不出在R上成立的函数依赖Dno→Dsal。因此分解ρ把函数依赖Dno→Dsal丢失了，即ρ不保持F。

规范化

范式（Normal Forma，NF）是一种关系的状态，也是衡量关系模式好坏的标准。
范式的种类（ 1NF，2NF，3NF，BCNF ）与数据依赖有着直接的联系。在关系模式中存在函数依赖时就有可能存在数据冗余，引出数据操作异常现象。
例如：就诊关系模式R（Dname，Dlevel，Dsal，Pname，Fsum）不是一个好的设计，因为存在冗余信息（重复存储的职称和工资）。数据冗余不仅浪费存储空间，而且会使数据库难以保持数据的一致性。
范式可以用于确保数据库模式中没有各种类型的异常和不一致性。为了确定一个特定关系是否符合范式要求，需要检查关系中属性间的函数依赖，而不是检查关系中的当前实例。

1NF

• 定义：在关系模式R的每个关系r中，如果每个属性值都是不可再分的原子值，那么称R是第一范式（1NF）的模式。
• 1NF不允许每个元组的每个属性对应一组值、一行值或两个值的组合。简单地说，1NF中不允许出现“表中有表”的现象。
• 1NF是关系模式应具有的最起码的条件。满足1NF的关系称为规范化的关系；否则称为非规范化的关系。关系数据库研究的关系都是规范化的关系。

2NF

• 定义： 如果关系模式R∈1NF，且每个非主属性（不是组成候选码的属性）完全函数依赖于候选码，那么称R属于2NF的模式。
• 2NF是基于完全函数依赖的，只有在主键是复合属性下才可能不符合2NF。
• 2NF是通往更高范式的中间步骤，它消除了1NF存在的部分问题。

2NF分解算法：将关系模式R分解成2NF模式子集
设有关系模式R(U)，主键是W，R上还存在函数依赖X→Z，其中Z是非主属性和X    W，则W→Z就是一个局部依赖。此时应该把R分解成两个模式：
① R1（XZ），主键是X；
② R2（U-Z），主键仍为W，外键是X（参考R1）。
利用外键和主键的连接可以从R1和R2重新得到R。
如果R1和R2还不是2NF，则重复上述过程，一直到数据库模式中每一个关系模式都是2NF为止。

3NF

• 定义：如果关系模式R∈1NF，且每个非主属性都不传递依赖于R的候选码，那么称R属于3NF的模式。
• 在3NF中，关系模式是由主键和一组相互独立的非主属性组成的，它满足两个条件：
  （1）R中的非主属性相互独立；
  （2）R中的非主属性函数依赖于主键。

3NF分解算法： 将关系模式R分解为3NF模式集。
设关系模式R（U），主键是W，R上还存在FD X→Z，其中Z是非主属性，     且X不是候选键，这样W→Z就是一个传递依赖。此时应把R分解成两个模式：
① R1（XZ），主键是X；
② R2（U -Z ），主键仍是W，外键是X（参考R1）。
利用外键和主键相匹配机制，R1和R2通过连接可以重新得到R。
如果R1和R2还不是3NF，则重复上述过程，一直到数据库模式中每一个关系模式都是3NF为止。

举例：
R1（Dno，Dlevel，Dsal）上存在Dno→Dlevel和Dlevel→Dsal，则Dno →Dsal为传递函数依赖
分解为：R11（Dno，Dlevel）和R12（Dlevel，Dsal）

定理：如果R是3NF模式，那么R也是2NF模式。
局部依赖和传递依赖是关系模式产生数据冗余和异常的两个重要原因。
由于3NF模式中不存在非主属性对候选键的局部依赖和传递依赖，因此3NF消除了很大一部分存储异常，具有较好的性能。
而对于非1NF、1NF和2NF的关系模式，由于它们的性能较差，通常不宜作为数据库模式，需要将这些关系模式变换为3NF或更高级的范式。这种变换过程称为“关系的规范化处理”。

BCNF

在3NF模式中，并未排除主属性对候选键的传递依赖，因此有必要提出更高一级的范式。

• BCNF定义：如果关系模式R∈1NF，且每个属性都不传递依赖于R的候选码，那么称R是BCNF的模式。
• 由BCNF的定义可以得到以下结论，一个满足BCNF的关系模式有：
  所有非主属性对每一个码都是完全函数依赖。
  所有的主属性对每一个不包含它的码，也是完全函数依赖。
  没有任何属性完全函数依赖于非码的任何一组属性。

BCNF分解算法：将R无损分解且保持依赖地分解成3NF模式集。
① 对于关系模式R和R上成立的FD集F，先求出F的最小依赖集，然后再把最小依赖集中那些左部相同的FD用合并性合并起来。
② 对最小依赖集中每个FD X→Y去构成一个模式(XY)。
③ 在构成的模式集中，如果每个模式都不包含R的候选码，那么把候选码作为一个模式放入模式集中。
举例：
设关系模式R（ABCDE），R的最小依赖集为{A→B，C→D}。从依赖集可知R的候选码为ACE。
先根据最小依赖集，可知ρ={AB,CD}。然后再加入由候选码组成的模式ACE。因此最后结果ρ={AB,CD,ACE}是一个3NF模式集，R相对于该依赖集是无损分解且保持函数依赖。

一个数据库模式中的关系模式如果都属于BCNF，那么在函数依赖范畴内，它已实现了彻底的分离，已消除了插入和删除的异常。
3NF的“不彻底性”表现在可能存在主属性对码的部分依赖和传递依赖。

几个范式的递进如下：