数据库原理及MySQL应用 | 关系规范化

各位看官，各位朋友，久等了，终于有时间更新了 ！

当关系数据库的数据模式设计存在不合理之处时，则会导致数据冗余现象的产生，并进而引发操作异常。通过对其范式进行优化处理，在确保数据冗余度最小化的同时也能提升系统的运行效率。

01、第一范式

第一范式也被称为1NF 是数据库设计中的基础规范具体来说就是一个二维表格如果满足1NF它才能被称为关系。

当关系模式R的所有属性均为原子型时（即每个属性对应的域中的元素均为不可分割的基本单位），则称其为处于第一范式中，并表示为R∈1NF。

如图1所示的二维表格结构中，在order_id（orderid）、order_date（orderdate）、book_id（bookid）、title（title）、quantity（quantity）、category_code（ctgcode）和category_name（ctgname）这些字段中，
对于每一行数据而言可能会存在多个值的情况，
这意味着这些字段中的数据不具备原子性，
导致该结构形成了嵌套的数据表，
因此该二维表格结构不符合第一范式的要求，
不能存放在关系数据库中。

■ 表1 图书销售表booksale

对该二维表格进行规范化处理，可以得到表2所示的满足第一范式的关系。

■ 表2满足第一范式的图书销售关系booksale

通过对表2所示的关系分析可知，数据之间存在如下联系：

(1) 每位顾客可以拥有多张订单，每张订单只属于一位顾客。

(2) 每张订单里可以包含多册图书，每册图书也可以被包含在多张订单里。

(3) 每册图书属于一个类别，每个类别下可以有多册图书。

在这一数据模型中，在每一个由ordered_id和book_id属性共同组成的元组中都有一个唯一的图书销售记录与之对应。因此可以将(ordered_id, book_id)视为该数据模型中的一个候选键。在本模型中(ordered_id, book_id)是唯一确定的候选键，在这里我们可将其定义为主键字段。因此该数据模型的关系模式就可以表示为：

    Booksale (cstid, cstname, orderid, orderdate, bookid, title, quantity, ctgcode, ctgname)

02、操作异常问题

由于Booksale关系模式符合第一范式的要求，在实际应用中发现其具体实例中可能存在较多的数据冗余现象。这种冗余不仅会导致占用更多的存储空间，并且在执行插入、更新、删除等操作时可能会导致操作异常发生进而引发数据不一致性问题出现。

1. 插入异常

如果一位顾客希望申请会员身份，则需要满足一定的条件和要求。然而，在当前系统中由于该记录缺少主键字段这一必要信息项的存在导致该顾客的信息无法被成功插入到此关系中。换句话说，在这种情况下需要插入到关系中的记录也无法成功完成其相应的插入操作。

为了将booksale关系的数据分别存储在表2-22至表2-17这五个子表格中（每个子表格对应一个特定的关系），这样可以让会员信息得以插入到customers关系中以解决因无法直接向customers关系插入而导致的问题。

对应的关系模式为：

 Customers (cstid, cstname)

    
 Orders (orderid, orderdate, cstid［FK］)
    
 Books (bookid, title, ctgcode［FK］)
    
 Categories (ctgcode, ctgname)
    
 Orderitems (orderid［FK］, bookid［FK］, quantity)

2. 删除异常

在图书销售与顾客管理的booksale关系中，在oids=4这一特定订单记录被移除的情况下，“李明宇”这位顾客的信息也将随之消失。换言之，在这种操作下我们无法避免地会失去这位顾客的数据。

一旦将数据库的关系划分为五个较小的关系，则只需在orders表中进行相应的元组删减操作即可。这样处理后，并不会影响到客户数据的安全性，并且能够有效规避因删减操作而产生的异常情况。

3. 更新复杂

在对数据库进行数据更新操作时，在执行一次完整的事务操作之前，请确保所有相关的记录都已正确修改完毕。为了防止因事务冲突导致的数据不一致问题，在这种情况下尤其需要注意的是：如果只单独修改某一条记录而不影响其他相关联的数据项，则可能会导致后续处理出现问题。因此，在这种情况下特别需要注意的是：不仅必须同步修改该特定书籍的所有相关信息（title），而且还必须同步修改与之相关的其他属性值（如pub_date, category等）。只有这样处理后才能保证事务的整体一致性得到保障

