为什么事实 table 中的维度成员集通常用作复合键？
Why do the set of dimension members in a fact table are typically used as a composite key?
根据我的研究，"best practices" 似乎表明事实 table 中的一行会有一个由所有维度度量组成的复合键：例如，如果我的度量在事实上 table 是 "sales" 并且我有四个维度： "location, salesperson, buyerCat, salesMonth" 然后，我的复合键将包含这 4 个维度的唯一值。但这会导致严重的问题：如果我有两个具有唯一维度集的度量怎么办？？？
--Example: Fact table row:
Sales Amount: 0, location: US, salesperson: Bob, buyerCat: Young, salesMonth: Feb/2010
Sales Amount: 0, location: US, salesperson: Bob, buyerCat: Young, salesMonth: Feb/2010
此度量将被阻止进入数据集市，因为所有维度成员都被用作复合键。我说的不对吗？
除非您将组合键定义为唯一的，否则您可以拥有任意多个重复项。
如果您发现这会有问题，那么您可能需要查看您的数据模型并询问为什么要加载使用完全相同维度的多行。
在您给出的示例中，大概这些实际上是不同的销售额。如果是这样，它们可能发生在不同的日子 - 但您只是在月级记录，所以您丢失了该数据。如果您将确切的日期作为一个维度，那么您的重复问题就会消失。或者，如果两次销售可以在同一天进行，则可能有一个来自销售的交易编号可以被记录并用作退化维度——同样，您不再有使用相同维度的行。
交易事实 tables 应该根据事件对事物进行建模 - 在您的示例中，正在进行销售 - 并且它们应该引用足够的维度以唯一地标识该事件的每个特定事件。
如果您真的不关心将数据保留到最细粒度，那么您正在构建的不是交易事实 table，而是周期性快照事实 table.在这种情况下，您应该将这两行相加，这样您只有一行的销售额为 740 美元。
但是，我会非常小心地以这种方式构建仓库，而不是构建交易事实 tables，它会下降到最低粒度 - 即使没有人想要报告或分析到现在是那个级别，他们以后可能会想要，并且重构您的数据仓库和 ETL 以在较低粒度下工作会很痛苦。然而，如果您首先以尽可能低的粒度创建事务事实 table，则您始终可以聚合起来——无论您的用户是在像 SSAS 这样的 OLAP 工具中这样做，还是您创建一些聚合的 tables 或视图以便更轻松地进行报告。
最好避免使用复合键或任何与业务相关的键来唯一标识您的事实 table 行。我可以向您保证，您会发现许多共享相同维度键的记录。使用 Kimball website 提供的步骤清楚地定义您的事实 table 粒度，您将无需担心事实行的唯一性
根据我的研究，"best practices" 似乎表明事实 table 中的一行会有一个由所有维度度量组成的复合键：例如，如果我的度量在事实上 table 是 "sales" 并且我有四个维度： "location, salesperson, buyerCat, salesMonth" 然后，我的复合键将包含这 4 个维度的唯一值。但这会导致严重的问题：如果我有两个具有唯一维度集的度量怎么办？？？
--Example: Fact table row:
Sales Amount: 0, location: US, salesperson: Bob, buyerCat: Young, salesMonth: Feb/2010
Sales Amount: 0, location: US, salesperson: Bob, buyerCat: Young, salesMonth: Feb/2010
此度量将被阻止进入数据集市，因为所有维度成员都被用作复合键。我说的不对吗？
除非您将组合键定义为唯一的，否则您可以拥有任意多个重复项。
如果您发现这会有问题，那么您可能需要查看您的数据模型并询问为什么要加载使用完全相同维度的多行。
在您给出的示例中，大概这些实际上是不同的销售额。如果是这样，它们可能发生在不同的日子 - 但您只是在月级记录，所以您丢失了该数据。如果您将确切的日期作为一个维度，那么您的重复问题就会消失。或者，如果两次销售可以在同一天进行，则可能有一个来自销售的交易编号可以被记录并用作退化维度——同样，您不再有使用相同维度的行。
交易事实 tables 应该根据事件对事物进行建模 - 在您的示例中，正在进行销售 - 并且它们应该引用足够的维度以唯一地标识该事件的每个特定事件。
如果您真的不关心将数据保留到最细粒度，那么您正在构建的不是交易事实 table，而是周期性快照事实 table.在这种情况下，您应该将这两行相加，这样您只有一行的销售额为 740 美元。
但是，我会非常小心地以这种方式构建仓库，而不是构建交易事实 tables，它会下降到最低粒度 - 即使没有人想要报告或分析到现在是那个级别，他们以后可能会想要，并且重构您的数据仓库和 ETL 以在较低粒度下工作会很痛苦。然而，如果您首先以尽可能低的粒度创建事务事实 table，则您始终可以聚合起来——无论您的用户是在像 SSAS 这样的 OLAP 工具中这样做，还是您创建一些聚合的 tables 或视图以便更轻松地进行报告。
最好避免使用复合键或任何与业务相关的键来唯一标识您的事实 table 行。我可以向您保证，您会发现许多共享相同维度键的记录。使用 Kimball website 提供的步骤清楚地定义您的事实 table 粒度，您将无需担心事实行的唯一性