成都創(chuàng)新互聯(lián)公司是專(zhuān)業(yè)的龍子湖網(wǎng)站建設(shè)公司，龍子湖接單;提供成都網(wǎng)站設(shè)計(jì)、網(wǎng)站制作,網(wǎng)頁(yè)設(shè)計(jì),網(wǎng)站設(shè)計(jì),建網(wǎng)站,PHP網(wǎng)站建設(shè)等專(zhuān)業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行龍子湖網(wǎng)站開(kāi)發(fā)網(wǎng)頁(yè)制作和功能擴(kuò)展;專(zhuān)業(yè)做搜索引擎喜愛(ài)的網(wǎng)站,專(zhuān)業(yè)的做網(wǎng)站團(tuán)隊(duì),希望更多企業(yè)前來(lái)合作!

維度建模的基本概念

維度建模是專(zhuān)門(mén)用于分析型數(shù)據(jù)庫(kù)、數(shù)據(jù)倉(cāng)庫(kù)、數(shù)據(jù)集市建模的方法。

它本身屬于一種關(guān)系建模方法，但和之前在操作型數(shù)據(jù)庫(kù)中介紹的關(guān)系建模方法相比增加了兩個(gè)概念：

1、維度表

表示對(duì)分析主題所屬類(lèi)型的描述。比如”昨天早上張三在京東花費(fèi)200元購(gòu)買(mǎi)了一個(gè)皮包”。那么以購(gòu)買(mǎi)為主題進(jìn)行分析，可從這段信息中提取三個(gè)維度：時(shí)間維度(昨天早上)，地點(diǎn)維度(京東), 商品維度(皮包)。通常來(lái)說(shuō)維度表信息比較固定，且數(shù)據(jù)量小。

2、事實(shí)表

表示對(duì)分析主題的度量。比如上面那個(gè)例子中，200元就是事實(shí)信息。事實(shí)表包含了與各維度表相關(guān)聯(lián)的外碼，并通過(guò)JOIN方式與維度表關(guān)聯(lián)。事實(shí)表的度量通常是數(shù)值類(lèi)型，且記錄數(shù)會(huì)不斷增加，表規(guī)模迅速增長(zhǎng)。

維度建模的三種模式

1、星形模式

星形模式(Star Schema)是最常用的維度建模方式，下圖展示了使用星形模式進(jìn)行維度建模的關(guān)系結(jié)構(gòu)：

可以看出，星形模式的維度建模由一個(gè)事實(shí)表和一組維表成，且具有以下特點(diǎn)：

維表只和事實(shí)表關(guān)聯(lián)，維表之間沒(méi)有關(guān)聯(lián)；

每個(gè)維表的主碼為單列，且該主碼放置在事實(shí)表中，作為兩邊連接的外碼；

以事實(shí)表為核心，維表圍繞核心呈星形分布；

2、雪花模式

雪花模式(Snowflake Schema)是對(duì)星形模式的擴(kuò)展，每個(gè)維表可繼續(xù)向外連接多個(gè)子維表。下圖為使用雪花模式進(jìn)行維度建模的關(guān)系結(jié)構(gòu)：

星形模式中的維表相對(duì)雪花模式來(lái)說(shuō)要大，而且不滿足規(guī)范化設(shè)計(jì)。雪花模型相當(dāng)于將星形模式的大維表拆分成小維表，滿足了規(guī)范化設(shè)計(jì)。然而這種模式在實(shí)際應(yīng)用中很少見(jiàn)，因?yàn)檫@樣做會(huì)導(dǎo)致開(kāi)發(fā)難度增大，而數(shù)據(jù)冗余問(wèn)題在數(shù)據(jù)倉(cāng)庫(kù)里并不嚴(yán)重。

3、星座模式

星座模式(Fact Constellations Schema)也是星型模式的擴(kuò)展。基于這種思想就有了星座模式：

前面介紹的兩種維度建模方法都是多維表對(duì)應(yīng)單事實(shí)表，但在很多時(shí)候維度空間內(nèi)的事實(shí)表不止一個(gè)，而一個(gè)維表也可能被多個(gè)事實(shí)表用到。在業(yè)務(wù)發(fā)展后期，絕大部分維度建模都采用的是星座模式。

4、三種模式對(duì)比

