designs\project\database-数学与数据库范式

A data model (first sense) is an abstract, self-contained, logical definition of the data structures, data operators, and so forth, that together make up the abstract machine with which users interact. 数据模型（第一感觉）是数据结构、数据操作符等抽象的、自包含的、逻辑的定义，它们共同构成了用户交互的抽象机器。
A data model (second sense) is a model of the data—especially the persistent data—of some particular enterprise. 数据模型（第二种感觉）是数据的模型——特别是某些特定企业的持久数据。
Any given database consists of relation variables (relvars for short). 任何给定的数据库都包含关系变量（简称relvars）
The value of any given relvar at any given time is a relation value (relation for short). 任何给定时间内任何给定的relvar的值都是一个关系值（简称 relation）
Every relvar represents a certain predicate. 每个relvar代表一个特定的谓词。
Within any given relvar, every tuple represents a certain proposition. 在任何给定的relvar中，每个元组代表一个特定的命题。
In accordance with The Closed World Assumption, relvar R at time T contains all and only those tuples that represent instantiations of the predicate corresponding to relvar R that evaluate to TRUE at time T. 根据闭包运算假设，在T时刻，relvar R包含所有的元组，这些元组表示谓词的实例化对应于relvar R，在T时刻评估为真

其他概念

数学功底不足啊。

基本概念：

RVA: relational valued attribute关系属性：

层次结构不对称，使得某些任务更容易，但他们肯定使其他任务更复杂。
尤其是查询是不对称的，并且比其对称的等价查询更复杂。
完整性约束、更新异常也存在类似的问题。
如何选择更好的层次结构，没有指导方针。
通常使用非层次结构设计表达任然是最好的。

重复组：Column C is a repeating group column (also known as a multivalued attribute) if and only if it’s defined to be of type T but the values that appear in that column aren’t values of type T but are, rather, groups (in other words, sets or lists or arrays or ...) of values of type T. 当且仅当列C的定义为类型T，但出现在这一列的值不是类型T的值,而是类型为T的值的组 (换句话说,集合，列表或数组等)时，他是重复组，也称为多值属性（multivalued attribute）。

原子性：values in the domains on which each relation is defined are required to be atomic with respect to the DBMS; 在定义任意关系，R的域内的值，必须在整个DBMS中保持原子性。cannot be decomposed into smaller pieces by the DBMS ; 也就是说不能被DBMS分解成更小的部分。

函数依赖：设X和Y是关系变量R的标题的子集，那么当且仅当只要R的两个元组具有一致的X，它们就具有一致的Y时在R中存在函数依赖（FD）:
X→Y 这里的X和Y分别是决定因素（determinant）和依赖因素（dependant），而FD整体可以读作X函数决定Y, 或者 Y函数依赖于X，或者更简单的X箭头Y。

平凡的函数依赖：当且仅当FD X→Y 没有办法可以违反时, 它是平凡的（trivial）。（当且仅当Y是X的一个子集时，FD X→Y是平凡的）

FD的不可约性：当且仅当FD X→Y存在于R中而对于X的任何真子集X1，X1→Y不存在于R中时FD X→Y对于关系变量R是不可约的

候选键：设K是关系变量R的标题的一个子集，那么当且仅当它同时具有以下两个属性时，K是R的一个候选键（或简写为键）：

唯一性（uniqueness）：任何有效的R值都不能包含两个具有相同的K值得不同元组。
不可约性（irreducibility）：K的任何真子集都不具有唯一性属性。

键属性（key attribute）：是指R的一个属性，它至少是R的一个键的一部分。

非键属性（nonkey attribute）：是指R的一个属性，它不属于R的任何键。

全键（all key）：当且仅当整个标题是一个键时。

超键（superkey）：设SK是关系变量R的标题的一个子集，那么当且仅当它具有以下属性时，SK是R的一个超键：唯一性：R的任何有效值都不能包含两个具有相同的SK值得不同元组。（简洁的说，R的超键是R的标题的具有唯一性但不一定不可约的一个子集）

子键（subkey）：设SK是关系变量R的标题的一个子集，那么当且仅当它至少是R的一个键的一个子集时SK是R的一个子键。

键蕴含：设F是关系变量R中存在的FD，则当且仅当它是R上的一个超键约束时,R的键才蕴含F。

希思定理：设关系r具有标题H,并设X、Y、Z都是H的子集，且X、Y、Z的并集等于H。设XY代表X和Y的并集，XZ也代表类似的含义。如果r满足FD X→Y，则r等于其在XY和XZ上的投影的连接。

不可约的关系：

引用的完整性：是指引用属性有效的。在关系型数据库中，它要求关系（表）的一个属性（列）的每一个值都以另一个（或相同）关系（表）的属性（列）中作为另一个值存在。

（函数的one-to-one 参考：xxxx）

当一个，外键被使用时，它必须在父表中引用一个有效的现有主键。例如，删除一条记录，这条记录包含另一张表中的外键所引用的值，这将破坏引用完整性。一些关系数据库管理系统（RDBMS）可以强制引用完整性。正常情况下，要么通过删除外键行来保持完整性，要么返回一个错误，而不执行删除操作。使用哪种方法可以由数据字典中定义的引用完整性约束来确定。

形容词“参照”描述了外键执行的动作，“引用”到另一张表中的链接列。简单地说，“参照完整性”是一个保证，它“引用”的目标将被找到。数据库中缺少引用完整性可能导致关系数据库返回不完整的数据，通常没有任何错误的指示。

引用的完整性形式化：包含依赖——两个谓词R和S之间的包含依赖写作：R[A1,……An] ⊆ S[B1,……Bn]，Ai，Bi 分别是R，S的是不同的属性。这意味着A1,……An中出现的元祖，也一定会在B1,……Bn中出现。也就是S的实现。（连接依赖？）

逻辑上的包含依赖的含义可以通过推理规则（可以用PSPACE算法）来实现。逻辑上依赖关系可以是包含依赖或函数依赖，单从属性的词意特征上是不能判定的。

（谓词的定义参照：xxxx）

传递依赖：

FD集合的覆盖C：一个FD集合F的一个覆盖是一个FD集合C，其中F中的每个FD都被C中的FD蕴含。

FD集合的覆盖C 是不可约的：

单例依赖因素（singleton dependant）：在C中的每个FD的右侧都只有一个属性。
不可约的决定因素（irreducibel dependant）：在C中的每个FD本身是不可约的。
没有冗余的FD：任何FD都不可以在不丢失C是F的一个覆盖这个性质的情况下从C中去掉。

