促銷維度
促銷維度描述了銷售商品的促銷條件。促銷條件包括臨時降價、終端通道展示禮券等。促銷維度通常被認(rèn)為是一種因果維度,因為它描述了認(rèn)為可能導(dǎo)致產(chǎn)品銷售發(fā)生改變的因素。
促銷基于以下一個或多因素來判斷:
1.促銷產(chǎn)品的銷售是否在促銷期間獲得大幅增加,也稱提升。
2.促銷產(chǎn)品在促銷前或促銷后的銷售,與促銷期間的銷售比較,是否有降低,這種降低是否抵消了促銷期間的銷售增益。
3.促銷產(chǎn)品在銷售方面表現(xiàn)良好,但是其他與其相鄰的產(chǎn)品的銷售卻顯著降低了。
4.促銷分類中的所有產(chǎn)品是否都獲得了銷售方面的凈總增益,將考慮促銷前、促銷期間,促銷后的時間段。
5.促銷是否有利可圖。
事務(wù)系統(tǒng)跟蹤降價。禮券的出現(xiàn)通常也通過交易獲得,因為客戶要么在銷售時出示禮券,要么不出示。廣告和櫥窗展示條件可能需要其他源的介入。
臨時降價通常與廣告或終端通道展銷相關(guān)。在促銷維度中為每個發(fā)生的促銷條件的組合建立一行是具有實際意義的。在過去一年中,有1000個廣告,5000個臨時降價,1000個終端通道展銷,但僅有10000次該三個條件的組合能夠影響任何特定的產(chǎn)品。(如:對某次促銷,多數(shù)門店同時采用上述三種促銷機(jī)制。但一些商店可能沒有布置終端通道展銷。在這種情況下,需要兩個不同的促銷條件行,一行包括通常的降價加廣告加展示,另外一行包括降價加廣告。)

