产品这是彭文华的第175篇原创
我现在是真的认识到：一个好问题，胜过100篇回答。因为一个问题产生的原因，是因为他在理解事情的时候，对不上号，顺不起来啊。而为什么会产生问题，本身就是一个问题。比如这个：
为啥会有这个问题？
乍一眼看上去，这哥们是不是干活干傻了？BI（商务智能）的概念里本来就包含数据仓库的，BI的建模和数仓的建模有啥区别？不是一个东西么？你莫不是新新新新新新来的吧？嗯，没错，BI的确包含数仓，但是BI产品就不含数仓了。数仓负责建模，BI产品则提供固定报表、多维分析、驾驶舱等应用。我15年前刚工作的时候，就是这个逻辑了。那时候的BI产品，除了数据库，其他的功能都自带的，连ETL工具都自带。
不过那时候数据仓库的产品不多，当时如日中天的是Teradata，巨贵无比。反而是BI产品大行其道，为了抢占市场，各大BI厂商不断增强自己的能力，ETL、任务调度、建Cube、做报表、数据展示能做的都做了。所以在绝大多数BI产品中，都设置了“主题建模”的功能，尽量减少数仓层面的依赖。15年后的今天，得益于开源理念，很多数据仓库产品不但免费，功能也不断强大。比如咱中国人开发并开源的Apache顶级项目-Kylin，就自带Cube。这个时候你就会发现，原来的Teradata就慢慢的没落了。
所以，如果你现在去做BI项目的开发，就会发现很奇怪的事情：数仓这边要建模，这个毋容置疑。但是BI产品里，也会有一个“建模”。这不就让人头大了么？嘿嘿，开头这哥们说的其实就是BI产品里的“建模”模块和数仓中的“建模”工作之间的联系与区别。
数据仓库建什么模？
我之前写过好多数仓建模的文章，这里就偷个懒，复制几张图过来。数据仓库建模分为4个阶段：业务建模、领域建模、逻辑建模和物理建模。通常意义上来说，我们说的建模狭义上指的是“逻辑建模”。业务建模和领域建模跟业务关系比较紧密，通常会在最开始就完成了。而物理建模就是执行一下脚本，分分钟就搞定了，比业务建模和领域建模还快呢。
而逻辑建模的时候，为了解耦，通常会把数仓进行分层设计。每一层的建模范式都不完全一样。比如：
其实上面的图也不完全正确。在传统数仓建模的时候，DWS其实也是用维度模型建模的。宽表模型是大数据环境下的产物。啥？你问问建的模型长啥样？其实就是按照一定规则组合起来的一堆数据表。大致是这个德行的：
因为长的像星星，所以叫星型模型。除此之外，还有雪花型、星座型、cube、宽表等等。我这里有一篇文章，写的很详细：【戳我查阅：一口气讲完数据仓建模方法】，你可以去参考一下。
BI建什么模？
前面说了，此BI非彼BI。群里提问的哥们问的不是“商业智能”那个BI，而是BI产品的“BI”。你想想，我们在数仓里建好模型了，不管是维度模型，还是宽表模型，还是Cube，然后呢？
当然是得有一个地方把这些数据展示出来了，要不放在那里生崽儿么？这时候就轮到BI产品出马了。BI产品一端连着用户，另一端连着数据仓库。所以BI产品有一个巨大的任务，就是做业务和数据之的翻译。这个时候就又轮到“建模”哥们出马了，在BI产品中，它是这个德行：
这是永洪网站上截的图，帮他们打个广告，支持一下国产BI产品。
这是QuickBi的说明，也是一个意思。这个业务和数据之间的翻译工作该咋做呢？其实还是维度建模，就是设置维度和度量了。然后加上各种的个性化操作，什么传入参数了、表间关联关系了、确定维度和度量了、添加过滤条件了，甚至还可以新增维度和度量，比如以年龄字段为基础，新增一个年龄段的维度。
这些都是BI工程师做的偏业务的数据建模。建好模型之后，BI产品会把这些建模的信息保存好。当打开报表的时候，解析引擎会按照刚才建模的结果，解析成SQL语句，挨个执行。做各种查询、关联、传参、过滤，顺带则把新增维度、度量等操作也一并做了。最后把结果展示给用户。
总结
唉，不管是啥工作，都是一脑门子的官司，深究下去无穷无尽。数据仓库的建模，目的是把数据整理好，所以重点在于实体与实体之间的关系。按照组织关系分类，自然就有星型、雪花型、星座等模型，也有为了加速存在的Cube和大数据环境特有的宽表模型。BI产品的建模，目的是进行业务与数据之间的翻译。所以重点在于如何用现有数据满足业务的需求。于是就有了选择数据源、表间关联、传参、过滤、确定维度、确定度量、新增维度、新增度量等乱七八糟的操作。这两个“建模”本来就是一件事情，只不过一个侧重数据的逻辑建模，一个侧重于数据的业务建模；一个是在数据仓库阶段，一个是在数据业务输出阶段；一个目的是为了数据组织和存储，一个目的是为了数据的业务表达。
