正在學習 MongoDB 數據庫，來簡單的補充一下沒有學好的數據庫基本概念。
基本概念
- 實體（Entity）：描述業務的主要數據結集合；
- 屬性（Attribute）：描述實體內的單體信息；
- 關係（Relationship）：描述實體與實體之間的數據規則，1-N，N-1，N-N；
以上這些都是基本概念，下面描述模型會用到。
傳統模型設計：概念-邏輯-物理
- 概念模型 CDM：
- 描述業務系統需要管理的對象；
- 用概念名詞來描述現實中的實體及業務規則，如：聯繫人；
- 主要作用在用戶需求分析階段；
- 邏輯模型 LDM：
- 基於概念模型，詳細列出所有實體、實體的屬性及關係；
- 基於業務的描述，和數據庫無關；
- 主要作用在進一步的需求分析和開發者設計階段；
- 物理模型 PDM：
- 根據邏輯模型，結合數據庫的物理結構，設計具體的表結構，字段列表及主外鍵；
- 技術實現細節和具體的數據庫類型相關；
- 主要作用在應用開發階段；
我們開發過程中，簡單一些的系統都會直接跳過 CDM、LDM直接進行 PDM 的設計。PDM 部分的設計是要根據數據庫的結構，比如 MySQL 關係型數據庫，就要根據表、字段、外鍵這些屬性進行設計。對應在 MongoDB 的文檔模型中就要根據 JSON 結構進行設計。
舉例子
概念模型
甲方：“我們來設計一個系統，這個系統記錄了聯繫人，我可以把聯繫人分組。”
···
此時，我們建立概念模型，包含：
- Contact：聯繫人
- Group：分組
邏輯模型
有了聯繫人、分組之後，我們推斷聯繫人有聯繫人的屬性、分組也有分組id（作為屬性的存在），於是我們進一步按照甲方的需求進行設計：
- Contact
- name
- gender
- Phones[]
- Address[]
- ··· ···
- getName()
- getGender()
- getPhones()
- getAddress()
- Group
- name
- description
- created
- ··· ···
此時Contact與Group的關係為 N-N
第三範式下的物理模型
第三範式原則：數據庫內儘量不要存在冗余
總結
數據模型三要素：實體、屬性、關係
數據模型三深度：概念模型、邏輯模型、物理模型；
一個模型逐步細化 ··· ···