1.1 理解数据模型

第1章 什么是DAX？

1.1 理解数据模型
1.2 DAX FOR EXCEL用户
1.3 DAX for SQL开发人员
1.4 DAX for MDX开发人员
1.5 DAX FOR POWER BI 用户

DAX代表Data Analysis eXpression （数据分析表达式），是Microsoft Power BI，Microsoft Analysis Services和Microsoft Power Pivot for Excel的编程语言。它创建于2010年，第一版是Microsoft Excel 2010的PowerPivot 。2010年，PowerPivot的拼写中间没有空格。空格是在2013年Power Pivot中引入的。此后，DAX在使用DAX在Excel中创建Power Pivot数据模型的Excel社区和运用DAX在Power BI和Analysis Services构建模型的商业智能社区中流行起来。DAX存在于许多不同的工具中，它们共享相同的名为Tabular（表格模型）的内部引擎。因此，我们经常引用Tabular（表格模型），一个词就能包含所有这些不同的工具。

DAX是一种简单的语言。就是说，DAX与大多数编程语言不同，因此熟悉其一些新概念可能需要一些时间。根据我们向成千上万的人讲授DAX的经验，学习DAX的基础非常简单：您将可以在数小时内就能开始使用它。当要理解高级概念（例如评估上下文，迭代和上下文转换）时，所有事情似乎都很复杂。不要放弃！耐心一点。当您的大脑开始消化这些概念时，您会发现DAX确实是一种简单的语言。这只是需要一些习惯。

第一章从表和关系的角度简述一下数据模型的含义。我们建议所有经验水平的读者阅读本节内容，以熟悉整本书中使用的表、模型和不同类型的关系。

在以下各节中，我们为有编程语言（例如Microsoft Excel，SQL和MDX）经验的读者提供建议。每个部分都针对特定的语言，以帮助好奇的读者简要地将DAX与之进行比较。专注于对您知道的语言的比较是否对您有帮助；然后阅读最后一节"面向Power BI用户的DAX "，并进入下一章，这是我们真正开始DAX语言之旅的起点。

理解数据模型

DAX专为在数据模型上计算业务公式而设计。读者可能已经知道什么是数据模型。如果没有，我们将从对数据模型和关系的描述开始，以建立基础来建立其DAX知识。

数据模型是一组通过关系链接的表。

我们都知道表是什么：一组包含数据的行，每行分为几列。每列都有一种数据类型，并且包含一条信息。我们通常将表中的一行称为记录。表是组织数据的便捷方法。表虽然本身是最简单的形式，但它本身就是数据模型。因此，当我们在Excel工作簿中写入名字和数字时，我们正在创建数据模型。

如果数据模型包含许多表，则它们很可能通过关系链接在一起。关系是两个表之间的链接。当两个表被关联在一起时，我们说它们是相关的。在图形上，关系由连接两个表的线表示。显示了一个数据模型的示例。

图1-2 此报告显示跨多个表进行筛选的效果

以下是关系的一些重要方面：

• 关系中的两个表没有相同的角色。他们被称为"一"方和"多"方的关系，分别用1和用*表示1-1中，关注产品与产品子类别之间的关系。一个子类别包含许多产品，而一个产品只有一个子类别。因此，产品子类别是关系的"一"方，具有一个子类别，而产品是关系中的"多"方，具有许多产品。

• 特殊类型的关系是1：1和弱关系。在1：1关系中，两个表都是一个一面，而在弱关系中，两个表可以是"一"方。这些特殊类型的关系并不常见。我们将在第15章 " 高级关系 " 中详细讨论它们。

• 用于创建关系的列通常在两个表中都具有相同的名称，称为关系的键。在关系的"一"方，该列的每一行都必须具有唯一的值，并且不能包含空格。在"多"方，相同的值可以在许多不同的行中重复，而且经常如此。当一列的每一行都有唯一的值时，该列称为表的键。

• 关系可以形成一条链。每个产品都有一个子类别，每个子类别都有一个类别。因此，每个产品都有一个类别。要检索产品的类别，必须遍历两个关系的链。图1-1包含一个由三个关系组成的链的示例，从销售开始，一直到产品类别。

• 在每种关系中，一个或两个小箭头可以确定交叉筛选的方向。图1-1显示了Sales和Product之间的关系中的两个箭头，而所有其他关系都有一个箭头。箭头指示关系的自动筛选（交叉筛选）的方向。由于确定筛选的正确方向是最重要的学习技能之一，因此我们将在后面的章节中详细讨论该主题。如第15章所述，我们通常不鼓励使用双向筛选。它们存在于此模型中仅出于教育目的。

了解关系的方向

每个关系可以具有单向或双向交叉筛选。筛选总是从关系的一方到多方进行。如果交叉筛选是双向的，也就是说，如果交叉筛选上有两个箭头，则过滤也会从多侧到单侧进行。

一个示例可能有助于理解此行为。如果报告是基于图1一1所示的数据模型，Years位于行上，Quantity和Count of Product Name在值区域中，它产生的结果如图1一2所示。

图1-2 此报告显示跨多个表进行筛选的效果

Calendar Year是属于Date表的列。由于Date在与Sales关系的"一"方，因此引擎会根据年份筛选Sales。这就是为什么显示的数量按年份进行筛选的原因。

使用Products时，情况略有不同。发生筛选是因为Sales表和Product表之间的关系是双向的。当我们在报表中放置Count of product names时，由于每年的筛选会通过Sales传递到Product，因此我们会获得每年销售的产品数量。如果关系如以下各节所述，Sales和Product 之间的关系是单向的，结果将有所不同。

如果我们修改的报告，将Color置于行，Count of Date置于值区域，其结果是不同的，如图1一3所示。

图1-3 此报告显示，如果未启用双向筛选，则不会筛选表

行上的筛选是Product 表中的Color列。由于Product表处于与Sales表关系的"一"方，因此正确筛选了Quantity。Count of product names被滤除，因为它要从行所在的表即Product表上取值。意外的数字是Count of Date。确实，它总是显示相同的所有行的值，即Date表中的总行数。

来自Color列的过滤器不会传递到Date，因为Date和Sales之间的关系是单向的。因此，尽管Sales上面有一个活动的筛选，但由于关系类型阻止了该筛选，因此该筛选无法传递到Date。

如果我们改变Date和Sales之间的关系，启用双向交叉筛选，结果如图1一4所示。

图1-4如果启用双向筛选，则使用Color列筛选Date表

现在，这些数字反映了至少出售一种给定颜色的产品的天数。乍一看，似乎所有的关系都应定义为双向的，以便使过滤器向任何方向传递，并始终返回有意义的结果。正如您将在本书后面学习的那样，用这种方法设计数据模型几乎是不合适的。实际上，根据您使用的场景，您将会选择正确的传递关系。如果您遵循我们的建议，则应尽可能避免双向筛选。