龍 宇

（南京郵電大學 通信與信息工程學院，江蘇 南京 210003）

　　摘  要： 評估關系數據庫的質量的過程對數據庫產業至關重要。評估關系數據庫的質量包含兩種獨立的審計方式：一種是對圖表中描述的數據庫結構的審計，另一種是在指定點對數據庫內容進行審計。數據庫圖表審計主要檢查設計缺陷，是否有違背數據庫準則以及偏離原始數據模型的情況，同時測量數據庫的大小、復雜性和結構質量。數據庫內容審計則比較選擇的數據的狀態屬性，以確定是否有不正確的數據，并檢查是否有丟失和多余的記錄。上述兩種方式的目的都是為了啟動數據清理過程，以確保或恢復數據的質量。

　　關鍵詞： 數據質量；數據模型；架構分析；數據有效性；數據一致性

0 引言

　　大多數IT用戶的現有數據庫都是長期演進的產品，許多年前就被設計出來了。當關系數據庫剛開始進入市場時，它們中很多都是從早期的分層或網絡數據庫中通過數據遷移生成的。因此，從一開始，關系數據庫的設計原則就是能適應來自非關系型系統的不兼容的數據，后來，隨著數據結構的侵蝕，造成了不受控制的演變結果。用戶需求隨著時間的推移發生變化，數據模型必須改變以保持同步。如果數據模型變得過時，由于程序錯誤以及使用方式的不一致，使得無效數據值能進入數據庫，那么類似的錯誤數據將會在數據庫中成倍增加，這些問題會使得數據質量大幅降低，并最終導致數據崩潰。

1 數據質量影響因素

　　數據質量下降的主要原因有：（1）數據遷移時的妥協；（2）未能預見到未來的需求；（3）缺乏數據獨立性；（4）規范化不當；（5）存儲不當；（6）不一致和不正確的數據更新；（7）數據測試的不準確性。

　　1.1 數據遷移時的妥協

　　許多用戶的數據庫從一開始質量就很低，因為用戶的數據源自傳統的數據庫系統，如IMS、IDMS或ADABAS。為了使數據遷移變得更容易，因權宜之計而犧牲了關系數據庫的部分原則，如數據庫數組中的數據項放入一行或者以blob形式來隱藏改變的數據結構或提高性能。這些妥協仍困擾著用戶，并且成為錯誤的根源，同時還導致很難調整數據庫[1]。

　　1.2 未能預見未來的需求

　　在一個數據庫生命周期的起始，設計者必須對數據總量以及數據的使用方式作出相關的假設，設計者還需要預見到數據將如何演變。數據庫的設計是基于這些假設的。如果假設被證明是正確的，該數據庫可以正常發展；如果假設不正確，數據庫結構很快就會過時，格式也將與內容不一致，它還將變得越來越難以適應，數據量的增長超出預期，數據的使用方式與原先預測的也有很大不同。因此，它成為重新設計數據庫的一個必要條件[2]。

　　1.3 缺乏數據獨立性

　　數據庫設計人員往往無法準確預測數據庫的實際增長，也無法預見它會如何被使用。當他們開始設計數據庫時，他們很可能會僅從一個單一的應用觀點出發來設計，而不是從所有可能的應用的全局觀點出發。因此，從一開始，對于應用程序來講數據就不是獨立的。隨后，數據庫結構需要能兼容更多的、不同的應用程序，但設計的彈性越大，就越脆弱。在某些方面它就不再足夠健壯。

　　1.4 規范化不當

　　數據庫結構的每個臨時補丁都具有一定的負面影響。創建新的子表時，附加屬性是必需的。與此不同的是，本地數據庫管理員只需將它們添加到現有的表。因此，數據庫中的行變得越來越長，并更難處理。當需要增加新的鍵時，它們以索引的形式添加，于是，索引越來越多。當數據組添加到現有行時，違背了第二準則。為了避免產生新的子表，會出現重復的數據項，這又違反第一準則[3]。

　　1.5 存儲過程濫用

　　另一個導致數據丟失以及數據依賴性的因素就是存儲過程的使用。如果存儲程序只用于訪問操作，并確保數據的完整性，這是可以接受的。然而，它們經常被誤用來執行程序的邏輯，而不是放在單獨的規則模塊中或放置在客戶端組件程序中以檢查業務規則，開發人員在存儲過程中將其隱藏，使得它們對一些工具不再可見，從而導致存儲過程充滿了選擇和循環、集和聲明，這就是濫用的典型跡象。

