平臺管理架構(gòu):數(shù)據(jù)交互平臺
提供者:配置組
發(fā)布時間:2012/01/10 12:00
七、“部門管理系統(tǒng)”針對各業(yè)務(wù)科室、護理單元進行日常管理、決策分析的需要設(shè)計,

5.1.1.          平臺功能架構(gòu)

與一般處理信息查詢和交換的平臺不同,工作人員考核數(shù)據(jù)交換平臺不僅要滿足數(shù)據(jù)交換的需要,而且交換的數(shù)據(jù)應(yīng)當(dāng)有規(guī)則,部門、人員、考核指標、考核等次等信息必須有嚴格的代碼,并進行全生命周期管理,以便對各考核、統(tǒng)計對象的數(shù)據(jù)進行對比分析,通過指標層級構(gòu)建實施共性指標考核與個人指標考核的有機結(jié)合和鉆取分析。

為此,數(shù)據(jù)交換平臺必須充分考慮數(shù)據(jù)庫、數(shù)據(jù)表規(guī)劃,綜合運用編碼技術(shù)、數(shù)據(jù)交換技術(shù)、數(shù)據(jù)挖掘技術(shù)、數(shù)據(jù)鉆取技術(shù)來實現(xiàn)。

5.1.2.    全局編碼機制

全局編碼是指平臺內(nèi)唯一識別的編碼,適用于代碼字典、考核指標、考核等次、應(yīng)用單位、內(nèi)設(shè)機構(gòu)、崗位及人員的編碼,以及系統(tǒng)版本、系統(tǒng)角色、系統(tǒng)帳戶、系統(tǒng)模塊、操作步驟、業(yè)務(wù)流程節(jié)點的編碼。全局編碼由編碼前綴和自增長序列號組成。編碼前綴由人工編碼,每個應(yīng)用系統(tǒng)版本一個編碼前綴,自增長序列號由程序自動生成。

5.1.3.    數(shù)據(jù)交換機制

數(shù)據(jù)交換的包括兩個方向,一個方向是自上下而發(fā)布,另一個方向是自下而上歸集。自上而下發(fā)布是將一級單位數(shù)據(jù)庫的相關(guān)數(shù)據(jù)發(fā)布到二級應(yīng)用數(shù)據(jù)庫中,一般包括各類代碼、指標、模型,以及存放相互關(guān)系的數(shù)據(jù)。自下而上歸集主要是各二級單位自建的部門、人員、指標以及以月度、季度、半年、年度匯總后的考核匯總數(shù)據(jù)。各單位個性考核管理模塊、沒有按考核分析周期匯總的原始數(shù)據(jù)仍保留在原數(shù)據(jù)庫中。

常見的數(shù)據(jù)交換方式有多種,包括信息發(fā)布/訂閱、同步作業(yè)、中轉(zhuǎn)服務(wù)和企業(yè)服務(wù)總線,由于各二級單位現(xiàn)有的考核管理軟件使用平臺、數(shù)據(jù)格式可能不同,可優(yōu)先考慮使用oracle的企業(yè)服務(wù)總線(ESB)。如果是同類數(shù)據(jù)庫,也可采用發(fā)布/訂閱方式等方式更加靈活便捷。

企業(yè)服務(wù)總線是通過一個消息和路由系統(tǒng)(總線)和解析設(shè)施(適配器)提供不同的系統(tǒng)之間的溝通方式的一種架構(gòu)。通過消息路由有效地降低了“一級”應(yīng)用和”二級”應(yīng)用系統(tǒng)之間交互的耦合性,使得兩級應(yīng)用之間在技術(shù)上是完全相互獨立的、互不影響。多個系統(tǒng)均發(fā)送消息至總線,并由總線將消息轉(zhuǎn)發(fā),企業(yè)服務(wù)總線能夠把數(shù)據(jù)解析為不同的格式。大多數(shù)企業(yè)服務(wù)總線應(yīng)用都有許多可以使用的標準的適配器和一個應(yīng)用程序編程接口。這個應(yīng)用程序編程接口允許開發(fā)人員使用自己的適配器與其它系統(tǒng)進行溝通。企業(yè)服務(wù)總線還能提供服務(wù)編排(把多項服務(wù)組合為一項服務(wù))、流程編排(流程流)以及安全和管理(身份識別、監(jiān)視、審計和登錄)。

發(fā)布/訂閱(Publish/subscribe 或pub/sub)是一種消息范式,消息的發(fā)送者(發(fā)布者)不是計劃發(fā)送其消息給特定的接收者(訂閱者)。而是發(fā)布的消息分為不同的類別,而不需要知道什么樣的訂閱者訂閱。訂閱者對一個或多個類別表達興趣,于是只接收感興趣的消息,而不需要知道什么樣的發(fā)布者發(fā)布的消息。這種發(fā)布者和訂閱者的解耦可以允許更好的可擴放性和更為動態(tài)的網(wǎng)絡(luò)拓撲.

發(fā)布/訂閱是消息隊列范式的兄弟,通常是更大的面向消息的中間件系統(tǒng)的一部分。大多數(shù)消息系統(tǒng)在應(yīng)用程序接口(API)中同時支持消息隊列模型和發(fā)布/訂閱模型,例如Java消息服務(wù)(JMS)。

發(fā)布者與訂閱者松散地耦合,并且不需要知道對方的存在。由于主題是被關(guān)注的,發(fā)布者和訂閱者可以對系統(tǒng)拓撲毫無所知。 發(fā)送者和訂閱者都可以繼續(xù)正常操作,不管對方。對于相對小的安裝,發(fā)布/訂閱通過并行操作,消息緩存,基于樹的或基于網(wǎng)絡(luò)的發(fā)送等,與傳統(tǒng)的客戶端/服務(wù)器相比,提供了更好的可縮放性的機會。

5.1.4.    數(shù)據(jù)鉆取機制

除可看到各類統(tǒng)計報表外,一級應(yīng)用、二級應(yīng)用均需要反查各類數(shù)據(jù)的來源,直到明細臺帳。為減少明細臺帳、個性考核數(shù)據(jù)的同步上傳工作量,減少數(shù)據(jù)冗余,可通過以下方式來實現(xiàn)明細臺帳、個性臺帳的反查。①針對各應(yīng)用單位設(shè)置是否可跨數(shù)據(jù)庫查詢權(quán)限;②為每個應(yīng)用系統(tǒng)版本配置數(shù)據(jù)庫名稱、地址等屬性;③每條數(shù)據(jù)記錄中均記錄數(shù)據(jù)來源的系統(tǒng)版本標識。

 

 

 

圖片??????????????????????????????????????? 圖片