本文转载自微信公众号「曾二爷」，作者曾二爷。转载本文请联系曾二爷公众号。
一、什么是建模
人的大脑算力有限，世界又太过于复杂。需要将你的关注点抽象出简单模型，用于问题的研究和解决。
比如数学建模，将关注的问题抽象成数学模型进行解决;比如AAARR增长黑客模型，抽象出用户的5个生命周期进行研究和指导行动。
而数据建模便是将问题域用数据表示出。
二、业务模型
接下来我们以下面的公立校业务场景来进行探讨：
老师创建作业布置到多个班级
班级里的学生做完后提交作业(一个学生只有一个班级)
这里涉四种实体(老师、作业、班级、学生)及四个业务流程(创建作业、布置作业、做作业、交作业)。
三、关系型三范式模型
服务端的同学为了在关系型数据库中满足业务快速增删改查，尽量减少数据冗余，常常采用三范式进行数据建模。
针对上述业务一般会有(老师、作业、班级、学生)四种实体表和(班级-作业、学生-作业)两个关系表。
创建作业这个业务弱化到了作业表中
布置作业体现在班级-作业关系表中
做作业和交作业融合到学生-作业关系表中
这样我们6个表的增删改查就可以实现这个业务。
四、数仓模型
4.1 维度建模
到了数仓我们主要将数据用于分析，一般采用维度建模将三范式模型进行重构。划分维度和事实，建立不同层级的数据，满足多种分析场景。
当我们需要分析的是老师布置作业到班级这个业务过程时，作业-班级就相当于事实表，维度表有班级、作业。
4.2 粒度
业务过程会有不同的粒度，比如学生-作业的粒度就比班级-作业更细。粗粒度的班级-作业能汇总学生-作业的一些信息，比如某份作业某个班级有多少人提交。
一般我们会重点建设各个业务过程的最细粒度的事实表，方便后面的多级粒度的汇总。
4.3 历史与现在
通常来说数仓从业务库同步过来的数据都是当前数据的一个镜像，业务库的模型都是针对于当前业务的，不会保存历史的信息。比如新的学期班级表中的年级属性会变更，业务库就直接进行更改。
到了数仓如果我们要计算历史作业的提交信息，那就得保存学生提交作业的当时他所在的年级。像年级慢慢变化的维度我们称之为缓慢变化维。
处理方式既可以建立一个班级历史信息表，关联的时候带上时间，也可以将年级信息‘退化’到学生-作业的事实表中不再放维度表。
4.4 多事实融合
所谓宽表既可能是多个维度退化到事实表形成的，也可能是多个有关联的事实融合而来。
比如 文中的例子我们可以通过信息的冗余和置空实现一个最极端的宽表：老师-作业-班级-学生
该表记录了所以老师的信息，如果没有创建过作业那其他的信息都为空
如果老师有创建过多个作业那老师的信息冗余存储到每条作业信息
班级和学生信息也全都记录到这个表上，如果没有作业信息，那老师、作业信息都为空，如果有多条作业信息也进行冗余存储
使用的时候就需要按需去重或者过滤空值
这样融合了多个业务流程的明细，可以支撑各种业务的分析，但维护成本、存储成本等都是很高的。
