摘要：
数据流管理系统（DSMS）以有效的方式提供实时数据处理，但在数据质量（DQ）和性能之间总是存在权衡。我们为关系型DSMS提出了一个基于本体的数据质量框架，包括以透明、模块化和灵活的方式进行DQ测量和监控。我们遵循一种三方面的方法，将关系型数据流管理的DQ指标的特点考虑在内。(1)查询指标尊重查询操作带来的数据质量变化，(2)内容指标允许对数据流中的数据进行语义评估。最后，(3)应用指标允许用户对数据质量值进行简便的计算，以考虑到应用的特殊性。此外，质量监控器允许我们观察数据质量值，并采取对策来平衡数据质量和性能。该框架是按照适合数据流的DQ管理方法设计的。它已经在运输系统和健康监测领域进行了评估。

背景：
数据流管理系统连续产生数据，可能是无限制的，而且速率很高。
特点：低成本的传感器和高通信带宽--》受益于大量数据的应用越来越多
数据流管理系统（DSMS）：能够实时查询和处理数据，提供广泛的查询和分析操作。查询必须在数据经过时不断地被评估。
挑战：
但产生这些数据流的传感器给数据质量（DQ）评估带来了新的问题，因为它们容易发生故障和错误。
由于传感器连续产生的大量数据，传统的DQ程序无法应用，而各种类型的传感器可能会带来更多问题[Campbell等人，2013]

常见的错误：数据包的丢失、环境影响、内部电子故障、电池耗尽或通信中断[Paradis and Han 2007]

如龙卷风预警系统[Tran等人，2010]或心脏病预测[Lindeberg等人，2010]需要高数据可靠性。

削弱DQ缺陷的一种可能性是融合来自多个来源的数据。来自同一地区的几个传感器的数据被整合，以获得一个连贯的情况，这可能会导致DQ属性的预期值（例如，准确性、一致性、及时性）[Khaleghi等人，2011]。只有当数据具有所需的质量时，它们才应该被用于进一步的处理（例如，将某些检测到的事件通知用户）。因此，DQ是DSMS的一个关键概念，这一点非常重要。然而，一方面是准确性和一致性，另一方面是及时性和完整性，这两者之间通常存在着权衡。虽然必须保持性能以确保实时处理（及时性），但必须确保计算结果的足够准确性。基于DQ值的控制机制，如抽样或额外数据源的动态整合，必须明智地进行微调以保持这种敏感的平衡。

以前关于数据流中的DQ的工作更多关注于系统方面，即服务质量（QoS）。DSMS的QoS维度分为基于时间（例如，吞吐量、输出延迟）和基于内容（例如，采样率、数据挖掘质量）的维度[Schmidt 2006]。意识到QoS维度的DSMS的例子有Aurora [Abadi等人，2003]和QStream [Schmidt等人，2004]。这些系统的一个限制是，QoS参数只提供给输出流。其他方法，如Borealis[Abadi等人，2005]和Klein和Lehner[2009]的方法，在操作者层面管理DQ。查询操作者的实现被修改以在整个查询过程中保持质量信息。通过提供基于输入值计算新DQ值的DQ函数，将输入流中的质量形成传播到输出。这种方法的主要缺点是DQ管理和DSMS的紧密结合，例如，它阻碍了DQ模型的扩展和新的层面。此外，特定应用的DQ功能不容易被引入，因为这需要改变基础的DSMS。

1.1. Contributions

在这篇文章中，我们为数据流应用提出了一个灵活的、整体的、基于本体的数据质量框架。该框架是按照DSMS中的DQ管理方法设计的，该方法是基于全面数据质量管理（TDQM）[Wang 1998]。一个有效的DQ管理对于DSMS来说是必需的，因为DQ的测量和改进必须在系统运行和数据处理的时候进行。因此，DQ方法必须提供DQ管理过程中这些部分的自动化手段。我们认为DSMS是坚定的实时系统，也就是有坚定期限的软实时系统。如果结果在某个截止日期之前没有到达，那么系统的相应输出在截止日期之后就没有用了，但不会因此产生严重的后果[Kopetz 2011]。DQ框架的核心是一个本体，它管理所有与DQ相关的元数据，如数据源、其DQ因素和DQ指标。我们的方法的一个关键特征是对三种类型的DQ度量的区分。

（1）基于内容的衡量标准
（2）基于查询的衡量标准
（3）基于应用的衡量标准。

这些指标可以通过语义规则、DSMS中的查询或特定应用的函数来实现。特别是，计算DQ的方法并不固定。由于所有与DQ相关的元数据都存储在本体中，我们遵循本体驱动（或元数据驱动）的方法进行DQ管理[Jarke等人，1999, 2003]。此外，我们还提供了监控DQ的可能性，当观察到低质量的数值时，定义执行的行动，以及当数值再次处于可接受范围时执行的反击。我们将质量框架作为全球传感器网络（GSN[Aberer等人，2006]）系统的一个扩展来实施.

我们在两个领域评估了我们的方法：运输系统[Geisler等人]。2012] (在CoCar(X)项目的背景下1)和健康监测[Quix等人，2013]。智能交通系统（ITS）依赖于由固定或移动传感器获得的数据。测量交通应用或健康监测中的DQ对于用户的接受程度尤其重要。在这篇文章中，我们重点关注作为我们研究起点的交通场景（DQ框架是作为Geisler等人[2012]提出的交通应用评估环境的扩展而开发的），但我们也将介绍我们的框架在健康监测案例研究中的应用。本文是对我们之前工作[Geisler等人，2011]的实质性扩展，特别是增加了基于数据流应用的DQ方法，用DQ监控和窗口化扩展了框架，并在不同领域提出了一个新的用例。

1.2. Structure of the Paper

2. REQUIREMENTS

数据质量管理不仅是DSMS中的一个问题。数据质量是一个应用的最重要的成功因素之一。糟糕的质量可能会导致用户不满意，造成经济损失，在最糟糕的情况下，它还会危及人们的健康和生命[Redman 2004; Wang and Strong 1996; Judah and Friedman 2014]。特别是在交通方面，安全应用需要基于具有相应质量的数据的高质量输出。在我们的工作中，我们将数据质量定义为 "适合使用"，因为这个质量概念既适用于产品，也适用于数据[Juran 1999; Redman 1996] 。因此，DQ不能由一个单一的衡量标准来定义；相反，必须考虑多个方面来评估相应数据的质量[Wang and Strong 1996]。DQ定义和测量的复杂性需要一个明确的方法来建立系统中的DQ管理技术。这些方法论通常从产品质量管理模式中采用。

然而，现有的DQ方法学[Batini等人，2009]，如TDQM（Wang [1998]）模型，并不适用于数据流，因为分析和改进步骤没有考虑到DSMS的动态和连续性质。在DSMS中改善DQ的行动需要在数据被处理的过程中进行；因此，如果DQ测量值不在期望范围内，系统应该能够自动调用方法来改善DQ。尽管具体的行动不能被采纳，但DSMS中的DQ框架要求DQ的结构化过程也是合理的，其中包括设计、测量、分析和改进等主要阶段。