　　1.6 不一致和不正確的數據更新

　　一個數據庫的內容不僅受到錯誤使用程序的影響，而且受到數據不一致變化的影響。例如，在兩個不同的表中存放有相同的數據，當在一個表改變其數據屬性，但沒有改變另一個表中相應字段的屬性時，該屬性就不再與該屬性的類型兼容。法蘭克福股市一度不得不關閉了半天，就是因為數據庫中的無效值導致的數據異常錯誤[4]。與此同時，另一個問題是丟失和冗余記錄。丟失的記錄是那些仍然有用但已有意或無意刪了的記錄。冗余記錄是那些應該被刪除，但由于某些原因卻沒有被刪除的記錄。它們仍然在數據庫中占據著寶貴的空間，盡管它們已不再使用。

　　1.7 測試數據不足

　　測試應用系統時，測試人員往往集中在他們可以很容易地看到的地方，即用戶界面，而忽略了他們看不到的東西，也就是數據庫。它需要大量的單調的努力掃描幾千行的數據，以查看該內容是什么，它們應該是什么。大多數測試人員沒有時間仔細看一些隨機樣本。實際上，內容檢查應該做到自動化。但問題是，沒有一個公司愿意去做這件事。一次對英國超過150名高級IT工作者的調查發現，超過40％的受訪者聲明他們的數據是不可靠的，可能無法滿足他們的業務需要。但他們沒有采取措施去清理和糾正數據[5]。

2 數據質量的研究與發展

　　從1980年關系數據庫的出現開始，數據庫的質量一直是研究人員關注的話題。關于這個問題的最早出版物主要設想制定一個將現有的層次型數據庫轉化為關系數據庫的標準，以這樣的方式來保持數據的語義完整性，同時實現最佳的關系架構。美國的Premerlani、布拉哈以及戴維斯和歐洲的埃諾是上述理論的早期研究人員。埃諾研究的是數據庫架構的一致性與實體關系模型數據庫模式[6]，而戴維斯研究的是將現有的文件系統轉化為適當的關系結構[7]。Premerlani和布拉哈研究數據庫結構的逆向轉化工程[8]。

　　當然，關于如何更好地設計出高品質的數據庫，已經有了一些著作，如1972年，E.F.Codd發表了文章“數據庫子語言的關系完整性”，奠定了規范化數據結構標準的基礎[9]。到1990年，已經有很多文獻研究如何更好地設計關系數據庫。1990年之后，他對數據質量的研究工作轉向現有關系數據庫，以便提升它們的質量，并且在這里將質量加入標準化規則。歐洲的埃諾和Henrard和美國的布拉哈和Premerlani在這個領域中具有權威。布拉哈和Premerlani挑出了一些他們研究數據庫時發現的缺陷，如缺少主鍵，不匹配的引用，枚舉域缺少標準。

　　彼得和Richards于1994年刊登在通訊ACM上的文章對傳統的數據庫逆向過程具有里程碑意義。這篇文章中對于數據庫的關鍵不足之處進行了描述，并且講述了應當如何解決[10]。彼得于1996年出版了有關數據逆向工程的著作，也標志著將傳統數據庫轉化到現有的關系型數據庫的研究工作達到高潮。與彼得的研究并行的工程是新型數據研究，用于檢測質量比較差的企業數據。這項工作的早期出版物出現于1996年，作者是Y.Wand和R.Wang[11]。該作者指出，他們調查的500家年銷售額超過2千萬美元的中型公司中，60％的公司數據質量存在問題，其中主要問題是為用戶定義的數據質量比較差。他們承認數據有問題，但無法精確定義它們。所以Y.Wand和R.Wang著手于重新定義最經常報道的、質量比較差的數據，包括：

　　（1）表述不完整，即現實世界不能完全映射到數據；

　　（2）模棱兩可的表示，即現實世界被數據歪曲；

　　（3）無意義的狀態，即數據描述了一些在現實世界中不存在的東西；

　　（4）不正確的狀態，即數據是亂碼；

　　（5）過時的狀態，即數據不再是最新的。

　　為了彌補這些缺陷，作者提出了一套用戶應該努力滿足的質量標準。這些是準確度和精密度、可靠性、及時性和流動性、完整性、一致性。

