定義數據模型 (Define the data model)
數據模型是一種高層次的抽象方法,用於組織和管理資料庫或資訊系統中的數據。它建立了數據元素(代表現實世界中的實體)之間的關係,並規範了這些數據如何被有序地儲存及有效地檢索。這種模型可以是理論上的概念架構,也可以是具體實施的結構。
數據模型的主要目標在於支援資訊系統的開發,它通過確立數據的明確定義和格式化結構來達成此目的。數據模型通常以圖形的形式呈現,例如透過圖表來直觀表示數據間的聯繫。它對於構建資料庫和數據倉庫、管理數據分析處理流程,以及開發允許使用者以有意義方式存取資訊的應用程式,扮演著關鍵的角色。
數據模型是文件化和組織數據的藍圖,它指導如何存儲和訪問數據,以及不同類型數據元素之間的相互關聯。這些模型可以是抽象的,提供概念上的數據組織方式;也可以是具體的,明確指出資料結構的實際實現細節。
在英文中,數據模型(data model)和資料模型(information model)有一些區別。數據模型是一種描述資料結構和關係的方式,而資料模型是一種描述資料的含義和用途的方式。數據模型通常用於資料庫或資訊系統的設計,而資料模型通常用於資料的分析或交換。
建立數據模型的步驟包括:
- 識別不同的數據組件,考慮原始數據和處理後的數據,以及相關的元數據(這些被稱為實體)。
- 識別不同數據組件之間的關係(這些被稱為關聯)。
- 識別數據的預期用途(這些被稱為需求),並認識到數據在未來可能對未預期的用途具有更大的價值。
- 識別您計劃在項目中使用的技術(硬件和軟件)的優勢和限制(這被稱為技術評估階段)。
- 構建實體和它們關係的草案模型,嘗試使模型獨立於任何特定的用途或技術約束。
數據模型的類型有
概念數據模型:這種模型識別了不同實體之間的最高級別關係,但不指定屬性或主鍵。
企業數據模型:這種模型建立了一個跨企業的數據元素和關係的共同視圖和理解,可以整合不同部門或資料庫的數據。
邏輯數據模型:這種模型描述了數據的盡可能詳細的資訊,而不考慮它們在資料庫中的物理實現。這種模型指定了每個實體的所有屬性和主鍵,以及外鍵和關係。這種模型通常需要進行規範化。
物理數據模型:這種模型表示了模型在資料庫中的建構方式。這種模型顯示了所有表結構,包括列名,列數據類型,列約束,主鍵,外鍵和表之間的關係。這種模型可能根據用戶需求或技術考慮而發生反規範化。這種模型也可能因不同的關係型資料庫管理系統而有所不同。
關係數據模型:這種模型是一種將現實世界視為實體和關係的數據模型。這種模型的目的是將數據規範化並呈現在一種良好的規範形式中。
維度數據模型:這種模型是一種邏輯設計技術,旨在將數據以一種標準的,直觀的框架呈現,以便高性能的訪問。這種模型本質上是維度的,並且遵循一種使用關係模型的紀律,但有一些重要的限制。每個維度模型由一個具有多部分鍵的表組成,稱為事實表,以及一組較小的表,稱為維度表。每個維度表都有一個單部分主鍵,與事實表中的多部分鍵的一個組成部分完全對應。這種特徵“星形”結構通常被稱為星形連接。
包括不同實體之間的重要實體和關係。實體是概念,關於收集資訊的實在或抽象的。
不指定任何屬性。
不指定主鍵。
企業數據模型
在整個企業中開發數據元素及其關係的共同一致的觀點和理解,稱為企業數據建模。
這種類型的數據建模為遍布整個由不同部門或部門控制的企業的資訊提供訪問,這些部門或部門具有不同的資料庫和數據模型。
企業數據建模有時也稱為全球業務模型,整個企業的所有資訊將以實體的形式捕獲。
當企業邏輯數據模型轉換為物理數據模型時,超類型和子類型可能不會原封不動。即邏輯結構和物理結構超類型和子類型可能完全不同。
邏輯數據建模
邏輯數據模型盡可能詳細地描述數據,而不考慮它們將如何在資料庫中物理實現。邏輯數據模型的特點包括:
包括所有實體及其之間的關係。
指定每個實體的所有屬性。
指定每個實體的主鍵。
指定外來鍵。
此級別發生正規化。
物理數據建模
物理數據模型表示模型將在資料庫中構建的方式。物理資料庫模型顯示所有表結構,包括列名稱、列數據類型、列約束、主鍵、外鍵和表之間的關係。物理數據模型的特點包括:
指定所有表和列。
使用外來鍵標識表之間的關係。
根据用户需求可能發生反规范化。
物理考慮可能會導致物理數據模型與邏輯數據模型之間存在很大差異。
不同的 RDBMS 的物理數據模型將不同。例如,MySQL、SQL Server、Oracle、Postgres 等中的列數據類型可能不同。
關系數據建模
關係數據模型是一種將現實世界視為實體和關係的數據模型。
實體是收集資訊的概念、實在或抽象。
關係數據模型的目標是正規化數據並以良好的規範形式呈現它。
以下是關係數據模型開發過程中出現的一些問題:
數據模型的未來範圍是什麼?
如何正規化數據?
如何組合屬性和實體?
如何將一個實體連接到另一個實體?
如何驗證數據?
如何呈現報告?
維度數據建模
DM 是一種邏輯設計技術,該技術旨在以標準的、直觀的框架呈現數據,該框架允許高性能訪問。它本質上是維度的,並遵循一些重要限制的紀律使用關係模型。每個維度模型都由一個帶有多部分鍵的表組成,稱為事實表,以及一組稱為維度表的小表。每個維度表都有一個單部分主鍵,與事實表中多部分鍵的組成部分完全對應。這種特徵“星型”結構通常稱為星形聯接。
事實表由於具有由兩個或多個外鍵組成的多部分主鍵,因此始終表示多對多關係。最有用的事實表還包含一個或多個對定義每條記錄的鍵組合發生的數值計量或“事實”。
與此相反,維度表最常包含描述性文本資訊。維度屬性幾乎總是數據倉庫查詢中最有趣的約束的來源,它們幾乎總是 SQL 答案集中的行標題的來源。
物理與邏輯
關係與維度
數據倉庫
數據倉庫是一種面向主題的、集成的、與時間變化的、非揮發性的數據集合,用於支援管理層的決策過程。
面向主題:數據倉庫可用於分析特定主題領域。例如,“銷售”可以是特定主題。
集成:數據倉庫整合來自多個數據源的數據。例如,源 A 和源 B 可能有不同的產品標識方式,但在數據倉庫中,只有一種標識產品的方式。
時變:歷史數據保存在數據倉庫中。例如,可以從數據倉庫中檢索 3 個月、6 個月、12 個月甚至更早的數據。這與事務系統形成對比,事務系統中經常只保存最新數據。例如,事務系統可能保留客戶的最新地址,而數據倉庫可以保存與客戶相關的所有地址。
不揮發性:一旦數據進入數據倉庫,它就不會更改。因此,數據倉庫中的歷史數據永遠不應該被更改。
數據倉庫是交易數據的副本,特別結構化以進行查詢和分析。
數據倉庫體系結構 所有數據倉庫系統都具有以下層:
數據源層
數據提取層
暫存區
ETL層
數據存儲層
數據邏輯層
數據呈現層
元數據層
系統運營層
數據源層
這表示將數據輸入數據倉庫的不同數據源。數據源可以是任何格式 – 純文本文件、關係資料庫、其他類型的資料庫、Excel 文件等都可以作為數據源。
許多不同類型的數據可以是數據源:
作業 – 如銷售數據、人力資源數據、產品數據、庫存數據、營銷數據、系統數據。
帶有用戶瀏覽數據的 Web 服務器日誌。
內部市場研究數據。
第三方數據,如人口普查數據、人口統計數據或調查數據。
數據提取層
- 數據從數據源提取到數據倉庫系統中。可能有一些最小的數據淨化,但不太可能有任何主要的數據轉換。
暫存區
- 這是數據在經過擦洗和轉換為數據倉庫/數據市場之前所在的地方。擁有一個公共區域使後續的數據處理/整合更容易。
ETL層
- 這是數據獲得“智能”的地方,邏輯被應用於將數據從交易性質轉換為分析性質。這一層也是發生數據清洗的地方。ETL 設計階段通常是數據倉庫項目中最耗時的階段,並且通常在這一層使用 ETL 工具。
數據存儲層
- 這是轉換和淨化數據所在的地方。根據範圍和功能,在此可以找到 3 種類型的實體:數據倉庫、數據市場和運營數據店(ODS)。在任何特定系統中,您可以只有三者之一、三者之二或所有三種類型。
數據邏輯層
- 這是存儲業務規則的地方。這裡存儲的業務規則不會影響底層數據轉換規則,但會影響報告的外觀。
數據呈現層
- 這指用戶獲得的資訊。這可以是瀏覽器中表格/圖形報告的形式,每天自动生成和發送的電子郵件報告,或警告用戶異常的警報,等等。通常在此層使用 OLAP 工具和/或報告工具。
元數據層
- 這是存儲有關數據倉庫系統中存儲數據的資訊的地方。邏輯數據模型就是元數據層的一個例子。通常使用元數據工具來管理元數據。
系統運營層
- 這一層包括有關數據倉庫系統運行方式的資訊,例如 ETL 作業狀態、系統性能和用戶訪問記錄。
資料庫與數據倉庫
資料庫:
用於在線交易處理(OLTP)。這會記錄用戶的歷史數據。
表和聯接很复雜,因為它們是正規化的。這樣做是為了減少冗余數據並節省存儲空間。
用於資料庫設計的實體 - 關係建模技術。
優化為寫操作。
分析查詢的性能低。
數據倉庫:
用於在線分析處理(OLAP)。這會讀取歷史數據以供業務決策。
表和聯接很簡單,因為它們是非正規的。這樣做是為了減少分析查詢的響應時間。
用於數據倉庫設計的数据建模技術。
優化读操作。
分析查詢的性能高。
一般數據流 -(例如:在線保險註冊)