DQ测量可能是非常复杂的，可能需要比简单的SQL查询更多的表达能力。在一个简单的SQL查询中提供更多的表达。例如，在交通信息系统中，来自全球定位系统（GPS）传感器的信息必须与道路的特定部分相匹配（地图匹配）。这样的应用需要特定的DQ度量和DQ维度，因为匹配置信度的评级只能由方法本身来评定。
Redman[2013]甚至将DQ描述为主观的--其定义可能因不同的案例和用户而异。因此，我们的目标是建立一个容易扩展的DQ框架，并且不被重新限制在某些质量维度上。由于DQ是多维的（即，一个元素可能在不同的DQ维度上有几个DQ值），基于单个DQ值的DQ值的计算应该是可能的。这种计算应该由用户定义的评估公式完成。因此，用户可以根据他们的需要和个人喜好来调整综合DQ值的计算。原则上，必须找到一种通用的方法，使我们能够实现独立于应用领域的任何维度和任何度量。

此外，数据流中的DQ管理应该是全面的，而不仅仅是集中在输出流的质量上。在整个DSMS中监控DQ是很重要的：传入的图元可能已经包含了质量信息，当数据 "流经 "DSMS时，这些信息需要被维护。这也包括查询操作的语义（可能需要重新计算DQ值，例如，通过聚合、连接或类似操作）必须在DQ管理中加以考虑。此外，还必须增加新的DQ维度，这些维度可以根据现有的DQ值或通过特定的应用功能或语义规则来计算。因此，为了在每个数据处理步骤中提供质量信息，一个解决方案必须便于用DQ值扩展数据流元素。

对所使用的数据质量的了解有助于评价基于这些数据的计算结果的重要性。基于这些数据的计算结果的重要性。除了对DQ下降或低的唯一观察，如果可能的话，最好采取对策来提高质量。因此，DQ框架还应该包括一种舒适的方式来定义规则，指定定期检查的DQ值。此外，应该可以定义当规则被违反时应该执行的行动。

数据分析师也可能对涉及原始数据窗口化的数据质量测量感兴趣，例如，一个参数在过去5分钟或50个元素的平均值。窗口化可能只是数据质量分析的需要，在不需要这种DQ测量时，不应该进行窗口化。因此，应该提供一个灵活的解决方案，为分析目的创建一个数据窗口。DSMS属于实时系统[Stonebraker等人，2005]，在狭窄的时间框架和内存范围内运行。因此，DQ处理的整合需要满足实时性的要求，并且不能对内存的使用或中央处理单元（CPU）的时间构成明显的额外开销。此外，还需要最大程度的自动化。没有时间进行重新定义DSMS中的数据流的人工处理。此外，DQ管理应该是一个可选择的功能--如果不需要或不需要DQ信息，那么应该可以关闭DQ功能而不影响数据处理。

最后，为了便于定制和扩展，DQ框架必须是元数据驱动的，也就是说，测量DQ的过程应该由中央组件管理的元数据来配置。这也使得DQ相关功能的定义和数据流的处理得以分离。

在下面的章节中，将介绍DSMS的DQ管理框架的方法。的DQ管理框架的方法将被介绍。首先，第3节将介绍总体方法。随后，第4节描述了该框架的架构，第5节和第6节详细解释了该框架的每个组成部分。

3. DATA QUALITY MANAGEMENT METHODOLOGY FOR DSMS

Wang和Strong[1996]强调，数据质量不能根据单一的方面来评定。他们提出了数据质量维度的概念，即 "代表数据质量单一方面或构造的一组数据质量属性"。为了我们的目的，我们对这个定义做了如下调整。
定义3.1（数据质量维度、数据质量度量和数据）。一个数据 被认为是具有明确定义的原子属性，并且可以使用一个或多个明确定义的度量标准对特定的数据项进行测量。数据质量度量被定义为将一个或多个数据项映射到一个数字DQ值的函数。数据一词指的是产生或处理的所有种类的价值项目--无论它是作为原始值还是派生值或计算值来衡量的。

DQ管理的常见方法已经在工业和研究中得到认可。因此，利用这些知识并提取适合数据流设置的方面是合理的。我们选择将前述的TDQM循环适应于数据流。我们采用了设计、测量、分析和改进这四个阶段，但在周期中增加了一个额外的步骤。此外，对于数据流的设置，我们区分了必须在设计时手动完成的步骤和在运行时自动执行的步骤。对于这四个阶段，我们希望有以下行动。
（1）Define：与其他模型类似，在这个阶段，将获得对要实施的应用的要求。基于这些要求，DQ维度和相应的度量被定义。此外，尺寸、度量和数据流组件之间的映射关系，例如，属性必须被指定。这些步骤是在设计时完成的。在系统的运行期间，不需要定义步骤。另外，自动分析和改进的规则也可以在这一步定义。
（2）Measure: 基于定义的维度、度量和流组件之间的映射，可以测量相应的DQ值。这必须在系统运行期间完成，因为DQ值必须和基础数据一样是最新的。
（3）Analyze: 测量的DQ值也在运行期间进行评估。在线分析使系统和用户能够对低DQ值作出及时反应，这与传统的DQ方法相比是一个很大的优势。分析的规则是在设计时定义的，以实现对DQ值的自动监测。
（4）Improve: 有两个层次的改进是可能的。首先，当分析阶段的DQ监测确定DQ值下降时，在设计时定义的措施，例如，激活额外的数据源，在运行时自动执行。这种在线改进可以帮助解决在定义阶段发现的问题，只要它们发生。改进的效果，如果存在的话，又可以在测量阶段被发现。其次，当然也可以在审查测量的DQ值时对流程、数据源等进行离线改进。最后，在定义阶段定义的元数据可以被更新，以改善运行中的DQ测量、分析和改进过程，例如，可以增加一个缺失的维度或定义一个新的对策。

Fig. 1. DQ Management for data streams. 

4. ONTOLOGY-BASED DATA QUALITY FRAMEWORK ARCHITECTURE

（1）基于这些要求，我们确定了数据流应用和数据流处理的三个主要方面，对这些方面必须计算元素和属性的DQ。
首先，数据流的内容和它的元素应该根据它们的语义来评定。这可以通过语义规则来完成，这些规则描述了一个属性值或一个数据流元素中几个属性的组合值的可接受范围。这种规则是语义的，因为它们使用了数据项的特定领域语义。例如，一个规则可以为车辆的速度测量定义一个上限。如果一辆车的速度超过280公里/小时，那么这个属性的DQ值应该非常低。这种类型的DQ测量是由基于内容的质量服务完成的。
（2）为了对数据处理的每一步的DQ进行评级，DSMS中的查询处理操作（如连接、聚合）也必须被考虑在内，因为它们可以改变流经系统的流元素的DQ值。因此，一个框架应该包括分析查询和重新计算相应的质量值的方法。我们将这些任务分配给基于查询的质量服务。
（3）在数据流应用中，定制的和与应用相关的数据处理和分析被实施，也可能增加或改变DQ值。这些任务被归入 "基于应用的质量服务 "部分。此外，一个数据质量监控器观察数据质量值，并在必要时调用行动以抵消低质量。这些服务和质量监控器的元数据被存储在DQ本体中；整体架构如图2所示。

