數據倉庫架構設計 - 如何改進架構模型

我必須爲旅行社創建數據倉庫。我是第一次這樣做。我已經學習了關於星型，雪花和星座模式的基礎知識以及關於創建數據警報的基礎知識。我想問一下，如果這個設計總體上是好的，那麼可以改變什麼呢？數據倉庫架構設計 - 如何改進架構模型

這裏是我的尺寸層次：

這裏是我achived現在（在MySQL Workbench中創建模式）：

2017-04-02 anton86993

你能更具體地說明你在哪些方面遇到困難嗎？你的圖表是否顯示了你在昏暗中的所有領域？另外我不認爲付款類型應該包括年/月/日/小時/分 – Rich

我不是一個很大的分維的粉絲。一旦您開始介紹這些數據庫設計，它們就像標準的[OLTP]（https://en.wikipedia.org/wiki/Online_transaction_processing）一樣。這消除了星形模式提供的許多優點。例如：通過可視化工具的數據（如[PowerBI]（https://powerbi.microsoft.com/en-us/），[QlikView]（http://www.qlik.com/en-gb）等）更喜歡[Kimball]推薦的扁平尺寸表（https://en.wikipedia.org/wiki/Dimensional_modeling）。 –

想指出前兩個評論是基於以前版本的問題。 – Rich

以下是基於修訂後的問題的新答案。這個設計有很多你可能想看的東西。這裏有幾個指針但不是完整的列表：

你的DimTime維度應該是什麼粒度？通常情況下，日期/日期粒度具有日期維度，但在表格中它看起來像星期幾。
如果這對於分析銷售或滿意度評估時的重要性，您可以創建一個單獨的每日時間維度。
忠誠事實似乎是一段時間內客戶行爲的總結 - 應該是幾周？如果是這樣，你可以去一週的額外維度
爲什麼付款類型有幾秒鐘的時間呢？這似乎並不正確 - 付款類型不是每天都要花費幾秒鐘的時間。也許這是你缺少時間維度，付款類型應該是分開的？
產品維度是否應具有區域層次結構？你是否說如果產品在不同的城市，產品是不同的？你可能想再看一遍。

我相信其他的建議可以找到，祝您的課程好運！

來源

2017-04-04 13:13:57 Rich

1.我們希望從一年的開始日期，一個季度，一個月，一週，然後一週的一天，沒有時間的一天; 2.我想這僅僅是爲了教育目的而不是在現實生活中的實施，所以它不必如此詳細:)。我猜這很好。我們想在最大的一天檢查客戶的忠誠度，因爲它是旅行社。 4. PaymentType沒有秒。它有分鐘然後PaymentId或我不明白它; 5.在我的國家我們有省份，所以我想它應該被稱爲省而不是地區我是對嗎？ – anton86993

1.我同意，你不需要每天的時間，但它至少應該是'約會'。 4.爲什麼分鐘？付款類型是一種付款方式 - 與分鐘無關，我想！ 5.產品不是地區性的，就是我所說的。祝你學習好 – Rich

採取DimClient作爲例。你有一個很好的代理鍵。接下來，您需要填寫有關客戶的所有內容（包括clientID），然後還包括地區，城市，地區和國家/地區。當你擁有所有內容時，該維度就完成了。

您可以通過ClientKey將它鏈接到Fact表中，因此您需要將該Key作爲外鍵放入Fact表中。

通過與其他維度類似的過程，填充維度和事實，並且您將處於良好狀態。你不需要subdimensions來反映你的hiearchies：維度是非規範化的。

編輯：這個問題本來是完全不同的，因此上面的答案與其原始形式相關。

來源

2017-04-02 14:09:33 Rich

爲什麼我應該在這裏創建星型模式而不是雪花？我們的講師告訴我們要更像規範化的模式（雪花）。爲什麼？ – anton86993

我不知道你的講師爲什麼要你這樣做，但如果你想要好的分數，你應該可以做他們說的！如果你想用Kimball風格做一個尺寸模型，你應該儘可能地避免雪花（標準化），因爲這會降低以尺寸方式做事的好處。如果您想要雪花，請使用代理鍵創建子維度，然後使用維度中的外鍵將其鏈接到它們，如「正常」標準化模型。如果您有特定的問題，非常樂意提供幫助 - 只需詢問。 – Rich

只要我回家，我會做到這一點，並在這裏顯示我的結果:) – anton86993

數據倉庫架構設計 - 如何改進架構模型

回答

相關問題