数仓建模理论——高质量数据建模

数据模型的概念和意义 - DIKW

低质量数据模型十宗罪：

1. 没有准确的不过到需求：调研不完备，理解不充分，缺乏沟通，测试不足,etc. 造成后期大量的调整
2. 数据模型不完整：
   a. 设计时对需求把握不准确，缺少相关表，不能覆盖需求。
   b. column限制，表、字段描述信息缺失。
3. 各层模型与其扮演角色不匹配。（概念模型，逻辑模型，物理模型）
4. 数据结构不合理。主键一定不能为空，相同字段在不同表里定义必须一致。
5. 抽象画不够，造成模型不灵活。
6. 没有或者不遵循命名规范。
7. 缺少数据模型的定义和描述。库改了很多轮模型却没有更新过。
8. 数据模型可读性差。建模工具管理模型ER图，数据字典可读性。
9. 元数据与数据不匹配。
10. 数据模型与企业标准不一致。各个项目各自标准没有企业统一规范。

低质量数据模型的影响

1. 大量修改和重做
2. 重复建设
3. 知识丢失，经年累月后没有传承
4. 下游开发困难
5. 成本高
6. 数据质量低下
7. 新业务无法展开

数仓必备技能

1. 对于业务知识的了解， 30%
2. 沟通能力，25%
3. 规范化能力比如文档撰写，13%
   

1. 建模基础 - 实体

通常是名词。“人” 或 “事”的抽象。
实体举例：

• 业务场景：
  实体抽象：
  
  业务中并没有提到POS机，但刷卡消费需要用到POS机，这里就是沟通能力、业务知识、需求挖掘的能力。
• 沟通技巧
  需要有中间品的产出，拿着这个产出于客户讨论。
  Explore: 客户表述业务场景。
  Clarify：用自己的语言澄清表述自己的理解。
  Confirm：客户确认你说的对不对。
  Action：建模
  
  实体的分类方式 —— 5W1H
  
  实体的分类方式——按照含义分类
  
  实体的分类方式——按照Pattern分类
  

2. 建模基础——属性（Attribute）

属性是对实体的描述。
实体对应的是表，属性对应的是列。

属性的一些特性：

1. 强制、可选？
2. 原子、组合？直接、派生？
3. 单值、多值？
4. 可选键？用以唯一确定实例
5. 数据类型是什么？
6. 是否有默认值？
7. 派生属性是如何计算的？加以注释！

3. 域（Domain）

域类型

1. 格式：VARCHAR，INTEGER，…
2. 列表：枚举，GENDER
3. 范围：0 to 150
   好处：
4. 提高数据质量
5. 使数据模型更易于理解和沟通
6. 标准化，提高建模效率

---

NULL值的处理

NULL的含义：

1. 真未知
2. 尚未知
3. 不适用
   隐患：
4. 数学运算：结果都是NULL
5. Where子句：将不包含条件为NULL的数据。如需加
   where field = xxx or field is null
6. Join：NULL不能和NULL join，使用coalesce函数将NULL转换成其他字符如NA
from a join b on coalesce(a.id,'NA') = coalesce(b.id,'NA')
7. 聚合函数会受影响
8. 子查询：子查询中not in存在NULL可能导致无返回结果

原则及方法：
针对不同需求对NULL进行不同的处理。
9. 根据查询的需求
10. 根据数据的本质
11. 默认值能否代替NULL？如何代替？提醒开发者注意！

---

规范化——范式

减少冗余：同一含义的数据只存一份
“Each non-primary key value MUSt be dependent on the key(1NF), the whole key(2NF), and nothing but hte key(3NF)”
“每一个非键值属性必须依赖于键，依赖于整个键而不是键的一部分，并且不依赖于其他非键属性”

第一范式：原子性，没有重复列，列不可再分，也没有重复行。

1. 数据规范成二维表格
2. 确保每一列表达的统一含义的数据
3. 去掉多值属性，拆分多列
4. 去掉重复组，挪到新表中去
5. 确定主键

第二范式：非主键属性依赖于整个键，而不是其中一部分

1. 首先满足第一范式
2. 如果非主键属性只依赖于主键的一部分，则需要移出创建的新表
3. 如果主键只有一个属性，不需要考虑第二范式

第三范式：

1. 首先满足第二范式
2. 如果非主键属性还依赖其他非主属性，则需要移出创建新表

数据建模基础 命名规范

共通的要求

1. 清晰：表达的含义要清晰
2. 别太复杂：很想说简单，但有的时候很难简单
3. 可共享：希望放眼整个企业，至少也是当下的系统
4. 基于经验可识别：一些企业习惯的共识，不要试图改变
5. 命名风格一致性：同一术语在不同环境中保持统一含义，相同环境下保持统一风格。
6. 尽量英文。
   
   

逻辑模型Tips

物理模型Tips

缩写技巧

哪些对象需要命名

表的命名规范

主题域

数仓中可能有成百上千的表，怎么分组合适呢？
把相同特征的放在一起。
为了逻辑更清楚，把差不多的放一块。
没有金科玉律。

分类办法

1. 借鉴成熟的模型
   

2. 归纳当前模型

   • 业务角度
   • 应用角度
   • 层次角度

归纳当前模型

通用功能调研

逻辑模型Check List

每一个需求都要有对应的模型变更
需求里没有的不要过度设计，为了增加弹性而增加的工作量需要与客户沟通


概念模型通常会有几个大方向的图，用于与客户沟通别跑偏。
逻辑模型中遇到不符合概念模型的细节一定要再次与客户沟通！说起来容易，做起来难。

物理模型 建模

部分资料建议：逻辑模型做规范化设计，物理模型做逆规范化设计。（容易引起在维护中只改物理模型，就不管逻辑模型了）
个人建议：物理模型与逻辑模型完全保持一致。



逆规范化空间换时间，权衡利弊。


质量问题分清主次，哪些能改哪些不能，不能搞定的反馈给上游（影响、危害）。