数据库重点复习

关系模式 SLC(Sno, Sdept, Sloc, Cno, Score)，其中Sno为学号、Sdept为系别、Sloc为学生住处，并且每个系的学生住在同一个地方。Cno为课程号、Score 为学生成绩。其中每个学生可以选修多门课程，一门课程可以被多个学生选修。一个学生选定一门课程后就会产生一个成绩。根据语义，码为属性组合（Sno、Cno）。函数依赖图如下：

图中用虚线表示部分函数依赖。可以看到非主属性 Sdept、Sloc部分函数依赖于码。所以SLC∈2NF。

在应用中使用这个关系模式可能存在以下问题：

1. 插入异常。假设来了个新生还未选课，即Cno为空。如Sno＝95102，Sdept ＝IS，Sloc＝N。因课程号是主属性，根据实体完整性，主属性不能为空或部分为空，所以该学生的信息无法插入SLC。另外，如果成立了一个新系还没有招生，即Sno、Cno都为空。根据实体完整性，该系的信息也无法插入。

2. 删除异常。假定某个学生本来只选修了3号课程这一门课。现在因身体不适，他连3号课程也不选修了。因课程号是主属性，此操作将导致该学生信息的整个元组都要删除。另外，如果一个系的学生都毕业走了，在删除学生信息的同时该系的信息也将被删除。

3. 修改复杂。

例如学生转系，在修改此学生元组的Sdept值的同时，还可能需要修改住处（Sloc）。如果这个学生选修了K门课，则必须无遗漏地修改K个元组中全部Sdept、Sloc信息。在如系之间调整住处（Sloc），假设一个系有1000个人，每个人平均选修了10门课，住处（Sloc）需无遗漏地修改1万次。

4. 数据冗余度大

假设一个系有1000个人，每个人平均选修了10门课，住处（Sloc）需重复存放1万次。再如一个学生选修了10门课程，那么他的Sdept和Sloc 值就要重复存储了10次。

分析原因：非主属性Sdept、Sloc仅依赖于Sno这个字段，也就是Sdept、Sloc 部分函数依赖于码（Sno，Cno）而不是完全函数依赖。

解决思路：消除了非主属性对码的部分函数依赖。

解决方法：用投影分解将关系模式 SLC进行分解。具体步骤如下：

把部分函数依赖于码的属性取出来；对SLC而言，取出属性Sdept、Sloc。

把剩下的属性构成一个独立的关系模式；对SLC而言，将剩下的属性Sno, Cno, Score构成一个独立的关系模式。即SC（Sno, Cno, Score）。

找出取出属性的决定因素并将它们放在一起构成一个独立的关系模式；对SLC 而言，找出取出属性Sdept、Sloc的决定因素Sno并将它们放在一起构成一个独立的关系模式。即SL（Sno、Sdept、Sloc）。

综上所述，原关系模式SLC(Sno, Sdept, Sloc, Cno, Score)分解为两个关系模式：SC（Sno, Cno, Score）和SL（Sno、Sdept、Sloc）。

上述例子中的关系模式SC（Sno, Cno, Score）。根据语义，码为属性组合（Sno、Cno）。函数依赖图如下：

由图可知，码（Sno、Cno）函数确定非主属性Score，不存在非主属性对码的传递函数依赖，满足3NF。

再如：上述例子中的关系模式 SL（Sno、Sdept、Sloc）。根据语义，码为属性Sno。函数依赖图如下：

由图可知，码Sno函数确定非主属性Sdept，Sdept函数确定非主属性Sloc。Sloc传递函数依赖于Sno，即SL中存在非主属性对码的传递函数依赖。

在应用中使用这两个关系模式可能存在以下问题：

1. 插入异常。如果成立了一个新系还没有招生，即Sno为空。根据实体完整性，该系的信息也无法插入。但假设来了个新生还未选课，即Cno为空。如 Sno＝95102，Sdept＝IS，Sloc＝N。因学号非空，我们可以将该学生的信息插入SL 中。

2. 删除异常。如果一个系的学生都毕业走了，在删除学生信息的同时该系的信息也将被删除。但假定某个学生本来只选修了一门课。现在因身体不适，他连一门课程也不选修了。在删除该学生选课情况时，学生的信息不会丢失。因为学生的学号非空，所以学生信息还在SL中。

3. 修改复杂。

例如系之间调整住处（Sloc），假设一个系有1000个人，每个人平均选修了10门课，住处（Sloc）需无遗漏地修改1000次。但学生转系，不管一个学生选修了多少门课，都只需要在SL中修改1个元组的Sdept、Sloc信息。

