資料架構 - 資料建模方法

資料建模是資料架構的重要組成部分。這意味著要規劃如何在系統中組織、儲存和使用資料。本章介紹不同的資料建模方法，幫助您學習如何為您的組織建立有用的資料模型。

什麼是資料建模？

資料建模是資料庫設計中一項重要的技術。它包括確定需要儲存哪些資料，並將資料組織到表和列中，以顯示不同資料片段之間的關係。這種結構可以應用於不同型別的資料庫，包括關係型資料庫和NoSQL資料庫。

關係型建模

關係型建模由Edgar F. Codd於1970年提出。它將資料組織成表（關係），每個表包含記錄的行和屬性的列。這種方法使用鍵來顯示錶之間的關係，有助於維護資料準確性並更容易檢索資訊。

關係型建模中的鍵

在關係型建模中，鍵對於保持資料庫的組織性和準確性非常重要。它們有助於唯一地標識每條記錄，並顯示不同表之間的連線方式。以下是一些關鍵型別。

主鍵：這是表中每條記錄的唯一識別符號，例如學生表中的StudentID。
外部索引鍵：外部索引鍵是一個表中的一列，它連結到另一個表中的主鍵，從而建立關係。例如，銷售表中的ProductKey連線到產品表中的產品。
自然鍵：一個已經存在的唯一欄位，用作主鍵，例如社會安全號碼（政府頒發的用於識別個人的號碼）。

實體關係圖

通常，您從實體關係（ER）圖開始關係型建模。該圖顯示了資料庫的不同部分（實體）以及它們是如何連線的（關係）。完成ER圖後，您可以建立一個更詳細的模型，其中包括資料庫的實際表和列。

這就是建立ER圖的方法。

在上圖的ER圖中，我們表示學生和課程實體。以下是我們所做的簡要說明

實體：該圖包含兩個主要實體：學生和課程。
屬性：該圖列出了學生和課程實體的屬性。學生實體具有以下屬性：
- StudentID（唯一識別符號）
- 姓名（組合：名，中間名，姓）
- 電話號碼（多值屬性）
課程實體包括：
- Cou_ID（唯一識別符號）
- 名稱（課程名稱）
弱實體：成績是一個弱實體，它依賴於學生和課程實體。
關係：註冊關係連線學生和課程，這意味著一個學生可以註冊多門課程。獲得關係連線學生和成績，表明一個學生可以獲得多個成績。
關係中的關鍵屬性
- 註冊關係可能包括註冊日期和狀態。
- 獲得關係可能包括成績日期。
組合和多值屬性：學生實體的名稱屬性是組合屬性，而電話號碼是多值屬性。

ER圖元件

該圖包含幾個元件，顯示實體如何相互關聯。以下是建立ER圖中使用的關鍵元件。

用於資料完整性的規範化規則

建立ER圖後，應用規範化。規範化是一個將複雜資料庫分解成更簡單表的過程。這有助於減少重複資料並提高資訊的準確性。該過程包括幾個步驟，稱為正規化

第一正規化 (1NF)：此正規化確保表被正確組織。它要求：
- 表具有主鍵。
- 每列只有一值。
- 沒有重複的列組。
第二正規化 (2NF)：基於1NF，此正規化確保：
- 它滿足1NF的所有條件。
- 每個非鍵列僅依賴於主鍵。
第三正規化 (3NF)：基於1NF，此正規化確保：
- 它滿足1NF和2NF的所有條件。
- 非鍵列必須直接連線到主鍵，而不是透過另一列。

使用歷史表跟蹤更改

在關係型資料庫中，跟蹤隨時間推移的更改非常重要。為此，我們使用歷史表。這些表是原始表的副本，但它們具有額外的列來記錄重要的細節，例如：

時間戳：更改發生的時間。
使用者ID：更改發生的時間。
之前/之後的值：更改之前的數值和更改後的新數值。

歷史表對於審計、報告和資料恢復非常有幫助。它們為您提供了資料隨時間推移如何變化的完整檢視。

維度建模

維度建模始於1996年，目的是簡化資料的分析和查詢。它將資料分為兩部分：事實（即數字或資料點）和維度（即提供上下文，如類別或日期）。當常規資料庫變得緩慢或難以使用時，此方法很有用。它通常採用這些傳統資料庫中的資料來建立更有效的資訊分析方式。

維度建模中的事實

在維度建模中，“事實”是衡量特定指標（如銷售額或收入）的數值資料點。這些事實可以組合或彙總，例如查詢平均值或總計，這使得更容易分析資料。這樣，您可以快速從大型資訊集中發現有用的見解。

維度建模中的維度

在維度建模中，“維度”有助於解釋事實。它們描述有關資料的重要詳細資訊，例如時間、產品或客戶資訊。維度通常組織成層次結構，允許更深入的資料分析。事實表儲存數值資料，而維度表則保留描述此資料的相關詳細資訊。

維度建模中的鍵

在維度建模中，我們通常使用代理鍵作為主鍵而不是自然鍵。代理鍵是專門建立的人工值，用於唯一標識資料庫中的記錄，當自然鍵不可用或不合適時，它們很有用。

