下载掌阅APP，畅读海量书库
立即打开
一个不合理的数据库逻辑设计可能会导致数据冗余、信息内容无效、数据不一致、更新异常、插入异常、删除异常等问题。产生这些问题的原因以及消除的方法都与数据依赖的概念有紧密联系。
关系模型中各属性之间相互依赖、相互制约的关系就成为数据依赖。数据依赖是可以作为关系模式的取值的任何一个关系所必须满足的一种约束条件，是通过一个关系中数据间值的相等与否体现出来的相互关系。它一般可分为函数依赖、多值依赖和连接依赖。
（1）函数依赖。函数依赖是最常接触到的，本节会对此概念进行详细讲解。
（2）多值依赖。在关系模式中，函数依赖不能表示属性值之间的一对多联系，虽然有些属性值之间没有直接关系，但存在间接的关系。把没有直接联系但有间接的联系的属性值称为多值依赖的数据依赖。
例如，书店网站的用户和图书之间没有直接联系，但用户和图书可通过订单或网购书籍的行为产生联系。又如，有这样一个关系（仓库管理员，仓库号，库存产品号），假设一个产品只能放到一个仓库中，但是一个仓库可以有若干个管理员，那么对应于一个（仓库管理员，库存产品）有一个仓库号，而实际上，这个仓库号只与库存产品号有关，与管理员无关，这就是多值依赖。
多值依赖属第四范式的定义范围，比函数依赖要复杂得多。
（3）连接依赖。连接依赖是多值依赖的推广。简单举例来说，设有供应关系PBO ｛P＃，B＃，O＃｝，其中P＃、B＃和O＃分别表示出版社编号、图书编号和订单编号。令PB ＝ ｛P＃，B＃｝、BO ＝ ｛B＃，O＃｝和OP ＝ ｛O＃，P＃｝，则有连接依赖（PB，BO，OP）在PBO上成立。
因此，多值依赖是模式的无损分解集合中只有两个分解元素的连接依赖，是连接依赖的特例。连接依赖属第五范式的定义范围。
由于本书只着重讲解第一、第二和第三范式，以下只对函数依赖适当展开讨论，关于多值依赖和连接依赖的相关详细内容可根据需要参考其他书籍。
（1）函数依赖的概念。函数依赖是指同一关系中各属性或属性组之间的相互依赖关系，类似于变量之间的单值函数关系，它是最重要的数据依赖，也是关系规范化的理论基础。
函数依赖的定义为：对于 X 的每一个具体值， Y 都有唯一的具体值与之对应，则称 Y 函数依赖于 X ，或 X 函数决定 Y ， X 称为决定因素。
其中，如果 X→Y 且 Y 不是 X 的子集，则称 X→Y 是非平凡的函数依赖；如果 Y 是 X 的子集，则称 X→Y 是平凡的函数依赖。
【例2-23】 在书籍信息（书籍编号，ISBN，书名，作者，出版社编号，出版日期，页数，版本，分类编号，库存数量，价格，折扣价）中，书籍的“书籍编号”确定了，其“书名”“作者”等就随之确定了。因而称“书籍编号”是决定因素，它“函数决定”了“书名”等属性的内容，而“书名”等内容则“函数依赖”于“书籍编号”。
在函数依赖 X→Y 中，从 X 的值应该知道与之对应的唯一 Y 值，但若 X 不含主键，就会产生各种问题。在一个关系中，不可能存在两个不同的元组在主键属性上取值一样，也不可能存在主键或主键的一部分为空值的元组。若某关系模型的属性间有函数依赖 X→Y ，而 X 又不包含主键，那么在具有相同 X 值的所有元组中， Y 值就会不断地重复，导致数据冗余的出现，随之而来的是更新异常的问题；若某个 X 值与某个特定的 Y 值相联系，由于 X 不含主键，这种 X 与 Y 相联系的信息可能会因为主键或主键的部分值为空而不能作为一个合法的记录在数据库存在，从而导致出现插入异常和删除异常的问题。
（2）函数依赖的类型。函数依赖的类型主要有完全函数依赖、部分函数依赖以及传递函数依赖三种。
设 X→Y 是关系模型的一个函数依赖，如果存在 X 的真子集 X ＇，使 X ＇→ Y 成立，则称 Y 部分依赖于 X ，否则称 Y 完全依赖于 X 。
一般来说，部分函数依赖只有当决定因子是组合属性时才有意义，当决定因子是单属性时就只能是完全函数依赖。
【例2-24】 在订单信息（订单号，书籍编号，书名）中，主键为订单号和书籍编号，则有函数依赖关系：书籍编号→书名，而“书籍编号”只是主键（订单号，书籍编号）中的一部分，因而发生了部分函数依赖。
传递函数依赖的定义为：在同一关系模型中，如果存在非平凡的函数依赖 X→Y 、 Y→Z ，而不存在 Y→X ，则称 Z 传递依赖于 X 。
【例2-25】 在关系（书籍编号，书名，作者，作者简介）中，有如下函数依赖：书籍编号→书名、书名→作者、作者→作者简介，所以“作者简介”传递依赖于“书籍编号”。
在关系数据库的设计过程中，对于同一个问题，选用不同的关系模式，其性能的优劣是大不相同的，为了区分关系模式的优劣，人们常常把关系模式分为各种不同等级的范式（Normal Form，NF）。所谓范式，就是关系模型要满足的一定条件，此约束已经形成了规范。满足这些规范的数据库的结构会更加简洁明晰，避免或减少了各种操作异常，反之不仅会给数据库的编程人员制造麻烦，而且可能导致数据库存储了大量的冗余信息。如果一个系统在数据库设计阶段没有规范化，在使用和维护阶段就会后患无穷。
目前关系数据库分成六个等级：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴德斯科范式（BCNF）、第四范式（4NF）和第五范式（5NF，又称完美范式）。各种范式呈递次规范，一级比一级要求得严格，越高的范式数据库冗余越少，而且规则是要累加的，如要满足第三范式就必须要先满足第一范式和第二范式。
关系规范化就是一个将低级范式转换为若干个高级范式的过程，一般来说，数据库的规范化在实用中达到三级范式就可以了。
第一范式，即每个属性值都是不可再分的最小数据单位。关系模型的最低要求是元组的每个分量必须是不可再分的数据项，这是最基本的规范化。数据库理论研究的都是规范化关系，其他不是第一范式的关系被称为非规范化关系。
【例2-26】 判断下面哪一张表符合第一范式。
订单信息＿1
订单信息＿2
明显，订单信息＿2才符合第一范式，每个属性值都是不可再分的数据项。
第二范式，即在第一范式的基础上进一步增加规则，规定关系的每一个非主属性完全依赖于主键。第二范式就是不允许关系模型的属性之间有这样的函数依赖 X→Y ，其中 X 是主键的真子集， Y 是非主属性，也就是不允许有非主属性对主键的部分函数依赖。
【例2-27】 用户列表（用户号，账号，密码，姓名，性别，地址，邮编，电话，Email）中“账号”和“姓名”不允许重名。判断其是否符合第二范式。
分析该关系模式可知候选键是“用户号”或“账号”，其他为非主属性，因此可以选择“账号”作为主键。关系模式存在以下的函数依赖关系：账号→ （密码，姓名，性别，地址，邮编，电话，Email）、用户编号→ （账号，密码，姓名，性别，地址，邮编，电话，Email），不存在非主属性对关键字的部分函数依赖，属于第二范式。
通常分解为第二范式的方法：
（1）把关系模式中对主键完全函数依赖的非主属性与决定它们的主键放在一个关系模式中。
（2）把对主键部分函数依赖的非主属性和决定它们的主属性放在一个关系模式中。
（3）检查分解后的新模式，如果仍不是2NF，则继续按照前面的方法进行分解，直到达到要求。
【例2-28】 订单信息（订单号，书籍编号，书名，作者，出版日期，出版社名称，出版社地址，出版社电话，价格，下单时间，数量）是否符合第二范式？如不符合，试将其分解以符合第二范式。
分析该关系模式，可知主键为复合键，即“订单号”和“书籍编号”。但它并不符合第二范式，因为“书名”“作者”“出版日期”“出版社名称”“出版社地址”“出版社电话”“价格”等与主键是部分函数依赖，即只依赖于“书籍编号”。
若要按第二范式分解，应该分解为：书籍（书籍编号，书名，作者，出版日期，出版社名称，出版社地址，出版社电话，价格），订单（订单号，书籍编号，下单时间，数量）。
按第二范式分解后形成的关系模式解决了第一范式中存在的非主属性对主键的部分函数依赖，规范化程度更高了一点，但有时还会存在问题。如以分解后得到的关系“书籍”来说，还存在数据存储冗余、插入异常、更新异常、删除异常等问题。
（1）数据冗余。由于出版社名称→ （出版社地址、出版社电话）的存在会使关系模式存在数据冗余，例如该关系中有50本北京电子工业出版社的书，那么“出版社地址”“出版社电话”属性的值将会有50个都是相同的。
（2）插入异常。如果目前该关系中还没有清华大学出版社的书籍，那么有关清华大学出版社的地址和电话信息也无法保存。
（3）更新异常。当更换出版社的电话时，需要修改多个元组的“出版社电话”的值。
（4）删除异常。当需要删除某个出版社的信息时，会同时删除所有这个出版社的书籍信息。
原因在于在这个关系中，还有一个非主属性对关键字的传递函数依赖存在。要解决这些问题需要进一步对这个关系进行第三范式的规范化。
第三范式，即在第二范式的基础上进一步增加规则，规定每一个非主属性都不传递依赖于某个候选键。
第三范式就是不允许关系模型的属性之间有这样的非平凡函数依赖 X→Y ，其中 X 不包含键， Y 是非主属性。 X 不包含键有两种情形：一种是 X 是主键的真子集，这是第二范式所不允许的；另外一种是 X 不是主键的真子集，这是第三范式所不允许的。
【例2-29】 判断书籍信息（书籍编号，书名，作者，出版日期，出版社名称，出版社地址，出版社电话，价格）是否符合第三范式。
分析该关系模式，可判断并不符合第三范式，因为存在如下传递依赖关系：书籍编号→出版社名称，出版社名称→ （出版社地址，出版社电话）。
通常分解为第三范式的方法：
（1）把直接对主键函数依赖的非主属性与决定它们的主键放在一个关系模式中。
（2）把造成传递函数依赖的决定因素连同被它们决定的属性放在一个关系模式中。
（3）检查分解后的新模式，如果不是3NF，则继续按照前面的方法进行分解，直到达到要求。
若要按第三范式分解，应该分解为：书籍（书籍编号，书名，作者，出版日期，出版社名称，价格）、出版社（出版社名称，出版社地址，出版社电话）。
综上，可以总结出各范式间的关系，如图2-5所示。
图2-5 各范式之间的关系