亚洲先锋影音人AV成_免费A级毛片一分钟_人人爽人人爽人人插_日韩少妇极品熟妇人妻潮喷

沃卡惠移動(dòng)端logo

數(shù)據(jù)倉庫中的七種建模方法及示例

2024-06-17 09:52:074636

試象一下,你是一家繁忙餐廳的分析工程師。每天,顧客都會(huì)預(yù)訂、下訂單并完成付款。所有這些數(shù)據(jù)都會(huì)流入餐廳的交易數(shù)據(jù)庫,記錄每次互動(dòng)的詳細(xì)信息。

但是,事務(wù)型數(shù)據(jù)庫雖然非常適合日常運(yùn)營,但并不適合分析數(shù)據(jù)以發(fā)現(xiàn)有助于業(yè)務(wù)增長的趨勢和見解。這就是數(shù)據(jù)倉庫的作用所在。數(shù)據(jù)倉庫是一個(gè)單獨(dú)的數(shù)據(jù)庫,經(jīng)過優(yōu)化,可用于存儲(chǔ)大量歷史數(shù)據(jù)以及快速查詢和分析。

挑戰(zhàn)在于如何構(gòu)建倉庫中的數(shù)據(jù),以便進(jìn)行高效分析,同時(shí)保持足夠的靈活性以應(yīng)對不斷變化的業(yè)務(wù)需求。數(shù)據(jù)倉庫中的數(shù)據(jù)建模有幾種常見和不太常見的方法。在本文中,我們將介紹七種關(guān)鍵的建模技術(shù),權(quán)衡它們的優(yōu)缺點(diǎn),并幫助您為數(shù)據(jù)倉庫選擇正確的方法。

數(shù)據(jù)倉庫

一、事務(wù)數(shù)據(jù)庫示例

在深入研究數(shù)據(jù)倉庫建模之前,讓我們簡單看一下餐廳的典型事務(wù)數(shù)據(jù)庫可能包含哪些內(nèi)容:

包含姓名、電子郵件、電話號(hào)碼等詳細(xì)信息的客戶表

預(yù)訂表,包括預(yù)訂日期、時(shí)間、團(tuán)體規(guī)模等

帶有描述的產(chǎn)品表,鏈接到產(chǎn)品價(jià)格和產(chǎn)品組表

訂單表將顧客與他們所選的菜單項(xiàng)聯(lián)系起來

訂單明細(xì)表,其中包含每個(gè)訂單的每個(gè)菜單項(xiàng)的數(shù)量

包含總額、付款方式等的付款表。

交易數(shù)據(jù)庫使用針對處理交易進(jìn)行優(yōu)化的規(guī)范化結(jié)構(gòu)。但這種結(jié)構(gòu)使分析和報(bào)告更加困難。數(shù)據(jù)倉庫建模方法對數(shù)據(jù)進(jìn)行非規(guī)范化和重組,以優(yōu)化整合層中的分析,同時(shí)仍便于快速寫入加工層。

二、數(shù)據(jù)倉庫建模方法

1.第三范式(3NF)

第三范式 (3NF) 是一種經(jīng)典的關(guān)系數(shù)據(jù)庫建模方法,可最大限度地減少數(shù)據(jù)冗余。在 3NF 中,每個(gè)非鍵列僅依賴于表的主鍵。

將 3NF 應(yīng)用于我們的餐廳數(shù)據(jù)倉庫,我們將進(jìn)一步分離表格,這樣各個(gè)表格結(jié)構(gòu)中就不會(huì)有層次結(jié)構(gòu),而是作為表格鏈接的層次結(jié)構(gòu)。訂單和付款等交易表將引用元數(shù)據(jù)表的主鍵,而元數(shù)據(jù)表又將引用更高級別的元數(shù)據(jù)表。

本質(zhì)上,我們要做的改變是確定客戶表包含地址詳細(xì)信息,這是自然層次結(jié)構(gòu)。然后,我們會(huì)將它們拆分為組件表。通常,您不會(huì)將此方法用于整合層,但它可能適用于加工層。如果您正在提取可能以不同粒度級別本機(jī)構(gòu)建的多個(gè)源,則尤其如此。

3NF 實(shí)體關(guān)系數(shù)據(jù)庫

