本书中所有的示例和练习数据都是已提前为您准备好的。目前您可以使用这些数据按照说明进行一些简单的操作。但是，这种简单性遮盖了一个深刻而重要的主题:那就是在自己的报告中如何组织自己的数据表。本章内容涵盖了这部分内容，以便您能够理解加载到Power BI中表的各种类型。

      值得注意的是，这个话题很容易被忽略，或者被认为是微不足道的。但从实践经验来看，人们最容易犯错误之一就是不能正确的使用表结构，特别是当他们不知道为什么重要或不知道如何正确制作表格时，如果你把表的结构弄错了，其他的事情就会变得困难很多

1.  Data Tables vs. Lookup Tables

       As you have already learned, there are two main types of tables that can be loaded into Power BI: data tables (also called fact tables, or transaction tables) and lookup tables (also called dimension tables, reference tables, or master data tables). These two types of tables have some very important differences, as described in the following sections.

     正如你已经了解到的，有两种主要类型的表可以加载到Power BI中:数据表(也称做事实表或事务表)和查找表(也称为维度表、引用表或主数据表)。这两种类型的表有一些非常重要的区别，下面会给大家详细介绍。

🔶 Data Tables 事实表

     虽然事实表不一定是加载到Power BI中的最大的表，但很多情况下它确实是导入的最大的表，这样说很矛盾，但你在学习了更多关于PBI的知识后就会觉得这样说是有道理的。本书中使用的销售表是就是一个事实表，它包含了发生在世界各地的AdventureWorks零售店的收银机记录的个人交易的详细信息。这个表中的每一行数据表示购物交易清单上的一项。事实表可以由数百万(或数十亿甚至数万亿)行数据组成。一些事实表中包括销售、预算、汇率、总账、核验结果和股票数量等信息。

     事实表对期中记载的事项发生频率和存储频率没有限制。我们可以想一想，一家卖汉堡和薯条的快餐连锁店，每天可能有数百笔几乎完全相同的交易，因为同一类型的汉堡在任何一天都可以卖很多次。这种情况下，对每笔交易的区分通常使用交易时间(时间戳)，也可能是具有唯一性的发票号或者收据号

🔶 Lookup Tables 维度表

     与事实表相比，维度表往往更小(比方说这个表行数跟事实表比更少)，而且通常更宽(具有更多的列)。常见的维度表有客户表、产品表、日期表和账户交易表等。

      跟事实表相比，维度表有另外一个特殊的地方就是它必须具有某种类型的唯一标识代码，或者说某个字段的值必须是唯一的、不重复的，用这个字段可以惟一地区分表中的每一行数据。这个唯一的列通常称为键(在数据库语言中称为主键-Main Key)。本书中使用的产品表-Products table里，AdventureWorks这一列有许多不同的产品（确切地说，有397种）。表中的每个产品都有一个唯一的产品代码(product id)，这是能唯一识别(代表)这个产品的数字。例如，产品key 为212的行代表的是一个红色的运动100型头盔。Products表中不能有其他产品这使用这个代码（key 为212）。仔细想想的话，每个产品一个代码是必须的。如果企业对不同的产品使用相同的产品代码，那岂不是乱套了。客户编码和店号也一样，不能重复。我们实际使用的日期表也是遵循这一逻辑建立的，日期表的date字段是唯一的，可以用作唯一ID(主键)。

