建模是在数据世界里抽象真实世界的过程，使用数据来描述真实对象，在抽象中清晰。

建模是宏观数据治理中重要的一环，在火热的数据分析、人工智能、NPS等标签下，数据是最重要的基础。

马上进入国庆假期，借最后时间记录一下建模的四个常见关键词：

业务域、概念模型、逻辑模型、物理模型。

Table of Contents

业务域

业务域即建模中最宏观的概念，也是最开始着手的一步。

如果把建模比作一个地产开发的项目，那么业务域就是如何去划分每个区域的功能。

根据业务/系统/部门等不同的参考标准，把数据按照MECE原则切分，使各个业务域各自穷尽、没有关联。

概念模型

在确定业务域之后，就是概念模型的设计工作。

地产开发项目中，在已划分好的业务域中，设计各个业务域楼盘，制作蓝图。

也就是在业务域中，划分出实体、关系、属性。找到其中的细节，以角色去区别每一个元素，这个过程会很枯燥漫长，对于大项目而言，可能会存在上万的实体。

概念模型并不仅限于一层，可以根据模型的大小、复杂度，再进行细分，从原子到衍生。

在度过了艰难的概念模型后，逻辑模型就逐渐明朗了，这个过程中，也就是抽象到清晰的过程。

还是这个地产项目，到这一层就可以从宏观设计到具体设计，每一个板材、每一个电路。

实际上在这个过程中，就得到了表格和字段。至此整个建模的组织模型完成了，剩下的便是SQL去实现。

真正的地产项目，一定是拔地而起的楼盘才叫竣工。

数仓的从0到1，就在这个阶段完成，把之前的组织模型落地，录入信息，创建表格和ETL。

逻辑到物理的这一步，叫做系统模型。

从表面上看，真正有效的是第四步，很多数仓开发者的工作只是完成物理模型的创建。

但事实上，从现在Google重新进行数据治理的风口证明，前三部的组织模型构建，才是真正有价值有意义的事情。

在没有足够的方法论支撑而建立起的数仓，不能够完全提炼出数据的价值，也不能经得住指标繁衍的冲击。

在大多数企业的数仓中，组织模型从简计划，从短计议，导致数仓仅仅是满足于现有的要求，对后续的维护产生巨大压力和工作量。

当意识到很多项目数仓需要重新建模设计时，也许已经力不从心。