引用：https://zhuanlan.zhihu.com/p/111979066

1 維度表的定義

在維度建模中，通常將指標(biāo)的度量稱之為“事實(shí)”，將產(chǎn)生度量的環(huán)境稱之為“維度”。將描述同一個(gè)業(yè)務(wù)實(shí)體的的多個(gè)維度列組合在一起，就是常說的“維度表”。維度表是用戶分析數(shù)據(jù)的窗口，其提供了事件發(fā)生過程中的環(huán)境描述信息，能夠做數(shù)據(jù)查詢的過濾條件和數(shù)據(jù)分析的分組。維度設(shè)計(jì)既是維度建模的基礎(chǔ)，也是其關(guān)鍵所在，可以說，維度表設(shè)計(jì)的質(zhì)量，將決定了整個(gè)維度模型分析能力的上限。

2 維度表的構(gòu)成

維度表通常表示的是參與到業(yè)務(wù)過程中的一個(gè)業(yè)務(wù)實(shí)體（如，商品、賣家、買家、優(yōu)惠券、時(shí)間等等），其每一行數(shù)據(jù)表示的是一個(gè)業(yè)務(wù)實(shí)體的實(shí)例（如，商品維度表中的一行表示的就是一個(gè)商品）。

2.1 維度表的結(jié)構(gòu)

維度表一般由【代理鍵、自然鍵、維度屬性】三部分構(gòu)成。如果有保留維度變化歷史或大型維度表的拆分需求，可能還會加入其它部分以做技術(shù)實(shí)現(xiàn)上的補(bǔ)充。

代理鍵：不具有任何業(yè)務(wù)含義，僅做維度表數(shù)據(jù)唯一性區(qū)分的屬性，通常以主鍵形式出現(xiàn)。
自然鍵：具有業(yè)務(wù)含義，是業(yè)務(wù)實(shí)體一個(gè)實(shí)例的唯一性區(qū)分（如，商品ID），在維度表中不一定做表的主鍵。
維度屬性：描述同一業(yè)務(wù)實(shí)體各種特征的維度列（如，商品維度表中的商品名稱、商品價(jià)格等）。

維度表中的代理鍵，會根據(jù)分析的需求決定是否存在，如果沒有需要保留追溯業(yè)務(wù)實(shí)體歷史變化的需求，一般情況會用自然鍵直接做為維度表的主鍵，這樣通常簡單、高校、且易于理解。代理鍵的存在主要是應(yīng)對處理變化維度的需求。

2.2 維度表的內(nèi)容

3 設(shè)計(jì)方法

維度表的設(shè)計(jì)就是確定維度屬性的過程，如何識別維度屬性、如何生成維度屬性，將是設(shè)計(jì)過程中需要著重考慮的地方。

3.1 維度表設(shè)計(jì)流程

3.1.1 選擇實(shí)體

維度表設(shè)計(jì)首先要選擇實(shí)體，也就是維度表所要描述的抽象對象。如，互聯(lián)網(wǎng)電商在交易過程中涉及到的實(shí)體有：買家、賣家、訂單、廣告等等，當(dāng)然還有一些在不同業(yè)務(wù)場景下衍生出來的一些業(yè)務(wù)抽象實(shí)體，如優(yōu)惠券、活動、商圈等都可以作為維度實(shí)體。 實(shí)體的選擇主要是結(jié)合業(yè)務(wù)流程，在需要建模的業(yè)務(wù)流程環(huán)節(jié)涉及到了哪些參與者，這些不同的參與者便是維度表描述的實(shí)體對象，維度表中的屬性，就是用來區(qū)分不同實(shí)體的特性。下面用電商平臺的注冊環(huán)節(jié)舉例說明，電商網(wǎng)站的注冊，自然需要買家進(jìn)行注冊賬號和個(gè)人信息，其中涉及買家(即消費(fèi)者)實(shí)體。

3.1.2 確定主維表

