说明：本文适合与BI同行、产品经理、高级业务分析师等用户学习。本文分为上下两篇，本文介绍SQL和DAX，下篇介绍Tableau 专利技术VizQL（数据分析，绕不过SQL、DAX、VizQL（下））
喜乐君
今天在读者群中，有人问为“何为DAX”？“既生SQL、何生DAX”？而我更想延伸说明的是，“Tableau何以20年宝刀不老，最重要的技术相比SQL、DAX有何不同？”
每个工具都顺应了特定的需求，每个工具也自有最佳的实践场景，无需厚此薄彼、相互抨击。同时，工具是时代的产物，只有理解工具产生的时代和企业需求背景，才能理解它的相对价值。
一、何为SQL和DAX
总结而言，SQL和DAX生于不同的时代，对应不同的背景，专注于差异化的任务，适用于不同的群体。
1）
SQL的全称是Structured Query Language ，由IBM在70年代开发，作为IBM关系数据库原型System R的原型关系语言，实现了关系数据库中的信息检索。它伴随关系型数据库而生，是定义和操纵关系数据的基本工具。这里的重点是“定义Define”和“操作Manipulate”，其中后者通往计算。
SQL is a standardized language for defining and manipulating data in a relational database.
IBM Document
SQL的目的是定义和操作数据，其中权限控制是特殊的操作项目，因此SQL常常被分为三种类型：
- DDL 数据定义语言（Data Definition Language）：创建、删除数据表，包括Create、Drop、Alter命令。
- DML数据操作语言（Data Manipulation Language）：查询和变更数据，包括Select、Update、Insert、Delete。
- DCL数据控制语言（Data Control Language）：权限控制，包括Commit、rollback、grant、revoke。
看到这里，数据分析师会发现自己使用的SELECT仅仅是SQL的功能之一，很多SQL命令都未曾耳闻。当然，在实际应用中，90%以上的SQL语言都是数据操作类型的。
分析师要注意，并没有单独的专用于分析的SQL命令，因为SQL在设计之初，分析并非它的主要功能。聚合的查询、计算、转换，都被设计在了SELECT之中。
换句话说，SQL的设计初衷是与数据库的增删改查，而非多变的抽象查询分析。
2）
反观DAX，它出生于21世纪，此时几千万、几亿行的数据已经稀松平常，它要解决的问题是，如何更高效地完成数据查询和分析，特别是处理多个操作的嵌套转换。
从SQL Server 2012开始，微软推出了SSAS Tabular Model（表模型），DAX被用于从表模型中分析数据，全称Data Analytical eXpression （数据分析表达式）。它出生就肩负了分析的重任，而不是用于创建、删除、修改数据表及其数据，也不能用于数据库层面的权限控制，事实上，这些数据库“硬交互”领域已经被SQL垄断。
和SQL类编程的思路不同，DAX是函数式、公式式语言，比如SUMMARIZE、SUMMARIZECOLUMNS的名称就充分体现了“聚合是分析本质”，经典的度量值计算函数CALCULATE则体现了“所有数据操作都是计算”的特征。
可见，“年轻派”DAX的基因是分析，“中年大叔”SQL则垄断数据库“增删改”的硬交互。如下图所示。
二、SQL和DAX在分析中的对比
SQL作为专业的数据库交互语言，它本身具有强大的分析能力，特别是嵌套查询、窗口函数、变量、视图等多种功能的组合使用，可以发挥不亚于任何一个分析工具的爆发力。既然于此，在新生代DAX面前，它又哪些优势，又有哪些不足？
同样的逻辑，新生代的DAX在分析上具有天然的优势，易于理解的函数、强大的功能组合，和可视化POWER BI/Pivot等前端的天然结合，让它拥有越来越多的用户。但是，它也存在“入门难”“函数纷繁复杂”的不足。应该如何取舍？
1、二者的基础：数据表交互的差异
首先，SQL和DAX都是基于表table的，更准确的说，都是基于集合的，这是关系数据库的理论基础之一。
其次，SQL和DAX有一个关键的差异，SQL基于单表操作，DAX则天生置于模型之中。 从这个角度看，DAX天然面向业务主题——业务主题不是单表的分析，而是围绕业务事实表构建的多表关系。
在SQL中，如果想要从另一个表中查询数据，必须使用JOIN、UNION、Natural JOIN等方式完成多表合并，然后方可查询，也就是说合并是查询的一部分；而在DAX中，分析师需要实现构建好模型（通常是其他team的专业用户完成），而在查询过程中，只需要RELATED指定另一个表的字段，表之间的合并关系（SQL join后的 on的条件）事先已经被设定了。
换个角度看，可以认为DAX基于更高级的劳动分工：分析中至关重要的数据建模（合并、关系），和数据查询分开了。这个重要性，不亚于SQL和数据库实现了数据存储、查询的分离。这也是DAX在分析方面明显领先于SQL的关键所在。
再者，作为数据库操纵工具，SQL可以可以实现数据表的写入、删除和反向查询，而Viz QL和DAX这种专用于分析任务的语言，基本都是单向查询，不能完成数据表写入、删除任务。
所以说，SQL是数据库的数据存储、操纵和检索工具（store, manipulate and retrieve data in databases），而VizQL和DAX则是更高级的数据检索和操作处理工具。从分析角度看，它们都可以完成相同的工具，只是方式有所不同，喜乐君在之前的【分析通识】篇中系统介绍过。
2、高度灵活：作为编程语言的SQL
相比DAX，SQL其实是一个编程语言，只是相比C++、Python这种专门的语言显得不那么强大。
作为编程语言，每次我们都要用完整的结构表述查询分析的需求，单独一个命令无法完成任何工作，只有组合才能发挥强大的作用。在编程的设计理念下，分析师要使用使用命令（commends）、子句（clause）、运算符（operators）和函数（functions）组合完成想要的任务。这种足够细分的设计，让SQL仅需要不多的功能，就能像乐高积木一样组合无限的完整语句。
高度灵活的背后，是会出现很多重复性工作，好在有了view视图，分析师可以把各种嵌套的子查询保存下来，然后在后续直接引用。这就好比我只需要告诉读者《数据可视化分析》第一版第三章3.1小节，读者就能心神领会一样。
以Mysql为例，喜乐君用一个简单的图片，就能概括绝大多数和查询、分析有关的命令、函数。它们的组合，也都符合SELECT查询的约定编程规范，可谓大道至简，一朝吃遍。
相比SQL的高度灵活，DAX更像是高度专业的分析工具，不管是函数的理解，还是相互组合而来的高度专业表达式。
3、高度专业：作为函数、公式语言的DAX
相比SQL的编程，DAX是函数、公式，函数和公式的无尽组合就是表达式（expression，DAX的X）。
函数完成数据查询和分析，会让分析中普遍存在的分组、聚合、筛选、排序、TOP等常见分析场景变得简单，但也会让一些组合变得困难。因为它缺乏像SQL一样清晰的操作次序，上下文的分类及其转换成为很多分析师难以逾越的大山。
同时，函数太多了，让如何选择最佳函数也成为了一件难事，这在SQL中本来不是问题，只要你想要分组聚合，你就必须用GROUP BY，但在DAX，你会面临SUMMARIZE、SUMMARIZECOLUMNS、ADDCOLUMNS、ALL、VALUES等多个选择。下图是喜乐君正在整理的DAX函数清单，还没有写完的清单。
DAX是函数、公式语言，设计初衷就是分析，而非查询。你可以把它视为是一大段SQL被封装的函数（比如addcolumns）。封装让函数之间的组合，提升了工具的专业性，作为代价，一定程度上失去了SQL的超级灵活性，甚至于何时使用FILTER，合适使用CALCULATETABLE都变成了难题。
当然，DAX的复杂，是专业的“副作用”，是高级的代价。唯有如此，才能适应纷繁复杂的分析需求，比如客户RFM分析、多遍聚合、复杂上下文、上下文转换、扩展表等等。
下一次，我们会介绍Tableau背后的Viz QL，看看它如何在SQL和DAX中间，走出了优雅的“第三路线”。
by 喜乐君
Jun 13, 2023 V1.0
Jun 16, 2023 V1.1
推荐阅读：
了解 喜乐君 的更多信息
订阅后即可通过电子邮件收到最新文章。
Pingback： 数据分析，绕不过SQL、DAX、VizQL（下） - 喜乐君
Pingback： 【产品对比】非对称之战：Tableau VS. FINE BI – 喜乐君
评论已关闭。