如何避免星型模式中的複雜連接？

Question

我的事實表在他參加的課程中包含用戶分數。我必須在報告中展示的一些課程細節來自多個表格（在實際的OLTP db中）。
我是否在維度表中創建該課程條目的非規範化版本？
還是我只是直接加入事實表的課程表連接，以介紹這門課程（course_type，教師誰創造了這門課程等）

Answer 1

也許我不明白你的問題的其他表，但一個事實表在星型模式中應該被加入到圍繞它的維度表中。 如果您不想進行連接，只需創建一個視圖，然後使用視圖進行報告。

如果你發佈一個模式（schema），它會更容易發表評論/幫助。

Answer 2

Snowflaking或橋接表來使連接更加複雜，並不僅僅是從編碼的角度看，這也使得它成爲BI用戶較少簡單。

在大多數情況下，我會將這些直接放在現有的或附加的維度表中。

例如，你有一個分數的事實表，它在其中可能會或可能不會對用戶持有人口統計維度用戶詳細信息（或許只有一橋）。有時候最好分解出人口統計信息。因此，儘管性別和年齡可能與用戶實體相關聯，但在維度模型中，這些維度可能是單個維度或集中到一個維度 - 這取決於使用場景。

也許你的分數附加到一個州和州有地區（雪花）。將區域維度直接連接起來而不是通過狀態維度可能更有效。

我想你會發現的是，維模型是一個非常務實的非規範化的做法。主要的事情是不可談判的事實 - 之後，維度的選擇非常瞭解數據的行爲，您對常見使用場景的遠見 - 並避免陷入太少維度和太多維度問題。

Answer 3

將多個維度合併在一起是常見的做法，犧牲正常化有利於性能。這通常是在你的典型查詢需要所有維度的時候完成的（而不是在不同的用例中使用不同的位）。

還記得，當您收到加入開銷的減少，也有一些缺點：

• 失去彈性，如倉庫擴展
• 全表掃描的時間可能妨礙發展（傳統基於行的RDBMS如SQL Server）
• 磁盤空間的消耗

您必須單獨考慮每種情況。

這可能是值得也考慮創建物化視圖的選擇，如果這種能力是由你的RDBMS提供。

Answer 4

我們通常將雪花模式作爲物理DWH設計，但添加了一個報告視圖層，將雪花模式平滑爲星形模式。

這樣，您的OLAP多維數據集就變得簡單多了，而且更容易管理。