何时使用多事实关系模型
多事实关系模型是一种数据模型，它允许您在单个数据源中添加不相关的表，然后在可视化分析期间使用相关字段根据上下文将表实质上拼接在一起。与混合不同，数据存在于单个数据源中 - 主数据源和辅助数据源的概念不适用，并且不会从左联接中删除任何数据。与单表数据模型不同，多个基表维护自己的关于他们之间共享的表的上下文。多事实关系数据模型为您提供了在 Tableau 中执行多事实分析的更多选项。
想象一下，您想分析天气和冰淇淋销售趋势如何结合在一起。天气和冰淇淋销售都发生在特定的时间和特定的地点，但冰淇淋销售和天气之间没有直接联系。这些是不相关的数据片段，但都与日期和地点的共同概念相关。
这个问题有助于创建多事实关系模型。冰淇淋销售和天气均可添加为基表，并在“Date”（日期）和“Location”（地点）（共享表）上相关。
多基表数据模型，包含两个不相关的表（“Cream Sales”（冰淇淋销售）和“Weather”（天气））和两个共享表（“Date”（日期）和“Location”（地点））。“Ice Cream Sales”（冰淇淋销售）和“Location”（地点）之间有一个中间表，即“Parlor Info”（店铺信息）。
为什么我们要构建对不相关表进行建模的能力？
分析通常涉及汇总彼此之间没有直接关系但都与相同的共同信息（例如日期或地点）相关的数据表。多事实关系模型通过引入相关度概念和使用多个不相关基表构建数据模型的能力来支持松散语义耦合。
语义耦合是用来描述数据组合紧密程度的术语。联接或并集是一种紧密的语义耦合；它们将多个表组合成一个新的物理表，然后充当单个表。关系是表之间的一种松散耦合，将表在逻辑上联系在一起，保持它们作为单独表的不同状态。语义耦合谱的进一步延伸是 数据混合，其中来自不同数据源的结果根据它们之间共享的元素进行可视化组合。多事实关系模型更接近于光谱的混合端，但是在单个数据源内而不是跨数据源。
多事实关系模型（具有多个基表的数据模型）允许模型中存在不相关的表，只要模型中也存在共享表。在分析过程中，共享表中的字段根据共同的维度（例如在同一地点或同一时间发生）将原本不相关的数据表“拼接”在一起。关系的所有优点都得以保留，包括保留每个表的粒度或本机详细级别。
与单基表数据模型类似，Tableau 根据可视化项的结构确定后台使用的最佳联接类型。但在多事实关系模型中，联接选项扩展为包括外部联接和交叉联接，以处理不同级别的关联性。有关详细信息，请参见关于多事实关系数据模型。
这个名称从何而来？
多事实关系因多事实分析而得名。在数据仓库模型中，数据存储在被维度表包围的中央事实表中。在此上下文中，事实 指测量值或指标，即用于捕获有关数据的事实的数据数字字段，也就是 Tableau 的度量。维度表包含有关这些事实的属性。
基于事实表的架构通常构造为星型或雪花型，具体取决于维度表的组织方式。当需要跨事实表进行分析时，这称为多事实分析。分析是在公共维度表（称为共享维度或一致维度）的上下文中完成的。在 Tableau 中，您可以使用关系构建这些数据模型，因此我们将这套功能命名为多事实关系。
何时使用多事实关系数据模型
如果您的数据由彼此相关的表组成，那么您可以坚持使用通过关系构建的单个基表数据源。当您的数据跨越不同的概念（无论是多个事实表的形式还是不同的不相关上下文的形式）时，就需要多事实关系模型。
只要有可能，就使用单个基表构建数据源。在单基表数据模型中，每个表都是相关的，无需考虑相关程度。仅在需要该数据模型结构时才使用多事实关系。
多事实分析
多事实分析是 Tableau 中多事实关系的核心用例。在这个例子中，事实 A 和事实 B 共享一个表，即“Date”（日期）。
为了在 Tableau 中对此进行建模，事实表成为基表，并为其共享维度表建立多个传入关系。
其他场景
然而，多事实关系数据模型不仅仅用于多事实分析。Tableau 不需要严格定义事实表或维度表。任何表都可以作为基表（尽管它应该适合基表的特征）。一些表明多基表数据源可能会有帮助的场景包括：
- 经历各个阶段，例如共享学生表的申请表、成绩单表和校友活动表等基表。
- 同一事件的不同上下文，例如医疗预约和账单发票事件的基表，以及用于将上下文设置为医生或患者的共享表。
- 可能相关的不同领域，例如以前最好通过数据混合来处理的场景，例如通过共享的日期和地点表关联起来的冰淇淋销售和天气。
在此 Tableau 博客文章中了解有关多事实关系何时有用的更多信息：何时以及如何在 Tableau 中使用多事实关系。
识别基表
在多事实关系模型中，方向性很重要。也就是说，哪些表是模型左侧的基表，以及哪些表在下游共享会影响如何评估关系以返回分析结果。
考虑一下发票、预约、医生和患者的概念性领结：
在 Tableau 中构建数据模型的正确方法是以“Invoices”（发票）和“Appointments”（预约）作为基表，以“Doctors”（医生）和“Patients”（患者）作为共享表（而不是以“Doctors”（医生）和“Patients”（患者）作为基表）。
正确：“Invoices”（发票）和“Appointments”（预约）作为基表 | 错误：“Doctors”（医生）和“Patients”（患者）作为基表 |
 |  |
