BI数据可视化报表开发：分析模型VS自定义SQL

各位数据的朋友，大家好，我是老周道数据，和你一起，用常人思维+数据分析，通过数据讲故事。

很多朋友会问：“以前用报表工具开发了很多报表，也写了很多的SQL，这次想移植到奥威BI中来，但在奥威BI软件中怎么通过自定义SQL来配置图表？”如果我说奥威BI软件虽然有自定义SQL这个功能，但是基本上强烈建议大家不去使用。你一定会觉得不可思议。为什么？用自定义SQL来实现数据可视化不是更容易上手吗？别急，请大家耐心把今天的内容看完。我相信大家以后再也不愿意回到写SQL的年代了！（点击观看视频）

亨利·福特曾说过:如果我最初问消费者他们想要什么,他们会告诉我”要一匹更快的马”！奥威BI软件不是更快的报表工具，它是为了解决用户在数据分析中遇到的需求场景：如何更快发现数据中的问题，如何更快的分析原因？

奥威BI软件就是将以往报表工具由需求部门提需求，然后IT部门开发报表的这样一种开发模式，改为IT人员仅需要开发数据仓库并构建分析模型，至于报表的开发，则完全由需求用户自行来完成。要想实现这样的改变，有两个地方要进行创新：1、构建分析模型要简单；2、前端报表要实现0代码拖拖拽拽就可以完成。我们今天就通过一些示例来看一下奥威BI软件是如何做到这些的。

自定义SQL：用个性化的开发去满足个性化的需求

对于一个有经验的报表开发者而言，已经非常习惯根据用户的需求，通过自定义SQL来开发报表。回忆一下，当我们拿到用户的报表需求表样时，就会开始这样的构思：报表中有哪些列，这些列会用到哪些聚合函数，比如销售收入，用sum的方式聚合，亦或者哪些列之间有什么样的计算公式，比如毛利=收入-成本。这样，我们就基本确定了select语句中的各列是如何定义的；然后再看表样中的行是什么，来决定我们是按什么来构建group by。然后再看表样中需要按什么进行筛选，比如按时间，那么，我们就加上相应的where条件。

通过这样的思维方式，我们来确定我们要开发的SQL查询语句，如果涉及到多表，则通过join来实现，如果再复杂些，涉及到中间表或其他更复杂的计算，则通过存贮过程来实现。

不管我们最终是通过select查询，还是存贮过程，我们都将这种自定义SQL的方式称之为：是用个性化的开发去满足个性化的需求。

为什么这样说呢？因为我们在根据用户的需求开发时，一定是用户要什么就开发什么，绝对不会去想用户可能还需要什么，也绝对不会画蛇添足的去做一些其他无关的开发，假设用户的报表有10列，我们绝对不会开发第11列。而一旦用户第二天告诉你，不好意思，我还想加另外一个字段，或者我漏掉了一个计算规则。这时，你又得重新根据用户的想法开发。所以，在现实场景中，IT开发人员经常加班加点开发完一个报表，第二天用户就把需求给改变了，还报怨说，在EXCEL一下就改过来了，怎么到你们手上还要花那么长时间呢？

怎么办？如何改变这种IT费力不讨好，需求部门却不停排队等开发的状况呢？有没有更好的办法？有的，这就是用构建分析模型的方式去应对需求，我们称之为用共性的开发去满足个性化的需求。

构建分析模型：用共性的开发去满足个性化的需求

很多人一听分析模型这么高大上的概念，就感觉这一定很复杂啊。其实并不复杂，我们只需要通过几个简单的问题，就可以将分析模型构建出来，接下来，我们举一个销售分析的例子，来看我们是怎么通过几个简单的问题，就将一个销售分析模型构建出来的：

第一个问题：我们要分析什么业务——即确定分析主题。这里我们明确是分析销售的业务，也就是说分析主题为销售分析；

第二个问题：这个分析主题要从哪些角度分析? ——即确定分析维度。那我们来看一下，销售分析要从哪些角度来分析呢？我们通常要从产品、客户、业务员这几个维度来分析，另外，这些维度通常还会衍生出许多其他的属性，比如产品可能还有不同的品类、品牌的，而客户还区分不同的客户级别、客户分类等，这些也都是分析的维度。另外，还有一个非常重要不可或缺的维度，那就是时间维度，而时间维度又会区分为年、季、月、周、日甚至时分秒不同的颗粒度，这些，都是分析维度，这么一细分，我们可能就会有10多种甚至数十种分析的维度出来了。

