1. 概述

数据模型是数据管理的分析工具和交流的有力手段；同时，还能够很好地保证数据的一致性，是实现商务智能（Business Intelligence）的重要基础。因此建立、管理一个企业级的数据模型，应该遵循标准的命名和设计规范。

---

---

2. 数据仓库命名规范

2.1. 命名规范

2.1.1. 表属性规范

2.1.1.1. 表名

• ODS层表名
  前缀为ODS_应用系统名（缩写）_数据表名。数据表名称必须以有特征含义的单词或缩写组成，中间可以用“_”分割，例如：ODS_FUN_CUSTOMERINFO。表名称不能用双引号包含，表名长度不超过30个字符。如果ODS设计采用贴源设计，数据表名应与源系统一致。
  系统和应用名规则：
  • 核心 COR
  • 对公信贷 CLN
  • 个贷 PLN
  • 基金 FUN
  • 票据 TIC
  • 理财 FIN
  • 报表 RPT
  • ……

2.1.1.2. DW事实表表名

• 前缀为DW_主题名（缩写）_功能描述。数据表名称必须以有特征含义的单词或缩写组成，中间可以用“_”分割，例如：DW_ORD_DETAIL。表名称不能用双引号包含，表名长度不超过30个字符。
  主题名规则：
  • 订单 ORD
  • 营销活动 MKC
  • 贷款 LN
  • 网银 NET
  • 客户 CUS
  • ……
    数据表名规则：
  • 基础表 _BA
  • 日汇总表 _D
  • 月汇总表 _M
  • 历史累计 _H
  • 全量加载 _A
  • 增量加载 _I

2.1.1.3. APP应用层表名

• 前缀为APP_主题名（缩写）_功能描述。数据表名称必须以有特征含义的单词或缩写组成，中间可以用“_”分割，例如：APP_RPT_DEALER_GOODS。表名称不能用双引号包含，表名长度不超过30个字符。
  参考DW层表名称规范。

2.1.1.4. DW/DM维度表表名

• 前缀为D_。数据表名称必须以有特征含义的单词或缩写组成，中间可以用“_”分割，例如：D_ACCOUNT、D_PUB_DATE。表名称不能用双引号包含，表名长度不超过30个字符。
  数据表名规则：
  • 日期维度 D_PUB_DATE
  • 城市 D_CITY

2.1.1.5. 元数据表名

• 前缀为M_应用名（缩写）_功能描述。数据表名称必须以有特征含义的单词或缩写组成，中间可以用“_”分割，例如：M_ETL_TASK。表名称不能用双引号包含，表名长度不超过30个字符。
  应用名规则：
  • ETL ETL
  • 报表 RPT
  • OLAP分析 OLP
  • 源系统 SRC
  • 数据库 DB
  • 软硬件 SHW
  • ……

2.1.2. 索引

2.1.2.1. 普通索引

• 前缀为IDX_。索引名称应是前缀+表名+构成的字段名。如果复合索引的构成字段较多，则只包含第一个字段，并添加序号。表名可以去掉前缀。

2.1.2.2. 主键索引

• 前缀为IDX_PK_。索引名称应是前缀+表名+构成的主键字段名，在创建表时用using index指定主键索引属性。

2.1.2.3. 唯一索引

• 前缀为IDX_UK_。索引名称应是前缀+表名+构成的字段名。

2.1.2.4. 外键索引

• 前缀为IDX_FK_。索引名称应是前缀+表名+构成的外键字段名。

2.1.2.5. 函数索引

• 前缀为IDX_func_。索引名称应是前缀+表名+构成的特征表达字符。

2.1.2.6. 簇索引

• 前缀为IDX_clu_。索引名称应是前缀+表名+构成的簇字段。

2.1.3. 视图

• 前缀为V_。按业务操作命名视图。

2.1.4. 物化视图

• 前缀为MV_。按业务操作命名实体化视图。

2.1.5. 存储过程

• 前缀为SP_。按业务操作命名存储过程。

2.1.6. 触发器

• 前缀为Trig_。触发器名应是前缀+表名+触发器名。

2.1.7. 函数

• 前缀为Func_。按业务操作命名函数。

2.1.8. 数据包

• 前缀为Pkg_。按业务操作集合命名数据包。

2.1.9. 序列

• 前缀为Seq_。按业务属性命名。

2.1.10. 普通变量