確定主維表，主要是識別出維度表的主要數(shù)據(jù)來源。通常，業(yè)務(wù)系統(tǒng)中也會將相同類型業(yè)務(wù)實(shí)體進(jìn)行統(tǒng)一存儲（即一張表），亦或是在大型企業(yè)有建設(shè)業(yè)務(wù)中臺會提前做同類業(yè)務(wù)實(shí)體的數(shù)據(jù)融合（如，商品中心、用戶中心等）。但在沒有類似業(yè)務(wù)中臺可以直接獲取全量維度實(shí)體數(shù)據(jù)的情況下，就需要自行確定業(yè)務(wù)實(shí)體數(shù)據(jù)的來源，并做融合。一般情況會將常規(guī)主要業(yè)務(wù)流程中產(chǎn)生的業(yè)務(wù)系統(tǒng)數(shù)據(jù)做為主維度表，因?yàn)槠湟话闶蔷S度表的主要數(shù)據(jù)來源，并且數(shù)據(jù)準(zhǔn)確、豐富。例如，電商APP可能會有多個(gè)注冊入口，APP、微信、支付寶、分享外鏈等等，我們可能會將APP注冊流程中產(chǎn)生的數(shù)據(jù)表作為主維表，當(dāng)然可能有的企業(yè)已經(jīng)在用戶注冊系統(tǒng)已經(jīng)將其他各種渠道注冊的用戶數(shù)據(jù)已經(jīng)囊括進(jìn)入。

3.1.3 確定輔維表

輔維表存在的目的有兩方面。一方面是補(bǔ)全主維表在維度實(shí)體的數(shù)據(jù)（如，用戶大部分是通過獨(dú)立注冊登錄APP，還有小部分是通過微信登錄、支付寶登錄等等）；另一方面是為了尋找維度表所表示的業(yè)務(wù)實(shí)體的一些其他屬性描述輔助表（如，商品類目表、商品屬性表、用戶家庭關(guān)系表等），這些輔維表用來豐富維度表的屬性描述，增強(qiáng)維度表的表現(xiàn)性，同樣也能擴(kuò)展維度表的分析能力。

3.1.4 識別維度屬性

維度表的維度屬性一般可以分為相對穩(wěn)定的“固化屬性”和變動頻繁“動態(tài)屬性“。

“固化屬性”通常是和維度實(shí)體關(guān)系相對緊密且較為穩(wěn)定的固有屬性，不依賴或很少依賴于其它的業(yè)務(wù)活動過程（如，商品維度表中的商品名稱、商品品牌等）； ”動態(tài)屬性“通常是只能基于特定的事務(wù)過程或者活動關(guān)聯(lián)，在維度實(shí)體的層次上匯總得到的一些統(tǒng)計(jì)屬性（如，描述商品的近30天銷量，首次上架日期等）。

由于“固化屬性”和“動態(tài)屬性”的變更周期差異巨大，一般會在維度表的構(gòu)建過程中結(jié)合具體的場景進(jìn)行拆分，一方面是保證維度表能夠高效的產(chǎn)出，另一方面也是為追溯歷史數(shù)據(jù)提供合理的技術(shù)實(shí)現(xiàn)。

3.2 生成維度屬性

維度屬性的生成，既可能來自原始業(yè)務(wù)系統(tǒng)的即有的業(yè)務(wù)實(shí)體表（如，業(yè)務(wù)系統(tǒng)會有商品表/商品擴(kuò)展表），同時(shí)也可能來自事務(wù)過程之后的數(shù)據(jù)統(tǒng)計(jì)（如，近商品近一天的銷量），無論維度屬性來自哪里，都可以參照以下建議不斷地豐富和完善維度屬性，維度屬性越是詳盡，維度模型/數(shù)據(jù)倉庫的分析寬度和深度才能更強(qiáng)大。

3.2.1 多增加文字描述

業(yè)務(wù)操作系統(tǒng)同步進(jìn)入數(shù)倉的數(shù)據(jù)表中，通常會將某一屬性的可枚舉值一代碼的形式表示（如，商品類型<01：服裝；02:食物>），而代碼的具體含義會在表屬性的說明中或者在數(shù)據(jù)字典的說明文檔中。這樣做的目的是方便對其維護(hù)并提高在業(yè)務(wù)系統(tǒng)中的存取效率。 在數(shù)據(jù)倉庫這種分析型的系統(tǒng)中，為了能夠完善其可解釋性，最佳的方案是增加一個(gè)與代碼表示列對應(yīng)的文字描述屬性列，目的是描述代碼表示列的具體含義，使分析人員可以更便捷的根據(jù)需要進(jìn)行過濾、訪問和組織數(shù)據(jù)。

3.2.2統(tǒng)一標(biāo)志值

