为什么(以及如何)确定数据仓库/ BI数据质量风险

编者按:韦恩Yaddow是一个独立的顾问拥有超过20年的经验主要数据迁移/集成/ ETL测试项目在组织包括摩根大通(J.P. Morgan Chase)、瑞士信贷(Credit Suisse)、标准普尔,AIG,奥本海默基金、IBM和Achieve3000。此外,韦恩告诉IIST(国际软件测试研究所)课程188金宝搏官网登录app数据仓库,ETL,数据集成测试。他继续带领众多ETL测试咨询和培训项目。你可以联系他wyaddow@gmail.com。

介绍数据质量风险评估

数据仓库和商业智能(DWH / BI)与风险项目洗澡——从数据仓库的数据质量在BI报告分析值。如果处理不当,数据质量风险,特别是能让整个项目halt-leaving规划者争夺,赞助商寻找补救措施,和预算消灭。

风险分析的转换风险评估数据成风险决策信息。风险是由两个因素:(1)风险概率和(2)风险影响——影响进度的DWH / BI项目也可以衡量的损失风险。

数据质量风险管理是一个结构化的方法识别、评估和优先级的数据质量风险计划的资源减少,监视和控制不良事件的概率和影响。

用户通常不知道自己想要什么了,直到他们开始看到BI应用程序的早期版本(例如,报告)。这种情况下通常需要BI团队构建数据仓库和应用程序报告之前完全定义和指定。夫妇这一挑战固有的数据质量问题当采购操作系统,可伸缩性方面的数据量,数据刷新频率和潜在的风险是非常真实的。

这个博客轮廓识别和最小化的方法数据质量风险常与DWH / BI项目。解决额外DWH / BI项目风险(包括性能、时间表、缺陷发现在SDLC,等等)也很重要,但超出了这篇文章的范围。

数据质量是一个组织的数据资产的期望状态反映以下属性:

• 清晰的定义与意义
• 正确价值观的来源,在提取,同时加载目标,在分析报告
• 在分析应用程序可以理解的表示格式
• 作用在支持目标的业务流程。

图1说明了主要控制点(测试点)在一个端到端的数据质量审计和报告的过程。

应该尽早并且经常解决数据质量风险

提取、转换和加载(ETL)流程仍是最被低估,under-budgeted大多数BI / DW迭代的一部分。最大的原因的ETL部分项目经常会提出更多的问题比它解决与源数据质量的缺乏了解。数据仓库(测试、ETL测试和BI测试:有什么区别吗?)

以下是常见的概率/数据质量风险几率他们以及他们可能存在影响。清单不打算详尽;请注意我们只显示那些被频繁的BI项目“高”的影响。

数据质量风险	几率	影响	潜在的风险缓解任务
人力资源能力 不够资格所需资源的数据仓库和业务智能知识测试;缺乏技能数据测试的工具、方法和最佳实践。	地中海	高	参与DWH / BI培训资源,招聘员工以DW的经验,合同DWH / BI专业顾问。
主测试计划/策略 主测试计划/策略不存在或者在范围是不够的	地中海	高	的测试策略/主测试计划文档所有项目测试的总体结构和目标,从单元测试到组件系统和性能测试。它涵盖了活动在DWH / BI生命周期和测试人员确定评估标准。
源数据质量受到质疑 数据集成工作可能不符合计划进度,因为质量的源数据是未知的	高	高	正式的早期(即数据分析的源数据。,during requirements gathering) to understand whether data quality meets project needs. Inaccuracies, omissions, cleanliness, and inconsistencies in the source data should be identified and resolved before or during the extract / transform process. 通常,特定数据元素存在于多个源系统。识别各种来源并与用户讨论哪一个是最适用的。 使用商业数据质量工具伴随着咨询和培训。
源数据不完整的历史 所有源数据中不同层次的历史数据	高	高	如果你的业务需求要求四年的历史数据,但最好的,最新的数据只包含一年有消息和其他来源的三年吗?三年将需要从其他数据源,提取可能质量有问题。
源和目标数据地图怀疑 源数据可能不准确映射由于缺乏数据字典和数据模型	地中海	高	数据字典应该开发和维护支持与项目相关的所有数据。质量数据映射文档可能结果。
目标数据错误 只能测试加载数据的一个子集	地中海	高	确保目标数据采样过程是高质量的 )测试工具允许大量的数据覆盖 选择的数据采样方法广泛足以避免丢失的缺陷在源和目标数据 选择一个适当的技术来匹配源和目标数据来确定源和目标是否等于或目标数据已经改变了 验证,ETL过程中不丢失数据或信息。数据仓库必须得到所有相关数据从源程序到目标根据业务规则。
SRC - TRGT端到端测试不协调 贫困或不存在测试源仓库数据流	高	高	这种“审核”必须包括验证的信息在源系统(如电子表格)是准确的,这样有一个高水平的信心,它是可以信任的,当它被加载到仓库。它只组织执行质量检查数据的子集点在仓库可能无法充分保护自己免受时产生的数据质量问题之间交换的信息是所有这些“动态点。”
数据字典和数据模型的不足 数据和信息在仓库和/或集市无法轻易被开发人员和QA	地中海	高	确保准确、数据模型和映射文档的当前文档。 用自动化文档工具 ——创造有意义的数据定义和数据文档描述数据字典 ——创造程序维护文档与源系统的变化 提供培训通过数据管家/ QA团队的主人
过多的数据缺陷 数据缺陷被发现在每个迭代的后期阶段	高	高	确保数据需求完成,数据字典是可用的和电流 概要文件所有数据源和目标后ETL来源 确保数据映射和其他规范文档都保持电流
复杂的数据转换 复杂的数据转换和BI报告	高	高	初期验证表加入复杂性、查询和生成的业务报告 验证和澄清的业务需求,以及早期和仔细的翻译数据的需求 验证的数据字段的数量和可访问性来源 验证reports-get数量的一种将取代现有的报告数量以及有多少新的报告
数据量可伸缩性有疑问 由于需求变更数据量增长	地中海	高	使用工具集数据量估计 考虑技术设计了数据量是由有经验的DBA /数据架构师
数据需求不完整 质量问题由于不清楚或不存在的数据需求文档。	地中海	高	确保变更请求批准后,需求总是更新。 执行验证和澄清的需求,以及早期注意翻译的数据需求
不回归测试自动化 最小的自动化回归测试	地中海	高	没有自动化的回归测试,测试后可以运行构建越来越少部署;手工测试可能会导致更少的测试运行