通過將4個不同的因果機(jī)制(降價、廣告、展示、禮券)區(qū)分開,建立不同的維度而不是將它們合并在一個維度中。這樣將會記錄與促銷信息相似的信息。將4個維度放在一起的理由如下:
1.如果4個因果機(jī)制高度關(guān)聯(lián),合并而成的單一維度不會比任一單個維度大很多。
2.合并成單一維度可方便瀏覽,觀察降價、廣告、展示、禮券的相互影響關(guān)系。對維度表的瀏覽無法揭示促銷對哪個商店或產(chǎn)品有影響,此類信息顯然需要瀏覽事實表方能獲得。
贊成4個因果機(jī)制劃分到4個不同的維度中的原因:
1.對業(yè)務(wù)群體來說,當(dāng)分別考慮不同的機(jī)制時,不同的維度可能更易于理解。
2.對不同維度的管理可能比對合并維度的管理更直接。
這兩種選擇在內(nèi)容上沒有差別。
注:應(yīng)當(dāng)仔細(xì)權(quán)衡包含在促銷維度中的促銷成本屬性。該屬性可用于約束和分組。該成本沒有出現(xiàn)在表示獨立產(chǎn)品銷售的POS事務(wù)事實表中,因為其粒度不符。成本應(yīng)該駐留在粒度為整個促銷的事實表中。
空外鍵、空屬性和空事實
通常,許多銷售事務(wù)包括未被促銷的產(chǎn)品。促銷維度必須包含一行,具有唯一鍵0或-1,用以表示這個不含促銷條件,避免事實表中出現(xiàn)空的促銷鍵。如果將一個空值放在事實表中的已被聲明為外鍵的列,則違背了參照完整性的要求。
警告:不要在事實表中使用空值鍵。正確的設(shè)計應(yīng)在對應(yīng)維度表中包括一行以表明該維度不可用于度量。
當(dāng)某一給定的維度行未被完全填充時,或者有些屬性未被應(yīng)用到所有維度行時,就會導(dǎo)致出現(xiàn)空值。建議用描述字符串替換空值(如:Unknown(未知)或Not Applicable(不適用))。某些OLAP產(chǎn)品禁止使用空值屬性。
在事實表中也會遇到空值。讓事實表非空的方法可通過聚集函數(shù)處理,(如:SUM、MIN、MAX、COUNT和AVG等。)如果用零值替換可能會使聚集計算產(chǎn)生傾斜。
其他零售業(yè)維度
任何出現(xiàn)在事實表度量事件中的表示單一值的描述性屬性是增加到一個已存在維度或自身維度的一個好的選擇。有關(guān)某個維度是否應(yīng)該與某個事實表關(guān)聯(lián)的決策應(yīng)該基于事實表的聲明的粒度來確定是或不是。(如:可能由出納員確定每個事務(wù)。對應(yīng)的出納員維度可能包含非專屬于員工屬性的子集。)
一種展現(xiàn)支付方式的更棘手的情況是,也許商店有嚴(yán)格的規(guī)則,每個事務(wù)僅能接受一種支付方式。作為維度建模人員比較簡單的方式是將一個簡單的支付方式維度附加到銷售模式中,該維度可能包括支付方式描述,以及將支付方式分組為現(xiàn)金等價物或用信用卡支付類型。
每種產(chǎn)品每種支付方式一行這樣的方式,不如將支付方式獲取到不同的事實表中,其粒度要么是每個事務(wù)一行,要么是每個事務(wù)的每個支付方式一行。
事務(wù)號碼的退化維度
零售事實表的每個列表項行都包含POS事務(wù)號碼。在某個操作型的父/子關(guān)系數(shù)據(jù)庫中,POS事務(wù)號碼是事務(wù)頭指針記錄的鍵。包括所有將事務(wù)作為一個整體的有效信息。在維度模型中,已經(jīng)從其他維度獲得了該頭指針信息。POS事務(wù)號仍然有用,因為它可用于分組鍵,將購買的所有產(chǎn)品放在一個單一的市場購物籃事務(wù)中。還能確保與操作型系統(tǒng)的關(guān)聯(lián)。
盡管POS事務(wù)號碼看起來像事實表中的維度鍵,但是當(dāng)POS事務(wù)維度被清空時,描述性項可能會出現(xiàn)錯誤。因為產(chǎn)生的維度是空的,我們將POS事務(wù)號碼稱為退化維度。當(dāng)事實表粒度表示單一事務(wù)或事務(wù)列表時,退化維度是比較常見的,因為退化維度表示雙親的唯一標(biāo)識符。
退化維度通常在事實表的主鍵中起著重要作用。在本案例研究中,銷售事實表主鍵包含退化POS事務(wù)號碼以及產(chǎn)品鍵。
*注:操作型事務(wù)控制號碼,(如:訂單號碼、發(fā)票號碼、提貨單號碼通常產(chǎn)生空的維度并且表示為事務(wù)事實表中的退化維度。退化維度是沒有對應(yīng)維度表的維度鍵。)
實際的銷售模式


