维度建模:事实表是否应该有外键?

时间:2009-06-25 19:30:49

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

fact table根本没有钥匙吗? 要么 如果可以的话,这是一个好的设计吗?如果事实表没有任何维度,那么它在何种基础上进行分析?

如果事实表只有主键/ s且没有外键/ s?

,该怎么办?

4 个答案:

答案 0 :(得分:2)

不恰当地说,外键将您链接到将您的事实表分成类别和子类别的表。

所以如果事实表是

create table stores (id, kindOfStore, sales)

然后kindOfStore将是你的维度 - 如果就是这样,那么你可以争辩说,kindOfStore的一个单独的表是矫枉过正的(除了空间浪费说类型的商店=“食物”而不是“Kind_id = 8”)。如果您有子类别,则链接到像

这样的diminsion表是有意义的
create table kindOfStore (id, Variety, Specialization, Subspecialization) 

在事实表中存储Variety,Specialization和Subspecialization将是空间效率低下的空间。

生成的模式是星型模式,并且数据仓库已经过优化以处理这些模式,尽管更新更快的数据仓库引擎似乎非常快,甚至非星型模式也非常快。

与OLTP数据库相比,Datawarehouses将事实表非规范化(使用更少的表),但这绝不意味着您应该争取单个表解决方案。

答案 1 :(得分:2)

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

在这些细节中,优势通常是时间和地点尺寸。

如果你的事实在时间或空间上不存在,那么可以想象的是,在没有这些维度的条目的情况下存在(虽然我不能在我的生活中找出事实就是这样)。

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

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

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

答案 2 :(得分:0)

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

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

答案 3 :(得分:0)

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

想象一下销售数据库,机会表包含很长的属性列表,对吧?您的客户说“我想获得所有机会名称,ID和被分配为实体所有者的人员列表”......然后您可以创建别名或同义词,或者在逻辑设计中映射相同的表格。

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