更多潜在的数据质量风险考虑:

• 遗留数据架构和数据定义工件可能不可用或不完整的援助项目计划。源数据可能不准确映射到遗留系统由于缺乏(或过时的)数据字典。
• 项目团队可能会遇到不兼容的软件188金宝搏官网登录app、硬件和/或过程由于多个操作系统或供应商,或者格式不兼容(数据库管理系统(DBMS)数据库管理系统,数据库管理系统,操作系统,等等)。
• 转换后的数据的完整性和质量可能是由于缺乏企业级数据治理。
• 独立的数据验证,的质量目标系统数据可能不符合部门的标准,因为独立数据验证(例如,QA部门,外包)没有考虑工作范围的一部分。
• 源数据转换是可能的不准确和迁移由于缺乏关键业务主题专家参与需求和业务规则的过程。

常见的条件,导致数据质量风险

当商业智能和分析用户没有看到价值的报告数据仓库,他们要么经历糟糕的数据或糟糕的分析。通常,它的数据。功能性DWH / BI测试经常寻找的“错误”ETL逻辑。这可能是合法的,但是如果变换提取缺陷的来源,他们要将数据转换为有缺陷的目标结果。

大学研究人员发现,数据和信息的数量被公司收购了接近两倍在过去的四年,而估计有10 - 30%的它可以被归类为“质量差”(如不准确、不一致、不格式化的输入不正确)。常见问题与企业的数据有很多,但通常分为以下五个主要方面:

• 数据定义——通常显现通过不一致的定义在一个公司的企业基础设施不支持数据字典。
• 初始数据录入进入公司数据库——由于不正确的值,不适当的培训和/或监测的数据输入,可怜的数据输入模板,可怜的(或不存在)编辑/证明的数据值;等。
• 衰变随着时间的推移变得不准确,导致数据(例如,客户联系信息、资产价值、销售/采购量)。
• 数据移动——不充分或ETL过程设计不良造成的,会导致数据仓库是由比原始遗留不准确的信息来源。
• 数据使用——一个不正确的应用程序的数据对象的具体信息,如电子表格、查询、报告、门户网站,等等。

上述每个条件代表一个潜在的大多数DWH / BI项目数据质量风险。

以下项目任务都要有强大的审查,验证,或与他们相关的验证责任提高数据质量管理通过任何数据仓库项目:

1. 业务需求收集和分析
2. 逻辑数据建模
3. 数据映射
4. 物理建模和实现
5. 提取、转换和加载(ETL)设计
6. 报告和多维数据集设计
7. 项目计划
8. 数据质量管理
9. 测试和验证
10. 数据仓库存档
11. 备份和恢复的数据仓库
12. 变更管理
13. ROI的决心

结束语

数据仓库项目是高度复杂的和固有的风险。这是项目经理的责任导致数据仓库团队识别所有数据质量与特定数据仓库实现相关联的风险。这个过程的目的是记录与项目风险相关的基本信息。

如果项目团队和设计师未能评估质量的源数据,然后他们让整个项目很大的风险。仔细考虑一下这个:如果没有人需要时间来评估所有源数据质量,那么完全有可能,你会购买并安装所有DWH / BI技术,做所有的分析,编写所有的源到目标的代码来填充目标表,并且仍然失败。

(阅读更多数据仓库/ BI测试博客韦恩Yaddow)