優(yōu)點(diǎn):

減少數(shù)據(jù)冗余,節(jié)省存儲(chǔ)空間

通過主鍵關(guān)系保證數(shù)據(jù)完整性

提供靈活性以適應(yīng)未來的變化

缺點(diǎn):

可能需要進(jìn)行許多表連接進(jìn)行分析,從而影響查詢性能

對于業(yè)務(wù)用戶來說,理解和操作起來可能很復(fù)雜

2.Kimball星型模式

Kimball 星型模式是數(shù)據(jù)倉庫中的一個(gè)關(guān)鍵概念,由數(shù)據(jù)倉庫和商業(yè)智能領(lǐng)域的杰出人物 Ralph Kimball 提出。它旨在簡化數(shù)據(jù)存儲(chǔ)并提高查詢性能,使復(fù)雜的數(shù)據(jù)結(jié)構(gòu)更易于管理并更易于進(jìn)行業(yè)務(wù)分析。

關(guān)鍵部件

事實(shí)表:事實(shí)表是星型模式的核心,包含定量數(shù)據(jù),例如銷售額、交易次數(shù)和其他可衡量指標(biāo)。事實(shí)表中的每條記錄都對應(yīng)一個(gè)特定事件或交易,并包含鏈接到維度表的外鍵。由于它保存的交易數(shù)據(jù)量很大,因此該表通常很大。通常,它包括銷售額、銷售量和成本等數(shù)值度量,以及引用維度表的鍵。

維度表:維度表是為事實(shí)表中的數(shù)據(jù)提供上下文的外圍表。它們包含與業(yè)務(wù)維度相關(guān)的描述性屬性,例如時(shí)間段、地理位置、產(chǎn)品、客戶和員工。與事實(shí)表相比,維度表通常更小且更靜態(tài)。它們以非規(guī)范化形式存儲(chǔ)數(shù)據(jù)以簡化查詢,使其更易于理解和導(dǎo)航。

結(jié)構(gòu)和設(shè)計(jì)

星型模式因其布局類似星星而得名。事實(shí)表位于中心,周圍是維度表,每個(gè)維度表都通過外鍵連接到事實(shí)表。這種設(shè)計(jì)非常直觀,允許用戶在事實(shí)表和維度表之間執(zhí)行直接連接。

在我們的餐廳示例中,我們將有一個(gè)中央訂單事實(shí)表,其中包含客戶、日期、產(chǎn)品等維度表的外鍵。維度表包含冗余、非規(guī)范化的數(shù)據(jù),以避免進(jìn)一步連接。這是倉庫中整合層或表示層的一種相當(dāng)標(biāo)準(zhǔn)的方法。

訂單數(shù)據(jù)的星型模式 ERD

優(yōu)點(diǎn):

通過最小化連接來優(yōu)化快速查詢

對于熟悉業(yè)務(wù)流程的業(yè)務(wù)用戶來說很直觀

聚合計(jì)算簡單

缺點(diǎn):

非規(guī)范化增加了數(shù)據(jù)冗余

處理緩慢變化的維度可能很棘手

適應(yīng)未來變化的靈活性較差

3.雪花模式

雪花模式是數(shù)據(jù)倉庫中星型模式的一種變體,旨在處理復(fù)雜且高度規(guī)范化的數(shù)據(jù)結(jié)構(gòu)。該模式因其復(fù)雜的雪花狀形狀而得名,它將數(shù)據(jù)組織到多個(gè)相關(guān)表中,從而增強(qiáng)了數(shù)據(jù)完整性并減少了冗余。然而,這會(huì)增加查詢編寫的復(fù)雜性并可能影響性能。它幾乎可以看作是星型模式和 3NF 的混合體。

關(guān)鍵部件

事實(shí)表:事實(shí)表仍然是雪花模式中的中心表,包含定量數(shù)據(jù),例如銷售額、收入或其他業(yè)務(wù)指標(biāo)。它包含維度表的外鍵,為事實(shí)提供背景信息。事實(shí)表中的每條記錄代表一個(gè)可測量的事件,并包括數(shù)值度量和鏈接到相關(guān)維度的外鍵。