一些布爾類的屬性列，其屬性值在業(yè)務(wù)系統(tǒng)中可能會以各種不同的形式出現(xiàn)，如，可以是整形的0和1，或者是字符型的“Y”和“N”，亦或是“True”和“False”，統(tǒng)一張維度表中，不同的布爾類屬性列使用不同的表示方式，將會使維度表的使用效率大打折扣，分析人員在使用維度表的布爾類屬性列時(shí)需要不斷的去查詢說明文檔，確認(rèn)每個(gè)屬性列的表示方式。 在生成維度屬性時(shí)，將這些布爾類的屬性列的標(biāo)志值做統(tǒng)一規(guī)定，使用0/1或者Y/N進(jìn)行表示，這樣其表示也更加明確，使用更加便捷，也不會在生成報(bào)表過程中其意義含糊不清。

3.2.3 屬性拆分

數(shù)據(jù)倉庫獲取的數(shù)據(jù)充滿了不確定性，既會有業(yè)務(wù)系統(tǒng)中表屬性的各種隨性組合，也會有一些標(biāo)準(zhǔn)化可按照特定規(guī)則拆分的屬性（如，客戶的身份證號碼、買家的收貨地址郵編等），如果能夠按照既定的規(guī)則對維度表的屬性做合理的拆分，將會進(jìn)一步豐富維度表的表達(dá)能力。 業(yè)務(wù)系統(tǒng)中存儲的客戶身份號碼，可以依據(jù)身份號碼的構(gòu)成規(guī)則進(jìn)行拆分。18位身份證號碼，1-2位表示省、直轄市；3-4位表示地級市；5-6位表示區(qū)、縣；7-14位表示出生年月；第17位表示性別（男為單，女為雙）。這樣，依據(jù)身份證號碼的構(gòu)成，一個(gè)身份證號碼，可以擴(kuò)展出客戶戶籍省、市、區(qū)縣、出生年月、性別至少5個(gè)維度屬性，并且出生年月還可以進(jìn)一步拆分?jǐn)U展，每個(gè)拆分出的屬性，可參照上述1，增加對應(yīng)的文字描述，完善代碼屬性值和文字描述屬性一一對應(yīng)，拆分?jǐn)U展后的維度表將會有更強(qiáng)的表達(dá)能力。

3.2.4 屬性組合

屬性組合與屬性拆分相互對應(yīng)，屬性拆分的目的是從一個(gè)固定的編碼中獲取更加詳細(xì)的維度屬性，豐富維度的可解釋行；屬性組合則是相反的過程，是將一些具有相關(guān)性的維度屬性列進(jìn)行組合，方便在查詢時(shí)的維度屬性使用或展示。 比如業(yè)務(wù)操作系統(tǒng)存儲的地區(qū)代碼或者地區(qū)名稱，我們會根據(jù)業(yè)務(wù)上的使用習(xí)慣會進(jìn)行適當(dāng)?shù)慕M合，將省份、城市組合，或者將城市、區(qū)縣組合，在做查詢應(yīng)用或頁面展示時(shí)都是不錯(cuò)的選擇。通常會選擇根據(jù)業(yè)務(wù)需求進(jìn)行適當(dāng)組合，不必窮盡所有排列組合，因?yàn)閿?shù)據(jù)倉庫建設(shè)的目的主要還是在于能更便捷的應(yīng)用數(shù)據(jù)。

3.2.5 數(shù)值型維度屬性

考慮到“事實(shí)”通常是數(shù)值型，作為“維度”的數(shù)值型屬性往往容易被忽略掉。同時(shí)數(shù)值型屬性究竟是該被歸入“事實(shí)”中還是該被歸入到“維度”中也讓很多人感到困惑。簡單來講，數(shù)值型的屬性既可以作為“事實(shí)”，同時(shí)也可以作為“維度”屬性。 當(dāng)數(shù)值型屬性用作聚合匯總時(shí)，那么無疑就是“事實(shí)”；用作查詢過濾條件或者分組鍵時(shí)，也可以作為“維度”屬性。比如“商品價(jià)格”，其可以同時(shí)出現(xiàn)在事實(shí)表和維度表中，在事實(shí)表中可以作為指標(biāo)度量計(jì)算商品成交的平均價(jià)格，在維度表中則可以通過價(jià)格去分析商品在不同價(jià)格或者不同價(jià)格區(qū)間的成交情況。

3.2.6 統(tǒng)計(jì)型維度屬性

