我们重新审视和定义了等值JOIN运算，并简化了语法。一个直接的效果显然是让语句书写和理解更容易。外键属性化、同维表等同化和主子表一体化方案直接消除了显式的关联运算，也更符合自然思维;维度对齐则可让程序员不再关心表间关系，降低语句的复杂度。
一
简化JOIN的好处不仅在于此，还能够降低出错率。
我们知道，SQL允许用WHERE来写JOIN运算的过滤条件(回到原始的笛卡尔积式的定义)，很多程序员也习惯于这么写。当JOIN表只有两三个的时候，那问题还不大，但如果JOIN表有七八个甚至十几个的时候，漏写一个JOIN条件是很有可能的。而漏写了JOIN条件意味着将发生多对多的完全叉乘，而这个SQL却可以正常执行，一方面计算结果会出错(回忆一下以前说过的，发生多对多JOIN时，大概率是语句写错了)，另一方面，如果漏写条件的表很大，笛卡尔积的规模将是平方级的，这极有可能把数据库直接“跑死”!
采用简化后的JOIN语法，就不可能发生漏写JOIN条件的情况了。因为对JOIN的理解不再是以笛卡尔积为基础，而且设计这些语法时已经假定了多对多关联没有业务意义，这个规则下写不出完全叉乘的运算。
对于多个子表分组后与主表对齐的运算，在SQL中要写成多个子查询的形式。但如果只有一个子表时，可以先JOIN再GROUP，这时不需要子查询。有些程序员没有仔细分析，会把这种写法推广到多个子表的情况，也先JOIN再GROUP，可以避免使用子查询，但计算结果是错误的。
使用维度对齐的写法就不容易发生这种错误了，无论多少个子表，都不需要子查询，一个子表和多个子表的写法完全相同。
二
重新看待JOIN运算，最关键的作用在于实现关联查询。
当前敏捷BI产品非常火热，各家产品都宣称能够让业务人员拖拖拽拽就完成想要的查询报表。但实际应用效果会远不如人意，业务人员仍然要经常求助于IT部门。造成这个现象的主要原因在于大多数业务查询都是有过程的计算，不大可能由直接不会编程的业务人员独立完成。但是，仍有约三成左右的业务查询并不涉及多步过程，而业务人员仍然无法完成。
这是由于大多数敏捷BI产品(以及多年前流行的OLAP产品)都不支持关联查询。这些产品的工作模式是先由技术人员构建模型，再由业务人员基于模型在界面上进行查询。而所谓建模，其实就是生成一个逻辑上或物理上的单表，业务人员只能在这个单表的范围内查询分析，无论界面做得多么流畅炫酷，在数据获取层面都不可能超越这个事先构建好的单表范围。用户的查询需求一旦超出了这个单表，需要关联到其它表中数据时，就要由技术人员再次建模。建模实际上要针对不同的关联需求分别实现，我们称之为按需建模。但实际上，有意义的查询绝大多数都有关联需求，技术人员也不可能事先预测所有的关联，就算预测了也不可能把所有的关联可能性都事先做好。结果是，要么建模动作频频发生，要么业务用户没法使用，无论如何，这些敏捷BI产品都会失去敏捷性。
为什么这些BI产品不能支持关联查询呢?因为并不容易，其根源就在于SQL对JOIN的定义过于简单，导致表间关联过于繁琐，超出业务人员的理解能力，直接把数据结构暴露出来由业务用户自己完成JOIN运算是不可能的。有些BI产品的界面协助下有一些改善，在事先定义好维度后，可以让业务人员正确处理没有形成环的关联关系以及同表内没有相同维度的关联情况，全自关联(形成环)和同表多同维字段仍需要再建模去解决，这些细节我们也留到讲述维度概念时来再详细讨论。
但是，如果改变了对JOIN运算的看法，关联查询可以从根本上得到解决。回忆前面讲过的三种JOIN及其简化手段，我们事实上把这几种情况的多表关联都看成了单表查询，而业务用户对于单表查询并没有理解障碍。无非就是表的属性(字段)稍复杂了一些：可能有子属性(外键字段指向的外键表)，子属性可能还有子属性(多层的外键表)，有些字段取值是集合而非单值(子表看作为主表的字段)。发生自关联也不会影响理解(前面的例子就是个自关联)，同表有相同维度也不碍事(各自有各自的子属性)。在这种关联机制下，技术人员只要一次性把数据结构(元数据)定义好，在合适的界面下，由业务人员可以自己实现JOIN运算，不再需要技术人员的参与。数据建模只发生于数据结构改变的时刻，而不需要为新的关联需求建模，这也就是非按需建模。
