3. 数据模型入门

在监管报送项目中，数据模型是连接业务语义与技术实现的“中间语言”。监管机构下发的报送制度、填报说明、校验规则，最终都要落到一张张表、一个个字段和一条条映射关系上。如果缺少清晰的数据模型，业务人员说的“贷款余额”和开发人员理解的“贷款余额”很可能不是同一个东西，报送结果自然难以对齐。本节围绕数据模型的基本概念、三种类型及其在监管报送中的作用展开，帮助大家建立“先建模、后开发、再校验”的工作习惯。

一、核心原理：数据模型是什么，为什么需要分层

数据模型是对现实世界中数据特征及其相互关系的抽象描述。它回答三个问题：有哪些业务对象（实体）、对象有哪些属性（字段）、对象之间如何关联（关系）。在监管报送语境下，数据模型还要额外回答第四个问题：这些对象和属性如何对应到监管报表的指标口径。

之所以要把模型分成概念、逻辑、物理三层，是因为不同角色关注点不同。业务专家关心“贷款”“客户”“担保”这些概念及其边界；数据架构师关心实体如何规范化、主外键如何设计；开发人员关心字段类型、分区策略、存储格式。三层模型就像建筑图纸：概念模型是效果图，逻辑模型是施工图，物理模型是材料清单。缺少任何一层，都会导致沟通断层。

二、三种模型类型及其特征对比

概念模型、逻辑模型、物理模型在抽象层次、受众、稳定性和表达方式上差异明显。下表从六个维度进行对比，便于在实际项目中判断当前应产出哪一层模型。

对比维度	概念模型	逻辑模型	物理模型
抽象层次	最高，面向业务	中等，面向结构	最低，面向实现
主要受众	业务专家、监管对接人	数据架构师、指标管理员	开发工程师、DBA
核心元素	实体、业务关系	实体、属性、主外键、范式	表、字段、类型、索引、分区
是否含技术细节	不含	少量	完整
稳定性	高，变化慢	中，随口径调整	低，随平台演进
典型产物	ER概念图、业务术语表	ER图、数据字典	DDL脚本、映射文档

需要强调的是，三层模型并非严格串行。实际项目中常采用“概念先行、逻辑迭代、物理落地”的节奏，但逻辑模型与物理模型之间往往存在双向反馈：物理实现中发现性能瓶颈，可能反过来调整逻辑模型的冗余设计。

三、方法流程：从监管制度到物理落地的建模路径

下面给出一条可复用的建模流程，适用于EAST、1104、客户风险等常见监管报送场景。

1. 制度解析：提取监管报表中的指标、维度、频度和校验规则，形成指标清单。
2. 概念建模：识别核心业务实体（如客户、账户、交易、担保），明确实体间业务关系，产出概念ER图。
3. 逻辑建模：为实体补充属性，确定主键、外键、规范化程度，形成逻辑数据字典，并与指标口径建立映射。
4. 物理建模：根据目标平台（如Hive、Oracle、GaussDB）确定字段类型、分区键、索引和存储格式，生成DDL。
5. 口径回归：用物理表数据回算监管指标，与制度口径比对，验证模型正确性。

其中第3步到第4步的转换最容易出问题。例如逻辑模型中“客户”与“账户”是一对多关系，物理落地时若把账户信息冗余进客户表，虽然查询变快，但会导致客户属性更新时出现不一致。此时应通过视图或宽表加工层解决，而不是破坏逻辑模型的规范性。

-- 物理模型示例：监管报送客户账户宽表（Hive）
CREATE TABLE rpt_cust_acct_wide (
  cust_id        STRING COMMENT '客户编号',
  cust_name      STRING COMMENT '客户名称',
  acct_no        STRING COMMENT '账号',
  acct_bal       DECIMAL(18,2) COMMENT '账户余额',
  loan_bal       DECIMAL(18,2) COMMENT '贷款余额',
  report_dt      STRING COMMENT '报送日期',
  etl_time       TIMESTAMP COMMENT '加工时间'
)
PARTITIONED BY (dt STRING)
STORED AS ORC;

四、案例与场景：一个贷款余额指标的建模过程

假设监管报表要求报送“对公贷款余额”，业务口径为“报告期末尚未结清的对公贷款本金余额”。建模过程如下：

• 概念层：识别“客户”“贷款合同”“还款计划”三个实体，明确贷款合同属于客户，还款计划属于贷款合同。
• 逻辑层：定义贷款合同实体属性包括合同编号、客户编号、贷款金额、放款日期、到期日、五级分类；确定合同编号为主键，客户编号为外键。
• 物理层：在Hive中建立贷款合同表，按报送日期分区，贷款金额使用DECIMAL类型避免精度丢失。
• 口径映射：“对公贷款余额”= 贷款合同中客户类型为对公且合同状态为未结清的贷款金额之和。

这个案例说明，指标口径不是孤立存在的，它必须挂接到具体实体和属性上。如果概念模型中没有区分“对公”和“对私”，逻辑模型就无法准确表达过滤条件，物理层也就无法生成正确的汇总SQL。

五、常见误区与复盘

在监管报送项目中，数据建模常见的误区有以下几类：

• 跳过概念模型直接建表：导致业务术语不统一，同一指标在不同报表中口径打架。
• 逻辑模型过度规范化：为了追求范式，把监管报表需要的宽表拆得过细，加工链路变长，反而增加出错概率。
• 物理模型硬编码口径：把过滤条件写死在ETL脚本中，监管口径调整时需要全量排查，维护成本极高。
• 模型与指标脱节：模型只描述数据结构，不记录指标映射，导致校验失败时无法快速定位是数据问题还是口径问题。

复盘时可以用一个简单问题检验模型质量：给定任意一个监管指标，能否在5分钟内说清它来自哪张物理表、经过哪些逻辑实体、对应什么业务概念？如果答案是否定的，说明模型分层和映射关系还需要完善。