為數(shù)據(jù)倉(cāng)庫(kù)或數(shù)據(jù)集市設(shè)計(jì)數(shù)據(jù)庫(kù)本質(zhì)上與為傳統(tǒng)OLTP系統(tǒng)設(shè)計(jì)數(shù)據(jù)庫(kù)有很大不同。事實(shí)上，對(duì)于這些純分析系統(tǒng)來(lái)說(shuō)，許多被普遍接受的設(shè)計(jì)OLTP數(shù)據(jù)庫(kù)的最佳實(shí)踐很可能被認(rèn)為是最糟糕的實(shí)踐。

因此，數(shù)據(jù)建模人員在設(shè)計(jì)數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)集市時(shí)必須掌握一些新技巧。盡管其中包含的一些建議可能與您感到舒適的內(nèi)容相反，但請(qǐng)保持開(kāi)放的心態(tài)。請(qǐng)記住，宋飛的喬治·科斯坦扎（GeorgeCostanza）并沒(méi)有在紐約洋基隊(duì)找到理想的工作，直到他接受了與他所有想法相反的做法，如下面的視頻剪輯所示。所以，放棄任何舊的OLTP設(shè)計(jì)。

云數(shù)據(jù)建模：良好的數(shù)據(jù)庫(kù)設(shè)計(jì)意味著“適當(dāng)?shù)拇笮　焙凸?jié)約

正如本博客系列的第1部分一樣，云不是涅盤。是的，它提供了本質(zhì)上無(wú)限可擴(kuò)展的資源。但你必須為使用它們付費(fèi)。當(dāng)您為部署到云端的應(yīng)用程序做出糟糕的數(shù)據(jù)庫(kù)設(shè)計(jì)選擇時(shí)，您的公司將每月為所有不可避免的低效支付費(fèi)用。靜態(tài)過(guò)度配置或動(dòng)態(tài)擴(kuò)展會(huì)在一個(gè)糟糕的設(shè)計(jì)上迅速增加每月的云成本。所以，您真的應(yīng)該熟悉云提供商的規(guī)模與成本計(jì)算器。

請(qǐng)看下面的圖1。它顯示了一個(gè)只有4TB數(shù)據(jù)的數(shù)據(jù)倉(cāng)庫(kù)項(xiàng)目的定價(jià)，按照今天的標(biāo)準(zhǔn)，這個(gè)價(jià)格很低。我選擇了“隨需應(yīng)變”來(lái)支持多達(dá)64個(gè)虛擬CPU和448GB的內(nèi)存，因?yàn)槲蚁Ｍ@個(gè)數(shù)據(jù)倉(cāng)庫(kù)能夠完全或至少大部分位于內(nèi)存中，以實(shí)現(xiàn)閃電般的快速訪問(wèn)。因此，僅在云中運(yùn)行這一個(gè)數(shù)據(jù)倉(cāng)庫(kù)每年就需要136000美元。如果我能減少CPU和內(nèi)存需求，我就能顯著降低成本。所以，我不想為了安全而過(guò)度提供。我想從第一天起根據(jù)一個(gè)良好的數(shù)據(jù)庫(kù)設(shè)計(jì)來(lái)調(diào)整這個(gè)大小，這個(gè)數(shù)據(jù)庫(kù)設(shè)計(jì)不會(huì)因?yàn)榈托У脑O(shè)計(jì)而浪費(fèi)資源。

　　圖1: AWS中4TB數(shù)據(jù)倉(cāng)庫(kù)的定價(jià)

現(xiàn)在，我們將介紹一些數(shù)據(jù)建?；A(chǔ)知識(shí)，這些基礎(chǔ)知識(shí)無(wú)論是在本地還是在云中都適用。

要認(rèn)識(shí)和理解的第一件也是最重要的一件事是您現(xiàn)在正在為其設(shè)計(jì)數(shù)據(jù)模型的新的、完全不同的目標(biāo)環(huán)境。

　　圖2：數(shù)據(jù)庫(kù)設(shè)計(jì)特征

