1. 概述
数据模型是数据管理的分析工具和交流的有力手段;同时,还能够很好地保证数据的一致性,是实现商务智能(Business Intelligence)的重要基础。因此建立、管理一个企业级的数据模型,应该遵循标准的命名和设计规范。
文章目录
- 
- [1. 概述](#1. 概述)
 - [2. 数据仓库命名规范](#2. 数据仓库命名规范)
 - 
- [2.1. 命名规范](#2.1. 命名规范)
 - 
- [2.1.1. 表属性规范](#2.1.1. 表属性规范)
 - 
- [2.1.1.1. 表名](#2.1.1.1. 表名)
 - [2.1.1.2. DW事实表表名](#2.1.1.2. DW事实表表名)
 - [2.1.1.3. APP应用层表名](#2.1.1.3. APP应用层表名)
 - [2.1.1.4. DW/DM维度表表名](#2.1.1.4. DW/DM维度表表名)
 - [2.1.1.5. 元数据表名](#2.1.1.5. 元数据表名)
 
 - [2.1.2. 索引](#2.1.2. 索引)
 - 
- [2.1.2.1. 普通索引](#2.1.2.1. 普通索引)
 - [2.1.2.2. 主键索引](#2.1.2.2. 主键索引)
 - [2.1.2.3. 唯一索引](#2.1.2.3. 唯一索引)
 - [2.1.2.4. 外键索引](#2.1.2.4. 外键索引)
 - [2.1.2.5. 函数索引](#2.1.2.5. 函数索引)
 - [2.1.2.6. 簇索引](#2.1.2.6. 簇索引)
 
 - [2.1.3. 视图](#2.1.3. 视图)
 - [2.1.4. 物化视图](#2.1.4. 物化视图)
 - [2.1.5. 存储过程](#2.1.5. 存储过程)
 - [2.1.6. 触发器](#2.1.6. 触发器)
 - [2.1.7. 函数](#2.1.7. 函数)
 - [2.1.8. 数据包](#2.1.8. 数据包)
 - [2.1.9. 序列](#2.1.9. 序列)
 - [2.1.10. 普通变量](#2.1.10. 普通变量)
 - [2.1.11. 游标变量](#2.1.11. 游标变量)
 - [2.1.12. 记录型变量](#2.1.12. 记录型变量)
 - [2.1.13. 表类型变量](#2.1.13. 表类型变量)
 - [2.1.14. 数据库链接](#2.1.14. 数据库链接)
 
 - [2.2. 命名](#2.2. 命名)
 - 
- [2.2.1. 语言](#2.2.1. 语言)
 - [2.2.2. 大小写](#2.2.2. 大小写)
 - [2.2.3. 单词分隔](#2.2.3. 单词分隔)
 - [2.2.4. 保留字](#2.2.4. 保留字)
 - [2.2.5. 命名长度](#2.2.5. 命名长度)
 - [2.2.6. 字段名称](#2.2.6. 字段名称)
 - [2.2.7 命名风格比较](#2.2.7 命名风格比较)
 
 - [2.3. 数据类型](#2.3. 数据类型)
 - 
- [2.3.1. 字符型](#2.3.1. 字符型)
 - [2.3.2. 数字型](#2.3.2. 数字型)
 - [2.3.3. 日期和时间](#2.3.3. 日期和时间)
 - [2.3.4. 大字段](#2.3.4. 大字段)
 - [2.3.5. 唯一键](#2.3.5. 唯一键)
 
 
 - [3. 数仓表命名的分层与后缀规则](#3. 数仓表命名的分层与后缀规则)
 
 
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 - ......
 
 - ETL 
 
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 设计要点
- 前缀代表层级,中间部分代表主题,后缀代表刷新策略或加载方式。
 - 实时表必须有显式标识 (
rt_或_rt),否则容易被误认为批处理表。 - 对于全删全导表,建议用 
_fa(full append)或_full明确风险,提醒使用者数据全覆盖。 - 尽量保证不同层级和刷新策略不混淆,一眼就能看出表的特性。
 
3.5 多系统同名表处理规则
在集团公司或多系统环境中,常常会遇到不同业务系统存在同名表的情况。例如:
- OA 系统 :
emp(员工信息表,OA中用于考勤、人事流程) - ERP 系统 :
emp(员工信息表,ERP中用于薪资、财务成本) - POS 系统 :
emp(员工信息表,POS中用于销售员信息) 
如果不加区分直接同步到 ODS 层,会造成表名冲突和含义混淆。
3.5.1处理原则
- 表名唯一化
在 ODS 层命名时加入系统标识(系统缩写),保证不同系统的同名表在数仓中不会冲突。 - 保持可追溯性
表名应能快速反映来源系统,方便数据溯源和问题排查。 - 贴源设计
ODS 层表结构与源系统一致,尽量减少字段改动,确保原貌。 
3.5.2命名规则
- 
系统缩写:建议统一在企业级数据标准中定义,如:
- OA 系统:
oa - ERP 系统:
erp - POS 系统:
pos - HR 系统:
hr - CRM 系统:
crm 
 - OA 系统:
 - 
表名:与源系统一致(保持贴源原则)
示例
 
| 来源系统 | 源表名 | ODS 表名 | 
|---|---|---|
| OA | emp | ods_oa_emp | 
| ERP | emp | ods_erp_emp | 
| POS | emp | ods_pos_emp | 
设计要点
- 系统缩写应全局唯一,避免缩写重复导致歧义。
 - 如果同一个系统中存在多个子模块(如 ERP 财务、ERP 生产),可以扩展缩写:
- ERP 财务模块:
erp_fin - ERP 生产模块:
erp_mfg 
 - ERP 财务模块:
 - 在元数据管理平台(如 Data Catalog)中登记系统缩写及表名映射关系,方便后续管理。
 - 对于实时同步的同名表,可以在系统缩写后增加 
_rt:ods_oa_emp_rtods_pos_emp_rt