30、数据质量：确保数据库可靠性的关键-优快云博客

本文链接：https://blog.youkuaiyun.com/js777/article/details/149596417

数据质量：确保数据库可靠性的关键

在计算机领域，早在上世纪60年代就有这样一个广为认同的说法：“垃圾进，垃圾出”（GIGO）。在数据库兴起的那些年，这个概念曾一度被淡忘。但如今，随着一些数据仓库的数据量逼近PB级，数据质量再次变得极为重要。

数据质量的重要性

数据质量指的是数据库中的数据要准确、及时，并且在需要时能够获取。数据质量确保了数据的准确性和及时性，而且在数据进入数据库之前确保其质量，要比数据存储之后再去处理容易得多。

我们如此关注数据质量，是因为我们需要确信从数据库中检索到的数据是可靠的。我们的运营和战略决策都基于从数据库中获取的数据，这些决策的质量直接取决于数据的质量。

以SmartMart这样的零售连锁店的服装采购决策为例。采购人员会根据前一年的销售情况和对服装款式的了解，提前9到12个月为冬季假日购物季选择库存商品。他们会查询运营数据库，生成每个款式在各个门店和网络上的销售报告，然后根据销售模式调整订单。但如果销售数据有误，就可能导致为每个门店订购错误的商品。在假日购物季，顾客往往不愿等待商品到货，他们可能会购买其他商品或转向其他零售商，最终导致SmartMart的销售损失。

不准确的数据会给企业带来诸多问题，如因电话号码或电子邮件地址过时无法联系到客户、订单缺失未发货的商品、客户未收到召回通知等。总之，数据出现问题，企业就会受损。而且，数据库应用程序崩溃有时比生成包含不准确结果的报告要好，因为前者能明确知道存在问题，而后者可能没有迹象表明报告无效，从而会继续使用这些错误数据。

识别和处理不完整数据

数据质量问题的一个来源是数据缺失，主要有两种情况：从未录入数据库的数据和不应删除却被删除的数据。
- 缺失行 ：缺失行可能由多种原因导致，常见的是有人使用低级数据操作工具“维护”数据库时，在复制数据或删除行的过程中出现错误。如果缺失行不违反引用完整性约束，就很难检测到。例如，直到客户反馈未收到商品，才会发现订单中缺少某个商品，但很难确定错误发生的位置，可能是商品在从客户计算机传输到供应商计算机时丢失（网络订单）、客服代表未录入商品（电话或邮件订单）、数据库维护人员误删商品等。虽然可以轻松录入缺失的商品并发货给客户，但要防止错误再次发生，就需要找出错误原因并解决。这可能是修复应用程序中的漏洞、制定控制维护语言使用的政策，甚至对数据录入人员进行额外培训，但无法控制互联网上数据包的丢失。
- 缺失列数据 ：SQL基于三值逻辑，数据与搜索条件的逻辑比较结果可以是真、假或不确定。当列包含空值时就会出现不确定情况。有时空值无害，但在某些情况下我们需要这些数据。目前无法区分两种类型的空值，但一些数据库理论家建议数据库管理系统应支持四值逻辑：真、假、可以为空和不可以为空。属于最后一类的空值会导致数据缺失问题。例如，客户表中有客户所在国家的列，如果客户在公司所在国家，该列的空值可能无关紧要，但如果客户在其他国家，该列留空就会导致营销邮件无法投递。通过禁止必须有值的列出现空值，可以相对容易地防止列数据缺失。
- 缺失主键数据 ：具有严格完整性控制的关系数据库会阻止因主键部分为空而导致的数据录入。从数据检索的角度看，这是一个积极的结果，因为它确保了进入数据库的每一条数据都能被检索到。但缺乏主键可能意味着一组重要的数据无法存储在数据库中。例如，当关系中“一”端的实体没有明显的主键属性且未创建任意键时，主键可能由两个或多个列的连接组成。如果员工实体没有员工编号属性，主键可能由姓名和电话号码组成。如果电话号码不可用，由于没有完整的主键，数据就无法录入。解决方法在于数据库设计，对于没有固有主键的“顶级”实体，应赋予任意主键，这些任意键会作为外键的一部分贯穿整个设计，确保所有实体实例都有主键值。

识别和处理不正确的数据

不正确的数据是最难检测和预防的问题类型，通常直到外部人员投诉才会被发现，确定错误发生的原因也同样困难，因为有些问题是独一无二的。
- 错误代码 ：关系数据库大量使用编码数据，代码通过主键 - 外键关系在相关表中定义。例如，我们通常将美国州名存储为双字母缩写，并使用包含缩写和完整州名的表进行验证和输出。但编码是一把双刃剑。一家公司将产品分为不同类别，每个类别用三字母代码表示，代码存储在包含代码和产品类别描述的表中。当公司决定引入新产品时，员工使用的应用程序允许用户自行创建代码并输入描述。为方便用户，用户无需明确输入新代码，应用程序在数据录入时捕获引用完整性检查失败的情况，自动询问用户代码描述并在代码表中创建新行。问题在于，如果用户误输入现有产品的代码，应用程序会将其视为新产品，导致数据库中同一产品可能存在多个代码，使用正确代码搜索时无法检索到包含错误代码的行。解决方法是限制输入新代码的权限，在一些组织中，只有数据库管理员有权修改主代码表。如果需要录入新产品，数据库管理员在文员录入产品数据之前分配并输入代码，应用程序再检索代码列表并提供给数据录入人员。
- 错误计算 ：数据库设计者需要决定是否将计算值包含在数据库中，还是在需要时动态计算。这取决于多种因素，如计算的开销和使用频率。例如，我们通常在订单行项目表中计算并存储行成本：

line_items (order_numb, item_numb, quantity_ordered, line_cost)

行成本通过从商品表中获取每个商品的成本（商品编号是外键）并乘以订购数量来计算。价格查找快速，计算简单。但如果计算行成本的公式有误，订单的总金额通常也会错误。虽然更容易注意到订单总金额错误，但可能需要更多调查才能找到具体错误并追踪其来源。数据库管理系统在修改数据时执行的许多自动计算是通过触发器实现的，触发器是存储在数据库中的小过程，在特定操作发生时触发执行。因此，自动计算中的错误不仅需要检查应用程序，还需要检查所有相关的数据库触发器。不过，一旦识别并纠正了计算中的错误，同样的问题不太可能再次发生。
- 错误录入数据库的数据 ：人类容易出现输入错误，即使有完整性约束，也难以避免简单的拼写错误。例如，用户输入“24 West 325th Street”而不是“325 West 24th Street”，客户就可能收不到订单。邮政编码或邮编中一对字母或数字的换位就可能导致客户无法收到商品。排版错误最难检测，通常直到客户投诉才会发现。修复通常很简单，编辑数据并替换错误值即可。但确定错误发生的原因比查找缺失行的来源更困难，可能只是一次性的打字错误，也可能是底层应用程序代码存在问题。区分打字错误和系统错误的最佳策略是记录错误日志，日志应包括检测到错误的表、行和列、错误报告时间以及录入错误数据的人员。目的不是指责员工，而是查看错误中可能存在的模式。如果同一表的同一列出现多个错误，可能是底层系统问题；如果同一员工出现多个错误，可能需要对该员工进行更多培训；如果错误模式随机，则可能是一次性的排版错误。是否需要对所有数据录入人员进行更多培训，取决于组织和错误对组织的影响。
- 违反业务规则 ：企业通常有一些规则可以融入数据库，以便在数据修改时自动执行。例如，一家图书俱乐部在发货后向客户收费，可能会对客户账户设置限额。订单表包含一个触发器，将新存储订单的金额添加到客户表中客户的欠款总额中。如果客户表没有限制欠款总额列值的约束，客户可能会轻松超出公司允许的欠款余额。虽然可以通过应用程序执行这些约束，但不能保证所有数据修改都通过应用程序进行。在所有可以将业务规则实现为数据库约束的情况下，都应该这样做，这可以减轻应用程序开发人员执行约束的责任，简化应用程序逻辑，并确保约束始终得到执行。

识别和处理难以理解的数据

难以理解的数据是我们无法理解的数据，与不正确的数据不同，这类数据相对容易发现，但找到问题的根源可能和处理不正确的数据一样困难。
- 列中的多个值 ：假设我们使用一个人事数据库，依赖表的结构如下：

Dependents (employee_ID, child_first_name, child_birth_date)