4. 数据冗余度大

假设一个系有1000个人，每个人平均选修了10门课，住处（Sloc）需重复存放1000次。但不管一个学生选修了多少门课，都只需要在SL中存放1个元组的Sdept、Sloc信息。

分解之后的两个关系模式SC和SL和原关系模式SLC相比：在一定程度上减轻原F关系模式SLC中存在的插入异常、删除异常、数据冗余度大、修改复杂等问题。但并不能完全消除关系模式中的各种异常情况和数据冗余。

分析原因：非主属性Sloc传递依赖于码Sno。

解决思路：消除了非主属性对码的传递函数依赖。

解决方法：用投影分解法将关系模式SL进行分解。具体步骤如下：

把传递函数依赖于码的属性取出来；对SL而言，取出属性Sloc。

把剩下的属性构成一个独立的关系模式；对SL而言，将剩下的属性Sno, Sdept 构成一个独立的关系模式。即SD（Sno, Sdept）。

找出取出属性的决定因素并将它们放在一起构成一个独立的关系模式；对SL 而言，找出取出属性Sloc的决定因素Sdept并将它们放在一起构成一个独立的关系模式。即DL（Sdept、Sloc）。

综上所述，关系模式SL (Sno, Sdept, Sloc)分解为两个关系模式：SD（Sno, Sdept）和DL（Sdept、Sloc）。

所以，原模式SLC(Sno, Sdept, Sloc, Cno, Score)按如下分解满足3NF：

SC（Sno, Cno, Score），SD（Sno, Sdept），DL（Sdept、Sloc）

在应用中使用这三个关系模式不会存在以下问题：

1. 插入不异常。如果成立了一个新系还没有招生，因为系Sdept非空，该系的信息可以插入DL中。假设来了个新生还未选课，因学号非空，我们可以将该学生的信息插入SD 中。

2. 删除不异常。如果一个系的学生都毕业走了，在删除学生信息的同时该系的信息不会被删除。因为系的系号非空，所以系信息还在DL中。又如某个学生本来只选修了一门课。现在因身体不适，他连一门课程也不选修了。在删除该学生选课情况时，学生的信息不会丢失。因为学生的学号非空，所以学生信息还在SD中。

3. 修改不复杂。

例如系之间调整住处（Sloc），不管一个系有多少个学生，住处（Sloc）只需在DL中修改1次。又如学生转系，不管一个学生选修了多少门课，都只需要在SD 中修改1个元组的Sdept信息。

4. 数据冗余度不大

不管一个系有多少个学生，住处（Sloc）只需在DL中存放1次。但系（Sdept）还得多次存放。冗余只能尽可能减少，不能避免。因为如果没有冗余，数据间就没了联系。

////关系完整性约束

关系完整性是为保证数据库中数据的正确性和相容性，对关系模型提出的某种约束条件或规则。完整性通常包括域完整性，实体完整性、参照完整性和用户定义完整性，其中域完整性，实体完整性和参照完整性，是关系模型必须满足的完整性约束条件。

实体完整性(Entity integrity)是指关系的主关键字不能重复也不能取“空值\"。

在关系模式中，以主关键字作为惟一性标识，而主关键字中的属性(称为主属性)不能取空值，否则，表明关系模式中存在着不可标识的实体(因空值是“不确定\"的)，这与现实世界的实际情况相矛盾，这样的实体就不是一个完整实体

参照完整性(Referential Iintigrity)是定义建立关系之间联系的主关键字与

外部关键字引用的约束条件。

关系数据库中通常都包含多个存在相互联系的关系，关系与关系之间的联系是通过公共属性来实现的。所谓公共属性，它是一个关系R(称为被参照关系或目标关系)的主关键字，同时又是另一关系K(称为参照关系)的外部关键字。如果参照关系K中外部关键字的取值，要么与被参照关系R中某元组主关键字的值相同，要么取空值，那么，在这两个关系间建立关联的主关键字和外部关键字引用，符合参照完整性规则要求。如果参照关系K的外部关键字也是其主关键字，根据实体完整性要求，主关键字不得取空值，因此，参照关系K外部关键字的取值实际上只能取相应被参照关系R中已经存在的主关键字值。

实体完整性和参照完整性适用于任何关系型数据库系统，它主要是针对关系的主关键字和外部关键字取值必须有效而做出的约束。用户定义完整性(user defined integrity)则是根据应用环境的要求和实际的需要，对某一具体应用所涉及的数据提出约束性条件。这一约束机制一般不应由应用程序提供，而应有由关系模型提供定义并检验，用户定义完整性主要包括字段有效性约束和记录有效性。