解决关联查询(JOIN 简化和提速系列 5)

五. 解决关联查询

我们重新审视和定义了等值 JOIN 运算,并简化了语法。一个直接的效果显然是让语句书写和理解更容易。外键属性化、同维表等同化和子表集合化方案直接消除了 JOIN 关键字,也更符合自然思维;维度对齐则可让程序员不再关心表间关系,降低语句的复杂度。

简化 JOIN 语法的好处不仅在于此,还能够降低出错率
我们知道,SQL 允许用 WHERE 来写 JOIN 运算的过滤条件(回顾原始的笛卡尔积式的定义),很多程序员也习惯于这么写。当 JOIN 表只有两三个的时候,那问题还不大,但如果 JOIN 表有七八个甚至十几个的时候,漏写一个 JOIN 条件是很有可能的。而漏写了 JOIN 条件意味着将发生多对多的完全叉乘,而这个 SQL 却可以正常执行,一方面计算结果会出错(回忆一下以前说过的,发生多对多 JOIN 时,大概率是语句写错了),另一方面,如果漏写条件的表很大,笛卡尔积的规模将是平方级的,这极有可能把数据库直接“跑死”!
采用简化后的 JOIN 语法,就不可能发生漏写 JOIN 条件的情况了。因为对 JOIN 的理解不再是以笛卡尔积为基础,而且设计这些语法时已经假定了多对多关联没有业务意义,这个规则下写不出完全叉乘的运算。

对于多个子表分组后与主表对齐的运算,在 SQL 中要写成多个子查询的形式。但如果只有一个子表时,可以先 JOIN 再 GROUP,这时不需要子查询。有些程序员没有仔细分析,会把这种写法推广到多个子表的情况,也先 JOIN 再 GROUP,可以避免使用子查询,但计算结果是错误的。
使用维度对齐的写法就不容易发生这种错误了,无论多少个子表,都不需要子查询,一个子表和多个子表的写法完全相同。

重新看待 JOIN 运算,最关键的作用在于实现关联查询
当前 BI 是个热门,各家产品都宣称能够让业务人员拖拖拽拽就完成想要的查询报表。但实际应用效果却远不如人意,业务人员仍然要经常求助于 IT 部门。造成这个现象的主要原因在于大多数业务查询都是有过程的计算,本来也不可能拖拽完成。但是,也有一部分查询并不涉及多步过程,而业务人员仍然难以完成。
这就是关联查询,也是大多数 BI 产品的软肋。在之前的文章中已经讲过为什么关联查询很难做,其根本原因就在于 SQL 对 JOIN 的定义过于简单。
结果,BI 产品的工作模式就变成先由技术人员建模,再由业务人员基于建好的模做查询。而所谓建模,就是生成一个逻辑上或物理上的宽表。也就是说,建模要针对不同的关联需求分别实现,我们称之为按需建模,这时候的 BI 也就失去敏捷性了。

如果我们改变了对 JOIN 运算的看法,关联查询可以从根本上得到解决。回忆前面讲过的三种 JOIN 及其简化手段,我们事实上把这几种情况的多表关联都转化成了单表查询,而业务用户对于单表查询并没有理解障碍。无非就是表的属性(字段)稍复杂了一些:可能有子属性(外键字段指向维表并引用其字段),子属性可能还有子属性(多层的维表),有些字段取值是集合而非单值(子表看作为主表的字段)。发生互相关联甚至自我关联也不会影响理解(前面的中国经理的美国员工例子就是互关联),同表有相同维度当然更不碍事(各自有各自的子属性)。
在这种关联机制下,技术人员只要一次性把数据结构(元数据)定义好,在合适的界面下(把表的字段列成有层次的树状而不是常规的线状),就可以由业务人员自己实现 JOIN 运算,不再需要技术人员的参与。数据建模只要在数据结构发生改变的时刻实施,而不需要为新的关联需求建模,这也就是非按需建模,在这种机制支持下的 BI 才能拥有足够的敏捷性。

clipboardpng