雪花圖與多對多關系-魔扣目錄

本文介紹了雪花圖與多對多關系的處理方法，對大家解決問題具有一定的參考價值，需要的朋友們下面隨著小編來一起學習吧！

問題描述

我有一張雪花圖：

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關系設計解決方案：

希望我沒有把您弄糊涂。

這篇關于雪花圖與多對多關系的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，