来源：数据蒋堂
作者：蒋步星
本文长度为3000字，建议阅读6分钟
本文为你讲解SQL中用于多表关联的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运算，不再需要技术人员的参与。数据建模只发生于数据结构改变的时刻，而不需要为新的关联需求建模，这也就是非按需建模。
专栏作者简介
润乾软件创始人、首席科学家
清华大学计算机硕士，著有《非线性报表模型原理》等，1989年，中国首个国际奥林匹克数学竞赛团体冠军成员，个人金牌；2000年，创立润乾公司；2004年，首次在润乾报表中提出非线性报表模型，完美解决了中国式复杂报表制表难题，目前该模型已经成为报表行业的标准；2014年，经过7年开发，润乾软件发布不依赖关系代数模型的计算引擎——集算器，有效地提高了复杂结构化大数据计算的开发和运算效率；2015年，润乾软件被福布斯中文网站评为“2015福布斯中国非上市潜力企业100强”；2016年，荣获中国电子信息产业发展研究院评选的“2016年中国软件和信息服务业十大领军人物”；2017年, 自主创新研发新一代的数据仓库、云数据库等产品即将面世。
数据蒋堂
《数据蒋堂》的作者蒋步星，从事信息系统建设和数据处理长达20多年的时间。他丰富的工程经验与深厚的理论功底相互融合、创新思想与传统观念的相互碰撞，虚拟与现实的相互交织，产生出了一篇篇的沥血之作。此连载的内容涉及从数据呈现、采集到加工计算再到存储以及挖掘等各个方面。大可观数据世界之远景、小可看技术疑难之细节。针对数据领域一些技术难点，站在研发人员的角度从浅入深，进行全方位、360度无死角深度剖析；对于一些业内观点，站在技术人员角度阐述自己的思考和理解。蒋步星还会对大数据的发展，站在业内专家角度给予预测和推断。静下心来认真研读你会发现，《数据蒋堂》的文章，有的会让用户避免重复前人走过的弯路，有的会让攻城狮面对扎心的难题茅塞顿开，有的会为初入行业的读者提供一把开启数据世界的钥匙，有的甚至会让业内专家大跌眼镜，产生思想交锋。
往期回顾：
数据蒋堂 | 常规遍历语法
校对：谭佳瑶
为保证发文质量、树立口碑，数据派现设立“错别字基金”，鼓励读者积极纠错。
若您在阅读文章过程中发现任何错误，请在文末留言，或到后台反馈，经小编确认后，数据派将向检举读者发8.8元红包。
同一位读者指出同一篇文章多处错误，奖金不变。不同读者指出同一处错误，奖励第一位读者。
感谢一直以来您的关注和支持，希望您能够监督数据派产出更加高质的内容。
428
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
