规定关系
第一范式规定关系的每一个分量必须是一个不可分的数据项。
非第一范式的例子如表5-5,可以转换为第一范式如表5-6。
表5-5
表5-6
几乎所有的商用关系DBMS都要求关系为第一范式,现在流行的关系数据库语言,如SQL,也都只支持第一范式。
如果关系仅仅满足第一范式的条件是不够的,可能会存在更新异常。为了消除这些异常,需要进行关系的规范化。
关系模式实例
下面是满足第一范式的(不好的)
关系模式的例子。例如:设有一
关系模式R(S#,C#,G,TN,D),其中(S#)为学号,C#为课程号,G为成绩,TN为任课教师姓名,D为教师所在系名,这些数据具有下列语义:
(1) 学号是一个学生的标识,课程号是一门课程的标识。
(2) 一位学生所修的每门课程都有一个成绩。
(3) 每门课程只有一位任课教师,但一位教师可以教多门课。
(4) 教师中没有重名,每位教师只属于一个系。
下面是一个具体关系实例的数据,如表5-7:
表5-7
学号
S#
|
课程号
C#
|
成绩
G
|
教师
TN
|
系名
D
|
s1
|
c1
|
g1
|
t1
|
d1
|
s1
|
c2
|
g2
|
t2
|
d2
|
s2
|
c1
|
g3
|
t1
|
d1
|
s2
|
c2
|
g4
|
t2
|
d2
|
s3
|
c2
|
g5
|
t2
|
d2
|
s3
|
c3
|
g6
|
t2
|
d2
|
虽然上述的
关系模式只有四个属性,但它是一个不好的
关系模式,因为该模式在使用过程中有以下几个问题:
(1) 数据冗余。例如,教师所在系名对选该教师所开课的所有学生都重复输入一次。
(2) 插入异常。由于关系的主键{S#, C#} 不能为空值,如果一个教师不教课,则这位教师的姓名及所属的系名就不能插入表中。
(3) 删除异常。如果所有学生都退选某一门课,则有关该门课的其它数据(任课教师名及所在系名)也将被删除。
(4) 修改异常。如果改变一门课的任课教师,则需要修改表中选修该门课程的多行记录,如果部分修改,部分不修改,则会导致数据的不一致。
根据上述示例说明的语义,找出有下面的函数依赖集合F:
F = { {S#, C#}→ G,C#→TN,TN → D}
图 5-2
针对函数依赖集合,运用关系数据库设计理论,可以对上述关系进行分解,得到3个
关系模式如下:
SCG(S#, C#, G)
CTN(C#, TN)
TND(TN, D)
上述3个关系可以消除数据冗余,插入异常,删除异常和修改异常等现象。是一个比较好的关系模式。把原来一个关系表的数据分解为三个关系表存放。
具体的关系实例的数据如表5-8:
表5-8
S#
|
C#
|
G
|
s1
s1
s2
s2
s3
s3
|
c1
c2
c1
c2
c2
c3
|
g1
g2
g3
g4
g5
g6
|
对于上述示例,是满足第一范式的
关系模式,但它不是一个好的关系模式,存在数据冗余和操作异常现象。通过分析模式属性间的函数依赖关系,把一个模式分解为三个
关系模式后,消除了数据冗余和操作异常。对于任一给定的模式,如何判断是一个好的还是不好的
关系模式呢?又如何把一个不好的关系模式分解转换为好的关系模式呢?这就是在下面要讨论的问题,对关系模式中X→Y的函数依赖关系,给出不同程度的限制,得到满足不同范式要求的模式。