零售模式的擴(kuò)展能力
因為POS事務(wù)數(shù)據(jù)在最初建模時就是以最細(xì)粒度級別構(gòu)建的。增加的維度可方便地應(yīng)用細(xì)粒度,不必改變維度鍵或事實,所有現(xiàn)存的BI應(yīng)用不需要任何改變,仍然可以運(yùn)行。
維度模型可預(yù)見的對稱性確保它們能夠承受一些源數(shù)據(jù)相當(dāng)顯著的變化,以及建模假設(shè)為無效的現(xiàn)有BI應(yīng)用,包括:
新維度屬性。如果發(fā)現(xiàn)了維度的新文本描述符,可以把這些屬性作為新列增加進(jìn)去。所有現(xiàn)存的應(yīng)用將可以不受這些屬性的影響而繼續(xù)其工作。如果新屬性僅在某特定時間點可用,則老的維度行中將插入不可用或類似的描述。要警告的是,如果商業(yè)用戶想要根據(jù)新確定的屬性跟蹤歷史數(shù)據(jù)變化,則該場景將更加復(fù)雜。
新維度??稍谑聦嵄砩显黾有戮S度,在事實表上增加新的外鍵列并將新維度的主鍵填寫到該外鍵列上。
新可度量事實。如果新的可度量事實可用,可以將它們方便地增加到事實表。最簡單的實例是當(dāng)新事實在同一個度量事件中可用,并與已經(jīng)存在的事實粒度相同時。事實表被改變,增加了新列,值被填充至表中。如果新事實僅在某個時間點可用,則將空值填充到舊事實表行中。當(dāng)新的可度量事實以不同粒度出現(xiàn)時,如果新事實不能分配或分派到事實表的原始粒度,新事實應(yīng)有屬于自己的事實表,因為在同一個事實表中出現(xiàn)不同的粒度是錯誤的。
無事實的事實表
在促銷范圍事實表中,將為每天(或每周,如果促銷是為一周為持續(xù)期的話)每個商店中促銷的產(chǎn)品加載一行,無論產(chǎn)品是否賣出。事實表能夠確??吹奖淮黉N定義的鍵之間的關(guān)系,與其他事件例如產(chǎn)品銷售無關(guān)。我們將其稱為無事實的事實表,因為它沒有度量結(jié)果,僅僅獲得所包括的鍵之間的關(guān)系。為了便于計算,可以包括虛擬事實,(如:本例中的促銷計數(shù),它始終包含常量值1,這是一種包裝方法,可使BI應(yīng)用避免對外鍵計數(shù)。)

