Question

我有一张雪花图：

Fact: 
id_movie
id_user
rating

Dim Users:
id_user
...


Dim Movies:
id_movie
...

在我的ERD中，我还有一个表类别，与这样的电影有很多关系：

Dim_Category:
id_category
...

Map_Category_Movie:
id_movie
id_category
relevance

我正在尝试找到一种在snowflace / star模式中对此进行建模的有效方法。我的问题：

我可以将这两个表添加到雪花图中，但这会感觉不对，因为我通常只使用这个图的外边缘上的子表聚合的表。
我可以为相关性创建另一个事实表，但是由于我想最终报告用户的相关性与他们在电影评级中的行为的相关性，我需要使用两个事实表，这对我来说是一种不正确的方法。

这里有什么指导吗？

Answer 1

你很有可能已经回答过自己，欢迎来到地狱。首先，来自http://www.information-management.com/的引文会对您感兴趣：

雪花结构将减少对尺寸的批量更新。尽管总是被认为比一颗星更慢，但一些测试显示扁平和雪花尺寸之间的性能没有差异。事实上，在某些情况下，雪花提供了优越的性能，例如当宽尺寸（即顾客）被分割成雪花时。

因此，使用桥接表不会导致性能的显着损失。我更喜欢雪花，因为有时候管理您的数据集市会更容易，而硬件/数据大小让您有机会这样做。

我友好的建议是创建桥表（movie_ID，category_ID，相关性）并继续。

如果您有固定和小类别列表，请使用预定义类别创建表格：

dim_movies
----------
movies_id
category1_relavance
category2_relavance
category3_relavance

最多十个也许没问题，特别是如果你为公司工作，你正在创建dwh，而不仅仅是咨询它（你可以管理）。

有一次，我们试图创建一个数据仓库的杰作，其中有一个类似于你的例子。付款交易是基于业绩（每个事实表的数据超过2TB）所以我们决定投入创建星型模式。

我们创建了像上面描述的维度，每次都没有。不同类别的增长etl在表中添加了新的字段。 ETL过程还必须动态重新创建多维数据集。它花了很多痛苦，但是我记得性能比雪花好13％。

此外，在最详尽的项目中，我相信10y.o的孩子会更好地设计数据库，我们必须每个项目连接5个类别。每个类别都指向20多个可能的表中的一个。它只能通过他们基于某些规则的软件加入。这是某种1 ... 5：很多关系（它不存在！？！）

pk     code_conto     cat1    cat2    cat3    cat4    cat5
----------------------------------------------------------
1      123            17      NULL    5467    12      NULL
2      124            67      1098    NULL    1423    AK12
3      123            NULL    NULL    NULL    13      23

代码是这样的：

If (code_conto == 123)
{
    Category1_join_set = 'SELECT cat_id, cat_name FROM cat_customers'; //NOTE THIS
    Category2_join_set = 'SELECT cat_id, cat_name FROM cat_products';
    Category3_join_set = 'SELECT cat_id, cat_name FROM cat_city';
    ...
    ...
}
    If (code_conto == 124)
{
    Category1_join_set = 'SELECT cat_id, cat_name FROM cat_products'; //AND THIS
    Category2_join_set = 'SELECT cat_id, cat_name FROM cat_origin';   //ON SAME FIELD
    Category3_join_set = 'SELECT cat_id, cat_name FROM cat_blabla';   //DIFFERENT JOIN TABLE
    ...
    ...
}

所有硬编码。所以我们在CASE声明中用100多次重复WHEN对我们的查询进行了硬编码。你猜怎么着？ ERP提供商“改进”他的软件并创建了映射表，其中“C”表示基于code_conto键的语句。我们花了超过3周的时间来提供良好且安全的ETL工作（使用SQL，外部工具）。

我没有写下这一切。我想说服你和其他人在多对多的关系中使用桥牌表可能是97％的最佳实践。

然而，M：M关系可能有五种设计解决方案：

数组或系列（我甚至不想尝试）
桥牌表
分组
固定级别
动态创建固定级别

希望我没有把你弄糊涂。

SnowFlake Diagram和多对多的关系

1 个答案: