很多小伙伴要求讲一下数据模型的多种形态。这是一个很重要很重要的问题，我们必须通过实际的案例来说明，在具体展开的时候，本文先从一个宏观视角来解释数据模型为什么那么重要以及它的形态，以及和传统认知中的不同。

商务智能的原子流程在自助商务智能中，《BI 真经》认识到：这是业务人员用业务逻辑常识筛选数据模型后动态分组汇总后再可视化然后做出智慧地选择的过程。

任何一个图表的背后都有这个过程的存在，这个原子过程，这里称为商务智能分析的表查询原子过程，具体分为五步骤：

第一步：局部数据的快速坍缩

这里并没有用传统的 IT 词汇，而是使用了物理学中的词汇。在以标准表格式存在与业务对应的数字化元宇宙中有多个表，它们的可能关系，是一个笛卡尔积。这个笛卡尔积的组合是很巨大的。但对于某个业务主题，往往需要的是几个有关系的表。

表的关系，其本质就是将可能的笛卡尔积的排列组合的数据迅速缩减量级。

因此，我们很快就可以轻松理解这几个词汇：

强关系：一对多关系，可以最快速度来实现笛卡尔积的缩减。弱关系：多对多关系，可以部分缩减笛卡尔积的量级。无关系：表数据以笛卡尔积的量级存在，十分巨大。可以看到，为什么我们提倡使用一对多关系的一种物理本质在于，当业务的构建可以以强关系存在的时候，是可以在每一个分析的原子过程中，以最快的速度来实现数据坍缩，得到要处理的数据子集。

此步骤输出：一个坍缩过后的子数据集，可以理解为一个逻辑表，常常也被成为大平表。

第二步：动态筛选

将已经坍缩好的数据以一个逻辑表的形态给出，动态筛选出要的行的集合。动态性在于这个筛选是在运行时进行的，每次用户都可以指定要筛选的内容，而不必事先告诉任何人。例如：用户不必事先告诉 IT 说要东北区域的零售商类型的交易数据，这种筛选是在运行时做出的。

上一步给出的大平表是进行这个操作的逻辑基础。

此步骤输出：一个被筛选后的大平表。

第三步：选择字段

上一步给出的被筛选后的大平表可能有 N 个列，N 可能是很大的数字。这时候需要将关心的内容，拿出来进行观测，以便得到洞察。

此步骤输出：一个被筛选后被选择了某些字段的大平表。

第四步：分组

按某些字段进行分组。

此步骤输出：一个按某些字段的分组。此时，任何一个分组都对应了多项数据。

第五步：汇总

在上一步的分组中，在每个组为对应的多项数据进行汇总。

此步骤输出：分组汇总表。

数据的列化如果我们把数据理解成一些原子的话，那么这些原子的存在形态应该可以最优化地适配上述五种操作，我们看看这些操作需要的数据状态：

第一步，建立关系按照字段值来对比。

第二步，按照字段值筛选。

第三步，选择字段，因此，每个字段是不同的。

第四步，按字段的内容分组，因此，同一字段的内容可以被分组，该分组要满足 MECE 原则，彼此独立，互不重复。

第五步，按字段分组后的汇总。

这里可以看出，数据的存在形态应该是字段化的，它要满足：

1、字段数应该尽可能少

2、字段之间彼此独立，互不交叉

3、字段内容彼此独立，互不交叉

这就是：数据的列化。

整个流程如果用一个图来表示，流程是这样的：

这是从全局看上去的感受。具体说来，如下：

可以看出，一对多关系，也就是强关系是很特别的存在。

一对多关系由于任何分析涉及的分组汇总表的根本上都要来自原始的数据表，那么，如何将数据元宇宙的数据用最快速度从几百万，几千万，几个亿坍缩成几百行就是关键的关键了，而且需要极度的性能，那么，这个的本质不是靠 CPU 的性能保证的，而是靠数学上的严格的数学逻辑，那就是一对多带来的效果。当然，CPU 之类的硬件提供的物理算力也是有意义的。

实际的复杂在实际的世界中，数据之间有关系，可能有很多关系。但要明白：这并不重要。

关系的真正意义，并不在于它是不是在反应实际的关系，而是在于：

它是否在后续分析时可以利用到一对多的特性来迅速缩减数据规模。

所以，关系的好坏或者结构设计，不是考虑实际有没有关系，而是分析驱动的。

在分析时，如果需要一种结构，那么就应该为这种结构来准备合理的数据坍缩结构设计。

复杂的数据模型如果单纯的表示某些关系，那么数据模型，可以是这样的：

维度表和事实表，分别表示一对多关系中位于一端和位于多端的表。

在学习的初期，我们会好奇的是，数据模型根本无法做成所谓的星型模型。

维度建模维度建模，来自伟大的 Kimball。推荐其书籍《数据仓库工具箱（第三版）》，该书籍系统化地提出了维度建模，以及如何做到大致规范的数据模型。而问题是，在过去刚刚学习数据建模的时候，就发现数据表怎么都不是星型模型，星型模型太理想了。

星型模型是这样的：

我还清楚的记得国内某大厂的高级分析专家在探讨时死扣概念，一定要说明星型模型和雪花模型的差异之类。

然后，事实上更复杂，尤其是对于真正的业务用户，其数据模型复杂度超越 IT 的想象。

业务与 IT 的不同在 IT 构建的数据仓库中，往往可以有主流的大事实表，而对于自助数据建模的业务人员，他们的表有时候更多，而形成的组合更加恐怖。

真实的数据模型来看看来自真实的人力资源领域大型复杂场景的实际样子。

在 Power BI 中，一旦模型十分复杂，系统便不显示，需要手动启动。如下：

没有错，你没有眼花，以上的结构才是真实的数据模型可能的样子。

理论的失效对照传统理论，你会发现，根本无法创建一个星型模型。目前，市面上可以找到的教科书并没有显示这种真实的复杂应该如何面对。

请注意，这里需要强调：

维度建模方法论，本身没有任何问题，而且非常重要。维度建模方法论，由于没有被给出这类复杂案例，而导致很多业务伙伴在做模型的时候根本不知道自己连到哪里是哪里了。这样就会得到一个体验：为什么正确的理论指导自己做得更加懵逼呢。

模型的局部化对于复杂模型，我们只需要考虑一个局部，就可以化解很多问题。可以类比地想象，宇宙很大，地球受到的引力来自的关系几乎是无穷大的。但只考虑地球和太阳这个局部组合的时候，它们有着强关系，且形成稳定的结构。

多事实表两三个事实表，并不算什么，来看看上述模型的局部子模型的多事实表。如下：

这个局部模型强调了一个重要维度对多件事情的影响。

多级连接类似地，还有一些多级连接结构，例如：

对于某种场景的业务，它涉及到这样一个局部主题，那它就是这样的。

环形结构有时候必须考虑一个形成环形的结构，例如：

有些业务的存在，的确需要跨越环形结构进行计算。

多关系结构可能你已经熟悉实线和虚线关系了。那么这个例子更加典型，如下：

这里可能会切换很多计算时使用的关系。

多环形结构某些业务中涉及的相关表要进行多环形结构计算，如下：

如何跨越关系进行计算是真实存在的需要。

DAX 之父的建议DAX 之父曾说过，DAX 的魅力对于业务人员有一种非常重要的体验：把一堆表放到 Power BI 里，连上各种线，总能做出你要的结果。这让人想到，不管是黑猫白猫，什么方法论，只要能你连出来，算出来，就是数据分析的好猫。

DAX 在最初版本设计的时候，就将一对多关系实现为与事实表融为一体的左外连接结构，并体现为扩展表。大家不用理解扩展表，也不用理解左外连接，只需要知道 DAX 关系模型的根基是牢牢地基于一对多存在，坚实高效。

如何精进要理解这么多模型的结构的唯一方法就是：实践。数据建模就像是下棋时候的布局，如果你的布局是合理的，那么，加下来在走棋的时候就会非常得心应手。

推荐参考这里的图书：PowerBI书籍。

总结具有超过一百个数据源的大型真实模型内置于《HRCM Power BI - 员工职业生涯分析》案例，即将推出下载，可以供你参考学习其中的精华，不要错过。