數(shù)據(jù)倉(cāng)庫(kù): 你知道這6種類型維度嗎
正常維度（Normal Dimension）
- 該維度表屬性跟實(shí)體相關(guān)，具有唯一標(biāo)識(shí)，可根據(jù)外鍵訪問(wèn)其他依賴屬性
正常維度是當(dāng)所有屬性都相關(guān)時(shí)（它們?nèi)可婕耙粋€(gè)實(shí)體，例如：商品），它具有業(yè)務(wù)唯一標(biāo)識(shí)（自然主鍵），并且所有屬性都依賴于代理主鍵，例如：
上面的DIM_PRODUCT，產(chǎn)品的組件為PRODUCT_CODE。有時(shí)，在表中可以找到一個(gè)創(chuàng)建日期的日期屬性（在上面的示例中為DATE_PRICE_UPDATED，有時(shí)是一個(gè)替代鍵（在上面的示例中為DATE_LAUNCHED_KEY）。另一個(gè)雪花型維度建模示例是SUPPLIER_KEY，通過(guò)該外鍵能夠訪問(wèn)存儲(chǔ)在DIM_SUPPLIER中的所有供應(yīng)商屬性。
垃圾維度
在垃圾維度中，屬性互不相關(guān)。假設(shè)事務(wù)/源系統(tǒng)中的源表有4到8列，每列有2到6個(gè)值（有些是Yes / No列）。這些列彼此不相關(guān)，也不是很大的屬性。這些列中的大多數(shù)解釋了事實(shí)表本身。例如，電商網(wǎng)站中有一個(gè)支付表。支付表有訂單ID列、 客戶ID列、實(shí)際付款日期、付款金額、付款方式等。但是該表還有以下列：是否使用積分、是否使用優(yōu)惠券和是否為秒殺訂單。這些列均為「是/否」列。
這樣我們就可以創(chuàng)建一個(gè)垃圾維度：
注意：
- 垃圾維度始終是靜態(tài)，就是維度表的數(shù)量是固定的。
- JUNK直接跟在DIM_后面。對(duì)于Y / N列，使用“ IS_…”或“…_FLAG”進(jìn)行命名。
- 數(shù)據(jù)類型是一致的，即對(duì)于Y / N列，它可以是bit或CHAR（1），但不能是INT或VARCHAR（N）
- 優(yōu)先選擇CHAR（1）
- 垃圾維度是沒(méi)有業(yè)務(wù)主鍵的
- 擴(kuò)展垃圾維度：
- 如果我們向垃圾維度添加一列，會(huì)發(fā)生以下情況。上面的垃圾維度有9行，即4個(gè)Y / N列的組合為8行（4 * 2），外加未知行。注意理解：每一個(gè)列Y/N，不與其他列組合。
- 如果再添加1個(gè)Y / N列（例如IS_REFUNDABLE），則行數(shù)變?yōu)?7，即對(duì)于現(xiàn)有的8行（不是未知行），將IS_REFUNDABLE設(shè)置為N。然后將現(xiàn)有的8行復(fù)制到第10 -17行，IS_REFUNDABLE為Y。注意理解：需要保證之前的維度數(shù)據(jù)依然有效，只是行政的這一列不起作用。可以想象下如果用該維度表關(guān)聯(lián)事實(shí)表，如果關(guān)聯(lián)出來(lái)的新列是Y，顯然數(shù)據(jù)是錯(cuò)誤的。
- 在事實(shí)表中，有JUNK_PAYMENT_KEY列，包含值0到17。
- 垃圾維度的列值也是可以被擴(kuò)展的，例如：IS_PROCESSED列是Y / N列，但現(xiàn)在它還有第三個(gè)值U（未知）。
“垃圾維度中的屬性是屬于事務(wù)（源表）級(jí)別（或事實(shí)表涉及的內(nèi)容），并不是維度級(jí)別。
”
分割維度
當(dāng)一個(gè)維度預(yù)計(jì)會(huì)很大時(shí)，例如：有5000萬(wàn)行，出于性能原因，我們可以將維度分為兩個(gè)或三個(gè)。
拆分始終是垂直的，即某些列放入到維表1，有些列放入到維表2。例如，將客戶詳細(xì)信息放入dim_customer_contact，將與訂單處理相關(guān)的客戶屬性放入dim_customer_order，將相關(guān)客戶屬性營(yíng)銷，促銷和忠誠(chéng)度計(jì)劃已納入dim_customer_marketing。
每個(gè)維度中的相關(guān)行具有相同的業(yè)務(wù)主鍵（自然主鍵），這種情況肯定是不能使用代理主鍵的。
文本維度
文本維度沒(méi)有業(yè)務(wù)主鍵的。如果源事務(wù)表的文本列較窄（例如10至20個(gè)字符），并且該列不在維級(jí)別上，而是在事實(shí)表級(jí)別上，則將其保留在事實(shí)表中。例如：訂單ID，交易ID，付款I(lǐng)D。但如果源事務(wù)表具有寬文本列，例如varchar（255）或varchar（800），有兩種設(shè)計(jì)選擇。
-
將此varchar列放在一個(gè)維度（稱為“文本維度”）中。
-
將其保留在事實(shí)表中。
例如：一些注釋列，交易描述列或訂單描述列
- 選擇哪種設(shè)計(jì)方式有幾個(gè)注意事項(xiàng)：
-
文本列的長(zhǎng)度和值重復(fù)度。文本越長(zhǎng)，將其單獨(dú)放在一個(gè)維度中是明智的，尤其是在事實(shí)表很大的情況下。
-
如果此varchar列中的值具有很高的可重復(fù)性，可以單獨(dú)放在維度表中，節(jié)省空間。性能也一樣，因?yàn)榇蠖鄶?shù)訪問(wèn)事實(shí)表的查詢都與text列無(wú)關(guān)。
-
如果文本列的長(zhǎng)度為20-70個(gè)字符，并且可重復(fù)性非常低（例如1.2的倍數(shù)），則可以將該文本列保留在事實(shí)表中是合理的。
-
如果在源表中有兩個(gè)注釋/注釋列，則最好創(chuàng)建兩個(gè)文本維度，而不是將它們合并為一個(gè)文本維度
(1). 功能清晰–事實(shí)表中的不同替代鍵描述它們是什么
(2). 查詢性能–維度表的行數(shù)較少，合并時(shí)避免了笛卡爾積性能低下
堆疊維度
堆疊維度是將兩個(gè)或多個(gè)維度合并為一個(gè)維度的維度，如下所示：
-
堆疊的維度僅具有一個(gè)或兩個(gè)屬性，而且始終是不更新的。
-
不建議使用堆疊尺寸。但在實(shí)際開(kāi)發(fā)中，堆疊維度確實(shí)存在。通常因?yàn)樗c源系統(tǒng)中的類似，所以很多人只是將其復(fù)制到數(shù)據(jù)倉(cāng)庫(kù)中。我們經(jīng)常會(huì)遇到一些類型和狀態(tài)列：客戶狀態(tài)、產(chǎn)品類型、商鋪類型、安全性類型、安全性類別、經(jīng)紀(jì)人類型等。所有這些列均應(yīng)具有各自的維度，因?yàn)樗鼈兇_實(shí)是該屬性尺寸。
-
但是有類型和狀態(tài)列是事實(shí)表的屬性，例如：事務(wù)類型或事務(wù)狀態(tài)。要將交易類型和交易狀態(tài)合并為一個(gè)維度，可以使用垃圾維度。盡量避免使用像這樣的堆疊尺寸。
不同屬性維度
最后一種類型是獨(dú)特的屬性維，其中所有屬性都是事實(shí)表本身的屬性。例如，考慮一個(gè)基金管理中的持有表，其中每個(gè)基金，證券和日期的顆粒都是一行。每個(gè)證券都具有許多屬性，例如部門，等級(jí)，國(guó)家，貨幣，資產(chǎn)類別等。證券的示例包括債券，股票，CDS，IRS，期權(quán)，期貨。從理論上講，這些屬性在各個(gè)基金中是一致的。但是事實(shí)并非如此，因?yàn)榭赡軙?huì)被更新。
在正常情況下，部門，等級(jí)，國(guó)家，貨幣和資產(chǎn)類別都是安全維度的屬性。它們實(shí)際上是持有事實(shí)表的屬性。為了正確存儲(chǔ)它們，應(yīng)該創(chuàng)建一個(gè)獨(dú)特的屬性維，如下所示：
上面的示例比較簡(jiǎn)單，實(shí)際上，這種維度中的屬性有可能會(huì)是幾十個(gè)。顧名思義，以上維度包含一個(gè)獨(dú)特的屬性列表。并非所有可能的值，而是僅事實(shí)表中實(shí)際存在的值。這種維表沒(méi)有業(yè)務(wù)ID。所有屬性都是事實(shí)表的屬性，而不是特定維度的屬性。
一個(gè)不同屬性維度可以在物理上分為兩個(gè)或三個(gè)。這是一個(gè)垂直拆分，類似于之前的拆分維度，基于屬性的邏輯分組。拆分它的目的是減少行數(shù)，從而提高查詢性能。從某種意義上說(shuō)，這就像一個(gè)垃圾維度，但是覆蓋了更廣泛的屬性范圍，即50-60列而不是3-5列。