©2010-2026 宁波自信网络信息技术有限公司 版权所有
客服电话：0574-28810668 投诉电话：18658249818
浙ICP备2021020529号-1 | 浙B2-20240490
关注我们 ：
1、 医院患者管理系统分析与设计 107 2020年4月19日 文档仅供参考，不当之处，请联系改正。 大连理工大学城市学院 软件工程大作业 学院(系)： 计算机工程学院 专 业： 学 生： 授课教师： 张应博 完成日期： 6月 大连理工大学城市学院《软件工程》大作业 题目：医院患者管理系统分析与设计
2、 成绩： 总计 大作业 67页 表格 22表 插图 56幅 目录 第一章 医院患者管理系统需求分析 4 1. 导言 4 2. 系统定义 5 3. 应用环境 5 4. 功能规格 7 5. 性能需求 16 6. 产品提交 17 7. 实现约束 17 8. 签字 18 第二章 医院患者管理系统概要设计 19 1. 导言 19 2. 系统分析 19 2. 界面设计 20 4. 体系结构 22 5. 数据模型 28 6. 模块设计 35 第三章 医院患者管理系统详细设计 51 第四章 医院患者管理
3、系统编码实现 82 1.编码格式规范 82 2.命名规范 82 3.声明规范 83 4.目录规范 83 5..代码实例 83 第五章 医院患者管理系统测试计划 84 1. 测试项目 84 2. 测试方法 84 第六章 医院患者管理系统部署运营和维护 85 第七章 总结与展望 86 1.本程序的总结和展望 86 2.感想 86 参考文献 87 第一章 医院患者管理系统需求分析 1. 导言 1.1 目的 该文档是关于用户对于医院患者管理系统的功能和性能的要求，重点描述了医院患者管理系统的功能需求，是概要设计阶段的重要输入。 本文档的预期读者是： ·
4、 设计人员； · 开发人员； · 项目管理人员； · 测试人员； · 用户。 1.2 范围 该文档是借助于当前系统的逻辑模型导出目标系统的逻辑模型的，解决整个项目系统的“做什么”的问题。在这里，没有涉及开发技术，而主要是经过建立模型的方式来描述用户的需求，为客户、用户、开发方等不同参与方提供一个交流的平台。 1.3 编写说明 JSP,Java Server Page（Java服务器页面）的缩写，一个脚本化的语言。 UML,Unified Modeling Language（统一建模语言）的缩写，是一个标准的建模语言。 1.4 术语定义 无 1.5 参考资料 [1]《U
5、ML说明》，***********************软件有限公司 [2]《需求规格报告格式标准》，************公司软件工程过程化组织 1.6 版本更新信息 本文档的更新记录如表1-1所示。 表1-1 版本更新记录 修改编号 修改日期 修改后版本 修改位置 修改内容概述 001 .5.3 0.1 全部 初始发布版本 002 .5.10 0.2 第3.1节 增加 2. 系统定义 我们分别阐述一下项目的来源、背景，项目的用户特点和项目的目标。 1.1 项目来源及背景 本项目是为小型医院、诊所开发的一
6、个简单的患者管理系统。 随着中国社区医院、小型诊所的发展，传统的手工纸质化的患者管理方式，已经日益显示其不足之处，在处理患者信息的数量、准确性方面都比较欠缺，信息化、网络化也成为这些小型医院的一个必然的发展趋势，患者管理系统作为医院信息管理系统是医院自动化管理系统得一个重要组成部分，它的开发大大的提高了医院信息管理的规范化能力。 2.2 用户的特点 本系统的用户都是网上用户，包括两类，一类是患者，她们的差异比较大，有的计算机应用水平比较高很高，有的可能很低。另一类是医生，她们对业务很熟悉，经过实际使用，她们对使用管理软件比较熟悉。另外一类用户是系统管理员用户，在实际中，她们可能是医院院长
7、或人力资源部主管，系统管理人员对系统很熟悉 2.3 项目目标 本项目设定的目标如下： · 系统能够提供友好的用户界面，使操作人员的工作量最大限度的减少； · 系统具有良好的运行效率，能够达到提高生产率的目的； · 系统应有良好的可扩充性，能够容易地加入其它系统的应用； · 平台的设计具有一定的超前性，灵活性，能够适应企业生产配置的变化； 3. 应用环境 根据用户的需求陈述，能够确定本项目分为客户端（患者）和管理端（医生、超级管理员），客户端主要功能是为患者提供医生信息查询、就诊预约、查询预约信息、查看病历等。管理端的功能为医生提供查看预约患者信息、创立、修改、查看患者病历信息等
8、功能，为医院管理人员进行医生的添加、删除管理等。它们的关系如图1-1所示。 图1-1 医院患者管理系统流程图 3.1 系统运行的网络环境 本系统的网络运行图如图1-2所示，无论是客户端的患者用户还是管理端的医生用户、系统管理员用户都能够经过网络登录到本系统中。患者经过网络查询医生信息、提交预约信息；医生经过网络查看预约患者信息、创立患者病历、查看、修改病历发；管理端的管理员管理医生信息。 3.2 系统运行的硬件环境 本系统的硬件环境如下： 客户机：普通PC · CPU：P41.8GHz以上 · 内存：256MB以上 · 能够运行IE5.0以上或者Netscape4.0以
9、上版本的机器 · 分辨率：推荐使用1024×768像素或以上 Web服务器 · CPU：P41.0GHz · 内存：1G以上 · 硬盘：80GB以上 · 网卡：KMb/s速度 数据库服务器 · CPU：P42.0GHz · 内存：1GB以上 ·硬盘：80GB以上 图1-2 网络拓扑结构图 系统运行软件环境 本系统的软件环境如下： · 操作系统：Windows 或以上版本 · 数据库：MySQL · 开发工具包：JDK Version 1.6.0 ·Web服务器：Tomcat 6.0 ·浏览器：IE6.0以上 4. 功能规格 我们采用面向对象分析
10、作为主要的系统建模方法，使用UML（Unified Modeling Language）作为建模语言。UML为建模活动提供了从不同角度观察和展示系统的各种特征的方法。在UML中，从任何一个角度对系统所作的抽象都可能需要几种模型来描述，而这些来自不同角度的模型图最终组成了系统的映像。 用例描述角色（用户、外部系统以及系统处理）是如何与系统交互来完成工作的。用例模型提供了一个非常重要的方式来界定系统边界以及定义系统功能，同时，该模型将来能够派生出动态对象模型。 设计用例时，我们遵循下列步骤： 1）识别出系统的角色。角色能够是用户、外部系统，甚至是外部处理，经过某种途径与系统交互。重要的是着重
11、从系统外部执行者的角度来描述系统需要提供哪些功能，并指明这些功能的执行者（角色）是谁。尽可能地确保所有角色都被完全识别出来。 2）描述主要的用例。能够采取不断地问自已“这个角色究竟想过系统做什么？”来准确地描述用例。 3）重新审视每个用例，为它们下个详尽的定义。 4.1 角色定义 角色或者执行者指与系统产生交互的外部用户或者外部系统。 4.1.1 患者 患者是指在这个系统中经过客户端提交预约就诊信息的人员，这个角色主要参与客户端的注册系统用户、医生信息查询、提交预约就诊信息等功能。 4.1.2管理用户 管理用户是指管理端的用户，此角色派生两个子类，医生和系统管理员。
12、医生是指在这个系统中经过客户端查看预约患者信息的人员，这个角色主要参与客户端的查看预约患者信息、创立患者病例、查询患者病例、修改患者病例等功能。 系统管理员是指管理医生用户的人员，这个角色主要负责对管理端医生用户的增加、删除等功能。她也是经过管理端登录对管理端的用户进行设置，它们的关系如图1-3所示。 图1-3 管理用户角色的关系 4.1.3 数据库 数据库是一个与系统产生交互的外部系统，这个角色负责系统的数据查询、增加、删除和修改等操作。 4.2 系统主用例图 医院患者管理系统能够分为两个主要的组成部分，一个是客户端子系统。一个是管理端子系统。客户端子系统功能主要是指患者、
13、医生经过登录网站进行操作的功能。管理端子系统功能是医院的管理人员管理医生用户的功能。系统的主用例如图1-4所示。 图1-4 系统的主用例图 4.3 客户端子系统 患者经过本网站网站登录到系统中进行就诊预约、查看病历信息等，患者经过它提交预约信息，这就是客户端子系统的功能。在客户端用户能够看到能够预约的医生的信息。图1-5是它的活动图。 客户端的功能主要包括查看医生信息、填写预约申请、查看病历等功能，图1-6是它的用例图。 图1-5 客户端的活动图 图1-6 客
14、户端的功能用例图 客户端管理的这些用例描述如下： 1.1：查看医生信息。 1.2：填写、提交预约信息。 1.3：查询预约情况。 1.4：查询病例信息。 4.3.1 查看医生信息 用例描述：患者查看医生信息； 执行者：患者； 前置条件：患者已登录系统； 后置条件：查看医生信息后，患者可选择某一位医生预约就诊。 基本路径： a）患者登录到医院的预约网页，显示当前能够预约的医生列表； b）点击任何一个医生能够显示该医生在一周每天可预约的人数； 4.3.2 输入预约信息 如果患者选中某位医生，就能够开始填写预约信息，从患者的基本信息开始，具体描述如下。 用例描述：填写预
15、约信息； 执行者：患者； 前置条件：患者已选择某位医生； 后置条件：预约信息提交以后则能够查看该主治医生的详细信息。 基本路径： a）基本信息输入，包括姓名、性别、年龄、电话、地址、等信息； b）输入完成后，点击提交可提交预约信息。 4.3.3 查询预约情况 患者提交预约信息后可经过该功能查询自己是否预约成功，具体功能描述如下。 用例描述：查询预约情况； 执行者：患者； 前置条件：患者已提交预约信息； 后置条件：无。 基本路径： a）患者点击页面左侧“查询预约信息”超链接； b）若预约信息已成功提交，则在页面中间部分显示预约的信息 4.3.4 查询病例信息 患
16、者可经过本页面查询自己的病例信息，具体功能描述如下。 用例描述：查询病例信息； 执行者：患者； 前置条件：患者预约成功，且完成至少一次就诊； 后置条件：无。 基本路径： a）患者点击页面左侧“查询病例”超链接； b）若患者完成一次就诊，则在页面中可显示自己的病例信息。 4.4 管理端子系统 管理端子系统主要是提供医生和系统管理员使用的功能，医生使用的功能有查询预约患者信息、创立病例、查询患者病例；系统管理员是用的功能为添加医生账号和删除医生账号。图1-7是管理端的用例图。 图1-7 管理端用例图 4.4.1 登录管理 登录到管理端的所有人都需要经过登录界面进入
17、相应的管理界面。在登发界面输入用户名和密码，系统首先判断用户名和密码的正确性，然后根据用户名确定其权限，不同的登录者具有不同的权限，根据登录者具有的权限将相应的功能显示在管理界面上。图1-8是它的活动视图。 图A-8 登录管理活动视图 4.4.2添加医生账户 医生账户管理模块主要是完成医生账户的添加和删除。具体描述如下。 用例描述：添加医生账户； 执行者： 系统管理员； 前置条件： 系统管理员已登录系统； 后置条件： 无。 基本路径： a）进入医生账户管理界面，首先显示当前已存在的医生账户； b）点击“添加”按钮能够添加医生账户，输入新账户的相关信息完成添加；
18、4.4.2删除医生账户 医生账户管理模块主要是完成医生账户的添加和删除。具体描述如下。 用例描述：删除医生账户； 执行者： 系统管理员； 前置条件： 系统管理员已登录系统； 后置条件： 无。 基本路径： a）进入医生账户管理界面，首先显示当前已存在的医生账户； b）点击某个医生能够详细浏览这个医生的具体内容，同时也能够对这个账户经行删除； 4.4.3查看预约患者信息 在网上招聘系统中，要定期维护问卷，因为每个招聘职位都附有一个磁问卷，应聘者必须回答问卷，才能够提交简历。问卷管理主要是组织问卷，问卷中的所有题目都来自题库，每份问卷都有不同的针对性，针对不同的招聘需求。具体功能
19、描述如下。 用例描述：查看预约患者信息； 执行者： 医生； 前置条件： 医生已登录到系统； 后置条件： 无。 基本路径： a）进入医生所属管理界面； b）经过点击“查看预约患者信息”可显示已成功提交预约信息的患者列表； c）单击某一患者能够查看该患者的详细信息； 4.4.4创立病例 患者在就诊之后，医生应为其建立相应的病例信息，具体功能描述如下。 用例描述：创立病例信息； 执行者： 医生； 前置条件： 医生已登录系统； 后置条件： 无。 基本路径： a）进入医生所属管理界面； b）经过点击左侧导航栏“创立病例”按钮，在右侧填写症状、诊断、处方等病例信息； 4
20、4.5修改病例 医生为患者建立相应的病例信息后，也能够正对相应的情况对病例经行修改，具体功能描述如下。 用例描述：修改病例信息； 执行者： 医生； 前置条件： 医生已登录系统； 后置条件： 无。 基本路径： a）进入医生所属管理界面； b）经过点击左侧导航栏“修改病例”按钮，在右侧可对症状、诊断、处方等病例信息进行修改； 5. 性能需求 根据用户对本系统的要求，确定系统在响应时间、可靠性、安全性等方面有较高的必能要求。 5.1 界面需求 系统的界面要求如下。 1）页面内容：主题突出，站点定义、术语和行文格式统一、规范、明确、栏目、菜单设置和布局合理，传递的信息准确、
21、及时。内容丰富，文字准确，语句通顺，专用术语规范，行文格式统一规范。 2）导航结构：页面具有明确的导航指示，且便于理解，方便用户使用。 3）技术环境：页面大小适当，能用各种常见浏览器以不同分辨率浏览，无错误链接和空链接；采用CSS处理，控制字体大小和版面布局。 4）艺术风格：界面、版面形象清晰悦目、布局合理，字号大小适宜、字体选择合理，前后一致，美观大方，动与静搭配恰当，动静效果好；色彩和谐自然，与主题内容相协调。 5.2 响应时间需求 无论是客户端还是管理端，当用户登录，进行任何操作的时候，系统应该及时地进行反应，反应的时间在5秒以内。系统应能监测出各种非正常情况，如与设备的通信中
22、断，无法连接数据库服务器等，以避免出现长时间等待甚至无响应。 5.3 可靠性需求 系统应保证7×24小时内不宕机，保证20人能够同时在客户端登录，此时系统能正常运行，正确提示相关内容。 5.4 开放性需求 系统应具有较强的灵活性，以适应将来功能扩展的需求。 5.5 可扩展性需求 系统设计要求能够体现扩展性要求，以适应将来功能扩展的需求。 5.6 系统安全性需求 系统有严格的权限管理功能，各功能模块需有相应的权限方能进入。系统需能够防止各类误操作可能造成的数据丢失，破坏。防止用户非法获得网页以及内容。应该使用过滤器（Filter）或拦截器，对非法进入页面进行拦截 6. 产品提交
23、 提交产品为： a）应用系统软件包； b）数据库初始数据； c）系统开发过程文档； c） 系统使用、维护说明文档，提交方式为CD介质。 7. 实现约束 系统的实现约束如下： a）操作系统为WindowsXP； b）开发平台为：MyEclipse7.1； c）数据库为：MySQL6.0。 8. 签字 本需求规格经过双方认可，特签字如表A-2所例。 表A-2 需求规格签字 用户签署信息 企业签署信息 单位名称 大连XXX医院 ( 盖 章 ) 签署人姓名
24、 签署日期 .5.18 单位名称 MJD软件有限公司 （ 盖 章 ） 签署人姓名 签署日期 .5.18 第二章 医院患者管理系统概要设计 1. 导言 1.1 目的 该文档的目的是描述网上招聘系统项目的概要设计，其主要内容包括： ·系统功能简介； ·数据设计； ·模块设计； ·界面设计。 本文档的预期的读者是： ·开发人员； ·项目管理人员； ·测试人员。 1.2 范围 该文档定义了系统的结构和单元接口，但未确定单
25、元的实现方法，这部分内容将在详细设计/实现中确定。 1.3 术语定义 UML：Unified Modeling Language（统一建模语言）的缩写，是一个标准的建模语言。 JSP：Java Server Page（java服务器页面）的缩写，一个脚本化的语言。 MVC:Model-View-Control（模式-视图-控制）的缩写，表示一个三层的结构体系。 JavaBean：用Java语言实现的满足一定功能的类。 2. 系统分析 本系统能够实现网上在线招聘，应聘者经过互联网投递简历进行网上测评。同时，招聘单位能够汇总简历，游览简历，并经过测评结果选择合格的简历，通知面试，
26、进行面试。方便企业与求职者的交流。系统包括管理端子系统和客户端子系统。 管理端子系统包括题库管理、问卷管理、职位发布、简历管理、面试管理、用户管理等功能。客户端子系统包括查询职位，简历录入，回答问卷，提交简历等功能。图2-1和图2-2为客户端和管理端的组成构图。 图B-1 客户端子系统图示 图B-2 管理端子系统 2. 界面设计 3.1 管理端界面设计 管理端的系统管理员界面主要实现添加医生账户、删除医生账户的功能。主要界面设计如下： ·登录界面：经过输入用户各和密码实现用户登录； ·添加医生账户：填入医生的编号，姓
27、名、年龄、职称、特长、科室等信息后点击“添加”按钮完成添加； ·删除医生账户：选择要删除的医生后点击“删除”完成以上那个账户的删除； ·查询医生信息：查询医生账户的信息，能够对医生每天可预约的患者数量进行设定。 ·注销页面：登出该患者管理系统； 具体页面流如图2-3所示。 3.2 客户端界面设计 客户端主要为应聘者提供网上预约就诊的过程，应聘者经过浏览可预约的医生信息后可选择某位医生进行预约，填写个人信息，提交后，提交的预约信息保存到服务器端。 在客户界面，患者首先进入患者管理系统主界面，注册患者账号后即可登录，点击“查询医生信息”按钮能够查看可预约医生的信息，可选择某位医生进行
28、预约；提交预约信息后，能够点击“查询预约信息”按钮查看自己的预约信息是否成功提交到服务器；若患者已经完成一次就诊，且医生已经为其创立了病例信息，则能够经过点击“查询病例”按钮查看自己的病例信息。 具体页面流如图B-4所示 4. 体系结构 系统的总体结构设计遵循如下原则。 1）系统应具有良好的适应性：能适应用户对系统的软件环境、管理内容、模式和界面的要求； 2）系统应具有可靠性：采用成熟的技术方法和软件开发平台，以保证系统在以后的实际应用中安全、可靠； 3）系统应具有较好的安全性：应提高安全机制和用户权限限制机制的完善程度，确保数据的受限访问； 4）系统应具有良好的可维护性：系统
29、应易于维护、安装； 5）系统应具有良好的可扩展性：系统应适应未来信息化建设的要求，能方便地进行功能扩展，以建立完善的信息集成管理体系。 本系统采用体系结构，struct是一个基于模型（Model）一视图（View）一控制器（Controller），即MVC模式的应用架构的开源框架。 4.1 体系结构 当前软件项目中有很多体系结构，其中struct是比较流行的一种。 4.1.1 struct体系结构 对于开发Web应用，要从头设计并开发出一个可靠、稳定的框架不是一件容易的事情。随着Web开发技术的日趋成熟，在Web开发领域出现了一些现成的优秀的框架、开发者能够直接使用它们，struc
30、t就是一个很好的框架结构，它是在JSP Model2基础上实现的一个MVC框架，在struct框架在模型由实现业务逻辑的JavaBean或者EJB组件构成，控制器由ActionServlet和Action来实现，视图由一组JSP文件组成，图2-5显示了Struct实现的MVC框架。 图B-3 管理端的页面流程 患者网上注册 患者网上登录 显示医生信息 选择某位可预约医生 填写预约信息 提交 查询预约信息 查询病例信息 图B-4 客户端的页面流程 其中： ·视图，就是一组JSP文件，这些JSP文件没有业务逻辑，也没有模型信息，只有标签，这些标签能够是标准的JSP
31、标签或者是客户化标签，如struct标签库的标签。另外，一般将struct框架中的ActionForm Bean也划为视图模块，ActionForm Bean是一种JavaBean，除了具有一些JavaBean的常规方法外，还包含了一些特殊的方法，用于验证HTML表单数据以及将其属性重新设置为默认值。Struct框架利用ActionForm Bean来进行视图和控制器之间表单数据的传递。Strcut框架将用户输入的表单数据保存在ActionForm Bean中，将它传递给控制器，控制器能够对ActionForm Bean中的数据进行修改，JSP文件使用struct标签读取修改后的ActionF
32、orm Bean的信息，然后重新设置HTML表单。 控制器 ActionServlet 视图 JSP Struct-config.xml 模型 JavaBean EJB Action Action Action 浏览器 Web 服务器 图B-5 struct实现的MVC框架 ·控制器，控制器由ActionServlet类和Action类实现，ActionServlet类是struct框架中的核心组件，是这个MVC的中央控制器的角色。ActionServlet主要负责接收HTTP请求的信息，根据配置文件struct-config.xml的配置信息，将请求转发
33、给适当的Action对象，如果该Action对象不存在，ActionServlet会先创立这个Action对象.Action类负责调用模型的方法，更新模型的状态，并帮助控制应用程序的流程，对于小型简单的应用，Action类本身也能够完成一些实际的业务逻辑。 ·模型，模型表示应用程序的状态和业务逻辑，业务逻辑常常由JavaBean或者EJB组件实现。 如果在Web应用开发中套用现成的struct框架，就能够简化每个开发阶段的工作，开发人员能够更加有针对性地分析应用需求，不必重新设计框架，只需在struct框架的基础上，设计MVC各个模块包含的具体组件，在编码过程中，能够充分利用struct提
34、供的各种实用类和标签库，简化编码工作。 Struct框架能够方便迅速地将一个复杂的应用划分成模型、视图和控制器组件，而struct的配置文件struct-config.xml能够灵活地组装这些组件，以简化开发过程。 4.1.2 系统体系结构 根据系统分析结果，该系统从结构上应满足： ·基于游览器进行显示以方便用户使用； ·采用MVC的三层体系结构，分化各个功能组件； ·采用JDBC技术与数据库通信以便于数据库的转换； ·采用标签技术完成动态页面的简单逻辑。 本系统的体系结构如图B-6所示，它基本遵循了struct体系的MVC框架规范。 视图(V)层:用户界面(浏览器) H
35、TML,CSS,DHTML,JavaScript,XML 视图(V)层:服务器端脚本 Connects UI to Business Objects, Java Server Pages,Java Servlets 控制(C)层:分布式组件 JavaBean 模型(M):数据源和持久对象存储 ODBC, JDBC, OLEDB, ADO, XML, LDAP 图B-6 系统的体系结构 其中： ·表示层，用于与用户进行交互并显示结果。包括所有的JSP，提供用户界面，接受用户输入，还包括相应的ActionFrom Bean，用来存放表单数据，并进行表单数据验证； ·控制层
36、包括所有的Action类，它完成三项任务，一是进行业务逻辑验证，二是调用模型组件，三是决定将合适的视图组件返回给用户； ·模型，包括进行逻辑处理的JavaBean等，数据库采用ODBC技术以提供数据库的可移植性。 体系结构的具体拓扑图示如图B-7所示。 图B-7体系结构拓扑图 1）客户层：用于与企业信息系统的用户进行交互以及显示根据特定业务规则进行计算后的结果。本系统将完全采用基于Web的（B/S架构）客户端，即用户能够直接经过浏览器来访问和使用本系统。 2）中间层：这相当于三层标准架构中的Web应用服务层，支持诸如响应客户请求以及查询等功能。而且由中间层进行逻辑处理，再将
37、处理的结果反馈给客户或者发送到数据库中。 3）服务层：主要是数据库系统，这里的数据库系统主要是关系数据库系统（RDMS）。 4.2 系统进行环境 下面讲述系统运行的网络结构，硬件、软件环境。 4.2.1 网络结构图 本系统的网络拓扑图如图B-8所示。 图B-8 网络拓扑图 其中的局域网用户机主要是公司内部的人员能够使用的机器，运程用户机主要是指经过互联网登录系统的人员使用的机器，能够是公司内部的人，也能够是应聘者。 4.2.2 硬件环境 本系统的硬件环境如下。 1）客户机：普通PC ·CPU：P41.8GHz以上 ·内存：256MB以上 ·能够运行IE
38、5.0以上或者Netscape4.0以上版本的机器 ·分辨率：推荐使用1024×768像素或以上 2）Web服务器 ·CPU：P42.0GHz ·内存：1GB以上 ·硬盘：80GB以上 ·网卡：KMb/s速度网卡 3）数据库服务器 ·CPU：P42.0GHz ·内存：1GB以上 ·硬盘：80GB以上 4.2.3 软件环境 本系统的软件环境如下： ·操作系统：UNIX/Linux/Windows 或以上版本 ·数据库：SQL Server ·开发工具包：JDK Version1.4.2 ·开发环境：eclipse-SDK-3.1.2win32 ·Web服务器
39、Tomcat ·浏览器：IE6.0以上 1） 数据库及操作系统：对于核心数据库来说，选择一个合适的数据库系统对我们的系统运行是很重要的，选择数据库的关键因素是要考虑预计会有多少人同时访问数据库；正常工作时间的级别；用来访问数据库的应用程序的类型；运行数据库的服务器的硬件和操作系统类型以及管理人员的专业技术水平。当前市场上适用于中小型企业的数据库产品有IBM DB2、Microsoft SQL Server系列，Oracle系列。所有这些产品都基于SQL语言。同时，它们还拥有精度复杂的安全控制以适应不同的商业需要。服务器操作系统使用Windows Server 考虑到价格因素、易用性，
40、我们使用SQL Server 作为系统后台数据库系统，服务器操作系统采用Windows Server。 2）Web服务软件：当前的Web服务器软件有很多种，成熟而且稳定的有Apache、Tomcat和Microsoft的IIS，它们占据着Web服务器市场最大的份额。Tomcat是Sun和Apache合作推出的JSP Server，支持Servlet2.2及JSP1.1等版本。而且Tomcat未来将会取代Jserv，成为Apache主要的Servlet&JSP Engine。Tomcat在设计上是以独立的Server执行，而不像Jserv是附在Apche中，这样就更能够在servlet中，发
41、挥非HttpServlet的能力。Tomcat是Java程序，因此只要有JDK就能够使用，不需要考虑操作系统平台。因此这里选择Tomcat作为Web服务器。 5. 数据模型 本系统的数据模型设计内容主要是进行数据库的设计。 5.1 数据库的概念结构模型设计 概念设计用来反映现实世界中的实体、属性和它们之间的关系等的原始数据形式，建立数据库的每一幅用户视图。图2-9是系统E-R图。 图2-9 系统的E-R图 5.2 数据库的逻辑结构模型设计 数据库的逻辑设计是将各局部的E-R图进行分解、合并后重新组织起来形成数据库全局逻辑结构，包括所确定的关键字和属性、重新确定的记录结构、
42、所建立的各个数据之间的相互关系。根据本系统需求分析，系统的数据库包括了医生表、患者表、病历记录表、预约记录表、管理员表、医生最大可预约数表、医生当前可预约数表。 5.3 数据库物理结构模型设计 信息存储结构的设计在系统的设计中至关重要，要考虑到数据冗余、系统执行效率、信息控制以及维护等方面的要求。信息的管理离不开数据库的支持，我们采用MySQL数据库管理系统。 数据表详细结构设计 医生表(doctor)的详细设计结构。 字段名 类型 备注 约束条件 默认值 DID VARCHAR(5) 医生编号 主键 Name VARCHAR(12) 姓名 索
43、引 Age TINYINT(3) UNSIGNED 年龄 0 Password VARCHAR(41) 密码 初始化：DID Sex TINYINT(3) UNSIGNED 性别 1-男 0-女 1 Level VARCHAR(12) 医生职称 Section VARCHAR(20) 所属科室 索引 Specialism VARCHAR(20) 医生擅长 Phone VARCHAR(15) 联系电话 患者表(patient)的详细结构 字段名 类型 备注 约束条件 默认值
44、 PID MEDIUMINT(8) UNSIGNED AUTO_INCREMENT 患者编号 主键 Name VARCHAR(12) 姓名 Username VARCHAR(20) 登录用户名 惟一索引 Password VARCHAR(41) 密码 Age TINYINT(3) UNSIGNED 年龄 0 Sex TINYINT(3) UNSIGNED 性别 1—男 0—女 1 Address TINYTEXT 家庭住址 Phone VARCHAR(12) 联系电话 History
45、 INTEGER UNSIGNED 患者病历 病历表(history)的详细结构 字段名 类型 备注 约束条件 默认值 HID INT UNSIGNED(10) AUTO_INCREMENT 病历记录编号 主键 Doctor VARCHAR(5) 主治医生编号 索引 Description TINYTEXT 症状 Diagnose TINYTEXT 诊断 Patient MEDIUMINT(8) UNSIGNED 患者编号 索引 0 Rx TINYTEXT 处方 Finished
46、 TINYINT(1) UNSIGNED 就诊是否结束 1-是 2-否 0 FDate DATETIME 开始时间 SDate DATETIME 结束时间 预约记录表(pinqueue)的详细结构 字段名 类型 备注 约束条件 默认值 QID INT UNSIGNED(10) AUTO_INCREMENT 记录编号 主键 Patient MEDIUMINT(8) UNSIGNED 患者编号 索引 0 Doctor VARCHAR(5) 主治医生编号 索引 Day TINYINT(1) UNSI
47、GNED 预约就诊时间 0-周日 1-周一 2-周二 3-周三 4-周四 5-周五 6-周六 0 AP TINYINT(1) UNSIGNED 预约就诊时间 0-上午 1-下午 0 Date DATETIME 预约时间 管理员表(administrator)的详细结构 字段名 类型 备注 约束条件 默认值 AID TINYINT(2) UNSIGNED AUTO_INCREMENT 管理员编号 主键 Username VARCHAR(20) 登录时的用户名 惟一索引 Password VARCHA
48、R(41) 登录时密码 Email VARCHAR(20) 电子邮件 Name VARCHAR(12) 姓名 Phone VARCHAR(15) 联系电话 可为空 医生最大可预约数量表(appointment)的详细结构 字段名 类型 备注 约束条件 默认值 DID VARCHAR(5) 医生编号 主键 SunA TINYINT(3) UNSIGNED 周日上午最大可预约数 0 SunP TINYINT(3) UNSIGNED 周日下午最大可预约数 0 MonA TINYINT(3) U
49、NSIGNED 周一上午最大可预约数 0 MonP TINYINT(3) UNSIGNED 周一下午最大可预约数 0 TueA TINYINT(3) UNSIGNED 周二上午最大可预约数 0 TueP TINYINT(3) UNSIGNED 周二下午最大可预约数 0 WedA TINYINT(3) UNSIGNED 周三上午最大可预约数 0 WedP TINYINT(3) UNSIGNED 周三下午最大可预约数 0 ThuA TINYINT(3) UNSIGNED 周四上午最大可预约数 0 ThuP TINY
50、INT(3) UNSIGNED 周四下午最大可预约数 0 FriA TINYINT(3) UNSIGNED 周五上午最大可预约数 0 FriP TINYINT(3) UNSIGNED 周五下午最大可预约数 0 SatA TINYINT(3) UNSIGNED 周六上午最大可预约数 0 SatP TINYINT(3) UNSIGNED 周六下午最大可预约数 0 医生当前可预约数量表(currappointment)的详细结构 字段名 类型 备注 约束 条件 默认值 DID VARCHAR(5) 医生编号 主键
©2010-2026 宁波自信网络信息技术有限公司 版权所有
客服电话：0574-28810668 投诉电话：18658249818
浙ICP备2021020529号-1 | 浙B2-20240490
关注我们 ：
