數據建模流程: 概念模型＞＞邏輯模型＞＞物理模型

?數據建模流程

概念模型

概念模型是一種高層次的數據模型，用于描述系統中的關鍵業務概念及其之間的關系。它主要關注業務需求和數據需求，而不涉及具體的技術實現細節。概念模型通常用于在項目初期幫助業務人員和技術人員達成共識，確保對業務需求的理解一致

特點

業務導向：概念模型主要從業務角度出發，描述業務實體、屬性和它們之間的關系。
高層次抽象：它不涉及具體的技術細節，如數據庫表結構、數據類型等。
易于理解：概念模型通常使用圖形化的表示方法（如實體-關系圖），便于業務人員和技術人員共同理解。
獨立于技術實現：概念模型不依賴于特定的數據庫管理系統或技術平臺。

組成部分

實體（Entity）：表示業務中的關鍵概念或對象，如“客戶”、“訂單”、“產品”等。
屬性（Attribute）：描述實體的特征或屬性，如“客戶”實體可能有“姓名”、“地址”、“電話”等屬性。
關系（Relationship）：表示實體之間的關聯，如“客戶”與“訂單”之間的關系可以是“客戶下訂單”。

作用

需求分析：幫助業務人員和技術人員共同理解和定義業務需求。
溝通工具：作為業務人員和技術人員之間的溝通橋梁，確保雙方對業務需求的理解一致。
設計基礎：為后續的邏輯模型和物理模型設計提供基礎。
文檔化：作為項目文檔的一部分，記錄業務需求和數據需求。

示例

在線商店的概念模型

實體：客戶、訂單、產品、支付。
屬性：
- 客戶：客戶ID、姓名、地址、電話。
- 訂單：訂單ID、訂單日期、總金額。
- 產品：產品ID、名稱、價格、庫存。
- 支付：支付ID、支付日期、支付金額。
關系：
- 客戶與訂單：一個客戶可以有多個訂單。1對多
- 訂單與產品：一個訂單可以包含多個產品。1對多
- 訂單與支付：一個訂單對應一個支付。1對1

示例:電腦租賃業務的概念模型

實體：采購管理, 庫存管理, 設備管理, 客戶關系管理, 合同管理, 統計分析, 系統管理

屬性：

采購管理：采購訂單、供應商信息、采購日期、采購金額等。
庫存管理：庫存數量、庫存位置、庫存狀態、入庫日期、出庫日期等。
設備管理：設備ID、設備名稱、設備狀態、維護記錄、購買日期等。
客戶關系管理：客戶ID、客戶姓名、聯系方式、客戶等級、歷史交易等。
合同管理：合同ID、合同日期、合同金額、合同狀態、相關客戶等。
統計分析：分析類型、分析日期、分析結果、相關數據等。
系統管理：系統日志、用戶權限、系統配置、維護記錄等。

關系：

采購管理與庫存管理：采購的物品需要入庫，庫存管理需要根據采購訂單調整庫存。
庫存管理與設備管理：設備可能作為庫存的一部分進行管理，設備出庫和入庫需要記錄。
庫存管理與合同管理：庫存管理需要根據合同需求調整庫存，合同管理需要確保合同中的物品有足夠庫存。
客戶關系管理與合同管理：合同管理需要與客戶關系管理相結合，以確保合同的執行和客戶滿意度。
統計分析與各個管理模塊：統計分析需要從各個管理模塊收集數據，進行分析以支持決策。
系統管理與各個管理模塊：系統管理負責維護整個系統的運行，確保各個管理模塊的數據安全和系統穩定。

注意

注重全局的理解

需要對整體架構做思考

通常是自上而下的模式，與業務反復溝通澄清需求

劃定系統邊界，避免方向性錯誤

業務主導

用一頁紙整體展示

邏輯模型

邏輯模型是一種詳細的數據模型，用于描述系統中的數據結構、關系和約束，而不涉及具體的物理存儲細節。邏輯模型是概念模型和物理模型之間的橋梁，它更詳細地定義了數據的組織方式，但仍然獨立于特定的數據庫管理系統（DBMS）或技術平臺。

邏輯模型在整個的模型設計過程中所占的工作量是最高的,達到60%~70%,?

1.充分分析業務流程,將業務對象的數據屬性和數據關系分析清晰, 業務對象和邏輯實體并不一定是一一對應的,往往是1對多的關系

2.邏輯模型需要繼承自概念模型, 即基于概念模型來設計邏輯模型, 也要考慮后面物理模型的設計(考慮物理模型的物理數據庫的存儲情況來做屬性微調和管理變更, )

3.對概念模型里面多對多的關系進行拆分

特點

