告别宽表，用 DQL 成就新一代 BI

BI商业智能这个概念已经提出好几十年了，这个概念本身比较宽泛，不同人也有不同的理解和定义，但落实到技术环节，特别是面向业务用户的环节，所称的BI，基本就是指的多维分析或者自助报表

不管是叫自助报表还是多维分析，也都是一回事，都是让用户自己去通过拖拽的方式查询数据或制作报表

查询：中国经理的美国员工

人事系统里员工表，还有部门表。员工表中有所属部门的字段与部门表关联，部门会有经理，而经理也是个员工，部门表中的经理字段会再和员工表关联。这就发生互相关联的情况，转圈了

我们用前面提到的那个查询中国经理的美国员工的例子来看一下SQL要怎么写，员工表里有个部门外键字段指向部门表的主键，部门表里又有经理外键字段指回员工表，这是很常见的数据结构设计

SQL写出来是这样的：

员工表和部门表JOIN，再JOIN回员工表，也就是同一个表要连接两次，这就起个别名。在WHERE中写上JOIN的条件和最终我们希望的条件。整个句子要看一会才能明白

使用DQL会写成这样：

这个句子中，美国员工好理解，中国经理的条件稍复杂一点，字段有了子属性，子属性又有子属性，但并不难理解，也就是部门的经理的国籍是中国

在DQL的语法体系中，外键被看成了属性，外键指向表的字段可直接用子属性的方式引用，也允许多层和递归引用

同维表等同化

订单及订单明细是典型的主子表，前者的主键是后者的一部分

现在我们想计算每张订单的总金额

用 SQL 写出来会是这样：

要完成这个运算，不仅要用到 JOIN，还需要做一次 GROUP BY，否则选出来的记录数太多。

如果我们把子表中与主表相关的记录看成主表的一个字段，那么这个问题也可以不再使用 JOIN 以及 GROUP BY：

与普通字段不同，订单明细被看成订单表的字段时，其取值将是一个集合，因为两个表是一对多的关系。所以要在这里使用聚合运算把集合值计算成单值。这种简化方式称为子表集合化

这样看待主子表关联，不仅理解书写更为简单，而且不容易出错

如果有多个子表时，SQL需要分别先做GROUP,然后在一起和主表JOIN才行，会写成子查询的形式，但是DQL则仍然很简单，SELECT后直接再加字段就可以了

按维对齐

我们希望按地区统计销售员人数和合同额

用SQL写出来是这样：

这个子查询很复杂

而在DQL中，可以和外键属性化结合，这样查询会写成：

这里又出现了子属性，但整个句子仍然很简单，DQL允许每个表独立设定统计维度，无须关心表间关联，还可以与属性化的外键配合使用

对这些JOIN更深入的探讨，可以参考连接运算 1-SQL 中的 JOIN

解决关联

前面讲的这几个JOIN的例子，都是在实际应用中常见的，具有业务意义的查询需求，

这些例子都是可以用来检验BI产品的“自助”灵活程度的，能否不需要技术人员更新模型就由完成这些查询。结果会发现，业内的大部分BI产品，无论界面多炫丽、操作多流畅，都经不起这个检验

原因就在于，低层模型上，并没有解决好JOIN问题

有了DQL之后，我们就能解决BI中的JOIN问题了

从前面的DQL例子中可以明显的看出，前3个查询用SQL的JOIN都没有了，多表变成单表了，只是字段变成有子属性了，而这并不难理解，业务人员可以轻车熟路地搞定。最后一个按维对齐的情况虽然还有JOIN，但也很简单，用户无需关心这些表之间的关联关系，只要向统一的目标维度对齐就行了

重新定义JOIN后，就彻底把不易于理解和拼写的JOIN变的简单易懂了，再做一个拖拽的前端界面，能让业务人员做JOIN的BI就做成了

有人可能会问，多表变一表，那不还是宽表吗不也还得技术人员做吗/p>

DQL和宽表大有不同!!!

DQL当然也需要技术人员提前定义好元数据，但是用到技术人员的地方也仅此一次

元数据中预先定义好了各种关联关系，但并没有做实际关联，当用户在前端拖拽分析的时候，才实时生成关联查询，不需要像宽表一样预先关联，占用数据库资源

它的关联关系只要数据表本身结构不变，就不用修改元数据，不需要像宽表一样总得重新生成，相当于一次定义可以适应无数次不同的分析需求，它拥有宽表的优势但从根本上解决了宽表的各种弊端

这就是所谓的非按需建模，建模只要考虑数据结构本身，而与用户需求无关。宽表（无论逻辑还是物理的）则是按需建模，需求一变就要再建模

用DQL语法还能降低出错率

很多程序员习惯用 WHERE 来写 JOIN 运算的过滤条件，表少的时候没有问题，表多的时候漏写了 JOIN 条件意味着将发生多对多的完全叉乘，而这个 SQL 却还可以正常执行，一方面计算结果会出错，另一方面，如果漏写条件的表很大，笛卡尔积的规模将是平方级的，这极有可能把数据库直接“跑死”！

采用DQL的 JOIN 语法，就不可能发生漏写 JOIN 条件的情况了。因为对 JOIN 的理解不再是以笛卡尔积为基础，而且设计这些语法时已经假定了多对多关联没有业务意义，这个规则下写不出完全叉乘的运算

对于多个子表分组后与主表对齐的运算，在 SQL 中要写成多个子查询的形式。但如果只有一个子表时，可以先 JOIN 再 GROUP，这时不需要子查询。有些程序员没有仔细分析，会把这种写法推广到多个子表的情况，也先 JOIN 再 GROUP，可以避免使用子查询，但计算结果是错误的

使用维度对齐的写法就不容易发生这种错误了，无论多少个子表，都不需要子查询，一个子表和多个子表的写法完全相同

DQL还能让数据结构显得更为清晰

表与表之间没有直接的关联，都只处在中间地位的维度关联，增删表的时候不会影响到其它表，数据结构耦合度低

不过，要说明的是，无论是E-R图还是后面的总线图，其中连线的数量都是相当的，这是数据关系本身决定的，不会因为改变了看待方法而变少，只是总线式看着更清晰些

DQL让BI告别了宽表，实现了更大程度的自由自助；也拓宽了BI分析的边界，让分析可以应对更多的数据场景，让BI成了更自由更好用的新一代的BI

告别宽表的新一代BI

DQL从低层模型上解决了JOIN的问题后，前端的界面要怎么来做其实也就变的简单了，不需要再费心去想怎么样设计才能让用户更好的理解数据了，因为不管怎么做，都能轻松理解拖拽了

下面是润乾基于DQL实现的一套界面，我们还是按前面的例子，挨个看看每个JOIN是怎么呈现给业务人员，怎么拖拽的

外键关联—中国经理的美国员工

经过DQL解析后，数据就都变成业务人员可以理解的清晰的树状结构了

原先的两个表变到一个表里了，业务人员已经完全不用去管后台是几个表，怎么关联了，直接拖拽员工姓名，再拖拽部门经理姓名，然后再设置一下两个的国籍，就可以了

同维表关联

同样的，多表变一表，主键相同的表，像员工表，经理表；客户表，VIP客户表，直接同化到一个表中了

而且查询控件还会自动把和已选择数据不匹配的数据项过滤隐藏掉，有汇总的还会自动建立汇总项与统计维度之间的匹配关系，使用起来就更加智能了，不仅避免了出错，保证了拖拽分析的业务正确性，也使得查询分析更加流畅了

直接添加小猿微信 微信名片

来源：灰小猿