关系模型的数据结构

关系模型的数据结构
关系模型源于数学，它用二维表来组织数据，而这个二维表在关系数据库中称为关系。

关系数据库是表的集合
用关系表示实体以及实体间的联系的模型，称为关系模型，下面我们来看看关系模型中的基本术语
1.关系
关系就是二维表，它满足以下几个条件
1）关系表中的每一列都是不可再分的基本属性。

（有子属性，分开了，不是关系表）
2）表中的各属性不能重名
3）表中的行、列次序并不重要，即交换列的前后顺序（比如将性别放在年龄前面）不影响其表达的一个语义。

2.元组
表中的每一行数据称为一个元组，它相当于一个记录值
3.属性
表中的每一列是一个属性值的集合，列可以命名，称为属性名，属性与前面讲到的实体属性（特征）或记录的字段意义相当。

关系表中的每一行数据不允许完全相同，因为存储值完全相同的两行或多行数据并没有实际意义
4.主键
主键也称主码或主关键字，是表中用于唯一确定一个元组的一个属性或最小属性组。

主键可以由一个属性组成，也可以由多个属性共同组成。

如表所示，学号就是此学生基本信息表的主键，因为它可以唯一地确定一个学生。

而表所示的关系的主键就由学号和课程号共同组成，因为一个学生可以选修多门课程，而且一门课程也可以有多个学生选修，因此，只有将学号和课程号结合起来才能共同的确定一行记录。

通常称由多个属性共同组成的主键为复合主键。

表的主键与其实际应用语义有关，与表设计者的意图有关，如表，用（学号，课程号）作为主键在一个学生对一门课程只能有一次考试的前提下是成立的，如果设定一个学生对一门课程可以有多次考试，则用（学号，课程号）作主键就不够了，因为一个学生对一门课程有多少次考试，则这个值就回重复多少遍，如果是这种情况，就必须为这个表添加一个“考试次数”列，同时作为主键
有时一个表中可能存在多个可以作主键的属性，比如，对于学生信息表，如果能够保证姓名肯定不重复的话，那么姓名也可以作为学生基本信息的主键，如果表中存在多个可以作为主键的属性，则称这些属性为候选键属性，相应的键称为候选键，从中选一个作为主键都是可以的。

5.域
属性的取值范围称为域。

例如，大学生的年龄假设在14~40岁范围内，则学生的“年龄”属性的域就是（14~40）
关系模型的数据操作
增删改查
关系模型的数据完整性约束
数据完整性是指数据库中存储的数据是有意义的，是正确的。

主要包括三大类
1）实体完整性
是指的是关系数据库中所有的表都必须有主键，而且表中不允许存在以下两种情况
（1）无主键值的记录
（2）主键值相同的记录
因为若记录没有主键值，则此记录在表中一定是无意义的。

关系模型
中的每一行记录都对应客观存在的一个实例或一个事实，比如，一个
学号唯一地确定了一个学生，如果表中存在没有学号的学生记录，则
此学生一定不属于正常管理的学生。

另外，如果表中存在主键值相等
的两个或多个记录，则这两个或多个记录会对应同一个实例，这会出
现两种情况。

第一，表中的其他值也完全相同，则这些记录就是重复
记录，存储重复的记录是没有意义的，第二，如果其他值不完全相同，
则会出现语义矛盾，哪条记录才是真实的
实体中每个具体的记录值（一行数据），比如学生实体中的每个具体的学生，称为实体的一个实例。

2）参照完整性
参照完整性有时也称为引用完整性。

现实世界中的实体之间往往存在着某种联系，在关系模型中，实体以及实体之间的联系都是用关系来表示的，这样就自然存在着关系（表）与关系（表）之间的引用关系。

参照完整性就是描述实体之间的联系的。

参照完整性一般是指多个实体或表之间的关联关系。

比如表2-3中，学生选课信息表所描述的学生必须受限于表2-1学生基本信息表中已有的学生，不能在学生选课信息表中描述一个根本就不存在的学生，也就是学生选课信息表中学号的取值必须在学生基本信息表中学号的取值范围内。

这种一个表中某列的取值受限于另一个表的某列的取值范围约東的特点就称为参照完整性。

