mysql - 雪花图和多对多关系

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

我正在尝试找到一种有效的方法来在雪花/星型模式中对此进行建模。我的问题:

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

这里有什么指导吗？

Answer 1

很有可能您已经对自己做出了回答并欢迎来到 hell 。一、引自http://www.information-management.com/你会感兴趣:

The snowflake structure will reduce batch updates to dimensions. Though always said to be slower than a star, some tests have revealed no difference in performance between flattened and snowflaked dimensions. In fact in some cases, the snowflake provides superior performance, such as when a wide dimension (i.e., customer) is segmented into a snowflake.

因此，使用桥接表不会导致性能显着下降。在大多数情况下，我更喜欢雪花，因为有时管理数据集市真的更容易，而且硬件/数据大小为您提供了这样做的机会。

我的友好建议是创建桥接表(movie_ID、category_ID、relevance)并继续。

如果您有固定和小的类别列表，请创建包含预定义类别的表:

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

最多 10 个也许没问题，尤其是如果您为创建 dwh 的公司工作，而不仅仅是咨询它(您可以管理)。

曾经，我们试图创建数据仓库的杰作，其中有一个与您类似的示例。付款交易基于性能(每个事实表的数据超过 2TB)，因此我们决定尝试创建星型模式。

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

此外，在最详尽的项目中，我相信 10 岁的 child 会更好地设计 DB，我们必须准确地将每个项目连接 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 语句中重复 WHEN 超过 100 次。你猜怎么了？ ERP 提供商“改进”了他的软件并创建了映射表，其中“C”是基于 code_conto 键的语句。我们花了 3 个多星期的时间来提供良好且安全的 ETL 作业(使用 SQL、外部工具)。

我不是白写了这一切。我想说服您和其他人，在多对多关系中使用桥接表可能是 97% 的最佳实践。

但是，有五种可能的 M:M 关系设计解决方案:

1. 数组或系列(我什至不想尝试)
2. 桥牌
3. 分组
4. 固定水平
5. 动态创建的固定关卡

希望我没有让您感到困惑。