如果将该关系划分为5个小范围，则对编号为10的图书名称进行修改操作时，仅需修改books表中的一个记录。这将确保在操作完成后，系统不会出现数据不一致的问题。

表 booksale及其通过分解而获得的五个子表均可用作存储相关数据的目的，并且每个子表都有其独特的优势和不足之处。

将关系booksale拆分为五个子关系后，在数据冗余和操作异常方面均能取得显著改善。然而这会使得数据查询的复杂性有所提升。例如在希望检索顾客‘张志远’购买的所有书籍信息时 若采用booksale这一子关系进行查询 则相应的代数表达式将更为简洁明了。

相同的查询操作，在对分解后的5个关系进行查询时，则必须先将这些关系连接起来后再执行查询。

因为连接运算在数据库操作中不仅会消耗大量系统资源而且其效率也极为低下。因此如果将关系模式划分得太细碎将会导致数据库在执行查询操作时表现出较低的性能水平性能。

03、函数依赖

该[函数]类型的依赖关系在数据库设计中扮演着核心角色。在对关系模式进行规范化处理的过程中，始终采用函数依赖作为分析对象来考察其存在的数据规律。

1. 函数依赖的概念

在关系模式R中定义了两个属性或属性组X和Y。当且仅当对于每个特定的x∈dom(X)，都存在唯一的y∈dom(Y)与之对应时，则存在函数依赖关系使得Y依函数依赖于X或者表示为函数决定关系式的形式，并通常用符号表示法写作 X \rightarrow Y 。其中称其为决定因素的因素就是关键制约因素。

当X \rightarrow Y且Y \subseteq X时，则称此函数依赖为平凡函数依赖；而当X \rightarrow Y且Y \nsubseteq X时，则称此函数依赖为非平凡的。此处我们关注的是非平凡的函数依赖关系。

在Booksale关系模式中，在属性cstid中的每一个具体值对应属性cstname中只有一个唯一值。因此可得出结论：即该函数决定关系模式中的主键字段对码字段之间的依赖关系为：主键字段→码字段（如：CSTID → CSTNAME）。反之则不然：由于可能存在顾客具有相同名称的情况，则码字段（如CSTNAME）无法反向决定主键字段（如CSTID），即对于属性CSTNAME中的一个值而言，在属性CSTID中可能对应多个数值。

。

在单笔订单中的一册图书具备固定的销量水平，在这种情况下，orderid与bookid的组合能够唯一确定quantity值，并以数学关系表示为：(orderid, bookid) → quantity

2. 部分函数依赖与完全函数依赖

我们称在关系模式R中，当属性集X函数决定属性Y时，在这种情况下若存在一个真子集X′（即至少少了一个属性），其对应函数依赖关系也成立，则说明属性Y的部分依赖关系存在于属性集X中，并被记作

；如果在X中找不到一个真子集X′，使得X′→Y成立，则称Y完全依赖于X。

在关系模式Booksale中

在函数依赖关系中，若属性集S是X的子集，则称X部分函数依赖于S。具体而言，在决定因素(order, book_id)这一集合中存在一个其子集（即book_id）即可通过该属性唯一确定价格。其对应的价格为：book_id → price。

在关系模式中，(orderid, bookid) → quantity 是一种完全函数依赖关系；其原因在于该决定因素集合中的任何真子集都无法单独函数决定 quantity。

3. 传递函数依赖

在关系模式R中，如果存在函数依赖X→Y，Y→Z，而

，则称Z传递依赖于X，记作。

在关系模式Booksale中，bookid→ctgcode，ctgcode→ctgname，而

，所以是一个传递函数依赖。

提示/

因为，在R上的部分函数依赖必然是传递函数依赖，在这种情况下，则必定没有传递函数依赖存在时, 也就意味着没有部分函数依赖存在

04、第二范式

包含在主键中的属性称为主属性；不包含在主键中的属性称为非主属性。

当关系模式R归类于第一范式（1NF），并且所有非主键字段都完全依赖其主键时，则称R属于第二范式（2NF），写作R∈2NF。

改写说明