3NF过程：现在展示一个过程，可以保证产生的所有关系变量都属于3NF，并保持所有FD的一种分解。输入是一个关系变量R和在R中存在的FD的不可约覆盖（irreducible cover）

设S是标题的一个集合。S初始化为空集{}。
设X是在C中的某个FD的左边（决定因素），设C中的FD及其左边部分X的完整集合是 X→Y1，…，X→Yn；并设Y1，…，Yn的并集是Y。把X和Y的并集添加到S中。为每个不同的X执行此步骤。
设U是R中不包含S中任何元素的属性的集合。如果U是非空的，则把U添加到S中。
如果S中的元素不是R的超键，则把R的某个键K添加到S中。

恒等投影：一个给定关系变量的恒等投影（identity projection）是关系变量在它的所有属性上的投影。

独立投影：关系变量R的投影R1和R2是独立的，当且仅当在R中存在的每一个FD在R1和R2的连接中也存在。

无损分解：

Rissanen定理：设关系变量R具有标题H,它具有投影R1和R2，它们分别具有标题H1和H2;进一步，设H1和H2都是H的真子集，设它们的并集等于H，并设它们的交集是空的。那么当且仅当（a）其共同属性构成至少其中一个投影的超键，且（b）在R中的每个FD都被其中至少一个投影存在的FD蕴含时，投影R1和R2是独立的。

阿姆斯特朗公理(Armstrong’s axioms)：

如果Y是X的一个子集，则X→Y(“自反律” ，reflexivity)
如果X→Y，则XZ→YZ(“增广律”， augmentation)
如果X→Y和Y→Z，则X→Z(“传递律”，transtivity)

F的闭包：反正看不懂，以后能看懂了补上。

附加规则：

X→Y(“自含律”， self determination)
如果X→Y和X→Z，则X→YZ (“合并律”， union)
如果X→Y和Z→W，则XZ→YW (“复合律”， composition)
如果X→YZ，则X→Y和X→Z (“分解律”， decomposition)

这些规则和阿姆斯特朗公理可以用于3NF求Cover的过程。

多值依赖（Multivalued Dependency, MVD）：是一个正好由两个分量组成的连接依赖。

连接依赖：设H是一个标题，那么一个关于H的连接依赖（JD）是一种形式为{X1，…Xn}的表达式，其中，X1，…Xn（JD的分量）是H的子集，且它们的并集等于H。

设X1，…Xn是关系变量R的标题H的子集，那么当且仅当R可以无损地分解成其在X1，…Xn上的投影时。（即，当且仅当R的每一个合法的r值等于相应的投影r1,…,rn的连接）

希思定理同样适用于连接依赖：

循环依赖：

无关的分量：

结合分量：

不可约的JD:

追逐算法：略：

能说明D蕴含d
通过一个明确的反例，也就是，一个满足D中所有的依赖，但违反d的关系，来说明D不蕴含d

MVD公理:

嵌入式依赖：

相等依赖：

限制-合并范式：

正交：

冗余：

关系理论

xxxxx

在1 NF（第一范式）之后，标准化的目标如下：

减少依赖项带来的插入、更新和删除副作用;
增加了应用程序的生命周期，随着新类型的数据类型的引入，减少对关系集合进行重组的需求;
使关系模型能给用户提供更多的信息;
为了保持已有查询，随着时间推移未来可能会用到的的查询的效率。

如果违反第一范式，可能会造成的插入、更新和删除的副作用：

更新异常：同样的信息可以在多行中表示;因此，对关系的更新可能导致逻辑上的不一致。

例如，“员工技能”关系中的每个记录可能包含员工ID、员工地址和技能;因此，对特定员工的地址变更可能需要应用于多个记录（每个技能一个）。如果更新只是部分成功——员工的地址在某些记录上被更新，而不是其他记录——那么这个关系就会处于不一致的状态。具体来说，这个关系为这个问题提供了相互矛盾的答案。

员工ID	员工地址	员工技能
426	87 Sycamore Grove	Typing打字
426	87 Sycamore Grove	Shorthand速记
519	94 Chestnut Street	Public Speaking演讲
519	96 Walnut Avenue	Carpentry 木匠
更新异常。员工519显示在不同的记录上有不同的地址。

插入异常：在某些情况下，某些事实根本无法被记录下来。

例如，“教员和他们的课程”关系中的每一个记录都可能包含教员ID、教员名称、教员招聘日期和课程代码。因此，我们可以记录任何教授至少一门课程的教员的详细信息，但我们不能记录一个新聘用的教员，他还没有被分配去教授任何课程，除非将课程代码设置为null。这种现象被称为插入异常。

教员ID	教员名称	教员招聘日期	课程代码
389	Dr.GiddensDr.	10-Feb-1985	ENG-206
407	SapersteinDr.	19-Apr-1999	CMP-101
407	Saperstein	19-Apr-1999	CMP-101
424	Dr. Newsome	29-Mar-2007
插入异常。直到新教员，Dr. Newsome被指派教授至少一门课程，他的记录才能被录入。

删除异常: 在某些情况下，删除代表某些数据，附带删除代表完全其他事实的数据。

“教师和他们的课程”示例中描述关系存在这种类型的异常, 因为如果一名教员暂时停止被分配到任何课程，我们必须删除该教员的整条记录，也删除掉了教员,除非我们将课程代码设置为null。这种现象被称为“删除异常”。

教员ID	教员名称	教员招聘日期	课程代码
389	Dr.GiddensDr.	10-Feb-1985	ENG-206
407	SapersteinDr.	19-Apr-1999	CMP-101
407	Saperstein	19-Apr-1999	CMP-101
424	Dr. Newsome	29-Mar-2007
删除异常。Delete 389如果他或她暂时停止被分配到任何课程，关于他的所有信息都将丢失。

一个完全规范化的数据库允许它的结构被扩展。

以适应新类型的数据，而不需要改变现有的结构。因此，与数据库交互的应用程序受到的影响最小。

使关系模型能给用户提供更多的信息

保证查询和操纵数据效率：

不对称结构：对每个客户都对应一个“重复组”的事务。因此，对与客户交易相关的任何查询的自动评估，将大致包括两个阶段

打开一个或多个客户的交易组，允许对组中的个体交易进行检查，
根据第一阶段的结果得出一个查询结果

Customer

Cust. ID

Transactions

