資料模型設計心得

首先簡單的說一下我對資料、模型、資料模型、資料模型要素以及資料模型的分類的理解。

資料：是符號。例如張三。

模型：現實世界事與物特徵的抽象與模擬。如飛機模型、空氣動力模型。

資料模型：通過對現實世界的事與物主要特徵的分析、抽象，為資訊系統的實施提供資料訪問的資料結構以及相應的約束。資料模型的要素有操作、資料結構以及約束。通常情況下我們在資料模型設計的時候考慮最多的是資料結構而忽視了其他兩個要素。

根據資料模型的應用層次可以分為概念資料模型模型（概念模型）、邏輯資料模型（資料模型）、以及物理資料模型（物理模型）。

概念模型：從業務的角度來考慮問題，主要用來描述事與物的概念化結構，其用途是統一業務概念，作為業務人員和技術人員之間溝通的橋梁。其描述方法有er

圖、merise圖、barker圖等。在建立概念模型的過程中主要考慮的是現實世界中的事與物以及他們之間的關係而不用關注事與物的具體屬性。

邏輯資料模型：從資料庫的角度來考慮問題，在概念模型的基礎上對事與物屬性的細化以及物件整合。其描述方法有er圖。在這個層面資料模型可以分為層次、網狀、關係模型。

物理模型：面向具體的物理計算環境。

下面我們來說一下什麼樣的資料模型才是好的資料模型。資料模型的設計是自由的任意的，對於同乙個系統或者同乙個表每個設計人員的設計結果都是不一樣的

，那麼有沒有什麼標準來評價資料模型的好與壞呢。我覺得應該從以下幾個方面來考慮。

1：是否滿足現有的業務需求。

2：是否易於應對未來的可能的業務變更。好的擴充套件性、很強的靈活性。

3：是否高效。對開發人員來是否簡單高效，執行是否高效。

最後來說一下在資料模型設計過程中的感悟。

1：關於擴充套件性可以通過橫表轉縱表的方式。檢視可以為開發人員提供乙個介面遮蔽底層具體實現的複雜性同時提高系統的擴充套件性。

2：關於資料來源要有元資料的概念，同樣的資料盡量在乙個源頭去取，這對資料的維護以及資料一致性都很有好處。

3：關於抽象抽象是我們分析問題解決問題非常重要的手段，抽象能力的高低充分體現了資料模型設計人員的水平。

4：關於動靜分離動靜是相對的，沒有絕對的動與靜。在實體屬性的選取、表空間等方面考慮動態資料與靜態資料分離。

用乙個例子來說明這個問題吧。

在電子商務系統中從靈活的角度來看後端管理系統會涉及多個表，但是對於前端展現來說如果從多個表獲取資料的話那麼在高併發的情況下會嚴重的影響效能。於是

乎就有了發布這個環節。發布的目的除了對資訊進行審核外，還把相關的資訊發布到乙個表或者快取中再或者生成靜態頁面，如果使用oralce的話還可以使用

物化檢視。

5：關於資料字典要重視資料字典，這對開發人員理解資料模型的設計以及以後的維護都非常重要。

6：如何進行資料模型設計

首先是要了解業務然後建立概念模型，確定實體以及實體關係。

在概念模型的基礎上生成邏輯模型，確定實體屬性，標準化資料（消除多值字段達到第一正規化；消除部分依賴達到第二正規化；消除傳遞依賴達到第三正規化）。

模型驗證：通過具體的業務來驗證模型是否能滿足要求。

在邏輯模型的基礎上生產物理模型。

7：三少整個模型中表應該盡量的少；在乙個表中字段應該盡量的少同時復合主鍵欄位應盡量的少。

8：如果在大資料量或者高併發的情況下，要充分考慮資料庫的壓力，事先要考慮哪些表可能是熱表。要盡量的降低模組的耦合。如果使用的是oracle rac 的話要考慮一下多例項競爭的問題，不同的模組訪問不同的例項。

9：一定要做壓力測試、要做充分的壓力測試，要不上線後會死的很慘，移動總部的乙個web專案應為沒有做充分的壓力測試，導致上線後不得不掛維護頁面，動用了n多的資源去解決問題。

10：在做模型設計的時候要考慮專案的各個生命週期階段對模型的要求，不能僅僅把眼光限制在功能的實現，例如要考慮模型對以後維護的支援，對於大表的資料如何進行清除、轉歷史，顯然delete、insert是首先可以想到的但是不可行的方法，建議做分割槽轉換。

11：資料模型設計對系統可變性的支撐：業務系統的變化點通常是流程相關部分，這部分會隨著不同的公司、公司的不同發展階段而變化，因此最好將這部分單獨建模，獨立於系統核心模型之外。

12：資料模型是對現實世界的模擬，不是對現實世界的完全照搬，對於乙個實體一定要重點考慮這個實體在系統內的角色，對這個角色建模而不是照搬現實世界。