戴海伟 谭碧竹
用户层的主要任务是提供可视界面,以便用户可以通过这个界面录入和观察数据。
用浏览器作为客户端,其优点在于客户端界面统一,便于熟悉和操作,又不需要对软件进行配置,对于开发人员来说,可以撇开前台的繁琐工作,集中精力处理后台的关键事务,从而减少了工作量,节约了整个系统的开发时间。
在医院设备、物资信息资料管理系统中,包括立项建议、购买论证(包括招标式竞争采购)、项目实施、仪器安装和验收、仪器维修和保养、仪器报废处理等,由于每个人只负责项目流程的一部分,考虑到客户端工作人员的可扩展性,因此采用浏览器模式。
医院设备、物资信息资料项目系统的数据录入界面显著特点是在输入、修改时采用了目前较为流行的树型结构显示条,输入情况一目了然,修改时很容易找到相应的记录,从而节约工作时间,提高工作效率。树型结构层次清晰,能方便的反映工作分解结构的各个层次。
在设计客户端界面时,还注意了风格的统一问题,比如:窗体的位置、大小、字体的选择等,如用灰色表示只读,不能修改。特别是对于某些必须填写的字段,用醒目的红色表示,加以提醒。对于某些不能重复的关键字段,在设计上采用自动校验的功能,当输入重复值时,自动弹出提示框,直到输入不重复值时才能继续输入下一字段。
业务逻辑层完成的是“数据中转站”的功能,它响应用户服务层的请求,一方面从数据服务层为用户层取得所需的数据,回送给用户层显示;另一方面对用户层提交的数据进行业务规则的校验,符合规则的数据才被二次提交给数据服务层存储。因此,业务层是沟通用户服务层与数据服务层的逻辑桥梁,其主要功能是完成业务规则的校验和数据的提供。
选择三层结构是为了减少客户端的维护、配置工作,把它从前台移到中间业务层来实现。业务层为用户层提供数据,在业务层配置了和数据服务层的连接,不需要为每一台客户端应用程序再重新配置。
2.1 业务层组件的划分
将数据的录入、修改和数据的查询、统计划分为不同的两类组件,这是因为一方面它们的使用人员和场合有较大的差异,另一方面,从后台数据库来看,数据录入、修改是在表的基础上进行的,查询则主要借助于存储过程来完成。它们的数据提供者不同。所以,参照上面的第一条原则,我们把中间业务层首先划分为资料维护类和查询统计类。再根据业务功能特点,进行业务功能的详细划分。
2.2 提供业务规则
提供业务规则的组件和提供数据的组件是不可分的。在逻辑上它们是中间业务层提供的两种功能,在物理上存在于相同的组件上。规则只有依附在数据上才有意义,对数据起过滤、计算的作用。把数据从后台数据库服务器牵引到中间业务层的同时,可以选择把数据库本身的约束也引进来,但不需要把所有的业务规则都集中在中间业务层实现,在设计系统时,实际上在三个层面中都分布了业务规则,只是数量和性质各不相同。
2.2.1 在客户端实现了一些非常简单的业务规则。
某些字段不能为空,或者必须大于零之类的限制,通过设置数据感应控件的属性可以完成,不用额外添加代码,没有必要把这个错误送到业务规则层,甚至数据服务层再被退回,反而增加了处理错误的代码。
2.2.2 在业务规则层实现了一些逻辑依赖关系。
只有当货币安置字段的值为0时,才能在安置类型字段中选择一次性安置或过渡安置。
2.2.3 在数据服务层,利用数据库本身提供的主外键约束、触发器、存储过程等完成了数据完整性校验和大量的查询工作。这些工作可以在业务层自己编写代码完成,但专业的DBMS系统处理起来更方便、快捷,还能针对存储过程进行专门的优化,提供系统的执行效率,减少网络流量。
数据服务层主要用来完成数据库相关服务。从数据完整性、索引、并发性方面对数据库进行了设计。
3.1 数据完整性
为了保证数据质量,有必要加强数据库的数据完整性。数据库的数据完整性包括以下三个方面:
3.1.1 实体完整性
必须确保表中的每一行都是独立的。每一行都能够被设置指针,并且能够在不干扰其他行的情况下被访问。独立形式的实体完整性是通过建立主关键字约束,唯一索引、唯一约束或 IDENTITY 特征来实现的。
主关键字是表中的一列或多列,其所具有的值对表格中的其他各行而言必须是唯一的。每个表格只能有一个主关键字,并且主关键字不允许是空值。主关键字被创建后,通过主关键字建立唯一索引来实现表格的唯一性。通过给表格设定主关键字,不仅实现了表格中行的独立,而且访问设有主关键字的表格,其数据的检索也更加快捷。
创建一个IDENTITY列是一种更为复杂、更为先进的强化独立性的方式。主关键字列用 IDENTITY属性来定义,这样的好处是:当用户插入行时,数据库会同时自动给被插入行的每列赋值,用户不必知道插入行的每个值,也无须存储。当索引是整数时,数据的访问更加快捷,因而功能也相应增强。
每个表格只允许有一个主关键字,而有时需要非主关键字段中的唯一值。这种情况下,可以使用UNIQUE 约束来给非主关键字段建立唯一索引。如果用户插入一个已经在表格中存在的行,数据库将给出错误提示,告诉用户一个相同的行已经存在,以此防止相同的行插入。
3.1.2 域完整性
域完整性,是指对一个给定的列而言,只有一定范围内的数值是有效的。通过规定数据类型、使用CHECK 约束和规则、使用缺省值、非空定义以及外键约束,可以限定有效值的范围。
数据类型用于定义可以放置于列、局部变量和存储过程参数中的数据类型,可以直接使用数据库提供的数据类型,也可以自己定义数据类型。数据类型对填入某列的数据加以限制。例如,字符型数据不能插入到以数字型数据创建的列中。
CHECK 约束可对插入某列的数值加以限制。表格中的一列可以有多个 CHECK约束。用户也可以随时给新创建的或已经存在的表格增加限制。
有时,用户可能不知道确切的数字,或者数据中带有空值,而表格中的该列不允许使用空值,或者用户本身不希望出现空值。在这些情况下,可以使用缺省值。缺省值可以在创建或变更表格时用 DEFAULT关键字来定义。例如,用户想对某列中的数值取平均值,此时,如列中出现空值,则该命令不能被执行。在此情况下,可以给每行中的每一列空值上赋一缺省值0。这样平均运算既有效,又包含了表格中每一行的数字。
在创建表格的同时定义某一列为 NOT NULL,能够防止该列被赋以 NULL值。这是确保数据完整性,特别是域的完整性的另一种方式。列中的 NULL意味着该值是未知的。NULL 的运行方式不同于0 值或空值,因为它们不能相互比较而且也不相等。在使用 SQL 命令时,NULL 将引起许多麻烦,因为在遇到 NULL值时,每条命令都将不能正常运行。
外键约束与主关键字或唯一约束共同使用,可以确保被插入列中的值也被包含在另一个表中的主关键字之中。它不仅被用以确保域的完整性,而且对参照完整性也很重要。
3.1.3 参照完整性
使用参照完整性意味着要维持两个表格之间的关系,并且数据库中不允许孤立行的存在。数据库不允许用户在从表中添加主表中不具备的行。同时,如果对应于主表的某行在从表中有记录时,也不允许对该主表行进行删除和修改。在数据库中通过上文讲述的外键约束和 CHECK 约束来实现参照完整性。
3.2 并发性
并发性是指在多用户同时访问数据时,通过锁定保持事务完整性的功能。为大量并发用户开发的系统,最好能在一段时间内保持事务。排他型锁可以起到这一作用,它可以阻止其他事务读取表中的数据,直到当前的事务被确认或回滚时为止。
4.1 总体原则
4.1.1 全局统一规划、统一标准、统一建设、统一维护。
4.1.2 在流程控制方面增加一些辅助表。
4.1.3 树立用户数据是最重要的思想,数据的安全、完整性是整个数据库设计必须遵守的原则,任何发生的信息都要永久备份存档。
4.2 数据库的优化和性能保障
4.2.1 作为一个网络环境下的数据库应用,应重视后台数据库的管理工作。
4.2.2 该系统的性能主要与程序和数据库配置有关,程序主要是复杂的SQL数据库,部分对性能影响较大,复杂的查询将进行严格的压力测试。
4.2 数据库的优化和性能调整是一个很大的课题,可以通过交流、培训等方式逐步加强这方面工作。
对流行的数据库的管理简单比较,ORACLE对数据库系统的前期规划比较重视,手工调整的要求比较高,当然管理工具也较强大;SYBASE 的管理工具较弱,需在命令行做很多工作,而且在 NT 平台上的产品性能不佳;相对来说,SQL SERVER 自动适应功能较好,比较适合。
5.1 运行环境及开发工具
5.2 开发工具
.NET、SQL Server 2000基于Windows编程
5.3 设备
服务器端:
(1)处理器CPU:PIII500(含)以上;
(2)内存RAM:256MB(含)以上;
(3)硬盘HD:500MB空间(含)以上;
(4)显示设备:800x600真彩(含)以上。
客户端:
(1)处理器CPU:Celeron300(含)以上;
(2)内存RAM:64MB(含)以上;
(3)硬盘HD:100MB空间(含)以上;
(4)显示设备:800x600真彩(含)以上。
5.4 支持软件
以下给出系统运行的软件支撑环境:
服务器端:
Win2000 Server 操作系统;
SQL Server 2000 数据库系统;
IIS4.0(含)以上。
客户端:
Windows Me/Windows 98/Windows 2000 Professional/Windows XP;
具有IE5.0以上功能的浏览器。
6.1 测试步骤
软件的测试是贯穿整个开发过程的,在系统完成后再把整个系统作为一个单独的实体来测试是不现实的。经过以下几个步骤对系统进行测试:
6.1.1 模块测试
在设计阶段划分的功能模块,明确地规定了它应完成的功能、提供的接口,而且都相对比较独立,测试起来比较简单。首先必须先通过编译程序检查并且改正所有语法错误,排除编码引起的错误。然后再对重要的执行通路进行测试以便发现模块内部的错误。模块测试的目的是保证每个模块作为一个单元能够正确运行。
6.1.2 子系统测试
子系统测试是把经过单元测试的模块放在一起形成一个子系统来测试。模块相互间的协调和通信是这个测试过程中的主要问题。
6.1.3 系统测试
系统测试是把经过测试的子系统装配成一个完整的系统来测试。在这个过程中应该验证系统是否提供了需求说明书中指定的功能,可能会有一些设计和编码的上的错误暴露出来。
6.1.4 系统试运行
系统在完成初步测试工作后并没有立即投入使用,而是经过了一段时间的试运行,对系统产生的关键数据进行演算检查。在确信系统具有良好的稳定性、正确性后才正式运行。
7.1 整个系统的开发有以下几个特点:
(1)安全保密性:在系统的安全性方面有较高的安全防护,基本的安全防护为静态式密码,并且严格管理用户密码,只有在特定用户状态下才能对用户的信息资料进行访问查询。对用户进行严格的授权管理。
(2)易用性:由于项目资料管理针对医院设备处与其他业务部门,在其立项、任务管理、计划、执行、检查等业务都属于日常工作。因此,系统以易用作为设计依据,使系统尽可能简便、易用。采用灵活通用的表单定义方式,由用户自定义表单界面,以满足不断变化的业务需要。
(3)B/S结构:使系统在可扩展性、易维护性等方面有很大的优势。
7.2 故障处理:
当发现运行异常现象时,具有报警信息提示,并将出现的异常记录在日志文件中,方便查阅。
7.3 由于医院设备、物资信息资料管理系统最终运行的结果是加强了文档管理,预先规定活动需要登记的文档类型,活动在执行时,根据这些文档类型上载文件,并作为最后检查的依据。同时文档管理全面、灵活,文档之间可以继承、借鉴,方便了用户查阅、使用,对文档进行了严格的版本管理。
7.4 医院设备、物资项目管理信息系统不同于其他产品的制造,医院设备、物资信息项目管理系统的整个过程都是设计过程,没有制造过程,且具有使用周期长、不可预见因素多等特点,因此加强了审验的管理,在不同阶段定义审验标准,在实施过程中强调审验,以及时了解工作进展情况,对使用的中间过程进行监控,以确保进度,以保证医院设备、物资信息资料项目管理系统的质量。
[1] 黄志球. 数据库应用技术基础[M].北京:机械工业出版社,2003.
[2]陈勇强. 项目采购管理[M].北京:机械工业出版社,2004.
[3]Paul C. Dinsmore. Creating the Project Office: A Manager's Guide to Leading Organizational Change[M].北京:清华大学出版社,2004.
[4]美国项目管理协会.项目管理知识体系指南(第3版)[M].北京:电子工业出版社,2006.
[5]马丽春,陈校云,夏磊,等.项目管理在医院行政后勤管理中的实践与体会[J].中国卫生事业管理,2009(7):454-455.
[6]戴海伟,张亚琦.非形式下适用于医学物件库管理的模型设计[J].中国医学装备,2010,7(1):4.