Jones

Wilkins

Tr. ID	Date	Amount
12898	14-Oct-2003	−21
1234	12-Nov-2003	−12

(参见前文-基本概念：RVA)

数据库范式

(translated from https://en.wikipedia.org/wiki/Database_normalization)

UNF Unnomalized form

它可以处理复杂的数据结构。查询这个数据模型更简单。重组数据更容易。CRUD操作受到异常的困扰，如果处理不当，可能导致数据不一致。

ID	Name	Course
1	Jack	Mathematics, Chemistry
2	Tim	Chemistry
3	Ana	Physics,Chemistry

更少的数据冗余。

ID	Name	Course1	Course2
1	Jack	Mathematics	Chemistry
2	Tim	Chemistry
3	Ana	Physics	Chemistry

使用基于非规范化关系模型原理的NoSQL数据库来处理存储问题。一些NoSQL数据库的例子是MongoDB、Apache Cassandra和Redis。这些数据库具有更大的可伸缩性和更容易查询，因为它们不涉及像JOIN操作。

(参见前文重复组的概念)

1NF

概念：

There's no top-to-bottom ordering to the rows.(eg: the row-ordering is an intrinsic and meaningful aspect of the view)
There's no left-to-right ordering to the columns.
There are no duplicate rows.(eg: A table that lacks a unique key constraint.)
Every row-and-column intersection contains exactly one value from the applicable domain (and nothing else).(eg: A table with at least one nullable attribute. )
All columns are regular [i.e. rows have no hidden components such as row IDs, object IDs, or hidden timestamps].

relation-valued attributes are useful in rare cases: 关系属性在极少数情况下是有用的

电话号码列只是包含文本：不同格式的数字，而且其中两个客户的电话号码不止一个。

在这一列中，我们存在多重关联信息。但它并不是一堆杂乱无章的的文本信息：我们显然在一个record中存储了多个电话号码。这些电话号码违背了原子性。

电话号码的表示法违反了1NF形式：我们的列包含非原子值，而且包含不止一个非原子值。

客户ID	First Name	Surname	Telephone Number
123	Pooja	Singh	555-861-2025, 192-122-1111
456	San	Zhang	(555) 403-1659 Ext. 53; 182-929-2929
789	John	Doe	555-808-9633

这两个电话号码栏仍然构成一个“重复组”：他们重复了概念上相同的属性，即电话号码。

一个武断的、毫无意义的排序已经被引入：为什么555-861-2025将被放入电话号码1栏而不是电话号码2栏？如果有3个电话号码呢？检索一个电话号码需要检索任意数量的行？

添加一个额外的电话号码可能需要通过添加新栏目来重新组织表，而不是添加一个新的行（且表中存在null）。

客户ID	First Name	Surname	Telephone Number1	Telephone Number2
123	Pooja	Singh	555-861-2025	192-122-1111
456	San	Zhang	(555) 403-1659 Ext. 53	182-929-2929
789	John	Doe	555-808-9633

1 NF要求ID能够惟一地标识一行。

客户ID	First Name	Surname	Telephone Number
123	Pooja	Singh	555-861-2025
123	Pooja	Singh	192-122-1111
456	San	Zhang	(555) 403-1659 Ext. 53
456	San	Zhang	182-929-2929
789	John	Doe	555-808-9633

值得注意的是，这种设计满足了第二和第三范式的附加要求。

客户ID	First Name	Surname
123	Pooja	Singh
456	San	Zhang
789	John	Doe

ID	客户ID	Telephone Number
1	123	555-861-2025
2	123	192-122-1111
3	456	(555) 403-1659 Ext. 53
4	456	182-929-2929
5	789	555-808-9633

2NF

概念：a relation is in 2NF if it is in 1NF and no non-prime attribute is dependent on any proper subset of any candidate key of the relation.如果在1 NF中，并且任何非主键属性都不依赖于关系的候选键的任何真子集。 A non-prime attribute of a relation is an attribute that is not a part of any candidate key of the relation.关系的非主键属性：是一个属性，它不包含任何候选键。Put simply, a relation is in 2NF if it is in 1NF and every non-prime attribute of the relation is dependent on the whole of every candidate key. 简单地说，一个关系是2 NF如果它在1 N，并且任何非主键属性都依赖于每个全部候选键。

电动牙刷的模型

尽管设计者已经制定了型号全名作为主键。{厂商，型号}为候选主键。

厂商->厂商属地，厂商作为候选主键的真子集，这违背了2NF。

厂商	型号	型号全名	厂商属地
Forte	X-Prime	Forte X-Prime	Italy
Forte	Ultraclean	Forte Ultraclean	Italy
Dent-o-Fresh	EZbrush	Dent-o-Fresh EZbrush	USA
Kobayashi	ST-60	Kobayashi ST-60	Japan
Hoch	Toothmaster	Hoch Toothmaster	Germany
Hoch	X-Prime	Hoch X-Prime	Germany

应用2NF 使用电动牙刷厂商，电动牙刷模型两个关系

厂商	型号	型号全名
Forte	X-Prime	Forte X-Prime
Forte	Ultraclean	Forte Ultraclean
Dent-o-Fresh	EZbrush	Dent-o-Fresh EZbrush
Kobayashi	ST-60	Kobayashi ST-60
Hoch	Toothmaster	Hoch Toothmaster
Hoch	X-Prime	Hoch X-Prime

厂商	厂商属地
Forte	Italy
Dent-o-Fresh	USA
Kobayashi	Japan
Hoch	Germany

3NF

概念： is a normal form that is used in normalizing a database design to reduce the duplication of data and ensure referential integrity by ensuring that:-是一种范式，用于规范化数据库设计，以减少数据的重复，确保引用完整性，确保：（应用完整性：参见前文定义）

(1) the entity is in second normal form.符合第二范式的需求。

(2)Every non-prime attribute of R is non-transitively dependent on every key of R .R的每一个非主键属性都不隐式的（传递的）依赖于R的每一个键。参见传递依赖。

all the attributes in a table are determined only by the candidate keys of that relation and not by any non-prime attributes. 表中的所有属性仅由该关系的候选键决定，而不是由任何主键之外的属性决定。

3NF was designed to improve database processing while minimizing storage costs. 3NF data modeling was ideal for online transaction processing (OLTP)applications with heavy order entry type of needs.

3NF的设计目的是改进数据库处理性能，同时最小化存储成本。3NF数据建模对于具有大量订单输入类型的在线事务处理系统（OLTP）应用程序非常理想。

设计者，设计组合键{锦标赛，年份}作为主键。

冠军生日是传递依赖于候选键{锦标赛，年份}，{锦标赛，年份}->冠军--函数依赖-->冠军生日。

这使得表格很容易出现逻辑上的不一致，因为不能保证同一个冠军的生日一致。没有什么可以阻止同一个人在不同的记录上显示不同的出生日期。

锦标赛	年份	冠军	冠军生日
Indiana Invitational	1998	Al Fredrickson	1975.7.21
Cleveland Open	1999	Bob Albertson	1968.12.28
Des Moines Masters	1999	Al Fredrickson	1975.7.21
Indiana Invitational	1999	Chip Masterson	1977.4.14

有必要把这张表做如下拆分：

锦标赛	年份	冠军
Indiana Invitational	1998	Al Fredrickson
Cleveland Open	1999	Bob Albertson
Des Moines Masters	1999	Al Fredrickson
Indiana Invitational	1999	Chip Masterson

冠军	冠军生日
Bob Albertson	1968.12.28
Al Fredrickson	1975.7.21
Chip Masterson	1977.4.14

EKNF

主键范式概念： is a subtle enhancement on third normal form, thus EKNF tables are in 3NF by definition. This happens when there is more than one unique compound key and they overlap. Such cases can cause redundant information in the overlapping column(s). 是对第三范式的一种微妙的增强，因此EKNF表在定义上是3 NF。当有不止一个唯一的复合键时，多个复合键重叠时，就会发生这种情况。会导致重叠列（s）中的冗余信息。 A table is in EKNF if and only if all its elementary functional dependencies begin at whole keys or end at elementary key attributes. For every full non-trivial functional dependency of the form X→Y, either X is a key or Y is (a part of) an elementary key. 一个关系属于EKNF当且仅当：它的所有元素都是可由主键的函数依赖定义。对于关系中的所有完整的非平凡的函数依赖X-> Y，要么X是一个键要么是Y（一部分）子键。

(参见前文：候选键，超键，子键，主键，完整的函数依赖，平凡的函数依赖的定义)

BCNF

概念： It is a slightly stronger version of the third normal form (3NF). 它是（3 NF）的一个稍强的版本。If a relational schema is in BCNF then all redundancy based on functional dependency has been removed, although other types of redundancy may still exist. A relational schema R is in Boyce–Codd normal form if and only if for every one of its dependencies X → Y, at least one of the following conditions hold: 对于BCNF，删除了所有函数依赖造成的冗余，尽管其他类型的冗余可能仍然存在。关系模式R属于BoyceCodd范式，当且仅当它的每一个依赖项X-> Y中，至少符合以下条件中的一个：

X → Y is a trivial functional dependency (Y ⊆ X) X → Y是平凡的函数依赖Y ⊆ X
X is a superkey for schema R X是关系R的超键

只有在极少数情况下，3 NF表不符合BCNF的要求。即重叠候选键。

一个不符合BCNF的3 NF表的例子是：今天的场地预订

每一条记录代表网球俱乐部的场地预定，包括一号场地（干地），二号场地（草地）。

一个预定包含场地，和场地预定时间段。

额外的，每个预定包含四个费率类型。

表的所有超键：

S1 = {Court, Start Time}
S2 = {Court, End Time}
S3 = {Rate Type, Start Time}
S4 = {Rate Type, End Time}
S5 = {Court, Start Time, End Time}
S6 = {Rate Type, Start Time, End Time}
S7 = {Court, Rate Type, Start Time}
S8 = {Court, Rate Type, End Time}
ST = {Court, Rate Type, Start Time, End Time},平凡超键

注意,即使在下表开始时间和结束时间没有重复的值,我们必须承认在一周的其他天或者不同的场地可以有冗余的开始或结束时间。这就是为什么开始时间和结束时间不能被认为是表的超键的原因。

然而，只有S1、S2、S3和S4是候选键（即该关系的最小超级键），因为例如 S1 ⊂ S5，所以S5不能成为候选键。

回想2NF禁止局部依赖，3NF禁止传递依赖。现在的场地预订表中，没有非主键属性：也就是说，所有属性都属于某个候选键。因此，这张表同时遵循2 NF和3 NF。

依赖场地的服务档次→场地是存在的函数依赖，因为服务档次只能应用于其对应的特定场地。

该表不符合BCNF。这是因为档次→场地的依赖关系，在这种情况下，场地所依赖的决定因素属性档次——（1.）既不是候选键，也不是候选键的超集，（2）。场地不是服务档次的子集。

场地	开放时间	关闭时间	服务档次
1	09:30	10:30	SAVER，普通
1	11:00	12:00	SAVER，普通
1	14:00	15:30	STANDARD，标准
2	10:00	11:30	PREMIUM-B，高档
2	11:30	13:30	PREMIUM-B，高档
2	15:00	16:30	PREMIUM-A，高档

场地档次表。

场地档次表的候选键是{服务档次}和{场地、会员标志};当天预订表的候选键是{场地、开放时间}和{场地、关闭时间}。这两个表都遵循BCNF原则。当{服务档次}是场地档次表中的一个键时，一个场地的{服务档次}关联两个不同的{场地}是不可能的，所以通过在场地服务档次表中使用服务档次作为键，就消除了影响原始场地预定表的异常。

服务档次	场地	会员
SAVER	1	Yes
STANDARD	1	No
PREMIUM-B	2	Yes
PREMIUM-A	2	No

当天预订

会员	场地	开放时间	关闭时间
Yes	1	09:30	10:30
Yes	1	11:00	12:00
No	1	14:00	15:30
No	2	10:00	11:30
No	2	11:30	13:30
No	2	15:00	16:30

无法分解为BCNF范式的情况：In some cases, a non-BCNF table cannot be decomposed into tables that satisfy BCNF and preserve the dependencies that held in the original table. Beeri and Bernstein showed in 1979 that, for example, a set of functional dependencies {AB → C, C → B} cannot be represented by a BCNF schema. 在某些情况下，非BCNF表不能分解为满足BCNF的表，并保留原始表中持有的相依性。Beeri和Bernstein在1979年表明。栗如：如下函数依赖 {AB → C, C → B}不能用BCNF模式表示。

Eg:

我们简单地假设一个商店只属于某一种类型。

对于任何个人/商店类型的组合，表格告诉我们在地理位置上离这个人的家最近的这类商店是哪一个。

这个关系的候选键位 {个人，商店类型}、{个人，附近的商店}

因为这三个属性都是键属性（即属于候选键），所以表，符合3 NF范式。然而，表不符合BCNF，因为商店类型属性在函数依赖于非超键：最近的商店。即为附近的商店→商店类型。

个人附近的商店表：

个人	商店类型	附近的商店
Davidson	Optician 眼睛商	Eagle Eye
Davidson	Hairdresser 美发师	Snippets
Wright	Bookshop 书店	Merlin Books
Fuller	Bakery 面包店	Doughy's
Fuller	Hairdresser美发师	Sweeney Todd's
Fuller	Optician眼睛商	Eagle Eye

违反BCNF意味着表受到异常的影响。例如，Eagle Eye可能会将其商店类型改为“配镜师”，并在 “Davidson”记录中保留商店类型的“眼镜商”。这就暗示了这个问题的答案：“Eagle Eye的商店类型是什么？”每家商店的商店类型只保留一份似乎更可取，因为这样做可以防止这种反常现象的发生：

在这个修改后的设计中，“个人附近商店”的关系中有{个人，商店}的候选键，而“商店”关系中有一个{商店}候选键。不幸的是，尽管这种设计遵循BCNF，但它在另一方面又是不可接受的：它允许我们记录个人附件的同一类型的多个商店,而不一定是最近的商店。换句话说，它的候选键丢失了函数依赖：{个人，商店类型} → {商店}。

个人附件的商店表：

个人	附近的商店
Davidson	Eagle Eye
Davidson	Snippets
Wright	Merlin Books
Fuller	Doughy's
Fuller	Sweeney Todd's
Fuller	Eagle Eye

商店表

附近的商店	商店类型
Eagle Eye	Optician 眼睛商
Snippets	Hairdresser 美发师
Merlin Books	Bookshop 书店
Doughy's	Bakery 面包店
Sweeney Todd's	Hairdresser美发师

一种消除所有这些异常（但不符合BCNF）的设计是可能的。该设计引入了一种新的标准形式，称为EKNF范式。这个设计由最初的“个人附近的商店表”表，并补充上面描述的“商店”表组成。由Bernstein模式生成算法生成。表结构实际上是EKNF，尽管在设计算法的时候，对3 NF的增强还没有被提出出来：

个人附近的商店表：

个人	商店类型	附近的商店
Davidson	Optician 眼睛商	Eagle Eye
Davidson	Hairdresser 美发师	Snippets
Wright	Bookshop 书店	Merlin Books
Fuller	Bakery 面包店	Doughy's
Fuller	Hairdresser美发师	Sweeney Todd's
Fuller	Optician眼睛商	Eagle Eye

商店表：

附近的商店	商店类型
Eagle Eye	Optician 眼睛商
Snippets	Hairdresser 美发师
Merlin Books	Bookshop 书店
Doughy's	Bakery 面包店
Sweeney Todd's	Hairdresser美发师

（附录： 3NF过程，也就是所谓的Bernstein算法？如何构建BCNF范式的关系，见前文3NF构建过程）

4NF

概念：4NF is concerned with a more general type of dependency known as a multivalued dependency. A table is in 4NF if and only if, for every one of its non-trivial multivalued dependencies X-->>Y, X is a superkey—that is, X is either a candidate key or a superset thereof. 4NF关注的是一种更为一般的依赖类型，即多值依赖性。一个关系符合4 NF范式当且仅当，对于每一个非平凡的多值依赖X-->>Y，X是一个超键，也就是说，理论上X要么是一个候选键，要么是一个超键。

多值依赖：A multivalued dependency X-->> Y signifies that if we choose any x actually occurring in the table (call this choice xc), and compile a list of all the xcyzcombinations that occur in the table, we will find that xc is associated with the same y entries regardless of z. So essentially the presence of z provides no useful information to constrain the possible values of y. 多值依赖性X->>Y表示，如果表中存在任意一条记录包含x，例举表中出现的所有xyz组合的列表，我们会发现xc与相同的y项相关联，而与z无关。所以本质上，z的存在没有提供任何有用的信息，来约束y的可能值。

一个多值依赖 X -->>Y is one where either Y is a subset of X, or X and Y together form the whole set of attributes of the relation. 是Y是X的子集，或者X和Y一起构成了关系的集合的全部元素

博主默默的写下了R = {((x, y), z) | 关系的全部元素=关系(x, y) 与z的关系 }。？嗯~看上去还行。

A functional dependency is a special case of multivalued dependency. In a functional dependency X → Y, every x determines exactly one y, never more than one. 函数依赖是多值依赖性的特殊情况。在函数依赖关系X Y中，每一个X决定一个Y，永远不会多于一个Y。

每一行表明，一个给定的餐厅可以向给定的区域提供特定种类的披萨。

这个关系没有非键属性，因为它唯一的键{餐厅、披萨品种、送货区域}。因此，它符合包含BCNF在内的及其以下的所有的范式。然而，如果我们假设一家餐厅提供的披萨品种不受送货区的影响（例如，一家餐厅向所有区域提供它所供应的所有比萨品种），那么它就不符合4 NF。问题的根源是，该表对餐馆属性的两个非平凡的多值依赖关系（这不是一个超级键）。这两个多值依赖关系是:

{餐厅} –>> {比萨品种} （一个餐厅有多个披萨品种因此这是一个非函数依赖配送区域同理）

{餐厅} –>> {配送区域}

这些非超键的多值依赖关系反映了一个事实，即餐馆提供的比萨品种与餐厅提供的区域是独立的。这种情况导致了关系上的冗余：例如，我们被告知，A1 Pizza有Stuffed Crust品种，如果A1披萨开始生产Cheese Crust pizzas，那么我们将需要添加多行，每一排都是A1 Pizza的送货区域。此外，没有什么可以阻止我们，在A1 Pizza的配送区域中添加Cheese Crust pizzas，从而，违背了多值依赖{餐厅} –>> {比萨品种}。

披萨派送单表：

餐厅	比萨品种	配送区域
A1 Pizza	Thick Crust	Springfield
A1 Pizza	Thick Crust	Shelbyville
A1 Pizza	Thick Crust	Capital City
A1 Pizza	Stuffed Crust	Springfield
A1 Pizza	Stuffed Crust	Shelbyville
A1 Pizza	Stuffed Crust	Capital City
Elite Pizza	Thin Crust	Capital City
Elite Pizza	Stuffed Crust	Capital City
Vincenzo's Pizza	Thick Crust	Springfield
Vincenzo's Pizza	Thick Crust	Shelbyville
Vincenzo's Pizza	Thin Crust	Springfield
Vincenzo's Pizza	Thin Crust	Shelbyville

为了消除这些反常现象的可能性，我们必须将提供的品种的事实与交付区域的事实放在不同的表中，产生两个表，它们都符合4 NF：

餐厅派送披萨品种表：

餐厅	比萨品种
A1 Pizza	Thick Crust
A1 Pizza	Stuffed Crust
Elite Pizza	Thin Crust
Elite Pizza	Stuffed Crust
Vincenzo's Pizza	Thick Crust
Vincenzo's Pizza	Thin Crust

与此相反，如果餐厅提供的披萨品种有时在不同的送货区域之间有合理的差异，那么原来的{餐厅，披萨品种，配送区域}披萨派送单表就能满足4 NF的要求。

餐厅派送区域表：

餐厅	配送区域
A1 Pizza	Springfield
A1 Pizza	Shelbyville
A1 Pizza	Capital City
Elite Pizza	Capital City
Vincenzo's Pizza	Springfield
Vincenzo's Pizza	Shelbyville

Ronald Fagin证明了实现4 NF总是可能的。

ETNF

Wikipedia上没有定义。

5NF

概念：also known as project-join normal form (PJ/NF) 也称为连接范式。is a level of database normalization designed to reduce redundancy in relational databases recording multi-valued facts by isolating semantically related multiple relationships. 是一种数据库标准化级别，旨在减少关系数据库中的冗余，通过隔离的语义相关的多个关系来记录多值的因素。A table is said to be in the 5NF if and only if every non-trivial join dependency in that table is implied by the candidate keys. 当且仅当表中每个非平凡的连接依赖都是由候选键为条件的，那么该表被认为是满足5 NF。

A join dependency *{A, B, … Z} on R is implied by the candidate key(s) of R if and only if each of A, B, …, Z is a superkey for R .

一个在关系R上定义的连接依赖*{A, B, … Z}，是由R的候选键（s）为条件的，当且仅当这个连接依赖的每个元素A B…Z，都是R的超键。

主键是所有三列的组合。还要注意，该表位于4 NF中，因为表中没有多值依赖项（2个元素的连接依赖项）：没有列（它本身不是候选键或超键）是其他两列的决定因素。

在没有任何限制行商、品牌和产品类型的有效组合的规则的情况下，为了正确地对情况进行建模，上述三属性表是必需的。

由行商销售人员提供，指定的品牌，指定类型的产品表：

(博主亲自上阵写的关系代数式：R = {(行商，品牌，产品类型) | 指定行商销售品牌产品})

(关系代数参考博主的其他博文：暂时没有时间翻译，嘿嘿~)

行商	品牌	产品类型
Jack Schneider	Acme	Vacuum Cleaner
Jack Schneider	Acme	Breadbox
Mary Jones	Robusto	Pruning Shears
Mary Jones	Robusto	Vacuum Cleaner
Mary Jones	Robusto	Breadbox
Mary Jones	Robusto	Umbrella Stand
Louis Ferguson	Robusto	Vacuum Cleaner
Louis Ferguson	Robusto	Telescope
Louis Ferguson	Acme	Vacuum Cleaner
Louis Ferguson	Acme	Lava Lamp
Louis Ferguson	Nimbus	Tie Rack

然而，假设以下规则适用：行商在他们的零担中有特定的品牌和特定的产品类型。如果品牌B1和品牌B2在他们的零担中销售,产品类型P在他们的零担中销售,那么(假设品牌B1和B2两品牌都生产产品类型P), 行商的零担中必定卖那些由品牌B1和B2生产的产品P。我们可以把表分解为三个关系:

在这种情况下，Louis Ferguson卖Acme所做的任何东西，他还出售任何其他品牌（Robusto）制造的真空吸尘器。他也一定出售由ACME（阿克米）制造的Vacuum Cleaners(假设ACME生产真空吸尘器)。

请注意这个设置是如何帮助消除冗余的。假设杰克施耐德开始销售Robusto的产品Breadboxes和Vacuum Cleaners。在之前的设置中我们需要为每种产品类型添加两条新纪录(<Jack Schneider, Robusto, Breadboxes>, <Jack Schneider, Robusto, Vacuum Cleaners>)。有了新的设置，我们只需要在行商出售的品牌表中添加一条记录(<Jack Schneider, Robusto>)。

行商出售的货品种类表：

行商	产品类型
Jack Schneider	Vacuum Cleaner
Jack Schneider	Breadbox
Mary Jones	Pruning Shears
Mary Jones	Vacuum Cleaner
Mary Jones	Breadbox
Mary Jones	Umbrella Stand
Louis Ferguson	Vacuum Cleaner
Louis Ferguson	Telescope
Louis Ferguson	Lava Lamp
Louis Ferguson	Tie Rack

行商出售的品牌表：

行商	品牌
Jack Schneider	Acme
Mary Jones	Robusto
Louis Ferguson	Robusto
Louis Ferguson	Acme
Louis Ferguson	Nimbus

品牌供应商生产的产品表：

品牌	产品类型
Acme	Vacuum Cleaner
Acme	Breadbox
Acme	Lava Lamp
Robusto	Pruning Shears
Robusto	Vacuum Cleaner
Robusto	Breadbox
Robusto	Umbrella Stand
Robusto	Telescope
Nimbus	Tie Rack

（split table 关系的无损分解：见前文定义）

只有在极少数情况下，4 NF表不符合5 NF。在这些情况下，在这个表的结构中，在4 NF表中管理属性值的有效组合的复杂的实际约束并不是隐式的。如果这样的表不被规范化为5 NF，维护表内数据的逻辑一致性的负担必须部分由负责插入、删除和更新的应用程序承担; 而且，表内的数据会变得不一致，这是一个更高的风险。相比之下，5 NF的设计排除了这种不一致的可能性。

表T位于第五范式（5 NF）或连接范式（PJNF），如果不能将无损分解成任意数量的小表。在这种情况下，在分解后的所有较小的表都有与表T相同的候选键。

DKNF-域键范式

概念：is a normal form used in database normalization which requires that the database contains no constraints other than domain constraints and key constraints.是数据库规范化中使用的一种范式，它要求数据库不包含除域约束和键约束之外的约束。

A domain constraint specifies the permissible values for a given attribute, while a key constraint specifies the attributes that uniquely identify a row in a given table.域约束指定给定属性的允许值，而键约束指定唯一标识给定表中行的属性。

The domain/key normal form is achieved when every constraint on the relation is a logical consequence of the definition of keys and domains, and enforcing key and domain restraints and conditions causes all constraints to be met. Thus, it avoids all non-temporal anomalies.当关系的每个约束都是键和域定义的逻辑结果时，并且键约束和域约束条件覆盖所有约束，就会实现域/键正常形式。因此，它避免了所有非暂时性的异常。

The reason to use domain/key normal form is to avoid having general constraints in the database that are not clear domain or key constraints. Most databases can easily test domain and key constraints on attributes. General constraints however would normally require special database programming in the form of stored procedures (often of the trigger variety) that are expensive to maintain and expensive for the database to execute. Therefore, general constraints are split into domain and key constraints.使用域/键范式的原因是为了避免在数据库中有而不是域/键约束的通用约束。大多数数据库可以很容易地测试域和属性的键约束。然而，一般的约束通常需要以存储过程（通常是触发器类型）的形式进行特殊的数据库编程，而这些程序的维护成本很高，而且数据库的执行成本很高。因此，一般约束被划分为域和键约束。

It's much easier to build a database in domain/key normal form than it is to convert lesser databases which may contain numerous anomalies. However, successfully building a domain/key normal form database remains a difficult task, even for experienced database programmers. Thus, while the domain/key normal form eliminates the problems found in most databases, it tends to be the most costly normal form to achieve. However, failing to achieve the domain/key normal form may carry long-term, hidden costs due to anomalies which appear in databases adhering only to lower normal forms over time.用域/键范式构建数据库要比转换那些可能包含大量不规则的不好的数据库要容易得多。然而，即使对于有经验的数据库程序员来说，成功构建一个域/键范式的数据库仍然是一项艰巨的任务。因此，虽然域/键范式消除了大多数数据库中发现的问题，但它往往是最昂贵的范式。然而，由于在数据库中出现的异常情况，无法实现域/键的正常形式可能会带来长期的隐性成本，这些异常会随着时间的推移而拉低数据库的范式。

The third normal form, Boyce–Codd normal form, fourth normal form and fifth normal form are special cases of the domain/key normal form. All have either functional, multi-valued or join dependencies that can be converted into (super)keys. The domains on those normal forms were unconstrained so all domain constraints are satisfied. However, transforming a higher normal form into domain/key normal form is not always a dependency-preserving transformation and therefore not always possible.第3范式，BCNF范式，第四范式和第五范式是域/键范式的特殊情况。它们包含函数依赖、多值依赖或连接依赖，可以转换成（超）键。这些范式的域不受约束，因此所有域约束都得到满足。然而，将一个更高的范式转换成域/键范式并不总是一个依赖于保持的无损分解转换，因此并不总是可行的。

尽管我们不能从身价中推断出富豪类型，但有一个约束将富人的类型与身价联系起来。这一限制规定，一个古怪的百万富翁或邪恶的百万富翁的净资产将达到100万至一亿以下，而一个古怪的亿万富翁或邪恶的亿万富翁的净资产将达到1亿或更高。这个约束既不是域约束也不是键约束;因此，我们不能依赖于域约束和键约束来保证不一致的富豪类型/身价组合不会进入数据库。

富豪表：

富豪	富豪类型	身价
Steve	Eccentric Millionaire	124,543,621
Roderick	Evil Billionaire	6,553,228,893
Katrina	Eccentric Millionaire	8,829,462,998
Gary	Evil Billionaire	495,565,211

通过改变富豪的类型属性，使其只包含两个值，“邪恶”和“古怪”（富人的百万富翁或亿万富翁的地位隐含在他们的身价中，因此没有任何有用的信息丢失），可以消除DKNF的违规行为。

富豪表：

富豪	富豪类型	身价
Steve	Eccentric	124,543,621
Roderick	Evil	6,553,228,893
Katrina	Eccentric	8,829,462,998
Gary	Evil	495,565,211

豪的程度表：

程度	最小身价	最大身价
Millionaire	1,000,000	999,999,999
Billionaire	1,000,000,000	999,999,999,999

外键：不能建立外键的关系是明显违反DKNF的。例如，一个“Parent ID”属性指向多个参照表中的一个，具体指向哪一个表，这取决于第二个属性“Parent Type”，这违反了DKNF。

6NF

概念：defined sixth normal form as a normal form, based on an extension of the relational algebra根据关系代数的扩展，将第六范式定义为一种范式。Relational operators, such as join, are generalized to support a natural treatment of interval data, such as sequences of dates or moments in time, for instance in temporal databases.关系运算符，例如join，被泛化为支持对区间数据的处理，例如时间序列或时刻数据，例如在时态数据库中。Sixth normal form is then based on this generalized join, as follows: 然后，根据这个广义的连接，第六范式的形式如下：

A relvar R [table] is in sixth normal form (abbreviated 6NF) if and only if it satisfies no nontrivial join dependencies at all — where, as before, a join dependency is trivial if and only if at least one of the projections (possibly U_projections) involved is taken over the set of all attributes of the relvar [table] concerned. 一个关系（relvar） R表满足第六范式（缩写为6 NF），当且仅当它没有任何非平凡的连接依赖项时——与以前一样，当且仅当，至少有一个投影（可能是全局投影）包含与关系R相关的所有属性时，那么这个连接依赖平凡的。

Date等人也给出了以下定义：Relvar R是第六范式（6 NF）当且仅当R的每一个JD[连接依赖]都是平凡的——在这里，一个JD是平凡的当且仅当它的一个组件与相关R的head完全相等时。

6 NF中的任何关系也在5 NF中。

第六范式的目的是将关系变量分解为不可约的组件。尽管对于经典关系变量（非时态关系变量）来说，这可能相对不重要，但在处理时间变量或其他区间数据时，它可能很重要。例如，如果一个关系由供应商的名称、状态和城市组成，我们可能还想添加时间数据，比如这些值是有效的（例如，对于历史数据），但是这三个值可能会彼此独立，并且以不同的速率变化。例如，我们可能希望追溯改变状态的历史; 对生产成本的审查可能会发现，一个变化是由一个供应商变更城市引起的费用的变化。

第六种范式目前正在一些数据仓库中使用，其好处超过了缺点。例如，使用锚点模型。尽管使用6 NF会导致表的爆炸式增长，但是现代数据库可以在不需要它们的地方，从select查询中删除表（使用一个叫做“表消除”的过程），因此加快了只访问几个属性的查询。

为了使表在6 NF中，它必须先遵守5个NF，然后它要求每个表只满足简单的连接依赖项。让我们用一个简单的例子11，在5 NF中有一个表：这里，在users表中，每个属性都是非空的，主键是用户名：

用户表：

用户名

所在部门

状态

这张表在5 NF中，因为每个连接依赖都是由表的唯一候选键（用户名）作为条件的。更具体地说，唯一可能的连接依赖项是：{用户名，状态}，{用户名，所在部门}。

6NF无损分解，用户表：

用户名

状态

用户_部门表：

用户名

所在部门

因此，从5 NF的一个表中，6 NF产生了两个表。

另一个我们可以演示6 NF的例子是当我们观察被占据的空间时。为此，我们选择了这个表：

医疗领域包含了几个专业术语。他们是：住院医生-研究生-专家。

要想晋升到更高的职位，需要几年的时间才能进行必要的实践。如果一个医生在其领域实践时间少于规定的时间，他或她就不能在等级上提升。例如：如果整形外科医生Miller Michael在医疗领域工作了3年零11个月，他将无法成为一名整形专家，因为从研究生到专家的最低期限是4年。

从一个职位到另一个职位的转变是基于考试的。考试要求从一年级到另一年级（例如：从研究生到专家），可以在4年之后进行。

医师表：

医师名字	科室	职称	年资
Smith James	orthopedic	specialist	23
Miller Michael	orthopedic	probationer	4
Thomas Linda	neurologist	probationer	5
Scott Nancy	orthopedic	resident	1
Allen Brian	neurologist	specialist	12
Turner Steven	ophthalmologist	probationer	3
Collins Kevin	ophthalmologist	specialist	7
King Donald	neurologist	resident	1
Harris Sarah	ophthalmologist	resident	2

为表1应用6 NF的下一步是消除所有非平凡的连接依赖项。

医师表：

医师名字	科室	年资
Smith James	orthopedic	23
Miller Michael	orthopedic	4
Thomas Linda	neurologist	5
Scott Nancy	orthopedic	1
Allen Brian	neurologist	12
Turner Steven	ophthalmologist	3
Collins Kevin	ophthalmologist	7
King Donald	neurologist	1
Harris Sarah	ophthalmologist	2

职称表：

职称	最低年资	最高年资
resident	0	2
probationer	3	5
specialist	6	45

现在我们将展示从5 NF到6 NF也减少了表所占用的空间。在括号中，它表示表中每个字段占用多少空间（以字节为单位）。= [366] (bytes)

医师名字	科室	职称	年资
Smith James[12]	orthopedic[11]	specialist[11]	23[4]
Miller Michael[15]	orthopedic[11]	probationer[12]	4[4]
Thomas Linda[13]	neurologist[12]	probationer[12]	5[4]
Scott Nancy[12]	orthopedic[11]	resident[9]	1[4]
Allen Brian[12]	neurologist[12]	specialist[11]	12[4]
Turner Steven[14]	ophthalmologist[16]	probationer[12]	3[4]
Collins Kevin[14]	ophthalmologist[16]	specialist[11]	7[4]
King Donald[12]	neurologist[12]	resident[9]	1[4]
Harris Sarah[13]	ophthalmologist[16]	resident[9]	2[4]

我们可以看到，表1，在5 NF中，总共占用了366字节。这个表被翻译成6个NF将由表表2.1和表2.2组成。最后两个将占用326个字节。

医师表（326 bytes）

医师名字	科室	年资
Smith James[12]	orthopedic[11]	23[4]
Miller Michael[15]	orthopedic[11]	4[4]
Thomas Linda[13]	neurologist[12]	5[4]
Scott Nancy[12]	orthopedic[11]	1[4]
Allen Brian[12]	neurologist[12]	12[4]
Turner Steven[14]	ophthalmologist[16]	3[4]
Collins Kevin[14]	ophthalmologist[16]	7[4]
King Donald[12]	neurologist[12]	1[4]
Harris Sarah[13]	ophthalmologist[16]	2[4]

职称表270 bytes

职称	最低年资	最高年资
resident[9]	0[4]	2[4]
probationer[12]	3[4]	5[4]
specialist[11]	6[4]	45[4]

我们可以看到，在这个例子中，6 NF占用的少于5 NF（更具体，更少的40字节）。进入6 NF减少了被占用的空间。如果初始表更大，进入6 NF之后，空间的缩小也会更大。

但是在实践中，信息分离使得多个表中的行开销占用了更多的空间。但是，它并没有降低灵活性、一致性和查询复杂度。

其他问题

	UNF (1970)	1NF (1971)	2NF (1971)	3NF (1971)	EKNF (1982)	BCNF (1974)	4NF (1977)	ETNF (2012)	5NF (1979)	DKNF (1981)	6NF (2003)
Primary key
No repeating groups
Atomic columns
No partial dependencies
No transitive dependencies
Every non-trivial functional dependency involves either a superkey or an elementary key's subkey											N/A
No redundancy from any functional dependency											N/A
Every non-trivial, multi-value dependency has a superkey											N/A
A component of every explicit join dependency is a superkey											N/A
Every non-trivial join dependency is implied by a candidate key											N/A
Every constraint is a consequence of domain constraints and key constraints											N/A
Every join dependency is trivial

表格来自维基百科

数据库重构：数据库重构是对数据库模式的一个简单的更改，它改进了它的设计，同时保留了它的行为和信息语义。在概念上，数据库重构比代码重构更困难;代码重构只需要维护行为语义，而数据库重构也必须维护信息语义。

数据库重构的过程是应用数据库重构来演进现有的数据库模式（数据库重构是进化数据库设计的核心实践）。您重构数据库模式的原因有两个：以一种渐进的方式开发模式，与系统的其他部分的演进设计并行，或者用现有的遗留数据库模式修复设计问题。

数据库重构不会改变数据解释或使用的方式，也不会修复bug或添加新功能。对数据库的每次重构都会使系统处于工作状态，因此不会造成维护滞后，只要在生产环境中存在有意义的数据。

数据库重构的一个例子是在数据库标准化过程中将一个聚合表分割成两个不同的表

反范式化：

反规范化的意思：

什么不是反规范化：

反规范化的害处：

正交分解：