📚 课程目录第2章数据源与数据表结构

2. 数据源与数据表结构

信用评分模型的核心燃料是数据。在开始特征提取之前，必须清晰理解数据的来源、类型以及它们在数据库中的组织方式。本章将系统梳理信用评分建模中常见的三大数据源，并详细解析三张核心数据表的结构设计，为后续的SQL特征工程打下坚实基础。

2.1 常见数据源

信用评分模型的数据源通常分为三类：申请数据、行为数据和外部数据。这三类数据在建模中的角色和时效性各有不同。

数据源类型	核心内容	数据特点	建模用途
申请数据	客户在申请时填写的个人信息，如年龄、收入、职业、学历、婚姻状况、居住地址等。	截面数据，申请时点一次性获取；真实性依赖客户自报和风控核验。	构建申请评分卡（Application Scorecard），评估客户初始信用风险。
行为数据	客户在授信后的还款、消费、额度使用、逾期等历史行为记录。	时序数据，随时间动态更新；数据量大，维度丰富，是模型迭代的核心。	构建行为评分卡（Behavior Scorecard）和催收评分卡（Collection Scorecard），监控存量客户风险。
外部数据	来自第三方机构的数据，如人行征信报告、百行征信、多头借贷数据、黑名单、社保公积金等。	补充性强，可验证内部数据；获取成本高，需合规授权。	增强模型区分度，识别欺诈风险，补充客户收入与负债信息。

实践建议：在特征提取时，行为数据通常贡献最大的模型区分能力（IV值最高），但申请数据在冷启动阶段至关重要。外部数据主要用于风险兜底和反欺诈，不宜过度依赖。

2.2 核心表结构设计

为了高效地存储和查询上述数据，数据库通常设计为星型或雪花型结构。以下三张表是信用评分系统中最核心的数据表：客户主表、交易流水表和逾期记录表。

2.2.1 客户主表 (Customer Master Table)

客户主表是数据仓库的维度表，记录每个客户的静态信息和最新状态。每一条记录对应一个唯一客户。

-- 客户主表结构示例
CREATE TABLE customer_master (
    customer_id      VARCHAR(32) PRIMARY KEY,  -- 客户唯一标识
    apply_date       DATE,                     -- 申请日期
    name             VARCHAR(64),              -- 客户姓名
    gender           CHAR(1),                  -- 性别: M/F
    age              INT,                      -- 年龄
    education        VARCHAR(16),              -- 学历
    marital_status   VARCHAR(8),               -- 婚姻状况
    income           DECIMAL(12,2),            -- 月收入
    occupation       VARCHAR(32),              -- 职业
    province         VARCHAR(16),              -- 省份
    city             VARCHAR(32),              -- 城市
    product_type     VARCHAR(16),              -- 申请产品类型
    credit_limit     DECIMAL(12,2),            -- 授信额度
    account_status   VARCHAR(8),               -- 账户状态: 正常/冻结/注销
    create_time      TIMESTAMP,                -- 记录创建时间
    update_time      TIMESTAMP                 -- 记录更新时间
);

2.2.2 交易流水表 (Transaction Table)

交易流水表是事实表，记录客户每一笔资金变动。这是行为数据中最核心、数据量最大的表，也是SQL特征工程的主战场。

-- 交易流水表结构示例
CREATE TABLE transaction_log (
    trans_id         BIGINT PRIMARY KEY,       -- 交易流水号
    customer_id      VARCHAR(32),              -- 客户ID (外键)
    trans_date       DATE,                     -- 交易日期
    trans_time       TIMESTAMP,                -- 交易时间
    trans_type       VARCHAR(16),              -- 交易类型: 消费/还款/取现/退款
    trans_amount     DECIMAL(12,2),            -- 交易金额
    balance_after    DECIMAL(12,2),            -- 交易后余额
    merchant_code    VARCHAR(32),              -- 商户编码
    channel          VARCHAR(16),              -- 渠道: 线上/线下/APP
    is_installment   BOOLEAN,                  -- 是否分期
    installment_term INT,                      -- 分期期数
    create_time      TIMESTAMP                 -- 记录创建时间
);

