雪花图与多对多关系

我有一张雪花图：

Fact: 
id_movie
id_user
rating

Dim Users:
id_user
...


Dim Movies:
id_movie
...

在我的ERD中，我还有一个表Category，它与电影有多对多的关系：

Dim_Category:
id_category
...

Map_Category_Movie:
id_movie
id_category
relevance

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

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

这里有什么指导吗？

---

解决方案

很有可能你已经对自己做出了回应，欢迎来到地狱。 首先，您会对http://www.information-management.com/中的报价感兴趣：

雪花结构将减少对维度的批量更新。虽然一直被认为比恒星慢，但一些测试表明，扁平维度和雪花维度在性能上没有区别。事实上，在某些情况下，雪花提供了卓越的性能，例如当较宽的维度(即，客户)被分割成雪花时。

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

我的友好建议是创建桥接表(MOVICE_ID、CATEGORY_ID、REALICATION)，然后继续。

如果您有固定的和较小的类别列表，请创建具有预定义类别的表：

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

最多10个也许可以，特别是如果您为公司工作，您创建的是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
    ...
    ...
}

都是硬编码的。因此，我们对查询进行了硬编码，重复了100多次When In Case语句。你猜怎么着？ERP供应商改进了他的软件，并创建了映射表，其中是基于CODE_CONTO键的‘C’IF语句。 我们花了3周多的时间来提供良好且安全的ETL工作(使用SQL、外部工具)。

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

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

1. 数组或系列(我甚至不想尝试)
2. 桥接表
3. 分组
4. 固定级别
5. 动态创建固定级别

希望我没有把您弄糊涂。