本意是每个员工的每个受抚养人在表中都有一行记录。但当查询员工编号为12的受抚养人时，可能会看到这样的数据：
| Employee_ID | child_first_name | child_birth_date |
| — | — | — |
| 12 | Mary, John, Sam | 1 - 15 - 00 |
显然，这些数据存在问题。将多个值放在同一列中不仅违反了关系数据模型的原则，还无法准确关联数据值。出生日期是适用于第一个、第二个还是第三个受抚养人，或者是否适用于所有三个（可能是三胞胎），仅从数据库中的数据无法确定。字符列特别容易出现多个数据值的问题，尤其是在处理姓名时，因为除了长度限制外，不能对其附加禁止空格或逗号的约束，因为这些字符可能是合法姓名的一部分。解决这类问题的唯一方法是对数据录入人员进行培训，让他们明白多个值意味着多个行。
- 孤立的外键 ：我们对关系数据库进行的许多查询都涉及主键和外键之间的连接。如果删除了对主键的所有外键引用，包含主键的行在连接结果中就不会出现。如果外键引用的主键缺失，包含外键的行在连接结果中也不会出现。前者可能是个问题，而后者总是个问题。例如，数据库中没有订单的客户可能没问题，但无法与客户表连接以提供客户标识的订单会是个大麻烦。关系数据库必须防止这些“孤立的外键”存在于数据库中，解决方案应在定义外键时提供。外键定义可以包含 ON DELETE 子句。

总之，数据质量问题来源广泛，解决方法也多种多样。我们需要识别不同类型的数据质量问题，采取相应的预防和处理措施，以确保数据库的可靠性和企业决策的准确性。

数据质量：确保数据库可靠性的关键（续）

数据质量问题解决策略总结

数据质量保障流程

为了更好地保障数据质量，我们可以构建一个数据质量保障流程，其 mermaid 流程图如下：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px

    A([开始]):::startend --> B(数据录入):::process
    B --> C{数据检查}:::decision
    C -->|完整、正确、可理解| D(数据存储):::process
    C -->|不完整| E(识别缺失类型):::process
    E --> F(分析原因):::process
    F --> G(采取对应措施):::process
    G --> B
    C -->|不正确| H(识别错误类型):::process
    H --> I(分析原因):::process
    I --> J(采取对应措施):::process
    J --> B
    C -->|难以理解| K(识别问题类型):::process
    K --> L(分析原因):::process
    L --> M(采取对应措施):::process
    M --> B
    D --> N(数据使用):::process
    N --> O{是否发现新问题}:::decision
    O -->|是| P(记录问题):::process
    P --> C
    O -->|否| Q([结束]):::startend

这个流程从数据录入开始，首先进行数据检查，判断数据是否完整、正确和可理解。如果数据存在问题，会识别问题类型，分析原因并采取对应措施，然后重新进行数据录入和检查。如果数据合格，则进行存储和使用。在数据使用过程中，若发现新问题，会记录问题并重新回到数据检查环节，形成一个闭环的数据质量保障体系。

数据质量监控与持续改进

除了上述的流程和策略，持续的数据质量监控和改进也是非常重要的。可以定期对数据库中的数据进行抽样检查，统计各类数据质量问题的发生频率和影响程度。例如，每月抽取一定比例的订单数据，检查其中是否存在缺失行、错误计算等问题。根据统计结果，分析哪些问题是频繁出现的，哪些是偶尔发生但影响较大的。

对于频繁出现的问题，可以深入研究其产生的根本原因，可能是业务流程存在缺陷，也可能是数据录入人员对规则不熟悉。针对这些原因，制定长期的改进计划，如优化业务流程、加强人员培训等。对于偶尔发生但影响较大的问题，要及时采取应急措施，避免问题进一步扩大。

同时，随着业务的发展和数据库的变化，数据质量问题也可能会发生变化。因此，要建立一个灵活的反馈机制，让数据使用者能够及时反馈发现的问题。根据这些反馈，及时调整数据质量保障策略和流程，确保数据质量始终处于良好的状态。

总结

数据质量是数据库可靠性的基石，它直接影响着企业的运营和决策。在实际应用中，我们会遇到各种各样的数据质量问题，包括不完整数据、不正确数据和难以理解的数据等。针对这些问题，我们需要采取一系列的识别、处理和预防措施，如合理的数据库设计、严格的权限管理、有效的错误日志记录和用户培训等。同时，构建一个完善的数据质量保障流程，进行持续的数据质量监控和改进，才能确保数据库中的数据准确、及时、完整且可理解，为企业的发展提供有力的支持。通过对数据质量的重视和有效管理，企业能够减少因数据问题带来的损失，提高运营效率和决策的准确性。