為確定當(dāng)前促銷的產(chǎn)品中哪些尚未賣出,需要兩步過程:首先,查詢促銷無事實的事實表,確定給定時間內(nèi)促銷的產(chǎn)品。然后確定通過POS銷售事實表哪些產(chǎn)品已經(jīng)賣出去了。多維度數(shù)據(jù)庫通常包含未發(fā)生行為的確切值。
維度與事實表鍵
維度表代理鍵
維度表的唯一主鍵應(yīng)該是代理鍵而不是來自于操作型系統(tǒng)的標(biāo)識符,也就是所謂的自然鍵。代理鍵有許多其他的稱謂:無意義鍵、整數(shù)鍵、非自然鍵、人工鍵和合成鍵等等。代理鍵簡單地以按照順序序列生成的整數(shù)表示。產(chǎn)品行的第1行代理鍵為1,則下一產(chǎn)品行的鍵為2,如此下去。代理鍵的作用僅僅就是連接維度表與事實表。列名帶有Key后綴的,表示該鍵是主鍵(PK)或外鍵(FK),表示可能是代理鍵。
注:數(shù)據(jù)倉庫中維度表與事實表的每個連接應(yīng)該基于無實際含義的整數(shù)代理鍵。應(yīng)該避免使用自然鍵作為維度表的主鍵。
最初,利用操作型自然鍵作為維度模型的主鍵實現(xiàn)起來可能比較便捷。但從長遠(yuǎn)來看,使用代理鍵的效果會更好。使用維度表代理鍵的優(yōu)點如下:
1.為數(shù)據(jù)倉庫緩沖操作型系統(tǒng)的變化。代理鍵確保倉庫小組維持對DW/BI環(huán)境的控制,而不受制于生產(chǎn)代碼的建立、更新、刪除、循環(huán)、重用等操作型規(guī)則。在許多組織中,歷史的操作型代碼,(如:不活躍的賬戶號碼或廢棄的產(chǎn)品代碼,經(jīng)過一段休眠期后,可能會被重新分配。長時間不用重新使用,操作型系統(tǒng)不會停止運(yùn)行。)但對DW/BI系統(tǒng)來說,可能需要保存數(shù)據(jù)許多年。代理鍵為數(shù)據(jù)倉庫提供了一種機(jī)制,用于區(qū)分同一個操作型賬號的兩個不同的實例。若僅依賴操作型代碼,可能在獲取或整理數(shù)據(jù)時遭遇鍵重疊的問題。
2.集成多個源系統(tǒng)。代理鍵能夠確保數(shù)據(jù)倉庫小組從多個操作型源系統(tǒng)中集成數(shù)據(jù),即使它們?nèi)狈σ恢滦缘脑存I,通過后端整理,建立交叉引用映射表可將多個自然鍵連接成為一個公共的代理鍵。
3.改進(jìn)性能。代理鍵是盡可能小的一個整數(shù),這樣確保方便地適應(yīng)未來預(yù)期的粒度變化(維度行的數(shù)量變化)。通常操作型代碼是龐大的字母數(shù)字組合串,甚至是由一組字段組成。事實表中的代理鍵越小,事實表的索引就越小,能夠一次輸入-輸出更多的事實表行。
4處理空值或未知條件。特定的代理鍵值用于記錄不涉及操作型代碼的維度條件,(如:非促銷條件或匿名客戶)??煞峙湟粋€代理鍵區(qū)分這些缺乏操作型代碼的情況。
5支持維度屬性變化跟蹤。一種主要的處理維度屬性變化的技術(shù)需要代理鍵處理單一自然鍵的多個輪廓。偽代理鍵簡單地將自然鍵粘接到一起,增加一個時間戳,這種方式存在危險。需要避免多個維度和事實表的連接。有時稱為雙筒連接,主要原因在于這樣會降低性能和易用性。
需要在ETL系統(tǒng)建立并維護(hù)交叉參考表,用于以代理鍵替代每個事實表和維度表行。
維度中自然和持久的超自然鍵
由操作型源系統(tǒng)分配和使用的自然鍵使用其他名稱,(如:業(yè)務(wù)鍵、產(chǎn)品鍵和操作鍵等。在書中,它們用NK標(biāo)識表示。)自然鍵通常被建模為維度表的屬性。如果同一個實體在兩個操作型源系統(tǒng)中表示,則可能在維度中存在兩個自然鍵屬性,表示不同系統(tǒng)的實體。操作型自然鍵通常組成有意義的組合鍵。
在跟蹤維度表屬性變化時,重要的是能夠確定一個標(biāo)識符用于唯一地和可靠地區(qū)分維度實體的屬性變化。如果維度的自然鍵沒有受到完全的保護(hù)和保存,ETL系統(tǒng)需要分配永久的持久性標(biāo)識符,也被稱為超自然鍵。持久的超自然鍵被DW/BI系統(tǒng)控制并在系統(tǒng)生命周期中保持不變。類似維度代理鍵,它是一種簡單的整數(shù)序列分配方法。
退化維度的代理鍵
通常不會給退化維度分配代理鍵,但每種環(huán)境下仍然需要評估以確定是否需要。如果事務(wù)控制號在跨多個本地系統(tǒng)或重用時不是唯一的,則需要分配代理鍵。(如,銷售商的POS系統(tǒng)可能不會為多個商店分配唯一的事務(wù)號。)最后,與BI工具的能力有關(guān),需要分配代理鍵(建立關(guān)聯(lián)維度表)以橫向鉆取事務(wù)號。以此方式對應(yīng)維度表建模的控制號維度不在退化。
日期維度的智能鍵
日期維度具有特殊的特征和需求。日歷日期是固定的預(yù)先確定的,不需要擔(dān)心刪除日期或處理新的,未預(yù)見的日歷上的日期。因為日期維度具有可預(yù)測性,因此可以在日期維度中使用更加智能的鍵。
如果序列整數(shù)作為日期維度的主鍵,則該鍵應(yīng)該按照時間先后順序分配。
日期維度的主鍵是一個有意義的整數(shù),其格式為YYYYMMDD。事實表的YYYYMMDD鍵的過濾對可用性和性能具有決定性影響。對日歷屬性的過濾和分組發(fā)生在維度表,而不應(yīng)該處于BI應(yīng)用的代碼中。
YYYYMMDD鍵可用于分區(qū)事實表。分區(qū)確保能夠?qū)⒈韯澐譃楦〉谋?。按照日期對一個大的事實表進(jìn)行劃分是可行的,可以移除舊數(shù)據(jù),加載新數(shù)據(jù),索引當(dāng)前分區(qū),二不需要操作事實表的其他內(nèi)容,減少了加載、備份、歸檔以及查詢響應(yīng)的時間。如果日期鍵是有序的整數(shù),年按照增量1到希望的年份,月從1到12等等,則可以直接用程序更新和維護(hù)分區(qū)。使用智能YYYYMMDD鍵提供代理,將使分區(qū)的管理更加方便。
事實表的代理鍵
事實表中的代理鍵通常只是對后端ETL處理有幫助。如前文所述,事實表的主鍵通常包括表外鍵的子集以及退化維度。
事實表代理鍵是一個簡單整數(shù),不包含任何業(yè)務(wù)含義,按照事實表行順序分配。事實表的代理鍵的確可以帶來以下的利益:
1.直接的唯一標(biāo)識。單一事實表行可以由此鍵直接獲得。在ETL處理過程中,不需要查詢多個維度就可以識別出特定的行。
2.返回或恢復(fù)海量加載。若某一加載涉及大量的行,這些行帶有順序分配的代理鍵,在完成前過程停止,則通過觀察表的最大鍵,數(shù)據(jù)庫管理員能夠準(zhǔn)確地確定過程在何處停止。數(shù)據(jù)庫管理員可以不執(zhí)行完全加載,只定義一個需要加載的范圍鍵,或從正確的點重新開啟加載過程。
3.插入加刪除的替換更新。事實表代理鍵成為事實表中真正的物理鍵。不再是僅僅由一系列維度外鍵組合而成的事實表鍵,至少到目前為止與關(guān)系數(shù)據(jù)庫管理系統(tǒng)有關(guān)。因此它可能采用插入加刪除的方式替換事實表更新操作。
4.使用事實表代理鍵作為父/子模式中的父節(jié)點。一個事實表包含的行是另外粒度更細(xì)的事實表的父指針。父表中的事實表代理鍵也會暴露在子表中。使用事實表代理鍵而不使用自然父鍵與在維度表中使用代理鍵一樣都存在爭議。
抵制規(guī)范化的沖動
具有規(guī)范化維度的雪花模式
帶有重復(fù)文本的扁平非規(guī)范化維度表使來自操作型世界的數(shù)據(jù)建模者非常不舒服。
規(guī)范化的維度表被稱為雪花模式。冗余屬性從扁平非規(guī)范化維度表中移除,放置于不同規(guī)范化的維度表中。
雪花模式是維度建模的合法分支,然而,建議您抵制采用雪花模式的沖動主要出于設(shè)計動機(jī):易用性和性能。
1.眾多的雪花模式表構(gòu)成了一個復(fù)雜的結(jié)果。
2.多數(shù)數(shù)據(jù)庫優(yōu)化器也要考慮處理雪花模式的復(fù)雜性。
3.與雪花模式維度表有關(guān)的磁盤空間節(jié)省問題并不是非常明顯。
4.雪花模式對用戶瀏覽維度的能力具有負(fù)面影響。
5.如果僅希望獲得分類描述列表,雪花模式產(chǎn)品維度表非常不錯。然而,如果想要瀏覽分類中的所有品牌,則需要遍歷品牌和分類維度。如果還希望獲得分類中每個品牌的包裝類型,則需要遍歷更多的表才行。
6.最后,雪花模式無法實現(xiàn)位圖索引。

