数据仓库建表规范.docxVIP

一、命名规范(重中之重)

表命名:

清晰自描述:?表名应清晰反映其内容和用途。

前缀/后缀约定:

分层标识：?明确区分不同数据层。

ods_?/?stg_：操作数据存储层/贴源层/临时层(原始数据或轻度清洗)

dwd_?/?fct_：明细事实层/事实表(业务过程原子事实)

dim_：维度层/维度表(描述性属性)

dws_?/?agg_?/?sum_：汇总层/轻度汇总层(按主题、粒度的聚合)

ads_?/?rpt_?/?dm_：应用层/数据集市层/报表层(面向特定分析或报表的宽表)

tmp_?/?temp_：临时表(明确用于中间计算或临时存储)

主题域标识(可选但推荐)：?在分层标识后或表名前加入业务主题域缩写(e.g.,?dwd_sales_order,?dws_finance_daily_summary)。

格式：

小写字母+下划线(_)分隔单词(推荐，兼容性好)。

避免使用数据库保留字、特殊字符(如?-,?@,?$,空格)。

避免使用复数形式(e.g.,?order?优于?orders)。

保持简洁，但不要过度缩写导致难以理解。如果缩写，确保团队内有统一词典。

字段命名:

清晰自描述:?字段名应清晰表达其含义。

使用完整单词或标准缩写：?优先使用完整单词(e.g.,?customer_id,?order_date)。如需缩写，确保团队内统一(e.g.,?cust_id,?ord_dt)。

避免歧义：?不使用过于泛化的名称(如?id,?name,?value,?date)。

为?id?加上上下文(e.g.,?customer_id,?product_id,?order_id)。

为?name?加上上下文(e.g.,?customer_name,?product_name)。

为?date?加上上下文(e.g.,?order_date,?shipment_date,?effective_date)。

数据类型/业务含义标识(可选但推荐)：

_id：标识主键、外键或唯一标识符。

_code?/?_cd：表示编码字段。

_name?/?_nm：表示名称字段。

_desc：表示描述字段。

_date?/?_dt：表示日期字段(通常到天)。

_datetime?/?_dttm?/?_ts：表示日期时间字段(带时分秒或时间戳)。

_amount?/?_amt：表示金额字段。

_quantity?/?_qty：表示数量字段。

_flag?/?_ind：表示布尔或标志字段(e.g.,?is_active_flag)。

_count?/?_cnt：表示计数字段。

_percent?/?_pct：表示百分比字段。

_key：常用于维度表的自然键或代理键。

统一时态和语态：?尽量使用名词形式，描述“是什么”而非“如何获得”。避免使用?calc_,?derived_?等前缀（业务含义更重要）。

格式：?同表命名，小写+下划线。

二、数据类型规范

精确匹配业务含义：

金额：?DECIMAL(p,s)?(指定精确精度和小数位，e.g.,?DECIMAL(18,2))。

整数数量：?INT?/?BIGINT?(根据范围选择)。

日期：?DATE。

日期时间/时间戳：?TIMESTAMP?/?DATETIME?(根据数据库支持选择，明确是否带时区)。

布尔值：?BOOLEAN?(或使用?TINYINT(1)?/?CHAR(1)?表示?Y/N?/?0/1，需统一)。

短文本/代码：?VARCHAR(n)?(指定足够但不过大的长度)。

长文本/描述：?TEXT?/?VARCHAR(max)?(谨慎使用，避免在事实表或频繁查询的表中滥用)。

GUID/UUID：?CHAR(36)?或数据库特定的UUID类型。

避免不精确类型：

避免使用?FLOAT/DOUBLE?存储金额(存在精度损失风险)。

避免使用过大的?VARCHAR?(e.g.,?VARCHAR(255))存储只有几个字符的代码，浪费空间。

谨慎使用?BLOB/CLOB，通常只应在ODS层存储原始报文等，DWD以上层应解析成结构化字段。

统一标准：?整个仓库对相同业务含义的字段使用相同的数据类型(e.g.,所有?customer_id?都用?BIGINT，所有?order_date?都用?DATE)。

三、表结构设计规范

主键(PrimaryKey-PK):

DWD事实表：?强烈建议定义显式PK。PK通常由业务过程本身的自然键组成(e.g.,?order_id+line_item_id)，或唯一标识该行的事实代理键(SurrogateK