我们提出了一个扩展DSMS的DQ框架，也就是说，DQ框架是DSMS的一个（可选）附加物。我们坚持关系型DSMS和著名的数据流的多集或袋状语义[Arasu等人，2006；Geisler 2013]。因此，单个数据流由一组属性（模式）定义，并由遵守模式的数据流元素或图元组成。当纳入DQ时，数据流属性集可以由一组DQ属性扩展，其中每个属性代表一个DQ维度。我们将这些数据流定义为具有质量特征的数据流，如下所示。

在语法上，质量属性与数据属性没有区别。从语义上讲，它们的处理方式不同，在数据处理过程中必须可以识别。例如，一个Car-2-X消息数据流（该消息包括来自车辆传感器的信息）可以通过DQ信息以下列方式扩展。

Definition 4.1 Quality-Affine Data Stream

S is a (possibly infinite) multiset of data stream elements (s,τ,q)
，是一个时间戳
s是构成流模式S的一组属性。
q代表测量到的数据质量的维度。（1，m）
:信息的年龄
:测量到的速度的错误率

5. SEMANTIC DATA QUALITY COMPONENTS

DQ本体表示DQ测量所需的元数据，包括DQ维度和DQ度量，与数据流应用领域的概念相联系。这允许对图元、窗口和属性的DQ进行评估。我们决定使用本体论来构建这些语义知识。
本体论使我们能够单独定义领域知识、DQ维度和度量，并以模块化的方式将它们相互联系起来。
在下文中，我们将首先讨论并得出适合ITS应用和DSMS的DQ维度和度量。之后，我们将详细介绍本体的结构，并描述处理本体的框架的组成部分。

5.1. DQ Dimensions in DSMS and Traffic Applications

DQ维度被定义为可以测量的数据项的特征，而DQ度量被定义为执行这些测量的方法（即为数据项分配DQ值，见定义3.1）。正如一些DQ方法论和我们的方法所强调的那样（参见第3节），DQ管理的第一个重要步骤是识别应用需求和推导相关的DQ维度和度量。目前已经有一套公认的、通用的维度，普遍适用。然而，每个应用都可能引入针对该应用或领域的DQ的新方面。正如Redman[2004]所指出的，存在 "数以百计的数据质量维度，相对少数的维度在实践中是最重要的"。因此，确定与目标应用相关的维度是至关重要的。

存在大量的结构化和描述DQ维度的分类方法。 如TDQM分类[Wang and Strong 1996; Strong et al. 1997]，Red-man分类[Redman 1996]，或DataWarehouse质量（DWQ）分类[Jarke et al. 1999]。这些分类法根据不同的方面对维度进行分类。Fan和Geerts[2012]特别指出，及时性、完整性和一致性是数据质量的核心问题。具体到ITS，有几个缺陷的来源是获取数据的方式所固有的。静态和移动传感器都会出现错误和故障。基于道路的传感器（如感应式环路）可以在流量和速度测量中引入2%到10%的误差，这些误差是由环境条件、不正确的位置、校准问题、不良维护和操作故障等造成的。这些原因也适用于非侵入式传感器，如雷达传感器[Margiotta 2002]。因此，从获取数据开始，对数据质量的监控对于做出正确的估计至关重要。另外，路网覆盖率、采样率和聚集间隔等方面的问题也是质量问题[Margiotta 2002]。Dalgleish和Hoose[2008]定义了交通数据中的三类错误。系统误差（与参考值的持续偏差），随机误差（误差值在平均值周围有一定的分布），以及失误（不可预见的错误，例如，人为故障）。已经有几项工作，试图分析交通应用中的质量问题。表一中总结了所提出的维度。

Table I. DQ Dimensions in ITS Literature

我们还在健康领域做了一个文献研究，以找到具体的重要的 DQ维度。这些文章根据被评为最重要和最频繁的维度进行分析研究。表二总结了我们的发现。

Klein和Lehner[2009]提出了一个数据流的DQ维度分类。这与我们的工作有关。在表III中，我们列出了一组非详尽的DQ维度，我们认为这些维度对DSMS中的DQ评级很重要。特别是，我们选择了我们认为与交通和健康应用相关的维度（基于Klein和Lehner[2009]，表一和表二）。其他维度也可能是相关的，我们的系统并不局限于选定的维度。使用一个可扩展的本体，我们能够对任意的维度和相应的元规则进行建模。我们区分了两类维度。基于应用的DQ维度评价数据的特定应用语义。此外，基于系统的DQ维度也考虑了与性能相关的问题。例如，一个系统的各种性能方面的服务质量（QoS）必须在查询处理中被跟踪和考虑到。也有一些维度同时属于这两个类别。此外，一个维度的DQ可以在不同的层面上进行测量。它可以在系统范围内测量，例如，在输出率上；在操作者层面，例如，操作者的选择性；或者在窗口、元组或属性层面。

5.2. Data Quality Ontology

本体是一个非常合适的工具，可以
（1）对DQ概念以及领域概念和它们之间的关系进行建模
（2）将知识模块化并使其可重复使用
（3）由于其人的可读性和广泛的工具的可用性，可以由用户改变
（4）作为自动评估DQ过程中的一个配置。

Visualization of the DQ Ontology. 

关于DQ2,3,4、DQ管理清理[Preece等人，2008；Br ¨uggemann和Gr¨uning，2008]、DQ管理Vo- cabulary规范5和数据流6[Kolozali等人，2014]已经提出了几个本体。但是，许多人无法访问，或者只是在文章中稀疏地描述。而那些可访问的文章也不能完全满足我们的需求。DQ的几个概念在多个本体中重复出现，如DQ维度、度量等。但也有一些是手头的应用所特有的。

就整个框架结构而言，DQ本体已经被建模，以便将数据流应用中的组件（图元、窗口和属性）与相应的质量维度和度量联系起来，其中需要进行DQ评估。DQ本体也可以被看作是DQ信息的元模型；它受到了数据仓库系统中DWQ管理的元模型的启发[Jarke等人，1999]。它与DWQ元模型的不同之处在于，它包括来自数据流领域的概念，不包括与数据仓库相关的概念。此外，它是沿着该方法的三段式设计的。图3划定了DQ本体的结构。彩色的概念描述了数据流应用中的范围，例如，数据流窗口或数据流元素的属性。白色的概念说明了DQ评估组件，包括重写SQL查询的度量，评估语义规则，以及将用户定义的操作应用到应用程序。虚线箭头表示对象属性（即关系），箭头指向 "使用"对象的方向，例如，一个DQ窗口有一个DQ因子。实线箭头代表isA关系。