詳細的數據結構：邏輯模型詳細描述了實體、屬性、關系和約束。
獨立于技術實現：雖然邏輯模型比概念模型更詳細，但它仍然不涉及具體的物理存儲細節，如文件組織、索引等。
規范化：邏輯模型通常遵循規范化原則，以減少數據冗余和提高數據完整性。
易于轉換：邏輯模型可以相對容易地轉換為物理模型，適用于不同的數據庫管理系統。

組成部分

實體（Entity）：表示業務中的關鍵概念或對象，如“客戶”、“訂單”、“產品”等。
屬性（Attribute）：描述實體的特征或屬性，如“客戶”實體可能有“客戶ID”、“姓名”、“地址”、“電話”等屬性。
關系（Relationship）：表示實體之間的關聯，如“客戶”與“訂單”之間的關系可以是“客戶下訂單”。
約束（Constraints）：定義數據的規則和限制，如主鍵、外鍵、唯一性約束等

作用

詳細設計：在概念模型的基礎上，進一步詳細設計數據結構。
規范化：通過規范化過程，減少數據冗余和提高數據完整性。
溝通工具：作為業務人員、數據架構師和開發人員之間的溝通工具，確保對數據結構的理解一致。
轉換基礎：為物理模型的設計和實現提供基礎。

示例

在線商店的邏輯模型

實體：客戶、訂單、產品、支付。
屬性：
- 客戶：客戶ID（主鍵）、姓名、地址、電話。
- 訂單：訂單ID（主鍵）、客戶ID（外鍵）、訂單日期、總金額。
- 產品：產品ID（主鍵）、名稱、價格、庫存。
- 支付：支付ID（主鍵）、訂單ID（外鍵）、支付日期、支付金額。
關系：
- 客戶與訂單：一個客戶可以有多個訂單（一對多關系）。
- 訂單與產品：一個訂單可以包含多個產品，一個產品可以屬于多個訂單（多對多關系，通常通過關聯表實現）。
- 訂單與支付：一個訂單對應一個支付（一對一關系）。

示例: 電腦租賃業務的邏輯模型

1.?實體及其屬性

訂單詳細信息

訂單編號：唯一標識一個訂單。
產品編號：唯一標識一個產品。
產品名稱
產品類型
產品數量
租賃周期

訂單基本信息

訂單編號：唯一標識一個訂單。
客戶編號：唯一標識一個客戶。
聯系人姓名
訂單日期
訂單狀態
訂單金額
優惠金額

合同基本信息

合同編號：唯一標識一個合同。
簽訂人名稱
簽訂日期
合同開始日期
合同結束日期
合同狀態
合同金額
合同質量
合同押金

合同歷史信息

合同編號：唯一標識一個合同。
變更項目
合同變更時間
變更后合同狀態
變更后合同開始日期
變更后合同結束日期

合同結算信息

合同編號：唯一標識一個合同。
結算狀態：合同的結算狀態。
結算金額：合同的結算金額。
結算時間：合同結算的時間。

合同訂單信息

合同編號：唯一標識一個合同。
訂單編號：唯一標識一個訂單。
訂單順序號：可能與訂單在合同中的順序有關

2.?實體之間的關系

訂單與合同：通過“合同訂單信息”實體關聯，表示一個合同可以包含多個訂單。
合同歷史：通過“合同歷史信息”實體記錄合同的變更歷史。
合同結算：通過“合同結算信息”實體記錄合同的結算情況。

3.?邏輯模型的作用

數據組織：該模型詳細描述了訂單和合同相關的數據結構，包括各個實體的屬性及其關系。
數據完整性：通過定義主鍵和外鍵（如訂單編號、合同編號），確保數據的完整性和一致性。
業務規則：通過定義各種狀態（如訂單狀態、合同狀態）和金額字段，支持業務規則的實施。
歷史記錄：通過“合同歷史信息”實體，記錄合同的變更歷史，支持審計和跟蹤。

注意

使用標準業務術語
遵守模型設計規范
先范式建模、再逆規范化
定義需完整且準確
應用成熟的建模模式
一定程度抽象，保證模型彈性
重要數據關系需強制建立
使用建模工具
與概念模型保持一致，拆分概念模型中的多對多關系

建模工具

專業術語?

與邏輯模型相關的常見專業術語

實體（Entity）

表示業務中的關鍵概念或對象，如“客戶”、“訂單”、“產品”等。

屬性（Attribute）

描述實體的特征或屬性，如“客戶”實體可能有“客戶ID”、“姓名”、“地址”、“電話”等屬性。

關系（Relationship）

描述實體之間的關聯和依賴。，如“客戶”與“訂單”之間的關系可以是“客戶下訂單”。

主鍵（Primary Key）

實體的唯一標識確保每個實體實例的唯一性, 如“客戶ID”可以作為“客戶”實體的主鍵。

外鍵（Foreign Key）

