表命名规范

普通维度逻辑表：{projectname}.dim{业务/pub}{维度定义}[{自定义命名标签}]，其中的pub与具体业务无关，各个业务部都可以共用，例如时间维度

层级维度逻辑表：{projectname}.dim{业务/pub}{维度定义}[{自定义命名标签}]_lvl{n}，例如，地区维度分为省、市、区层次

设计原则

一致性维度规范
公共层的维度表中相同维度属性在不同物理表中的字段名称、数据类型、数据内容必须保持一致。除了以下情况：
在不同的实际物理表中，如果由于维度角色的差异，需要使用其他的名称，其他名称也必须是规范的维度属性的别名。例如，定义一个标准的会员ID时，如果在一个表中，分别要表示买家ID，卖家ID，那么设计规范阶段就预先对会员ID分别定义买家ID和卖家ID
如果由于历史原因，在暂时不一致的情况下，必须在规范的维度定义一个标准维度属性，不同的物理名也必须是来自标准维度属性的别名

组合原则
将维度所描述业务相关性强的字段在一个物理维表实现。相关性强是指经常需要一起查询或进行报表展现、两个维度属性间是否存在天然的关系等。例如，商品基本属性和所属品牌
无相关性的维度可以适当考虑杂项维度（例如交易），可以构建一个交易杂项维度收集交易的特殊标记属性、业务分类等信息。也可以将杂项维度退化在事实表中处理，不过容易造成事实表相对庞大，加工处理较为复杂
所谓的行为维度是经过汇总计算的指标，在下游的应用使用时将其当维度处理。如果有需要，度量指标可以作为行为维度冗余到维度表中

拆分
对于维度属性过多，涉及源较多的维度表（例如会员表），可以做适当拆分：
拆分为核心表和扩展表。核心表相对字段较少，刷新产出时间较早，优先使用。扩展表字段较多，且可以冗余核心表部分字段，刷新产出时间较晚，适合数据分析人员使用
根据维度属性的业务不相关性，将相关度不大的维度属性拆分为多个物理表存储

冗余
数据记录数较大的维度表（例如商品表），可以适当冗余一些子集合，以减少下游扫描数据量：
可以根据当天是否有行为，产出一个有活跃行为的相关维表，以减少应用的数据扫描量
可根据所属业务扫描数据范围大小的不同，进行适当子集合冗余

尽可能生成丰富的维度属性
例如电商公司的商品维度可能有近百个维度属性，为下游的数据统计、分析、探查提供了良好的基础

尽可能多的给出包含一些富有意义的文字性描述
属性不应该是编码，而应该是真正的文字。在维度建模中，通常是编码和文字同时存在，例如商品维度中的商品ID和商品标题、类目ID和类目名称等。ID通常用于不同表之间的关联，而名称通常用于报表标签

区分数值型属性和事实
数值型字段是作为事实还是维度属性，可以根据字段的常用用途区分。例如，若用于查询约束条件或分组统计，则是作为维度属性；若用于参与度量的计算，则是作为事实

尽量沉淀出通用的维度属性
通过逻辑处理得到维度属性
通过多表关联得到维度属性
通过单表的不同字段混合处理得到维度属性
通过对单表的某个字段进行解析得到维度属性

数据存储及生命周期管理规范

CDM公共维度层的表的类型为维度表，存储方式为按天分区。
模型设计者根据自身业务需求设置表的生命周期管理。您可依据3个月内的最大需要访问的跨度设置保留策略，具体计算方式如下：

  • 当3个月内的最大访问跨度小于或等于4天时，建议将保留天数设为7天。
  • 当3个月内的最大访问跨度小于或等于12天时，建议将保留天数设为15天。
  • 当3个月内的最大访问跨度小于或等于30天时， 建议将保留天数设为33天。
  • 当3个月内的最大访问跨度小于或等于90天时，建议将保留天数设为93天。
  • 当3个月内的最大访问跨度小于或等于180天时， 建议将保留天数设为183天。
  • 当3个月内的最大访问跨度小于或等于365天时，建议将保留天数设为368天。