从数据仓库的DQ评估方法[Jarke等人，1999]中采用的DQ因素的概念，提供了数据流对象、DQ度量和DQ维度与数据流组件范围内的DQ评估任务之间的联系。衡量标准根据其目的、方式和计算类型进行了分类。一个语义指标与一个或多个语义规则有关。语义规则可以由任意的数学表达式来表达，例如布尔表达式或算术表达式（取决于系统中在线质量评估期间用于评估表达式的数学表达式解析器的能力）。例如，我们可以定义一个语义规则实例，通过表达式speed < 280来限制可重复的速度值。为了描述数据的内在属性（例如，根据欧盟指令，我们将速度计的内在测量误差固定为0.9），可以定义一个常数度量，其实例将包括一个DQ维度的常数值。

应用指标为用户定义的函数和相关的DQ尺寸提供了一个接口。应用指标的计算是在DSMS的用户定义代码中定义的。最后，SQL度量考虑到两种情况。
(1)引入DQ维度，使用SQL操作符进行计算（例如，完整性），
(2)DQ值在处理SQL查询时发生变化（例如，当查询中使用连接或聚合时）。每个SQL Metric实例都与一个或多个Function实例相关，它可以识别改变质量值的SQL操作者（输入）或用于计算新DQ维度值的SQL表达式（称为输出或替换函数）。使用定义的输出函数重写具有输入函数的SQL查询是由查询规则实例定义的。这些规则将DQ维度、SQL操作符和函数与替换函数联系起来。查询的重写将在第6节描述。

到目前为止所描述的本体是通用的，也就是说，与领域无关。它 可以应用于任何领域。为了实现建模概念所需应用的DQ要求，必须创建实例。图4概述了一个SQL度量的使用实例，用来评估一个窗口的关系元组中的属性的完整性。流属性Speed被分配了一个DQ因子，该因子将DQ维度的完备性与SQL度量联系起来。完整性是由算术运算符和SQL函数（count/all）组成的表达式定义的。变量count和all是对函数的引用。每个函数都有一个SQL映射，表示插入到查询中的SQL表达式，以计算变量的值。映射定义中的占位符#被相应的属性名称（本例中为Speed）所取代。SQL映射的表达能力仅限于SQL查询的SELECT子句中所允许的表达方式；更复杂的表达方式可以通过应用指标来实现。

第2节中描述的另一个要求是可以定义DQ值的界限。DQ值的界限，以及在该值不在所需的界限内时采取相应的对策。因此，在本体中实现了一个DQ约束的概念，它与被测试的DQ因子、描述如何检查约束的语义规则、定义了DQ因子的流对象以及违反约束时要执行的一个或多个约束行动有关。对于每个绑定动作，可以定义一个或多个计数器绑定动作。当DQ值再次处于可容忍的范围内时，这些就被执行。对于每个约束，可以定义一个孵化值，它决定了在采取行动之前，测量的DQ值必须超过或低于该约束的频率。例如，假设我们用一个DQFactor来监控用于计算平均速度的元素数量。如果只有几个元素，那么我们就激活另一个数据源以提高平均速度值的准确性。因此，如图5所示，定义了一个DQFactor Data_Quality_Factor_Volume的约束，一个流aggregationAndIntegrate（代表聚合和整合的数据），其孵化时间为5，以及一个相应的约束规则。边界规则检查在当前时间窗口中是否有超过50条Car-2-X信息被使用，也就是说，当该规则连续5次被评估为真时，该规则会。当该规则已被dq car2xno datavolume ≤ 50。绑定动作addMobilePhones将被调用，连续五次被评估为false，计数器动作removeMobilePhones中定义的方法被调用。

最后，需求中要求有一个灵活的解决方案来创建仅用于数据质量分析的窗口。尽管本体中已经有一个概念 "窗口"，但为此目的引入了一个新的概念DQ窗口。第一个概念是应用逻辑的一部分，而第二个概念只需要用于DQ分析的目的。DQ窗口也与DQ因子相连，以表明要测量的DQ参数并与相应的流对象相连。这个概念的每个实例都有两个属性，即大小和滑动，它们决定了DQ窗口的大小和滑动步骤（两者都可以是基于数值或基于时间）。在下文中，我们将描述本体在系统初始化过程中是如何被加载并提供给框架的DQ组件的。对于一个应用来说，属性、传感器、维度、度量和规则的定义只需要做一次。由于本体的模块化设计，可以重复使用维度、度量等的实例。本体已在W3C网络本体语言（OWL）中实现，可在http://dbis.rwthachen.de/projects/DQStream，并已提交给Swoogle和Watson进行索引。DQ信息由元数据提供者提供，并由DQ处理器和相应的服务处理。

6. DATA QUALITY PROCESSING

在扩展的TDQM周期中的定义阶段之后（参见第3节），测量阶段必须被准备和执行。在定义阶段创建的本体内容被用来配置测量阶段，或者更具体地说，用来配置系统的运行时间。这意味着，对于每个流组件，指定的DQ维度和度量被整合到DSMS流程和数据流中，这样DQ测量就可以在运行时执行。负责准备测量的组件在下文中解释。实际测量是由第6节中描述的数据质量服务来进行的。

由于该框架的重点是对具有DQ评估功能的关系型DSMS的可选扩展，所有有助于数据处理的底层组件和使用的DSMS的一部分都归入数据处理器这一术语。这个组件负责系统中的数据操作和查询的执行（重写和原始查询）。数据处理器获取流图元并将其传播到系统中。当DQ处理被启用时，它将图元交付给DQ处理器，后者将根据加载的指标计算DQ值。与确定的数据处理的三个方面相对应，设计了三种不同的DQ评估服务。DQ服务分为两组。首先，离线DQ处理是在系统的初始化阶段执行的，它执行与SQL指标相对应的查询的重写。第二，在线DQ服务对语义规则进行实时评估，并整合应用程序的DQ测量结果。

质量元数据提供者代表了DQ评价信息（在DQ本体中定义）和DQ处理器之间的接口，DQ处理器将在随后列出。DQ处理器在DSMS的初始化过程中，或在连续查询被注册或改变时，将本体加载到主内存中。DQ处理器从质量元数据提供者那里检索DQ信息，并在DSMS中启用实时DQ处理。该处理器分析注册的数据流组件，并在质量元数据提供者中查找相应的DQ维度和指标。对于每个DQ维度和属性，都有一个字段被添加到手头的数据流元素中（即，数据流被转换为质量参数流）。处理器确定每个DQ属性使用的是哪种度量。它将常量指标、语义指标和应用指标的处理委托给相应的服务组件（基于应用的质量服务和基于内容的质量服务）。SQL指标由基于查询的质量服务来处理，它直接与质量元数据提供者进行通信。质量服务将在随后的章节中详细介绍。

