读DAMA数据管理知识体系指南40数据质量概念（下）

1. 数据质量和元数据

1.1. 元数据对于管理数据质量至关重要

• 1.1.1. 元数据定义数据所代表的内容，拥有一个强大的数据定义流程，有助于组织正式确定和记录用于衡量数据质量的标准和要求
  
• 1.1.2. 数据质量是为了满足预期，而元数据是阐明期望的主要手段
  

1.2. 数据的质量取决于它如何满足数据消费者的需求
1.3. 管理良好的元数据还可以支持改进数据质量的工作
1.4. 元数据存储库可以存储数据质量度量的结果，以便在整个组织中共享这些结果，并使数据质量团队就优先级和改进驱动因素达成共识
2. 数据质量ISO标准

2.1. 为了能够以及时和经济高效的方式创建、收集、储存、维护、转移、处理和呈现数据以支持业务流程，既需要了解决定其数据质量的特征，也需要具有能够对数据质量进行测量、管理和报告的能力
2.2. ISO 8000的目的是帮助组织定义什么是符合质量的数据、什么是不符合质量的数据，使他们能够使用标准约束要求符合质量的数据，并检核他们已经收到了符合同一质量标准的数据
2.3. 标准描述数据质量管理的结构和组织

• 2.3.1. 数据质量规划
  
• 2.3.2. 数据质量控制
  
• 2.3.3. 数据质量保证
  
• 2.3.4. 数据质量改进
  

3. 数据质量改进生命周期

3.1. 大多数改进数据质量的方法都是基于物理产品制造过程中的质量改进技术

• 3.1.1. 数据被理解为一系列过程的产物
  

3.2. 创建数据的过程可能由一个步骤（数据收集）或多个步骤组成：数据收集、集成到数据仓库、数据集市聚合等
3.3. 基于科学的方法，戴明环是一个被称为“计划-执行-检查-处理”的问题解决模型

• 3.3.1. 计划(Plan)阶段
  
  
  
  • 3.3.1.1. 数据质量团队评估已知问题的范围、影响和优先级，并评估解决这些问题的备选方案
    
  
  
• 3.3.2. 执行(Do)阶段
  
  
  
  • 3.3.2.1. 数据质量团队负责努力解决引起问题的根本原因，并做出对持续监控数据的计划
    
  
  
• 3.3.3. 检查(Check)阶段
  
  
  
  • 3.3.3.1. 这一阶段包括积极监控按要求测量的数据质量
    
  • 3.3.3.2. 只要数据满足定义的质量阈值，就不需要采取其他行动，这个过程将处于控制之中并能满足商业需求
    
  
  
• 3.3.4. 处理(Act)阶段
  
  
  
  • 3.3.4.1. 这一阶段是指处理和解决新出现的数据质量问题的活动
    
  
  
• 3.3.5. 新周期开始于
  
  
  
  • 3.3.5.1. 现有测量值低于阈值
    
  • 3.3.5.2. 新数据集正在调查中
    
  • 3.3.5.3. 对现有数据集提出新的数据质量要求
    
  • 3.3.5.4. 业务规则、标准或期望变更
    
  
  

3.4. 对于给定的数据集，数据质量管理周期首先确定不符合数据消费者要求的数据，以及阻碍其实现业务目标的数据问题
3.5. 第一次正确获取数据的成本，远比获取错误数据并修复数据的成本要低

• 3.5.1. 在整个数据生命周期中维护高质量数据，比在现有流程中尝试提高质量风险更小，且对组织的影响也要小得多
  
• 3.5.2. 在建立流程或系统时就确立数据质量标准是成熟的数据管理组织的标志之一
  
• 3.5.3. 要做到这一点，需要良好的治理和行为准则以及跨职能的协作
  

4. 数据质量业务规则类型

4.1. 业务规则描述业务应该如何在内部运行，以便成功地与外部世界保持一致
4.2. 常见的业务规则类型

