雲資料建模：為資料倉儲設計資料庫

　為資料倉儲或資料集市設計資料庫本質上與為傳統OLTP系統設計資料庫有很大不同。事實上，對於這些純分析系統來說，許多被普遍接受的設計OLTP資料庫的最佳實踐很可能被認為是最糟糕的實踐。

　　因此，資料建模人員在設計資料倉儲和資料集市時必須掌握一些新技巧。儘管其中包含的一些建議可能與您感到舒適的內容相反，但請保持開放的心態。請記住，宋飛的喬治·科斯坦扎（GeorgeCostanza）並沒有在紐約洋基隊找到理想的工作，直到他接受了與他所有想法相反的做法，如下面的視訊剪輯所示。所以，放棄任何舊的OLTP設計。

　　雲資料建模：良好的資料庫設計意味著“適當的大小”和節約

　　正如本部落格系列的第1部分一樣，雲不是涅盤。是的，它提供了本質上無限可擴充套件的資源。但你必須為使用它們付費。當您為部署到雲端的應用程式做出糟糕的資料庫設計選擇時，您的公司將每月為所有不可避免的低效支付費用。靜態過度配置或動態擴充套件會在一個糟糕的設計上迅速增加每月的雲成本。所以，您真的應該熟悉雲提供商的規模與成本計算器。

　　請看下面的圖1。它顯示了一個只有4TB資料的資料倉儲專案的定價，按照今天的標準，這個價格很低。我選擇了“隨需應變”來支援多達64個虛擬CPU和448GB的記憶體，因為我希望這個資料倉儲能夠完全或至少大部分位於記憶體中，以實現閃電般的快速訪問。因此，僅在雲中執行這一個資料倉儲每年就需要136000美元。如果我能減少CPU和記憶體需求，我就能顯著降低成本。所以，我不想為了安全而過度提供。我想從第一天起根據一個良好的資料庫設計來調整這個大小，這個資料庫設計不會因為低效的設計而浪費資源。

　　圖1: AWS中4TB資料倉儲的定價

　　現在，我們將介紹一些資料建模基礎知識，這些基礎知識無論是在本地還是在雲中都適用。

　　要認識和理解的第一件也是最重要的一件事是您現在正在為其設計資料模型的新的、完全不同的目標環境。

　　圖2：資料庫設計特徵

　　主要的底層設計原則是，與OLTP系統相比，使用者執行的請求數量相對較少，OLTP系統掃描超大表中的數十萬到數百萬行，並應用聚合函式將資料彙總到少量輸出行中。對於這個目標環境，您不希望像在OLTP系統中那樣規範化資料。事實上，引用電影《年輕的弗蘭肯斯坦》（Young Frankenstein）中的一句話，讓你的大腦工作“abby normal”（艾比正常）會讓你受益匪淺。

　　 星型模式：資料倉儲和資料湖的資料建模和資料庫設計範例

　　拉爾夫·金博爾（RalphKimball）為此開發了一種資料建模和資料庫設計正規化，稱為維度建模和/或星型模式設計。我第一次見到拉爾夫是在20世紀90年代初，當時我參加了他的一次研討會。我當時在埃爾文的老家Logic Works工作，向拉爾夫展示了資料建模工具如何利用他的理想。我在2003年出版了第一本書，展示了我如何使用拉爾夫的技術在Oracle資料庫中建立大型資料倉儲。

　　星型模式設計實際上非常簡單。只有兩種型別的實體和/或表：

　　維度：較小的非規範化表，其中包含終端使用者查詢的業務描述性列

　　事實：非常大的表，主鍵由相關維度表外來鍵列串聯而成，並且具有數字相加的非鍵列，用於終端使用者查詢期間的計算

　　讓我們以一個簡單的現有OLTP資料模型為例，看看如何將其轉換為星型模式設計。

　　圖3:OLTP銷售點系統的資料模型

　　這是OLTP便利店銷售點和訂購系統的資料模型。我把它淡化了一點，使之足夠簡單，可以作為一個例子。請注意各種顏色，它們基本上表示此資料模型中類似實體的主題區域。因此，在步驟#1中，我們只需確定所有維度和事實。黃色實體向下展平到store維度，洋紅實體向下展平到product維度。綠色實體根本沒有被納入資料模型，白色實體成為事實。

　　圖4：新增關係之前銷售點系統的邏輯資料模型

　　那麼，這一時期和促銷實體是從哪裡來的呢？嗯，在大多數資料倉儲中，您都需要一個時間維度，因為業務使用者希望看到給定日期的資料。所以，你總是會有一些時間維度。促銷實體是新的，因為業務使用者告訴我們，他們希望通過資料倉儲能夠看到的關鍵專案之一是他們的促銷效果如何。

　　至於第#2步，這很容易——只需新增事實與其所有維度之間的關係。請注意，所有關係都是標識的。看到恆星中心的事實了嗎？因此命名為星型模式。

　　圖5：新增關係後銷售點系統的邏輯資料模型

　　如果幸運的話，您的資料建模工具將為星形模式設計提供圖表支援。在這裡，我們看到歐文提供了這樣一個功能。然而，許多其他資料建模工具不提供此功能。

　　圖6：銷售點系統物理資料模型的星型模式顯示格式

　　現在只剩下將OLTP資料模型中的所有屬性放置到我們的一個維度或事實中。你最終會得到一個類似這樣的模型。

　　圖7：放置OLTP系統的所有屬性並建立一些新的聚合事實後的星型模式物理資料模型

　　 您可以預掃描和預聚合資料以加快查詢速度

　　你是否注意到銷售概念被分解為三個獨立的事實？在與業務使用者交談時，我們發現他們通常希望每週或每月報告或分析。因此，我們構建了一些事實，這些事實基本上是基本事實的聚合，因此，我們基本上預掃描和預聚合了一些資料，以加速這些查詢。

　　創造這樣的綜合事實是很正常的。它們不必像前面的示例中所示的那樣是簡單的基於時間的。它可以是按地區或時區，甚至是按感興趣的產品。例如，本例中的便利店公司有一個德克薩斯總公司和一個啤酒總公司，如圖所示，因為他們的總部位於德克薩斯州，啤酒佔所有利潤的30%以上。事實上，“啤酒人”是公司的第三位高管，所以他們應該得到自己的總數。

　　圖8：建立了一些新的、特定於業務且合理的事實後的星型模式物理資料模型

　 　不要阻止優化器看到它是一個星形模式

　　最後，在星型模式設計中要避免的一件事是snowflaking（這與Snowflake資料庫無關）。許多資料庫優化器識別星型模式，並具有按數量級優化其執行的程式碼。但是，您不能向圖片中新增任何使優化器看不到它是星型模式的內容，甚至使其變得複雜。下面是一個雪花新增到我們之前的星型模式模型中的示例。

　　圖9：一個snowflaking的例子使優化器無法看到它是一個星形模式

　　雖然新增類別和子類別作為規範化工作可能是有意義的，但額外的關係層通常會混淆資料庫優化器，從而導致查詢執行時間大大降低。所以請避免snowflaking。

　　正如我們在本部落格中看到的，資料倉儲的資料建模與OLTP系統的資料建模非常不同。但是，有一些技術可以產生非常成功的資料倉儲，還有一些資料建模工具，如erwin，旨在支援使用此類功能進行建模。