关于数据库范式

查了查数据库的只是，忘了好多。

如果一个关系模式R的所有属性都是原子的，即不可再分的基本数据项，则RÎ1NF。

ID	Artist	FavoriteColor	……
1	Babyface	Blue,Yellow	……
2	Sting	Green	……

对上例我们不能把它拆分成FavoriteColor1、FavoriteColor2……因为首先我们不能确定该拆分成几列；其次FavoriteColor1与FavoriteColor2在结构、含意方面都是相同的，这实际上也是一类“repeating group”；同时这种设计会导致某些查询困难，比如“有哪些艺人喜欢黄色？”

解决方案是将表拆分成两个：

ID	Artist	……
1	Babyface	……
2	Sting	……

ID	FavoriteColor
1	Blue
1	Yellow
2	Green

“2NF针对的是复合候选键（即键包含的字段个数>1）的情况，非主属性不能只依赖于复合候选键中的一部分字段。”显然，如果是非复合候选键，如果它符合1NF，那么它一定符合2NF。

假设有这样一张涉及艺人与唱片公司的关系表：

Artist 艺人	Company 唱片公司	DurationYears 签约总年数	CompAddr 公司住址
Babyface	Solar	4	Indiana
Babyface	Laface	2	Indiana

显然，{Artist,Company}为可以作为一个候选键，DurationYears在这没有问题，但CompAddr是违反2NF的，它只依赖于候选键的一部分（依赖于Company），这是违反2NF的，为了消除这种情况，我们可以：

Artist 艺人	CompID 唱片公司	DurationYears 签约总年数
Babyface	1	4
Babyface	2	2

ID	Company 唱片公司	CompAddr 公司住址
1	Solar	Indiana
2	Laface	Indiana

总结： 

对于2NF，如果关系中的候选键只包含一个属性，可以直接略过。 

 

在考虑2NF的过程中，不要把几个无关的实体的属性杂揉放在一个关系中，比如Artist是一个实体、Company是一个实体，它们可以有一系列的关联表（也是实体），但在关联表中尽量不要引入前两个实体的无关属性。 

3NF(Third normal form)

Every non-prime attribute is non-transitively dependent on every key of the table.

不存在非主属性对任一键（候选键）的传递依赖。

传递依赖，你可以顾名思义，这里就不再引入定义了，举个例子，有下面一张表：

Tournament 赛事	Year 年份	Winner 冠军	Winner Date of Birth 冠军生日
Indiana Invitational	1998	Al Fredrickson	21 July 1975
Cleveland Open	1999	Bob Albertson	28 September 1968
Des Moines Masters	1999	Al Fredrickson	21 July 1975
Indiana Invitational	1999	Chip Masterson	14 March 1977

这里的候选键为{Tournament,Year}，显然有这样的决定关系：

{Tournament,Year}→Winner

{Tournament,Year}→Winner→Winner Date of Birth

其中第二条就属于违反3NF的情况，因为Winner Date of Birth依赖于Winner而不是直接依赖于候选键。这种情况下，可以将Winner,Winner Date of Birth单独作为一张表，这里不赘述。

总结： 

我觉得大多数人凭借直观感觉，就可使设计的关系符合3NF，所以这些理论，你只需要姑且读之。