【数据蒋堂】第32期：JOIN简化 - 意义总结

蒋步星《JOIN运算的简化与提速》系列技术文章。

更多敬请期待.....

我们重新审视和定义了等值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运算，不再需要技术人员的参与。数据建模只发生于数据结构改变的时刻，而不需要为新的关联需求建模，这也就是非按需建模。

  正文结束  

 课程视频（可点击底部阅读原文观看）

https://edu.hellobi.com/course/197/lessons  （主题二）

 近期文章

    关于数据蒋堂    

《数据蒋堂》的作者蒋步星，从事信息系统建设和数据处理长达20多年的时间。他丰富的工程经验与深厚的理论功底相互融合、创新思想与传统观念的相互碰撞，虚拟与现实的相互交织，产生出了一篇篇的沥血之作。此连载的内容涉及从数据呈现、采集到加工计算再到存储以及挖掘等各个方面。大可观数据世界之远景、小可看技术疑难之细节。针对数据领域一些技术难点，站在研发人员的角度从浅入深，进行全方位、360度无死角深度剖析；对于一些业内观点，站在技术人员角度阐述自己的思考和理解。蒋步星还会对大数据的发展，站在业内专家角度给予预测和推断。静下心来认真研读你会发现，《数据蒋堂》的文章，有的会让用户避免重复前人走过的弯路，有的会让攻城狮面对扎心的难题茅塞顿开，有的会为初入行业的读者提供一把开启数据世界的钥匙，有的甚至会让业内专家大跌眼镜，产生思想交锋。

蒋步星，清华大学计算机硕士，著有《非线性报表模型原理》等

1989年中国国际奥林匹克数学竞赛团体冠军成员，个人金牌。

2000年创立润乾公司，首次在润乾报表中提出非线性报表模型，完美解决了中国式复杂报表制表难题，目前该模型已经成为报表行业的标准。

2008年开始研发不依赖关系型数据的计算引擎，历经多个版本后，于2014年集算器正式发布。有效地提高了复杂结构化大数据计算的开发速度和运算效率。

2016年荣获中国电子信息产业发展研究院评选的“2016年中国软件和信息服务业 • 十大领军人物”。

2017年创办数据领域技术讲堂《数据蒋堂》，专注数据、每周一期。

2017年获得中国大数据产业生态大会评选的“2017年度中国数据大工匠”