• 前缀为Var_。存放字符、数字、日期型变量。

2.1.11. 游标变量

• 前缀为Cur_。存放游标记录集。

2.1.12. 记录型变量

• 前缀为Rec_。存放记录型数据。

2.1.13. 表类型变量

• 前缀为Tab_。存放表类型数据。

2.1.14. 数据库链接

• 前缀为dbl_。表示分布式数据库外部链接关系。

2.2. 命名

2.2.1. 语言

命名应该使用英文单词，避免使用拼音，特别不应该使用拼音简写。命名不允许使用中文或者特殊字符。

2.2.2. 大小写

名称一律小写，以方便不同数据库移植，以及避免程序调用问题。

2.2.3. 单词分隔

命名的各单词之间可以使用下划线进行分隔。

2.2.4. 保留字

命名不允许使用SQL保留字。

2.2.5. 命名长度

表名、字段名、视图名长度应限制在20个字符内(含前缀)。

2.2.6. 字段名称

同一个字段名在一个数据库中只能代表一个意思。不同的表用于相同内容的字段应该采用同样的名称，字段类型定义。

2.2.7 命名风格比较

在数据库及相关系统开发中，常见的命名风格主要有以下三种：

命名风格	格式示例	特点	适用场景	优缺点
蛇形命名法（snake_case）	customer_info, order_detail	全小写单词，中间用下划线分隔	数据库表名、字段名、文件名	优点：可读性强、与SQL关键字区分度高、跨语言兼容好；缺点：名称稍长
驼峰命名法（camelCase / PascalCase）	小驼峰：customerInfo；大驼峰：CustomerInfo	单词间不加分隔符，每个单词首字母大写（小驼峰首个单词小写）	程序变量名、函数名、类名	优点：简洁；缺点：在SQL中可读性差，对大小写敏感的系统易出错
匈牙利命名法（HungarianNotation）	strCustomerName，iOrderCount	前缀表示数据类型或用途（str=字符串，i=整数）	早期Windows编程、部分嵌入式开发	优点：类型信息直观；缺点：冗余、与现代IDE类型推断重复，不适合现代数据库命名

建议

• 数据库表名与字段名：推荐使用蛇形命名法（snake_case），全小写+下划线分隔，保证跨平台可移植性与可读性。
• 程序代码（如存储过程、函数）：可根据语言习惯选择驼峰命名法，但仍建议与数据库命名保持一定一致性。
• 匈牙利命名法：不建议用于现代数据库对象命名，可在少数特殊嵌入式场景保留。

示例：

• 表名（snake_case）：dw_order_detail
• 字段名（snake_case）：customer_id、order_date
• 存储过程（PascalCase）：SP_UpdateCustomerInfo

2.3. 数据类型

2.3.1. 字符型

固定长度的字串类型采用char，长度不固定的字串类型采用varchar。避免在长度不固定的情况下采用char类型。

2.3.2. 数字型

数字型字段尽量采用number类型，要注意精度。

2.3.3. 日期和时间

• 系统时间：由数据库产生的系统时间首选数据库的日期型，如DATE类型。
• 外部时间：由数据导入或外部应用程序产生的日期时间类型采用varchar类型，数据格式采用：YYYYMMDDHH24MISS。

2.3.4. 大字段

如无特别需要，避免使用大字段（blob，clob，long，text，image等）。

2.3.5. 唯一键

对于数字型唯一键值，尽可能用自增产生。

3. 数仓表命名的分层与后缀规则

为了方便在日常开发与运维中快速识别表的用途、刷新频率、加载方式，可以在表名中通过前缀、主题缩写、功能后缀等方式进行标签化命名。

3.1常见规则

类型	前缀	示例	含义
ODS（贴源层）	ods_	ods_fun_customerinfo	源系统原始数据，贴近源结构
DW/DM事实表	dw_ / dm_	dw_ord_detail	存放业务事件明细，如订单、交易等
维度表	d_	d_customer, d_pub_date	存放业务维度信息（客户、日期等）
APP应用层表	app_	app_rpt_dealer_goods	面向业务应用或报表的结果集
全量表	后缀 _a	dw_ord_detail_a	每次全量加载，覆盖写入
全删全导表	后缀 _fa / _full	dw_ord_detail_fa	加载前全量删除再写入（truncate+load）
日增量表	后缀 _d / _i	dw_ord_detail_d	按天增量加载，数据粒度为日
月增量表	后缀 _m	dw_ord_detail_m	按月增量加载，数据粒度为月
历史累积表	后缀 _h	dw_ord_detail_h	保存历史全量数据，带时间版本
实时同步表（Flink/Kafka）	前缀 rt_ / ods_rt_ / dw_rt_	ods_rt_trade_detail	实时数据采集表，由Flink或Kafka流处理写入
快照表	后缀 _snap	dw_account_snap	某时刻的全量快照
临时表	前缀 tmp_	tmp_sales_analysis	任务运行中临时使用
中间结果表	前缀 mid_	mid_sales_summary	数据加工中间结果