• 4.2.1. 定义一致性
  
  
  
  • 4.2.1.1. 确认对数据定义的理解相同，并在整个组织过程中得到实现和正确使用
    
  • 4.2.1.2. 确认包括对计算字段内任意时间或包含局部约束的算法协议，以及汇总和状态相互依赖规则
    
  
  
• 4.2.2. 数值存在和记录完备性
  
  
  
  • 4.2.2.1. 定义数值缺失的情况是否可接受的规则
    
  
  
• 4.2.3. 格式符合性
  
  
  
  • 4.2.3.1. 按指定模式分配给数据元素的值，如设置电话号码格式的标准
    
  
  
• 4.2.4. 值域匹配性
  
  
  
  • 4.2.4.1. 指定数据元素的赋值须包含在某数据值域的枚举值中
    
  
  
• 4.2.5. 范围一致性
  
  
  
  • 4.2.5.1. 数据元素赋值必须在定义的数字、词典或时间范围内
    
  
  
• 4.2.6. 映射一致性
  
  
  
  • 4.2.6.1. 表示分配给数据元素的值，必须对应于映射到其他等效对应值域中的选择的值
    
  
  
• 4.2.7. 一致性规则
  
  
  
  • 4.2.7.1. 指根据这些属性的实际值，在两个（或多个）属性之间关系的条件判定
    
  
  
• 4.2.8. 准确性验证
  
  
  
  • 4.2.8.1. 将数据值与记录系统或其他验证来源中的相应值进行比较，以验证值是否匹配
    
  
  
• 4.2.9. 唯一性验证
  
  
  
  • 4.2.9.1. 指定哪些实体必须具有唯一表达，以及每个表达的真实世界对象有且仅有一个记录的规则
    
  
  
• 4.2.10. 及时性验证
  
  
  
  • 4.2.10.1. 表明与数据可访问性和可用性预期相关特征的规则
    
  
  

4.3. 聚合检查

• 4.3.1. 验证文件中记录数量的合理性
  
  
  
  • 4.3.1.1. 需要基于一段时间内的统计量，以得到趋势信息
    
  
  
• 4.3.2. 验证从一组交易中计算出的平均金额的合理性
  
  
  
  • 4.3.2.1. 需要建立比较阈值，并基于一段时间内的统计数据
    
  
  
• 4.3.3. 验证指定时间段内交易数量的预期差异
  
  
  
  • 4.3.3.1. 需要基于一段时间内的统计数据，并通过它们来建立阈值
    
  
  

5. 数据质量问题的常见原因

5.1. 从创建到处置，数据质量问题在数据生命周期的任何节点都可能出现
5.2. 通过改进接口设计，将测试数据质量规则作为处理的一部分，关注系统设计中的数据质量，并严格控制自动化过程中的人工干预
5.3. 缺乏领导力导致的问题

• 5.3.1. 许多数据质量问题是由缺乏对高质量数据的组织承诺造成的，而缺乏组织承诺本身就是在治理和管理的形式上缺乏领导力
  
• 5.3.2. 在大多数组织中，数据差异（数据结构、格式和使用值的差异）是一个比简单错误严重的问题，可能是数据集成的主要障碍
  
• 5.3.3. 许多数据治理和信息资产项目仅由合规性驱动，而不是由作为数据资产衍生的潜在价值驱动
  
• 5.3.4. 有效管理数据质量的障碍
  
  
  
  • 5.3.4.1. 领导和员工缺乏意识
    
  • 5.3.4.2. 缺乏治理
    
  • 5.3.4.3. 缺乏领导力和管理能力
    
  • 5.3.4.4. 难以证明改进的合理性
    
  • 5.3.4.5. 测量价值的工具不合适或不起作用
    
  
  

5.4. 数据输入过程引起的问题

• 5.4.1. 数据输入接口问题
  
  
  
  • 5.4.1.1. 设计不当的数据输入接口可能导致数据质量问题
    
  • 5.4.1.2. 如果数据输入接口没有编辑或控件防止不正确的数据被录入系统，则数据处理人可能会采取快捷方式处理数据，如跳过非强制字段和不更新有默认值的字段
    
  
  
