清单。
1.3.2顶层数据流图
1.3.3病人住院模块数据流图
1.3.4病人出院模块数据流图
1.3.4数据字典
病人个人信息=病案号+姓名+性别+地址+电话号码+病房编号
病房信息=编号+地点+收费标准+所属科室
病床信息=病房编号+床位号
医生信息=编号+姓名+性别+职称+电话号码+部门
住院信息=日期+病案号+入院时间+出院时间+病房编号+床位号
治疗信息=时间+病案号+医生编号+诊断+治疗方案
住院=日期+病案号+入院时间+出院时间+病房编号+床位号
2.概念设计
2.1全局E-R图
3.逻辑设计
3.1初始关系模式设计
3.1.1转化原则
概念设计中得到的E-R图是由实体,属性和联系组成的,而关系数据库逻辑设计的结果是一组关系模式的集合,所以将E-R图转换为关系模型实际上就是将实体,属性和联系转换成关系模式,在转换中要遵循以下原则:
(1)一个实体转化为一个关系模式,实体的属性就是关系的属性,实体的键就是关系的键。
(2)一个联系转换为一个关系模式,与该联系相连的各实体的键以及联系的属性均转换为该关系的属性。该关系的键有三种情况:
1.如果联系为1:1,则每个实体的键都是关系的候选键。
2.如果联系为1:n,则n端实体的键是关系的键。
3.如果联系为n:m,则各实体键的组合是关系的键。
3.1.2转换结果
经分析,可将2中的E-R模型中的五个实体分别转换为五个关系模式:
病房(编号、地点、收费标准,所属科室)
病床(病房编号、床位号)
病人(病案号、姓名、性别、地址、电话号码、病房编号)
医生(编号、姓名、性别、职称、电话号码、部门)
住院(日期、病案号、入院时间、出院时间、病房编号、床位号)
其中,有下划线的键表示是主键。
再把其中一个联系转换为关系模式,由联系转换得到的关系模式的属性集中,包含两个发生联系的实体中的主键以及联系本身的属性,其关系键的确定与联系的类型有关。转换的关系模式如下:
治疗(时间、病案号、医生编号、诊断、治疗方案)
3.2关系模式规范化
规范化的基本思想是消除关系模式中的数据冗余,消除数据依赖中的不合适的部分,解决数据插入,删除时发生的异常现象。在SCD中,既存在完全函数依赖,又存在部分函数依赖和传递函数依赖。这种情况往往在数据库中是不允许的。也正是关系中存在着复杂的函数依赖,才导致数据操作中出现了种种弊端。克服这种弊端的方法是用投影运算将关系分解,去掉过于复杂的函数依赖关系,向更高一级的范式进行转换。
3.2.1第三范式的定义
如果关系模式R属于2NF,且每个非主属性都不传递依赖于R的每个关系键,则称R属于第三范式。
3.2.2BCN范式的定义
如果关系模式R属于1NF,且所有的函数依赖X->Y,决定因素X都包含了R的一个侯选键,则称R属于BCN范式。
分析上面的六个关系模式可看出,每个关系模式中,既不存在非主属性对主属性的部分函数依赖,也不存在传递函数依赖,也没有主属性对键的部分依赖。因此,这些关系模式都是BCN范式。
4.物理实现
该数据库使用Access2000数据库来实现。
4.1用Access2000分别创建六个表:
病房数据表
病床数据表
病人数据表
医生数据表
住院数据表
治疗数据表
4.2定义表之间的关系
这时,一个医院管理数据库就初步建成了。
5.研制报告
这次的课程设计中,我是按照数据库系统开发的四个基本过程来进行设计的的,历时一个星期.为了能够使该设计尽可能完善,我看了不少课外资料,主要是想了解一些大型数据库管理系统是如何开发的。通过阅读,我收获很大.从这些学习中我更加深入的了解数据库系统开发的各个方面。
整体上说,数据库这门课很好理解,理论知识学起来比较容易,但对它的功能,及作用如何实现缺乏实践。本次课程设计就给了我很好的机会,让我容书本知识于实际运用当中,使我对一个完整的数据库的设计过程有了充分的理解。这次编程也培养了我的严密的逻辑思维能力。通过课程设计我体会到要学一门知识就应该将它学好,学到精髓之处并学以致用。学到的并不代表我们掌握了,但掌握了就一定学到了。我们不应该是单纯的学习课本知识,而应该多动手多应用,将学到的知识相互结合起来应用到实际中才是我们要学的。课程设计不仅仅是让我们对一门课程更深的掌握,同时也是锻炼我们解决问题的能力的一个考验。我们应该在不断的求索中寻找前进的途径。由于时间关系,我没能完成一个基于该数据库的系统,但有机会我一定会努力完成。
上一篇:
农资销售管理系统(论文和程序)
下一篇:
对硕士毕业生迁移失业目的地的实证研讨