自然鍵可以提供有意義的資訊，但它們也有一些缺點。

它們可能更長更復雜。
它們可能包含敏感資訊，這可能會引發隱私問題。
在組合來自不同系統的資料時，它們可能會導致重複或不一致。

跟蹤維度建模中的更改

在維度建模中，我們使用緩慢變化維度 (SCD) 來跟蹤資料中的更改，這有助於管理資料隨時間的變化方式。共有三種類型。

型別1：此型別用新資料替換舊資料。它用於不需要保留舊資訊的小型更改，例如更正電話號碼。
型別2：此型別保留資料的新舊版本。它用於跟蹤隨時間的變化，例如當客戶搬到新地址時，確保我們擁有準確的歷史資訊。
型別3：此型別為每次更改建立一個新記錄，保留資料的完整歷史記錄。雖然它更復雜，但它允許我們保留所有更改的詳細記錄。

歷史表與緩慢變化維度

歷史表和緩慢變化維度 (SCD) 都跟蹤資料中的更改，但它們採用不同的方式。

歷史表：這些表保留每條記錄的完整更改歷史記錄。它們跟蹤記錄隨時間的每個版本，允許您檢視對特定條目所做的所有更改。
緩慢變化維度 (SCD)：緩慢變化維度專注於管理維度表中的更改，維度表儲存有關資料的詳細資訊。它們允許使用型別1、型別2和型別3等方法進行清晰且結構化的更新。SCD確保歷史資料保持準確和可靠，從而更容易分析隨時間的趨勢。

歷史表提供了每條記錄所有更改的完整檢視，而緩慢變化維度則側重於維度資料隨時間的變化方式。這樣，我們可以確保歷史資訊準確且易於查詢。

維度建模中的反規範化

反規範化意味著在維度建模中將資料複製到多個表中。這透過減少表數和所需的連線數來簡化資料庫，從而使查詢執行速度更快，並幫助您更輕鬆地建立報表。

但是，保持此複製資料的一致性可能很困難。例如，如果類別名稱更改，則必須在維度模型中的多個位置更新它。在關係模型中，您只需更新一次，這有助於防止錯誤。

比較維度模型和關係模型

在資料管理中，維度模型和關係模型是兩種不同的方法。維度模型旨在簡化資料分析，而關係模型則專注於準確地組織資料。

維度模型
- 這些模型有利於分析資料和了解業務績效。
- 它們可以有效地處理許多表，從而加快查詢速度並簡化報告。
關係模型
- 如果資料以標準的表格形式（帶有行和列）組織，則這些模型更容易設定。
- 它們專注於保持資料的正確性和減少重複，但這可能會減慢分析速度。

維度建模使用不同的佈局，例如星型和雪花型模式。星型模式有一個主表，周圍環繞著其他表，使其清晰易懂。

維度模型更適合於分析資料，而關係模型提供了一種清晰的管理資料的方式。兩者之間的選擇取決於業務需求和資料的複雜程度。

資料建模中的通用資料模型

公共資料模型 (CDM) 是一種用於儲存和組織資料，尤其是在資料倉庫中的標準方法。它建立了一種清晰一致的表格資料表示方式，使不同的系統更容易理解和使用這些資訊。

當從不同的來源（例如各種客戶關係管理 (CRM) 系統）匯入資料時，只使用一個系統的格式是不切實際的。每個系統可能具有不同的表結構和欄位名稱，這可能會導致混淆。相反，您應該建立一個新的公共資料模型 (CDM)，將所有這些格式整合到一個清晰的結構中。此公共資料模型 (CDM) 將足夠靈活，以滿足您當前和未來的資料需求。許多雲提供商提供易於定製的特定行業 CDM，幫助您節省時間並降低資料整合風險。

資料倉庫建模

資料倉庫建模是由 Daniel Linstedt 於 2000 年開發的一種組織資料的方法。它提供了一種靈活可靠的方式來管理歷史資料，從而更容易跟蹤隨時間推移的變化。

資料倉庫模型具有三個主要部分

中心表 (Hubs): 這些表代表重要的業務概念，例如客戶或產品，並具有唯一的 ID。
連結表 (Links): 這些表顯示中心表之間是如何關聯的，使用連線到中心表 ID 的鍵。
衛星表 (Satellites): 這些表儲存有關中心表或連結表的額外詳細資訊，例如隨時間的變化，並透過鍵連線。

資料倉庫的缺點

雖然資料倉庫建模提供了靈活性和清晰的歷史資料管理方法，但它也面臨一些挑戰，這些挑戰可能會影響其工作效率和設定難度。

複雜性： 設定資料倉庫建模可能很複雜，需要熟練的專業人員進行管理。
資料重複： 儲存詳細資料可能會導致重複條目，從而增加儲存成本。
效能： 擁有許多表可能會降低資料檢索速度，使查詢變得更加複雜。
缺乏標準化： 由於它是一種較新的方法，因此可能很難找到經驗豐富的資料倉庫建模工程師。

Kimball和Inmon資料倉庫方法論

本節介紹構建資料倉庫的兩種主要方法：Inmon 方法和Kimball 方法。每種方法都有其自身的優點和挑戰，正確的選擇取決於您組織的需求。