• 5.4.2. 列表条目放置
  
  
  
  • 5.4.2.1. 即使是数据输入界面的一个简单小功能，如下拉列表中的值顺序，也可能导致数据输入错误
    
  
  
• 5.4.3. 字段重载
  
  
  
  • 5.4.3.1. 随着时间的推移，有些组织会出于不同的商业目的重复字段，而不是更改数据模型和用户界面
    
  • 5.4.3.2. 会导致字段内数据不一致和混乱
    
  
  
• 5.4.4. 培训问题
  
  
  
  • 5.4.4.1. 即使控制和编辑到位，缺乏过程知识也会导致错误的数据输入
    
  • 5.4.4.2. 如果数据处理人不知道错误数据的影响，或者鼓励数据处理人提高录入效率而忽视录入准确性，则他们可能会根据数据质量以外的驱动因素做出选择
    
  
  
• 5.4.5. 业务流程的变更
  
  
  
  • 5.4.5.1. 业务流程随着时间的推移而变化，在变化过程中引入了新的业务规则和数据质量要求
    
  • 5.4.5.2. 这些业务规则更改并不总能被及时或全面地纳入系统
    
  
  
• 5.4.6. 业务流程执行混乱
  
  
  
  • 5.4.6.1. 通过混乱的流程创建的数据很可能不一致
    
  • 5.4.6.2. 混乱的流程可能是由培训或文档编制问题以及需求的变化导致的
    
  
  

5.5. 数据处理功能引起的问题

• 5.5.1. 有关数据源的错误假设
  
  
  
  • 5.5.1.1. 问题可能是由多种原因导致：错误或变更、系统文档不完整或过时，或知识转移不充分
    
  
  
• 5.5.2. 过时的业务规则
  
  
  
  • 5.5.2.1. 随着时间的推移，业务规则会发生变化，应定期对业务规则进行审查和更新
    
  • 5.5.2.2. 如果没有更新，可能无法识别问题或产生误报（或两者都有）
    
  
  
• 5.5.3. 变更的数据结构
  
  
  
  • 5.5.3.1. 源系统可以在不通知下游消费者（包括人和系统）或没有足够时间让下游消费者响应变更的情况下变更结构
    
  
  

5.6. 系统设计引起的问题

• 5.6.1. 未能执行参照完整性
  
  
  
  • 5.6.1.1. 参照完整性对于确保应用程序或系统级别的高质量数据是必要的
    
  • 5.6.1.2. 如果没有强制执行参照完整性，或者关闭了验证（如为了提高响应时间）​，则有可能出现各种数据质量问题
    

    5.6.1.2.1. 产生破坏唯一性约束的重复数据
    

    5.6.1.2.2. 既可以包含，又可以排除在某些报表中的孤儿数据，导致同样的计算生成多个值
    

    5.6.1.2.3. 由于参照完整性要求已还原或更改，无法升级
    

    5.6.1.2.4. 由于丢失的数据被分配为默认值而导致数据准确性
    

    
    
  
  
• 5.6.2. 未执行唯一性约束
  
  
  
  • 5.6.2.1. 表或文件中的多个数据实例副本预期包含唯一实例
    
  
  
• 5.6.3. 编码不准确和分歧
  
  
  
  • 5.6.3.1. 如果数据映射或格式不正确，或处理数据的规则不准确，处理过的数据就会出现质量问题，如计算错误、数据被链接或分配到不匹配的字段、键或者关系等
    
  
  
• 5.6.4. 数据模型不准确
  
  
  
  • 5.6.4.1. 如果数据模型内的假设没有实际数据的支持，则会出现数据质量问题，包括实际数据超出字段长度导致数据丢失、分配不正确ID或键值等
    
  
  
• 5.6.5. 字段重载
  
  
  
  • 5.6.5.1. 随着时间的推移，为了其他目的重用字段，而不是更改数据模型或代码，可能会导致混淆的值集、不明确的含义，以及潜在的结构问题，如分配错误的键值
    
  
  
