交叉引用表...维度还是事实?

Posted

技术标签:

【中文标题】交叉引用表...维度还是事实?【英文标题】:Cross-reference table...dimension or fact? 【发布时间】:2013-08-02 01:49:54 【问题描述】:

初学者维度建模问题:

您如何在正式的“业务流程”之外为维度之间的关系建模?例如,假设您正在为梦幻棒球联盟建模。一些明显的维度是团队和球员,一个示例事实是球员击球的结果。我很困惑的是如何简单地跟踪哪些球员在哪个球队。

在第三范式中,我将有一个包含团队和球员 FK 的交叉引用表,以及专门与两者组合相关的任何其他字段(招募日期、替补球员指标等)。这与星型模式有什么不同吗?如果不是,那么该表是否被视为事实表,没有数字属性?

让我感到困惑的是,这个交叉引用表本身并没有多大用处。只有在加入其他事实表时才有意义,以获取与另一个事实/流程相关联的团队中的球员列表。这让它感觉更像是一个维度而不是一个事实。

【问题讨论】:

【参考方案1】:

在维度建模中,您必须选择要建模的过程。如果 Team Player 关系对您的模型来说是次要的,您可以忽略它并知道当一名球员为球队击球时属于球队。

当然,这排除了从不击球的球员。

如果要考虑这种关系,即多对多关系,显而易见的解决方案是另一个事实表。事实表甚至可以是无事实的(当您没有关于它的额外信息时,但在这种情况下,球员的薪水将是一个明显且重要的事实)。

【讨论】:

【参考方案2】:

另一种选择是为播放器使用类型 2 SCD。这是一种随时间存储玩家属性变化的方法。

因此,对于单个玩家,您可能有四个维度记录,因为该玩家在四支球队中移动。维度记录具有开始日期和结束日期,因此如果玩家在一月份换了球队并且直到二月份才开始比赛,那么该信息仍然会被存储。

您可以通过这种方式跟踪任何球员的属性,例如受伤等

这是一种无需特殊事实即可跟踪“缓慢”变化的方法。

如果您确实需要某种历史状态报告,您只需将玩家维度加入日期维度即可。

看看本文中的第二类:

http://en.wikipedia.org/wiki/Slowly_changing_dimension

【讨论】:

以上是关于交叉引用表...维度还是事实?的主要内容,如果未能解决你的问题,请参考以下文章

数据仓库中的低基数维度

数据库——事实表和维度表

我需要定义事实表或维度表吗?

hive建立数据仓库 事实表的外键和维度表主键怎么关联 啥命令

数据仓库设计:如何设计交货日期变化的事实和维度表

为啥要分出事实表fact和维度表dim