数据仓库之前：探索“脏数据”

数据清洗（Data cleaning）是对脏数据进行清理。数据清洗的关键步骤是在将数据加载到数据仓库之前，识别数据中的不正确性、不一致性等问题。这里我们列出了五种数据清洗方法的示例。然而，在真实场景中你可能会遇到其他类型的数据错误。

例如：

1. 重复（Duplication）问题
2. 关系（Relationship）问题
3. 不一致（Inconsistent）取值
4. 不正确（Incorrect）取值
5. 空值（Null value）问题

1. 重复（Duplication）问题

当尝试插入一条主键值已存在于表中的记录时，就会出现该错误。必须确保主键的唯一性以避免“重复键值”错误。

检查重复键值记录:

• GROUP BY <<PK attribute>> 按主键分组，把相同主键的行聚成一组。
• COUNT(*) 统计每组的行数。
• HAVING COUNT(*) > 1 只保留行数大于 1的组，也就是重复主键。

主键应全表唯一；若某主键出现多次，必然是重复记录或上游重复插入。该查询直接定位这些“异常主键”，让你能进一步清理或回溯来源。

清理重复记录：

• SELECT DISTINCT * 会对整行做去重（所有列的组合相同才算重复），只保留唯一行。
• 通过 CREATE TABLE ... AS 把去重结果落地为新表。

当“重复”的定义是“整行完全相同”时，这一步直接剔除重复行，保证新表只有唯一记录，方便后续加载数据仓库。

若你的“重复”是指“主键重复，但其它列可能不同”，通常会想保留最新的一条。可用窗口函数（示意）：

2. 关系（Relationship）问题或约束违规（Constraint Violation）

如果插入或更新的数据不遵循已定义的规则（如主键、外键、唯一性或检查约束），就会违反约束。需要根据已定义的约束对数据进行校验，以避免此类错误。

检查无效外键（FK）取值：

• <<table 1>> 是子表，里面的 <<FK>> 应该引用 <<table 2>>（父表）的 <<PK>>。
• 子表中凡是 <<FK>> 不在父表主键集合里的行，就是孤儿记录（外键无效）

数据仓库加载前必须保证参照完整性。该查询能批量找出所有外键在父表不存在的行，避免后续 JOIN 时出现丢匹配或错误聚合。

小提醒（NOT IN 与 NULL）： 若子表 <<FK>> 列里存在 NULL，NOT IN (子查询) 可能因三值逻辑出现意外结果。更稳妥写法是 NOT EXISTS 或 LEFT JOIN ... IS NULL：

解决方法（最简单的做法）：

• 直接删除子表中所有“外键无对应父键”的行。

3. 不一致（Inconsistent）取值

例如：单位、编码或精度不一致，或者两个不同属性之间互相冲突。

检查是否存在不一致取值：

• 按业务规则，“合同开始时间 ≤ 结束时间”。该条件找出开始时间晚于结束时间的行。

若存在不一致取值，解决方法（最简单的做法）：

4. 不正确（Incorrect）取值

不正确取值可能包括：拼写错误、属性值超出正确范围、属性值不合逻辑或数据类型不正确。

检查是否存在不正确取值：

• 距离不可能为负；该条件抓出非法数值。

若存在不正确取值，解决方法（最简单的做法）：

5. 空值（Null Value）问题

以 Uselog 案例为例：

检查 Major 表中是否存在空值：

若存在空值，解决方法（最简单的做法）：