星型模式設計

Question

星型模式設計對於數據倉庫至關重要嗎？或者你可以用另一種設計模式來做數據倉庫嗎？

Answer 1

將star schemas用於數據倉庫系統可以帶來諸多好處，在大多數情況下，將它們用於頂層是合適的。您也可能擁有一個運營數據存儲（ODS） - 一種標準化的結構，可保存「當前狀態」並便於操作，如數據確認。但是，在有些情況下，這是不可取的。我曾經有機會構建帶有或不帶有ODS層的系統，並且在每種情況下都有選擇架構的具體原因。

沒有進入數據倉庫架構的subtlties或開始博爾與Inmon火焰戰爭星型模式的主要好處是：

• 大多數數據庫管理系統 有設施在查詢優化器 做「星型變換」 使用Bitmap Index結構或 Index Intersection爲快速 謂詞解析。這意味着從星型模式中進行選擇可以在命中表（通常比索引大得多）之前完成，直到解決選擇。

• Partitioning星型模式相對簡單，因爲只有事實表需要分區（除非你有一些符合聖經的大尺寸）。Partition elimination意味着查詢優化器可以忽略不可能參與查詢結果的分支，這節省了I/O。

• Slowly changing dimensions在星型模式上實現比在雪花上更容易實現。

• 該模式更容易理解，並且往往涉及的連接數比snowflake或E-R模式少。你的報道團隊會愛你這個

• 星形模式更容易使用和（更重要的）讓與即席查詢工具，如Business Objects或Report Builder表現良好。作爲開發人員，您幾乎無法控制這些工具生成的SQL，所以您需要儘可能多地爲查詢優化器提供幫助。星型模式使得查詢優化器相對來說很少有錯誤的機會。

通常，除非你有特殊原因不能到您的報告層將使用星型模式。如果您有多個源系統，則可能需要使用規範化或雪花模式實施Operational Data Store以累積數據。這很容易，因爲ODS通常不會做歷史。歷史狀態在星型模式中進行跟蹤，這比標準化結構更容易實現。規範化或雪花化的操作數據存儲體現了「當前」狀態，並且沒有超出數據固有的歷史視圖。

ODS加載過程涉及數據清理和符合性，這與標準化結構相比更容易實現。一旦在ODS中擁有乾淨的數據，維度和事實負載就可以相對簡單地使用通用或相對簡單的機制來跟蹤歷史記錄（隨時間變化）;這對於星型模式來說要容易得多，許多ETL工具（例如）提供了用於緩慢變化維度的內置工具，並且實現通用機制相對簡單。

分層這樣的系統providies職責的分離 - 業務和數據清理邏輯在ODS處理和星型模型的負載處理歷史狀態。

Answer 2

關於星型模式的事情是，他們是這樣的東西大多數人都希望有一個數據倉庫做一個自然的模型。例如，生成具有不同粒度級別（例如月份或日期或年份）的報告很容易。將典型的業務數據插入星型模式也是有效的，這也是數據倉庫的一個常見且重要的特性。

你當然可以用任何一種你想要的，但除非你知道你的業務領域非常好，很可能您的報表將不能有效，因爲他們可以，如果你用了一個星型模式運行的數據庫。

Answer 3

星型模式用於實現對大量數據的高速訪問。通過減少對可能針對主題區域進行查詢所需的連接數量，可以實現高性能。這是通過在維度表中允許數據冗餘來完成的。

您必須記住，星型模式是倉庫頂層的模式。所有模型還涉及在倉庫堆棧底部登臺架構，還有一些還包括一個持久變換的合併登臺區域，其中所有源系統都合併到3NF建模架構中。各個主題領域都位於此之上。

頂級模式的替代方案包括一個變體，這是一個雪花模式。 Dan Linstedt提出的一種新方法也可以進行一些調查。

Answer 4

星型模式非常適合數據倉庫的最後一層。你如何到達另一個問題。據我所知，有兩個大營，比爾·因蒙和拉爾夫·金博爾。如果/當你決定和一個明星一起去時，你可能想看看這兩個傢伙的理論。

此外，一些報告工具非常喜歡星型架構設置。如果您被鎖定到特定的報告工具，那麼這可能會推動倉庫中報告集市的外觀。

Answer 5

可能沒有。然而，你會爲自己付出生命 - 你的組織會希望使用生活在DW之上的標準工具，並且這些工具會期望一個星型模式 - 將花費大量精力在一輪中安裝一個方形栓釘孔。

許多數據庫級別的優化假設您有一個星型模式;您將花費大量的時間進行優化和重組，以便讓數據庫以您不太明朗的佈局來做「正確的事情」。

確保利大於弊..

（聽起來是不是像我以前去過那裏？）

-D

Answer 6

星型模式是關係一個邏輯數據模型符合常規數據倉庫需求的數據庫;如果給出了關係環境，則星型或雪花型架構將成爲一種很好的設計模式，在許多DW設計方法中都是硬連線的。

然而有比關係型數據庫引擎等過了，他們可用於高效的數據倉庫。多維存儲引擎對於OLAP任務可能非常快（例如，TM1）;我們不能在這種情況下應用星型模式設計。其他需要特殊邏輯模型的例子包括XML數據庫或列式數據庫（例如實驗C-store)）。

Answer 7

有一個在datawarehousing litterature正在進行的辯論有關其中在數據倉庫架構的Star-Schema設計應適用。

總之Kimball倡導者非常高僅使用在數據倉庫的星型模式設計，同時Inmon首先要建立使用normalized 3NF設計企業數據倉庫，後來使用星型模式設計的數據集市。

另外在這裏你也可以說Snowflake schema design是另一種方法。

第四種設計可能是Data Vault Modeling的方法。

Answer 8

我們需要解決三個問題。

1）如何獲得數據輸出的操作源系統的不施壓，它們由內和它們之間的連接表，清洗數據作爲我們提取，創建派生等

2）如何合併來自不同來源的數據 - 來自不同部門的一些遺留文件，基於文件的文件，形成一個完整的，準確的，高效存儲的整體，用於對業務進行建模，而不反映源系統的結構。請記住，系統更換/更換速度相對較快，但業務的基本模式變化緩慢。

3）如何構建數據以儘可能快速和準確地滿足特定業務部門的特定分析和報告要求。

解決這三個非常不同的問題需要不同的體系結構層來解決這些問題

臨時層 我們複製的來源結構，而只是改變了從源數據每天晚上被加載。一旦數據從暫存層進入下一層，數據就會被丟棄。查詢是帶有簡單數據時間過濾器的單表查詢。對來源影響很小。

企業層 這是一個面向業務的第三範式數據庫。數據從分段層提取（並隨後丟棄）到企業層，在那裏進行清理，集成和規範化。

演示文稿（星型模式）圖層 在這裏，我們用尺寸模型來滿足特定要求。數據有意解除標準化以減少連接數量。可能在企業層中佔用多個表的層次結構會摺疊爲單個維度表，並且多個事務表可能會合併到單個事實表中。

你總是面對這三個問題。如果您選擇取消企業層，您仍然需要解決第二個問題，但是您必須在星型模式層中執行此操作，並且在我看來，這是做錯的地方。