在关系数据库中用外键（foreign key，有时也称为外部关键字或外码）来实现参照完整性。

例如，只要将学生选课表中的“学号”定义为引用学生基本信息表的“学号”的外键，就可以保证选课表中的“学号”的取值在学生基本信息表的已有“学号”范围内
外键一般出现在联系所对应的关系中，用于表示两个或多个实体之间的关联关系。

外键实际上是表中的一个（或多个）属性，它引用某个其他表（特殊情况下，也
可以是外键所在（2.4的表）的主键，当然，也可以是候选键，但多数情况下是主键。

下面举例说明如何指定外键
例2-1】学生和专业可以用下面的关系表示，其中主键用下划线标识。

学生（学号，姓名，性别，专业号，出生日期）
专业（专业号，专业名）
这两个关系之间存在着属性引用关系，即学生关系中的“专业号”引用了专业关系中的“专业号”，显然，学生关系中的“专业号”的值必须是确实存在的专业的专业号。

也就是说，学生关系中的“专业号”引用了专业关系中的“专业号”，是引用了专业关系中的“专业号”的外键
【例2-2】学生、课程以及学生与课程之间的选课关系可以用以下3个关系表示，其中主键用下划线标识。

学生（学号，姓名，性别，专业号，出生日期）
课程（课程号，课程名，学分）
选课（学号，课程号，成绩）
这3个关系中，选课关系中的“学号”必须是学生关系中已有的学生，因此选课关系中号”引用了学生关系中的“学号”。

同样，选课关系中的“课程号”也必须是课程关系中已有的课程，即选课关系中的“课程号”引用了课程关系中的“课程号”。

因此，选课关系中的“学号”是引用了学生关系中的“学号”的外键，而“课程号”是引用了课程关系中的“课程号”的外键。

主键必须是非空且不重复的，但外键无此要求。

外键可以有重复值，这点从表
2-3中可以看出。

外键也可以取空值，例如，职工与其所在的部门可以用以下两个关系表示。

职工（职工号，职工名，部门号，工资级别）
部门（部门号，部门名）
其中，职工关系的“部门号”是引用部门关系的“部门号”的外键，如果某新来职工还没有被分配到具体的部门，则其“部门号”就为空值；如果职工已经被分配到了某个部门，则其部门号就有了确定的值（非空值）。

3）用户定义完整性
用户定义的完整性也称为域完整性或语义完整性。

任何关系数据库管理系统都应该支持实体完整性和参照完整性，除此之外，不同的数据库应用系统根据其应用环境的不同，往往还需要一些特殊的约東条件，用户定义的完整性就是针对某一具体应用领域定义的数据约束条件，它反映某一具体应用所涉及的数据必须满足应用语义的要求。

用户定义的完整性实际上就是指明关系中属性的取值范围，也就是属性的域，这样可以限制关系中属性的取值类型及取值范围，防止属性的值与应用语义矛盾。

例如，学生的考试成绩的取值范围为0~100，人的性别的取值是{男，女}。

关系规范化
为什么要关系规范化
观察这个表的数据，会发现有以下几个问题
①数据冗余问题：在这个关系中，有关学生所在系和其所对应的宿舍楼的信息有冗余，因为一个系有多少个学生，这个系所对应的宿舍楼的信息就要重复存储多少遍。

而且学生基本信息（包括学生学号、姓名、性别、所在系）也有重复，一个学生修了多少门课，他的基本信息就重复多少遍。

②数据更新问题：如果某一学生从数字媒体系转到了信息管理系，那么不但要修改此学生的Sdept列的值，还要修改其Sloc列的值，从而使修改复杂化。

③数据插入问题：如果新成立了某个系，并且也确定好了此系学生的宿舍楼，即已经有了Sdept和Sloc信息，但也不能将这个信息插入到表1中，因为这个系还没有招生，其Sno和Cno列的值均为空，而Sno和Cno是这个表的主属性，因此不能为空。

④数据删除问题：如果一个学生只选了一门课，而后来又不选了，则应该删除此学生选此门课程的记录。

但由于这个学生只选了一门课，则删掉此学生的选课记录的同时也删掉了此学生的其他基本信息。

这些都是操作异常，为什么会出现操作异常呢，就是关系模式没有设计好。