🔶 Flattened Tables大宽表

     要理解表结构的重要性和加载数据的不同方法，拿到一个大宽表(我管它叫大宽表，就是你想要的列都放在一个表里)。在Excel数据透视表的早期(在Power pivot 出现之前)，你只能在单个数据表之上创建数据透视表。如果希望对一个销售数据表进行分析，就可以使用透视表来对数据进行聚合汇总。

     像下图这样，数据透视表(#2)是销售表(#​1)的透视表，使用数据透视表可以很容易地汇总每个产品的总销售额，正如ProductKey列中所标识的那样。

单表透视

     使用一个表做数据透视表一直用得挺好的，直到有一天你想从Sales表以外的表里拿数据时，假如你想知道产品名称、产品类别、子类别或任何其他相关信息，那怎么办? 以往的话，你会使用VLOOKUP()函数，或者使用INDEX&MATCH函数拿到所需要的数据列，并把这些数据列放到Sales表中，这样就可以在透视表中使用那些列了。随着业务量的增加或时间的推移，这个Sales表可能会越来越宽，越来越宽。

This process of bringing in the missing columns is called denormalising.

从其它表引用缺失列的过程叫"反范式规范化&#​34;。(denormalising译为反范式规范化请大家指正)

     从技术上来讲你可以把上面的表加载到Power BI数据模型中并按原样使用它，但这并不是最好的做法。如果你的需求非常简单，仅仅是使用像COUNT和SUM这样简单函数来运算，那么使用下面这样的"大宽表&#​34;也行。假如你需要很复杂的计算，例如你想计算产品子类销售的占比或者想使用CALCULATE这样的函数，那么我建议你就别使用"大宽表&#​34;了。这种"大宽表&#​34;看似简单，但Power BI数据模型不喜欢它。Power BI的数据模型并想把所有数据的列放在一个表里，就像以前做Excel数据透视表那样把所有列都放到一个表中当作数据源。所以在使用Power BI时，通常应该避免使用这样的"大宽表&#​34;。

大宽表 Flattened Tables

NOTE: Power BI数据建模引擎是一个列式数据库，它垂直压缩加载的数据。(现在你知道为什么这个引擎也被称为VertiPaq了)。关于列式数据库背后的细节技术性有点强，也不是本书介绍的重点，但是有几个关键点你应该知道：列中的惟一值越多，数据的压缩效果越好。此外，数据表中的列数比行数重要得多，就是说少列多行的表比多列少行的表要更好用(运行效率、压缩比等更好)，尤其是表越大这这种优势越明显。

2. Joining Tables by Using Relationships 使用关系来关联表

     将重复的数据保存在一个单独的维度表中是解决重复数据问题的一个好办法。像Sales表中的产品信息，只需要唯一标识每个产品ProductKey列就行了，它包含产品代码数据(每个产品的代码是唯一的)。Sales表包含唯一的产品键，需要的时候我们就可以从产品的维度表中获取所需的关于产品的其它信息。Power BI允许将两个表加载到数据模型中，并在它们之间创建一个关系，而不是让我们再用VLOOKUP等函数把没在销售表中的产品其它列信息弄过来。PBI中的表创建了关系以后，这些表就会协同工作，而不是把所有列放到需要处理的Sales表中。

     在第2章我们提到过，数据模型中表的结构和它们之间的关系可以用"模型模式&#​34;来描述，有好几种称呼来描述这种模式，下面会介绍两种最常见的模式:星形模式和雪花模式。

3. Star Schema 星形模型

   下面这个图展示了书中使用的星型模式数据结构，或者叫星形数据模型。示例中，Sales表(#1)是一个事实表，位于模型的中心。其他表(#​2、#3、#​4和#5)是维度表，围绕着事实表放置，唯度表和事实表连线关联以后像星星一样，这种结构就被称做星型模型。

NOTE:

在数据库领域，查找表被称为唯度表，我也习惯用唯度表这种称呼。

唯度表和事实表的关系为一对多关系，连线箭头总是指向事实表。

星形模型 Star Schema

     当然了，第二章也跟大家说过，你可以用自己想要的方法放置这些表，我建议使用Collie布局方法，就像下图所示。可以看到这两张图虽然布局不同，但表之间的关系是一样的。你采用什么样的视图布局在Power BI对结果没影响，你看惯某种布局后就可以一目了然地知道哪些表是唯度表，哪些是事实表。

Collie布局

4、Snowflake Schema 雪花模型

     任何一个都至少有一个某种类型的数据库来管理自己的数据。这些数据库通常由组织内部的IT人员创建的，也可能由第三方软件公司创建的。在传统的关系型数据库系统中，数据通常被划分为许多级别的唯度表。下面图片有一个数据表Sales(#1)，还有三个唯度表，它们呈一线连接(#​2、#3和#​4)。表4是表3的一个唯度表，表3是表2的一个唯度表，表2是表1的一个唯度表。

Snowflake Schema 雪花模型

This data structure is common in traditional transactional databases as it is the most efficient way to store the data in those systems.

这种数据结构在传统的事务数据库中用于存储数据是最有效的一种方法。但是这并不是Power BI中结构化数据的最佳方式，因为Power BI不是关系数据库，这种方法并不适合Power BI，有以下几点原因:

🔶  雪花模型中每个关系都是有代价的，过多的、额外的关系可能会对数据库的性能产生负面影响。

🔶 业务用户将使用数据库设计构建报告，他们将看到数据模型中的所有表。对于试图了解到哪里可以找到产品信息的最终用户来说，这种级级串连的结构是让人困惑，找起来也很麻烦。

🔶  Power BI是重新开始对数据进行构建，以非常有效的方式将重复数据存储在列中(之前提到的xVelocity, VertiPaq, SSAS Tabular, and Power Pivot等的后台数据引擎，即列式数据库)，特别是在较小的查找表中，所以根本没有理由像上图所示那样做。

5、加载数据的建议

    在构建自己的数据模型时，有几点做法可以引导您在正确的方法上前行。

🔶 尽可能，保持您的数据表长而瘦。如果有必要，通过逆透视的方法去掉一些多余的数据列。特别需要指出的是：如果数据表是大宽表(即有很多列)，那么每增加一列数据的压缩效果都不如不增加这一列，这意味着又长又宽的数据表可能会给你带来问题。

🔶 从数据表中移除属性重复的列，并创建查找表(维度表)，但要注意也不要做得太过了。如果查找表只有两列(例如，Key和Description)，那么最好删除Key列，直接将描述加载到数据表中。如何最好地处理这个问题取决于具体情况，也没有什么包治百病的方法。

🔶 如果查找表(维度表)连接到其他查找表(维度表)，可以考虑将它们合并成一个更宽的查找表(维度表)，对于Power BI来说，减少维度表的个数通常是一个更好的模型设计方案。