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