基于机房收费系统ER图与关系模型设计.docVIP

基于机房收费系统ER图与关系模型设计 　　[摘要]在机房收费系统中，数据库的地位是绝对不容忽视的。数据库结构设计的好坏，重则会决定软件系统的成败，轻则也会直接影响系统运行速度及系统的使用率。在设计时，不仅要考虑存取速度，而且要考虑数据的冗余和数据一致性等问题。文章以学院要新开发的机房收费系统为依托，设计ER图与关系模型，并使关系模型满足第三范式要求。 　　[关键词]需求分析；ER图；关系模型 　　[DOI]1013939/jcnkizgsc201703131 　　1设计背景与用户需求分析 　　电子计算机的发明，给人类的生活和工作都带来了巨大的变化。如果在管理中不使用计算机，已经是不可能的了。北京电子科技职业学院为了使学生方便到机房学习，决定开发机房上机收费系统。当然，首先我们要进行数据库的设计。院方提出机房收费系统要能显示并打印学生信息表和上机时间表。具体表格的内容如表1和表2所示。 　　表1学生信息表卡号学号姓名性别系部余额权限编号权限类型办卡日明男电信学院，计算机系，1作员2015/09/07 　　表2上机时间记录表卡号学号姓名性别学院系部班级上机日期上机时间下机日期下机时间时间金明男电信学院计算机系1班2015/9/1009：002015/9/1010：0012 　　2数据库关系模型的设计 　　在进行数据库的建设之前，我们要先进行数据库关系模型的设计，并使之满足第三范式的要求。 　　21第一范式设计 　　首先，我们要考虑表1结构是否满足第一范式要求。那么什么是第一范式呢？如果关系模式R的所有属性的值域中每一个属性值都是不可再分解值，则称R是属于第一范式，即1NF模式。[1]很显然表1的“系部”属性值是可以再分解的，所以它不满足第一范式。我们应该修改表1结构，设计成如表3所示。 　　表3学生信息表（改）卡号学号姓名性别学院系部班级余额权限编号权限类型办卡日明男电信学院计算机系1作员2015/09/07 　　通过表3的结构，我们可以写出第一范式： 　　学生（卡号、学号、姓名、性别、学院、系部、班级、余额、权限编号、权限类型、办卡日期） 　　上机时间记录（卡号、学号、姓名、性别、学院、系部、班级、上机日期、上机时间、下机日期、下机时间、时长、金额） 　　22第二范式设计 　　以上关系模型显然已经满足第一范式了，这时我们再判断它是不是满足第二范式。第二范式是这样定义的：如果关系模式R为第一范式，且R中每个非主属性完全函数依赖于R的主码（复合码），则称R为第二范式，即2NF模式[2]。第二范式里又提出一个新的名词――“完全函数依赖”。那么什么是完全函数依赖呢？如果属性Y函数依赖于复合属性X，且不与X的任何子集函数相依赖，则称“Y完全函数依赖于X” 。[3]显然，第一范式的关系模型中，“卡号”和“学号”是主键，但不是所有的非主属性完全函数都依赖于复合码。如“上机即使记录”这个关系中的“姓名”只依赖于“学号”，而不依赖于“卡号”。至此一点就可以断定，以上设计不满足第二范式。那么，还有哪些非主属性与两个主键不完全相关呢？经过分解，我们得出以下内容： 　　存储卡（卡号、余额、权限编号、权限类型、办卡日期、上机日期、上机时间、下机日期、下机时间、时长、金额） 　　学生（学号、姓名、性别、学院、系部、班级） 　　以上关系模型中，权限编号、权限类型、办卡日期这三项是不会变更的，我们把它从存储卡里分离出来，优化的结果是： 　　存储卡（卡号、余额、权限编号、权限类型、办卡日期） 　　学生（学号、姓名、性别、学院、系部、班级） 　　上机记录（卡号、上机日期、上机时间、下机日期、下机时间、时长、金额） 　　23第三范式设计 　　得到第二范式后，我们就要着手分析以上关系模型是否满足第三范式。“第三范式”的定义是：如果关系模式R为第二范式，且R中每个非主属性都不传递函数依赖于R的某个候选码，则称R为第三范式，即3NF模式。[4] 　　以上关系模型中，如果知道“卡号”就能知道“权限编号”，知道“权限编号”就能知道“权限类型”，所以它们之间存在传递关系，以上设计也就不满足第三范式。另外，上机记录中的“时长”与“金额”等也存在传递关系，经过优化，我们得到以下设计，使之满足第三范式： 　　存储卡（卡号、余额、权限编号、办卡日期） 　　学生（学号、姓名、性别、学院、系部、班级） 　　上?C记录（卡号、上机日期、上机时间、下机日期、下机时间、时长） 　　卡权限（权限编号、权限类型） 　　时间（时长、金额） 　　3绘制ER图，通过ER图对关系模型进行补充完善下面，我们可以尝试画出机房收费系统的ER图，如图所