5. 响应质量事件 从上面，已经注意到对每一个质量Screen都需要有所应对。可能的选择包括：1）终止处理过程； 2)设置防御性标志挂起进程用于后续的附加操作；3）标记问题内容，继续后续的处理。这三个选项都可能不是的最佳选择。中断处理是一个明显的痛苦的选项，中断之后，我们还不得不进行手工的干预、诊断，选择重新启动、从断点处处理或者完全的结束这次的工作，进行异常恢复。选择挂起也不是一个很好的选择，因为没有人清楚什么时间问题可以被修复，甚至是否可以被修复。一般的推荐，对很小的数据问题，尽量不要使用挂起的策略。第三个选择，标记问题数据继续进行处理往往是比较好的。错误事实表的数据在下面的审计维中会有所讨论。错误的维数据也可以借鉴审计维的方式，同时为了以防万一，对数据丢失或者产生垃圾数据，也可以用域本身对错误进行标记处理。
6. 建立审计维
审计维和其他维类似，在ETL后台处理中与事实表关联。下图是针对Shipment Invoice事实表和与其相关的审计维的例子：
图2: 审计维样例
上图中Shipment是一个典型的事实表，包含一大串的外键用来与维表关联，还有三个用DD标示的退化维和6个数字的域。这是数据仓库维模型设计中是一个典型的结构。
审计维包含事实表创建过程的元数据描述。数据质量系统的设计人员可以选择在错误发生时，保存获得或多或少的元数据记录。用上面的例子说明审计维表的产生产生过程。假如Shipment事实表每天以批操作的方式处理一次。今天运行的非常好，没有任何的错误纪录或标记。在这种情况下，只需要在审计表中生成一条审计纪录。这样，所有的错误信息对每一条事实记录将是相同的，它的作用仅是表明今天的工作一切正常。
如果上面的假设不存在，运行进程或者数据常常发生问题，例如，折扣数据有问题，触发了一个Out-of-Bound错误。就需要在审计维表中用一些信息来记录发生的问题，需要考虑如何对错误条件和版本号选择恰当的值，将错误问题的主外键关系进行恰当的关联。更多的关于这方面的详细信息请参阅《The Data Warehouse ETL Toolkit 2004》。
在完成最终的审计报告时，看看下面的审计报表，会发现一些可爱的地方。如下图：
图3: 利用审计维产生的报表
图中上测的那个报告看似是个正常的报表；但是下面的报表，可以清晰的揭示报告中存在的异常。在有审计维的体系结构中，通过一个简单的命令，这些质量审计报表就可以快速地实现。
7. 应用Six Sigma质量标准 借鉴制造业成功的质量管理实践，这些经验在数据仓库的领域也是非常有用的。在制造商的世界里，6 Sigma质量实践已经在帮助他们取得了具体、明显的质量进步，甚至将缺陷率降低到百万分之3到4的水平。而错误事件主题模型是一个非常好的基础，可以用来才采用6 Sigma标准来指导数据仓库领域的质量的实践。在错误事实主题中记录的所有的错误事件使得我们有机会通过使通过特定的机制对质量问题进行监控、评估，用于未来的改善。
本文中描述的数据质量框架，提供了一种可以以较小的代价，增量的添加到已有的数据仓库和数据集成环境中。一旦错误事件主题模型成功地建立之后，我们可以根据实际的环境确定质量Screen实施进度。需要完成的就是后面两个具体的两个工作：记录每一次发生的问题；决定对特定问题的特定的处理方式。错误Screen的实现并不拘泥于特定的技术，可以嵌入自己的代码中，也可以借助于特定的专业化的ETL 工具。
当然，数据质量管理过程是一个没有终点的过程，也没有统一架构原则。这里提供的是一种针对数据仓库项目可以简单实现的、可扩展的、一种相对比较完善的捕捉数据质量事件，同时对其进行量度和控制的方法。