主要的底層設(shè)計(jì)原則是，與OLTP系統(tǒng)相比，用戶運(yùn)行的請(qǐng)求數(shù)量相對(duì)較少，OLTP系統(tǒng)掃描超大表中的數(shù)十萬(wàn)到數(shù)百萬(wàn)行，并應(yīng)用聚合函數(shù)將數(shù)據(jù)匯總到少量輸出行中。對(duì)于這個(gè)目標(biāo)環(huán)境，您不希望像在OLTP系統(tǒng)中那樣規(guī)范化數(shù)據(jù)。事實(shí)上，引用電影《年輕的弗蘭肯斯坦》（Young Frankenstein）中的一句話，讓你的大腦工作“abby normal”（艾比正常）會(huì)讓你受益匪淺。

星型模式：數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)湖的數(shù)據(jù)建模和數(shù)據(jù)庫(kù)設(shè)計(jì)范例

拉爾夫·金博爾（RalphKimball）為此開(kāi)發(fā)了一種數(shù)據(jù)建模和數(shù)據(jù)庫(kù)設(shè)計(jì)范式，稱為維度建模和/或星型模式設(shè)計(jì)。我第一次見(jiàn)到拉爾夫是在20世紀(jì)90年代初，當(dāng)時(shí)我參加了他的一次研討會(huì)。我當(dāng)時(shí)在埃爾文的老家Logic Works工作，向拉爾夫展示了數(shù)據(jù)建模工具如何利用他的理想。我在2003年出版了第一本書(shū)，展示了我如何使用拉爾夫的技術(shù)在Oracle數(shù)據(jù)庫(kù)中創(chuàng)建大型數(shù)據(jù)倉(cāng)庫(kù)。

星型模式設(shè)計(jì)實(shí)際上非常簡(jiǎn)單。只有兩種類型的實(shí)體和/或表：

• 維度：較小的非規(guī)范化表，其中包含最終用戶查詢的業(yè)務(wù)描述性列
• 事實(shí)：非常大的表，主鍵由相關(guān)維度表外鍵列串聯(lián)而成，并且具有數(shù)字相加的非鍵列，用于最終用戶查詢期間的計(jì)算

讓我們以一個(gè)簡(jiǎn)單的現(xiàn)有OLTP數(shù)據(jù)模型為例，看看如何將其轉(zhuǎn)換為星型模式設(shè)計(jì)。

　　圖3:OLTP銷售點(diǎn)系統(tǒng)的數(shù)據(jù)模型

這是OLTP便利店銷售點(diǎn)和訂購(gòu)系統(tǒng)的數(shù)據(jù)模型。我把它淡化了一點(diǎn)，使之足夠簡(jiǎn)單，可以作為一個(gè)例子。請(qǐng)注意各種顏色，它們基本上表示此數(shù)據(jù)模型中類似實(shí)體的主題區(qū)域。因此，在步驟#1中，我們只需確定所有維度和事實(shí)。黃色實(shí)體向下展平到store維度，洋紅實(shí)體向下展平到product維度。綠色實(shí)體根本沒(méi)有被納入數(shù)據(jù)模型，白色實(shí)體成為事實(shí)。

　　圖4：添加關(guān)系之前銷售點(diǎn)系統(tǒng)的邏輯數(shù)據(jù)模型

那么，這一時(shí)期和促銷實(shí)體是從哪里來(lái)的呢？嗯，在大多數(shù)數(shù)據(jù)倉(cāng)庫(kù)中，您都需要一個(gè)時(shí)間維度，因?yàn)闃I(yè)務(wù)用戶希望看到給定日期的數(shù)據(jù)。所以，你總是會(huì)有一些時(shí)間維度。促銷實(shí)體是新的，因?yàn)闃I(yè)務(wù)用戶告訴我們，他們希望通過(guò)數(shù)據(jù)倉(cāng)庫(kù)能夠看到的關(guān)鍵項(xiàng)目之一是他們的促銷效果如何。