維度表:與星型模式不同,雪花模式進(jìn)一步規(guī)范化了維度表。每個(gè)維度表都可以分解為多個(gè)相關(guān)表,從而創(chuàng)建更規(guī)范的結(jié)構(gòu)。例如,我們的客戶維度將地址拆分為郵政編碼、城市和州表,每個(gè)表都通過外鍵鏈接。這種規(guī)范化減少了數(shù)據(jù)冗余,但增加了查詢所需的連接數(shù)。

結(jié)構(gòu)和設(shè)計(jì)

雪花模式由于其多級結(jié)構(gòu)而類似于雪花。維度表被規(guī)范化為多個(gè)相關(guān)表,分散成復(fù)雜的網(wǎng)狀結(jié)構(gòu)。這種設(shè)計(jì)旨在通過消除冗余來節(jié)省存儲(chǔ)空間并提高數(shù)據(jù)完整性。

訂單數(shù)據(jù)的雪花模式

優(yōu)點(diǎn):

與星型模式相比,減少了數(shù)據(jù)冗余

通過規(guī)范化確保數(shù)據(jù)完整性

使維度表更易于維護(hù)

缺點(diǎn):

與星型模式相比,可能需要更多連接,從而影響查詢性能

商業(yè)用戶更難理解和駕馭

4.寬表 (OBT)

One-Big-Table (OBT) 設(shè)計(jì),也稱為平面表或?qū)挶?,是一種數(shù)據(jù)倉庫方法,其中所有數(shù)據(jù)都合并到單個(gè)非規(guī)范化表中。這種方法與星型和雪花型等規(guī)范化模式形成鮮明對比,它提供了更簡單的結(jié)構(gòu),但代價(jià)是冗余度增加,并且在處理非常大的數(shù)據(jù)集時(shí)可能會(huì)出現(xiàn)性能問題。

關(guān)鍵部件

單表:OBT 設(shè)計(jì)的核心特征是所有相關(guān)數(shù)據(jù)都存儲(chǔ)在一個(gè)綜合表中。該表包含大量列,可捕獲分析所需的所有屬性和度量。該表可能包含數(shù)千列,每行代表一條包含多個(gè)維度和指標(biāo)的唯一記錄。

屬性和指標(biāo):在 OBT 設(shè)計(jì)中,屬性(通常在其他模式的維度表中找到)和指標(biāo)(通常在事實(shí)表中找到)被組合到單個(gè)表中。例如,客戶詳細(xì)信息、產(chǎn)品信息和銷售數(shù)據(jù)都將存儲(chǔ)在同一張表中,每條記錄都提供交易或事件的完整快照。

結(jié)構(gòu)和設(shè)計(jì)

OBT 設(shè)計(jì)的結(jié)構(gòu)非常簡單,只包含一個(gè)表,其中每行包含所有必要的數(shù)據(jù)點(diǎn)。這種扁平結(jié)構(gòu)無需連接,用戶無需了解復(fù)雜的表關(guān)系即可輕松查詢和檢索數(shù)據(jù)。

對于我們的餐廳,我們將為三個(gè)關(guān)鍵事件(預(yù)訂、訂單和付款)分別設(shè)置一個(gè)大表。我看到過一些關(guān)于 OBT 還是星型模式是更好的方法的相當(dāng)激烈的爭論。答案是“視情況而定”。如果您將數(shù)據(jù)拉入 Power BI,它將需要星型模式樣式的數(shù)據(jù)集。但是,如果您將數(shù)據(jù)拉入 Tableau,您可能更喜歡 OBT 方法。但應(yīng)該注意的是,如果您確實(shí)選擇 OBT,則應(yīng)將任何可重復(fù)使用的邏輯保留在可以反復(fù)引用的支持表中。

OBT 示例

優(yōu)點(diǎn):

極快的查詢性能,無需連接

所有數(shù)據(jù)都集中在一處,簡單易懂

適合數(shù)據(jù)科學(xué)消費(fèi)

缺點(diǎn):

數(shù)據(jù)冗余度高,需要大量存儲(chǔ)空間

如果不改變整個(gè)表結(jié)構(gòu),就很難做出改變

包含許多列的查詢可能難以編寫和維護(hù)

5.數(shù)據(jù)倉庫2.0

