【机房重构】一步一步往上爬——数据库设计

	期末考试结束了，寒假全职生活如期而至，终于可以开始全身心的投入我的机房重构了。又是一个新的项目，万事开头难，但不开头更难。自己也只能是一步一步往上爬，机房重构便从数据库设计开始。
	回想去年的自考学习，《数据库系统原理》中的知识就可以在机房重构的时候好好应用一把了。第二章的《数据库设计和ER模型》很仔细地教了我们如何进行数据库设计。所以，在参考自考书的基础上，把重构时的数据库全新地设计了一番。
	首先明确数据库系统的生存期一般可划分为七个阶段：规划、需求分析、概念设计、逻辑设计、物理设计、实现、运行维护。有了第一遍机房收费系统的经验基础，对该系统的需求有了一定的了解，下面就从采用ER模型的数据库概念设计步骤开始写起，看看数据库是怎么一步一步设计的。
一.设计局部ER模型
	1.确定局部结构范围。划分方式一般有两种，一种是依据系统的当前用户进行自然划分，例如，机房收费系统中的用户包含学生、操作员和管理员三种用户类型；另一种是按用户要求数据库提供的服务归纳成几类，使每一类应用范文的数据显著地不同于其他类，然后为每类应用设计一个局部ER模型。例如，机房收费系统中的操作员下可划分为：注册、充值、退卡等等几类。这里我将采用第二种方式设计。
	2.定义实体。任务就是从信息需求和局部范围定义出发，确定每一个实体类型的属性和键。这里我定义的实体包括：学生、操作员和管理员。
	3.定义联系。用于刻画实体之间的关联。依据需求分析的结果，考察是否存在联系。若有联系，进一步确认是1:1、1：N，还是M:N等。
	4.分配属性。确定属性的原则是：属性应该是不可再分解的语义单位；实体与属性之间的关系只能是1：N的；不同实体类型的属性之间应无直接关联关系。
二.设计全局ER模型
	1.确定公共实体类型。一般把同名实体类型作为公共实体类型的一类候选，把具有相同键的实体类型作为公共实体类型的另一类候选。
	2.合并局部ER模型。合并原则：首先进行两两合并；从公共实体类型开始，最后再加入独立的局部结构。
	3.消除冲突。包括属性冲突，即属性值的类型不同，如数据有字符串类型，数值型等；结构冲突，同一对象在不同应用中的不同抽象，如管理员，有时充当实体，有时又是另一应用的属性；命名冲突，这在我第一次机房中的数据库设计中有很大的共鸣，那时候同一字段都采用了不同的命名，所以自己总是得回头看看在某个表中它的实际含义。
三.全局ER模型的优化
	1.合并实体类型。一般在权衡利弊后，可以把1:1联系的两个实体类型合并。
	2.消除冗余属性。一般同一非键的属性出现在几个实体类型中，或者一个属性值可从其他属性的值导出，此时，应把冗余的属性从全局模型中去掉。
	3.消除冗余联系。
在经过了上面三个大阶段之后，机房重构的ER图（不包括各个属性）就在下面了：

接着根据将ER模型向关系模型的转换，就可以将关系模式给设计出来了。
	1.如果联系是1:1，可以在两个关系模式中的任意一个的属性中加入另一个模式的键作为外键。
	2.如果联系是1：N，则在N端实体类型转换成的关系模式中加入1端实体类型的键作为外键。
	3.如果联系是M：N，则将联系类型转换成关系模式，其属性为两端实体类型的键作为外键。
下面便是机房重构数据库系统的设计表：
	最后，就是要真正开始创建新的数据库，数据表了。第一次机房的时候就是在SQL中用代码编写的，不过对于其中的各个字段的数据类型都是很含混，一点也不严谨。所以，在这次重构的时候，需要将某些类型修改一番，不可能会做到完美，但必须要做的比前一次好。在浏览相关网页的时候，发现还可以将在Visio画出的ER图直接生成数据库系统的各个表，以后一定得试试。
	学习心得：
	总体说来，之所以在机房重构的这一次将数据库的设计也详细地做了一个总结，就是在自考中学过。那时候，学三范式，画ER图，写关系模式，都只是为了考试，没有实践，更多的只是做题，也就那样过去了，而这次机房重构是一次将其加以应用的好机会。
	在此过程中，虽然花费了不少时间，但相信，数据库设计得好些，后面的路会顺利些。从这几天的机房重构过程中，我想的最多的周杰伦《蜗牛》中唱的那一句歌词：我要一步一步往上爬。我不是想做蜗牛，但我需要学习蜗牛的精神。
	所以在机房重构这阶段中，我将用此句话来总结出我的系列文章，敬请期待~~