本文通過分析現今主流的數據庫存儲模型，對基于MML標準的電子病歷構建存儲模型。針對對象一關系型和關系型2種存儲模型比較分析，給出了基于MML標準的電子病歷系統的數據庫存儲模型設計方案。
1 引 言
MML(Medical Markup Language)作為一套不同醫療信息系統之間的數據交換規格于1995年開發，是一套比較完整的使用XML結構電子病歷交換標準，目前最新版本是3．0。采用MML標準可以將基于異構電子病歷的醫療信息系統很好的結合起來，實現數據的共享。
目前大多數采用電子病歷醫療信息系統的醫院都使用關系型數據庫，主要考慮到關系型數據庫有強大易用的查詢分析工具和易與醫院遺留系統整合的能力。但是由于基于MML的電子病歷映射到關系型數據庫時，原有的層次結構信息將丟失，此外關系型數據庫對基于MML的電子病歷內的嵌套和遞歸結構支持也較弱。
2數據庫類型選擇
針對醫療信息系統的研究發現，兩類數據庫系統操作是必須的：操作類型(例如，統計、分析)；研究類型(例如，查詢)。在分析應當選取何種類型的數據庫存儲模型作為研究對象時，首要前提是要支持這兩類操作。現有3種數據庫系統可以作為MML電子病歷的存儲模型，分別是XML原生數據庫、關系型數據庫和對象一關系型數據庫。
XML原生數據庫是專門為存儲XML數據設計的，支持DOM模型和斷言查詢。但現在缺乏商業級的產品，同時開發人員需要花費相當的時間來熟悉和適應，在未來可能作為XML存儲的重要應用但這里不作為分析研究的重點。
對于關系型數據庫系統，當MML電子病歷映射到數據庫時，文檔內在的層次關系將丟失。這可能不影響操作類型的操作，可是對審計跟蹤將有一定影響。作為現在主流的數據庫系統，關系型數據庫系統有豐富強大的查詢和分析工具，各種優化技術又使得性能高效，因此將其作為研究MML電子病歷系統存儲模型的對象。
相比之下對象一關系數據庫作為較新的數據庫系統，其在關系型數據庫和面向對象數據庫之間搭起了一座橋梁。對象一關系數據庫基于關系模型，存儲結構和數據訪問都是基于標準的面向對象版本的SQL。因為引進了OO概念，對象一關系數據庫也附加了、繼承和多態等OO特性。對象能存儲在表內并包含方法。由于擴展了面向對象的特性，支持復雜數據類型，對象一關系數據庫比傳統關系型數據庫更適合作為MML電子病歷的存儲模型。
MML電子病歷包括各種檢驗表、圖形等對象需要專門的方法來查詢，在這種情形下對象一關系型數據庫就尤顯優勢。
3存儲模型設計和實現
采用傳統的ANSI三層數據庫模型(外層、邏輯或內層、物理層)來設計MML電子病歷存儲模型。概念設計階段的目標是構造出獨立于具體數據庫管理系統的數據庫概念模式。在邏輯層設計的過程中，選用特定的數據模型將概念模式映射到邏輯模式。最后一步按照物理存儲結構開發數據庫的規范，底層算法用來設計執行數據榆索和數據管理。
3．1 基于MML電子病歷的ER模型
在概念設計階段采用廣為使用的實體一關系(ER)模型。根據MML電子病歷處理過程，設計了包括3個實體和8種關系的模型，3個實體分別為：Person，MML-emr和Organization。
針對設計出的ER模型(見圖1)，町以選用對象導向的方法或傳統的純關系數據模型方法。下而將詳細討論對比兩種方法，找出各自的優缺點。
3．2對象一關系型存儲模型設計
在將ER模型映射到對象一關系模型時，最直接的辦法是采用對象描述實體。表1為Person對象及其對應屬性。
需要注意的是有4個屬性是對象數組用以表示PER-AON實體的多值屬性。MML_emr和Organization對象和Person對象類似。ER圖中的關系也可映射為對象，表2為3個實體之間的關系。
ER模型中的多值屬性可以用VARRAYS或者嵌套表表示，嵌套表更適合對一組需求的查詢，如果是要通過單個操作完成的組需求的話VARRAYS效率更好些。
在對象一關系模型中，N∶M關系可以通過在嵌套表上添加REF(類似參考類型指針)實現。以MML電子病歷提供者provider和MML-emr之間的關系為例。每一個oo_MML_emr包含有oo_provider的嵌套表，每個oo_provider屬性指向一個person對象。在對象-關系模型中只需兩張表MML_emr和person就可以表示出這個N∶M的關系。而在關系型模型中需要MML_emr，per-son和MML_emr_person三張表。
l：M關系的實現在2種模型相似，在對象一關系模型中使用REF類型，而在關系模型中使用外鍵。
3．3 關系型存儲模型設計
采用標準算法將ER模型映射到關系型模型。首先為ER模型中的每個實體創建1張表；再對ER模型中的每個多值屬性創建表；1∶M類型的關系通過添加外鍵來實現；N∶M類型的關系使用單獨的表。由于基于MML的電子病歷包括大量的多值屬性和N∶M類型關系，所以相對于對象一關系模型會產生大量的表。
鑒于關系型數據庫在信息系統中的設計問題已經有了詳盡深入的研究，這里就不詳細展開了。
4 比較
在前述段落提到的分析結果我們認為基于MML電子病歷的數據庫存儲模型的最佳選擇是對象一關系類型。針對對象一關系型數據庫有2種設計方法，一種是把包括數據成員和方法的對象存儲到表中；另一種是在只使用傳統關系型數據庫設計方法不能滿足需求時才采用面向對象的方法來操作對象。
就分別采用這2種方法設計和實現對象一關系模型過程中存在的問題和對執行結果的分析來討論二者的優劣。
4．1 實現問題
對象關系模型創建的表的數量較關系型模型少許多，且使用基于對象方法的簡單表達式使得查詢也趨于簡單化。但是對象方法要認真設計實現，否則某些查詢因為沒有設計合適的對象方法將無法完成。
設計實現對象一關系數據庫時，每個對象都要考慮采用何種類型，是否使用用戶自定義類型(UDT)。對每個對象可能有的查詢／操作認真分析，據此設計用戶自定義函數(UDF)。例如，通過名字Bob Smith查詢病人電話列表，下面列出對象一關系的SQL語句：SELECT o．phoneFROM oo．person o WHERE o．hasName(＇Bob＇，＇Smith＇)；這里必須為oo．person對象設計該hasName自定義方法，不然將無法進行此查詢。在對象一關系模型中需要設計大量自定義方法。在傳統關系型模型，該查詢可以通過下列語句實現：SELECT o．phone FROM person p，person-name n person-phom o WHERE n．name＝＇Bob Smith＇AND n．id＝p．id AND o．id＝p．id；需要連接3個表。
對象一關系模型中表的查詢／操作比傳統的關系型模型簡單直觀，但是需要編程實現大量的自定義函數。此外由于N∶M關系是通過在對象中添加嵌套表或數組實現的，設計人員必須認真考慮應該將其添加到該關系相關的哪個對象上。
4．2 時延分析
對兩個均包含100份MML電子病歷的對象一關系數據庫和傳統關系型數據庫進行比較。選取下面4組典型的數據庫操作分別在2個數據庫上運行，以比較性能：
(1)使用簡單搜索規則對單個病人進行數據檢索，例如通過名字檢索病人數據；
(2)多病人數據檢索查詢；
(3)檢索MML emr tab表數據(不是病人數據)；
(4)增、刪和更新數據。
使用Oracle9i實現2個數據庫，共進行13組操作，每組運行5次取平均時間。實驗結果表3所示，對象一關系模型包含2列，2個版本的差別在于版本二只在必須的情況下使用用戶自定義函數(UDF)。Q1到Q3屬于分組一，在兩種數據庫中都沒有使用UDF。Q4到Q6屬于分組二，分別對oo_person_tab，oo_organization和oo_MML表進行多病人數據檢索查詢。以Q4為例，該查詢需要掃描整個oo_person_tab表以便執行hasName()。Q4的時間復雜度為O(n)。使用類似hasName()，hasID()等UDF的查詢依賴于表的行數。關系型數據庫采用優化技術，時間復雜度為O(log(n))，對對象一關系數據庫的優化由于UDF非常復雜，難于優化。Q7，Q8和Q9屬于分組三，在對象一關系數據庫的2個實現中也同樣發現，版本二由于只在必須時使用UDF，執行時延得以大幅縮短。分組四同樣是使用UDF的緣故，執行效率傳統關系型數據明顯高于對象一關系型。
5 結 語
設計層次上，對象一關系模型因為表的數量比較少而顯得比較簡潔，但設計的過程不如關系型模型直觀，設計人員需要認真考慮對象間的關系應當如何表示。實現層次上，對象一關系模型需要提供支持多值屬性和關系的搜索方法的具體實現，可以使用嵌套表或數組表示；關系型模型則采用獨立表，不需要設計人員編寫代碼。
查詢和執行方面，在對象一關系模型上的查詢表達式簡潔直觀，但需要事先編程實現對象方法。傳統關系型模型的數據庫操作效率要高過對象一關系模型。綜上，因為基于MML的電子病歷系統的原型非常復雜，使用對象一關系型存儲模型可以簡化數據庫的設計和實現，縮短開發周期；同時可以結合傳統關系型的優點，只在必須用用戶自定義方法的時候才使用UDF，一方面可以提高執行效率；另一方面可以盡量避免因為沒有提供必要的UDF而不能執行電子病歷靈活多樣的數據庫查詢操作