接下来第三个问题：这个分析主题要分析哪些指标? ——即确定分析的度量值和计算成员。那销售分析需要分析哪些指标呢？一般都会有销售金额、销售数量、单价、成本这些基本的指标，另外，还会有一些指标是基于这些基本指标计算出来的，比如毛利=销售金额-成本，还有一些衍生出来的统计指标，比如销售金额的占比，同比，本年累计等。这些就叫做计算成员。

当我们回答完这些问题的时候，闭上眼睛想一想，原来销售分析模型可以从这么多维度来分析，又可以分析这么多的指标，那是不是类似于一个魔方（立方体）呢？维度相当于水平的单元，而指标相当于垂直的单元，各单元又可以任意的进行旋转组合。大家想想，是不是所有关于销售的分析，无外乎就是这些维度和这些指标的排列组合呢？

有了这么一个立体的分析模型，最后，我们就只要再回答这些数据要从哪里取数？——即确定数据视图。比如销售的数量是从订单表的哪个字段上取，客户名称又是来自于哪个表哪个字段？销售订单表和客户表该如何关联？

经过了上述几个步骤，我们就基本上完成了一个销售分析模型的构建。大家想一想，是难还是不难呢？可能有的人会问，我怎么知道销售分析会从哪些维度、分析哪些指标啊，会不会因为我没有经验，就会漏掉很多内容啊？答案是：不会的，不需要什么经验，你也一定可以想清楚销售模型要分析哪些指标，从哪些维度去分析。为什么这么说呢？其实我们只要回归到业务本身就可以了。比如销售分析，我们一般是根据销售订单或者销售出库单来进行分析的，所以，我们只要回归到ERP的销售订单或销售出库单就可以。大家就会发现，ERP中销售订单上会有很多的字段，这些字段我们只要大概的分一下类就可以了：将不需要分析的字段，如送货地址去掉；然后再看哪些字段是数值型的，可以用来统计度量的，比如销售数量、单价之类的，我们就将之归为分析指标，而其他如客户、业务员、产品则是分析维度。

为了再帮助大家理解，我们再引出两个概念，一个是事实表，一个是维度表。这里的事实表即涉及到交易的表，比如销售订单，销售出库单，他们存贮了交易事实，我们称之为事实表，而客户、产品这些存贮基础资料的表，因为他们通常是用作为分析的维度，所以我们则称之为维度表。

讲到了现在，大家可能会觉得，这个分析模型似乎也没有什么神秘的，但是，也没有觉得这个分析模型有什么用啊。

接下来，我们就来举几个需求场景的例子，来对比一下，传统的自定义SQL与分析模型的方式，哪个更简单，区别又在哪里？

假设有一天，销售部的销售助理小芳找你来开发报表，说：“强哥，我想按客户统计截止到当前的订单出库率，要导出好多数据，好麻烦啊，你能不能帮我啊！”

这时的你一定已经在脑海中将所需要的SQL都已经写出来了：

Select 客户,sum(订单数量), sum(出库数量), sum(出库数量)/ sum(订单数量) as 订单出库率 from (

Select 客户,sum(订单数量) from 订单表 join 客户表 on订单表.客户ID=客户表.客户ID

Where订单表.时间<=时间条件 group by客户

) a,(

Select 客户,sum(出库数量) from 出库表 join 客户表 on出库表.客户ID=客户表.客户ID

Where出库表.时间<=时间条件group by客户

) b

Where a.客户=b.客户 group by客户

第二天，小芳又提出新需求：“不好意思啊，强哥，光按客户来看订单出库率还不够，还要按客户所在的区域，除了要看这个月的总的订单出库率，还要看与去年同期相比是高还是低，另外，还要按每个月来看这个订单出库率有没有什么变化。……”

这时，你的心情就变得五味杂陈了，心里想：怎么不早说啊？但看着小芳那双水汪汪充满期待的大眼睛，你只得故作轻松道：“行，没问题！”