为了解决这类似的问题，我们就要按照关系规范化去进行设计。

1.关系中的码
例1：有关系模式：学生（学号，姓名，性别，身份证号，年龄，所在系）
候选码为：学号，身份证号
主键可以为“学号”或者是“身份证号”。

主属性为：学号，身份证号
作主属性为：姓名，性别，年龄，所在系。

例2：有关系模式：选课（学号，课程号，考试次数，成绩）
设一个学生对一门课程可以有多次考试，每一次考试有一个考试成绩
候选码为：（学号，课程号，考试次数），也为主键
主属性为：学号，课程号，考试次数
非主属性为：成绩。

例3：有关系模式：授课（教师号，课程号，学年）
其语义为：一个教师在一个学年可以讲授多门不同的课程，可以在不同学年对同一门课程讲授多次，但不能在同一个学年对同一门课程讲授多次。

一门课程在一个学年可以由多个不同的教师讲授，同一个学年可以开设多门课程，同一门课程可以在不同学年开设多次。

其候选码为：（教师号，课程号，学年），因为只有（教师号，课程号，学年）三者才能唯一的确定一个元组。

这里的候选码也是主键
主属性为：教师号，课程号，学年。

没有非主属性。

称这种候选码为全部属性的表为全码表。

2.范式
1NF
第一范式（1NF）是指数据表中的每个字段必须是不可拆分的最小单元。

2NF
第二范式（2NF）是指满足1NF后，要求表中的所有列，都必须依赖于主键，而不能有任何一列与主键没有关系，也就是说一个表只描述一件事情。

这个是什么意思呢，意思就是说，表中除了主键的其他列，不能和主键没有关系，但其实这句话又有点相互矛盾，既然没关系，又怎么会放在同一列中呢，其实可
以这样想，单独把这一列和主键拿出来，如果他们之间没有关系，那肯定是不满足第二范式的。

这是一张成绩表，包括学号、课程号、成绩和学分，主键为学号，但是单独将学分和学号拿出来，两个没有关系，所以不满足第二范式。

第三范式（3NF）是指必须先满足第二范式（2NF），另外要求表中的每一列只与主键直接相关而不是间接相关。

这个又是什么意思呢，似乎和第二范式的描述差不多啊，其实不然，还是有细微差别的，第三范式保证了表中的字段消除了传递依赖，比如C依赖于B，B依赖于A，那么C依赖于A，像这样的情况不能让A、B、C出现在同一个表中。

可以看出，学院地点与学号不是直接相关连，学院地点和学院号直接相关连，所以不满足数据库第三范式。

如何转换呢？
2NF
函数依赖关系的分解过程有以下几个步骤可以用模式分解的办法将非2NF的关系模式分解为多个2NF的关系模式。

步骤
①用组成主键的属性集合的每一个子集作为主键构成一个关系模式。

②将依赖于这些主键的属性放置到相应的关系模式中
③最后去掉只由主键的子集构成的关系模式
例如，对S-L-C表，首先分解为如下的三个关系模式（下划线部分表示主键）：
S-l(Sno,.)
C(Cno,.)
S-c(Sno, Cno,.)
然后，将依赖于这些主键的属性放置到相应的关系模式中，形成如下三个关系模式
S-l(Sno, Sname, Ssex, Sdept, Sloc)
C（Cno）
S-c(sno,con,grade)
最后，去掉只由主键的子集构成的关系模式，也就是去掉C（Cno）关系模式。

SLC关系模式最终被分解的形式为：
s-l(Sno, Shane, Ssex, Sdept, Sloc)
s-c(Sno, Cno, Grade)
从表6-2所示的数据可以看出，一个系有多少个学生，就会重复描述每个系和其所在的宿舍楼多少遍，因此还存在数据冗余，也就存在操作异常。

比如，当新组建一个系时，如果此系还没有招收学生，但已分配了宿舍楼，则还是无法将此系的信息插入到数据库中，因为这时的学号为空。

由此看到，第二范式的关系模式同样还可能存在操作异常情况，因此还需要对此关系模式进行进一步的分解。

3NF
在建立在2NF的基础上把有传递关系的单独提出来成立一张表。