在一個實體中引用另一個實體的主鍵，建立實體之間的關系。如“訂單”實體中的“客戶ID”可以作為外鍵，引用“客戶”實體的主鍵。

規范化（Normalization）

通過分解實體和屬性，減少數據冗余, 提高數據完整性和一致性。

約束（Constraints）

定義數據的規則和限制，確保數據的完整性和一致性。如主鍵約束、外鍵約束、唯一性約束等。

實體-關系圖（Entity-Relationship Diagram, ERD）

用圖形化表示實體、屬性和關系的圖表,? 幫助理解和溝通數據模型。

數據字典（Data Dictionary）

描述數據模型中所有實體、屬性、關系和約束的文檔。

范式（Normal Forms）

規范化過程中的不同級別，如第一范式（1NF）、第二范式（2NF）、第三范式（3NF）等。

多對多關系（Many-to-Many Relationship）

兩個實體之間的關聯，其中一個實體的實例可以與另一個實體的多個實例相關聯，反之亦然。通常通過關聯表實現。

一對一關系（One-to-One Relationship）

兩個實體之間的關聯，其中一個實體的一個實例只能與另一個實體的一個實例相關聯。

一對多關系（One-to-Many Relationship）

兩個實體之間的關聯，其中一個實體的一個實例可以與另一個實體的多個實例相關聯(常見)

關聯實體（Associative Entity）

用于解決多對多的實體關系，通常包含兩個外鍵，分別引用相關實體的主鍵。

派生屬性（Derived Attribute）

通過計算或其他屬性派生出來的屬性，如“年齡”可以通過“出生日期”計算得出。減少數據冗余，提高數據一致性。

域（Domain）

屬性的取值范圍或數據類型，如“年齡”屬性的域可以是0到120的整數。

候選鍵（Candidate Key）

能夠唯一標識實體實例的屬性或屬性組合，如“客戶ID”和“身份證號”都可以作為“客戶”實體的候選鍵。

復合鍵（Composite Key）

由多個屬性組成的主鍵，在需要多個屬性唯一標識實體時使用。如“訂單ID”和“產品ID”可以組合成“訂單明細”實體的復合鍵。

弱實體（Weak Entity）

依賴于另一個實體存在的實體，如“訂單明細”依賴于“訂單”存在。

遞歸關系（Recursive Relationship）

實體與自身之間的關系，描述實體內部的層次結構。

示例

遵守規范

設計邏輯模型時應遵守的規范

業務驅動

理解需求：確保模型滿足業務需求，與業務目標一致。
業務術語：使用業務熟悉的術語命名實體和屬性。

規范化

范式應用：遵循規范化原則（如1NF、2NF、3NF）以減少冗余和依賴。
平衡：在規范化和性能之間找到平衡，避免過度規范化。

1NF（第一范式）確保每列的原子性，即每個字段不可再分。要求每行數據唯一，通常通過主鍵實現2NF（第二范式）在1NF的基礎上，非主鍵字段完全依賴于主鍵3NF（第三范式）在2NF的基礎上，消除傳遞依賴，確保非主鍵字段之間沒有依賴關系

一致性

命名規范：統一命名實體、屬性和關系，保持一致性。
數據類型：統一相同屬性的數據類型和格式。

可擴展性

靈活設計：確保模型能適應未來業務變化。
模塊化：采用模塊化設計，便于擴展和維護。

模塊化設計是一種將復雜系統分解為獨立、可管理和可重用模塊的方法。?