• 5.6.6. 时间数据不匹配
  
  
  
  • 5.6.6.1. 在没有统一数据字典的情况下，多个系统可能会采用不同的日期格式或时间，当不同源系统之间的数据同步时，反过来会导致数据不匹配和数据丢失
    
  
  
• 5.6.7. 主数据管理薄弱
  
  
  
  • 5.6.7.1. 不成熟的主数据管理可能为数据选择不可靠的数据源，导致数据质量问题，在数据来源准确的假设被推翻之前很难找到这些问题
    
  
  
• 5.6.8. 数据复制
  
  
  
  • 5.6.8.1. 不必要的数据复制通常是数据管理不善造成的
    
  • 5.6.8.2. 有害的数据复制问题
    

    5.6.8.2.1. 单源-多个本地实例
    

    5.6.8.2.2. 多源-单一本地实例
    

    5.6.8.2.2.1. 具有多个权威来源或记录系统的数据实例
    

    
    
  
  

5.7. 解决问题引起的问题

• 5.7.1. 手动数据修复是直接对数据库中的数据进行更改，而不是通过应用接口或业务处理规则进行更改实现
  
• 5.7.2. 脚本或手动命令通常是仓促编写的，用于在紧急情况下“修复”数据，如蓄意注入坏数据、安全疏忽、内部欺诈或外部数据源引起的业务中断等情况
  
• 5.7.3. 与其他未经测试的代码一样，如果修改需求之外的数据，或没有将补丁传送给受原始问题影响的所有历史数据的下游应用系统等，则极有可能导致更多的错误，并产生更高的风险
  
• 5.7.4. 大多数这样的补丁也都是直接更改数据，而不是保留先前的状态并添加已更正的行
  
• 5.7.5. 可能会引起安全漏洞或者业务中断，最终花费的时间比采用恰当纠正措施需要的时间更长
  
• 5.7.6. 所有的改变都应该通过一个受控的变更管理过程实现
  

6. 数据剖析

6.1. 数据剖析(Data Profiling)是一种用于检查数据和评估质量的数据分析形式
6.2. 数据剖析使用统计技术来发现数据集合的真实结构、内容和质量
6.3. 剖析引擎生成统计信息，分析人员可以使用这些统计信息识别数据内容和结构中的模式
6.4. 包括跨列分析，它可以识别重叠或重复的列，并暴露值的内在依赖关系
6.5. 表间分析探索重叠的值集，并帮助识别外键关系
6.6. 大多数数据分析工具允许深入分析数据，以进行进一步调查
6.7. 剖析通常被作为项目中数据发现的一部分（尤其是数据集成项目）​，或者用于评估待改进的数据的当前状态
6.8. 数据剖析结果可用来识别那些可以提升数据和元数据质量的机会
6.9. 剖析是理解数据的有效方法，但只是提高数据质量的第一步，它使组织能够识别潜在的问题。解决问题还需要其他形式的分析，包括业务流程分析、数据血缘分析和更深入的数据分析，这些分析有助于隔离出问题的根本原因
6.10. 空值数

• 6.10.1. 标识空值存在，并检查是否允许空值
  

6.11. 最大/最小值

• 6.11.1. 识别异常值，如负值
  

6.12. 最大/最小长度

• 6.12.1. 确定具有特定长度要求的字段的异常值或无效值
  

6.13. 单个列值的频率分布

• 6.13.1. 能够评估合理性（如交易的国家代码分布、频繁或不经常发生的值的检查，以及用默认值填充的记录百分比）​
  

6.14. 数据类型和格式

• 6.14.1. 识别不符合格式要求的水平，以及意外格式识别（如小数位数、嵌入空格、样本值）​
  

7. 数据质量和数据处理

7.1. 数据质量改进工作的重点是防止错误，但也可以通过某种形式的数据处理来提升数据质量
7.2. 数据清理

• 7.2.1. 数据清理或数据清洗，可以通过数据转换使其符合数据标准和域规则
  
• 7.2.2. 清理包括检测和纠正数据错误，使数据质量达到可接受的水平
  
• 7.2.3. 在理想情况下，随着时间的推移，数据问题的根本原因已经得到解决，对数据清理的需求应该减少
  