Data Vault 2.0 是一種現(xiàn)代數(shù)據(jù)倉庫方法,旨在提供可擴(kuò)展、靈活且可審計(jì)的數(shù)據(jù)模型。它由 Dan Linstedt 開發(fā),以原始 Data Vault 方法為基礎(chǔ),對其進(jìn)行了增強(qiáng),以更好地支持當(dāng)今復(fù)雜的數(shù)據(jù)環(huán)境。Data Vault 2.0 滿足了處理大數(shù)據(jù)、非結(jié)構(gòu)化數(shù)據(jù)和各種數(shù)據(jù)源的需求,同時(shí)保持了數(shù)據(jù)完整性和歷史準(zhǔn)確性。與 3NF 一樣,這將位于您的銀層。這不是您指向 BI 工具的東西。

關(guān)鍵部件

樞紐:樞紐存儲(chǔ)具有唯一代理鍵和元數(shù)據(jù)(如加載日期和源信息)的唯一業(yè)務(wù)鍵。每個(gè)樞紐代表一個(gè)核心業(yè)務(wù)概念,例如客戶、產(chǎn)品或訂單。樞紐高度穩(wěn)定且很少發(fā)生變化,為數(shù)據(jù)倉庫提供一致的參考點(diǎn)。

鏈接:鏈接捕獲存儲(chǔ)在中心中的業(yè)務(wù)鍵之間的關(guān)系。每個(gè)鏈接表包含相關(guān)中心的外鍵以及元數(shù)據(jù)。鏈接表示實(shí)體之間的事務(wù)、關(guān)聯(lián)或?qū)哟谓Y(jié)構(gòu)。它們用于對多對多關(guān)系以及關(guān)系隨時(shí)間的變化進(jìn)行建模。

衛(wèi)星:衛(wèi)星存儲(chǔ)中心中業(yè)務(wù)鍵或鏈接中關(guān)系的描述性屬性和上下文。它們包括用于跟蹤隨時(shí)間變化的元數(shù)據(jù),例如加載日期和來源。衛(wèi)星可以在不影響核心業(yè)務(wù)鍵和關(guān)系的情況下發(fā)展,從而可以靈活地適應(yīng)新的業(yè)務(wù)需求。

結(jié)構(gòu)和設(shè)計(jì)

Data Vault 2.0 采用模塊化架構(gòu)設(shè)計(jì),將數(shù)據(jù)存儲(chǔ)分為這三種類型的表,從而提高可擴(kuò)展性和靈活性。集線器、鏈路和衛(wèi)星被設(shè)計(jì)為增量和并行加載,從而可以高效處理大量數(shù)據(jù)和隨時(shí)間變化的數(shù)據(jù)。

數(shù)據(jù)倉庫 ERD 示例

優(yōu)點(diǎn):

旨在應(yīng)對業(yè)務(wù)需求隨時(shí)間的變化

將結(jié)構(gòu)變化與信息變化分開

提供可追溯性并保存歷史記錄

缺點(diǎn):

設(shè)計(jì)和實(shí)施起來可能很復(fù)雜

需要許多表格和連接來匯總數(shù)據(jù)進(jìn)行分析

查詢可能難以編寫和理解

6.活動(dòng)模式

活動(dòng)模式是 Ahmed Elsamadisi 設(shè)計(jì)的一種數(shù)據(jù)倉庫方法,用于以結(jié)構(gòu)化和高效的方式捕獲業(yè)務(wù)活動(dòng)或事件的詳細(xì)記錄。此模式側(cè)重于記錄企業(yè)內(nèi)部執(zhí)行的操作或交易,因此對于事件驅(qū)動(dòng)數(shù)據(jù)和詳細(xì)交易日志記錄特別有用。它已用于需要跟蹤大量細(xì)粒度事件的系統(tǒng),例如電子商務(wù)網(wǎng)站、金融系統(tǒng)或物聯(lián)網(wǎng)應(yīng)用程序。

關(guān)鍵部件

活動(dòng)表:活動(dòng)模式中的中心表是活動(dòng)表,它記錄每個(gè)業(yè)務(wù)活動(dòng)或事件。活動(dòng)表中的每一行代表單個(gè)事件或交易,捕獲有關(guān)發(fā)生了什么、何時(shí)發(fā)生以及其他相關(guān)背景的詳細(xì)信息。此表屬性已定義為標(biāo)準(zhǔn)的一部分,因此易于實(shí)現(xiàn)。