1. 理解業務需求
分解業務功能：將業務需求分解為獨立的功能模塊，每個模塊對應一個特定的業務領域或功能。識別核心數據實體：確定業務中的核心數據實體（如客戶、訂單、產品等）并圍繞這些實體設計模塊2. 劃分模塊
按業務領域劃分：根據業務領域（如銷售、財務、庫存等）劃分模塊，每個模塊負責一個
業務領域的
數據處理。按功能劃分：根據功能（如數據采集、數據清洗、數據存儲、數據分析等）劃分模塊，每個模塊
專注于一個功能。3. 定義模塊邊界
明確模塊職責：為每個模塊定義清晰的職責和范圍，確保模塊之間職責不重疊。模塊接口設計：定義模塊之間的交互接口（如輸入、輸出、調用方式），確保模塊間的通信標準化。4. 數據模型分層
分層設計：將數據模型分為不同的層次（如數據源層、數據存儲層、數據處理層、數據服務層等），
每個層次負責特定的功能。層次解耦：確保各層次之間的依賴最小化，便于單獨修改和擴展某一層次。5. 模塊獨立性
低耦合：盡量減少模塊間的依賴，確保一個模塊的修改不會影響其他模塊。高內聚：確保每個模塊內部的功能高度相關，提高模塊的獨立性和可維護性。6. 使用標準化組件
通用組件：識別和設計可重用的通用組件（如數據驗證、數據轉換、日志記錄等），減少重復開發。組件庫：建立和維護一個組件庫，便于在多個項目中復用。7. 數據流設計
明確數據流向：設計清晰的數據流，確保數據在不同模塊間的流動是高效和可控的。數據接口標準化：使用標準化的數據格式（如JSON、Avro、Parquet等）和協議（如REST、gRPC等）
進行模塊間的數據交換。8. 測試與驗證
單元測試：為每個模塊編寫單元測試，確保模塊的功能正確性。集成測試：進行模塊間的集成測試，確保模塊間的交互正常。9. 文檔化
模塊文檔：為每個模塊編寫詳細的設計文檔，包括功能描述、接口規范和使用示例。數據字典：維護數據字典，記錄每個模塊中的數據字段定義和業務含義。10. 版本控制與變更管理
版本控制：對每個模塊進行版本控制，便于追蹤變更和管理不同版本。變更管理：建立變更管理流程，確保模塊的修改經過充分測試和驗證。11. 持續改進
反饋機制：建立反饋機制，收集模塊使用中的問題和改進建議。迭代優化：根據反饋和業務變化，持續優化和調整模塊設計。示例：模塊化設計在數據倉庫中的應用數據源模塊：負責從不同數據源（如數據庫、API、文件）提取數據。數據清洗模塊：負責數據清洗、去重、格式轉換等。數據存儲模塊：負責將清洗后的數據存儲到數據倉庫或數據湖中。數據分析模塊：負責從存儲層讀取數據并進行業務分析。數據服務模塊：提供API或數據接口，供其他系統或應用使用。

?數據完整性

主鍵和外鍵：使用主鍵確保唯一性，外鍵維護關系完整性。
約束：通過約束（如唯一性、非空）保證數據質量。

性能優化

索引：合理使用索引提升查詢性能。
分區：對大表進行分區，優化查詢和管理。

文檔化

模型文檔：詳細記錄模型設計、實體、屬性和關系。
數據字典：維護數據字典，說明每個字段的含義和來源。

安全性

數據權限：設計時考慮數據訪問權限，確保敏感數據安全。
加密：對敏感數據進行加密存儲和傳輸。

版本控制

版本管理：對模型設計進行版本控制，便于追溯和回滾。
變更記錄：記錄每次變更的原因和內容。

數據治理

數據質量：確保數據準確性、一致性和完整性。
元數據管理：有效管理元數據，支持數據發現和使用。

測試與驗證

模型驗證：通過測試確保模型符合業務需求。
數據驗證：驗證模型中的數據是否準確和完整。

先范式建模、再逆規范化

1. 先范式建模

目標：通過規范化設計，確保數據結構的合理性、減少冗余、提高數據一致性。
步驟：
1. 1NF（第一范式）：確保每列的原子性，消除重復組。
2. 2NF（第二范式）：消除部分依賴，確保非主鍵字段完全依賴于主鍵。
3. 3NF（第三范式）：消除傳遞依賴，確保非主鍵字段之間沒有依賴關系。
4. 更高范式（可選）：如BCNF（巴斯-科德范式）、4NF（第四范式）等，進一步優化數據結構。

2. 再逆規范化

目標：在范式模型的基礎上，通過引入冗余或合并表來優化查詢性能。
常見逆規范化技術：
1. 合并表：將多個規范化的表合并為一個表，減少查詢時的表連接操作。
2. 增加冗余字段：在表中添加冗余字段，避免頻繁的表連接。
3. 預計算字段：存儲預計算的結果（如總和、平均值），避免實時計算。
4. 分區表：將大表按某種規則分區，提高查詢效率。
5. 物化視圖：創建物化視圖，存儲復雜查詢的結果，提升查詢性能。

為什么先范式建模、再逆規范化？

規范化是基礎：
- 范式建模確保數據結構的合理性和一致性，是邏輯建模的基礎。
- 只有在規范化的基礎上，才能準確識別哪些地方需要逆規范化。
逆規范化是優化：
- 逆規范化是在范式模型的基礎上，針對性能瓶頸進行的優化。
- 通過逆規范化，可以在不犧牲數據一致性的前提下，顯著提升查詢性能。

應用示例

電商訂單系統的數據模型
步驟：
1. 范式建模：
  - 訂單表（Orders）：存儲訂單基本信息。
  - 訂單明細表（OrderDetails）：存儲每個訂單的商品明細。
  - 商品表（Products）：存儲商品信息。
  - 用戶表（Users）：存儲用戶信息。
2. 逆規范化：
  - 在Orders表中增加冗余字段（如TotalAmount，預計算訂單總金額）。
  - 創建物化視圖，存儲用戶訂單歷史，避免頻繁查詢多表連接。
  - 將Orders和OrderDetails合并為寬表，減少查詢時的表連接操作。