在数据仓库中，一个维度可以与另一个维度相关吗？

Question

我目前正在开发一个数据仓库，我想知道通过外键将一个维度连接到另一个维度是否有意义。

例如，假设我们有两个维度“国家”和“城市”，我们应该在事实表中仅存储城市维度键。这座城市也知道它是一个国家。

或者将两个外键都存储在事实表中是否更有意义？

但是城市维度必须知道它属于哪个国家（看起来它违背了星型模式，因为我们现在在维度之间也有链接）

或者这纯粹是一个设计选择，不会对查询等产生影响？

Answer 1

不是一个直接的答案，但请考虑这两种情况；

A.你在城市的粒度上有一张事实表

• 您可以选择星型模式，即
  • 包含城市的单一维度
  • 此维度包含国家/地区列（重复）

factTransactionA >- dimCity

• 或者您可以选择雪花模式，即
  • 城市维度表
  • 单独的国家维度表
  • 这些尺寸可以连接起来。

factTransactionA  >- dimCity >- dimCountry

两者都有效，但请考虑......

B.你有一张城市的事实表和另一张乡村的事实表

当您不确定设计决策时......寻找其他约束或要求来帮助您做出决定

对于情况 B，您有有一个国家/地区维度。例如，您不应该“超载”城市维度并尝试使其适合国家/地区粒度的事实表。所以你知道你必须拥有这个：

factTransactionB >- Country dimension table

因此，如果我即时扩展此解释......通常，您在事实表之间使用“一致”维度，因此当我们考虑两个事实表时，我实际上会建议这种类型的模式：

factTransaction2 >- dimCountry  -< factTransaction1 >- dimCity

而不是这个

factTransaction2 >- dimCountry -< dimCity -< factTransaction1

这实际上意味着将dimCountry代理键烘焙到实际上位于城市级别的

factTransaction1

中。

因为

• 我的直觉告诉我我们应该避免事实之间存在两个一致的维度
• 如果您在国家/地区维度中有一个事实，那么国家/地区在您的业务中可能足够重要，可以融入其他事实，以便轻松比较不同事实的指标。

所以我觉得在这个冗长的解释中我提出了一个避免雪花模式的理由，但它们绝对是有效的

Answer 2

另一种方法是更通用的位置维度。

Location {    
   string City // can be null indicating a record for a whole country    
   string Country 
}   
CityFact }|--|| Location
CountryFact }|--|| Location

select from CityFact Join Location where Location.City = "City" and Location.Country = "Country"

select from CountryFact Join Location where Location.Country = "Country"

通过这种方式，您只需与位置表进行一次连接即可进行城市或国家/地区查找，并且可以使用单个维度支持城市和国家/地区详细级别事实表。在大多数情况下，这将比嵌套联接表现得更好，并将事实表上的键数量保持在最低限度。