維度表:活動(dòng)表附帶一個(gè)可選維度表,該維度表為活動(dòng)表中記錄的事件提供額外的背景信息。維度可能包括有關(guān)客戶、產(chǎn)品、位置、時(shí)間和其他相關(guān)實(shí)體的詳細(xì)信息,具體取決于它所涉及的活動(dòng)流。

在我們的餐廳示例中,我們可能有一個(gè)帶有相關(guān)客戶維度的客戶活動(dòng)表?;顒?dòng)表將跟蹤客戶的活動(dòng),例如他們的預(yù)訂、訂單和付款。這些活動(dòng)的詳細(xì)信息保存在列中feature_json,并有一個(gè)可選列用于存儲(chǔ)相關(guān)的收入影響。

活動(dòng)架構(gòu)示例

優(yōu)點(diǎn):

設(shè)計(jì)簡單直觀,表格數(shù)量極少

無需更改架構(gòu)即可捕獲實(shí)體的其他活動(dòng)

僅當(dāng)需要跟蹤新實(shí)體時(shí)才需要新表

缺點(diǎn):

相對較新的方法,尚未被廣泛采用

可能不適合所有業(yè)務(wù)領(lǐng)域和分析需求

7.以實(shí)體為中心的建模

以實(shí)體為中心的建模是一種靈活的方法,由 Maxime Beauchemin 提出,專注于圍繞客戶和產(chǎn)品等實(shí)體進(jìn)行建模。每個(gè)實(shí)體都有自己的表,使用 JSON 來跟蹤包括聚合在內(nèi)的各種指標(biāo)。這種方法不需要額外的維度表,因?yàn)閷?shí)體表位于實(shí)體的最低粒度,并且可以直接在表中包含其屬性。

在餐廳環(huán)境中,我們會(huì)有一個(gè)客戶表,其中包含客戶屬性列,加上一個(gè) json 列來保存時(shí)間綁定指標(biāo),例如visit.7d,,visit.14d。sale.30d

以實(shí)體為中心的建模

優(yōu)點(diǎn):

靈活適應(yīng)不斷變化的業(yè)務(wù)需求

只需少量表格即可輕松理解

在指標(biāo)欄內(nèi)有效捕捉歷史記錄

缺點(diǎn):

查詢可能很復(fù)雜,通常需要解除半結(jié)構(gòu)化數(shù)據(jù)的嵌套

實(shí)體具有重疊屬性或行為類型時(shí)的挑戰(zhàn)

與星型模式相比,更難實(shí)施完整性約束

三、選擇正確的建模方法

考慮到這七種常見的數(shù)據(jù)倉庫建模方法,如何為您的數(shù)據(jù)倉庫選擇正確的方法?請考慮以下因素:

分析要求:您需要回答哪些類型的問題?選擇針對這些查詢模式進(jìn)行優(yōu)化的模型。

數(shù)據(jù)量和可擴(kuò)展性:考慮您現(xiàn)在擁有的數(shù)據(jù)量以及未來預(yù)期的數(shù)據(jù)量。有些方法的可擴(kuò)展性優(yōu)于其他方法。

易用性:考慮誰將查詢數(shù)據(jù)倉庫。有些模型對于非技術(shù)用戶來說更直觀。

靈活性:您的業(yè)務(wù)可能會(huì)不斷發(fā)展。選擇能夠適應(yīng)不斷變化的需求的模型。

性能:考慮查詢速度和數(shù)據(jù)冗余之間的權(quán)衡。非規(guī)范化模型通常速度更快,但需要更多存儲(chǔ)空間。

最后,“正確”的數(shù)據(jù)倉庫建模方法取決于您獨(dú)特的業(yè)務(wù)需求和優(yōu)先事項(xiàng)。通過了解每種建模技術(shù)的優(yōu)勢和劣勢,您可以設(shè)計(jì)一個(gè)數(shù)據(jù)倉庫,提供快速、靈活且富有洞察力的分析,以推動(dòng)公司發(fā)展。