因为该关系模式中存在非主属性对于主键的部分函数依赖情况，并因此导致该关系模式不满足第二范式的条件

为了将关系模式规范到2NF，可以对关系模式做如下处理：

(1) 移除那些基于主键关联的属性，并将其所依存的主属性转移至新关系模式中作为其主键以建立新的数据结构。

(2) 剩下的属性构成另一个关系模式。

从原关系模式中提取属性orderdate、cstid和cstname，并将它们所依赖的主属性orderid复制到新关系模式中作为主键字段；随后构建新的Orders关系模式，并包含字段：orderid、orderdate、cstid和cstname。
同样地，从原关系模式中提取属性title、ctgcode和ctgname，并将它们所依赖的主属性bookid复制到新关系模式中作为主键字段；随后构建新的Books表，并包含字段：title、ctgcode和ctgname。
其余属性字段则构建一个新的OrderItems表，并包含以下字段：orderid（外键）、bookid（外键）和quantity。

因此，关系模式Booksale已被规范化为以下三者：这三者均未存在非主属性对主键的部分函数依赖性问题，因此它们都属于2NF范畴。经分解后生成的这三个新关系模式可通过外键连接实现数据完整性。

在关系模式分解后仍存在数据冗余问题。例如，在关系模式Orders中，由于一位顾客可能拥有多个订单记录（即有多张订单），因此顾客信息会被重复存储；而在关系模式Books里，则因为一个类别下可能有多个图书记录（即多册图书），所以图书类别信息也会被重复存储。

05、第三范式

若关系模式R达到第一范式，并且所有非主键属性均不传递函数依赖于该主键，则称关系模式R为第三范式，记作R\in 3NF。

在关系模式Orders中，在该关系模式中存在以下函数依赖：主键orderid能够唯一确定另一个属性值cstid；而cstid又能确定第三个属性值cstname；然而需要注意的是，在这种情况下（即当存在这样的一个中间属性链时），我们称...的关系依赖为传递函数依赖。

因为对于关系模式Orders而言，在其内部存在非主属性对主键的传递函数依赖。因此该关系模式不符合第三范式。

为了将关系模式规范到3NF，可以对关系模式做如下处理：

用于从关系模式中提取那些传递依赖于主键的属性，并将其直接函数依赖的属性进行复制以构建为新的关系模式的新主键。

(2) 剩下的属性构成另一个新关系模式。

例如，在原关系模式中提取属性cstname，并将其直接函数依赖的属性cstid复制作为新表Customers（cstid, cstname）的主键进行构建；其余原关系模式中的属性则构建一个新的表Orders（orderid, orderdate, cstid［FK］）。

分析关系模式Books，包含如下函数依赖：

在 Books 关系模式中，并非所有非主键字段都对主键保持传递函数依赖性。因此该关系模式无法达到第三范式（3NF）的要求。采用相同的技术策略将原关系模型进行分解后，则生成两个新的独立的关系模型。经过上述处理步骤后，在结果集中一共提取出五个新的独立的关系模型。具体而言，请参考表 2-22 至表 2-26 的详细信息。

经过分解处理后生成的这五个关系模式均未包含非主键字段向主键传递函数依赖的情况；这些新生成的关系模式之间可通过外键实现良好的关联。

最早被提出的关系范式是第一范式(1NF)、第二范式(2NF)和第三范式(3NF)，接着由R. Boyce和E. F. Codd于1974年共同提出了Boyce-Codd范式(BCNF)，这个关系范式是对3NF的增强定义。以上4个关系范式中除了1NF以外的3个关系范式都是基于属性之间的函数依赖提出的。比BCNF级别更高的关系范式还包括1977年提出的第四范式(4NF)和1979年提出的第五范式(5NF)，其中4NF建立在多值依赖的基础上，5NF建立在连接依赖的基础上。图2-6是各个关系范式之间的关系。

■ 图2-6关系范式之间的关系

在进行关系模式设计时，并非规范化程度越高越好。如果数据库的主要操作是查询而非更新，在不将模式拆分为过小的部分的情况下可以容忍适当的数据冗余（避免过度拆分），但这样会导致大量连接运算从而影响查询效率；而对于主要进行插入、更新和删除操作的数据库，则应尽量使关系模式达到3NF以防止数据操作异常。