　　除了改善數據的不足，作者還查明產生缺陷的原因，并提出一種修復的方法。兩年后，該通訊ACM中貢獻了很多以“檢查數據質量”為主題的文章。編者強調，這些數據構成了信息時代的原材料，其質量必須認真對待。關于這個問題的研究，有三篇文章值得特別注意：R.Wang的總數據質量管理，K.Orr的數據質量和系統理論和D.Kaplan、R. Krishnan、R. Padman以及J.Peters的評估數據質量的信息統計系統。這些文章給出了一個深刻的洞察數據質量問題的方法以及解決這些問題的方法。

　　K.Orr將數據質量定義為與現實世界的一致性。數據質量為1（100%）表明數據的表現形式與真實世界達到完美的一致性，而數據質量為0表示沒有相似性。K.Orr承認，沒有數據庫的質量達到100％，數據庫總有一些差錯，并且隨著時間流逝，數據與現實之間的差距還在增長，因為現實是不斷變化的。也許數據內容可以保持更新，但數據結構卻不能隨時改變。現有的數據庫主要是靜態的，因此，數據庫時間越久，它們與現實之間的差距越大。K.Orr強調需要定期調整數據結構[12]。

　　在ACM通信中有相似的文章，雷德曼描述了數據質量不佳對整個組織的影響。在操作層面，質量差的數據直接導致客戶的不滿、成本增加和較低的工作滿意度。低數據質量導致運營成本增加，而且會將時間花費在檢測和糾正錯誤上。據統計，40％~60％的公司服務預算是由于數據質量不佳而引起。在戰術層面，糟糕的數據質量會影響管理者的決策。由不正確的數據而產生的一絲懷疑可以阻礙管理人員作出決定。在戰略層面上，數據質量偏低讓人難以遵循一個給定的策略，因為沒有人能確保數據的可靠性。如果在無意中使用了這些低質量的數據就會產生錯誤。綜上所述，數據質量不佳對整個組織的質量有顯著影響，甚至可能威脅到整個系統架構的存在[13]。Wang強調測量數據質量的必要性，為此他提出了一套IQ衡量標準。這個標準可以衡量數據的準確性、及時性、完整性和一致性。準確性基于表的每列中不正確數據的百分比。及時性通過表的最近更新進行測量。完整性根據每行中丟失或默認數據的數量計算。一致性則記錄違背完整性標準的數據。這些度量的加權用來衡量表的質量[14]。

　　有關數據質量的研究，更近的貢獻是艾肯、艾倫等人的文章。文章講述了衡量成熟的數據管理過程的方式。這篇文章中出現了在2007年4月發表在IEEE計算機雜志上的定義模型過程的數據管理。在這個模型中，強調了定期審計數據的必要性。這些審計應針對缺陷的檢測，并把這件事作為日常管理。用戶組織應根據數據的好壞程度進行分級。

　　另一篇由Kim、Kishore和Sanders寫的文章講述了在電子商務過程中數據質量的重要性。沒有高質量數據的保證，電子商務將會變成不可靠的，而不可靠的電子商務永遠不會被客戶或業務合作伙伴接受。為了留住用戶的信心，數據必須接近于100％準確[15]。

　　最后，在一篇題為“軟件質量改進的一個銅子彈”中，Michael Blaha建議先從數據出發。在花費大量資金投入到改善軟件質量之前，用戶應該首先確保他們的數據是有序的。Blaha列出在數據中的一些共同的缺陷，例如外鍵超載，模棱兩可的主鍵，數據冗余，空引用；在開始數據再造項目之前，首先有必要認識到這些問題。

　　綜上所述，需要一直關注數據質量問題，但由于用戶量的增加，數據管理的數量也大幅增長，如管理大數據時，需要提升數據質量的控制能力。周期性的數據審計不再是浪費，而是一項絕對必要的事情。

3 檢查數據庫結構的預定義規則

　　數據庫的許多特征可以通過分析數據庫模式實現靜態檢查。該檢查的模式是檢查數據本身的一個先決條件。

　　3.1 檢查供應商的特定功能

　　數據庫的許多功能源自特定的供應商，也就是說，它們不是標準的SQL。因此，使用時要格外小心，比如一些選項應該禁止，因為它們會影響性能或阻止數據的傳輸。像NULL選項，處于相同的原因，也應該禁止。具體哪些功能應該禁止由經驗豐富的數據庫分析師決定。

　　3.2 檢查標準形式

　　不使用供應商特定的功能可能會降低性能，但它使數據庫更獨立，即數據變得更加便攜。SQL語言并沒有指定每個記錄都需要具有一個主鍵，但它可以是一個強制要求。有一個外鍵也并非必要，但是，如果該表是依賴于另一個表的，則至少需要定義一個外鍵。在任何情況下，一個表都不應該存在相同類型的重復數據。這種明顯違背一般準則的現象可以被識別并很容易偵查到。