統(tǒng)計(jì)型維度屬性一般指并非維度實(shí)體固有的屬性，而是隨著業(yè)務(wù)的發(fā)展，在業(yè)務(wù)過程中產(chǎn)生的一些實(shí)體相關(guān)的行為統(tǒng)計(jì)信息（如，近30天商品銷量）。這些統(tǒng)計(jì)信息一般是作為分析的結(jié)果數(shù)據(jù)進(jìn)行輸出，但由于其描述仍然是維度實(shí)體，自然也可以作為維度屬性來應(yīng)用。統(tǒng)計(jì)型維度屬性需要考慮的問題主要在于更新的頻率，一般將其與維度的基本屬性進(jìn)行拆分開來存儲，基本屬性相對變化較少，而統(tǒng)計(jì)型維度屬性易變的體質(zhì)通常會作為維度基礎(chǔ)屬性表的擴(kuò)展表進(jìn)行存儲和應(yīng)用。

3.2.7 通用型維度屬性

通用型維度屬性是在使用數(shù)倉過程中不斷總結(jié)，不斷沉淀的一些與業(yè)務(wù)強(qiáng)相關(guān)的維度屬性。一般是具有復(fù)雜計(jì)算邏輯的維度屬性，如需要經(jīng)過多張表關(guān)聯(lián)計(jì)算，或者在企業(yè)范圍內(nèi)超高頻使用的分析邏輯。不斷的沉淀這些通用的維度屬性，一方面是提高下游使用的便捷性，另一方面也能保證數(shù)據(jù)口徑的一致性。如，在業(yè)務(wù)上可能需要分析分銷OR自營商品數(shù)據(jù)表現(xiàn)，最佳實(shí)現(xiàn)是將商品“是否分銷”的維度屬性進(jìn)行封裝，統(tǒng)一構(gòu)造進(jìn)入維度表中，保證數(shù)據(jù)口徑的一致性。

4 設(shè)計(jì)原則

數(shù)據(jù)倉庫模型在設(shè)計(jì)過程中需要一些設(shè)計(jì)原則來做一些規(guī)范約束，這樣才不會在建設(shè)過程中，發(fā)現(xiàn)越建設(shè)越雜亂，經(jīng)常需要不斷返工，重新推倒以前的東西，再重新糾正，導(dǎo)致歷史包袱過重。

4.1 主鍵選擇

維度表主鍵通常會有自然鍵、代理鍵兩種選擇：

代理鍵：不具有任何業(yè)務(wù)含義，僅做維度表數(shù)據(jù)唯一性區(qū)分的屬性；
自然鍵：具有業(yè)務(wù)含義，是業(yè)務(wù)實(shí)體一個(gè)實(shí)例的唯一性區(qū)分（如，商品ID，一個(gè)商品ID就代表一個(gè)獨(dú)立商品）。

兩種主鍵選擇因業(yè)務(wù)而異，筆者從業(yè)依賴，所見最多的還是以“自然鍵”作為主鍵居多。一方面主要是“自然鍵”做主鍵易處理、好理解，和業(yè)務(wù)系統(tǒng)意義相同；另一方面大多業(yè)務(wù)場景很少有需要追溯歷史變化的需求。 在此做一些建議：

如業(yè)務(wù)上對該維度表表示的業(yè)務(wù)實(shí)體沒有或很少有追溯歷史變化的需求，可直接采用自然鍵作為主鍵使用（如，商品ID，用戶ID等），因?yàn)樯纱礞I的過程也會有耗費(fèi)大量的數(shù)據(jù)加工性能，并且如何能保證代理鍵的唯一性，也需要去做設(shè)計(jì)方案。
如卻有業(yè)務(wù)場景肯能會需要追溯歷史變化，可根據(jù)需求，結(jié)合維度表拆分，將拆分后的維度表，一部分用“自然鍵”做主鍵，另一部分涉及到緩慢變化的維度屬性，通過“代理鍵”做主鍵，這樣可以綜合兩種主鍵的優(yōu)勢，同時(shí)滿足業(yè)務(wù)需求。

4.2 一致性原則

維度表的一致性是關(guān)系到數(shù)據(jù)模型能否進(jìn)行跨業(yè)務(wù)橫向鉆取做多業(yè)務(wù)流程分析的關(guān)鍵。一致性原則主要體現(xiàn)在三個(gè)方面：結(jié)構(gòu)一致性、語意一致性、內(nèi)容一致性。結(jié)構(gòu)一致性：同一實(shí)體的同一維度屬性在不同維度表/事實(shí)表中，需有相同的維度屬性列名、相同的數(shù)據(jù)類型定義，以保證內(nèi)容的同一性。語意一致性：不同維度表/事實(shí)表中，相同維度屬性所表達(dá)的業(yè)務(wù)含義需要是一致的，否則在使用過程中會出現(xiàn)相同指標(biāo)、不同結(jié)果的數(shù)據(jù)指標(biāo)不一致性。內(nèi)容一致性：是需要在同一實(shí)體同一維度屬性在不同維度表中需要有相同的數(shù)據(jù)內(nèi)容表示（如，下單日期維度和支付日志維度中month屬性一個(gè)是‘2020-02’表示，一個(gè)‘03’表示）。

