龙 宇

（南京邮电大学 通信与信息工程学院，江苏 南京 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.