英语原文共 11 页，剩余内容已隐藏，支付完成后下载完整资料

数据清理中存在的问题和当前的方法

Erhard Rahm 洪海做

莱比锡大学，德国

http://dbs.uni-leipzig.de

摘要：我们分类数据清理所解决的数据质量问题，并提供一个概述主要解决方案。 整合异构数据时，特别需要数据清理来源，并应与模式相关的数据转换一起解决。 在数据仓库，数据清理是所谓的ETL流程的主要部分。 我们还讨论了当前的支持数据清理的工具。

1介绍

数据清理，也称为数据清理或清理，用于检测和删除错误和不一致从数据中提取数据质量。数据质量问题存在于单一数据中集合，例如文件和数据库，例如由于数据输入期间的拼写错误，缺少的信息或其他无效数据。需要集成多个数据源时，例如，在数据仓库，联合数据库中系统或全球基于网络的信息系统，数据清理的需求显着增加。这是因为源通常包含不同表示中的冗余数据。为了提供访问准确和一致的数据，合并不同的数据表示和消除重复信息变得必要。

数据仓库[6,16]要求并提供广泛的数据清理支持。他们加载和连续从各种来源刷新大量的数据，所以有些来源包含“脏”的概率数据“很高。此外，数据仓库用于决策，使其数据的正确性对于避免错误的结论至关重要。例如，重复或丢失的信息将会产生错误或误导统计（“垃圾进垃圾”）。由于可能的数据不一致的范围广泛绝对数据量，数据清理被认为是数据仓库中最大的问题之一。在此期间所谓的ETL过程（提取，变换，加载），如图1所示。 进一步的数据转换处理模式/数据转换和集成，以及过滤和聚合要存储的数据仓库。如图所示。 1，所有数据清理通常在之前的单独的数据分段区域中执行将转换的数据加载到仓库中。大量具有不同功能的工具可用以支持这些任务，但是通常很大一部分清洁和转型工作必须完成手动或通过难以编写和维护的低级程序。

联合数据库系统和基于Web的信息系统面临类似的数据转换步骤那些数据仓库。特别地，每个用于提取的数据源和调解器通常具有包装器用于整合[32,31]。到目前为止，这些系统仅提供对数据清理的有限支持，而是将重点放在模式转换和模式集成的数据转换。数据不是预先集成的数据仓库，但需要从多个来源提取，在查询运行时转换和组合。相应的通信和处理延迟可能很大，难以实现可接受的响应时间。提取和整合期间数据清理所需的努力将进一步扩大增加响应时间，但是强制实现有用的查询结果。

数据清理方法应满足若干要求。首先，它应该检测和删除所有个别数据来源和整合多个来源时的重大错误和不一致之处。该应该通过工具来支持方法，以限制手动检查和编程工作，并可扩展轻松覆盖其他来源。此外，数据清理不应单独执行，而是一起执行基于综合元数据的与模式相关的数据转换。用于数据清理的映射功能应以声明方式指定其他数据转换，并为其他数据源重用以及查询处理。特别是对于数据仓库，应支持工作流基础架构以可靠和有效的方式执行多个源和大型数据集的所有数据转换步骤。

虽然大量的研究涉及模式翻译和模式集成，但数据清理也是如此在研究界很少受到关注。一些作者侧重于问题重复识别和消除，例如[11,12,15,19,22,23]。一些研究小组集中精力一般问题不受限制，但与数据清理有关，如特殊数据挖掘方法[29,30]和基于模式匹配的数据变换[1，21]。最近有几项研究工作提出并对数据清理进行了更为全面，统一的处理，涵盖了几项转型阶段，具体操作者及其实施[11,19,25]。

在本文中，我们概述了数据清理及其解决方案需要解决的问题。在下一节我们介绍一下问题的分类。第3节讨论主要的清洁方法用于可用的工具和研究文献。第4节概述了数据的商业工具清洁，包括ETL工具。第5节是结论。

2数据清理问题

本节分类数据清理和数据转换要解决的主要数据质量问题。如我们会看到，这些问题是密切相关的，因此应该统一对待。数据转换[26]需要支持数据的结构，表示或内容的任何更改。这些转变在许多情况下变得必要，例如处理模式演进，将遗留系统迁移到新的信息系统，或者当要集成多个数据源时。

如图所示。我们大致区分了单源和多源问题之间模式和实例相关的问题。模式层面的问题当然也体现在实例中;他们可以通过改进的模式设计（模式演进），模式转换和模式层级来解决模式级别模式集成。实例级的问题，另一方面是指实际的错误和不一致在架构层级不可见的数据内容。它们是数据清理的主要重点。图2也指出了各种情况下的一些典型问题。尽管图中未示出。 2，单源问题在多源的情况下也发生（有可能性增加），除了具体的多源问题。

2.1单源问题

源的数据质量很大程度上取决于由模式和完整性限制来控制的程度控制允许的数据值。对于没有模式的源，如文件，几乎没有限制可以输入和存储哪些数据，导致错误和不一致的高概率。数据库另一方面，系统执行特定数据模型的限制（例如，关系方法需要简单属性值，引用完整性等）以及特定于应用程序的完整性约束。 Schemarelated因为数据质量问题因为缺乏合适的模型特定或应用特定而出现完整性约束，例如由于数据模型限制或不良模式设计，或因为只有少数完整性约束被定义为限制完整性控制的开销。实例特定的问题与错误有关以及在架构级别无法防止的不一致（例如，拼写错误）。

对于模式和实例级问题，我们可以区分不同的问题范围：attribute（field），记录，记录类型和来源; 各种情况的例子如表1和表2所示。注意唯一性在模式级别指定的约束不能防止重复的实例，例如，如果信息相同真实世界实体用不同的属性值输入两次（见表2中的示例）。

鉴于清理数据源是一个昂贵的过程，防止输入脏数据是显而易见的减少清洁问题的重要一步。 这需要数据库模式的适当设计和完整性约束以及数据录入应用程序。 此外，数据清理规则的发现仓库设计可以建议对现有模式强制执行的约束进行改进。

2.2多源问题

当需要整合多个来源时，单一来源存在的问题会更加严重。每个来源可能包含脏数据，源中的数据可能会有不同的表示，重叠或矛盾。这个是因为这些来源通常是独立开发，部署和维护以满足特定需求。这导致很大程度的异质性w.r.t.数据管理系统，数据模型，模式设计和实际数据。

在模式级别，数据模型和模式设计差异将通过模式的步骤来解决翻译和模式集成。主要问题w.r.t.模式设计是命名和结构冲突[2，24，17]。当同一个名称用于不同的对象（同音异义）时，会产生命名冲突或不同的名称用于同一个对象（同义词）。结构冲突发生在许多变化中涉及不同来源中相同对象的不同表示，例如属性与表表示，不同的组件结构，不同的数据类型，不同的完整性约束等。

除了模式级别的冲突之外，许多冲突只出现在实例级别（数据冲突）。所有来自单源情况的问题可能发生在不同来源中的不同表示（例如，重复的情况）记录，矛盾记录。 。 。 ）。此外，即使有相同的属性名称和数据类型，可能有不同的值表示（例如，用于婚姻状况）或不同的解释价值（例如，衡量单位美元对欧元）。此外，来源中的信息可能是提供在不同聚合级别（例如，每个产品的销售量与每个产品组的销售量）或参考不同的时间点（例如，截至昨天的来源1的销售额与上周的消息来源2相比）。

从多个来源清除数据的主要问题是识别重叠的数据，特别是匹配记录参考相同的真实世界实体（例如，客户）。这个问题也被称为对象身份问题[11]，重复消除或合并/清除问题[15]。经常的信息只是部分冗余，并且源可以通过提供附加信息相互补充关于实体。因此应该清除重复的信息，补充信息应该是巩固和合并，以实现对现实世界实体的一致观点。图2的例子中的两个来源。 3都是关系格式，但表现出模式和数据冲突。在模式级别，有名称冲突（同义词客户/客户端，Cid / Cno，性别/性别）和结构冲突（名称和地址的不同表示）。在实例层面，我们注意到有所不同性别表示（“0”/“1”对“F”/“M”），可能是重复记录（Kristen Smith）。该后一种观察也显示，虽然Cid / Cno都是源特定的标识符，但它们的内容是不可比的来源之间;不同的数字（11/493）可以指不同的人同一个人可以有相同的数字（24）。解决这些问题需要模式集成和数据清理;第三个表显示了一个可能的解决方案。请注意，应首先解决模式冲突，以允许数据清理，特别是基于名称和地址的统一表示来检测重复项，以及性别/性别价值观的匹配。

3数据清理方法

一般来说，数据清理有几个阶段：

（1）数据分析：为了检测哪些类型的错误和不一致被删除，请详细说明需要进行数据分析。除了手动检查数据或数据样本，分析程序应该用于获取有关数据属性的元数据，并检测数据质量问题。

（2）转换工作流和映射规则的定义：根据数据源的数量，异质程度和数据的“脏”，大量的数据转换和清理可能必须执行步骤。有时，模式转换用于将源映射到公共数据模型;对于数据仓库，通常使用关系表示。早期的数据清理步骤可以纠正单源实例问题，并准备数据进行集成。后来的步骤处理模式/数据集成和清理多源实例问题，例如重复。对于数据仓储，控制并且应在定义的工作流中指定这些转换和清理步骤的数据流ETL过程（图1）。

模式相关数据转换以及清理步骤应由声明式指定查询和映射语言尽可能地，使自动生成转换代码。另外，应该可以在a期间调用用户编写的清洁代码和专用工具数据转换工作流程。转换步骤可以请求用户对数据实例的反馈他们没有内置的清洁逻辑。

