openGauss 数据库设计中的规范化设计

关系属性间可能存在着不同的依赖关系，而有些依赖关系具有不适合的性质。数据库设计过程中，按照属性间的依赖情况定义了不同的关系规范化程度，即范式。主要包括第一范式、第二范式、第三范式和BCNF（Boyce Codd Normal Form）范式。基于这些范式，数据库设计过程中可以将具有不友好性质的关系转换为更合适的关系。
1. 函数依赖关系
函数依赖只能根据语义来确定，属于语义范畴。函数依赖的数学定义如定义3.1：
定义3.1 存在某个属性集U及U的子集，假设U上存在关系模式R(U)。若R(U)中的全部元组满足则，则称函数依赖于，记作。
关于函数依赖的常见种类和表示方式如表3-27所示。
表3-27 函数依赖关系

函数依赖关系	表示方式
是非平凡的函数依赖	,
是平凡的函数依赖	,
X,Y相互依赖	,()
Y不函数依赖于X

例如，一个客户居住在一个城市，具有唯一的姓氏，购买的货物价格是唯一的；一个城市里可能存在多个同姓氏的客户，购买的货物价格可能相同。则关系模式（客户号，城市，货物价格，姓氏）中客户号是所有属性的决定因素，存在函数依赖客户号（城市，货物价格，姓氏），但（城市，货物价格，姓氏）不是客户号的子集，所以该函数依赖是非平凡函数依赖。子关系模式（城市，货物价格，姓氏）中（城市，货物价格，姓氏）所有属性构成了决定因素组，存在函数依赖（客户号，城市，货物价格，姓氏）（城市，货物价格，姓氏），该函数依赖为平凡函数依赖。部分函数依赖的数学定义如定义3.2：
定义3.2 存在某个属性集U及U的子集，假设U上存在关系模式R(U)。若函数依赖于()，并且对于全部真子集()，都满足，则称完全函数依赖于，记作；反之，若存在满足，则称部分依赖于，记作。例如，一个客户可能提交了多个货运订单，每个货运订单内只有该客户订购的一种商品，客户有唯一的收货地址；一个货运订单内包含了多个客户同时下定的商品。则关系模式（客户号，货运订单号，商品名称，收货地址）中，存在函数依赖（客户号，货运订单号）（商品名称），因为客户号和货运单号不能单独决定商品名称，则商品名称完全依赖于客户号和货运订单号。同时存在函数依赖（客户号，货运订单号）收货地址，但因为客户号单属性就可以决定收货地址，收货地址属性不完全依赖于属性组（客户号，货运单号），所以该函数依赖是部分依赖。传递函数的数学定义如定义3.3：
定义3.3 存在某个属性集U及U的子集，假设U上存在关系模式R(U)。若函数依赖于()，不属于的真子集()，不函数依赖于()，且函数依赖于()，则间存在对的传递函数依赖，记作。
这里强调了，是因为，则，事实上，是直接函数依赖并不是传递函数依赖。
这里强调了，是因为如果，则，实际上，是直接函数依赖而不是传递函数依赖。
例如，一个客户购买的商品都从唯一的商品仓库发货，每个城市只有唯一的商品仓库。
则关系模式(客户号，商品所属仓库，发货城市)中，存在函数依赖客户号商品所属仓库，商品所属仓库发货城市，则该关系模式中客户号发货城市为传递依赖。
2. 码
码是关系模式中的一个重要概念，其数学定义如定义3.4。
定义3.4 存在某个属性集U及U的子集，假设U上存在关系模式R(U)。若中没有两条元组在属性集上具有相同值，即若则[]，那么中一个值一定可以唯一标识一个元组，此时称是R(U)的超码（Super Key）。超码中可能包含若干冗余属性不对元组标识起作用，即该超码的真子集也是超码，此时最小的超码（所有真子集均不是超码）被称为候选码（Candidate Key），被选取用于设计数据库的任一候选码被称为主码（Primary Key）。
候选码中的属性称为主属性（Primary Attribute）；不包含在任何候选码中的属性称为非主属性（Nonprime Attribute）或非码属性（Non-Key Attribute）。关系模式中存在单个属性是码；也存在整个属性组是码，被称为全码（All-Key）。外码的数学定义如定义3.5：
定义3.5 存在某个属性集U，假设U上存在关系模式。若是的非主属性或属性组，但其是的主属性或属性组，此时称是的外部码（Foreign Key），也称外码。
例如，一个客户具有唯一的收货地址；购买的货物从不同的货物仓库邮寄，每个货物仓库具有不同的仓库名，存放多种货物。
则关系模式（客户号，收货地址，发货仓库号）中，客户号是关系模式中所有属性的决定性属性，即候选码/主码。虽然发货仓库号不是该关系模式的候选码，但却是关系模式（发货仓库号，仓库名，货物数目）的候选码/主码，因此发货仓库号是该关系的外码。外码和主码的结合用于描述关系间的联系。
3. 范式
范式理论（Normal Form）起源于20世纪70年代，由英国计算机科学家埃德加·弗兰克·科德（E.F.Codd）基于关系型数据库模型总结提出。科德首先于1971年-1972年提出了1NF、2NF、3NF的概念，然后又于1974年与美国计算机科学家雷蒙德·博伊斯（Raymond F. Boyce）合作对3NF进行了修正，进一步提出了巴斯范式BCNF（Boycee Codd Normal Form）。1976年，美国数学家、计算机科学家罗纳德·法金（Ronald Fagin）又提出了继BCNF后又一规范化理论标准4NF。后续的科学家们也在不断的进行范式理论的研究，提出了5NF等更高级别的范式理论。
关系型数据库设计中需要进行大量的关系模式规范化处理（Normalization），即将存在各种依赖关系（部分依赖、传递依赖）的关系模式，基于范式理论并通过模式分解的方式转换成若干个符合高级范式的关系模式的集合。目前在关系型数据库设计中，常被引用的范式理论主要有1NF、2NF、3NF、BCNF、4NF、5NF，上述范式理论为层层递进的子集关系，具体为。
第一范式（1NF）：关系模式中所有的属性都应该是原子性的，即数据表的每一列都不可分割。关系型数据库中1NF是对关系模式的最基本要求，一般数据库设计中都需要满足1NF。
例如，每个客户有唯一的姓氏，唯一的电话，可能有多个收货地址。则关系模式（客户号，姓氏，电话）中所有属性都不可拆解，具有原子性，属于1NF。而关系模式（客户号，姓氏，电话，收货地址（地址1，地址2，地址3））中收货地址可以拆解为多个属性，不具有原子性，不满足1NF。
第二范式（2NF）：1NF基础上保证非码属性必须完全依赖于候选码，消除非码属性对候选码的部分函数依赖问题，2NF的数学定义如定义3.6：
定义3.6 存在某个属性集U，假设U上存在关系模式R(U)。若R(U)，且R(U)中每个非主属性完全依赖于任何一个候选码（Candidate Key），则称R(U)。
例如，每个客户有唯一的收货地址，提交了多个订单；每个订单对应了一种商品，有唯一的收货地址。
则关系模式（客户号，收货地址，订单号）中存在函数依赖（客户号，订单号）收货地址，因为订单号和客户号都可以独立决定收货地址，该关系模式存在部分函数依赖，因此不符合2NF。不符合2NF的关系模式，往往会出现插入、删除异常以及修改复杂等问题。
第三范式（3NF）：2NF的基础上消除了非主属性对其他非主属性的传递依赖问题，3NF的数学定义如定义3.7：
定义3.7 存在某个属性集U，假设U上存在关系模式R(U)。若R(U)，且R(U)中不存在主属性，满足成立，，则满足这种要求的关系R(U)属于第三范式，记作R(U)。
例如，每位客户拥有唯一的货物运单号，每个货物运单包含多位客户的货物信息，每个货物运单对应唯一的发货仓库。则关系模式（客户号，货物运单号，发货仓库）中，存在函数依赖客户号货物运单号，货物运单号客户号，货物运单号发货仓库，则客户号发货仓库号，即存在传递依赖。为满足3NF，需通过关系模式分解将关系模式映射为多个关系模式，进而消除该传递依赖。若一个关系不属于3NF，也会产生插入异常、删除异常以及修改复杂等类似的问题，3NF的不彻底性表现在可能存在主属性对码的部分依赖和传递依赖。
BCNF范式是由Boyce和Codd共同提出的，它是3NF的修正和补充，其数学定义如定义3.8：
定义3.8 存在某个属性集U及U的子集，假设U上存在关系模式R(U)。若R(U)且R(U)中每个决定因素都包含码，即且时必包含码，则R(U)属于巴斯范式，记作R(U)。
例如，一个仓库只有一个名字，和唯一的销售税；一个城市内可能有多个同名，或同销售税的仓库。则关系模式（仓库号，仓库名，城市，销售税）中，存在函数依赖仓库号（仓库名，城市，销售税），关系模式中只有唯一的主码仓库号，没有其他属性对主码存在部分依赖和传递依赖，所以其属于BCNF。
BCNF关系模式排除了任何属性（码和非码）对码的传递依赖和部分依赖，所以。但是反之不成立，若，R未必属于BCNF。BCNF是在函数依赖的条件下，对模式分解所能达到的最高分离程度，其彻底消除了插入和删除异常。
事实上，1NF~BCNF都只是在函数依赖的范畴内讨论关系模式的优化方式。而除了函数依赖外，关系模式的属性间还存在着其他数据依赖，如多值依赖（Multi-Valued Dependency）、连接依赖（Join Dependency）。针对多值依赖问题，后续又引出了4NF的概念，而消除了4NF关系模式中存在的连接依赖后，则可进一步达到5NF的规范化关系模式。本文只介绍了1NF，2NF，3NF，BNCF范式，对于规范化程度更高的4NF与5NF不做详细介绍。
满足1NF往往是数据库设计中的最基本要求，并且满足1NF的关系模式就是合法的。但是插入异常、删除异常、修改复杂，及数据冗余等问题，严重影响了1NF关系模式的应用。因此，设计了规范化标准来解决这些问题，通过对关系模式的投影分解，将低级关系模式分解为若干高级关系模式，进而规避上述问题。综上所述，规范化的核心思想就是逐步消除关系模式中不友好的关系模式，使各关系模式达到高度单一化。