最近开始做数据库的大实验，其中有一条实验要求如下：

通过网络查找相关文献并参考所给资料进行需求分析，画出系统的 E-R 图，给出实体或联系的属性，标明联系的种类，并写出关系模式。

画ER图没有什么问题，但是关系模式是什么就不知道了。所以，还是有必要学习一下的。

关系模式的定义

通过google和课本上对关系模式的定义得出如下定义：

关系模式(Relation Schema)是对关系的描述,它可以形式化地表示为：R(U，D，dom，F)。

其中R为关系名，U为组成该关系的属性名集合，D为属性组U中属性所来自的域，dom为属性向域的映象集合，F为属性间数据的依赖关系集合。

通常简记为：R(U)或R(A1，A2，…,An)其中R为关系名，U为属性名集合，A1，A2，…,An为各属性名。

有了定义，对关系模式有一个大概的认识(可以说基本上还是蒙的)，那么按照实验的要求，我们要如何从ER图中的到一个关系模式呢？

ER图转关系模式

这里我会以学生管理系统中常见的几个实体关系为例，设计简单你的ER图，并做转换说明。

1对1转换关系

首先我们先从最简单的做起。这里我们将教师和课程的关系看做是1:1的关系(班主任),然后ER图如下:

通过定义，我们可以初步的到一组关系模式：

教师(性别，职工号，手机号，年龄，姓名)

班级(班级名称，班级号)

负责(职工号，班级号)

这就是一组关系模式，有人会说，负责这组关系模式好像多余呀。是的，下面我们就着手将其进行合并。

这里可以将教师和负责两个关系合并到一起，也可以选择将班级和负责合并到一起。

1.合并教师和负责

教师(性别，职工号，手机号，年龄，姓名，班级号)

班级(班级名称，班级号)

合并就是将关系负责的属性添加到教师的属性中去，然后合并重复的属性。

2.合并班级和负责

教师(性别，职工号，手机号，年龄，姓名)

班级(班级名称，班级号，职工号)

通过上面的合并，我们发现，合并后的两个关系才更像是我们最终的数据表结构。

1对n转换关系

班级和学生是1对n的关系，ER图如下：

同样的，我们有可以先得到一组独立地关系模式：

学生(学号，姓名，性别)

班级(班级名称，班级号)

包含(学号，班级号，人数)

然后将联系的关系进行合并。在1对n的关系中，需要将联系的关系添加到n的一方的关系模式中。

学生(学号，姓名，性别，班级号)

班级(班级名称，班级号)

m对n转换关系

最后看一下多对多的关系是如何转换的。首先还是先给出ER图：

学生和课程的关系是m:n的。然后得到初步的关系模型：

学生(学号，姓名，性别)

课程(课程号，课程名)

选修(学号，课程号，成绩)

按照上面的惯例，下面我们应该合并关系模型了。但是在多对多的关系下，三种关系模式是不能进行合并的。而两个实体联系的关系模式正式我们常说的中间表的结构。

理解关系模式的作用

在上面通过ER图得到关系模式和合并关系模式的过程中，我们发现关系模式其实就是对应我们的数据表结构。那么关系模式有什么用呢，以往我们不通过关系模式一样可以得到表结构。

其实是没错的，但是通过范式的学习，发现我们的关系模式更多的时候是得到最终数据表的一个分析工具。就像我们上面一样，一开始会得到一个初始的独立的关系模式，然后对关系模式做合并，得到一个更加合理的关系模式。

使用范式也是一样的，我们会从基本的关系模式出发，然后利用范式的规则，得到最终更加合理的关系模式。这个过程如果只是靠抽象的想象的话，如果实体数量少还好说的，但是随着实体数越来越多，就会显得不大现实，而且准确性也会下降。

总的来说，通过对关系模式的化简合并，才会得到我们最终的实际编程用的数据表结构，比如下面这样：

总结

通过学习，自己理解了一下关系模式。发现自己原来创建数据表的方式有点随意了。我只是做到了给出了一种数据表的解决办法，但是还不能算是数据库设计的范畴。看来自己还是处在一个程序员的位置，想要成为一个工程师，还有很长的路要走。

后面我还会继续更新对范式的相关学习。