Inmon 的自頂向下方法

Inmon 方法從收集來自不同來源資訊的中央資料倉庫開始。之後，將為特定部門建立使用中央倉庫資料的小型資料市場。這種結構化的方法通常受到注重資料質量的大型組織的青睞。

Inmon 方法中的流程

資料暫存：首先，資料從不同的來源快速收集到臨時表中，而無需任何更改。
企業資訊工廠 (CIF)：接下來，資料在一箇中心位置進行組織，作為組織的主要事實來源。
從屬資料市場：在設定CIF之後，將為不同的部門建立小型資料市場，使用中心資料作為其資訊來源。

優點：這種方法有助於保持較高的資料質量，並且適用於具有複雜資料需求的大型組織。

挑戰：它可能導致資料重複，從而增加儲存成本並使維護更加困難。

Kimball 的自底向上方法

Kimball 方法首先將原始資料收集到稱為暫存表的臨時表中，而無需對其進行清理。此方法側重於首先建立獨立的資料市場，這些資料市場旨在滿足不同業務領域的特定需求。然後將這些資料市場連線起來，以提供資料的完整檢視。

Kimball 方法中的流程

獨立資料市場：每個資料市場都是為特定部門構建的，使用簡單的模型來簡化分析。
整合：資料市場透過公共維度連結，確保所有領域保持一致。
用於報告的立方體：資料可以組織成立方體，這使得可以從不同的角度檢視資料變得容易。這有助於您快速找到重要的見解。

優點：這種方法鼓勵使用者參與，從而導致更好的資料管理。它還減少了重複儲存相同資料的可能性。

挑戰：如果管理不善，資料市場之間可能會存在差異，這可能會導致混淆和不準確的報告。

Inmon 和 Kimball 之間的區別

本節顯示了Inmon 和Kimball 方法之間的主要區別，重點關注每種方法如何滿足不同的需求。

起點：Inmon 從建立收集來自不同來源資料的中央資料倉庫開始。相比之下，Kimball 從一開始就專注於構建單獨的資料市場，以滿足不同部門的特定需求。
結構：Inmon 強調物理中央資料倉庫，它充當組織的單一事實來源。然而，Kimball 允許更大的靈活性，使組織無需嚴格的中央倉庫即可建立資料市場。
適應性：Inmon 和 Kimball 都可以適應現代資料實踐，例如使用資料湖。這種靈活性有助於組織跟上不斷變化的資料需求，並使管理各種資料來源變得更容易。

這些差異幫助組織選擇最適合其資料管理需求和目標的方法。

混合模型

混合模型結合了Kimball 和Inmon 方法的部分內容。它首先從各種聯機事務處理 (OLTP) 系統收集原始資料到臨時儲存表中，而無需對其進行清理。

然後，資料將移動到企業資訊工廠 (CIF)，在那裡以詳細格式儲存。之後，資料將傳輸到獨立的維度資料市場，這些資料市場可以根據每個部門的需求同時儲存詳細資料和彙總資料。

一些資料也可以放入立方體中進行報告。建議使用立方體，因為它們：

充當清晰的介面。
同時支援多個使用者。
提供彙總資料以提高速度。
消除複雜的連線。
包含層次結構和關鍵績效指標 (KPI)。
透過行級安全性確保資料隱私。
允許進行高階時間計算以進行趨勢分析。

在提取、轉換、載入 (ETL) 流程中使用資料庫檢視可以簡化編碼並改進查詢。檢視是基於 SQL 查詢的虛擬表，有助於管理複雜性而無需儲存額外資料。

映象 OLTP 系統

混合模型涉及一個映象聯機事務處理 (OLTP) 系統，這是一個與原始系統一起執行的副本。此安排允許主 OLTP 專注於使用者訪問和維護，同時收集資料。它還可以簡化提取、轉換、載入 (ETL) 流程，並可以透過允許特定索引而不會影響原始系統來提高效能。

選擇正確的資料模型

選擇資料模型時，沒有一刀切的方法。您的決策應考慮安全、資料大小和效能等因素。例如，新增星型模式可以提高查詢效能。

關於Inmon和Kimball方法的常見誤解

以下是關於Inmon 和Kimball 資料方法的一些常見誤解

Kimball 純粹是自底向上的：事實上，Kimball 將自頂向下的規劃與自底向上的執行相結合，重點關注設計和實施。
Inmon 需要大量的預先設計：Inmon 支援逐步構建資料倉庫的方法，而不是試圖一次完成所有工作。
Inmon 不支援星型模式：實際上，Inmon 認識到星型模式資料市場對於使用者更容易訪問的好處。
很少有公司使用 Inmon 的方法：調查顯示，許多組織實際上更喜歡 Inmon 方法。
這些方法是不相容的：Kimball 和 Inmon 可以很好地協同工作，尤其是在混合模型中。

Kimball 方法包括專案規劃和維護，而Inmon 則專注於資料倉庫本身。當人們談論 Kimball 時，他們通常指的是維度建模，其中包括一致維度和快照事實表等技術。

列印頁面