至于第#2步，這很容易——只需添加事實(shí)與其所有維度之間的關(guān)系。請(qǐng)注意，所有關(guān)系都是標(biāo)識(shí)的?？吹胶阈侵行牡氖聦?shí)了嗎？因此命名為星型模式。

　　圖5：添加關(guān)系后銷售點(diǎn)系統(tǒng)的邏輯數(shù)據(jù)模型

如果幸運(yùn)的話，您的數(shù)據(jù)建模工具將為星形模式設(shè)計(jì)提供圖表支持。在這里，我們看到歐文提供了這樣一個(gè)功能。然而，許多其他數(shù)據(jù)建模工具不提供此功能。

　　圖6：銷售點(diǎn)系統(tǒng)物理數(shù)據(jù)模型的星型模式顯示格式

現(xiàn)在只剩下將OLTP數(shù)據(jù)模型中的所有屬性放置到我們的一個(gè)維度或事實(shí)中。你最終會(huì)得到一個(gè)類似這樣的模型。

　　圖7：放置OLTP系統(tǒng)的所有屬性并創(chuàng)建一些新的聚合事實(shí)后的星型模式物理數(shù)據(jù)模型

您可以預(yù)掃描和預(yù)聚合數(shù)據(jù)以加快查詢速度

你是否注意到銷售概念被分解為三個(gè)獨(dú)立的事實(shí)？在與業(yè)務(wù)用戶交談時(shí)，我們發(fā)現(xiàn)他們通常希望每周或每月報(bào)告或分析。因此，我們構(gòu)建了一些事實(shí)，這些事實(shí)基本上是基本事實(shí)的聚合，因此，我們基本上預(yù)掃描和預(yù)聚合了一些數(shù)據(jù)，以加速這些查詢。

創(chuàng)造這樣的綜合事實(shí)是很正常的。它們不必像前面的示例中所示的那樣是簡(jiǎn)單的基于時(shí)間的。它可以是按地區(qū)或時(shí)區(qū)，甚至是按感興趣的產(chǎn)品。例如，本例中的便利店公司有一個(gè)德克薩斯總公司和一個(gè)啤酒總公司，如圖所示，因?yàn)樗麄兊目偛课挥诘驴怂_斯州，啤酒占所有利潤(rùn)的30%以上。事實(shí)上，“啤酒人”是公司的第三位高管，所以他們應(yīng)該得到自己的總數(shù)。

　　圖8：創(chuàng)建了一些新的、特定于業(yè)務(wù)且合理的事實(shí)后的星型模式物理數(shù)據(jù)模型

不要阻止優(yōu)化器看到它是一個(gè)星形模式

最后，在星型模式設(shè)計(jì)中要避免的一件事是snowflaking（這與Snowflake數(shù)據(jù)庫(kù)無(wú)關(guān)）。許多數(shù)據(jù)庫(kù)優(yōu)化器識(shí)別星型模式，并具有按數(shù)量級(jí)優(yōu)化其執(zhí)行的代碼。但是，您不能向圖片中添加任何使優(yōu)化器看不到它是星型模式的內(nèi)容，甚至使其變得復(fù)雜。下面是一個(gè)雪花添加到我們之前的星型模式模型中的示例。

　　圖9：一個(gè)snowflaking的例子使優(yōu)化器無(wú)法看到它是一個(gè)星形模式

雖然添加類別和子類別作為規(guī)范化工作可能是有意義的，但額外的關(guān)系層通常會(huì)混淆數(shù)據(jù)庫(kù)優(yōu)化器，從而導(dǎo)致查詢執(zhí)行時(shí)間大大降低。所以請(qǐng)避免snowflaking。

正如我們?cè)诒静┛椭锌吹降?，?shù)據(jù)倉(cāng)庫(kù)的數(shù)據(jù)建模與OLTP系統(tǒng)的數(shù)據(jù)建模非常不同。但是，有一些技術(shù)可以產(chǎn)生非常成功的數(shù)據(jù)倉(cāng)庫(kù)，還有一些數(shù)據(jù)建模工具，如erwin，旨在支持使用此類功能進(jìn)行建模。