3

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

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

4

4 回答 4

2

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

所以如果事实表是 

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

于 2009-06-25T19:48:44.213 回答
2

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

最重要的细节通常是时间和地点维度。

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

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

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

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

于 2009-06-25T19:59:44.693 回答
0

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

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

于 2009-06-25T19:35:50.230 回答
0

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

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

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

于 2009-07-09T21:19:12.043 回答