6.1. Query-Based Quality Service

由于关系型DSMS允许通过关系型操作符进行数据处理和过滤，这也是DQ测量必须考虑的因素。通过对查询的解析和分析，可以识别出在数据处理步骤中对DQ值有影响的操作者，如聚合、连接或选择。此外，可以通过SQL表达式计算的新DQ属性也可以通过重写初始查询插入。出于这个原因，在DSMS的初始化阶段或注册新的查询时，基于查询的质量服务会重写连续查询。这些查询由DSMS的数据处理器执行，处理流元素中的DQ信息。通过这种方式，我们使系统能够以同样的方式处理数据流和质量亲和的数据流。例如，如果用于计算道路平均速度的Car-2-X信息的数量与DQ测量有关，那么将为速度属性定义一个SQL Metric speed_datavolume。与图4的例子类似，定义了一个变量count和一个SQL映射COUNT(#)，表示应该如何重写查询以计算属性SpeedDatavolume的值。基于这个指标，原始查询Q1（见清单1）将被改写为查询Q2

6.2. Content-Based Quality Service

与重写查询不同的是，这项服务在数据流元素到达和相应的度量和尺寸可用时执行。基于内容的DQ服务根据流元素字段中的数据值计算DQ值。这些计算是基于本体中恒定度量和语义度量的语义规则的评估。这些规则由数学表达式表达，使用属性名称作为变量标识。计算的总结果被插入到相应的DQ属性中。语义度量还允许使用一个流元素的多个属性来定义规则。等式（1）举例说明了一个语义规则，它被定义为识别低于或高于合理界限的速度值。

6.3. Application-Based Quality Service

基于应用的质量服务为用户定义的功能提供了一个接口，为每个数据流元素添加DQ值。这允许定义任意的用户定义的DQ评估方法（只要它们可以用Java编码）。为了考虑到用户定义的操作的复杂性和未知参数，DQ的评估是专门针对特定的应用。例如，一个数据挖掘分类算法可以提供其准确性（即与所有分类元素相比，正确估计的元素）作为DQ属性。图6概述了用户定义的操作的应用。一个地图匹配算法将GPS坐标作为输入，并将其与道路网的相应道路相匹配。除了匹配结果，用户定义的函数还根据其计算和配置分别提供质量信息。

6.4. Data Quality Monitor

DQ监控器观察所处理的流对象的质量，并根据需要调用约束行动和相应的反作用。因此，它实现了第3节DQ方法中的两个步骤，即分析和改进阶段。在第5.2节的例子中，一个时间窗口中可用的Car-2-X消息的数量，由DQ值dq_car2xno_datavolume代表，将被监测。对于每个流对象，语义规则的评估方式与基于内容的质量服务中使用的语义规则相同。唯一的区别是，结果值不会被添加到流元素中，而且规则必须评估为真或假。如果一个规则返回为真，那么相应的约束就被视为违反了，并且违反计数器会增加。孵化值决定了在采取行动之前可以容忍多少个连续的违规行为。当达到最大孵化值时，一个方法（例如addMobilePhones）被执行，该方法的名称在本体中也被定义为绑定动作，同时还有DQ绑定。该方法是使用Java中的反射来调用的。当规则被违反的次数没有达到孵化值时，反作用力的指定方法（例如，移除MobilePhones）将以与绑定动作相同的方式执行。

该框架已经在基于Java的DSMS全球传感器网络（GSN，Aberer等人[2006]）之上实现。它已经被整合到我们基于数据流的交通应用的整体评估框架中[Geisler等人，2012]。在下文中，我们将简要介绍所述组件在GSN系统中的实现。

7. EVALUATION

对DQ框架的评估是为了测试几个方面。首先，我们的目标是在交通应用领域进行概念验证，以显示该系统的有用性和适应性。为此，我们使用了一个危险警告场景，检测高速公路上的排队终点。第二，必须证明该框架不影响DSMS的实时处理能力。因此，我们检查了DQ框架的CPU使用率、内存消耗和运行时间。 此外，还应该证明其有效性：我们改变了数据的来源质量，并测试了这些变化是否反映在输出流的DQ值上。最后，我们在第二个完全不同的应用领域，即健康监测领域，准备了一个额外的案例研究，以显示该框架的灵活性和适应性。

7.1. Case Study Queue-End Detection

许多道路上的死亡和事故都是由于司机察觉到排队结束的时间太晚造成的。因此，排队结束检测是一个重要的交通应用，可以大大减少此类事故造成的严重后果。然而，排队结束的检测应该有很高的可靠性，因为如果经常出现假阳性，道路使用者就会忽视这些信息。由于实时信息的DQ可能由于第5.1节中讨论的问题而波动，数据处理结果的可靠性不能在任何时候和所有方面都得到保证。最好是只向道路使用者传播那些对应于高DQ水平的信息。因此，一个基于多个DQ值的总体置信值被计算出来，它反映了排队结束估计的可靠性。然后，道路使用者可以配置一个单独的过滤器，使他们只收到高于一定置信度的排队结束信息。

在我们对GSN系统中的队列末端检测场景的实现中，我们 从交通模拟中接收两个独立的数据流。一个是由车辆发送的实时信息流。另一个包括描述交通模拟提供的交通状况中队列末端的真实位置的信息（进一步称为地面真相）。我们使用交通模拟来完全控制交通情况，并能够改变交通参数，如交通量。我们使用了VISSIM，这是目前最复杂的交通模拟之一。此外，当时还没有关于Car-2-X交通情景的真实数据。

收到的实时信息中的位置是扭曲的，以模拟GPS定位的误差。GPS定位的误差（我们称这个过程为降级）。之后，该位置由另一个虚拟传感器与路网中的某个路段和环节相匹配（称为地图匹配）。随后，在另一个虚拟传感器中，信息的数据被汇总到每个路段（我们计算平均速度、平均加速度、每个信息类型的信息数量）。在同一个传感器中，这些数据与地面真实信息的数据进行整合。整合后的数据流现在可以作为分类算法的训练数据。我们采用先测试后训练的方法，也就是说，先用一个数据项来测试数据挖掘方法的质量，然后再把它作为额外的训练数据项。如果分类算法在某些路段检测到排队结束，那么随后的虚拟传感器就会向道路使用者发送一个信息（在我们的模拟中，信息被发送到模拟软件，以使结果可视化）。

DQ本体论被扩展到为该场景所需的DQ维度和度量建模。本方案所需的DQ维度和指标。在图7中，显示了所有组件的DQ维度。封装器被描述为彩色方框，虚拟传感器为灰色方框，而DQ维度为白色方框。作为一个例子，我们在下面更详细地描述包装器的DQ维度。

在现实生活中，必须考虑到由速度表和加速度传感器引入的不精确性，我们在模拟中通过引入统计测量误差来做到这一点。这些值的DQ测量可以基于一般的统计数据或法律要求（例如，在欧盟，速度计必须有90%的精度）。因此，我们在这里使用恒定的DQ度量。特别是在实时应用中，一个重要的DQ维度是及时性。每个传入的信息都有一个时间戳（TS），它将被用来计算系统中信息的年龄。这是由SQL DQ Metric计算出来的。数据字段SPEED、ACCEL、LNG和LAT是通过语义DQ指标来评估的，该指标使用语义规则来计算维度一致性的DQ值。这些规则表达了字段值的合理性和合理性以及特定领域的完整性约束模型。字段LNG和LAT的一致性是根据道路网络中地理空间边界的限制来衡量的。总的可信度值，旨在表明传播信息中预测的危险的可靠性，被作为一个共同的DQ维度来处理。它也由语义DQMetric和规则来计算，本体中对各种DQ值的公式（2）定义如下。

信度公式取决于应用场景和领域，因此可以通过改变本体中的相应元素来轻松调整。

7.1.1. Results.

在对DQ模型进行调整以包括本数据流应用的DQ维度和关系后，我们在一个道路网络上进行了交通模拟，并在GSN系统中用上述组件处理模拟产生的数据。模拟的道路网络包括一条长约5公里的道路，有两个方向。道路的一个方向被一个建筑工地缩小了，该工地周围是一个减速区。车辆的数量被设定为每小时3000辆。10%的车辆配备了Car-2-X通信技术，也就是说，只有这些车辆发送信息。每次模拟运行的时间为30分钟。实验在一台拥有8GB主内存、2.4GHz英特尔酷睿I5双核处理器和Windows 7 64位操作系统的机器上执行。第一次模拟运行被视为参考运行，其参数和设置如前所述。

DQ的变化对衍生的DQ信息和信心值的影响。为了评估为了评估DQ信息和由此产生的置信值如何准确反映处理后的数据质量的变化，我们模拟了数据中的这些变化。首先，我们通过改变Car-2-X包装器的采样率来评估传入数据的数据量变化对数据质量因素的影响。在图8中，显示了不同的采样率（1.0意味着100%的元素被转发，0.25意味着75%的元素被随机丢弃）及其对整合与聚合组件的平均速度的数据量质量维的影响。采样率直接影响到数据量，因为数据被丢弃，因此随后转发和聚合的数据就会减少。显然，一个路段的平均速度值是越多的数据（即信息）来计算它就越准确。因此，数据量是评价平均速度的一个重要DQ维度。

这个DQ维度的影响也反映在不同的信心值的差异上（参见图9），因为这个DQ维度的权重只有1/ 16在由于这个DQ维度在整个信心值中的权重只有1.16，所以差异不是很明显。

在第二个实验中，我们比较了定位的准确性和它们对整个DQ的影响。我们改变了信息的定位误差，对GPS定位精度采用正态分布，偏差为5米（浮动汽车数据，FCD的情况），对蜂窝网络定位采用75米的偏差（浮动电话数据，FPD的情况）。这应该会对地图匹配的准确性产生影响，因为位置越准确，地图匹配就越准确。因此，信心值也会受到影响。图10显示了随着信息量的增加，两种不同情况下的准确性和可信度值。很容易看出，使用FCD定位的地图匹配信息的精度和置信度都高于使用FPD定位的信息。对地图匹配精度的影响更大，因为置信值是由几个DQ值组成的，而地图匹配精度的权重只有2/16的计算权重。

系统性能。

扩展实时数据处理系统的一个关键要求是，DQ评估不应影响或仅轻微影响系统性能。因此，我们做了几个实验，比较了有无DQ评估的模拟运行。

图11显示了上一节提出的方案中每个虚拟传感器的平均及时性。时间性是指在传感器中创建一个元素和处理它之间的绝对时间。在这个实验中，我们使用了30s的赢余规模和10s的滑动步骤。图中显示了系统中元素的快速处理时间。时效性的高增长可以用窗口化来解释（窗口中元素的平均时效性为15s）。

我们还对使用DQ框架的DSMS是否比没有DQ框架的DSMS需要明显更多的CPU功率或主内存感兴趣。图12显示，CPU的使用只在系统的初始化阶段比较高。在初始化阶段，本体被加载，DQ信息被一个推理器处理。另外，查询的重写也在这个阶段。在初始化阶段之后，没有发现实质性的差别。

同样的情况也适用于内存消耗（参见图13），在初始化阶段，由于加载本体，内存消耗明显增加。然而，在模拟运行结束时，两种情况下的内存量是差不多的。我们认为，内存消耗的缓慢下降是由Java虚拟机的垃圾回收造成的。

数据质量监控的效果

对质量值的监测 是很重要的，当数据质量不足以获得可靠的结果时，可以采取应对措施。另一方面，系统的性能也必须保持下去。为了了解DQ监测和相应行动的有效性，我们监测了Car-2-X消息的数量（即数据量），并将其汇总为基于时间窗口的数据挖掘的平均值和计数值（参见第5节中的本体论例子，图5）。数据量值很重要，因为它反映了聚合结果的准确性。聚合的数据越多，就越能接近现实，总之，可以更好地估计当前的交通状况。在这个实验中，我们改变了交通模拟中的渗透率（指配备Car-2-X的车辆在整个交通中的百分比）。在模拟运行的前1,000次中，5%的Car-2-X车辆被模拟。在那之后，渗透率下降到1%，这样，在那之后，预计Car-2-X信息会减少

我们定义了一个DQ Bound，其规则是当时间窗口中观察到少于50条Car-2-X信息时，评估为真。

2-X信息的时间窗口中被观察到。当DQ监控器观察到该规则连续五次为 "真 "时，另外，来自手机定位的数据被整合、汇总，并送入数据挖掘。对于手机定位，我们在交通应用中同时模拟了100部手机的位置，并从DSMS中每个手机的两个连续位置计算出手机的速度（详细描述见Geisler等人[2010]）。这些速度值和手机观测值的数量也被用于聚集和挖掘过程。当聚合时间窗口中的Car-2-X信息数量连续5次大于50（即规则被评估为 "假"）时，就不再获取手机数据，同样，只有Car-2-X信息被用于聚合以节省性能和通信成本。图14显示，当手机数据包括在只有少量Car-2-X车辆的时期时，数据挖掘的准确性（真阳性和真阴性的数量除以所有分类元素）略高。另一方面，当有足够多的Car-2-X信息可用时，准确性不受影响。这表明准确度取决于使用的信息量，而不是数据源本身，我们在我们定义的切换规则中找到了一个很好的平衡点

7.2. Case Study Traffic State Estimation

我们在第二个案例研究中证明了我们的框架的有用性和灵活性，它利用了交通状态估计的场景。交通模拟是在一张真实的地图上运行的（杜塞尔多夫市的一部分）。我们通过为第二个场景增加实例来进一步扩展本体。根据排队结束检测方案，我们计算了信息的总体置信度。结果在一个实时的网络应用中被可视化，如图15所示，显示了交通模拟运行期间DQ评估的最重要值。

7.3. Case Study Health Monitoring 

我们将数据质量框架应用于健康监测领域和MAS项目（移动AAL-系统的纳米电子学8）中开发的一个应用。该项目旨在开发一个通信平台和传感器设备来收集病人的生命参数。通过监测病人的健康状况，可以避免危急情况的发生，并且可以进行更加个性化的治疗。

各种生命参数由传感器测量，如光脑图（PPG）、血氧饱和度或心率。(PPG)、氧饱和度或心率。传感器数据被传递到一个主节点，该节点通过蓝牙将数据发送到一个智能手机上。智能手机对数据进行一些预处理，并通过互联网连接将其发送到服务器。在服务器端，数据可以被分析，医疗专家可以更详细地调查关键情况。移动设备和服务器上的软件架构与我们在Quix等人[2013]中描述的健康应用程序的架构类似。由于传感器可能由于病人的移动或传感器的轻微错误位置而不能产生正确的数据，不正确的传感器数据必须被考虑在内。因此，在这种情况下，衡量传感器数据的质量是很重要的。

在本案例研究中，我们将数据质量框架应用于由脉搏血氧仪（一种放在手指上使用红外光来产生PPG的设备）创建的PPG测量。PPG被用来推导其他数值，如血液中的氧饱和度或心率。尽管不同病人的PPG数据存在差异，但PPG应该有一个规则的波形。我们估计数据质量的方法试图测量这种 "规律性"。它计算两个连续传感器测量值的差异。如果在50个元素的窗口上的平均差异很高，那么这表明数据质量低。这个规则可以用一个公式表示如下。

我们整合了5的公差值和0的最小值。为了得到百分比值，我们将结果乘以10并从100中减去。

我们用四个虚拟传感器在我们的框架中实现了这个用例，图16中描述了所附的DQ尺寸。像往常一样，我们需要一个包装器来将输入的数据转换成DSMS能够处理的流元素。仔细看一下公式（3），我们显然需要对输入的数据进行两次窗口处理。首先，我们需要一个窗口来获得两个连续的PPG值并计算它们之间的差异。第二，我们需要一个50个元素的窗口来进行平均计算。第一个传感器，计算PPG差值，是用来实现前面所述的第一次窗口化两个元素，以计算两个连续读数的PPG差值。第二个传感器在技术上只是转发数据，两个DQ维度DQ_PPG_DATAVOLUME和DQ_PPG_DIFF_AVERAGE在此引入。在最后一个传感器中，一致性的计算如公式（3）所定义，并在本体论中定义为语义度量。最终计算一致性所需的第二个50个元素的窗口是利用在本体中定义窗口的功能实现的，用于分析目的（如5.2节所述）。图17描述了本体中窗口的实例化情况。

7.3.1. Results.

我们使用血氧仪设备在大约40s的时间内记录的真实世界数据测试了健康监测方案。在这段时间里，产生了2,990次PPG测量，这导致平均数据率约为每秒100个元素。在测量开始时，带设备的手指是静止的，而在测量结束时（大约2250个元素后），手指是移动的，这应该会导致一致性值不好，因为测量不再像预期的那样有规律。一致性评估的结果显示在图18中。

评估期非常短，但这是一个很好的例子，说明我们的框架能够多快地检测出数据质量的下降（同样也是上升）。我们的框架能够快速检测到数据质量的下降（同样，也是上升）。只需一点边际延迟（这也归因于窗口化），就能检测到不规则性，并且一致性迅速下降。这个用例与之前的交通用例不同，因为我们使用的是真实世界而不是模拟数据。关于噪音和范围，数据因病人而异，因情况而异。实验不能像使用模拟那样被控制。这阻碍了寻找一般的最佳参数和算法，以获得最佳的结果。然而，该框架提供了足够的灵活性，可以尝试不同的方法来分析数据。作为本案例研究的结束，我们已经证明了我们能够使我们的框架适应任意领域，对分析数据质量的变化提供快速的反应时间，并且通过提供两个不同层次的窗口来灵活地实施方案。

8. RELATED WORK

为了有效地管理数据质量，在不同的应用领域已经提出了几个数据质量管理模型。我们在第8.1节中回顾了最重要的模型。然后，第8.2节讨论了在数据流管理系统的背景下为处理数据质量而提出的具体方法

8.1. Data Quality Management Models

数据质量管理模型采用了一般质量管理方法的思想和概念，其中产品、客户和流程是重点。原则上，数据也可以被看作是一种产品[Wang 1998]，其属性可能与其他资源的属性不同，如无形性[Redman 1999]，但同时它们对于依赖它们的企业来说，与其他资源一样具有价值。因此，可以理解的是，全面质量管理等模型已经被用于数据的具体情况。

最早的质量管理方法之一是全面质量管理[Wang 1998]模式。作为全面质量管理的一个竞争或继承模式，六西格玛的概念已经发展起来。它最初是由摩托罗拉公司提出的一个概念，即每分钟只允许一定比例的零件有缺陷，后来在Schroeder等人[2008]中成为企业质量管理策略。这个概念也被应用于数据质量管理。例如，在交通领域，它被用于ROSATTE项目[Sch¨utzle 2009]，用于管理有关道路安全属性的数据质量，如警告标志的位置。在ROSATTE中特别采用了设计、测量、评估、改进、控制(DMAIC)模型，主要作为一种手工方法来实施，其中强调过程改进[Sch¨utzle等人，2010]。

还有一些模型是专门为DQ管理而设计的。Lee等人[2002]提出了AIM质量（AIMQ）方法，它包括一个将确定的DQ维度组织成四个类别的模型和一个测量用户对这些维度的价值并加权的调查问卷。对于数据仓库系统中的DQ管理，Jarke等人[1999]提出了基于目标-问题-指标（GQM）范式的DWQ方法[Basili和Rombach 1988]。在DWQ方法中，数据质量管理被整合到数据仓库架构中，并由元模型描述。质量模型直接与数据仓库的元数据相连。这将质量管理紧密地整合到数据仓库中，但同时也使其具有高度灵活性。Batini等人[2009]分析了文献中的多种数据质量方法，并确定了以下一般流程步骤。

(1) 状态重建。分析应用程序的流程、服务及其成本，也分析数据质量问题。它可以被看作是数据质量管理设计的需求分析。这个阶段的结果是要测量的DQ维度。
(2) 评估/测量。定义行动，以获得确定的数据质量维度的值。在测量步骤中，数值的确定是无偏差的，而在评估步骤中，测量的数值还要与参考值进行比较。
(3) 改进。定义了一个在质量不佳时进行反击的过程。相应的手段可以是过程驱动的，也可以是数据驱动的，描述的是质量的水平。

这也符合Juran描述的质量管理的三个步骤 一般来说：质量计划、质量控制和质量改进[Juran 1993; Godfrey 1999]。此外，Batini和Scannapieca[2006]也将他们的完整数据质量方法学（CDQM）建立在这三个步骤之上。所有上述的方法都有一个关键的缺点。它们都需要 大量的手工劳动，特别是设计、分析和改进任务。这对于数据流环境来说是不可行的，因为在这种环境下，数据会快速流逝，而且很不稳定。分析和改进必须在系统运行时完成。尽管如此，这些经典方法中的一些想法是非常有用的，并且已经在一些项目中得到了认可；因此，这些想法应该被DSMS中的DQ管理所采纳。例如，DWQ项目中元数据驱动的DQ管理方法至少使分析阶段的一部分自动化。我们扩展了这个想法，在我们的方法中也实现了改进阶段的自动化。

8.2. Data Quality Management in DSMS

DSMS可以实现在查询过程中监测系统性能的手段，并在某些质量标准未得到满足时调整系统配置。这通常被归纳为QoS一词。例如，如果系统过载，输出延迟或吞吐量低，DSMS可以通过采样技术放弃图元（例如在Aurora系统[Abadi等人，2003]）。在QStream系统[Schmidt等人，2004]中，为每个输出流定义了两个描述符--内容质量描述符，包括Schmidt[2006]定义的不一致性和信号频率，以及由数据率和延迟值组成的时间质量描述符。质量维度的计算贯穿整个查询过程。查询执行计划中的所有操作者都包括在处理新图元时用于计算每个质量维度的值的函数。在处理链的末端，每个连续查询的结果流的质量值被输出。

在Borealis[Abadi等人，2005]中，Aurora的QoS模型已被改进，不仅对输出，而且对每个中间运营商的QoS进行评级。QoS不仅针对输出，而且针对每个中间运营商。为此，每个元组包括一个具有质量维度的向量，这些维度可以是与内容相关的（例如，一个事件的重要性）或与性能相关的（例如，一个事件到这个操作者的处理时间）。向量可以由查询执行计划中的操作者更新，并提供一个评分功能[Abadi等人，2005]。前面的方法的一个关键限制是，向量中的质量维度对每个流都是一样的，这不允许对流内容进行特定的DQ评级。

为了在属性、元组和窗口层面上实现更细粒度的DQ评级，并包括特定应用的DQ维度，Klein和Lehner[2009]用修改过的操作符扩展了处理和探索流的公共基础设施（PIPES）系统[Kr¨amer和Seeger 2009]。DQ信息因此成为流模式的一部分。Klein和Lehner[2009]根据操作者对流数据的影响区分了四种不同类型的操作者（修改、生成、减少或合并操作者）。数据的变化又会导致属性、元组或窗口的DQ的更新。此外，他们的DQ窗口（评估数据质量的流的部分）的大小是可以根据有趣的因素动态调整的，例如，当流数据中出现有趣的峰值时，窗口的大小会减少。该方法的一个缺点是将DQ特征深度整合到运算器中。操作符的实现必须要有很大的改变，以包括质量信息。

Fiscato等人[2009]将数据质量整合到斯坦福流数据管理器（STREAM）系统[Arasu等人，2003]所定义的流的数据模型中。斯坦福流数据管理器（STREAM）系统[Arasu等人，2003]中定义的数据模型中。他们通过三个固定的DQ维度（权重、召回和效用）扩展了流的定义。使用这个定义，作者将DQ整合到与我们的数据模型相似的数据模型中，但没有提供灵活性。

与这些方法相比，我们的方法为数据流的质量管理提供了更多的灵活性。维度和度量的定义可以很容易地改变或扩展。在我们的方法中，指标的分类分为三类，为定义DQ指标提供了不同的可能性。通过使用SQL或Semantic度量标准，可以实现DQ管理和数据流处理的紧密结合，但是这些度量标准不是固定的，可以通过更新本体中的相应信息而轻松改变。

概率数据流表示一个元组存在的不确定性（元组存在的不确定性）或一个属性具有某个值的不确定性（属性值的不确定性）[Kanagal and Deshpande 2009]。不确定性也被研究用于数据库管理系统[Suciu等人，2011]。在这些文献中，主要讨论了数据流的元组存在的不确定性。为了对属性值的不确定性进行建模，必须为数据流的每个属性引入一个具有相应分布函数的随机变量[Kanagal and Deshpande 2009]。元组存在的不确定性可以用一个二进制随机变量来建模。虽然之前的方法对有离散数据的流假设了可能的流语义，但这种语义对有不确定连续数据的流是无效的。概率数据流（PODS）系统[Tran等人，2010]通过将每个连续值的属性建模为具有相应概率密度函数的连续随机变量来解决这个问题。

元组存在的不确定性或属性值的不确定性也可以在一定程度上被我们的方法处理。我们的方法在某种程度上也可以处理，例如，通过引入代表元组或属性值的不确定性的DQ属性。然而，在概率数据管理系统中考虑到不确定性的查询处理，需要比我们的方法更复杂的查询重写/处理技术。

9. CONCLUSION

我们为DSMS提出了一个灵活的、整体的DQ框架，它是按照DQ管理方法设计的，并展示了它在交通信息系统和健康监测方面的应用。以前的数据流中的DQ管理方法要么集中在与系统相关的方面，要么非常紧密地集成到DSMS中，这阻碍了用新的DQ指标或DQ维度来扩展DQ管理。相比之下，我们的方法是基于在DQ本体中对DQ相关概念的明确定义。此外，DQ概念和DSMS组件之间的关系也在本体论中定义。我们方法的一个关键思想是DSMS中的DQ的三重概念，这使得DQ管理变得灵活和可扩展。首先，基于查询的DQ可以通过将计算DQ值的语句整合到DSMS的查询表达中来测量。我们通过使用查询重写方法来减少对特定DSMS的依赖。查询在部署到DSMS之前被重写以包括DQ功能。其次，基于内容的DQ指的是可以通过语义规则（或函数）使用数据流中包含的数据进行评估的DQ维度。最后，基于应用的DQ提供了最大的灵活性，支持通过任何一种特定应用的方法进行DQ测量。

我们的DQ方法已经适应了DSMS的要求，特别是能够自动调用方法来应对低DQ。同样，我们的方法的灵活性并没有对应该应用于改善DQ的方法种类设置任何限制。在交通信息系统和健康监测的背景下对我们的框架进行的评估显示了其灵活性和有效性。我们的DQ框架在CPU或内存使用方面也没有明显的开销。我们还证明，基于DQ监测，可以实施有效和灵活的控制机制来应对低数据质量值。

未来的工作将涉及流量管理场景中的进一步应用。我们将使用我们的框架来测量交通应用中的DQ，同时改变系统配置。一个有趣的挑战是，如果某些维度的DQ低于所需的阈值，还可以实现DSMS组件（如查询、窗口和采样）的自动适应。