五. 解决关联查询

我们重新审视和定义了等值 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 才能拥有足够的敏捷性。