注:固定深度層次在維度表中應(yīng)該被扁平化。規(guī)范化雪花模式維度表不利于多屬性瀏覽并妨礙了位圖索引的使用。通過規(guī)范化維度表所節(jié)省的磁盤空間通常不會超過整個模式所需要空間的1%。應(yīng)該知道犧牲一些維度空間有利于改善性能和可用性。
過去,一些BI工具對雪花模式帶有一種偏好,雪花模式解決了BI工具的特殊需求。同樣,如果所有數(shù)據(jù)都通過OLAP多維數(shù)據(jù)庫發(fā)布給商業(yè)用戶(雪花模式用于裝載多維數(shù)據(jù)庫,但對用戶來說是不可見的),則采用雪花模式是可以接受的。
支架表
為某個事實表范圍之內(nèi)的維度建立附加的支架維度,如下圖。在該例中,“一旦刪除”支架表示日期維度,該維度與主維度呈雪花模式。支架表日期屬性具有描述性的獨特的標(biāo)記用于區(qū)分與業(yè)務(wù)過程有關(guān)的其他日期。只有當(dāng)業(yè)務(wù)希望按照非標(biāo)準(zhǔn)的日歷屬性(例如,財務(wù)周期、商業(yè)日期)過濾將日期屬性作為產(chǎn)品維度中的標(biāo)準(zhǔn)日期類型列對待。如果使用了日期支架,注意當(dāng)標(biāo)準(zhǔn)日期維度表按照范圍存儲時,支架日期將發(fā)生錯誤。

