平台管理架构:数据交互平台
提供者:配置组
发布时间:2012/01/10 12:00
七、“部门管理系统”针对各业务科室、护理单元进行日常管理、决策分析的需要设计,

5.1.1.          平台功能架构

与一般处理信息查询和交换的平台不同,工作人员考核数据交换平台不仅要满足数据交换的需要,而且交换的数据应当有规则,部门、人员、考核指标、考核等次等信息必须有严格的代码,并进行全生命周期管理,以便对各考核、统计对象的数据进行对比分析,通过指标层级构建实施共性指标考核与个人指标考核的有机结合和钻取分析。

为此,数据交换平台必须充分考虑数据库、数据表规划,综合运用编码技术、数据交换技术、数据挖掘技术、数据钻取技术来实现。

5.1.2.    全局编码机制

全局编码是指平台内唯一识别的编码,适用于代码字典、考核指标、考核等次、应用单位、内设机构、岗位及人员的编码,以及系统版本、系统角色、系统帐户、系统模块、操作步骤、业务流程节点的编码。全局编码由编码前缀和自增长序列号组成。编码前缀由人工编码,每个应用系统版本一个编码前缀,自增长序列号由程序自动生成。

5.1.3.    数据交换机制

数据交换的包括两个方向,一个方向是自上下而发布,另一个方向是自下而上归集。自上而下发布是将一级单位数据库的相关数据发布到二级应用数据库中,一般包括各类代码、指标、模型,以及存放相互关系的数据。自下而上归集主要是各二级单位自建的部门、人员、指标以及以月度、季度、半年、年度汇总后的考核汇总数据。各单位个性考核管理模块、没有按考核分析周期汇总的原始数据仍保留在原数据库中。

常见的数据交换方式有多种,包括信息发布/订阅、同步作业、中转服务和企业服务总线,由于各二级单位现有的考核管理软件使用平台、数据格式可能不同,可优先考虑使用oracle的企业服务总线(ESB)。如果是同类数据库,也可采用发布/订阅方式等方式更加灵活便捷。

企业服务总线是通过一个消息和路由系统(总线)和解析设施(适配器)提供不同的系统之间的沟通方式的一种架构。通过消息路由有效地降低了“一级”应用和”二级”应用系统之间交互的耦合性,使得两级应用之间在技术上是完全相互独立的、互不影响。多个系统均发送消息至总线,并由总线将消息转发,企业服务总线能够把数据解析为不同的格式。大多数企业服务总线应用都有许多可以使用的标准的适配器和一个应用程序编程接口。这个应用程序编程接口允许开发人员使用自己的适配器与其它系统进行沟通。企业服务总线还能提供服务编排(把多项服务组合为一项服务)、流程编排(流程流)以及安全和管理(身份识别、监视、审计和登录)。

发布/订阅(Publish/subscribe 或pub/sub)是一种消息范式,消息的发送者(发布者)不是计划发送其消息给特定的接收者(订阅者)。而是发布的消息分为不同的类别,而不需要知道什么样的订阅者订阅。订阅者对一个或多个类别表达兴趣,于是只接收感兴趣的消息,而不需要知道什么样的发布者发布的消息。这种发布者和订阅者的解耦可以允许更好的可扩放性和更为动态的网络拓扑.

发布/订阅是消息队列范式的兄弟,通常是更大的面向消息的中间件系统的一部分。大多数消息系统在应用程序接口(API)中同时支持消息队列模型和发布/订阅模型,例如Java消息服务(JMS)。

发布者与订阅者松散地耦合,并且不需要知道对方的存在。由于主题是被关注的,发布者和订阅者可以对系统拓扑毫无所知。 发送者和订阅者都可以继续正常操作,不管对方。对于相对小的安装,发布/订阅通过并行操作,消息缓存,基于树的或基于网络的发送等,与传统的客户端/服务器相比,提供了更好的可缩放性的机会。

5.1.4.    数据钻取机制

除可看到各类统计报表外,一级应用、二级应用均需要反查各类数据的来源,直到明细台帐。为减少明细台帐、个性考核数据的同步上传工作量,减少数据冗余,可通过以下方式来实现明细台帐、个性台帐的反查。①针对各应用单位设置是否可跨数据库查询权限;②为每个应用系统版本配置数据库名称、地址等属性;③每条数据记录中均记录数据来源的系统版本标识。

 

 

 

图片                                        图片