---

3.2 推荐命名模板

• 层级前缀：ods / dw / dm / d / app / rt
• 主题缩写：如 ord（订单）、cus（客户）、ln（贷款）
• 功能描述：表的业务含义
• 刷新标识：a（全量）、fa（全删全导）、d（日增量）、m（月增量）、h（历史）、rt（实时）

---

3.2.1 示例

表名	解析
ods_fun_customerinfo	ODS层，基金系统的客户信息，贴源表
dw_ord_detail_a	DW层，订单明细，全量加载
dw_ord_detail_d	DW层，订单明细，日增量加载
dw_ord_detail_h	DW层，订单明细历史累积表
d_customer	维度表，客户维度
rt_trade_detail	实时交易明细表，Flink/Kafka同步

---

3.3设计要点

• 层级前缀：ods / dw / dm / d / app / rt
• 主题缩写：如 ord（订单）、cus（客户）、ln（贷款）
• 功能描述：表的业务含义
• 刷新标识：a（全量）、fa（全删全导）、d（日增量）、m（月增量）、h（历史）、rt（实时）

---

3.3.1示例

表名	解析
ods_fun_customerinfo	ODS层，基金系统的客户信息，贴源表
dw_ord_detail_a	DW层，订单明细，全量加载
dw_ord_detail_d	DW层，订单明细，日增量加载
dw_ord_detail_h	DW层，订单明细历史累积表
d_customer	维度表，客户维度
rt_trade_detail	实时交易明细表，Flink/Kafka同步

---

3.4 设计要点

1. 前缀代表层级，中间部分代表主题，后缀代表刷新策略或加载方式。
2. 实时表必须有显式标识（rt_ 或 _rt），否则容易被误认为批处理表。
3. 对于全删全导表，建议用 _fa（full append）或 _full 明确风险，提醒使用者数据全覆盖。
4. 尽量保证不同层级和刷新策略不混淆，一眼就能看出表的特性。

3.5 多系统同名表处理规则

在集团公司或多系统环境中，常常会遇到不同业务系统存在同名表的情况。例如：

• OA 系统：emp（员工信息表，OA中用于考勤、人事流程）
• ERP 系统：emp（员工信息表，ERP中用于薪资、财务成本）
• POS 系统：emp（员工信息表，POS中用于销售员信息）

如果不加区分直接同步到 ODS 层，会造成表名冲突和含义混淆。

3.5.1处理原则

1. 表名唯一化
   在 ODS 层命名时加入系统标识（系统缩写），保证不同系统的同名表在数仓中不会冲突。
2. 保持可追溯性
   表名应能快速反映来源系统，方便数据溯源和问题排查。
3. 贴源设计
   ODS 层表结构与源系统一致，尽量减少字段改动，确保原貌。

3.5.2命名规则

• 系统缩写：建议统一在企业级数据标准中定义，如：

  • OA 系统：oa
  • ERP 系统：erp
  • POS 系统：pos
  • HR 系统：hr
  • CRM 系统：crm

• 表名：与源系统一致（保持贴源原则）

  示例

来源系统	源表名	ODS 表名
OA	emp	ods_oa_emp
ERP	emp	ods_erp_emp
POS	emp	ods_pos_emp

设计要点

• 系统缩写应全局唯一，避免缩写重复导致歧义。
• 如果同一个系统中存在多个子模块（如 ERP 财务、ERP 生产），可以扩展缩写：
  • ERP 财务模块：erp_fin
  • ERP 生产模块：erp_mfg
• 在元数据管理平台（如 Data Catalog）中登记系统缩写及表名映射关系，方便后续管理。
• 对于实时同步的同名表，可以在系统缩写后增加 _rt：
  • ods_oa_emp_rt
  • ods_pos_emp_rt