数据建模理论

数据建模理论三种类型

业务模型：业务介绍、流程图、架构图
领域模型：DataVault(OLP)
物理模型: 维度建模、范式建模

---

常见的建模方法

(网上太多不做详情描述)

1. ER模型|范式模型(Immnon,3NF）
   原子性、唯一性、独立性
2. 维度模型(Kimball)
   星型模型、雪花模型、星座模型
3. OLP模型(类似DataVault模型)
   Object指实体、Link关系、Perperty(属性)。OLP不太追求一致性治理，重点强调数据历史性、可塑性、原子性
4. Anchor模型
   对DataVault模型进一步规范、6NF基本变成K-V格式。设计初衷:只适合添加而不是修改。
5. 粒度建模
   有点类似标签体系。

---

数据模型设计原则

模型

公共层逻辑下沉：应用层的通用逻辑下沉到中间层
一致性：设计维度、度量、中间层时，保持口径一致
适当冗余：常见维度属性，冗余到事实表、维表
设置主键：所有表，必须考虑是否设置逻辑主键，理论上所有表都存在逻辑主键
全量改增量：主要针对事实表，大约100E条以上的事实表，设计增量
快慢表：为了查询方便，事实表会冗余多个字段，若为了冗余字段导致调度启动太晚，可以拆分快慢表
多主表拆二级分区：依赖多个主表，且每个主表时间差异太大，可拆二级分区，二级前置节点
频繁变化口径设计视图：经常变化口径，并需要回刷数据的业务中间层，可设计基础中间层+视图业务中间层的方式解决

命名

命名、注解清晰易理解：表命名符合架构规范、表、字段、口径注释清洗易理解。

---

数据架构

1. 数据架构域定义

1. 数据应用：包含研发态的代码包和运行态的部署环境归属的数据架构域(应用owner、代码包、部署计算资源、集群配置)
2. 数据架构域：包含数据架构师(主、备)、上级数据架构域、数据领域负责人、描述、名称
3. 计算源：代码运行物理环境(一般一个代码库对应两个计算源(开发调试环境+生产环境)）
4. 数据单元：实现某一种业务场景的代码集合:包含SQL、PYTHON、Shell、Jar.

2. 分域原则

1. 数据域为逻辑管理架构，与业务域映射，有架构层级支持变更调整
2. 数据应用归属与数据域，按功能模块设计数据应用，需要有归属主体

3. 数据架构师职责

1. 规划和设计本域数据领域模型(概念模型)，基于数据领域模型设计、管控和审核数据应用
2. 推动各数据应用负责人执行落地数据逻辑模型和物理模型(数据资产)
3. 管理、审批、审核所负责数据域的计算源以及物理集群，推荐数据治理工作(数据管理)

4. 数据架构分层划域执行标准
5. 数据能力衡量指标定义

---

架构原则

1.数据架构域与在线应用架构域大部分能够实现映射。
2.数据应用挂在架构域的叶子节点下。
3.数据表名不与架构域及主体耦合。
4.数据应用建议按功能模块拆分。