于是，你将原来的SQL复制出来，分别修改了一下。虽然其中那个订单出库率同比需要用到存贮过程，但也很快完成了。于是，你的SQL就变成了4个：

1、 客户订单出库率；

2、 客户区域订单出库率；

3、 总的订单出库率同比；

4、 每个月的订单出库率。

在另外一个平行宇宙里，小芳和你说完她的想法，刚要离开，你叫住了她，说：“小芳别走，强哥这就教你在BI软件中怎么做。”

第一步，构建一个同时包含订单事实表与出库事实表的分析模型。

通过拖拉、点击将销售订单、销售出库分别和客户表关联起来。

第二步，就可以直接做相应的报表了。

1、添加表格，视图选择刚刚上一步建好的【订单出库率视图】。

将订单数量、出库数量添加到【汇总】后，通过【fx】自定义表达式获得订单出库率指标。

订单数量：点击【汇总】旁的【+】，打开销售订单，勾选【订单数量】，点确定。

出库数量：点击【汇总】旁的【+】，打开销售出库，勾选【出库数量】点确定。

订单出库率：点击【汇总】旁的【+】，点击【fx】，勾选【汇总区域】后，分别在计算成员1、自定义表达式中输入订单出库率、出库数量/订单数量，点击确定。

2、将客户维度添加到行维度中：点击【行维度】旁的【+】，打开客户表，勾选【客户名称】，点确定。

3、复制表格

将该表格命名为【客户订单出库情况】后，点击选中该表格，点击【复制黏贴】，点击【复制到报表】，点确定。

点击数据集【客户】右侧【…】，点击【复制】后，重命名为【区域】。

点击【行维度】中的【客户名称】旁的【……】，点击【删除】。点击【行维度】旁的【+】，勾选【一级客户名称】，点确定。

最后将表格名称修改为【区域订单出库情况】即可获得以下效果，这样就可以按客户区域来看订单出库率了。

用同样的方法复制一个新表格，将数据集修改成【月份】，行维度修改成【时间年】、【时间月】，这样就可以按年月来看订单出库率。

最后用同样的方法再复制一个表格，计算去年的订单出库率。

总的思路为：数据集名称改为【总】；删除原定的行维度；计算去年订单数和出库数，然后再通过自定义表达式计算去年的订单出库率。

去年订单数量：点击【订单数量】旁的【……】，点击【同期】，选择【范围同比（上年范围）】，点确定。

去年出库数量：点击【出库数量】旁的【……】，点击【同期】，选择【范围同比（上年范围）】，点确定。

去年的订单出库率：点击【汇总】旁的【+】，点击【fx】，勾选【汇总区域】后，分别在计算成员1、自定义表达式中输入去年订单出库率、上年出库数量/上年订单数量，点击确定。

之后，将表格排版位置调整一下，再把按月查看的表格替换成折线图，即点击选中该表格，点击【更换图表】，点击选择一个折线图。BI数据可视化系统就会自动替换。

最后，添加一个按时间日期查询的筛选控件。即点击上方的【+】，点击【筛选】下的【公共筛选】，勾选【时间日期】，并在左下角勾选【日历（范围）】后点击确定。最终获得以下效果：

增加图表联动功能：

单击选定历史订单出库情况表，点击【联动】，选择【图表联动】，点击选择区域订单出库情况表、客户订单出库情况表，点击确定。

单击选中客户订单出库情况表，点击【联动】，选择【图表联动】，点击选择区域订单出库情况表，点击确定。

点击数据集构建器下筛选项【时间日期】旁的【…】，在条件筛选器中，将筛选条件改成筛选【近期（T+0）】、【-12】、【月】，点确定。如下图：

这时，当我们点击区域订单出库情况表中的【上海市】时，就能同时看到上海市的客户订单出库情况，以及上海市历史订单出库情况。如果我们点击某个客户，还可以看到这个客户的历史订单情况。

小芳：“如果我还想按产品来分析订单出库率呢？”

小强：“没问题，根据你的想法，我只需要在原来的分析模型上增加一个产品维度。”

刷新后，点击选中区域订单出库情况表，点击【复制粘贴】，选择【复制到报表】，点确定。再次重复以下操作：复制数据集；点【…】删掉原行维度，点【+】将物料表中的【物料名称】设为行维度；