歸納一下，星形模式/雪花模式/星座模式的關(guān)系如下圖所示：

雪花模式是將星型模式的維表進(jìn)一步劃分，使各維表均滿足規(guī)范化設(shè)計(jì)。而星座模式則是允許星形模式中出現(xiàn)多個(gè)事實(shí)表。本文后面部分將具體講到這幾種模式的使用，請(qǐng)讀者結(jié)合實(shí)例體會(huì)。

實(shí)例：零售公司銷(xiāo)售主題的維度建模

在進(jìn)行維度建模前，首先要了解用戶需求。而筆者在數(shù)據(jù)庫(kù)系列的第一篇就講過(guò)，ER建模是當(dāng)前收集和可視化需求的最佳技術(shù)。因此假定和某零售公司進(jìn)行多次需求PK后，得到以下ER圖：

隨后可利用建模工具將ER圖直接映射到關(guān)系圖：

需求搜集完畢后，便可進(jìn)行維度建模了。本例采用星形模型維度建模。但不論采取何種模式，維度建模的關(guān)鍵在于明確下面四個(gè)問(wèn)題：

1、哪些維度對(duì)主題分析有用？

本例中，根據(jù)產(chǎn)品(PRODUCT)、顧客(CUSTOMER)、商店(STORE)、日期(DATE)對(duì)銷(xiāo)售額進(jìn)行分析是非常有幫助的；

2、如何使用現(xiàn)有數(shù)據(jù)生成維表？

維度PRODUCT可由關(guān)系PRODUCT，關(guān)系VENDOR，關(guān)系CATEGORY連接得到；

維度CUSTOMER和關(guān)系CUSTOMER相同；

維度STORE可由關(guān)系STROE和關(guān)系REGION連接得到；

維度CALENDAR由關(guān)系SALESTRANSACTION中的TDate列分離得到；

3、用什么指標(biāo)來(lái)”度量”主題？

本例的主題是銷(xiāo)售，而銷(xiāo)量和銷(xiāo)售額這兩個(gè)指標(biāo)最能直觀反映銷(xiāo)售情況；

4、如何使用現(xiàn)有數(shù)據(jù)生成事實(shí)表？

銷(xiāo)量和銷(xiāo)售額信息可以由關(guān)系SALESTRANSACTION和關(guān)系SOLDVIA，關(guān)系PRODUCT連接得到；

明確這四個(gè)問(wèn)題后，便能輕松完成維度建模：

細(xì)心的讀者會(huì)發(fā)現(xiàn)三個(gè)問(wèn)題：1. 維表不滿足規(guī)范化設(shè)計(jì)(不滿足3NF)；2. 事實(shí)表也不滿足規(guī)范化設(shè)計(jì)(1NF都不滿足)；3. 維度建模中各維度的主碼由***ID變成***Key；

對(duì)于前兩個(gè)問(wèn)題，由于當(dāng)前建模環(huán)境是數(shù)據(jù)倉(cāng)庫(kù)，而沒(méi)有更新操作，所以不需要嚴(yán)格做規(guī)范化設(shè)計(jì)來(lái)消除冗余避免更新異常。

因此雖然可以以雪花模型進(jìn)行維度建模，如下所示：

但這樣會(huì)加大查詢?nèi)藛T負(fù)擔(dān)：每次查詢都涉及到太多表了。因此在實(shí)際應(yīng)用中，雪花模型僅是一種理論上的模型。星座模型則出現(xiàn)在”維度建模數(shù)據(jù)倉(cāng)庫(kù)”中，本文后面將會(huì)講到。

對(duì)于第三個(gè)問(wèn)題，***Key這樣的字段被稱(chēng)為代理碼(surrogate key)，它是一個(gè)通過(guò)自動(dòng)分配整數(shù)生成的主碼，沒(méi)有任何其他意義。使用它主要是為了能夠處理”緩慢變化的維度”，本文后面會(huì)仔細(xì)分析這個(gè)問(wèn)題，這里不糾結(jié)。

更多可能的事實(shí)屬性

除了對(duì)應(yīng)到維度的外碼和度量屬性，事實(shí)表中還常常考慮另外兩個(gè)屬性：事務(wù)標(biāo)識(shí)碼和事務(wù)時(shí)間。

