3.3.2 第二范式

满足第一范式的关系仍然存在数据库设计的异常问题，下面通过例子分析之。

【例3-6】供应商和它所提供的零件信息，关系模式如下。

FIRST （sno，sname，status，city，pno，qty），各属性的含义分别表示供应商号、供应商名称、供应商状态、供应商所在城市、零件号、零件数量，并且有函数依赖

F＝{sno→sname，sno→status，status→city，（sno，pno）→qty}

具体的关系如表3-3所示。

从表3-3可以看出，每个分量都是不可再分的数据项，所以是第一范式。

然而，第一范式会带来以下4个问题。

(1) 冗余度大。例如，每个供应商的sno、sname、status、city要与零件的种类一样多。

(2) 更新异常。例如，供应商S1从“天津”搬到“上海”，若稍不注意，就会使一些数据被修改，而另一些数据没有被修改，导致数据修改的不一致。

(3) 插入异常。若某个供应商的其他信息未提供，如“零件号”，则不能进行插入操作。

(4) 删除异常。若供应商S4的P2零件销售完了，删除后，在基本关系FIRST中将找不到S4，可S4又是客观存在的。

上述这些异常问题的原因在于，关系模式中非主属性 status 部分依赖于组合关键字 （sno，pno），即（sno，pno）status。

正因为上述原因引入了第二范式（2NF）。

若关系模式R∈1NF，且每个非主属性完全依赖于码，则关系模式R∈2NF，即当第一范式消除了非主属性对码的部分函数依赖，就可成为第二范式。

【例3-7】FIRST关系的码是（sno，pno），而sno→status，因此非主属性status部分函数依赖于码，故不是第二范式。

解：若此时将FIRST关系分解为：FIRST1（sno，sname，status，city）∈2NF；FIRST2 （sno，pno，qty）∈2NF

则FIRST1和FIRST2中的码分别为sno和sno，pno，每个非主属性完全依赖于码。

【例3-8】设有关系模式S（S#, C#, GRADE, TNAME, TADDR），各属性的含义分别表示学号、课程号、成绩、教师姓名和教师地址。（S#, C#）是S的候选键。试讨论关系模式S是否属于第二范式。如果不是，如何进行分解并使之符合第二范式的要求?

解：根据语义，S上有两个FD：（S#, C#）→（TNAME, TADDR, GRADE）和C#→（TNAME, TADDR）。显然，前一个函数依赖是部分依赖，因此S不是第二范式。

因此可以把S分解成两个关系模式S1（C#, TNAME, TADDR）和S2（S#, C#, GRADE），消除部分依赖，S1和S2都是第二范式模式。

【例3-9】设有关系模式S（S#, SN, SA, SS, SD, DN, C#, GR），各属性的含义分别为学号、姓名、年龄、性别、系名、地址、课程号、成绩。将该关系模式转换成第二范式。

解：(1) S的主关键字是（S#, C#），对此关键字存在着部分函数依赖的非主属性有SN、SA、SS、SD、DN（均依赖于S#），而GR对主关键字是完全函数依赖。

(2) 将S分解成两种模式：SR（S#, SN, SA, SS, SD, DN）；SC（S#, C#, GR）

若在一个关系中所有候选码都是单属性，就不可能存在部分依赖，它肯定是属于第二范式。只有当候选码是组合属性时，才有可能存在部分函数依赖，才需要判断和消除部分函数依赖，通过分解达到第二范式。

推论 当关系模式的所有候选码都是单属性时，该关系模式一定属于第二范式。