龍 宇
（南京郵電大學 通信與信息工程學院，江蘇 南京 210003）
摘 要： 評估關系數(shù)據(jù)庫的質量的過程對數(shù)據(jù)庫產業(yè)至關重要。評估關系數(shù)據(jù)庫的質量包含兩種獨立的審計方式：一種是對圖表中描述的數(shù)據(jù)庫結構的審計，另一種是在指定點對數(shù)據(jù)庫內容進行審計。數(shù)據(jù)庫圖表審計主要檢查設計缺陷，是否有違背數(shù)據(jù)庫準則以及偏離原始數(shù)據(jù)模型的情況，同時測量數(shù)據(jù)庫的大小、復雜性和結構質量。數(shù)據(jù)庫內容審計則比較選擇的數(shù)據(jù)的狀態(tài)屬性，以確定是否有不正確的數(shù)據(jù)，并檢查是否有丟失和多余的記錄。上述兩種方式的目的都是為了啟動數(shù)據(jù)清理過程，以確?；蚧謴蛿?shù)據(jù)的質量。
關鍵詞： 數(shù)據(jù)質量；數(shù)據(jù)模型；架構分析；數(shù)據(jù)有效性；數(shù)據(jù)一致性
0 引言
大多數(shù)IT用戶的現(xiàn)有數(shù)據(jù)庫都是長期演進的產品，許多年前就被設計出來了。當關系數(shù)據(jù)庫剛開始進入市場時，它們中很多都是從早期的分層或網(wǎng)絡數(shù)據(jù)庫中通過數(shù)據(jù)遷移生成的。因此，從一開始，關系數(shù)據(jù)庫的設計原則就是能適應來自非關系型系統(tǒng)的不兼容的數(shù)據(jù)，后來，隨著數(shù)據(jù)結構的侵蝕，造成了不受控制的演變結果。用戶需求隨著時間的推移發(fā)生變化，數(shù)據(jù)模型必須改變以保持同步。如果數(shù)據(jù)模型變得過時，由于程序錯誤以及使用方式的不一致，使得無效數(shù)據(jù)值能進入數(shù)據(jù)庫，那么類似的錯誤數(shù)據(jù)將會在數(shù)據(jù)庫中成倍增加，這些問題會使得數(shù)據(jù)質量大幅降低，并最終導致數(shù)據(jù)崩潰。
1 數(shù)據(jù)質量影響因素
數(shù)據(jù)質量下降的主要原因有：（1）數(shù)據(jù)遷移時的妥協(xié)；（2）未能預見到未來的需求；（3）缺乏數(shù)據(jù)獨立性；（4）規(guī)范化不當；（5）存儲不當；（6）不一致和不正確的數(shù)據(jù)更新；（7）數(shù)據(jù)測試的不準確性。
1.1 數(shù)據(jù)遷移時的妥協(xié)
許多用戶的數(shù)據(jù)庫從一開始質量就很低，因為用戶的數(shù)據(jù)源自傳統(tǒng)的數(shù)據(jù)庫系統(tǒng)，如IMS、IDMS或ADABAS。為了使數(shù)據(jù)遷移變得更容易，因權宜之計而犧牲了關系數(shù)據(jù)庫的部分原則，如數(shù)據(jù)庫數(shù)組中的數(shù)據(jù)項放入一行或者以blob形式來隱藏改變的數(shù)據(jù)結構或提高性能。這些妥協(xié)仍困擾著用戶，并且成為錯誤的根源，同時還導致很難調整數(shù)據(jù)庫[1]。
1.2 未能預見未來的需求
在一個數(shù)據(jù)庫生命周期的起始，設計者必須對數(shù)據(jù)總量以及數(shù)據(jù)的使用方式作出相關的假設，設計者還需要預見到數(shù)據(jù)將如何演變。數(shù)據(jù)庫的設計是基于這些假設的。如果假設被證明是正確的，該數(shù)據(jù)庫可以正常發(fā)展；如果假設不正確，數(shù)據(jù)庫結構很快就會過時，格式也將與內容不一致，它還將變得越來越難以適應，數(shù)據(jù)量的增長超出預期，數(shù)據(jù)的使用方式與原先預測的也有很大不同。因此，它成為重新設計數(shù)據(jù)庫的一個必要條件[2]。
1.3 缺乏數(shù)據(jù)獨立性
數(shù)據(jù)庫設計人員往往無法準確預測數(shù)據(jù)庫的實際增長，也無法預見它會如何被使用。當他們開始設計數(shù)據(jù)庫時，他們很可能會僅從一個單一的應用觀點出發(fā)來設計，而不是從所有可能的應用的全局觀點出發(fā)。因此，從一開始，對于應用程序來講數(shù)據(jù)就不是獨立的。隨后，數(shù)據(jù)庫結構需要能兼容更多的、不同的應用程序，但設計的彈性越大，就越脆弱。在某些方面它就不再足夠健壯。
1.4 規(guī)范化不當
數(shù)據(jù)庫結構的每個臨時補丁都具有一定的負面影響。創(chuàng)建新的子表時，附加屬性是必需的。與此不同的是，本地數(shù)據(jù)庫管理員只需將它們添加到現(xiàn)有的表。因此，數(shù)據(jù)庫中的行變得越來越長，并更難處理。當需要增加新的鍵時，它們以索引的形式添加，于是，索引越來越多。當數(shù)據(jù)組添加到現(xiàn)有行時，違背了第二準則。為了避免產生新的子表，會出現(xiàn)重復的數(shù)據(jù)項，這又違反第一準則[3]。
1.5 存儲過程濫用
另一個導致數(shù)據(jù)丟失以及數(shù)據(jù)依賴性的因素就是存儲過程的使用。如果存儲程序只用于訪問操作，并確保數(shù)據(jù)的完整性，這是可以接受的。然而，它們經(jīng)常被誤用來執(zhí)行程序的邏輯，而不是放在單獨的規(guī)則模塊中或放置在客戶端組件程序中以檢查業(yè)務規(guī)則，開發(fā)人員在存儲過程中將其隱藏，使得它們對一些工具不再可見，從而導致存儲過程充滿了選擇和循環(huán)、集和聲明，這就是濫用的典型跡象。
1.6 不一致和不正確的數(shù)據(jù)更新
一個數(shù)據(jù)庫的內容不僅受到錯誤使用程序的影響，而且受到數(shù)據(jù)不一致變化的影響。例如，在兩個不同的表中存放有相同的數(shù)據(jù)，當在一個表改變其數(shù)據(jù)屬性，但沒有改變另一個表中相應字段的屬性時，該屬性就不再與該屬性的類型兼容。法蘭克福股市一度不得不關閉了半天，就是因為數(shù)據(jù)庫中的無效值導致的數(shù)據(jù)異常錯誤[4]。與此同時，另一個問題是丟失和冗余記錄。丟失的記錄是那些仍然有用但已有意或無意刪了的記錄。冗余記錄是那些應該被刪除，但由于某些原因卻沒有被刪除的記錄。它們仍然在數(shù)據(jù)庫中占據(jù)著寶貴的空間，盡管它們已不再使用。
1.7 測試數(shù)據(jù)不足
測試應用系統(tǒng)時，測試人員往往集中在他們可以很容易地看到的地方，即用戶界面，而忽略了他們看不到的東西，也就是數(shù)據(jù)庫。它需要大量的單調的努力掃描幾千行的數(shù)據(jù)，以查看該內容是什么，它們應該是什么。大多數(shù)測試人員沒有時間仔細看一些隨機樣本。實際上，內容檢查應該做到自動化。但問題是，沒有一個公司愿意去做這件事。一次對英國超過150名高級IT工作者的調查發(fā)現(xiàn)，超過40％的受訪者聲明他們的數(shù)據(jù)是不可靠的，可能無法滿足他們的業(yè)務需要。但他們沒有采取措施去清理和糾正數(shù)據(jù)[5]。
2 數(shù)據(jù)質量的研究與發(fā)展
從1980年關系數(shù)據(jù)庫的出現(xiàn)開始，數(shù)據(jù)庫的質量一直是研究人員關注的話題。關于這個問題的最早出版物主要設想制定一個將現(xiàn)有的層次型數(shù)據(jù)庫轉化為關系數(shù)據(jù)庫的標準，以這樣的方式來保持數(shù)據(jù)的語義完整性，同時實現(xiàn)最佳的關系架構。美國的Premerlani、布拉哈以及戴維斯和歐洲的埃諾是上述理論的早期研究人員。埃諾研究的是數(shù)據(jù)庫架構的一致性與實體關系模型數(shù)據(jù)庫模式[6]，而戴維斯研究的是將現(xiàn)有的文件系統(tǒng)轉化為適當?shù)年P系結構[7]。Premerlani和布拉哈研究數(shù)據(jù)庫結構的逆向轉化工程[8]。
當然，關于如何更好地設計出高品質的數(shù)據(jù)庫，已經(jīng)有了一些著作，如1972年，E.F.Codd發(fā)表了文章“數(shù)據(jù)庫子語言的關系完整性”，奠定了規(guī)范化數(shù)據(jù)結構標準的基礎[9]。到1990年，已經(jīng)有很多文獻研究如何更好地設計關系數(shù)據(jù)庫。1990年之后，他對數(shù)據(jù)質量的研究工作轉向現(xiàn)有關系數(shù)據(jù)庫，以便提升它們的質量，并且在這里將質量加入標準化規(guī)則。歐洲的埃諾和Henrard和美國的布拉哈和Premerlani在這個領域中具有權威。布拉哈和Premerlani挑出了一些他們研究數(shù)據(jù)庫時發(fā)現(xiàn)的缺陷，如缺少主鍵，不匹配的引用，枚舉域缺少標準。
彼得和Richards于1994年刊登在通訊ACM上的文章對傳統(tǒng)的數(shù)據(jù)庫逆向過程具有里程碑意義。這篇文章中對于數(shù)據(jù)庫的關鍵不足之處進行了描述，并且講述了應當如何解決[10]。彼得于1996年出版了有關數(shù)據(jù)逆向工程的著作，也標志著將傳統(tǒng)數(shù)據(jù)庫轉化到現(xiàn)有的關系型數(shù)據(jù)庫的研究工作達到高潮。與彼得的研究并行的工程是新型數(shù)據(jù)研究，用于檢測質量比較差的企業(yè)數(shù)據(jù)。這項工作的早期出版物出現(xiàn)于1996年，作者是Y.Wand和R.Wang[11]。該作者指出，他們調查的500家年銷售額超過2千萬美元的中型公司中，60％的公司數(shù)據(jù)質量存在問題，其中主要問題是為用戶定義的數(shù)據(jù)質量比較差。他們承認數(shù)據(jù)有問題，但無法精確定義它們。所以Y.Wand和R.Wang著手于重新定義最經(jīng)常報道的、質量比較差的數(shù)據(jù)，包括：
?。?）表述不完整，即現(xiàn)實世界不能完全映射到數(shù)據(jù)；
（2）模棱兩可的表示，即現(xiàn)實世界被數(shù)據(jù)歪曲；
?。?）無意義的狀態(tài)，即數(shù)據(jù)描述了一些在現(xiàn)實世界中不存在的東西；
?。?）不正確的狀態(tài)，即數(shù)據(jù)是亂碼；
?。?）過時的狀態(tài)，即數(shù)據(jù)不再是最新的。
為了彌補這些缺陷，作者提出了一套用戶應該努力滿足的質量標準。這些是準確度和精密度、可靠性、及時性和流動性、完整性、一致性。
除了改善數(shù)據(jù)的不足，作者還查明產生缺陷的原因，并提出一種修復的方法。兩年后，該通訊ACM中貢獻了很多以“檢查數(shù)據(jù)質量”為主題的文章。編者強調，這些數(shù)據(jù)構成了信息時代的原材料，其質量必須認真對待。關于這個問題的研究，有三篇文章值得特別注意：R.Wang的總數(shù)據(jù)質量管理，K.Orr的數(shù)據(jù)質量和系統(tǒng)理論和D.Kaplan、R. Krishnan、R. Padman以及J.Peters的評估數(shù)據(jù)質量的信息統(tǒng)計系統(tǒng)。這些文章給出了一個深刻的洞察數(shù)據(jù)質量問題的方法以及解決這些問題的方法。
K.Orr將數(shù)據(jù)質量定義為與現(xiàn)實世界的一致性。數(shù)據(jù)質量為1（100%）表明數(shù)據(jù)的表現(xiàn)形式與真實世界達到完美的一致性，而數(shù)據(jù)質量為0表示沒有相似性。K.Orr承認，沒有數(shù)據(jù)庫的質量達到100％，數(shù)據(jù)庫總有一些差錯，并且隨著時間流逝，數(shù)據(jù)與現(xiàn)實之間的差距還在增長，因為現(xiàn)實是不斷變化的。也許數(shù)據(jù)內容可以保持更新，但數(shù)據(jù)結構卻不能隨時改變。現(xiàn)有的數(shù)據(jù)庫主要是靜態(tài)的，因此，數(shù)據(jù)庫時間越久，它們與現(xiàn)實之間的差距越大。K.Orr強調需要定期調整數(shù)據(jù)結構[12]。
在ACM通信中有相似的文章，雷德曼描述了數(shù)據(jù)質量不佳對整個組織的影響。在操作層面，質量差的數(shù)據(jù)直接導致客戶的不滿、成本增加和較低的工作滿意度。低數(shù)據(jù)質量導致運營成本增加，而且會將時間花費在檢測和糾正錯誤上。據(jù)統(tǒng)計，40％~60％的公司服務預算是由于數(shù)據(jù)質量不佳而引起。在戰(zhàn)術層面，糟糕的數(shù)據(jù)質量會影響管理者的決策。由不正確的數(shù)據(jù)而產生的一絲懷疑可以阻礙管理人員作出決定。在戰(zhàn)略層面上，數(shù)據(jù)質量偏低讓人難以遵循一個給定的策略，因為沒有人能確保數(shù)據(jù)的可靠性。如果在無意中使用了這些低質量的數(shù)據(jù)就會產生錯誤。綜上所述，數(shù)據(jù)質量不佳對整個組織的質量有顯著影響，甚至可能威脅到整個系統(tǒng)架構的存在[13]。Wang強調測量數(shù)據(jù)質量的必要性，為此他提出了一套IQ衡量標準。這個標準可以衡量數(shù)據(jù)的準確性、及時性、完整性和一致性。準確性基于表的每列中不正確數(shù)據(jù)的百分比。及時性通過表的最近更新進行測量。完整性根據(jù)每行中丟失或默認數(shù)據(jù)的數(shù)量計算。一致性則記錄違背完整性標準的數(shù)據(jù)。這些度量的加權用來衡量表的質量[14]。
有關數(shù)據(jù)質量的研究，更近的貢獻是艾肯、艾倫等人的文章。文章講述了衡量成熟的數(shù)據(jù)管理過程的方式。這篇文章中出現(xiàn)了在2007年4月發(fā)表在IEEE計算機雜志上的定義模型過程的數(shù)據(jù)管理。在這個模型中，強調了定期審計數(shù)據(jù)的必要性。這些審計應針對缺陷的檢測，并把這件事作為日常管理。用戶組織應根據(jù)數(shù)據(jù)的好壞程度進行分級。
另一篇由Kim、Kishore和Sanders寫的文章講述了在電子商務過程中數(shù)據(jù)質量的重要性。沒有高質量數(shù)據(jù)的保證，電子商務將會變成不可靠的，而不可靠的電子商務永遠不會被客戶或業(yè)務合作伙伴接受。為了留住用戶的信心，數(shù)據(jù)必須接近于100％準確[15]。
最后，在一篇題為“軟件質量改進的一個銅子彈”中，Michael Blaha建議先從數(shù)據(jù)出發(fā)。在花費大量資金投入到改善軟件質量之前，用戶應該首先確保他們的數(shù)據(jù)是有序的。Blaha列出在數(shù)據(jù)中的一些共同的缺陷，例如外鍵超載，模棱兩可的主鍵，數(shù)據(jù)冗余，空引用；在開始數(shù)據(jù)再造項目之前，首先有必要認識到這些問題。
綜上所述，需要一直關注數(shù)據(jù)質量問題，但由于用戶量的增加，數(shù)據(jù)管理的數(shù)量也大幅增長，如管理大數(shù)據(jù)時，需要提升數(shù)據(jù)質量的控制能力。周期性的數(shù)據(jù)審計不再是浪費，而是一項絕對必要的事情。
3 檢查數(shù)據(jù)庫結構的預定義規(guī)則
數(shù)據(jù)庫的許多特征可以通過分析數(shù)據(jù)庫模式實現(xiàn)靜態(tài)檢查。該檢查的模式是檢查數(shù)據(jù)本身的一個先決條件。
3.1 檢查供應商的特定功能
數(shù)據(jù)庫的許多功能源自特定的供應商，也就是說，它們不是標準的SQL。因此，使用時要格外小心，比如一些選項應該禁止，因為它們會影響性能或阻止數(shù)據(jù)的傳輸。像NULL選項，處于相同的原因，也應該禁止。具體哪些功能應該禁止由經(jīng)驗豐富的數(shù)據(jù)庫分析師決定。
3.2 檢查標準形式
不使用供應商特定的功能可能會降低性能，但它使數(shù)據(jù)庫更獨立，即數(shù)據(jù)變得更加便攜。SQL語言并沒有指定每個記錄都需要具有一個主鍵，但它可以是一個強制要求。有一個外鍵也并非必要，但是，如果該表是依賴于另一個表的，則至少需要定義一個外鍵。在任何情況下，一個表都不應該存在相同類型的重復數(shù)據(jù)。這種明顯違背一般準則的現(xiàn)象可以被識別并很容易偵查到。
3.3 檢查數(shù)據(jù)約束
一組數(shù)據(jù)需要多少屬性以及每一行的生命周期都是可以限定的，這就要檢查這些約束是否超標。
綜上所述，可以得出結論，設計數(shù)據(jù)庫應該有一組強制執(zhí)行的規(guī)則。典型的違反規(guī)則的情況如下：
?。?）表中缺少唯一的標識符；
（2）從屬表中丟失外鍵；
（3）表包含重復的數(shù)據(jù)屬性；
?。?）表包含一個子組；
?。?）表沒有外部視圖；
?。?）表沒有索引；
?。?）主鍵包含了太多的子鍵；
（8）空選項丟失；
?。?）刪除選項丟失；
?。?0）表中有不兼容的數(shù)據(jù)類型；
?。?1）屬性的數(shù)量超過上限；
?。?2）行的長度超過了最大允許長度；
（13）架構沒有得到充分評價。
檢查上述規(guī)則并報告相應的違規(guī)行為是架構審計工具的任務，然后數(shù)據(jù)庫管理員可以據(jù)此修正數(shù)據(jù)庫架構。DLIAudit、ADAAudit和SQLAudit等工具檢查IMS、ADABAS、DB-2、Oracle和MS-SQL數(shù)據(jù)庫是否存在違規(guī)行為。這些結果就是數(shù)據(jù)架構缺陷報告，可以用于數(shù)據(jù)庫功能重建。
4 驗證數(shù)據(jù)庫內容
驗證一個給定的數(shù)據(jù)庫的內容要求存在一種準則。首先應該規(guī)定表中應該有哪些屬性。通常，企業(yè)架構師知道正確數(shù)據(jù)的格式。因此他們更有資格定義數(shù)據(jù)驗證規(guī)則，這些規(guī)則俗稱業(yè)務規(guī)則（BR）。
在這里所描述的方法，一種是對象約束語言（OCL）規(guī)范，它被用來作為驗證數(shù)據(jù)正確性的基礎。OCL是一種用UML模型來指定和驗證準則的文本語言。雖然OCL是一種用來驗證數(shù)據(jù)合理性的功能強大的語言，但是對于業(yè)務架構師以及測試工程師而言，它的功能顯得有些不足，僅僅是一種指定語義模型的常規(guī)語言。業(yè)務規(guī)則語言提供的概念從業(yè)務建模的角度在概念層面很容易理解。
4.1 把數(shù)據(jù)驗證準則轉換為SQL約束
為了驗證特定數(shù)據(jù)庫的內容是否違反了業(yè)務定義準則，在BR語言中，將數(shù)據(jù)驗證規(guī)則語言自動轉換成一個SQL語句，這個過程需要兩步。
第一步，業(yè)務規(guī)則被轉換成OCL約束。有人可能會問，為什么這些規(guī)則不能直接轉換成SQL。原因是OCL含有特殊的指向規(guī)則，它們用來描述數(shù)據(jù)實體之間的關系。OCL的優(yōu)勢是它通過一個基本的直接圖模型實現(xiàn)“語義導航”。這種模型是一個域模型（如作為UML或實體關系模型），是獨立的底層數(shù)據(jù)庫模型。這樣可使數(shù)據(jù)驗證規(guī)則適應數(shù)據(jù)庫模式的變化。在這方面，OCL成為業(yè)務規(guī)則和SQL之間的橋梁。
第二步，將第一步所生成的OCL約束轉換成SQL語句。為每個OCL約束創(chuàng)建一個完整視圖。德穆思提出了把OCL約束轉化為SQL的方法，為將OCL表達式映射為SQL語句奠定了基礎。這種轉變必須考慮使用指定了OCL約束的域模型和底層數(shù)據(jù)庫模式。因此，框架需要允許將OCL約束映射到任意數(shù)據(jù)基本模式。
4.2 執(zhí)行SQL語句和評估SQL查詢結果
生成的SQL代碼，即完整性視圖，在目標數(shù)據(jù)庫上執(zhí)行。完整性視圖的目的在于鑒別關系表中所有行有哪些違反數(shù)據(jù)定義規(guī)則。這些規(guī)則的違反記錄被存儲在臨時表，即一個完整性視圖，用于進一步評價。一般而言，這些完整性視圖提供了信息的數(shù)據(jù)質量，因為它們的測量包含其中以某種方式違反了完整性的所有的行規(guī)則。這些違反規(guī)則的情況通過完整性視圖確定。如果完整性視圖沒有行，則數(shù)據(jù)質量=1，這意味著沒有違反規(guī)則的情況；反之，數(shù)據(jù)質量=0，意味著完整性視圖中的行的數(shù)目與原表是一樣的，目標數(shù)據(jù)庫表每行都是錯誤的。當兩個或多個列不能滿足同一個規(guī)則時，仍然只算一次。
5 結束語
本文列出了數(shù)據(jù)質量下降的原因并仔細分析了各種因素帶來的影響，介紹了數(shù)據(jù)質量檢測研究的發(fā)展過程并給出不同階段研究人員的成果，提出了檢查數(shù)據(jù)庫結構的預定義規(guī)則并給出設計數(shù)據(jù)庫應該有一組強制執(zhí)行的規(guī)則，提出了驗證數(shù)據(jù)庫內容的流程，對于以后的數(shù)據(jù)質量研究具有指導意義。
參考文獻
[1] KAPLAN D， KRISHNAN R， PADMAN R， et al. Assessing data quality in accounting information systems [C]. Comm. of ACM， 1998：41-78.
[2] BLAHA M. A manager′s guide to database technology building and purchasing better Applications[M]. Englewood Cliffs：Prentice-Hall， 2001.
[3] DATE C J. An introduction to database systems[M]. Addison-Wesley Pub， Reading Mass， 1975.
[4] KUBICA J， MOORE A.Probabilistic noise identification and data cleaning[C]. In：Proc.of the Third IEEE Conference on Data Mining，2003：22-39.
[5] HUANG K T， LEE Y W， WANG R Y.Quality information and knowledge management[M]. New Jersey： Prentice Hall，1998.
[6] HAINAUT J L. Strategies for data reengineering[C]. IEEE Proc. of 9th WCRE， Richmond， 2002：26-63.
[7] DAVIS K. Step by step data model reverse engineering [C]. Proc. of 2nd WCRE， IEEE Computer Society Press， Toronto， 1995：317-330.
[8] PREMERLENI W， BLAHA M. An approach for reengineering of relational databases[C]. Comm. of ACM， 1994：42-79.
[9] CODD E F. A relational model of data for large shared data banks [C]. CACM，1970：377-390.
[10] AIKEN P， MUNTZ A， RICHARDS R. DOD legacy systems reverse engineering data requirements[C]. Comm. of ACM，1994，2（5）：26-63.
[11] WAND Y， WANG R. Anchoring data quality dimensions in ontological foundations[C]. Comm. of ACM， 1996，11（11）：86-125.
[12] ORR K. Data quality and system theory[C]. Comm. of ACM， 1998，2（2）：66-107.
[13] REDMAN T. The impact of poor data quality on the typical enterprise[C]. Comm. of ACM， 1998， 2（2）：79-120.
[14] WANG R. Total data quality management[C]. Comm. of ACM， 1998，2（2）：58-99.
[15] YONG J K， KISHORE R， SANDERS G L. From DQ to EQ-understanding data quality in the context of E-business systems[C]. Comm. of ACM， 2005：75-123.