信息系統交付使用之初，數據庫表結構的設計往往邏輯結構清晰，管理使用方便，但是當信息系統項目運行一段時間，隨著業務的不斷變化和增加，處理流程不斷的變革，信息系統需要從前台界面到後台數據庫的完善和修改，勢必要對數據庫表結構必須要進行擴展。我們通常的數據庫擴展往往采用增加備用字段、擴展字段的內涵、增加主從表和管理表的方式，這種數據庫表結構的擴展往往會帶來營運的中斷和操作的風險，本文通過分析常見的數據庫庫表結構的擴展方法中的不足，提出了幾種基於 pureXML 方式的數據庫表結構的擴展模式，可以成功的結束數據庫擴展的技術難題。
概述
信息系統的建設往往遵循業務調研、需求分析、再進入到數據庫和軟件的概要設計、詳細設計、代碼編寫等等階段，在這個過程中數據庫設計者往往根據已有的業務調研、需求分析的成果進行數據庫表結構的設計，這時的數據庫的設計者是通盤考慮，全局謀劃所設計的數據庫結構，整個庫表結構邏輯清晰，管理方便並且符合 3NF 的要求。信息系統項目運行一段時間，隨著業務的不斷變化和增加，處理流程不斷的變革，這種業務需求的驅動下，我們的軟件體系也需要不斷的修改和完善，這種修改和完善不僅是界面的調整和模塊的增加，而且必須對數據庫表結構進行必要的調整和修改。
這種項目維護期間的數據庫調整和擴展，必須對數據庫設計文檔進行修改，對數據字典進行調整，理想的情況是文檔齊備、資料完整，但實際工作中，由於設計和開發人員的責任心和對文檔的輕視，每次對數據庫表結構的調整都會造成數據庫庫表結構混亂，為今後的工作帶來系統管理、維護和軟件的再次修改和調整帶來隱患;其次，數據庫的擴展和調整中，對數據庫設計者要求很高，很容易導致數據庫設計中范式設計的隱患，進而造成數據庫性能的急劇下降;最值得注意的是，由於數據庫存儲有大量的業務數據庫，每次對數據庫字段的修改和調整必須停機操作，從而帶來運營的中斷和操作的風險。特別是對於上線運行的核心業務系統，和若干 7×24 小時的業務系統，每次的數據庫停機操作對營運的影響非常的巨大，而且還可能引來不良的社會影響。
為了對數據庫進行有效的擴展，實際工作中往往采用預留備用字段、字段內涵擴展、增加從表擴展和增加關聯表的方式進行擴展，這種擴展往往存在若干的問題：
設計之初預留備用字段帶來的不足
為了減少對今後對數據庫表中的字段調整，某些設計者在設計之初，根據經驗對若干可能擴展的表中預留部分備用字段。預留備用字段的方式在某些程度上可以增加擴展的靈活性，但是確存在如下隱患：
預留字段的數量無法預測 , 預留 N 個還是預留 N+1，由於無法預知需要預留的數量造成擴展的不確定性;
預留字段的類型無法預測，預留字符型還是數值，無法去預測和評估;
常見在預留的擴展字段中，這些預留的擴展字段往往會破壞數據庫最基本的范式要求，數據庫的范式的最基本要求就是原子性和唯一性，而擴展的字段本身的定義是不明確的，這是不未確定的，也就是非原子的和非唯一的。
表結構的字段數據量不擴展，擴展若干字段的內涵
數據庫的調整會帶來運營的風險，部分數據庫設計者為了應付數據庫存儲的需要，不對數據庫表結構的字段的數量進行增加，而是非常“聰明”的將某個字段的內涵進行擴展，使得某些字段中同時存入 2+ 以上含義，由程序分析存入該字段的值的屬性和內容。例如：某字段原定義為 VARCHAR(4)，如果存儲字母開頭的值，如 A001 表示意思 XX;存儲數值開頭的值，如 1000 表示意思 YY;還有一種方式就是采用間隔符，對字段進行擴展，例如 A001+1000 等形式。我們的數據庫設計中，數據庫表中的每一個字段都是單一屬性，是不可再分的、原子性的，這個是數據庫設計的第一范式理論，任何的數據庫設計都應該遵守第一范式。這種設計不僅違反的數據庫設計的第一范式理論，而且造成讀取數據時需要程序進行“解碼”後才能進行查詢、統計等等，使得數據庫的整體性能大大降低。
增加從表，但又不能確定從表的數量
當對庫表進行擴展時，往往遇到存在 1:N 的情況時，這時必須增加從表來應對數據庫的擴展，但是由於每次增加數據庫從表時，無法預測需要增加多少個從表，每次增加從表都會造成數據庫的修改和調整。
增加關聯，但關聯表的字段無法預測
由於業務邏輯的改變，如果發現原表 T1,T2 存在 N:M 的關系時，必須增加關聯表，但是關聯表的字段數量又無法預測 , 每次對關聯表的調整又會造成對數據庫的影響。
通過對數據庫表結構中經常采用表和字段擴展的方式進行分析，我們都會發現對數據庫的修改，往往會造成諸多的不便，而且值得注意的是每次修改數據庫往往是業務需要非常緊迫，考慮到之前確保之前程序的穩定性和可靠性，此時又不能對原有的數據庫進行調整和重組，DBA 往往只能進行部分數據庫表結構的字段，往往最終導致數據庫表結構混亂，以及管理維護的失控。
數據庫表結構擴展原則
要做好數據庫的調整工作，為了減少對原系統的影響和歷史數據的存儲，我們在調整中往往按照以下三條原則來進行數據庫的調整：
對修改的關閉，對擴展的開放。原有的表結構中各字段都含有數據信息，不能對原有字段的刪除修改。如果刪除這些字段往往造成數據丟失，特別是對於某些關聯表的數據庫操作更是風險極大;
對表結構的修改最關鍵是減少對運營的影響。數據庫的調整，每次都需要備份數據，中斷業務系統，中斷業務系統會造成生產經營的巨大損失和不良的社會影響，所以對數據庫的調整必須采取措施減少對生產系統和運營系統的影響;
表結構很少重組結構，而只是增減字段。表結構的擴展是基於已有系統的運行，考慮到已有系統的穩定運行，我們很少去重構重組原表結構，只是增加和擴展表中的字段和數據庫表。
DB2 v9 的 pureXML 的技術特點
考慮到參加的表和字段擴展中遇到的問題和數據庫表結構調整的幾個基本原則，我們認為 pureXML 能夠幫助我們較好的解決這個問題。DB2 v9 中的 pureXML 技術第一次真正意義上提供了一種與 XML 層次型結構相匹配的層次型存儲方式和相對應的操作訪問方式.在 pureXML 中，XML 作為一種新的數據類型。幾乎每個 DB2 組件、工具和實用程序都已得到增強，以識別和處理這種新數據類型。新的存儲模式以解析後的注釋樹形式(類似於 XML 文檔對象模型 (DOM))保留 XML，它與關系數據存儲分開。
圖 1. DB2 的新 XML 關系存儲模型
在兩種數據存儲(關系和 XML)的頂部的數據庫引擎可以處理 XQuery、Xpath、SQL 和 SQL/XML。該引擎采用帶有 SQL 和 XQuery 解析程序的雙語查詢編譯器。因此開發人員可以根據具體情況更適用的原則使用 SQL 或 XQuery 任何一種語言(或同時使用這兩種語言)，支持事務級的 XML 操作。
基於 PureXML 技術的數據庫表格的擴展模式
為了應對數據庫的表結構的擴展，我們可以利用 XML 具有自我描述和層次行等特性，可以非常方便的存儲各種類型的數據庫。針對不同的數據庫表結構的擴展，提出字段模式的擴展、從表模式的擴展和主從陌生的擴展，可以方便的應對各種類型的庫表結構的調整。
字段模式的擴展
圖 2. 字段擴展模式介紹圖
對於需要對表結構進行增加字段的擴展需要，只需要對 XML 的列進行擴展就可完成數據庫的擴展。
方法：左表需要增加多個字段，右表只需要對 XML 字段進行擴展;
優點：適應於對數據庫字段的擴展，由於基於 XML 的字段，字段數量擴展沒有限制，字段類型沒有限制，且修改時無需停機處理;
適用范圍：適合於只對主鍵有唯一依賴關系的屬性
主從模式的擴展
圖 3. 主從擴展模式介紹圖
對需要對增加從表來對主表進行擴展的模式，也只需對列末的 XML 類型進行擴展，擴展的從表全部由 XML 來存儲。
方法：左邊需要增加多個外鍵和從表;右邊只需要對 XML 字段按照從表結構進行擴展
優點：適應於對從表的擴展，由於基於 XML 的字段，從數量擴展沒有限制，而且從表中字段類型沒有限制。
適用范圍：適合於需要增加從表的擴展。
關聯模式的擴展
圖 4. 關聯擴展模式介紹圖
方法：由於業務規則的增加，對於 N:M 的關系必須增加關聯表，在關聯表中增加 XML 字段
優點：關聯表中增加 XML 字段，可以應對字段增加和從表的增加(見字段模式和主從模式)，進而構成了復雜的數據庫擴展方法。
適應范圍：增加數據庫設計的彈性和可擴展性
從介紹了三種基於 pureXML 技術的數據庫表結構的擴展模式，通過該模式的使用可以讓數據庫系統的修改和擴展非常的方便和易用，而且可以進一步將各種模式進行相互組合和疊加，以應對成更加復雜的庫表結構的擴展。
結束語
以上分析了數據庫擴展中常見的幾種方法，提出基於 pureXML 技術的三種對數據庫模式的擴展技術，通過 XML 字段的方式使得對數據庫擴展實現按需分配，彈性擴展，無限擴展的可能;其次，XML 基於自描述性，而通過 XML 字段的方式使得數據庫結構清晰，容易管理和維護，而且字段增加時系統無需停機處理，減少對系統運營的影響和操作的風險;通過 XML 擴展模式確保了數據庫表對修改的關閉，對擴展的開發，軟件開發人員只需要按照 XML 擴展模式的思路，對數據庫的 CRUD 操作數據庫操作進行封裝，以便於大大提高系統的軟件維護的效率，減少維護的成本。