OLTP-交错-DW-重复

Question

我有一个项目，将数据从 OLTP 数据库提取到 Staging 星型模式，然后提取到数据仓库数据库。我有一个关系：播放列表<---(1-N)PlaylistTRack----->(1-N)Track--->(N-1)Sales。小组中有一个担心，如果我将 ttables Playlist/playlistTrack/Track 放入 Stagging bd 中的 1 个暗淡表中，将会创建重复项，但我不知道这是如何发生的，也不知道是否确实存在问题。

当我们搜索时，我们发现我们必须做一个桥接表。但如果真的存在的话，这能解决问题吗？

Answer 1

小组中有人担心，如果我将 ttables Playlist/playlistTrack/Track 放入 1 个 dimtable 中，将会创建重复项

这是一个合理的担忧。您的播放列表和您的曲目是两个不同的概念事物，它们以多对多的方式相互关联（一个播放列表可以有多个曲目，一个曲目可以出现在多个播放列表中）。您肯定不会想要将其折叠到单个表中，否则您将有重复项。 解决这个问题的桥接表就是你的

playlisttrack

表。该表的粒度是一个播放列表上的一个轨道，而键是播放列表和轨道维度的键的组合。

playlist <--- playlisttrack ---> track

现在，如果您有一个“不同”表扮演事实表的真正角色（“销售”），那么这不会改变所需的内容。您的 

sales

事实表将有一个指向 playlist: 的键 sales (fact) ---> playlist <--- playlisttrack ---> track

您的产品维度已按照称为“雪花”的模式分为三个表，但这是不可避免的。在这种情况下，虽然您的

sales

表仍然充当真正的事实表，但桥接表 (

playlisttrack

) 在某种程度上是一个具有自己粒度的事实表。认识到这一点很重要，因为在从 

sales

通过桥接表连接到

track

时必须小心，因为这会改变查询的粒度。除非您的查询在单个轨道上进行过滤，否则您需要使用仔细的

GROUP BY

逻辑和适当的聚合（销售事实上的

MAX

与

SUM

对比，直到按照销售事实粒度进行分组，然后仅在该分组之上使用

SUM

，等..）在任何此类查询中以避免过多计算您的销售事实。