　　3.3 檢查數據約束

　　一組數據需要多少屬性以及每一行的生命周期都是可以限定的，這就要檢查這些約束是否超標。

　　綜上所述，可以得出結論，設計數據庫應該有一組強制執行的規則。典型的違反規則的情況如下：

　　（1）表中缺少唯一的標識符；

　　（2）從屬表中丟失外鍵；

　　（3）表包含重復的數據屬性；

　　（4）表包含一個子組；

　　（5）表沒有外部視圖；

　　（6）表沒有索引；

　　（7）主鍵包含了太多的子鍵；

　　（8）空選項丟失；

　　（9）刪除選項丟失；

　　（10）表中有不兼容的數據類型；

　　（11）屬性的數量超過上限；

　　（12）行的長度超過了最大允許長度；

　　（13）架構沒有得到充分評價。

　　檢查上述規則并報告相應的違規行為是架構審計工具的任務，然后數據庫管理員可以據此修正數據庫架構。DLIAudit、ADAAudit和SQLAudit等工具檢查IMS、ADABAS、DB-2、Oracle和MS-SQL數據庫是否存在違規行為。這些結果就是數據架構缺陷報告，可以用于數據庫功能重建。

4 驗證數據庫內容

　　驗證一個給定的數據庫的內容要求存在一種準則。首先應該規定表中應該有哪些屬性。通常，企業架構師知道正確數據的格式。因此他們更有資格定義數據驗證規則，這些規則俗稱業務規則（BR）。

　　在這里所描述的方法，一種是對象約束語言（OCL）規范，它被用來作為驗證數據正確性的基礎。OCL是一種用UML模型來指定和驗證準則的文本語言。雖然OCL是一種用來驗證數據合理性的功能強大的語言，但是對于業務架構師以及測試工程師而言，它的功能顯得有些不足，僅僅是一種指定語義模型的常規語言。業務規則語言提供的概念從業務建模的角度在概念層面很容易理解。

　　4.1 把數據驗證準則轉換為SQL約束

　　為了驗證特定數據庫的內容是否違反了業務定義準則，在BR語言中，將數據驗證規則語言自動轉換成一個SQL語句，這個過程需要兩步。

　　第一步，業務規則被轉換成OCL約束。有人可能會問，為什么這些規則不能直接轉換成SQL。原因是OCL含有特殊的指向規則，它們用來描述數據實體之間的關系。OCL的優勢是它通過一個基本的直接圖模型實現“語義導航”。這種模型是一個域模型（如作為UML或實體關系模型），是獨立的底層數據庫模型。這樣可使數據驗證規則適應數據庫模式的變化。在這方面，OCL成為業務規則和SQL之間的橋梁。

　　第二步，將第一步所生成的OCL約束轉換成SQL語句。為每個OCL約束創建一個完整視圖。德穆思提出了把OCL約束轉化為SQL的方法，為將OCL表達式映射為SQL語句奠定了基礎。這種轉變必須考慮使用指定了OCL約束的域模型和底層數據庫模式。因此，框架需要允許將OCL約束映射到任意數據基本模式。

　　4.2 執行SQL語句和評估SQL查詢結果

　　生成的SQL代碼，即完整性視圖，在目標數據庫上執行。完整性視圖的目的在于鑒別關系表中所有行有哪些違反數據定義規則。這些規則的違反記錄被存儲在臨時表，即一個完整性視圖，用于進一步評價。一般而言，這些完整性視圖提供了信息的數據質量，因為它們的測量包含其中以某種方式違反了完整性的所有的行規則。這些違反規則的情況通過完整性視圖確定。如果完整性視圖沒有行，則數據質量=1，這意味著沒有違反規則的情況；反之，數據質量=0，意味著完整性視圖中的行的數目與原表是一樣的，目標數據庫表每行都是錯誤的。當兩個或多個列不能滿足同一個規則時，仍然只算一次。

5 結束語

　　本文列出了數據質量下降的原因并仔細分析了各種因素帶來的影響，介紹了數據質量檢測研究的發展過程并給出不同階段研究人員的成果，提出了檢查數據庫結構的預定義規則并給出設計數據庫應該有一組強制執行的規則，提出了驗證數據庫內容的流程，對于以后的數據質量研究具有指導意義。

參考文獻

　　[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.