《南软医院管理平台方案（大型医院）.pdf》由会员分享，可在线阅读，更多相关《南软医院管理平台方案（大型医院）.pdf（366页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、医院信息化平台方案技术标书附件 1HO-11-21目录目录目录.1第一章、医院信息化平台方案概述第一章、医院信息化平台方案概述.4超大型综合医院特征需求分析.4大平台架构方案.4贵院信息管理系统建设的要求和定位.7贵院信息项目建设目标.10贵院数字化平台整体规划.11系统构成及概要进度规划.13第二章、第二章、HEALTHONE 平台关键系统技术平台关键系统技术.15第三章、关键专项解决方案第三章、关键专项解决方案.371、“云”平台模式架构系统.372、绩效考核解决方案（PERFORMANCEASSESSMENT）.393、风险预警与协作广播方案.444、高端体检中心解决方案.465、多账户
2、双加密模式一卡通解决方案.1146、格式化电子病历解决方案.1247、决策支持系统.1628、PACS 系统部署.1699、嵌入一体式合理用药（数据库由成都美康公司提供）.18810、成本核算.20011、安全体系建设方案.213第四章、第四章、HEALTHONE 平台基础功能说明平台基础功能说明.244一、HEALTHONE平台概述.244二、运营营销与管理部分.244三、临床诊疗部分.244四、药品管理部分.245五、经济管理部分.245六、综合管理与统计分析部分.245七、外部接口部分.245第五章、第五章、HEALTHONE 技术体系架构技术体系架构.246第六章、系统参考标准第六章、
3、系统参考标准.253第七章、各部分功能描述如下第七章、各部分功能描述如下.260第八章、数据分析第八章、数据分析.294第九章、项目管理、项目测试、验收方案第九章、项目管理、项目测试、验收方案.307第十章、项目实施计划第十章、项目实施计划.343第十一章、硬件清单第十一章、硬件清单(供参考，向第三方采购供参考，向第三方采购).354第十二章、公司简介第十二章、公司简介.360第十三章、案例介绍第十三章、案例介绍.错误！未定义书签。错误！未定义书签。第一章、医院信息化平台方案概述第一章、医院信息化平台方案概述超大型综合医院特征需求分析超大型综合医院特征需求分析基本需求：基本需求：一个稳健的基础
4、平台，能胜任日门诊量万级压力流程合理，并能灵活再造，可以轻松定制各种业务流程，如方便病人和医护为核心的便捷流程，不是传统国有医院僵化的模型重要需求：重要需求：全成本核算：实现可自由定义的成本分摊模型，且不增加财务管理成本的全过程评价的供应链管理：医院药品采购是最容易产生灰色地带的环节，通过供应链管理将灰色机会屏蔽，涵盖从医生药品回扣处方到药品采购回扣各环节多维度绩效评价管理：将工作量，质控，成本及协作和服务评价作为参数，根据可调节权重形成评价体系护士工作量的准确统计：护士工作有特殊性，通过 RFID，条形码等低成本高准确实现护理工作量统计高端 VIP 流程管理：高端 VIP 全程解决方案，从挂
5、号到结账，从入院到出院，从资源到信用额度全流程自定义风险预警广播：对于死亡病人病历审查预警，到危机值预警，以及自定义预警预案通过快速的短信与广播平台，提高医院对特殊事件的相应效率营销管理：建立准客户，客户，售后关怀促进对医院的认可和忠诚度。以合理的数据模型分析业务数据，提供营销建议高端体检系统：通过高端体检解决方案，构建健康管理数据，为医院做客户积累，并构建高端目标客户群体大平台架构方案大平台架构方案本次医院信息化目标非常清晰，希望通过高规格规划，实现全数字化医院，目前医院已经引入大量一流的医疗仪器与设备，完整的信息化平台为贵院医疗服务提供强有力的支撑，提供服务流程优化，提供以绩效评价基础的决
6、策分析架构系统。一个可以延伸的平台系统，HealthOne 将网络延伸到医院外：1、病人可以通过手机、互联网预约,查询报告，和健康档案等2、管理者可以通过移动平台查询数据3、医护可以通过移动医护站工作一个专家在线，一个病人在线的，管理者永远在线的系统平台。开放性支持移动与对外展示（WEB）综合管理与统计分析经济管理药品管理临床诊疗运营营销与管理核心平台应用目标是应用目标是：支持医院门急诊、住院等医疗业务的高效良好运转；促进医院在财务、医技、药品、器械、后勤等方面与医疗活动的紧密协作和管理要求，提高医院核心生产力；依靠信息系统，扩展医疗活动和服务的内涵和范围，为病患提供更好的服务；增强医院管理能
7、力。最终实现病人服务“永远在线”医护服务“永远在线”的远期建设目标。系统的通用性原则有：先进行系统的通用性原则有：先进行，标准化、安全性和可扩展性等的原则；分步实施，阶段见效；界面友好，人性化。一般性需求一般性需求：要求充分考虑贵院未来的发展，在系统架构方式上充分考虑系统的投资情况和扩展情况。构建的系统必须是集成化、平台化设计，当服务地点和容量增加时，不需要替换已有的硬件和软件；并且需要承诺免费提供以某种技术实现方式与其他系统厂商合作进行系统融合的二次开发服务；必须实现较高的标准化要求，以达统一管理的要求；可以与第三方应用软件系统进行基于国家标准和 HL7 的消息交换，以适应集团式医院不断变化
8、的需求和系统的扩展升级；可以扩展使用第三方数据交换平台，进行方便的组合。标准化需求标准化需求：需要与其他系统进行数据交换的数据必须符合国家和地方卫生行政部门正式颁布的数据交换要求，例如：医疗保险等；各种医学术语名称及所有疾病名称应当符合现行的国家或国际标准，例如：ICD-10 编码等；能够支持 HL72.3.1 及以上版本的要求，包括可以接收、存储、发送 HL7 格式的数据；能够扩展支持国际相关编码标准，例如：SNOMAD、LONIC 等，对于特定的系统应当支持该系统内的国际工业标准。安全性需求安全性需求：系统具有抵御外界环境和人为操作失误的能力；保证不因操作人员的误操作导致系统的崩溃等。有足
9、够的防护措施，防止非法用户侵入；系统需要提供基于用户名、密码的用户身份认证系统和分别基于角色、基于功能的用户权限管理功能；充分保证数据安全性、完整性。需要提供数据库数据恢复和备份。保证系统的可靠性和稳定性，必须保证系统的 365724 正常运行，并提供系统异常情况下的后备解决方案，对存储的数据，应有冗余保护措施，保证用户数据的随时可提取性，对于容错及冗余都有相应的安全保护机制。贵院信息化建设必将经历一个从无到有病逐步完善的过程，在不同阶段进行不同重点项目的建设。最终目标是以患者为中心，以医疗为主线，以提高医院经济、社会效益，提高医院科学管理水平，提供医生医疗水平、提高医院医疗、服务质量为基本点
10、，带动医院医、教、研全面发展，实现医院全面信息化经营，努力朝实现数字化医院方向发展，除了构成医院自身的、功能齐全的信息管理系统综合应用平台外，还必须是一个开放的、多系统集成的、能支持与医院之外的卫生数字化体系进行数据交换和信息共享的信息系统应用体系。其内容则包括了 IT 组织、技术架构、应用系统建设等方方面面。在整个过程总应遵循以下三个基本原则：1、先行初步搭建好 IT 组织和必要的技术平台架构，再部署各应用系统2、整体部署功能子系统，核心应用原则上一次性完成，扩展应用可以后期补充3、尽可能的采用商品化的软件解决方案，通过抽象模型解决方案标准化核心要点如下：1、贵院的信息系统希望统一完整，能够
11、为病人提供更优质的医疗服务，能够方便医院的工作，能够为医院的管理提供支持。2、医疗服务是以一定的制度为基础，因此贵院信息系统的建设需要充分考虑与医院制度的协调协作，需要在实践的基础上发现符合自身规律的流程，并通过信息系统得固化形成规范化的制度，为医院的规范化和制度化发展提供决策基础和技术支持。3、贵院的信息系统需要立足于一个较高的起点，为病人提供更优质、更快捷、更廉价、更安全的医疗服务。4、贵院需要逐步建立高标准的基于企业资源计划的计算机管理信息系统为医院的发展提供支持。贵院信息管理系统建设的要求和定位贵院信息管理系统建设的要求和定位根据贵院业务发展和实际应用的需要，同时兼顾考虑到要保证整个系
12、统的高稳定性，高性能以及未来的扩充性，因此对整个系统的要求如下：充分考虑随着贵院医疗业务的扩展以，整个系统必须随着医院的发展而作出相应的扩展；产品必需符合 2010 版病历书写基本规范，及 2010 版电子病历基本规范（试行）和卫生部信息系统功能规范的要求；体现“以病人为中心，以医疗信息为主线”的设计思想，真正达到医院信息管理学的要求，最大限度满足实际工作的需要，支持联机事务处理，支持科室信息汇总分析与收支经济核算，支持医院领导对医疗动态与医疗质量的宏观监督与控制，HIS 软件以现行医院体系结构、管理方式和管理程序为基准，充分考虑各业务层次、各管理环节数据处理的实用性。用户接口和操作界面设计尽
13、可能考虑人体结构特征及视觉特征，界面力求美观大方，操作界面力求简捷实用;满足医院在门、急诊信息管理：住院病人信息管理、药品管理、病案管理、财务核算管理、后勤管理、行政管理等实际工作需要；综合查询及辅助决策支持等方面实现计算机数字化的需求，做到在全院内信息、数据高度共享、实现医院管理的现代化;系统中采用目前流行的成熟的先进技术，如支持病人使用条码或磁卡作为门急诊、住院病人的身份识别手段。支持多种支付手段。支持医院的流程变化及重组;提供符合医院实际情况的流程改造方案；为适应将来的发展，软件系统应具有良好的可拆分性、可扩充性、可移植性和安全性；系统的安装卸载简单方便，可管理性、可维护性强；软件设计模
14、块化、组件化，并提供配置模块和客户化工具。系统根据需要可随时调整设置各种单据、报表等的打印输出格式。应用软件与数据库系统的设计及应用要做到安全可靠，防止非法入侵；要防止合法用户使用数据库时向数据库加入不合语义的数据，对输入的数据要有审核和约束机制；具有用户权限控制和身份认证功能，系统须保证“7 天 24 小时”安全运行，数据库完整有效的备份方案，以防止灾难发生。协调好各种数据，做到“数出一门”、“算法统一”、“度量一致”，保证系统数据的一致性和有效性；数据库结构的设计应充分考虑发展的需要、移植的需要，具有良好的扩展性、伸缩性和适度冗余。窗口业务处理系统要求响应时间快，输入输出方便快捷，既要支持
15、鼠标，又要支持键盘操作。输入项目的定位要灵活、快捷。网络软件、平台软件、数据库软件和工具软件等均不得使用盗版和非法正版。若发生版权纠纷等问题，贵院概不承担任何责任，由此造成的一切后果和损失均由中标方承担。软件方案应充分考虑到系统的稳定性，安全性，可靠性及高性能。贵院信息项目建设目标贵院信息项目建设目标贵院数字化建设的目标是建立全面的管理信息系统和临床信息系统。用最新的最先进的IT 技术对全院的信息资源（人，财，物，医疗信息）进行全面的数字化，全面的优化和整合医院内部的资源以及医院外部全社会的信息资源为医院临床，管理服务，运用所有的信息资源为患者提供先进的，便捷的，人性化的医疗服务;同时建立全院
16、科研教学的信息平台和数据仓库；以提高医院服务水平，技术水平及管理水平，提高医院的整体经营效益，同时建设医院的数字文化，全面建设现代化的数字医院满足以下特征:人性化人性化:贵院数字化的建设应本着以人为本，以病人为中心的原则，在系统的每个细节都应该体现人文关怀主义，考虑如何更加的方便患者，更加方便业务人员，更加的人性化。一体化一体化:贵院的数字化建设不再考虑由各个独立的系统来构建，通过 HealthOne 平台实现基于 HL7 标准协议的数据聚合，与传统的系统集成有根本上的不同，不再需要相互调试接口，每个信息数据只需要按照平台格式发布即可，不需要关心“来自何方，将去哪里”。自学习自学习:Heath
17、One 内嵌数据挖掘分析模型，通过数据分析操作者的行为习惯，将最有可能的下一个行为预置，并提供行为轨迹采集使系统变成最适合具体操作人员习惯。无纸化无纸化:通过电子处方，电子病历，电子申请单，电子报告，电子办公等的应用逐步走向无纸化。无胶片化无胶片化:通过实施医学影像系统，建立放射科数字阅片中心和诊断工作站，临床中心数字阅片室，医生影像浏览工作站，全院的数字阅片中心，会诊中心，教学中心等实现全院无胶片化临床模式和管理模式。无线网络化无线网络化:通过建立无线网络，使用笔记本，平板电脑，PDA，无线病情跟踪器等无线设备实现医生护士查房，库房管理，病人病情跟踪等等，使一些业务不受空间的限制，无处不在。
18、贵院数字化平台整体规划贵院数字化平台整体规划规划概述：贵院未来完整的信息化应用架构是一个能够支持医院的医疗服务提供、基本运营和管理决策分析多方面业务需求的架构，HealthOne 整体架构如下：接口与插件接口与插件综合管理与统计分析综合管理与统计分析病案管理综合查询与分析医疗统计、院长病人咨询服务运营营销与管理运营营销与管理采购供应链管理风险预警与协作广播方案CRM 系统（巡诊回访，呼叫中心）绩效考核解决方案（工作量，成本核算，质控，满意度）护理和总务后勤工作量分析临床诊疗临床诊疗输血 管理 系统住院医生工作站门诊医生工作站护士工作站临 床 检 验 系统医学影像系统手术室麻醉系统等经济管理经济
19、管理设备，后勤总务住院病人入、出、转财务与经济核算门急诊挂号门急诊划价收费住院收费物资药品管理药品管理用药咨询与服务合理用药审核药库药房制剂室管理医保远程医疗新农合大学生医保省直机关医保健康档案接口其他第三方接口系统构成及概要进度规划系统构成及概要进度规划项目子系统建设期第一期（3 月）第二期（3 月）第三期（6 月）运行决策绩效考核系统成本核算系统CRM 系统（含呼叫中心）后勤服务驱动及评价系统风险预警与协作广播系统一卡通系统（一卡多账户）消息平台系统高端体检解决方案临床诊疗部分门诊医生工作站系统住院医生工作站系统门诊护士站住院护士站检验信息管理系统医学影像管理系统/RIS手术、麻醉管理系统
20、重症监护系统体检信息系统（标准版）药品管理应用药库管理系统门诊药房管理系统住院药房管理系统药品会计管理系统合理用药系统经济管理应用门（急）诊挂号系统门（急）诊划价、收费系统入、出、转院管理系统住院记帐管理系统物资管理系统设备管理系统财务管理与经济核算管理系统综合管理与统计分析应用病案管理系统图书馆信息管理系统统计、查询、分析系统病人咨询服务系统外部接口医疗保险社区（农村）卫生服务信息系统医疗收费项目与价格监管系统新农合系统卫生监督执法系统远程医疗咨询系统财务软件办公自动化OA系统的维护与管理系统的维护与管理医院信息化基础建设与网站建设业务系统的应用与信息共享扩展模块HealthOne 漏费系统
21、人事管理系统第二章、第二章、HealthOne 平台关键系统技术平台关键系统技术根据网络支撑工作平台一期工程的需求，本节将讨论主要的关键技术，包括：三层结构体系分布式计算处理集群技术虚拟局域网技术；第三层交换技术；信息系统安全技术；VPN 技术；三层结构体系分析三层结构体系分析1 1、传统、传统 C/SC/S 模式的局限性模式的局限性早在 1980 年第一个数据库管理系统出现时，数据库的世纪就已悄然开始。那时的观念是由应用程序控制关系型数据库，这种数据处理的模式一般称为单层结构（1Tier）。由于这种结构的数据库占用计算机资源较多，于是在 80 年代中，数据库应用开始转向 C/S 结构，也就是
22、所谓的两层结构（2Tier），见下图：这种结构在近十年内不但得到了广泛的运用，而且相当成功。然而随着信息系统结构的复杂和规模的日益扩大，两层 C/S 结构成功的背后却逐渐暴露出其构架上的缺陷。具体表现在以下几方面：（1）由于客户端和服务器端直接连接，服务器将消耗部分系统资源用于处理与客户端的连接工作。那么每当同时存在大量客户端数据请求时，服务器有限的系统资源将被用于频繁应付与客户端之间的连接，从而无法及时响应数据请求。客户端数据请求堆积的直接后果将导致系统整体运行效率的大幅降低甚至全面崩溃。（2）主从式的结构中，唯一在线的数据库服务器成为系统可靠性的极大隐患。如果数据库服务器因为某种原因停止工
23、作，那么整个系统将趋于瘫痪。（3）客户端应用程序的分发工作的烦琐程度令人难以接受。系统开发过程完毕，随之而来的程序分发除了要求为每台客户机安装客户端程序的执行文件以外，还要求安装程序运行所必须的动态链接库文件（*.dll）、程序初始化文件(*.ini)等许多其他文件。另外，还必须完成每台客户机器的 ODBC 或 BDE 的配置工作。不仅如此，每次对客户端程序的修改和升级，又意味着上述相同分发过程的又一次重复。（4）在存储过程调用中，即所有处理过程都在数据库层进行，只是将最终结果返回到客户端。这种结构的业务逻辑需采用专用语言开发，很难再移植到其他的数据库上去。客户机/服务器系统比文件服务器系统能
24、提供更高的性能，因为客户端和服务器端将应用的处理要求分开，同时又共同实现其处理要求，对客户端程序的请求实现“分布式应用处理”。服务器为多个客户端应用程序管理数据，而客户端程序发送、请求和分析从服务器接收的数据，这是一种“胖客户机(FatClient)”，“瘦服务器(ThinServer)”的网络计算模式。在一个客户机/服务器应用中，客户端应用程序是针对一个小的、特定的数据集，如一个表的行来进行操作的，而不是像文件服务器那样针对整个文件进行，对某一条记录进行封锁，而不是对整个文件进行封锁，因此保证了系统的并发性，并使网络上传输的数据量减到最少，从而改善了系统的性能。客户机/服务器模型的优点主要在
25、于系统的客户端应用程序和服务器部件分别运行在不同的计算机上，系统中每台服务器都可以适合各部件的要求，这对于硬件和软件的变化显示出极大的适应性和灵活性，而且易于对系统进行扩充和缩小。在客户机/服务器模型中，系统中的功能部件充分隔离，客户端用程序的开发集中于数据的显示和分析，而数据库服务器的开发则集中于数据的管理，不必在每一个新的应用开发中都要对一个数据库进行编码。将大的应用处理任务分布到许多通用网络连接的低成本计算机上导致了费用的极大节约。随着 C/S 结构应用范围的不断扩大和计算机网络技术的发展，这种结构带来的问题日益明显，主要表现在以下几方面：首先首先，系统的可靠性有所降低。一个客户机/服务
26、器系统是由各自独立开发、制造和管理的各种硬件和软件的混合体，其内在的可靠性不如单一的、中央管理的大型机或小型机，出现问题时，很难立即获得技术支持和帮助。其次其次，维护费用较高。尽管这种应用模式在某种程度上提高了生产效率，由于客户端需要安装庞大而复杂的应用程序，当网络用户的规模达到一定的数量之后，系统的维护量急剧增加，因而维护应用系统变得十分困难。第三第三，系统资源的浪费。随着客户端的规模越来越大，对客户机资源的要求也越来越高。尽管硬件不断更新，但新的操作系统和新的应用软件的不断出现，使得用户对硬件的更新仍然跟不上软件更新的速度。客户不得不在本地硬盘上装入大量的软件，但是使用的大都只是其中很少一
27、部分（一般低于 10）。在一个拥有众多的“胖客户机”的环境中，这无疑是一种巨大的浪费。最后最后，系统缺乏灵活性。客户机/服务器需要对每一应用独立地开发应用程序，消耗了大量的资源，但胖客户机的计算模式却仍然满足不了日益增长的应用的需要。在向广域网扩充（如 Internet）的过程中，由于信息量的迅速增大，专用的客户端已经无法满足多功能的需求。2 2、分布式计算的结构、分布式计算的结构分布式数据处理的含义分散的选择方案就是分布式数据处理(DDP)方案。分布式数据处理不仅是一种技术上的概念，也是一种结构上的概念。分布式数据处理的概念是建立在集中和分散这两种信息服务都能实现的原则基础上的。集中/分散的
28、问题归结起来就是建立综合的信息系统(集中)和对用户服务(分散)这两者结合的问题，规模的大小已不再是争论点。从理论上来说，分布式数据处理将这两个领域能最好地结合在一起。计算机系统不仅能连接到所有的业务领域，而且能致力于各业务领域的应用。由于所有的分布式系统都用一个网络联在一起，所以信息系统的综合也就很容易实现了。应该认识到分布式处理系统会具有较高的运行效率，因为其中某个计算机系统的失效并不危及整个系统的工作。事实上，在一个设计周到的分布式数据处理系统中，任何一个计算机子系统都能用来使整个系统正常工作。分布式数据处理的范围在分布式数据处理系统中，计算机组成网络，每台计算机可以与一台或多台其它计算机
29、联结起来。分布式数据处理网络一般按照地理位置或功能来考虑设计，而大多数网络是这两方面的结合。今天信息技术部门所面临的问题是如何能够创建通向未来的没有中断的跨越 LAN、WAN和 Internet 平台的分布式可伸缩性的应用结构,以满足当今复杂的、不断发展变化的业务需求，同时又能确保企业在系统、应用、信息及人员上的投资。能够适应这种变化的结构是多层分布式计算体系结构。多层体系结构能够在低费用的条件下比现行的PCLAN、两层客户/服务器或主机/终端应用结构提供更好、更及时信息的可能性。多层分布式计算应用服务技术是目前数据库应用发展的潮流，传统的客户/服务器（二层）的应用正朝着三层或 N-Tier
30、结构发展。三层结构是传统的客户/服务器结构的发展，代表了企业级应用的未来，典型的有 Web下的应用、多层 C/S 应用等。多层结构和三层结构的含义是一样的，只是细节有所不同。之所以会有双层、三层这些提法，是因为应用程序要解决三个层面的问题：（1）界面层提供给用户一个视觉上的界面，通过界面层，用户输入数据、获取数据。界面层同时也提供一定的安全性，确保用户不会看到机密的信息。（2）逻辑层（也称中间层、中介代理）是界面层和数据层的桥梁，它响应界面层的用户请求，执行任务并从数据层抓取数据，并将必要的数据传送给界面层。使用清晰的语言陈述论点。（3）数据层，数据层定义、维护数据的完整性、安全性，它响应逻辑
31、层的请求，访问数据。这一层通常由大型的数据库服务器实现，如Oracle、Sybase、DB2、MSSQLServer等。单层结构将界面层、逻辑层、数据层合并在一起。双层结构有两种，一种将界面层和逻辑层合为一层，数据层是另一层，通常称为胖客户/服务器结构；另一种将逻辑层和数据层合为一层，界面层是另一层，通常称为瘦客户/服务器结构。三层结构则将这几层分离处理。它是最简单的多层应用，它把应用程序分为：瘦客户端应用程序、应用程序服务器和远端数据库服务器。其中，客户端主要负责用户界面的处理；服务器端主要负责商业逻辑的处理，为客户端提供公共的数据服务，处理客户端与数据库间的数据流；远端数据库服务器提供关系
32、数据库的存取与维护。其优点在于：(1)具有灵活的硬件系统构成及更好的支持分布式计算环境，(2)提高程序的可维护性，(3)瘦客户的模式，(4)进行严密的安全管理，此外,系统管理简单,可支持异种数据库,有很高的可用性。基于多层分布式的企业物资信息系统平台及关键技术物资信息系统在企业内涉及的部门及各类的人员较多，各类客户用户的需求不一，其基本功能模块可划分如下：从多层结构的技术特点分析，系统设计主要从以下三个不同的层来考虑：（1）由于各项管理由不同的部门人员使用，对界面和功能的要求也不一，还有应用是建立在企业内部 Intranet 上，因此考虑用多层 C/S 和 Web(B/S)客户应用结合来构建系
33、统，Web 客户应用与企业内部 Web 资源信息系统集成，主要提供物资查询分析（库存、价格、项目用料情况及进销分析情况等）可方便于领导和一般用户使用。C/S 界面由各专项管理人员使用(数据输入、单据及报表打印和查询分析等)，并将其划分为若干独立客户应用程序便于系统安全和伸缩性维护。（2）逻辑层（中间层、应用服务器）是系统设计的关键和难点，划分好客户界面层、中间层和数据层各自所应完成的任务关系到系统的整体性能及伸缩性和维护方面。在这里我们根据业务数据的相关性，采用 OOP 的思想，划分成多个企业对象（每个企业对象是一个 COM+Datamodule）销售处理业务逻辑、入库验收业务逻辑、统计报表处
34、理业务逻辑、综合查询业务逻辑及系统管理业务逻辑等；这样，可以重复利用企业对象中的 provider 和方法，减少冗余，层次清晰。另外可以规划一些方法（不需要读写大量数据），尽量形成企业对象的方法，减少网络的数据传输。逻辑层主要封装各类应用的数据请求及处理 SQL。（3）数据层采用大型 SQL 数据库系统，在这里还必须根据业务规则编写触发器、部分业务处理存储过程等 SQL 语句。支持多层应用开发的工具很多，VC5.0、Delphi7.0、VB6.0、C+Builder4.0 及MicrosoftTransactionServer，Servlet(Java)都是不错的选择，MIDAS（Multi-
35、tierDistributedApplicationServicesSuite）是多层分布式应用服务包，是由 Inprise 公司开发的 Windows 平台的中间件产品，它能够有效地利用 COM+、TCP/IP、OLEEnterprise 和 CORBA 技术。MIDAS 提供了一套高级组件、服务和核心技术，可以简化跨平台（Windows、UNIX、Linux）、跨产品（Delphi、C+Builder、VC、VB 等开发系统可以协调工作）的多级分布式应用系统的开发。数据库服务器和应用服务器可在同一机器上，也可分布于不同的机器上，根据业务量可随时增加或减少应用服务器的位置和数量来实现负载平衡
36、，系统的伸缩性和维护方便。根据模块逻辑划分原则成不同摸块的客户端应用程序(exe)，分发客端应用程序可通过Web 下载，客户端程序无须配置庞大的数据引擎，真正达到瘦客户的目的。为什么要做分布式应用将应用分布化并不是问题的结束。分布式应用引入了一个全新的设计和扩展概念，它增加了软件产品的复杂性，但是带来了可观的回报。某些应用本身就带有分布性。因此，一种健壮的分布式计算框架所带来的好处是不言自明的。很多其它的应用也是分布式的，即它至少有两个组件运行在不同的计算机上，但是因为它不是为分布性应用而设计的，所以它们的规模和可扩展性就有很大的局限性。任何的工作流或群件应用程序，大多数的客户机/服务器应用程
37、序一些桌面办公系统本质上都控制着它们的用户的通讯和协作。将这些系统作为分布式系统并能够在正确的地方运行正确的组件会给用户带来好处，并且使人们对网络和计算机资源的运用更加充满信心。设计应用程序时考虑到分布性，能通过在客户端运行组件使应用适用于具有不同性能的不同的客户。设计应用时考虑分布性能够使系统在扩展上具有很高的灵活性。分布式应用与它们的非分布式版本比起来具有更大的可扩展性。如果整个复杂应用的逻辑结构可以用一个简单的模型来表示，那么仅仅只有一种方法来增加系统的工作效率：用更快的机器，而无需的应用本身进行调整。虽然现在的服务器和操作系统升级很快，但是买一个同样性能的机器还是比将服务器的速度升级为
38、原来的两倍所花的钱少。有了一个设计适当的分布式应用系统，一台功能不怎么强大的服务器就能够运行所有的组件。当负载增加时，可以将一些组件扩展到价格便宜的附加的机器上。分布式结构的实现分布式结构是将应用功能分成表示层、功能层和数据层。其解决方案是：对这三层进行明确分割,并在逻辑上使其独立。原来的数据层作为 DBMS 已经独立出来，所以关键是要将表示层和功能层分离成各自独立的程序，并且还要使这两层间的接口简洁明了。一般情况是只将表示层配置在客户机中，功能层也放在客户机中，与二层 C/S 结构相比，其程序的可维护性要好得多,但是其他问题并未得到解决。客户机的负荷太重，其业务处理所需的数据要从服务器传给客
39、户机,所以系统的性能容易变坏。如果将功能层和数据层分别放在不同的服务器中，则服务器和服务器之间也要进行数据传送。但是,由于在这种形态中三层是分别放在各自不同的硬件系统上的，所以灵活性很高，能够适应客户机数目的增加和处理负荷的变动。例如，在追加新业务处理时，可以相应增加装载功能层的服务器。因此,系统规模越大这种形态的优点就越显著。值得注意的是:分布式结构各层间的通信效率若不高,即使分配给各层的硬件能力很强,其作为整体来说也达不到所要求的性能。此外,设计时必须慎重考虑三层间的通信方法、通信频度及数据量。这和提高各层的独立性一样是分布式结构的关键问题。在分布式中，表示层是应用的用户接口部分,它担负着
40、用户与应用间的对话功能。它用于检查用户从键盘等输入的数据,显示应用输出的数据。为使用户能直观地进行操作，一般要使用图形用户接口(GUI)，操作简单、易学易用。在变更用户接口时，只需改写显示控制和数据检查程序，而不影响其他两层。检查的内容也只限于数据的形式和值的范围，不包括有关业务本身的处理逻辑。功能层相当于应用的本体，它是将具体的业务处理逻辑地编入程序中。表示层和功能层之间的数据交往要尽可能简洁。数据层就是 DBMS，负责管理对数据库数据的读写。DBMS 必须能迅速执行大量数据的更新和检索。现在的主流是关系数据库管理系统(RDBMS)。因此一般从功能层传送到数据层的要求大都使用 SQL 语言。
41、在分布式结构中，中间件(Middleware)是最重要的部件。所谓中间件是一个用 API 定义的软件层,是具有强大通信能力和良好可扩展性的分布式软件管理框架。它的功能是在客户机和服务器或者服务器和服务器之间传送数据，实现客户机群和服务器群之间的通信。其工作流程是:在客户机里的应用程序需要驻留网络上某个服务器的数据或服务时，搜索此数据的 C/S 应用程序需访问中间件系统。该系统将查找数据源或服务，并在发送应用程序请求后重新打包响应,将其传送回应用程序。随着网络计算模式的发展，中间件日益成为软件领域的新的热点。中间件在整个分布式系统中起数据总线的作用，各种异构系统通过中间件有机地结合成一个整体。每
42、个 C/S 环境，从最小的 LAN 环境到超级网络环境,都使用某种形式的中间件。无论客户机何时给服务器发送请求，也无论它何时应用存取数据库文件，都有某种形式的中间件传递 C/S 链路，用以消除通信协议、数据库查询语言、应用逻辑与操作系统之间潜在的不兼容问题。结论分布式结构具有更灵活的硬件系统构成，对于各个层可以选择与其处理负荷和处理特性相适应的硬件。合理地分割三层结构并使其独立，可以使系统的结构变得简单清晰，这样就提高了程序的可维护性。分布式结构中，应用的各层可以并行开发，各层也可以选择各自最适合的开发语言，有利于变更和维护应用技术规范。按层分割功能使各个程序的处理逻辑变得十分简单。一般而言，
43、分布式结构的优势主要表现在以下几个方面：利用单一的访问点，可以在任何地方访问站点的数据库；对于各种信息源，不论是文本还是图形都采用相同的界面；所有的信息，不论其基于的平台，都可以用相同的界面访问；可跨平台操作；减少整个系统的成本；维护升级十分方便；具有良好的开放性；系统的可扩充性良好；进行严密的安全管理；系统管理简单，可支持异种数据库，有很高的可用性。分布式计算实现分布式计算实现目前分布式计算比较成熟的体系有三种：DCOM/COM+、Corba、以及基于 Java 的 RMI，下面我们就 COM+和 Corba 作介绍：1 1、COM+COM+的结构的结构COM+是组件对象模型（COM）的进一
44、步扩展。COM 定义了组件和它们的客户之间互相作用的方式。它使得组件和客户端无需任何中介组件就能相互联系。客户进程直接调用组件中的方法。图 1 说明了组件对象模型的表示法：图 1 同一进程中的 COM 组件在现在的操作系统中，各进程之间是相互屏蔽的。当一个客户进程需要和另一个进程中的组件通讯时，它不能直接调用该进程，而需要遵循操作系统对进程间通讯所做的规定。COM 使得这种通讯能够以一种完全透明的方式进行：它截取从客户进程来的调用并将其传送到另一进程中的组件。图 2 表明了 COM/COM+运行库是怎样提供客户进程和组件之间的联系的。图 2 不同进程中的 COM 组件当客户进程和组件位于不同的
45、机器时，COM+仅仅只是用网络协议来代替本地进程之间的通讯。无论是客户还是组件都不会知道连接它们的线路比以前长了许多。图 3 显示了 COM+的整体结构：COM 运行库向客户和组件提供了面向对象的服务，并且使用 RPC 和安全机制产生符合 COM+线路协议标准的标准网络包。图 3COM+:不同机器上的 COM 组件2 2、组件和复用组件和复用大多数分布式应用都不是凭空产生的。现存的硬件结构、软件、组件以及工具需要集成起来，以便减少开发和扩展时间以及费用。COM+能够直接且透明地改进现存的对 COM 组件和工具的投资。对各种各样组件需求的巨大市场使得将标准化的解决方案集成到一个普通的应用系统中成
46、为可能。许多熟悉 COM 的开发者能够很轻易地将他们在 COM 方面的经验运用到基于 COM+的分布式应用中去。任何为分布式应用开发的组件都有可能在将来被复用。围绕组件模式来组织开发过程使得你能够在原有工作的基础上不断的提高新系统的功能并减少开发时间。基于 COM 和COM+的设计能使你的组件在现在和将来都能被很好的使用。3 3、位置独立性位置独立性当你开始在一个真正的网络上设计一个分布式应用时，以下几个相互冲突的设计问题会很清楚地反映出来：相互作用频繁的组件彼此间应该靠得更近些。某些组件只能在特定的机器或位置上运行。小组件增加了配置的灵活性，但它同时也增加了网络的拥塞。大组件减少了网络的拥塞
47、，但它同时也减少了配置的灵活性。当你使用 COM+时，这些设计上的限制将很容易解决，因为配置的细节并不是在源码中说明的。COM+使得组件的位置对你来说完全透明，无论它是位于客户的同一进程中或是在地球的另一端。在任何情况下，客户连接组件和调用组件的方法的方式都是一样的。COM+不仅无需改变源码，而且无需重新编译程序。一个简单的再配置动作就改变了组件之间相互连接的方式。COM+的位置独立性极大地简化了将应用组件分布化的任务，使其能够达到最合适的执行效果。例如，设想某个组件必需位于某台特定的机器上或某个特定的位置，并且此应用有许多小组件，你可以通过将这些组件配置在同一个 LAN 上，或者同一台机器上
48、，甚至同一个进程中来减少网络的负载。当应用是由比较少的大组件构成时，网络负载并不是问题，此时你可以将组件放在速度快的机器上，而不用去管这些机器到底在哪儿。图 4 显示了相同的“有效性检查组件”在两种不同情况下是如何分别配置的。一种情况是当“客户”机和“中间层”机器之间的带宽足够大时，它是怎样配置在客户机上的；另一种情况是当客户进程通过比较慢的网络连接来访问组件时，它又是怎样配置在服务器上的。图 4 位置独立性有了 COM+的位置独立性，应用系统可以将互相关联的组件放到靠得比较近的机器上，甚至可以将它们放到同一台机器上或同一个进程中。即使是由大量的小组件来完成一个具有复杂逻辑结构的功能，它们之间
49、仍然能够有效地相互作用。当组件在客户机上运行时，将用户界面和有效性检查放在客户端或离客户端比较近的机器上会更有意义；集中的数据库事务应该将服务器靠近数据库。4 4、语言无关性语言无关性在设计和实现分布式应用系统时，一个普遍的问题就是为开发一个特定的组件而选择语言以及工具的问题。语言选择是一个典型的在开发费用、可得到的技术支持以及执行性能之间的折衷。作为 COM 的扩展，COM+具有语言独立性。任何语言都可以用来创建COM 组件，并且这些组件可以使用更多的语言和工具。Java，MicrosoftVisualC+，MicrosoftVisualBasic，Delphi，PowerBuilder 和
50、 MicroFocusCOBOL 都能够和 COM+很好地相互作用。因为 COM+具有语言独立性，应用系统开发人员可以选择他们最熟悉的语言和工具来进行开发。语言独立性还使得一些原型组件开始时可以用诸如 VisualBasic 这样的高级语言来开发，而在以后用一种不同的语言，例如 VisualC+和 Java 来重新实现，而这种语言能够更好地支持诸如 COM+的自由线程多线程以及线程共用这些先进特性。5 5、基于基于 CORBACORBA 的分布式计算：的分布式计算：(a).(a).CORBA 允许灵活的客户机/服务器关系，如图：传统的客户机/服务器术语中，客户机和服务器之间的关系是固定的，客户