• 7.2.4. 方式
  
  
  
  • 7.2.4.1. 实施控制以防止数据输入错误
    
  • 7.2.4.2. 纠正源系统中的数据
    
  • 7.2.4.3. 改进数据录入的业务流程
    
  
  
• 7.2.5. 通过中游系统做出持续修正是必要的，因为在中游系统中重新处理数据比任何其他替代方案的代价都要小
  

7.3. 数据增强

• 7.3.1. 数据增强或丰富是给数据集添加属性以提高其质量和可用性的过程
  
• 7.3.2. 通过集成组织内部的数据集可以获得一些增强，也可以通过购买外部数据来增强组织数据
  
• 7.3.3. 时间戳
  
  
  
  • 7.3.3.1. 改进数据的一种方法是记录数据项创建、修改或停用的日期和时间，这有助于跟踪历史数据事件
    
  • 7.3.3.2. 如果在数据中发现了问题，时间戳能使分析人员定位到发生问题的时间范围，在根本原因分析中将非常有价值
    
  
  
• 7.3.4. 审计数据
  
  
  
  • 7.3.4.1. 审计可以记录数据血缘，这对于历史跟踪和验证很重要
    
  
  
• 7.3.5. 参考词汇表
  
  
  
  • 7.3.5.1. 在定制化的业务语境中，特定于业务的术语、本体和词汇表增强了数据理解和控制
    
  
  
• 7.3.6. 语境信息
  
  
  
  • 7.3.6.1. 添加如位置、环境或访问方法等上下文语境信息，并标记数据以供审查和分析
    
  
  
• 7.3.7. 地理信息
  
  
  
  • 7.3.7.1. 可以通过地址标准化和地理编码增强地理信息，包括区域编码、市政和街区地图、经纬度对和其他类型的位置数据
    
  
  
• 7.3.8. 人口统计信息
  
  
  
  • 7.3.8.1. 可以通过人口统计信息增强客户数据，如年龄、婚姻状况、性别、收入或民族编码
    
  • 7.3.8.2. 企业实体数据可以与年收入、员工数量、办公空间大小等关联
    
  
  
• 7.3.9. 心理信息
  
  
  
  • 7.3.9.1. 用于按特定行为、习惯或偏好对目标人群进行细分的数据，如产品和品牌偏好、组织成员资格、休闲活动、通勤交通方式、购物时间偏好等
    
  
  
• 7.3.10. 评估信息
  
  
  
  • 7.3.10.1. 针对资产评估、库存和销售数据等使用这种增强方式
    
  
  

7.4. 数据解析和格式化

• 7.4.1. 数据解析是使用预先确定的规则来解释其内容或值的分析过程
  
• 7.4.2. 数据分析人员定义一组模式
  
• 7.4.3. 把这些模式录入用于区分有效和无效的数据值的规则引擎内，规则引擎匹配特定模式触发操作
  
• 7.4.4. 当无效模式被识别出来时，应用程序可以尝试将无效值转换为符合规则的值，或者将数据从某个源模式映射到相应的目标表述来实现标准化
  

7.5. 数据转换与标准化

• 7.5.1. 在正常处理过程中，可以通过触发数据规则将数据转换为目标体系结构可读取的格式
  
• 7.5.2. 可读取并不总是意味着可接受
  
• 7.5.3. 规则直接在数据集成流中创建，或依赖于可选的嵌入式技术，或可从工具中访问的其他技术上进行创建
  
• 7.5.4. 数据转换建立在这些标准化技术基础之上
  
  
  
  • 7.5.4.1. 通过将原始格式和模式中的数据值映射到目标表述形式来指导基于规则的转换
    
  • 7.5.4.2. 模式中经解析的组件将按照知识库中的规则进行重新排列、更正或任何更改
    
  • 7.5.4.3. 事实上，标准化是分析人员或工具供应商经过反复分析语境、语言学，以及公认的最常见的惯用语等，为获取规则而进行的一种特殊的格式转换
    
  
  

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！