事務(wù)標(biāo)識(shí)碼通常被命名為T(mén)ID，其意義就是各種訂單號(hào)，事務(wù)編號(hào)…… 為什么將這個(gè)屬性放到事實(shí)表而不是維表中呢？一個(gè)主要原因是它的數(shù)量級(jí)太大了，這樣每次查詢都會(huì)耗費(fèi)很多資源來(lái)Join。這種將某些邏輯意義上的維度放到事實(shí)表里的做法被稱(chēng)為退化維度。

將事務(wù)時(shí)間維度放到事實(shí)表中的考慮也是出于相同考慮。然而這么設(shè)計(jì)又一次”逆規(guī)范化”了：事務(wù)標(biāo)識(shí)碼非主碼卻決定事務(wù)標(biāo)識(shí)時(shí)間，顯然違背了3NF。但現(xiàn)在我們是為數(shù)據(jù)倉(cāng)庫(kù)建模，所以這樣做是OK的。另外在分布式的數(shù)據(jù)倉(cāng)庫(kù)中，這個(gè)字段十分重要。因?yàn)槭聦?shí)表的數(shù)量級(jí)非常大，Hive或者Spark SQL這類(lèi)分布式數(shù)據(jù)倉(cāng)庫(kù)工具都會(huì)對(duì)這些數(shù)據(jù)進(jìn)行分區(qū)。任何成熟的分布式計(jì)算平臺(tái)中都應(yīng)禁止開(kāi)發(fā)人員建立非分區(qū)事實(shí)表，并默認(rèn)分區(qū)字段為(當(dāng)天)日期。

經(jīng)典星座模型

前文已經(jīng)講過(guò)，有多個(gè)事實(shí)表的維度模型被稱(chēng)為星座模型。星座模型主要有以下兩大作用：共享維度和設(shè)置細(xì)節(jié)/聚集事實(shí)表。下面分別對(duì)這兩種情況進(jìn)行分析：

1、共享維度

以前文提到的零售公司為例，假如該公司質(zhì)量監(jiān)管部門(mén)希望用分析銷(xiāo)售主題同樣的方法分析劣質(zhì)產(chǎn)品，那么此時(shí)不需要重新維度建模，只需往模型里加入一個(gè)新的劣質(zhì)產(chǎn)品事實(shí)表。之后新的數(shù)據(jù)倉(cāng)庫(kù)維度建模結(jié)果如下：

2、細(xì)節(jié)/聚集事實(shí)表

細(xì)節(jié)事實(shí)表(detailed fact tables)中每條記錄表示單一事實(shí)，而聚集事實(shí)表(aggregated fact tables)中每條記錄則聚合了多條事實(shí)。從表的字段上看，細(xì)節(jié)事實(shí)表通常有設(shè)置TID屬性，而聚集事實(shí)表則無(wú)。

兩種事實(shí)表各有優(yōu)缺點(diǎn)，細(xì)節(jié)事實(shí)表查詢靈活但是響應(yīng)速度相對(duì)慢，而聚集事實(shí)表雖然提高了查詢速度，但使查詢功能受到一定限制。一個(gè)常見(jiàn)的做法是使用星座模型同時(shí)設(shè)置兩種事實(shí)表(可含多個(gè)聚集事實(shí)表)。這種設(shè)計(jì)方法中，聚集事實(shí)表使用和細(xì)節(jié)事實(shí)表細(xì)節(jié)事實(shí)表的維度。如下維度建模方法采用星座模型綜合了細(xì)節(jié)事實(shí)表和兩種聚集事實(shí)表：

緩慢變化維度問(wèn)題

雖然，維表的數(shù)據(jù)比事實(shí)表更穩(wěn)定。但不論如何維度在某些時(shí)候總會(huì)發(fā)生一些變化。在之前曾拋出一個(gè)問(wèn)題：為什么維度建模后的關(guān)系不是***ID，而是***Key了。這樣做的目的其實(shí)就是為了解決一種被稱(chēng)為緩慢維度變化(slowly changing dimension)的問(wèn)題。在維度變化后，一部分歷史信息就被丟掉了。比如張三是某公司會(huì)員。

但僅僅這么做還是不夠的，代理碼需要配合時(shí)間戳，以及行標(biāo)識(shí)符使用才能解決緩慢維度變化的問(wèn)題。如下CUSTOMER表使用該方法避免緩慢維度變化：