保證一致性的兩個(gè)方法：

共享維度表結(jié)構(gòu)：同一實(shí)體的不同角色維度表共享一張維度表，通過在核心維度表上創(chuàng)建視圖或進(jìn)行數(shù)據(jù)導(dǎo)出實(shí)現(xiàn)維度表結(jié)構(gòu)的共享（如：下單日期維度、支付日志維度）。
共享維度表內(nèi)容：其他表加工過程中使用到維度屬性內(nèi)容，直接從維度表中獲取，該實(shí)體的所有屬性，均以維度表中屬性為準(zhǔn)，僅在維度表中進(jìn)行維護(hù)，其他事實(shí)表/維度表中使用到維度表的指定屬性，僅做內(nèi)容共享。

4.3 空值處理原則

一個(gè)原則：避免空值。 從各業(yè)務(wù)系統(tǒng)獲取的數(shù)據(jù)特點(diǎn)各異，同樣在表現(xiàn)在對空值的表示上，“NULL”、“null”、“Null”、“N/A”等等。在構(gòu)建維度表過程中，需要對此類值做明確的處理，因?yàn)檫M(jìn)入數(shù)據(jù)倉庫中經(jīng)加工的數(shù)據(jù)是要作為數(shù)據(jù)資產(chǎn)被應(yīng)用在各種業(yè)務(wù)上，不允許出現(xiàn)意義不明確的數(shù)據(jù)表示，否則這些數(shù)據(jù)將毫無意義，并且空值在進(jìn)行數(shù)據(jù)統(tǒng)計(jì)時(shí)有時(shí)會出現(xiàn)意外的一些統(tǒng)計(jì)結(jié)果。 維度屬性的數(shù)據(jù)值，可以通過以下三類區(qū)分：有效值、無效值、未知值。用統(tǒng)一明確的標(biāo)識進(jìn)行表示（如，“無效值”->“invalid”，“未知值”->“unknown”）。

4.4 命名規(guī)范

命名沒有統(tǒng)一的規(guī)范，只需要在企業(yè)內(nèi)部有統(tǒng)一規(guī)范即可，這樣方便做元數(shù)據(jù)管理，同樣也能增加開發(fā)/業(yè)務(wù)人員對數(shù)據(jù)的熟悉程度，能夠“望文生義”，簡單通過表名就能區(qū)分?jǐn)?shù)據(jù)表。 可以參考以下命名規(guī)范： dw.dim_user_info_di

dw：表示存儲表的物理庫名稱；
dim(dimension)：表示數(shù)據(jù)倉庫層次劃分的維度表層(DIM)；
user_info：表示維度表所表示的業(yè)務(wù)實(shí)體描述；
di：表示數(shù)據(jù)表的更新周期,（day increment）日增量更新。

4.5 生命周期管理規(guī)范

維度表的存儲周期，一般是越長越好，因?yàn)槲覀儾淮_定什么時(shí)候會用到多久的歷史數(shù)據(jù)，況且數(shù)據(jù)倉庫本身就是需要存儲歷史數(shù)據(jù)的。 但在實(shí)踐的過程中也同樣發(fā)現(xiàn)了一些問題，不少企業(yè)在維度表處理上，因其相比事實(shí)表數(shù)據(jù)要小很多，故通常都是將其從業(yè)務(wù)庫每日進(jìn)行全量同步，這樣會造成大量的數(shù)據(jù)冗余。類似情況是必須要對維度表數(shù)據(jù)最生命周期處理的，否則帶來的成本將遠(yuǎn)超其可能解決的業(yè)務(wù)問題。 而也有一些情況（如，維度表增量更新）在維度表生命周期的處理上要從容很多，增量處理維度表更新，或者通過緩慢變化維處理維度表變化，是又可能將維度表歷史所有數(shù)據(jù)存儲下來的。當(dāng)然數(shù)據(jù)的時(shí)效性還是要根據(jù)業(yè)務(wù)的需求進(jìn)行取舍，調(diào)整維度表合適的生命周期，及時(shí)清理/歸檔陳舊的歷史數(shù)據(jù)。

總結(jié)

以上是生活随笔為你收集整理的维度表设计-数据仓库维度建模的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。