问题起源
这位朋友是在看这张PPT的时候提出这个问题的：
他对这张片子有两个问题：
1、主题域、概念、逻辑和物理模型的区别与联系是什么；
2、为什么叫组织性数据模型，什么又叫系统级数据模型，而且还得让组织级数据模型指导系统级数据模型？
主题域模型
我们知道数据仓库的定义就是“数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。”
那什么是主题（subject）/主题域？用定义来说，就是：
主题域是一个抽象概念，是在较高层次上将企业信息系统中的数据综合、归类，并进行分析利用的抽象。
简单点用人话说，其实就是要建的表太多了，咱得归归类，要不就乱了。所以很多人一直会有一个很奇怪的问题：主题域到底怎么划分？
只要你你理解了分主题域其实就是我了归类，就知道主题域划分方式其实可以有很多种方法，只要遵循MECE原则即可。
所以你查资料，都会说主题域划分的方法有：
- 按业务；
- 按系统；
- 按部门；
- 按...
简单来说，就是你想怎么分都可以，只要 Group BY一下就行了。
比如，这是证券行业的：
这是保险行业的：
这是零售行业的：
我喜欢用盖房子做比喻。假如我们现在已经有一块地，要盖一个小区。那么主题域划分就像是在做规划图。咱要建的这个小区，哪里是住宅，哪里是别墅，哪里是幼儿园。
主题域模型就是最高视角的蓝图规划。
概念模型
如果说主题域模型是建小区的规划蓝图，那么概念模型就是某一栋楼的设计图。主题域模型太粗了，粗到根本没法干活儿。所以我们必须得往下细化一层，把每一个主题里的内容具象化出来。
我之前分享过，建模其实就是在数据世界里抽象真实世界的过程。抽象是不断清晰的，概念模型就是在主题域的基础上再清晰一些。那么在数据世界抽象真实世界的核心是什么？三个概念：实体、关系、属性。是不是很熟悉？对，就是数据库原理里的E-R图里的实体、关系。
而概念模型就是某个主题域中，抽象出该主题的所有实体，理清所有实体之间的关系，以及涉及的属性。
在抽象的时候，应该充分考虑共性的实体，设计好其中的关系，尽量规避实体间多对多的情况。这是FSLDM中，当事人的概念模型。笔记本没装PD，凑合看哈~
其中，当事人、个人、雇员是实体，两边的是他们的属性。连线则是他们之间的关系（不严谨）。通过概念模型，我们就能很清晰的看到金融业务最关注“当事人”的那些信息。因为我们在设计概念模型的时候，就是从业务出发，慢慢捋出来的呀。
逻辑模型
逻辑模型应该是我们最熟悉的了。其实就是我们用PowerDesigner、ErWin等工具设计出来的表结构。
具体工作就是按照概念模型里抽象出来的实体、属性以及关系，把每张表都详细设计出来。主键外键是什么，字段名、属性是啥，业务表怎么设计，要不要加关系表、码表等等。
类比建小区，逻辑模型就是设计好每一层的格局，电梯在哪里，楼梯在哪里，一梯几户，每户格局怎么设计，大门朝那开，客厅在哪，厕所在哪，卧室、阳台怎么布局等等。
到这一步，我们所有的建模工作都仍在“纸面”上，还没落地。数据库中一张表都还没有呢。所以，才有了那句话：“主题域、概念、逻辑模型”是组织级数据模型。
物理模型
物理模型就不用说了，就是在数据库里的一张张物理表结构。到这一步，才算是落地了。
类比建小区，物理模型就是万丈高楼平地起，真正的盖起了一栋栋的楼。
所以，主题域模型是全局规划蓝图，概念模型是局部抽象结果，逻辑模型是详细设计图纸，物理模型是按图建设的一栋栋楼房。
从主题域模型到逻辑模型，是逐步细化的过程；从逻辑模型到物理模型，是设计到实现的过程。所以才有主题域、概念、逻辑模型是组织级数据模型的说法。至于为什么是组织级数据模型指导系统级模型，有些人会觉得是多此一举。因为很多事时候，我们的工作就是直接建表，压根就没有上面的那么多设计工作。这个事儿啊，我给你举个例子就知道了。以FSLDM为例，一共有10个主题域，小3000个实体，一万多个属性。
3000多个实体，10000多个属性啊！如果不加以划分，这将是一个灾难。你理的清楚吗？？？群里有一个哥们，治理过13000张表，虽败犹荣，我愿称他为神！因为单是面对13000张表，还有勇气去治理，已经是神了。
所以逻辑模型和物理模型必须要在全局的视角下进行设计，而不是反过来一通乱建，然后再回来梳理。这跟整理一团乱麻没啥区别，而且这团乱麻本身还在不断的变化。
而且，在治理的同时，业务还不能停，甚至还要继续发展。葫芦得按下，瓢还不能起来...这不是闹呢么？
散会！
