建立教学管理数据库的关系模型

关系模型是根据前一阶段的设计成果———概念模型来设计的。

在关系数据库中实体以及实体间的联系都用“关系”来描述，而关系的存储结构就是二维表。图4．2所示的概念模型（E-R模型）中，学生是一种实体，其信息用二维表来存储时的形式见表4．2。

图4．1　局部E-R图

图4．2　全局E-R图

表4．2是部分学生的基本信息。表中的第一行是各列的名称，其余行对应学生集合中各个学生的基本信息。

表4．2　学生基本信息表（学生）

如果只是关注这张表的结构，即表的名称、构成的列，可以只用列名这一行来描述它，即

学生（学号，姓名，性别，出生日期，系部，班级）

这就是关系模式的表达形式，即“型”。“学生”是这个关系模式的名称，括号中列写的是该关系模式的属性，它们实际就是“学生”这个实体的属性，其中加下画线的属性“学号”是键，因为前面的表4．1中说明过它是实体“学生”的键。

将关系名称和属性名称改用英文或字母可以在以后使用T-SQL语句时编辑输入更方便一些，这样其对应的关系模式如下：

Student（Sno，Sn，Sex，Birthday，Dept，Class）

E-R模型中的每个实体、每个联系都可以转换成一个对应的关系模式。显然，关系模型是若干关系模式的集合。

同理，教师、课程、系部和宿舍区这几个实体都相应转化如下：

Teacher（Tno，Tn，Sex，BirthDay，Dept）

Course（Cno，Cn，Credit，Ct）

Department（Dept，Office，Phone，DeptHead，Dorm）

Dormitory（Dorm，Phone，Resp，Totalroom）

学生与课程之间的联系“选修”是一个多对多的联系，按规则必须转化为一个独立的关系模式，即

SC（Sno，Cno，Score）

这里，Score是它本身的属性，而Sno和Cno则是与它相联系的两个实体型学生、课程的键。同样的，联系“主讲”的关系模式如下：

TC（Tno，Cno，Dct）

最后，系部与学生之间的“属于”是一对多的联系，按规则已经将其归并到多端（学生），不再有独立的关系模式。同理，联系“受聘”和“使用”也合并到多端而无独立的关系模式。

通过以上过程，把E-R模型加以转换得到该系统的一种关系模型：

Student（Sno，sn，Sex，BirthDay，Dept，Class）

Teacher（Tno，Tn，Sex，BirthDay，Dept）

Course（Cno，Cn，Credit，Ct）

Department（Dept，Office，Phone，DeptHead，Dorm）

Dormitory（Dorm，Phone，Resp，Totalroom）

SC（Sno，Cno，Score）

TC（Tno，Cno，Dct）

从概念模型转换到关系模型的结果是唯一的吗？回答显然应该是否定的，因为转换时可以将Cno，Cn，Score纳入Student这个模式中，从而没有SC这个模式。可知，根据同一个数据库的概念模型可能产生两种，甚至多种不同的关系模式。如何评价这些不同的关系模式，即一个数据库应该构造几个关系模式，一个关系模式中应该包括哪些属性、不该包括哪些属性，构造出来的关系模式是否存在问题，等等。这些实际上就是数据库的逻辑设计问题，解决这些问题需要应用数据库逻辑设计的知识———关系数据库规范化理论。