（3）验证：转换工作流程的正确性和有效性以及转换定义应进行测试和评估，例如，在源数据的样本或副本上，以改进定义如有必要。可能需要多次重复的分析，设计和验证步骤，例如，因为应用一些转换后，一些错误才会变得明显。

（4）转换：通过运行ETL工作流加载和执行转换步骤刷新数据仓库或在多个来源处回答查询时。

（5）清除数据的回流：删除（单源）错误后，清除的数据也应替换原始资源中的脏数据，以便为传统应用程序提供改进的数据并避免为未来的数据提取重新进行清理工作。对于数据仓库，可清除数据从数据分段区（图1）。

转换过程显然需要大量的元数据，如模式，实例级数据特征，转换映射，工作流定义等。为了一致性，灵活性和易用性重用，这个元数据应该保存在基于DBMS的存储库[4]中。为了支持数据质量，详细有关转换过程的信息将在存储库和转换过程中进行记录实例，特别是关于源数据和谱系信息的完整性和新鲜度的信息关于转换对象的起源和应用于它们的更改。例如， 3，派生表客户包含属性CID和Cno，允许追溯源记录。在下文中，我们将更详细地描述数据分析（冲突检测），转换的可能方法定义和冲突解决。对于模式转换和模式集成的方法，我们参考文献，因为这些问题已被广泛研究和描述[2,24,26]。名称冲突通常通过重命名来解决;结构性冲突需要对输入进行部分重组和合并模式。

3.1数据分析

在模式中反映的元数据通常不足以评估源的数据质量，特别是如果只有一个很少的完整性约束被强制执行。因此，重要的是分析实际的实例以获得真实的（重新设计的）关于数据特征或异常值模式的元数据。此元数据有助于查找数据质量问题。此外，它可以有效地识别源模式之间的属性对应关系（模式匹配），基于哪些自动数据转换可以导出[20,9]。

数据分析，数据分析和数据挖掘有两种相关方法。数据分析集中对个人属性的实例分析。它导出信息，如数据类型，长度，值范围，离散值及其频率，方差，唯一性，空值的出现，典型的字符串模式（例如，对于电话号码）等，提供属性的各种质量方面的确切视图。

数据挖掘有助于发现大型数据集中的特定数据模式，例如几种之间的关系属性。 这是所谓的描述性数据挖掘模型的重点，包括聚类，摘要，关联发现和序列发现[10]。 如[28]所示，属性之间的完整性约束等因为可以导出功能依赖性或应用程序特定的“业务规则”，可以用于完成丢失值，纠正非法值，并跨数据源识别重复记录。 例如，高度信任的关联规则可能会在违反此规则的情况下提示数据质量问题。 所以一个规则“total = quantity unit price”的99％的置信度表示1％的记录不符合可能需要仔细检查。

3.2定义数据转换

数据转换过程通常由多个步骤组成，每个步骤可以执行模式和实例相关转换（映射）。允许数据转换和清洁系统生成转换代码，从而减少自编程的数量，这是必要的以适当的语言进行转换，例如由图形用户界面支持。各种ETL工具（参见第4节）通过支持专有规则语言来提供此功能。更一般和灵活方法是使用标准查询语言SQL执行数据转换并利用支持应用程序特定语言扩展的可能性，特别是用户定义的函数（UDF）在SQL中：99 [13,14]。 UDF可以用SQL或通用编程语言来实现嵌入式SQL语句。它们允许实现广泛的数据转换和支持重用于不同的转换和查询处理任务。此外，他们由DBMS的执行可以降低数据访问成本，从而提高性能。最后，UDF是SQL：99标准的一部分应该（最终）可以跨越许多平台和DBMS进行移植。

图4显示了SQL：99中指定的转换步骤。该实施例参照图1。 3并盖住部分需要应用于第一个源的数据转换。转换定义了一个视图可以执行进一步的映射。转换执行一个额外的模式重组通过分割源的名称和地址属性获取的视图中的属性。所需数据提取由UDF实现（以粗体显示）。

UDF实现可以包含清理逻辑，例如，删除城市名称中的拼写错误或提供缺少的邮政编码。UDF仍然可能意味着实质性的实施努力，并且不支持所有必要的模式转换。特别地，简单的和频繁需要的功能，如属性分割或合并不是一般支持但需要经常在应用程序特定的变体中重新实现（请参阅具体的提取功能如图1所示）。更复杂的模式重组（例如，折叠和展开属性）是根本不支持一般支持与模式相关的转换，语言扩展，如需要SchemaSQL提案[18]。在实例级别的数据清理也可以受益于特殊语言扩展，如匹配运算符支持“近似连接”（见下

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[25895]，资料为PDF文档或Word文档，PDF文档可免费转换为Word