筆記：資料模組化基本流程，概念模型，邏輯模型和實體模型

注：本文的資料模組化基本流程适用于OLTP系統資料模組化，同樣也涵蓋了DW的資料模組化

資料模組化基本流程：概念模型->邏輯模型->實體模型

概念模型：确定系統的核心以及劃清系統範圍和邊界

該階段需完成：

1.該系統的商業目的是什麼，要解決何種業務場景

2.該業務場景中，有哪些人或組織參與，角色分别是什麼

3.該業務場景中，有哪些物件參與，

4.此外需要具備相關行業經驗：如核心業務流程，組織架構，行業術語

5.5w1h：who， what，when，where，why,  how

概念模型tips：

1.注重全局的了解而非細節

2.在概念模型階段，就需要對整體架構做思考

3.概念模型階段通常是自上而下的模式，這裡需要讀大量的文檔做課前工作，并且通過大量的會議進行反複溝通、澄清需求确認需求。

4.在此階段，應粗略地估算出整個項目需要的時間以及項目計劃草案

5.出品的概念模型可以幫助劃定系統邊界，也就是說什麼地方做什麼地方不做，另外也能夠幫助避免一些方向性的錯誤

6.當然業務和資料都精通的專家更好了，但對比資料專家，這個階段更需要業務專家來配合

7.可以說概念模型是一個溝通的基礎，假設你和客戶讨論，讨論的内容是什麼？依據什麼來讨論？這個就是概念模型存在的意義，同時它也是邏輯模型非常重要的輸入，邏輯模型其實就是概念模型逐漸求精的結果。

8.要用與客戶一緻的商業語言，這個目的主要是避免雙方溝通産生歧義

9.通常用實體關系圖表示，但不需要添加實體的屬性

邏輯模型：梳理業務規則以及對概念模型的求精

該階段需完成：

1.分多少個主題？每個主題包含的實體

2.每個實體的屬性都有什麼？

3.各個實體之間的關系是什麼？

4.各個實體間是否有關系限制？

邏輯模型tips：

1.當你結束了邏輯模組化，如果項目是以資料為核心應用的話，你就能夠更精确推算出整個項目需要的時間，同時你也能估算出更精确的費用。

2.如果你的實體數量超過100個，建議你使用術語表進行統一的規劃定義

3.建議采用3NF進行規範化模組化

4.一定要先規範化，再逆規範化

5.不可缺少限制的定義，比如主鍵，比如外鍵，比如特殊屬性的範圍定義等。

6.強烈建議使用CASE工具做邏輯模組化

7.從系統工程管理的角度來講，你需要一個和你同等級或者略高等級的同僚（或小組）幫助定期評審你的模型，以確定模型的品質。

8.對于邏輯模型而言，需要對各個實體，重要的屬性做結構化、詳盡、準确的描述

9.需要和概念模型保持一緻，如果發現有些地方不一緻，需要确認是邏輯模型出問題了還是概念模型出問題了，再統一修正。

10.要非常非常注意細節，很多時候基礎模型的一個小小的纰漏都會帶來相關程式大量的修改

11.和概念模型簡單明了的一頁紙不同，邏輯模型應該是像一本書一樣，它需要被用來生成未來的資料字典

12.和概念模型隻有實體無需屬性不同，所有實體屬性都需要添加進去，不應有遺漏

13.實體之間的關系，是1:N, 0:N, 要清晰的描述

14.如果實體數量足夠多，需要使用術語表

15.要嚴格遵循命名規則 

16.對各個實體均需要有清晰完整的描述 

17.對于關鍵屬性都需要有清晰的描述 

實體模型：從性能，通路，開發等多方面考慮，做系統的實作

該階段需完成：

1.類型與長度的定義

2.字段的其他詳細定義：非空，預設值

3.卻準詳細的定義：枚舉類型字段，各枚舉值具體含義

4.限制的定義：主鍵，外鍵

實體模型tips：

1.注意開發，測試，生産不同版本的模型管理

2.注意性能

3.估算資料規模

4.考慮資料歸檔

5.同分考慮未來使用資料庫的優點與缺點

什麼樣的模型算是高品質資料模型呢？

1.對真實世界的抽象和表達要正确并且完整；

2.需要使用标準化的模組化語言，使資料模型能夠清晰的表達設計的思想，讓人容易了解并不産生歧義

3.資料模型的架構穩定并且靈活，能夠一定程度上容納未來的變化

4.根據需求的實際情況，不要随意的逆規範化，要盡可能的減少資料備援

5.需要充分考慮潛在的性能問題，尤其要根據資料庫産品的特點，避免使用資料庫産品的短處。

6.要不僅僅站在目前項目的視角去構築模型，需要從企業的全局視角出發，比如友善其他系統通路，可以很友善的外部資料接口，命名規則術語定義和企業标準保持一緻，等等。