查了查数据库的只是,忘了好多。
如果一个关系模式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,所以这些理论,你只需要姑且读之。