一、数据模型概念
数据模型就是数据组织和存储方法，它强调从业务、数据存取和使用角度来合理存储数据。简单来说，数据建模就是搞清楚每个表都有哪些字段、表之间有什么联系，然后根据需要添加字段或度量值、建立关系的过程。
目的：更好的组织和存储数据，以便在性能、成本、效率、质量之间取得平衡。
二、从OLTP和OLAP系统的区别看模型方法论的选择
| 对比属性 | 联机事务处理OLTP （ on-line transaction processing） | 联机分析处理OLAP（On-Line Analytical Processing） |
|---|---|---|
| 主要操作 | 随机读写 | 批量读写 |
| 模型 | 3NF实体关系模型 | 维度建模 |
| 数据表征 | 最新数据状态 | 随时间变化的历史状态 |
| 数据规模 | GB | TB、PB |
三、数据模型建立的过程
- 业务建模是针对公司或者部门级的业务进行全方面的梳理和分解。
- 概念建模是把业务建模的各个业务流程过程抽象出实体和关系（ER）。概念模型关注的是实体（指发生业务关系的对象。）和实体之间的关系，对于实体的属性没有做过多的考虑。
* 针对关键业务环节部分，抽象出实体。
* 确定实体之间的关系，1对1,1对多还是多对多。 - 逻辑模型是对概念模型进行具体的设计，实体的属性，主键，外键等等。
- 物理模型是将逻辑模型具体实施，考虑各种具体的技术实现因素，进行数据仓库体系结构设计，真正实现数据在数据仓库中的存放。
实体建模提示：
把业务抽象归纳出三个部分：
实体：主要指领域模型中特定的概念主体，指发生业务关系的对象。
事件：主要指概念主体之间完成一次业务流程的过程，特指特定的业务过程。
说明：主要是针对实体和事件的特殊说明。
四、应用：
业务、领域建模-->实体关系建模
逻辑建模阶段和物理建模阶段-->范式建模和维度建模
五、典型建模方法
1 范式建模
符合三范式：
第一范式：属性的原子性，列不可再分
第二范式：记录的唯一性，表中要有主键，表中其他字段都完全依赖于主键-->主键约束
第三范式：列不能有冗余，不能包含其他表中存在的字段，不存在传递依赖。-->外键约束
1.1.应用场景
- 业务数据库的表没有遵循3范式
- 有复杂的字段（比如json字段）需要解析
1.2.优点
- 减少数据冗余，避免了数据的不一致，
- 解耦方便维护，更新操作快
- 针对复杂字段的解析和复杂业务的分解，有利于下游直接使用
1.3.缺点：
由于太过规范化而导致用户对数据的理解有一定的难度，需要对业务有很深很细的了解。
2 维度建模
- 维度模型如图所示，主要应用于OLAP 系统中，通常以某一个事实表为中心进行表的组织，主要面向业务，特征是可能存在数据的冗余，但是能方便的得到数据。
- 关系模型虽然冗余少，但是在大规模数据，跨表分析统计查询过程中，会造成多表关联，这会大大降低执行效率。所以通常我们采用维度模型建模，把相关各种表整理成两种：事实表和维度表两种。
2.1 维度建模的三种模型
2.1.1星型模型：事实表周围只有一层维度表
2.1.2.优点
- 能够提升查询效率，因为生成的事实表已经经过预处理，主要的数据都在事实表里面，不用关联多个表就能获取大部分核心信息，方便下游使用
- 可读性比较好，设计维护相对简单
2.1.3.缺点
数据冗余
2.1.2.雪花模型：维度表有多个层级
- 优点：设计方式比较正规，数据冗余少
- 缺点：
* 查询的时候可能需要多表关联，导致查询效率下降，
* 规范化操作在后期维护比较复杂。 - 使用场景：在维度表数据量极大，需要节省存储空间的情况下，或者是业务逻辑比较复杂、必须要体现清晰的层次概念情况下，可以使用雪花型维度。
2.1.3.星座模型：多张事实表
提示：
按照事实表，维表来构建数据仓库，数据集市
2.2 维度表和事实表
2.2.1 维度表
- 维度表：一般是对事实的描述信息。每一张维表对应显示世界中的一个对象或者概念。
- 维度表特征：
- 维度的范围很宽（具有多个属性，多个列）
- 和事实表相比，行数相对少
- 内容相对固定：编码表
- 如商品信息表，每一行表示一种商品的具体特征和概念（小米手机，128G，白色，4999元）
2.2.2 事实表
- 每一个事实表的行包括：具有可加性的数值型的度量值、与维表相连接的外键、通常具有两个和两个以上的外键、外键之间表示维表之间多对多的关系。可统计的
- 特征：
- 非常大
- 内容相对窄（列数少）
- 经常发生变化，每天会新增很多
- 如订单表（小明，小米手机，4999元，优惠券200元，下单时间20200521 09：00）
六、维度建模的主要是4个主要步骤
1、选择业务过程
业务过程是通常表示的是业务执行的活动，与之相关的维度描述和每个业务过程事件关联的描述性环境。通常由某个操作型系统支持，例如：订单系统。业务过程建立或获取关键性能度量。一系列过程产生一系列事实表。
2、声明粒度
粒度传递的是与事实表度量有关的细节级别。精确定义某个事实表的每一行表示什么。对事实表的粒度要达成共识。
3、确认维度
健壮的维度集合来粉饰事实表。维度表示承担每个度量环境中所有可能的单值描述符。
4、确认事实
- 不同粒度的事实必须放在不同的事实表中。事实表的设计完全依赖物理活动，不受最终报表的影响。事实表通过外健关联与之相关的维度。查询操作主要是基于事实表开展计算和聚合。
七.建模的基本原则
1.高内聚、低耦合
主要从数据业务特性和访问特性两个角度来考虑:
将业务相近或者相关、粒度相同的数据设计为一个逻辑或者物理模型；
将高概率同时访问的数据放一起 ，将低概率同时访问的数据分开存储。
2.核心模型与扩展模型分离
核心模型包括的宇段支持常用的核心业务，扩展模型包括的字段支持个性化或少量应用的需要，不要让扩展模型包括的字段过多的入侵核心模型，破坏核心模型的性能及简洁等
3.存储成本与计算性能均衡
在很多时候，设计可能清晰，但存储成本很高，或存储成本很小但计算逻辑复杂，性能差，都需要做一个比较，做到均衡，而非执意孤行。
4.公共逻辑下沉及统一
避免重复计算，需将公共逻辑在底层实现并统一口径
5.数据可回滚
处理逻辑不变，多次执行结果需保持一致。
6.规范性
相同含义字段需在多表中命名一致，表命名需清晰可理解，便于查询及使用。
八.事实表分类
（1）事务型事实表
以每个事务或事件为单位，例如一个销售订单记录，一笔支付记录等，作为事实表里的一行数据。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。
（2）周期型快照事实表
周期型快照事实表中不会保留所有数据，只保留固定时间间隔的数据，以具有规律性的、可预见的时间间隔记录事实。例如每天或每月的总销售金额，或每月的账户余额等。
（3）累积型快照事实表
累积快照事实表用于跟踪业务事实的变化，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点。例如数据仓库中可能需要累积或者存储订单从下单开始，到订单商品被打包、运输、签收等各个业务阶段的时间点数据，来跟踪订单生命周期的进展情况。当这个业务过程进行时，事实表的记录也要不断更新。