支架表可以節(jié)省空間并能夠確保相同屬性被一致地引用。缺點:支架表引入了更多的連接,連接嚴(yán)重降低了系統(tǒng)的性能。支架表不易用戶理解,限制了用戶在單一維度中瀏覽屬性的能力。
【警告】盡管可以使用支架表,但出于對其潛在影響考慮,維度模型盡量不要大量使用支架表。
包含大量維度的蜈蚣事實表
維度模式中的事實表自然地具有高度規(guī)范化和緊湊的特性。無法進(jìn)一步規(guī)范化事實表鍵之間的極端復(fù)雜的多對多關(guān)系,因為維度之間不是相互關(guān)聯(lián)的。
盡管存在規(guī)范化維度層次的難以控制的期望,但是知道雪花模式是存在問題的。因此通過加入事實表消除了規(guī)范化表。不是在事實表上建立單一產(chǎn)品外鍵,他們將產(chǎn)品層次上頻繁分析的元素也當(dāng)成外鍵,(如,品牌、分類、部門等等)。原先緊湊的事實表變成連接大量維度表的奇形怪狀的怪物。我們將這樣的設(shè)計稱為蜈蚣事實表。

即使有緊湊的格式,事實表也是維度模型中的巨獸。包含太多維度表的事實表設(shè)計,將導(dǎo)致事實表需要更多磁盤空間。在蜈蚣表實例中,無法實現(xiàn)多對多部分構(gòu)成的鍵構(gòu)建有效的索引。
多數(shù)業(yè)務(wù)過程可以用不超過20維度的事實表表示。如果某個設(shè)計有25個或更多維度,應(yīng)該考慮采取措施合并關(guān)聯(lián)的維度。在產(chǎn)生的新維度比不同維度的笛卡爾積小很多的情況下,可以考慮合并這些維度。
注:大量的維度通常表明某些維度不是完全獨立的,應(yīng)該合并為一個維度。將同一層次的元素表示為事實表中不同維度是維度建模常見的錯誤。
列數(shù)據(jù)庫開發(fā)可以減少與蜈蚣事實表有關(guān)的查詢和存儲的負(fù)擔(dān)。不是將表的每行都存儲,列數(shù)據(jù)庫將表列作為連續(xù)對象存儲,表列建立了索引。即使基本的物理存儲時按列存儲的,在查詢級別上,表仍然按行方式顯示。列數(shù)據(jù)庫更有利于處理前面討論的蜈蚣表。
小結(jié)
在處理維度模型設(shè)計時采用4步過程方法。注意清楚地聲明與維度模型關(guān)聯(lián)的粒度是特別重要的。加載事實表時,獲取原子數(shù)據(jù)將會帶來最大的靈活性,因為可按任何可能的方式對數(shù)據(jù)進(jìn)行匯總。