動態數據庫的ＯＲＭ實現

摘要：針對現有的ORM組件不能實現運行時動態改變數據庫結構的不足，文章提出了一種動態數據庫的ORM解決方案，該方案從分析設計數據庫的基本原則入手，給出了一種將索引表和動態數據表相結合的ORM模型，通過索引表間接實現了動態數據庫的ORM，彌補了現有ORM組件的不足。同時分析比較了動態數據庫ORM和傳統JDBC直連的效率。

關鍵詞：動態數據庫；ORM；索引袁

0 引言

軟件結構體系已由單層結構向多層結構發展，在Web應用軟件中，這種體系結構表現為典型的三層結構：表述層、業務邏輯層、數據層。這種層次結構給應用軟件帶來了伸縮性、可維護性、可擴展性、可重用性和可管理性等諸多優點。

該層次結構中業務邏輯層不僅要處理業務邏輯，而且還負責訪問數據庫，操作和處理業務邏輯所需的數據。JDBC是所有數據庫訪問方式中效率最高的，但是由于JDBC的編碼方式屬于SQL語句嵌入式的硬編碼結構，所以在代碼里必然會帶有大量的SQL語句，從而導致開發效率的降低和維護成本的升高。所以為了把數據訪問和業務邏輯區分開來，部分應用在業務邏輯層和數據層之間增加了數據訪問中間件——持久層，由這一層來負責具體的數據訪問。持久層封裝了訪問細節并向業務邏輯層提供數據訪問接口，使業務邏輯不必再糾纏于數據訪問語句中，從而使業務代碼更加簡潔專一。

1 ORM模式簡介

ORM(Object-Relation-Mapping)模式指在單個組件中實現所有實體的持久化，封裝數據細節。目前最流行和最普及的數據層解決方案是關系數據庫，而關系數據庫是基于數學集合論原理的，這和被普遍接受的面向對象的業務邏輯實現存在一定的匹配問題。為了解決這種匹配問題，目前已經提出了多種解決方案，比如CMP、JDO、ORM等等。其中ORM作為目前比較流行的持久化解決方案，與CMP、JDO相比具有結構簡單，移植性高，對環境依賴度低的優點，與POJO(Plan Old Java Object)相結合使用的方式已經成為一種越來越受歡迎且用于取代CMP和JDO的持久化方案。

2 動態數據庫的ORM實現

與運行時物理表結構不改變的靜態數據庫相對，動態數據庫是指由于數據結構不能在設計期間完全預知，物理表結構在運行時會隨著業務邏輯的需求動態增加、刪除或修改數據庫。目前的ORM組件是通過對象一表和屬性一列的映射配置文件實現對象關系映射的，所以可以與靜態數據庫結合使用并能很好地工作。但是這種ORM組件對于動態數據庫而言卻是不適用的，映射配置文件不可能在應用運行時動態修改，同樣映射的對象文件也不可能在應用運行時動態修改。雖然業務邏輯可以避開ORM直接訪問數據庫，但是這樣做是與增加持久層簡化業務邏輯的初衷相背的。

所以，需要一種能與動態數據庫結合使用的ORM實現。本文提出了一種通過改進數據庫的表設計，增加索引表而實現動態數據庫結構的抽象規范，繼而在此基礎之上實現動態數據庫的ORM方案。

2．1 數據庫設計準則

由于動態數據庫數據表的動態特性，所以要實現ORM必須對其進行邏輯上的抽象，歸納出一個統一的邏輯結構，使ORM組件可以對數據表進行統一的管理和訪問。本文按照如下幾點對數據庫進行改良并抽象出統一的數據表邏輯結構。

2．1．1 統一生成準則

對于不同應用來說，每個生成的動態數據表在結構上具有一定的相似性。所以應該在設計階段根據可能的數據表的生成類型確定動態數據表的生成規則，讓所有的數據表都按照規則生成，這樣生成的數據表在結構上具有一致性，并能在邏輯上實現數據表的統一管理。

2．1．2 增加索引表

索引表是存放所有動態生成的數據表的參數的表，包括數據表的物理表名、邏輯表名、物理列名、邏輯列名等。索引表工作于持久層和數據層之間，邏輯上等同于ORM組件和數據表之間的代理，ORM組件通過索引表代理間接訪問數據表：

ORM則建立在表結構固定的索引表上，這樣，在邏輯上解決了動態數據表的ORM問題。本文引入了兩張索引表：表索引表和列索引表，其結構如表1和表2所示，其中表索引表的map_name列的數值是惟一的，列索引表的map_name列在table_id值相等的情況下取值也是惟一的。在新建一張數據表的時候，向表索引表中寫入一條記錄，其中的字段值為該數據表的相關信息，比如邏輯表名，物理表名等等。同時根據該數據