一、什么是建模

人的大脑算力有限，世界又太过于复杂。需要将你的关注点抽象出简单模型，用于问题的研究和解决。

比如数学建模，将关注的问题抽象成数学模型进行解决；比如AAARR增长黑客模型，抽象出用户的5个生命周期进行研究和指导行动。

而数据建模便是将问题域用数据表示出。

二、业务模型

接下来我们以下面的公立校业务场景来进行探讨：

1. 老师创建作业布置到多个班级
2. 班级里的学生做完后提交作业（一个学生只有一个班级）

这里涉四种实体（老师、作业、班级、学生）及四个业务流程（创建作业、布置作业、做作业、交作业）。

三、关系型三范式模型

服务端的同学为了在关系型数据库中满足业务快速增删改查，尽量减少数据冗余，常常采用三范式进行数据建模。

针对上述业务一般会有（老师、作业、班级、学生）四种实体表和（班级-作业、学生-作业）两个关系表。

创建作业这个业务弱化到了作业表中
布置作业体现在班级-作业关系表中
做作业和交作业融合到学生-作业关系表中

这样我们6个表的增删改查就可以实现这个业务。

四、数仓模型

4.1 维度建模

到了数仓我们主要将数据用于分析，一般采用维度建模将三范式模型进行重构。划分维度和事实，建立不同层级的数据，满足多种分析场景。

当我们需要分析的是老师布置作业到班级这个业务过程时，作业-班级就相当于事实表，维度表有班级、作业。

4.2 粒度

业务过程会有不同的粒度，比如学生-作业的粒度就比班级-作业更细。粗粒度的班级-作业能汇总学生-作业的一些信息，比如某份作业某个班级有多少人提交。
一般我们会重点建设各个业务过程的最细粒度的事实表，方便后面的多级粒度的汇总。

4.3 历史与现在

通常来说数仓从业务库同步过来的数据都是当前数据的一个镜像，业务库的模型都是针对于当前业务的，不会保存历史的信息。比如新的学期班级表中的年级属性会变更，业务库就直接进行更改。
到了数仓如果我们要计算历史作业的提交信息，那就得保存学生提交作业的当时他所在的年级。像年级慢慢变化的维度我们称之为缓慢变化维。
处理方式既可以建立一个班级历史信息表，关联的时候带上时间，也可以将年级信息‘退化’到学生-作业的事实表中不再放维度表。

4.4 多事实融合

所谓宽表既可能是多个维度退化到事实表形成的，也可能是多个有关联的事实融合而来。
比如 文中的例子我们可以通过信息的冗余和置空实现一个最极端的宽表： 老师-作业-班级-学生

1. 该表记录了所以老师的信息，如果没有创建过作业那其他的信息都为空
2. 如果老师有创建过多个作业那老师的信息冗余存储到每条作业信息
3. 班级和学生信息也全都记录到这个表上，如果没有作业信息，那老师、作业信息都为空，如果有多条作业信息也进行冗余存储
4. 使用的时候就需要按需去重或者过滤空值

这样融合了多个业务流程的明细，可以支撑种业务的分析，但维护成本、存储成本等都是很高的。