数据库范式
数据库五大范式详解
第一范式（1NF）第一范式，强调属性的原子性约束，要求属性具有原子性，不可再分解。
举个例子，活动表（活动编码，活动名称，活动地址），假设这个场景中，活动地址可以细分为国家、省份、城市、市区、位置，那么就没有达到第一范式。
第二范式（2NF）第二范式，强调记录的唯一性约束，表必须有一个主键，并且没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。
举个例子，版本表（版本编码，版本名称，产品编码，产品名称），其中主键是（版本编码，产品编码），这个场景中，数据库设计并不符合第二范式，因为产品名称只依赖于产品编码。
存在部分依赖。
所以，为了使其满足第二范式，可以改造成两个表：版本表（版本编码，产品编码）和产品表（产品编码，产品名称）。
第三范式（3NF）第三范式，强调属性冗余性的约束，即非主键列必须直接依赖于主键。
举个例子，订单表（订单编码，顾客编码，顾客名称），其中主键是（订单编码），这个场景中，顾客编码、顾客名称都完全依赖于主键，因此符合第二范式，但是顾客名称依赖于顾客编码，从而间接依赖于主键，所以不能满足第三范式。
为了使其满足第三范式，可以拆分两个表：订单表（订单编码，顾客编码）和顾客表（顾客编码，顾客名称），拆分后的数据库设计，就可以完全满足第三范式的要求了。
值得注意的是，第二范式的侧重点是非主键列是否完全依赖于主键，还是依赖于主键的一部分。
第三范式的侧重点是非主键列是直接依赖于主键，还是直接依赖于非主键列。
修正的第三范式（BCNF）修正的第三范式，是防止主键的某一列会依赖于主键的其他列。
举个例子，每个管理员只能管理一个仓库，那么如果设计库存表（仓库名，管理员名，商品名，数量），主键为（仓库名，管理员名，商品名），这是满足前面三个范式的，但是仓库名和管理员名之间存在依赖关系，因此删除某一个仓库，会导致管理员也被删除，因此设计不合理。
第四范式（4NF）当一个表中的非主属性相互独立时（3NF)，这些非主属性不应该有多值。
数据库的一二三范式
数据库的一二三范式数据库的一二三范式是关系数据库设计中的重要概念，它们是用来规范数据库表的结构，确保数据的一致性和完整性。
本文将分别介绍一二三范式的定义和应用。
一范式（1NF）：消除重复的数据一范式要求数据库表的每个字段都是原子性的，即不可再分。
也就是说，一个字段不能包含多个值。
如果一个字段需要包含多个值，就需要将其拆分成多个独立的字段。
这样可以避免数据冗余和更新异常。
例如，我们有一个学生表，其中的一个字段是“课程”，如果一个学生选修了多门课程，我们可以将“课程”字段拆分成多个字段，比如“课程1”，“课程2”等。
二范式（2NF）：消除非主属性对主键的部分依赖二范式要求数据库表中的非主属性都完全依赖于主键，而不是依赖于主键的一部分。
如果一个表存在非主属性对主键的部分依赖，就需要将其拆分成多个表，以消除数据冗余和更新异常。
例如，我们有一个订单表，其中的字段有“订单号”、“产品名称”、“产品价格”和“产品数量”。
订单号是主键，产品名称、产品价格和产品数量都依赖于订单号。
但是，产品名称和产品价格之间存在函数依赖关系，即产品名称确定了产品价格。
为了满足二范式，我们可以将产品名称和产品价格拆分成一个独立的表。
三范式（3NF）：消除传递依赖三范式要求数据库表中的非主属性不依赖于其他非主属性，而是直接依赖于主键。
如果一个表存在传递依赖，就需要将其拆分成多个表，以消除数据冗余和更新异常。
例如，我们有一个员工表，其中的字段有“员工号”、“员工姓名”、“部门号”和“部门名称”。
员工号是主键，员工姓名依赖于员工号，部门名称依赖于部门号。
但是，员工姓名和部门名称之间存在传递依赖，即员工号确定了部门号，部门号确定了部门名称。
为了满足三范式，我们可以将部门名称拆分成一个独立的表。
总结：数据库的一二三范式是关系数据库设计中的基本规范，用于规范数据库表的结构，保证数据的一致性和完整性。
一范式消除重复的数据，二范式消除非主属性对主键的部分依赖，三范式消除传递依赖。
数据库设计中的四个范式
数据库设计中的四个范式在创建⼀个数据库的过程中，必须依照⼀定的准则，这些准则被称为范式，从第⼀到第六共六个范式，⼀般数据库设计只要遵循第⼀范式，第⼆范式，和第三范式就⾜够了。
满⾜这些规范的数据库是简洁的、结构明晰的，同时，不会发⽣插⼊（insert）、删除（delete）和更新（update）操作异常。
反之则是乱七⼋糟，不仅给数据库的编程⼈员制造⿇烦，⽽且⾯⽬可憎，可能存储了⼤量不需要的冗余信息。
I、关系数据库设计范式介绍1.1 第⼀范式（1NF）⽆重复的列所谓第⼀范式（1NF）是指数据库表的每⼀列都是不可分割的基本数据项，同⼀列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。
如果出现重复的属性，就可能需要定义⼀个新的实体，新的实体由重复的属性构成，新实体与原实体之间为⼀对多关系。
在第⼀范式（1NF）中表的每⼀⾏只包含⼀个实例的信息。
简⽽⾔之，第⼀范式就是⽆重复的列。
说明：在任何⼀个关系数据库中，第⼀范式（1NF）是对关系模式的基本要求，不满⾜第⼀范式（1NF）的数据库就不是关系数据库。
笔者⽈：就是在⼀个不需要设⽴主键就能表中保证每⼀⾏都具有唯⼀性。
不设⽴主键就能保证⾏唯⼀性的表就是第⼀范式。
1.2 第⼆范式（2NF）属性完全依赖于主键第⼆范式（2NF）是在第⼀范式（1NF）的基础上建⽴起来的，即满⾜第⼆范式（2NF）必须先满⾜第⼀范式（1NF）。
第⼆范式（2NF）要求数据库表中的每个实例或⾏必须可以被惟⼀地区分。
为实现区分通常需要为表加上⼀个列，以存储各个实例的惟⼀标识。
例如员⼯信息表中加上了员⼯编号（emp_id）列，因为每个员⼯的员⼯编号是惟⼀的，因此每个员⼯可以被惟⼀区分。
这个惟⼀属性列被称为主关键字或主键、主码。
第⼆范式（2NF）要求实体的属性完全依赖于主关键字。
所谓完全依赖是指不能存在仅依赖主关键字⼀部分的属性，如果存在，那么这个属性和主关键字的这⼀部分应该分离出来形成⼀个新的实体，新实体与原实体之间是⼀对多的关系。
数据库范式名词解释
数据库范式名词解释
数据库范式是数据库设计中的一种理论，它基于离散数学中的知识，主要为了解决数据存储和优化的问题。
其核心目标是为了减少数据冗余，提高数据的一致性和完整性。
范式包括六种，从低到高依次是：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF)和第五范式（5NF，又称完美范式）。
其中，满足最低要求的范式是第一范式（1NF）。
第一范式（1NF）要求在关系模型中，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合、数组、记录等非原子数据项。
如果实体中的某个属性有多个值时，必须拆分为不同的属性。
在符合第一范式（1NF）的表中，每个域值只能是实体的一个属性或一个属性的一部分。
简而言之，第一范式就是无重复的域。
数据库范式的主要作用是解决关系数据库中数据冗余、更新异常、插入异常、删除异常问题。
通过应用数据库范式，可以避免数据冗余，减少数据库的存储空间，并降低维护数据完整性的成本。
数据库范式是关系数据库核心的技术之一，也是从事数据库开发人员必备知识。
第一、二、三范式
设计范式简介（范式,数据库设计范式,数据库的设计范式）是符合某一种级别的关系模式的集合。
构造数据库必须遵循一定的规则。
在关系数据库中，这种规则就是范式。
关系数据库中的关系必须满足一定的要求，即满足不同的范式。
目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）和第六范式（6NF）。
满足最低要求的范式是第一范式（1NF）。
在第一范式的基础上进一步满足更多要求的称为第二范式（2NF），其余范式以次类推。
一般说来，数据库只需满足第三范式（3NF）就行了。
下面我们举例介绍第一范式（1NF）、第二范式（2NF）和第三范式（3NF）。
在创建一个数据库的过程中，范化是将其转化为一些表的过程，这种方法可以使从数据库得到的结果更加明确。
这样可能使数据库产生重复数据，从而导致创建多余的表。
范化是在识别数据库中的数据元素、关系，以及定义所需的表和各表中的项目这些初始工作之后的一个细化的过程。
下面是范化的一个例子Customer Item purchased Purchase price------------------------------------------------------------------------Thomas Shirt $40Maria Tennis shoes $35Evelyn Shirt $40Pajaro Trousers $25如果上面这个表用于保存物品的价格，而你想要删除其中的一个顾客，这时你就必须同时删除一个价格。
范化就是要解决这个问题，你可以将这个表化为两个表，一个用于存储每个顾客和他所买物品的信息，另一个用于存储每件产品和其价格的信息，这样对其中一个表做添加或删除操作就不会影响另一个表。
关系数据库的几种设计范式介绍第一范式（1NF）在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
数据库设计范式第一范式到第三范式的演化过程
数据库设计范式第一范式到第三范式的演化过程数据库设计范式的演化是指在数据库设计过程中，逐步将数据规范化的过程。
范式是一种规范化的方式，旨在提高数据库的数据一致性、减少数据冗余，并提升数据的查询和维护效率。
本文将介绍数据库设计范式的演化过程，从第一范式到第三范式的理念和规则。
第一范式（1NF）：第一范式是数据库设计中最基本的范式，它要求数据库中的每个属性都是原子性的，即不可再分。
这意味着不允许一个属性包含多个值，必须将多个值分解为独立的属性。
例如，如果一个学生有多个电话号码，那么应该将每个电话号码作为独立的属性存储，而不是将其放在一个字段中。
第二范式（2NF）：第二范式在满足第一范式的基础上，进一步要求数据库中的每个非主属性完全依赖于主键。
所谓完全依赖是指不能存在部分依赖。
为了满足第二范式，我们需要将非主属性拆分到与其依赖的部分主键对应的表中。
举个例子来说明，在一个学校的数据库中，有一个学生表（Student），其中的属性包括学生ID（Student ID）、姓名（Name）、系别（Department）和课程名称（Course Name）。
这里，学生ID是主键，姓名、系别和课程名称都依赖于学生ID。
为了满足第二范式，应该将姓名、系别和课程名称拆分成一个独立的课程表（Course），并通过学生ID建立与学生表的关联。
第三范式（3NF）：第三范式在满足第二范式的基础上，进一步要求数据库中的每个非主属性都不传递依赖于主键。
所谓传递依赖是指非主属性通过其他非主属性传递依赖于主键。
为了满足第三范式，我们需要将非主属性以及传递依赖的部分拆分到另一个表中。
继续以上述学校数据库为例，假设在课程表（Course）中添加了上课地点（Location）属性。
上课地点依赖于课程名称，而课程名又依赖于学生ID（主键）。
这就是一个传递依赖的情况，为了满足第三范式，应该将上课地点从课程表中拆分出来，建立一个独立的上课地点表（Location），并与课程表通过外键进行关联。
三大范式
数据库设计三大范式为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。
在关系型数据库中这种规则就称为范式。
范式是符合某一种设计要求的总结。
要想设计一个结构合理的关系型数据库，必须满足一定的范式。
在实际开发中最为常见的设计范式有三个：1．第一范式(确保每列保持原子性)第一范式是最基本的范式。
如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足了第一范式。
第一范式的合理遵循需要根据系统的实际需求来定。
比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。
但是如果系统经常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作的时候将非常方便。
这样设计才算满足了数据库的第一范式，如下表所示。
上表所示的用户信息遵循了第一范式的要求，这样在对用户使用城市进行分类的时候就非常方便，也提高了数据库的性能。
2．第二范式(确保表中的每列都和主键相关)第二范式在第一范式的基础之上更进一层。
第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。
也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。
比如要设计一个订单信息表，因为订单中可能会有多种商品，所以要将订单编号和商品编号作为数据库表的联合主键，如下表所示。
订单信息表这样就产生一个问题：这个表中是以订单编号和商品编号作为联合主键。
这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关，而仅仅是与商品编号相关。
所以在这里违反了第二范式的设计原则。
而如果把这个订单信息表进行拆分，把商品信息分离到另一个表中，把订单项目表也分离到另一个表中，就非常完美了。
如下所示。
这样设计，在很大程度上减小了数据库的冗余。
如果要获取订单的商品信息，使用商品编号到商品信息表中查询即可。
数据库三大范式详解
数据库三大范式详解设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。
目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴德斯科范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。
满足最低要求的范式是第一范式（1NF）。
在第一范式的基础上进一步满足更多规范要求的称为第二范式（2NF），其余范式以次类推。
一般说来，数据库只需满足第三范式(3NF）就行了。
第一范式（1NF）无重复的列所谓第一范式（1NF）是指在关系模型中，对域添加的一个规范要求，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。
即实体中的某个属性有多个值时，必须拆分为不同的属性。
在符合第一范式（1NF）表中的每个域值只能是实体的一个属性或一个属性的一部分。
简而言之，第一范式就是无重复的域。
说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的设计基本要求，一般设计中都必须满足第一范式（1NF）。
不过有些关系模型中突破了1NF的限制，这种称为非1NF的关系模型。
换句话说，是否必须满足1NF的最低要求，主要依赖于所使用的关系模型。
第二范式（2NF）属性在1NF的基础上，非码属性必须完全依赖于主键[在1NF基础上消除非主属性对主码的部分函数依赖]第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。
第二范式（2NF）要求数据库表中的每个实例或记录必须可以被唯一地区分。
选取一个能区分每个实体的属性或属性组，作为实体的唯一标识。
例如在员工表中的身份证号码即可实现每个一员工的区分，该身份证号码即为候选键，任何一个候选键都可以被选作主键。
在找不到候选键时，可额外增加属性以实现区分，如果在员工关系中，没有对其身份证号进行存储，而姓名可能会在数据库运行的某个时间重复，无法区分出实体时，设计辟如ID等不重复的编号以实现区分，被添加的编号或ID选作主键。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
范式
就关系数据库而言，一贯认为：从其他元素中消除数据冗余问题，去除重复往往以减少冗余, 从特定的表中最小化冗余意味着摆脱不必要的数据。
商业上来讲，主要目标是通常保存空间和组织的数据可用性和可管理性，而不牺牲性能。
此外，要求强烈繁忙的应用程序和最终用户的需要往往需要以多种方式打破规则的范式，以满足性能要求。
第三范式以外的范式常常被忽视和有时甚至是第三范式本身就是多余的。
范式是一个升级的过程，每个上层的模式都是建立在下一级范式之上的。
消除数据冗余的影响如下：
❑物理空间需要存储的数据减少。
❑数据变得更有组织。
❑范式化允许修改少量的数据（即单记录）。
换言之，一个表的具体字段记录更新时，会影响其他引用他的表。
首先我们对一些概念性的东西来进行一个总结，通过对这些概念的理解，从来从根本上做到合理的数据库设计：
异常
●添加异常：当我们添加一条记录的时候，他依赖的主表记录还没有记录，而该记录
已经插入成功。
●删除异常：当我们的主表记录删除，而依赖他的子表没有清空对应的记录。
●更新异常：当我们的主表记录有更新草组，而已来他的子表没有相应的更新记录。
依赖，决定因子
●函数依赖：当Y的值由X决定的时候，我们就说Y函数依赖于X，这就类似于一个
线性方程：Y=X+1;类似的ERD图中，我们这样表示，很清楚的看
到表Category，中的主键是CategoryID，他决定着其他字段的值Name和Pic，
我们就说Name或者Pic 函数依赖于CategoryID，他们之间就是一个函数依赖关
系。
●决定因素：如上例中，CategoryID就是一个决定因素，他决定其他字段的值，Y=X
+1中，X就决定着Y的值，虽然加了一个常量。
●传递依赖：当X决定Y，Y决定Z的时候，我们就说Z传递依赖于X，，
从这个ERD图中，我们看到Account帐号表中的City字段，他被AccountID所决定，而City字段的值又决定了College的值，因为大学肯定是被城市所决定，所以College就传递依赖于AccountID。
●候选键：候选键（潜在的或允许的主键）可以扮演主键的角色他可以是一个表中的
一个字段或组合字段——也就是一条记录中的唯一标识。
，我们看到这个表，Customer表（客户表），字段分别表示，客户ID,客户名，货币缩写码，货币，转换汇率，地址。
这个表我们没有定义主键，但是我们可以推测那些可以成为主键，那么那些键就叫做候选键。
，我们就看到了，所有能成为主键的可能，表中的#就是主键的标识符。
●完全函数依赖：当X决定Y，但是X不被X和Z的组合所决定，换句话说，YE依赖
于独立的X，如果Y依赖于X加上一些其他的东西，那就不是完全函数依赖，本
质上，决定因素X不能是一个组合键。
，我们来看到旅游表Tra
vel，Country是旅游的国家，Populication是旅游的城市，同时TravelID和C
ountryID是主键，可以看出来只有CountryID决定着Populcation人口，但是
这里有两个主键，所以Populication并没有完全函数依赖于主键组合，只部分
依赖于CountryID
●多值依赖：某个字段中的值之一个集合，或者是用某种分隔符分割开来的元素集合，
我们就称为多值依赖。
很经典的，Path保存的这个递归表的所
有上司的级别，比如老大的ID是1，老2是2，Path 就保存1，2，像这样的字
段，我们就称为多值依赖。
●循环依赖：循环依赖就如其名，是一个个闭环的依赖系统。
A依赖于B,B依赖于C,
C依赖于A。
范式（学术定义）
●第一范式(1NF)：消除表中所有重复的记录，除了主键以外的所有其他字段全部依
赖于主键。
●第二范式（2NF）：所有非键值字段必须全部完全函数依赖于主键，当一个字段完
全函数依赖于一组组合主键的部分函数依赖是不允许的。
●第三范式（3NF）：消除传递依赖，意味着一个字段必须非间接的依赖于主键
●正规化范式（BCDF）：所有表中的决定因素必须是一个候选键，如果只有一个候选
键，那么就和第三范式是一样的。
●第四范式（4NF）：消除多值依赖。
●第五范式（5NF）：消除循环依赖。
我们从一个比较容易的位置来理解范式，通过上述的理解，加上实际的操作范式，让我们对数据库的设计有一个比较深的认识，以决定什么情况下用范式。
●第一范式(1NF)：通过创建一个新表来移除重复的元素，使他们成为一个主从关系
或者是one to many的关系，类似下图：。
●第二范式（2NF）：建立在1NF的基础上，就是移除重复的值到一个新表中去，新
表有唯一的主键，而主表有一个对新表的外键的引用，排除存在的部分依赖。
如下图：
Boo kid 是book表的主键，而author是author1的主键，在book表中建立author，主表有一个对子表的外键引用，而不是把author也定义为主键，那样就存在部分函数依赖，因为bookid就已经确定了title，page，isbn等等信息。
●第三范式：消除传递依赖，如下图：
我们把多对多的关系变化成上图的关系。
这是一种简单的形式，下面展示一个另外一种情况：
这里的表分别是客户（客户名，货币号，货币，货币，汇率，地址），提供商（客户名，货币号，货币，汇率，地址）。
首先他们的地址决定了他们的货币情况，而地址又是由客户或者提供商决定的，所以他们之间存在一个传递依赖关系，而且最好是把相同的存在于不同的数据移植到一个新表中去。
前面我们提到了
这个关系，也是一个不满足第三范式的表，City和College以及主键存在传递关系，所以可以把College移植到一个新表中去，
还有一些存在订单的表中，有类似（qty（数量），price（单价），total（总价））的结构，qty和price决定了total，而订单号决定了qty和，price，所以也存在一中依赖关系，我们要删除total字段，但是不是都遵循范式的表都是好的结构，我们还是要根据实际情况，比如在一个数据仓库的设计中，汇总字段就是必须的。
●超三范式（Beyond 3NF）中的one to one关系，这个主要用户当我们表中一些字
段经常存在空值的时候，我们将存在的NULL字段移到一个新表中去，然后建立1对1的关系。
●BCNF范式：BCNF划分成多个表的表格，以确保没有一个单一的表有更多不止一个
潜在的主键。
这是我的理解BCNF 。
在我看来，是BCNF 用于商业环境是“过度设计“的。
从本质上讲，从数学的角度上它的漂亮，但在商业环境中它不是很酷。
下面的例子是一个BCNF转换：
●第四范式：消除多值依赖，很经典的一个环境就是，我们的递归表问题
，一个Manager有多个Employee，然后每条记录都有一个Path 老表示这种关系，所以path和EmployeeId就存在一个多对多的关系。
我们就应该重新建立一个新表，用来消除Path字段，新表中就保留一个EmployeeId作为外键，另外一个EmployeeId用来表示他的下属。
●消除循环依赖，如下图：
在这个实例中Solution表中的键都是主键，他们存在这样的关系，每两个组合的主键决定另外一个主键。
比方项目1和经理1就决定了有哪些下属属于项目1和经理1关系，而
一个经理1和他的下属员工又决定了他们参与了那些项目。
所以他们之间其实是一个循环的依赖。
反范式：
●这种类型的应用在商业正常化环境将导致业绩不佳，更精确的数学的必要性比
商业要低的多。
因此：
●同样的，对于第4范式，我们很多时候都没有必要去消除他们里面多值的依赖，
那样对性能来说简直是个噩梦。
所以很多情况下，我们都是用类似的处理
CSDN上的，显示自己的技术就是这样的反范式化转换。
●在商业环境中，绝大多数超越第3范式的设计都是不切实际的。
因为应用程序
在3NF级别就能变现的相当出色。
我们上述的很多例子，将指向箭头反过来
就是先了反范式化。
所以我们要对整体的结构有个比较深的认识，才确定我
们是否范式话或者反范式化，范式化越深的东西越导致表的增多，也就意味
着查询的join开销。
●总结一下反范式化的一些准则：
⏹分离活动和静态的数据，数据可分为独立的物理表，即
⏹活动和静态表。
那些累计的历史数据导致我们占据了绝大多数的空间。
这
是影响性能的最经常的数据，在数据仓库设计中，我们经常将无效的静
态的数据移植到数据仓库中，由于OLAP和数据挖掘。
⏹在表之间复制字段，在那些不是直接有链接表的之间复制字段，使得我们
不必每次进行查询都要通过第3方表，越少的join操作，使得性能的
大幅度提升。
⏹在夫表中建立统计字段，这样可以减去消耗大的聚合操作，但是实时更新
会给我们带来另外的麻烦。
⏹分离繁重和轻松的字段，就像把活动和静态的数据数据表分离一样，这个
避免持续物理扫描很少使用的数据字段，尤其是当这些字段不包含空值。
这是一个潜在的合理利用4NF在分离表格分为两个表格，相关的一对一
关系。