维度建模：事实表应该有外键吗？答案

【问题标题】：Dimensional Modeling: should a fact table have a foreign key?维度建模：事实表应该有外键吗？
【发布时间】：2009-06-25 19:30:49
【问题描述】：

fact table 可以没有键吗？或者如果可以，这是一个好的设计吗？如果一个事实表没有任何维度，它是根据什么来分析的？

如果事实表只有主键而没有外键怎么办？

【问题讨论】：

事实表是数据仓库/维度建模中的常用术语，但并不是每个人都熟悉这些东西。我将添加一个标签和一个链接。

标签： sql-server database-design ssas data-warehouse

【解决方案1】：

说得不准确，外键将您链接到将事实表分为类别和子类别的表。

所以如果事实表是

create table stores (id, kindOfStore, sales)

那么 kindOfStore 将是您的维度 - 如果是这样，那么您可能会争辩说 kindOfStore 的单独表是多余的（除了浪费空间说 kind of store =“Food”而不是“Kind_id = 8”。如果您有子类别，则链接到像

这样的维度表是有意义的

create table kindOfStore (id, Variety, Specialization, Subspecialization)

将 Variety、Specialization 和 Subspecialization 存储在事实表中会导致空间效率低下。

生成的架构是星型架构，并且数据仓库已针对处理这些架构进行了优化，尽管更新更快的数据仓库引擎似乎非常快，以至于即使是非星型架构也相当快。

与 OLTP 数据库相比，数据仓库对事实表进行非规范化（使用更少的表），但这绝不意味着您应该争取单表解决方案。

【讨论】：

好吧...我明白即使没有维度表，事实表本身也很适合分析。如果有维度表并且不是事实表的外键怎么办。我觉得这太奇怪了……
您的意思是说一个星型模式（多个表），但没有人执行 ALTER TABLE ORDERS ADD FOREIGN KEY (foo) REFERENCES...？逻辑关系仍然存在。在实践中，当有人忘记添加密钥时，不可避免地会导致引用完整性问题。如果有人确实遇到了密钥问题（比如在 ETL 期间），那么他们应该尽快删除密钥并重新添加它们。

【解决方案2】：

维度建模旨在允许事实附加额外的细节，描述可以“汇总”并聚合为有意义的摘要信息的属性。它是数据仓库（主要是 READ 环境）的一个特征，但也可以放在 OLTP 中，根据主要事实对真正的交易数据进行建模（想想针对银行账户的交易，这可能是金融交易、票据和客户墓碑修订 -所有这些都有一个返回银行账户实体的公共链接）。

在通常与事实无关的一组细节中，最重要的是时间和地点维度。

如果您的事实不存在于时间或空间中，那么可以想象，如果没有在这些维度上的条目，它可能会存在（尽管我一生都无法弄清楚事实何时会像那样）。

如果进一步，其他维度很小且包含（意味着没有其他事实共享它们），您可以将它们作为 ENUM 滚动到原始事实表中。

最终结果将是一个单一的事实表，其中多个小维度表示为 ENUMS。

但是对于一些非常奇怪的数据来说，这将是一个非常奇怪的案例......

【讨论】：

【解决方案3】：

在一个好的设计中，每个表都会有一个主键。

外键的使用取决于您尝试限制表值的内容/方式。如果您想要更具体的答案，请提供有关您的情况的更具体信息

【讨论】：

我正在查看一个事实表，其中一个列我发现它可疑。所以，我想看看它从哪个维度表中提取值。出于这个原因，我在 SSAS 中创建了一个新项目并创建了一个新的 DSV（我不知道我是否可以从任何其他方法看到事实表和依赖项。我可以想到 SSMS，但我看不到事实表中的外键。所以 Visual Studio DSV 对我来说是一个可靠的方法）并且从添加/删除对话框中，我添加了事实表，但是当我点击相关表时，没有...

【解决方案4】：

我记得的情况是，当您使用包含用于维度列表目的的属性的表时，该工具需要将表或别名设置/标记/标识为事实表。

想象一个销售数据库，机会表包含一长串属性，对吧？您的客户说“我想获取所有机会名称、ID 和分配为 oppty 所有者的人员的列表”...然后您可以创建别名或同义词或在逻辑设计中映射同一个表。

退化维度可能是另一种情况......所以......虽然该表是一个真实的事实表，但提供的功能几乎相同，不是吗？

【讨论】：