-- 常用索引建议
CREATE INDEX idx_trans_customer_date ON transaction_log(customer_id, trans_date);
CREATE INDEX idx_trans_date ON transaction_log(trans_date);

2.2.3 逾期记录表 (Overdue Table)

逾期记录表记录客户的历史逾期事件，是定义目标变量（好坏客户）和计算催收特征的关键数据源。

-- 逾期记录表结构示例
CREATE TABLE overdue_record (
    overdue_id       BIGINT PRIMARY KEY,       -- 逾期记录ID
    customer_id      VARCHAR(32),              -- 客户ID (外键)
    due_date         DATE,                     -- 应还款日
    overdue_date     DATE,                     -- 首次逾期日期
    overdue_days     INT,                      -- 逾期天数
    overdue_amount   DECIMAL(12,2),            -- 逾期金额
    repayment_date   DATE,                     -- 结清日期 (NULL表示未结清)
    overdue_status   VARCHAR(8),               -- 逾期状态: 逾期中/已结清/核销
    collection_stage VARCHAR(16),              -- 催收阶段: M1/M2/M3/...
    create_time      TIMESTAMP                 -- 记录创建时间
);

-- 常用索引建议
CREATE INDEX idx_overdue_customer ON overdue_record(customer_id);
CREATE INDEX idx_overdue_date ON overdue_record(overdue_date);

    关键设计原则：
    粒度清晰：客户主表是1条/客户，交易流水表是1条/笔，逾期记录表是1条/逾期事件。
时间戳完备：所有表都包含 create_time 和 update_time，便于数据回溯和增量抽取。
索引策略：交易流水表和逾期记录表必须对 customer_id 和日期字段建立联合索引，这是SQL特征提取性能的保障。

2.3 数据源与核心表的关系架构

下图展示了三类数据源如何映射到三张核心数据表，以及它们在信用评分模型中的流转关系。

2.4 表关联与特征提取基础

在信用评分SQL特征提取中，最核心的关联模式是：以客户主表为驱动表，左连接交易流水表和逾期记录表，并在特定时间窗口内进行聚合。以下是一个典型的特征提取查询骨架：

-- 特征提取基础骨架
SELECT 
    cm.customer_id,
    cm.age,
    cm.income,
    -- 交易行为特征
    COALESCE(SUM(tl.trans_amount), 0) AS total_trans_amount_6m,
    COUNT(tl.trans_id) AS trans_count_6m,
    AVG(tl.trans_amount) AS avg_trans_amount_6m,
    -- 逾期特征
    COUNT(ov.overdue_id) AS overdue_count_12m,
    MAX(ov.overdue_days) AS max_overdue_days_12m
FROM customer_master cm
LEFT JOIN transaction_log tl 
    ON cm.customer_id = tl.customer_id 
    AND tl.trans_date BETWEEN '2023-01-01' AND '2023-06-30'
LEFT JOIN overdue_record ov 
    ON cm.customer_id = ov.customer_id 
    AND ov.overdue_date BETWEEN '2022-07-01' AND '2023-06-30'
GROUP BY cm.customer_id, cm.age, cm.income;

性能警告：在真实生产环境中，交易流水表可能包含数亿条记录。直接对全表进行LEFT JOIN和GROUP BY会导致严重的性能问题。必须通过时间分区裁剪、索引利用和子查询预聚合来优化。这些技巧将在后续章节详细讲解。

2.5 数据质量与一致性检查

在开始特征提取之前，必须对数据源进行质量检查。以下是常见的检查清单：

唯一性检查：客户主表的 customer_id 是否唯一？交易流水表是否存在重复流水号？
空值检查：关键字段（如 income、trans_amount）的空值比例是否在可接受范围内？
时间一致性：交易流水表的 trans_date 是否在合理时间范围内？是否存在未来日期？
外键完整性：交易流水表和逾期记录表中的 customer_id 是否都能在客户主表中找到对应记录？
业务逻辑校验：逾期天数 overdue_days 是否为正数？交易金额 trans_amount 是否大于0？

通过本章的学习，你应该能够清晰地识别信用评分建模的三大数据源，理解三张核心数据表的结构设计意图，并掌握它们之间的关联关系。这是后续进行高效SQL特征提取的前提。