这时候就可以按产品来看每个区域的订单出库情况。其实有了这个分析模型，不仅可以分析订单出库率，还可以分析与订单或出库相关的其他分析，比如分析每个区域的销售占比。

点击【+】，添加表格，点击【汇总】旁的【+】，勾选【销售金额】点确定；点击【行维度】旁的【+】，勾选【一级客户名称】，点确定，就可以看到每个区域的销售数据。

然后点击【销售金额】旁的【…】，选择【占比】，点击【行占比】，即可看到每个区域的销售占比情况。

如果要看每个区域不同月份的销售情况，只需点击【列维度】旁的【+】，勾选【时间年】、【时间月】，点确定。

只要你能想到的，都可以通过这种方式组合起来。

好，我们来回顾一下小强的操作，分为两部分，一部分是构建分析模型，第二部分就是根据这个分析模型制作报表，大家会发现，整个过程不需要写任何SQL，只需要理解业务需求实现出来就可以了，并且，这个分析模型还可以快速迭代，如果后面小芳想按业务员这个维度来分析，就只要将业务员维度加进来就可以了。

例子讲完了，大家会发现，通过分析模型来开发报表，灵活、高效，而且开发及运维的成本非常低。但在实践中，要改变以往的开发习惯还是有些困难的。

敲黑板，讲重点

对于写SQL的“高手”来说，需要进行以下的观念转变，才能跳出“报表开发”的泥沼，让开发变得更轻松：

首先要理解，自定义SQL是用个性化的开发去满足个性化的需求，而分析模型则是用共性的开发去满足个性化的需求。

开发时，要还原到最原始业务单据，用最明细的业务颗粒度来构建分析模型，尽量不要根据需求来构建中间结果表。很多开发人员会说，为什么不将用户想要的结果直接计算出来，用户直接查询就可以，这样查询效率最高，同时，用户还没有学习成本。但在这里，我是建议千万别这样。为什么呢？举个简单的例子。假如我们是想看各区域的销售占比，这时，我们用group by区域并计算出其占比。但如果用户又突然想从产品线的维度来看销售占比，怎么办？这时，开发人员又得重新完成中间结果表的开发。换言之，只要用户的需求发生了一点变化，开发人员都必须去响应。而如果我们只是用最原始的交易单据加上主数据构建的分析模型去响应用户需求，就非常简单，用户想按什么维度去分析销售占比，都只要在前端构建器中更换维度字段即可，完全可以通过自己的鼠标秒级切换，开发人员根本不需要介入！

还有一个就是，公共的维度要拿出来独立，不要join在大表里：比如说客户名称，不要在销售订单里有客户名称，出库单里也有客户名称，虽然大家可以理解到订单里的客户名称与出库单里的客户名称是同一个东西，但对于系统来说，它却并不能这么聪明地理解。这也就是为什么很多报表工具，在不同的报表之间跳转时，如果要从上一张报表将客户名称传递到下一张报表，需要强制进行参数的映射。但奥威BI软件可以不需要这样操作，后续再找个专题讲一下奥威BI软件最有特色的一个功能，就是智能分析路径功能，它可以在系统中实现任意报表之间的智能穿透钻取，参数是完全自动完成匹配传递的。

另外再请大家记住以下几个常用概念：

l 维度：就是观察数据的一种角度。如客户，时间都是维度，

l 维度值：就是构成某个维度的基本内容。如客户分类维度中的分类1、分类2，或时间季度维度中Q1、Q2等。

l 度量值：就是要分析展示的数据，即指标。如销售数量。

l 计算成员：基于度量值进行再计算的分析指标，如本年累计销售数量。

l 事实表：存放交易记录的表，包括度量值和维度ID。

l 维度表：一个维度对应一个或者多个维度表。比如客户维度对应客户表和客户分类表。

作为BI开发人员，只有你真正理解了分析模型怎么构建，怎么使用，你才算是从报表认知跃迁到BI认知，从一个报表开发人员升级成为一个BI开发人员。 

老周道数据，和你一起，用常人思维+数据分析，通过数据讲故事，我们下一讲再见！