一、數據庫設計初步
第一章 數據庫設計目標
確定數據庫應該滿足的特性，例如：
- 具有良好的結構（可讀性、可維護性）
- 數據完整性（避免數據就丟失）
- 計劃查詢
第二章 設計方法
- 需求分析—收集數據性質、特別需求（字段約束）
- 概念設計—繪製ERD（實體關係圖），包括表、字段、表之間的關係，以及規範化
- 邏輯設計—創建數據庫語言命令、生成表定義，有些ERD工具支持自動生成數據定義語言（DDL）
- 物理設計—根據底層物理屬性修改數據庫模型
- 調整階段—建立索引、規範化、反規範化、安全特性
第三章 數據庫建模構件塊
信息、數據、數據完整性。
- 數據完整性，即數據有效性、影響因素有：
- 認爲數據項操作錯誤
- 網絡傳輸錯誤
- 軟件病毒、硬件故障
- 自然災害
- 保護數據完整性
- 數據庫備份（規律性）
- 計算機安全
- 通過適當界面約束數據操作
表的概念
- 紀錄=元組=行
- 字段=列=屬性
數據類型
簡單數據類型：
- 字符串
- 定長：用於較短字符串，字符不足時自動前面補充空格
- 變長：可設置最大字符數。VARCHAR(500)
- 整型
- 定長小數：可指定小數位數
- 浮點型：檢索效率低
- 日期和時間
除簡單數據類型外，還有複雜數據類型和專門數據類型
約束和有效性
- NOT NULL
- 有效性檢查：通過腳本、函數約束具體允許的值，例如只允許插入‘M’、‘W’。
- 鍵約束：包括主鍵、外鍵、唯一鍵。鍵約束允許檢查驗證不同表中字段之間的值。主鍵和外鍵本質是實現父子表。
規範化（最小化冗餘）
- 優點
- 減少物理存儲需求
- 數據組織更好
- 更新數據時只需要操作少量數據（數據獨立性）
- 過度使用缺點
- 過多最小化冗餘按時更多數據表，查詢時需要較大SQL連接語句
- 可能是數據庫結構更復雜
數據表關係
- 鳥足結構
- 一對一、一對多、多對多
- 零、一或多
- 標識和非標識關係（字表主鍵是否包括父表主鍵）
鍵
- 主鍵：唯一標識（用於唯一鎖定一條記錄）
- 唯一鍵：唯一標識（避免出現相同紀錄值，如同一個樂隊不能有兩首同名歌曲，需要將其設置爲唯一鍵）
- 外鍵：反向引用父表中的主鍵，設置外鍵屬性會自動檢查父表主鍵（完整性約束
參照完整性
定義： 確保相關表中的主鍵值和外鍵值之間關係的完整性
索引
關係數據庫模型設計
第四章 規範化
規範化定義
- 異常：主表與明細表之間的矛盾。考慮插入異常、刪除異常、更新異常
- 依賴（傳遞依賴、完全函數依賴、多值依賴、循環依賴）、決定因子、候選鍵（除主鍵外可以唯一確定紀錄的組合字段，可代替主鍵）
定義範式（共六個，一般需要滿足第三範式）
- 第一範式：在關係模型中，對域添加的一個規範要求，所有的域都應該是原子性的，即數據庫表的每一列都是不可分割的原子數據項，而不能是集合，數組，記錄等非原子數據項。即實體中的某個屬性有多個值時，必須拆分爲不同的屬性。在符合第一範式（1NF）表中的每個域值只能是實體的一個屬性或一個屬性的一部分。簡而言之，第一範式就是無重複的域。
- 消除重複組
- 定義主鍵
- 使用主鍵唯一標識所有記錄，主鍵不可重複
- 其他字段必須直接或間接依賴主鍵
- 所有字段至少包含一個值
- 每個字段爲相同數據類型
- 創建新表，從原始表中移動重複組
- 第二範式：要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關係。
- 第三範式：在2NF基礎上，任何非主屬性不依賴於其它非主屬性（在2NF基礎上消除傳遞依賴）
第三範式（3NF）是第二範式（2NF）的一個子集，即滿足第三範式（3NF）必須滿足第二範式（2NF）。簡而言之，第三範式（3NF）要求一個關係中不包含已在其它關係已包含的非主關鍵字信息。例如，存在一個部門信息表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等信息。那麼在員工信息表中列出部門編號後就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。如果不存在部門信息表，則根據第三範式（3NF）也應該構建它，否則就會有大量的數據冗餘。簡而言之，第三範式就是屬性不依賴於其它非主屬性，也就是在滿足2NF的基礎上，任何非主屬性不得傳遞依賴於主屬性。