主题域、概念、逻辑、物理四种模型有什么区别与联系？ 保险金信托与弊端的区别和联系是什么意思

以下文章来源于大数据架构师 ，作者彭文华

傅一平荐语：概念是理解知识的关键，虽然你可能每天都听到主题域、概念、逻辑、物理模型这种数据仓库的名词，虽然你可能也实践过了，但不代表理解了这些概念的本质，理解本质的一个好处就是发现第一性原理，融通很多底层的知识，从而能举一反三，你在一个地方理解的东西可以应用到其他地方去。

孔子就夸颜回：闻一知十，这篇文章对于数据仓库建模概念给出了一些业务解释，有利于你去理解一些本质的东西。

正文开始

彭友萌好，我是你的老彭友。上周，有个彭友给我提了一个问题，说对主题域、概念、逻辑和物理模型不太理解，能不能解释一下。

我趁着周末，简单的整理一下，大家可以参考着看看哈~~~

问题起源

这位朋友是在看这张PPT的时候提出这个问题的：

他对这张片子有两个问题：

1、主题域、概念、逻辑和物理模型的区别与联系是什么；

2、为什么叫组织性数据模型，什么又叫系统级数据模型，而且还得让组织级数据模型指导系统级数据模型？

主题域模型

我们知道数据仓库的定义就是“数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。”

那什么是主题（subject）/主题域？用定义来说，就是：

主题域是一个抽象概念，是在较高层次上将企业信息系统中的数据综合、归类，并进行分析利用的抽象。

简单点用人话说，其实就是要建的表太多了，咱得归归类，要不就乱了。所以很多人一直会有一个很奇怪的问题：主题域到底怎么划分？

只要你你理解了分主题域其实就是我了归类，就知道主题域划分方式其实可以有很多种方法，只要遵循MECE原则即可。

所以你查资料，都会说主题域划分的方法有：

按业务；

按系统；

按部门；

按...

简单来说，就是你想怎么分都可以，只要 Group BY一下就行了。

比如，这是证券行业的：

这是保险行业的：

这是零售行业的：

我喜欢用盖房子做比喻。假如我们现在已经有一块地，要盖一个小区。那么主题域划分就像是在做规划图。咱要建的这个小区，哪里是住宅，哪里是别墅，哪里是幼儿园。

主题域模型就是最高视角的蓝图规划。

概念模型

如果说主题域模型是建小区的规划蓝图，那么概念模型就是某一栋楼的设计图。

主题域模型太粗了，粗到根本没法干活儿。所以我们必须得往下细化一层，把每一个主题里的内容具象化出来。

我之前分享过，建模其实就是在数据世界里抽象真实世界的过程。抽象是不断清晰的，概念模型就是在主题域的基础上再清晰一些。

那么在数据世界抽象真实世界的核心是什么？

三个概念：实体、关系、属性。是不是很熟悉？对，就是数据库原理里的E-R图里的实体、关系。

而概念模型就是某个主题域中，抽象出该主题的所有实体，理清所有实体之间的关系，以及涉及的属性。

在抽象的时候，应该充分考虑共性的实体，设计好其中的关系，尽量规避实体间多对多的情况。

这是FSLDM中，当事人的概念模型。笔记本没装PD，凑合看哈~~

其中，当事人、个人、雇员是实体，两边的是他们的属性。连线则是他们之间的关系（不严谨）。

通过概念模型，我们就能很清晰的看到金融业务最关注“当事人”的那些信息。因为我们在设计概念模型的时候，就是从业务出发，慢慢捋出来的呀。

逻辑模型

逻辑模型应该是我们最熟悉的了。其实就是我们用PowerDesigner、ErWin等工具设计出来的表结构。

具体工作就是按照概念模型里抽象出来的实体、属性以及关系，把每张表都详细设计出来。主键外键是什么，字段名、属性是啥，业务表怎么设计，要不要加关系表、码表等等。

类比建小区，逻辑模型就是设计好每一层的格局，电梯在哪里，楼梯在哪里，一梯几户，每户格局怎么设计，大门朝那开，客厅在哪，厕所在哪，卧室、阳台怎么布局等等。

到这一步，我们所有的建模工作都仍在“纸面”上，还没落地。数据库中一张表都还没有呢。

所以，才有了那句话：“主题域、概念、逻辑模型”是组织级数据模型。

物理模型

物理模型就不用说了，就是在数据库里的一张张物理表结构。到这一步，才算是落地了。

类比建小区，物理模型就是万丈高楼平地起，真正的盖起了一栋栋的楼。

所以，主题域模型是全局规划蓝图，概念模型是局部抽象结果，逻辑模型是详细设计图纸，物理模型是按图建设的一栋栋楼房。

从主题域模型到逻辑模型，是逐步细化的过程；从逻辑模型到物理模型，是设计到实现的过程。

所以才有主题域、概念、逻辑模型是组织级数据模型的说法。至于为什么是组织级数据模型指导系统级模型，有些人会觉得是多此一举。因为很多事时候，我们的工作就是直接建表，压根就没有上面的那么多设计工作。

这个事儿啊，我给你举个例子就知道了。

以FSLDM为例，一共有10个主题域，小3000个实体，一万多个属性。

3000多个实体，10000多个属性啊！如果不加以划分，这将是一个灾难。

你理的清楚吗？？？群里有一个哥们，治理过13000张表，虽败犹荣，我愿称他为神！因为单是面对13000张表，还有勇气去治理，已经是神了。

所以逻辑模型和物理模型必须要在全局的视角下进行设计，而不是反过来一通乱建，然后再回来梳理。这跟整理一团乱麻没啥区别，而且这团乱麻本身还在不断的变化。

而且，在治理的同时，业务还不能停，甚至还要继续发展。葫芦得按下，瓢还不能起来...这不是闹呢么？

散会！