从概念上讲，患者（或医生）是将预约事件和发票事件拼接在一起的实体。
如果您的数据模型是逆向的（例如以医生和患者作为基表，而不是预约和发票）， 外部联接拼接行为就没那么有用了。您的分析可能会显示出很多表范围的度量和歧义。如果您发现自己拥有意想不到的模糊相关字段，请重新评估用作基表的表，并查看数据模型是否需要反转。
基表和共享表的特征
如果您正在执行多事实分析，则事实表将成为基表，任何共享维度表都是共享表。Tableau 不要求严格遵守事实表和维度表的特征。但是，某些属性可以帮助您识别哪些表应该是基表，哪些表应该是共享表。
基表 | 共享表 |
数据仓库架构中的事实表 | 数据仓库架构中的共享或一致维度表 |
具体到上下文或分析 （航班信息、能源使用情况） | 在不同上下文中保持一致的概念 （日期、地点） |
测量重量 | 主要维度 |
更新/事务性更频繁 （医疗预约、处方、生命体征） | 更稳定/持久 （医生、患者） |
具有外键字段 | 具有主键字段 |
基于事件 （课程表、作业成绩） | 基于实体 （学生，教室） |
请注意，如果基表和共享表之间存在中间表，则可以 交换哪个表是基表，而无需从根本上改变数据模型。（例如第一个例子中的“Parlor Info”（店铺信息）和“Ice Cream Sales”（冰淇淋销售）。）重要的是哪些表位于共享表的上游以及哪些表是共享表。
尝试使用其他基表
有多种情况可能表明您应该构建具有多个基表而不是单个基表数据源的多事实关系模型：
- 如果您尝试构建具有循环的数据源，则下游表应该是另一个基表。
- 如果您有一系列在同一组关系子句（例如日期和地点）上相关的表，则应该将这些维度拉出来并制成共享表。
- 这尤其有用，因为多个关系子句必须全部为真（逻辑上为 AND），表才能与这些记录相关。
- 相反，如果您想要分析一次可能为真的记录（上下文 Or），则可以通过设置具有共享维度表的数据模型来提供这种灵活性。
- 如果您正在使用混合，但希望获得没有主要和辅助数据源的等效混合，请构建一个数据模型，将混合中的数据源与一个或多个共享表中的链接字段相结合。