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

In a datawarehouse can a dimension be related to another dimension?

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

例如,假设我们有两个维度 'Country' 和 'City',我们应该只在事实 table 中存储城市维度键。城市知道它的国家。

或者在 table.

中存储两个外键是否更有意义

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

或者这纯粹是一种设计选择,不会对查询等产生影响?

不是直接的答案,但请考虑这两种情况;

一个。你有一个事实 table 在城市

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

factTransactionA >- dimCity

  • 或者您可以选择雪花模式,即
    • 一个城市维度table
    • 一个单独的国家维度table
    • 可以合并这些维度。

factTransactionA >- dimCity >- dimCountry

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

乙。你有一个事实 table 在城市里,另一个在乡村里

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

对于案例 B,您 具有国家/地区维度。例如,您不应该“超载”城市维度并尝试使其符合国家/地区的事实 table。所以你知道你必须有这个:

factTransactionB >- Country dimension table

所以如果我即时扩展这个解释....通常,你在事实 table 之间使用“一致”维度,所以当我们考虑两个事实 table 时,我会实际上建议这种模式:

factTransaction2 >- dimCountry -< factTransaction1 >- dimCity

而不是这个

factTransaction2 >- dimCountry -< dimCity -< factTransaction1

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

因为

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

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