本期主要是记录一下规范化与反规范化设计。
在开始之前先回答一下上期 Oracle 数据建模（1）留下的问题：谈谈你对数据建模的理解？
从以下三方面进行回答：
1.概念
数据建模就是运用正式的数据建模技术，建立信息系统的数据模型的过程。也就是确定数据库结构的过程。
最主要工作是将现实世界中的事物及它们之间的联系抽象出来，并以某种组织方式存储在数据库中。这种组织方式就是数据库结构。
现实世界中的事物在数据建模中称为实体，而事物与事物之间的联系则称为关系。
2.方法（后续文章会详细说）
2.1 实体-关系模型（E/R图）
E/R图的表示符号：用矩形框表示实体集；用椭圆形表示实体集的属性；用菱形框和箭头表示实体集之间的联系。
2.2 对象定义语言（ODL）
ODL是用面向对象的术语来说明数据库结构的一种标准语言。
3.过程
设计者首先依据用户对数据设计的要求，对数据库的结构提出一个设计思路。
将设计思路用E/R图或者用ODL语言表述出来。
选择和确定一个数据库管理系统（DBMS）来定义和建立这个数据库。
好了，其实也就是概念性的东西，了解就好了，个人觉得不用刻意去记。现在开始本章的重点，规范化与反规范化。
1.规范化
规范化：通过模式分解将一个低级范式转换为若干个高级范式的过程。
关系规范化的程度为第一范式(1NF)，第二范式(2NF)，第三范式(3NF)和BC范式(BCNF)，第四范式(4NF)等。
这里留个问题：那为什么要规范化呢？
1.1什么是范式
按照教材中的定义，范式是“符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度”。这讲的什么鬼？实际上你可以把它理解为一张数据表的表结构所符合的某种设计标准的级别。就像是各地景区都会按照依照《旅游景区质量等级的划分与评定》国家标准与《旅游景区质量等级评定管理办法》进行等级划分，比如：AAAAA、AAAA、AAA、AA、A级旅游区（点）。
那么数据库范式也分为1NF，2NF，3NF，BCNF，4NF，5NF。一般在我们设计关系型数据库的时候，最多考虑到BCNF就够。符合高一级范式的设计，必定符合低一级范式，例如符合2NF的关系模式，必定符合1NF。
1.2 关系与关系模式
关系（你可以理解为数据表。“关系模式”和“关系”的区别，类似于面向对象程序设计中”类“与”对象“的区别。”关系“是”关系模式“的一个实例，你可以把”关系”理解为一张带数据的表，而“关系模式”是这张数据表的表结构。
接下来就对每一级范式进行一下解释。
1.1.1第一范式（1NF）
1NF的定义：满足1NF的关系中的每个属性（也就列，字段）不可再分，无重复的列。
例如：
表1是不符合1NF的定义，因为联系方式这个字段还能再分为手机号码，和Email。
表2满足1NF的定义。
实际上，1NF是所有关系型数据库的最基本要求，你在关系型数据库管理系统（RDBMS），例如SQL Server，Oracle，MySQL中创建数据表的时候，如果数据表的设计不符合这个最基本的要求，那么操作一定是不能成功的。也就是说，只要在RDBMS中已经存在的数据表，一定是符合1NF的。
但是，满足1NF的关系，也会存在一些问题。假设满足1NF的关系设计如表3
我们可以看到数据冗余过大，插入异常，修改异常，删除异常等问题。
1）数据冗余过大
每个学生姓名，手机号，邮箱，以及所在系的系主任名称，重复出现多次。
2）插入异常
假如该学校想在3月份新开一个系，九月份开学了才招收学生。那么按照此时表的设计，是没有办法将该系和系名，新增到表里边的。为什么？（注1）
注１：根据三种关系完整性约束中实体完整性的要求，关系中的码（注２）所包含的任意一个属性都不能为空，所有属性的组合也不能重复。为了满足此要求，图中的表，只能将学号与课名的组合作为码，否则就无法唯一地区分每一条记录。
注２：码：关系中的某个属性或者某几个属性的组合，用于区分每个元组（可以把“元组”理解为一张表中的每条记录，也就是每一行）。
这里以学生编号，系名作为码。
3）修改异常
假设Hzc01想转到数学系中，那么为了保证数据的一致性，需要将Hzc01所有行上的，系和系主任都更改为数学系和数学系的主任。
4）删除异常
假设某个学生Hzc02因违反校纪被学校开除了，应在数据表中把该学生的记录给删除了，但是随之他所在系和系主任都被删除了，这是不对的。（一个学生没有了，并不代表这个系也没了）
5）回答：为什么要规范化呢？
正因为仅符合1NF的数据库设计存在着这样那样的问题，我们需要提高设计标准，去掉导致上述四种问题的因素，使其符合更高一级的范式（2NF），这就是所谓的“规范化”。
1.1.2第二范式（2NF）
2NF的定义：2NF在1NF的基础之上，消除了非主属性对于码的部分函数依赖，也就是不存在非主键字段对任一主键字段的部分函数依赖关系。
怎么理解呢?
数学里边有这样的函数定义：y = f(x) , z = f(x,y)。（详细的解释百度一下哈，实在太长了）
判断方法：
首先，我们需要判断，表4是否符合2NF的要求？根据2NF的定义，判断的依据实际上就是看数据表中是否存在非主属性对于码的部分函数依赖。若存在，则数据表最高只符合1NF的要求，若不存在，则符合2NF的要求。判断的方法是：
第一步：找出数据表中所有的码。
第二步：根据第一步所得到的码，找出所有的主属性。
第三步：数据表中，除去所有的主属性，剩下的就都是非主属性了。
第四步：查看是否存在非主属性对码的部分函数依赖。
例如：
第一步完，假设表4的码只有一个，就是（学生编号，课程名）组成复合码（复合主键）
第二步：主属性有两个：学号与课名
第三步：非主属性有四个：姓名、系名、系主任、分数
第四步：
对于（学号，课名） → 姓名，有 学号 → 姓名，存在非主属性 姓名 对码（学号，课名）的部分函数依赖。
对于（学号，课名） → 系名，有 学号 → 系名，存在非主属性 系名 对码（学号，课名）的部分函数依赖。
对于（学号，课名） → 系主任，有 学号 → 系主任，存在非主属性 对码（学号，课名）的部分函数依赖。
所以表4存在非主属性对于码的部分函数依赖，最高只符合1NF的要求，不符合2NF的要求。
怎么消除这些部分函数依赖？
将大数据表拆分成两个或者更多个更小的数据表，在拆分的过程中，要达到更高一级范式的要求，这个过程叫做”模式分解“。
模式分解的方法不是唯一的，以下是其中一种方法：
选课（学号，课名，分数）
学生（学号，姓名，系名，系主任）
我们先来判断以下，选课表与学生表，是否符合了2NF的要求？
对于选课表，其码是（学号，课名），主属性是学号和课名，非主属性是分数，学号确定，并不能唯一确定分数，课名确定，也不能唯一确定分数，所以不存在非主属性分数对于码 （学号，课名）的部分函数依赖，所以此表符合2NF的要求。
对于学生表，其码是学号，主属性是学号，非主属性是姓名、系名和系主任，因为码只有一个属性，所以不可能存在非主属性对于码 的部分函数依赖，所以此表符合2NF的要求。新数据如表5：
现在我们来看一下，进行同样的操作，是否还存在着之前的那些问题？
1）数据冗余过大
每个学生姓名，手机号，邮箱，以及所在系的系主任名称，重复出现的次数比1NF少了。--有改进
2）插入异常
假如该学校想在3月份新开一个系，九月份开学了才招收学生。那么按照此时表的设计，是没有办法将该系和系名，新增到表里边的。--无改进
3）修改异常
假设Hzc01想转到数学系中，那么为了保证数据的一致性，需要将Hzc01所有行上的，系和系主任都更改为数学系和数学系的主任。--有改进，只改一次
4）删除异常
假设某个学生Hzc02因违反校纪被学校开除了，应在数据表中把该学生的记录给删除了，但是随之他所在系和系主任都被删除了。--无改进
所以说，仅仅符合2NF的要求，很多情况下还是不够的，而出现问题的原因，在于仍然存在非主属性系主任对于码学号的传递函数依赖。为了能进一步解决这些问题，我们还需要将符合2NF要求的数据表改进为符合3NF的要求。
1.1.3第一范式（1NF）
3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖。也就是说， 如果存在非主属性对于码的传递函数依赖，则不符合3NF的要求。
接下来我们看看表5中的设计，是否符合3NF的要求。
对于选课表，主码为（学号，课名），主属性为学号和课名，非主属性只有一个，为分数，不可能存在传递函数依赖，所以选课表的设计，符合3NF的要求。
对于学生表，主码为学号，主属性为学号，非主属性为姓名、系名和系主任。因为 学号 → 系名，同时 系名 → 系主任，所以存在非主属性系主任对于码学号的传递函数依赖，所以学生表的设计，不符合3NF的要求。
为了让数据表设计达到3NF，我们必须进一步进行模式分解为以下形式：
选课（学号，课名，分数）
学生（学号，姓名，系名）
系（系名，系主任）
对于选课表，符合3NF的要求，之前已经分析过了。
对于学生表，码为学号，主属性为学号，非主属性为系名，不可能存在非主属性对于码的传递函数依赖，所以符合3NF的要求。
对于系表，码为系名，主属性为系名，非主属性为系主任，不可能存在非主属性对于码的传递函数依赖（至少要有三个属性才可能存在传递函数依赖关系），所以符合3NF的要求。
新的数据表如表6
现在我们来看一下，进行同样的操作，是否还存在着之前的那些问题？
删除某个系中所有的学生记录
该系的信息不会丢失。——有改进
插入一个尚无学生的新系的信息。
因为系表与学生表目前是独立的两张表，所以不影响。——有改进
数据冗余更加少了。——有改进
结论
由此可见，符合3NF要求的数据库设计，基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。当然，在实际中，往往为了性能上或者应对扩展的需要，经常 做到2NF或者1NF，但是作为数据库设计人员，至少应该知道，3NF的要求是怎样的。
1.1.4BC范式（BCNF）
BC范式（BCNF）：也叫修正的第三范式，任何字段都不存在函数依赖，即主键对主键无依赖关系。
3NF 的“不彻底”性表现在可能存在主属性对码的部分依赖和传递依赖。
在函数依赖的范围内，如果关系模式已经分解到 BCNF，其规范化已到最高级。
最后来个总结：
关系模式的规范化过程是通过对关系模式的分解来实现的。
文章参考：规范化设计