可以看到用戶張三對(duì)應(yīng)新維度的TaxBracket狀態(tài)由Low變成了High。如果需要統(tǒng)計(jì)張三的相關(guān)行為，那么可以讓所有記錄用CustomerID字段Join事實(shí)表；如果要統(tǒng)計(jì)當(dāng)前TaxBracket為L(zhǎng)ow的用戶狀態(tài)，則可將Row Indicator字段為Current的記錄用CustomerKey字段Join事實(shí)表；如果要統(tǒng)計(jì)歷史TaxBracket狀態(tài)為L(zhǎng)ow的用戶情況，則只需要將TaxBracket屬性為L(zhǎng)ow的用戶記錄的CustomerKey屬性與事實(shí)表關(guān)聯(lián)。

數(shù)據(jù)倉(cāng)庫(kù)建模體系之規(guī)范化數(shù)據(jù)倉(cāng)庫(kù)

所謂”數(shù)據(jù)倉(cāng)庫(kù)建模體系”，指的是數(shù)據(jù)倉(cāng)庫(kù)從無(wú)到有的一整套建模方法。最常見(jiàn)的三種數(shù)據(jù)倉(cāng)庫(kù)建模體系分別為：規(guī)范化數(shù)據(jù)倉(cāng)庫(kù)，維度建模數(shù)據(jù)倉(cāng)庫(kù)，獨(dú)立數(shù)據(jù)集市。很多書(shū)將它們稱(chēng)為”數(shù)據(jù)倉(cāng)庫(kù)建模方法”，但筆者認(rèn)為數(shù)據(jù)倉(cāng)庫(kù)建模體系更能準(zhǔn)確表達(dá)意思，請(qǐng)?jiān)试S我自作主張一次吧：）。下面首先來(lái)介紹規(guī)范化數(shù)據(jù)倉(cāng)庫(kù)。

規(guī)范化數(shù)據(jù)倉(cāng)庫(kù)(normalized data warehouse)顧名思義，其中是規(guī)范化設(shè)計(jì)的分析型數(shù)據(jù)庫(kù)，然后基于這個(gè)數(shù)據(jù)庫(kù)為各部門(mén)建立數(shù)據(jù)集市。總體架構(gòu)如下圖所示：

該建模體系首先對(duì)ETL得到的數(shù)據(jù)進(jìn)行ER建模，關(guān)系建模，得到一個(gè)規(guī)范化的數(shù)據(jù)庫(kù)模式。然后用這個(gè)中心數(shù)據(jù)庫(kù)為公司各部門(mén)建立基于維度建模的數(shù)據(jù)集市。各部門(mén)開(kāi)發(fā)人員大都從這些數(shù)據(jù)集市提數(shù)，通常來(lái)說(shuō)不允許直接訪問(wèn)中心數(shù)據(jù)庫(kù)。

數(shù)據(jù)倉(cāng)庫(kù)建模體系之維度建模數(shù)據(jù)倉(cāng)庫(kù)

非維度建模數(shù)據(jù)倉(cāng)庫(kù)(dimensionally modeled data warehouse)是一種使用交錯(cuò)維度進(jìn)行建模的數(shù)據(jù)倉(cāng)庫(kù)，其總體架構(gòu)如下圖所示：

該建模體系首先設(shè)計(jì)一組常用的度集合(conformed dimension)，然后創(chuàng)建一個(gè)大星座模型表示所有分析型數(shù)據(jù)。如果這種一致維度不滿足某些數(shù)據(jù)分析要求，自然也可在數(shù)據(jù)倉(cāng)庫(kù)之上繼續(xù)構(gòu)建新的數(shù)據(jù)集市。

數(shù)據(jù)倉(cāng)庫(kù)建模體系之獨(dú)立數(shù)據(jù)集市

獨(dú)立數(shù)據(jù)集市的建模體系是讓公司的各個(gè)組織自己創(chuàng)建并完成ETL，自己維護(hù)自己的數(shù)據(jù)集市。其總體架構(gòu)如下圖所示：

從技術(shù)上來(lái)講這是一種很不值得推崇的方式，因?yàn)閷⑹剐畔⒎稚ⅲ绊懥似髽I(yè)全局范圍內(nèi)數(shù)據(jù)分析的效率。此外，各組織之間的ETL架構(gòu)相互獨(dú)立無(wú)法復(fù)用，也浪費(fèi)了企業(yè)的開(kāi)發(fā)資源。然而出于某些公司制度及預(yù)算方面的考慮，有時(shí)也會(huì)使用到這種建模體系。

