一步一步設計你的數據庫之高處俯瞰生命周期
引言：一步一步設計你的數據庫1得到這么多朋友的關注著實出乎了我的意外。這也堅定了我把這一系列的博文寫好的決心。近來工作上的事務比較繁重，加之我期望這個系列的文章能盡可能的系統、完整，需要花很多時間整理、思考數據庫設計的各種資料，所以文章的更新速度可能會慢一些，也希望大家能夠諒解。
系列的第二講我們將站在高處俯瞰一下數據庫的生命周期，了解數據庫設計的整體流程
數據庫生命周期
大家對軟件生命周期較為熟悉，數據庫也有其生命周期，如下圖所示。
圖（1）數據庫生命周期
數據庫的生命周期主要分為四個階段：需求分析、邏輯設計、物理設計、實現維護。
這個系列的博文將主要關注數據庫生命周期中的前兩個階段（需求分析、邏輯設計），還會涉及反范式化設計的一些內容。如圖中高亮圈出的部分。
數據庫的物理設計，包括索引的選擇與優化、數據分區等內容。這些內容也非常豐富，而且可以自成體系，園子里也有很多好文章，故在本系列中不作主要關注。本文最后將給出一些鏈接供大家參考。
數據庫生命周期的四個階段又能細分為多個小步驟，我們配合圖（1）來看看每一小步包含的內容。
階段1 需求分析
數據庫設計與軟件設計一樣首先需要進行需求分析。
我們需要與數據的創造者和使用者進行訪談。對訪談獲得的信息進行整理、分析，并撰寫正式的需求文檔。
需求文檔中需包含：需要處理的數據；數據的自然關系；數據庫實現的硬件環境、軟件平臺等；
圖（2）階段1 需求分析
階段2 邏輯設計
使用ER或UML建模技術，創建概念數據模型圖，展示所有數據以及數據間關系。最終概念數據模型必須被轉化為范式化的表。
數據庫邏輯設計主要步驟包括：
a) 概念數據建模
注：在需求分析完成后，使用ER圖或UML圖對數據進行建模。使用ER圖或UML圖描述需求中的語義，即得到了數據概念模型（Conceptual Data Model），例如：三元關系（ternary relationships）、超類（supertypes）、子類（subtypes）等。
例：零售商視角，產品/客戶數據庫的ER模型簡圖
注：ER圖的含義，以及詳細標記方法將在該系列的下一篇博文中進行討論
圖（3）階段2(a) 概念數據建模
b) 多視圖集成
注：當在大型項目設計或多人參與設計的情況下，會產生數據和關系的多個視圖。這些視圖必須進行化簡與集成，消除模型中的冗余與不一致，最終形成一個全局的模型。多視圖集成可以使用ER建模語義中的同義詞(synonyms)、聚合(aggregation)、泛化(generalization)等方法。多視圖集成在整合多個應用的場景中也非常重要。
例：集成零售商ER圖與客戶ER圖
零售商ER圖如圖（3）所示。客戶視角，產品/客戶數據庫的ER模型簡圖如下：
圖（4）以客戶為關注點繪制的ER圖
注：現在市面上有許多輔助建模工具可以繪制ER圖。使用Sybase的PowerDesigner繪制與圖（4）相同語義的ER圖如下：
其標記法與圖（4）中略有不同，這將在今后的博文中加以說明。
這里需要指出的是輔助軟件的使用不是設計的核心，大家不要被這些工具迷惑。所以后文中我們將主要使用手繪。只要掌握了ER圖的語義，使用這些軟件都不會是件難事。
集成零售商ER圖與客戶ER圖
圖（5） 階段2(b) 多視圖集成
c) 轉化概念數據模型為SQL表
注：根據映射規則，把ER圖中的實體與關系轉化為SQL表結構。在這一過程中我們將識別冗余的表，并去除這些表。
例：把圖（5）中的customer, product, salesperson實體轉化為SQL表
圖（6） 階段2(c)轉化概念數據模型為SQL表
d) 范式化
注：范式化是數據庫邏輯設計中的重要一步。范式化的目標是盡可能去除模型中的冗余信息，從而消除關系模型更新、插入、刪除異常（anomalies）。
講到范式化就會引出函數依賴（Functional Dependency）這一概念。函數依賴(FDs)源自于概念數據模型圖，反映了需求分析中的數據關系語義。不同實體之間的函數依賴表示各個實體唯一鍵之間的依賴。實體內部也有函數依賴，反映了實體中鍵屬性與非鍵屬性之間的依賴。在保證數據完整性約束的前提下，基于函數依賴對候選表進行范式化（分解、降低數據冗余）。
例：對圖（6）中的Salesperson表進行范式化，消除更新異常（update anomalies）
圖（7） 階段2(d)范式化
階段3 物理設計
數據庫物理設計包括選擇索引，數據分區與分組等。
邏輯設計方法學通過減少需要分析的數據依賴，簡化了大型關系數據庫的設計，這也減輕了數據庫物理設計階段的壓力。
1. 概念數據建模和多視圖集成準確地反映了現實需求場景
2. 范式化在模型轉化為SQL表的過程中保留了數據完整性
數據庫物理設計的目標是盡可能優化性能。
物理設計階段，全局表結構可能需要進行重構來滿足性能上的需求，這被稱為反范式化。
反范式化的步驟包括：
1. 辨別關鍵性流程，如頻繁運行、大容量、高優先級的處理操作
2. 通過增加冗余來提高關鍵性流程的性能
3. 評估所造成的代價（對查詢、修改、存儲的影響）和可能損失的數據一致性
階段4 數據庫的實現維護
當設計完成之后，使用數據庫管理系統（DBMS）中的數據定義語言（DDL）來創建數據結構。
數據庫創建完成后，應用程序或用戶可以使用數據操作語言（DML）來使用（查詢、修改等）該數據庫。
一旦數據庫開始運行，就需要對其性能進行監視。當數據庫性能無法滿足要求或用戶提出新的功能需求時，就需要對該數據庫進行再設計與修改。這形成了一個循環：監視 –> 再設計 –> 修改 –> 監視…。
#p#
關系數據庫基礎
在進行數據庫設計之前，我們先回顧一下關系數據庫的相關基本概念。
這里只做一個提綱挈領的簡介，大家可以根據相應的線索進行擴展。
表、行、列
關系數據庫可以想象成表的集合，每個表包含行與列。（可以想象成一個Excel workbook，包含多個worksheet）。
表在關系代數中被稱為關系，這也是關系數據庫名稱的起源（不要與表之間的外鍵關系混淆）。
列在關系代數中被稱為屬性（attribute）。列中允許存放的值的集合稱為列的域（域與數據類型密切相關，但并不完全相同）。
行在關系代數中的學名是元組（tuple）。
關系數據庫的理論基礎來自于“關系代數”。但在關系代數中，一個集合的各個元組沒有次序的概念，在關系數據庫中為了方便使用，定義了行的次序。
鍵、索引
鍵是一種約束，目的是保證數據完整性
1. 復合鍵（Compound key）：由多個數據列組成的鍵
2. 超鍵（Superkey）：列的集合，其中任何兩行都不會完全相同
3. 候選鍵（Candidate key）：首先是一個超鍵，同時這個超鍵中的任何列的缺失都會破壞行的唯一性
4. 主鍵（Primary key）：指定的某個候選鍵
索引是數據的物理組織形式，目的是提高查詢的性能
約束
基本約束
not null constraint, domain constraint
檢查約束（Check Constraints）
例：Salary > 0
主鍵約束（Primary Key Constraints）
實體完整性（entity integrity），沒有兩條記錄是完全相同的，組成主鍵的字段不能為null
唯一性約束（Unique Constraints）
外鍵約束（Foreign Key Constraints）也被稱為引用完整性約束
例：
關系數據庫操作
1.選擇（Selection）
2.映射（Projection）
3.聯合（Union）
4.交集（Intersection）
5.差集（Difference）
6.笛卡爾積（Cartesian Product）
7.連接（Join）
上述7種是最基本的關系數據庫操作，對應于集合論中的關系運算。
有些書籍中還會加入改名（Rename），除（Divide）等關系操作。
#p#
主要內容回顧
1. 數據庫生命周期的四個階段：需求分析、邏輯設計、物理設計、實現維護。
2. 關系數據庫的理論基礎是關系代數。
數據庫物理設計參考資料
第一個鏈接是我針對查詢優化作的讀書筆記，后三個鏈接是SQLServerCentral中幾篇關于索引的文章（需要簡單注冊后才能看到全文）
1. 查詢優化系列（查詢優化（1），查詢優化（2），查詢優化（3），查詢優化（4），查詢優化（5）——總結）
2. Part 1 - The basics of indexes
3. Part 2 - The Clustered Index
4. Part 3 - The Non-clustered index
原文鏈接：http://www.cnblogs.com/DBFocus/archive/2011/04/09/2010904.html
【編輯推薦】