三種數(shù)據(jù)倉(cāng)庫(kù)建模體系對(duì)比

規(guī)范化數(shù)據(jù)倉(cāng)庫(kù)和維度建模數(shù)據(jù)倉(cāng)庫(kù)分別是Bill Inmon和Ralph Kimball提出的方法。關(guān)于哪種方法更好，哪種方法更優(yōu)秀的爭(zhēng)論已經(jīng)由來(lái)已久。但隨著這兩種數(shù)據(jù)倉(cāng)庫(kù)應(yīng)用越來(lái)越多，人們也逐漸了解到兩種數(shù)據(jù)倉(cāng)庫(kù)的優(yōu)劣之處，如下表所示：

產(chǎn)生這些區(qū)別的根本之處在于規(guī)范化數(shù)據(jù)倉(cāng)庫(kù)需要對(duì)企業(yè)全局進(jìn)行規(guī)范化建模，這將導(dǎo)致較大的工作量。但這一步必須完成好，才能繼續(xù)往上建設(shè)數(shù)據(jù)集市。因此也就導(dǎo)致規(guī)范化數(shù)據(jù)倉(cāng)庫(kù)需要一定時(shí)間才能投入使用，敏捷性相對(duì)后者來(lái)說(shuō)略差。但是規(guī)范化數(shù)據(jù)倉(cāng)庫(kù)一旦建立好了，則以后數(shù)據(jù)就更易于管理。而且由于開(kāi)發(fā)人員不能直接使用其中心數(shù)據(jù)庫(kù)，更加確保了數(shù)據(jù)質(zhì)量。還有由于中心數(shù)據(jù)庫(kù)是采用規(guī)范化設(shè)計(jì)的，冗余情況也會(huì)更少。

然而另一方面維度建模數(shù)據(jù)倉(cāng)庫(kù)除了敏捷性更強(qiáng)，而且適用于業(yè)務(wù)變化比較頻繁的情況，對(duì)開(kāi)發(fā)人員的要求也沒(méi)有規(guī)范化數(shù)據(jù)倉(cāng)庫(kù)那么高。總之各有利弊，具體實(shí)施時(shí)需要仔細(xì)的權(quán)衡。

小結(jié)

數(shù)據(jù)倉(cāng)庫(kù)建模是一個(gè)綜合性技術(shù)，需要使用到ER建模、關(guān)系建模、維度建模等技術(shù)。而且當(dāng)企業(yè)業(yè)務(wù)復(fù)雜的時(shí)候，這部分工作更是需要專(zhuān)門(mén)團(tuán)隊(duì)與業(yè)務(wù)方共同合作來(lái)完成。因此一個(gè)優(yōu)秀的數(shù)據(jù)倉(cāng)庫(kù)建模團(tuán)隊(duì)既要有堅(jiān)實(shí)的數(shù)據(jù)倉(cāng)庫(kù)建模技術(shù)，還要有對(duì)現(xiàn)實(shí)業(yè)務(wù)清晰、透徹的理解。

互聯(lián)互通社區(qū)專(zhuān)注于IT互聯(lián)網(wǎng)交流與學(xué)習(xí)，關(guān)注公眾號(hào)：互聯(lián)互通社區(qū)，每日獲取最新報(bào)告并附帶專(zhuān)題內(nèi)容輔助學(xué)習(xí)。方案打造與宣講、架構(gòu)設(shè)計(jì)與執(zhí)行、技術(shù)攻堅(jiān)與培訓(xùn)、數(shù)據(jù)中臺(tái)等技術(shù)咨詢與服務(wù)合作請(qǐng)+微信：hulianhutongshequ

標(biāo)題名稱(chēng)：漫談數(shù)據(jù)倉(cāng)庫(kù)之維度建模-創(chuàng)新互聯(lián)
標(biāo)題路徑：http://chinadenli.net/article14/hhjde.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站建設(shè)、網(wǎng)站導(dǎo)航、Google、ChatGPT、移動(dòng)網(wǎng)站建設(shè)、標(biāo)簽優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)