一步一步設計你的數據庫之概念數據建模
邏輯數據庫設計有多種實現方式，包括：自頂至底，自底至頂以及混合方式。傳統數據庫設計是一個自底至頂的過程，從分析需求中的單個數據元素開始，把相關多個數據元素組合在一起轉化為數據庫中的表。這種方式較難應對復雜的大型數據庫設計，這就需要結合自頂至底的設計方式。
使用ER模型進行概念數據建模方便了項目團隊內部及與最終用戶之間的交流與溝通。ER建模的高效性還體現在它是一種自頂至底的設計方法。一個數據庫中的實體數量比數據元素少很多，因為大部分數據元素表示的是屬性。辨別實體并關注實體之間的關系能大大減少需要分析的對象數量。
概念數據建模連接了兩端，一端是需求分析，其能輔助捕獲需求中的實體及之間的關系，便于人們的交流。另一端是關系型數據庫，模型可以很容易的轉化為范式化或接近范式化的SQL表。
概念數據建模步驟
讓我們進一步仔細觀察應在需求分析和概念設計階段定義的基本數據元素和關系。一般需求分析與概念設計是同步完成的。
使用ER模型進行概念設計的步驟包括：
- 辨識實體與屬性
- 識別泛化層次結構
- 定義關系
下面我們對這三個步驟一一進行討論。
辨識實體與屬性
實體和屬性的概念及ER構圖都很簡單，但要在需求中區分實體和屬性不是一件易事。例如：需求描述中有句話，“項目地址位于某個城市”。這句話中的城市是一個實體還是一個屬性呢?又如：每一名員工有一份簡歷。這里的簡歷是一個實體還是一個屬性呢?
辨別實體與屬性可參考如下準則：
- 實體應包含描述性信息
- 多值屬性應作為實體來處理
- 屬性應附著在其直接描述的實體上
這些準則能引導開發人員得到符合范式的關系數據庫設計。
如何理解上述的三條準則呢?
|
識別泛化層次
如果實體之間有泛化層次關系，則把標識符和公共的描述符(屬性)放在超類實體中，把相同的標識符和特有的描述符放在子類實體中。舉例來說，在ER模型中有5個實體，分別是Employee、Manager、Engineer、 Technician、Secretary。其中Employee可以作為Manager、Engineer、Technician、Secretary 的超類實體。我們可以把標識符empno，公共描述符empname、address、date-of-birth放在超類實體中。子類實體 Manager中放empno，特有描述符jobtitle。Engineer實體中放empno，特有描述符jobtitle，highest- degree等。
定義關系
在識別實體和屬性之后我們可以處理代表實體之間聯系的數據元素即關系。關系在需求描述中一般是一些動詞如：works-in、works-for、purchases、drives，這些動詞聯系了不同的實體。
對于任何關系，需要明確以下幾個方面。
- 關系的度(二元、三元等);
- 關系的連通數(一對一、一對多等);
- 關系是強制的還是可選的;
- 關系本身有些什么屬性。
注：關系的這些概念可參看一步一步設計你的數據庫之看看基礎ER模型，這里不再贅述。
#p#
冗余關系
仔細分析冗余的關系。描述同一概念的兩個或多個關系被認為是冗余的。當把ER模型轉化為關系數據庫中的表時，冗余的關系可能造成非范式化的表。需要注意的是兩個實體間允許兩個或更多關系的存在，只要這些關系具有不同的含義。在這種情況下這些關系不是冗余的。
|
舉例來說，如下圖1中Employee生活的City與該Employee所屬的Professional-association的所在City可以不同(兩種含義)，故關系lives-in非冗余。
(圖1 非冗余關系) 如下圖2中的Employee工作的City與該Employee參與的Project的所在City在任何情況下都一致(同種含義)，故關系works-in冗余。
(圖2 傳遞性冗余關系) |
三元關系
非常小心的定義三元關系，只有當使用多個二元關系也無法充分描述多個實體間的語義時，我們才會定義三元關系。以Technician、Project、Notebook為例。
|
例1：如果 一個Technician只做一個Project，一個Project只有一個Technician，每個Project會被獨立記錄在一本Notebook中。
(圖3 例1二元關系圖) 例2：如果一個Technician能同時做多個Project，一個Project可以有多個Technician同時參與，每個Project有一本Notebook(多個做同一個Project的Technician共用一本Notebook)。
(圖4 例2二元關系圖) 例3：如果一個Technician能同時做多個Project，一個Project可以有多個Technician同時參與，一個Technician在一個Project中使用獨立的一本Notebook。
(圖5 例3三元關系圖) |
注：三元關系的語義分析可參看一步一步設計你的數據庫之縱覽高級ER模型，這里不再贅述。
#p#
我們假設要為一家工程項目公司設計一個數據庫來跟蹤所有的全職員工，包括員工被分配的項目，所擁有的技能，所在的部門和事業部，所屬于的專業協會，被分配的電腦。
單個視圖的ER建模
通過需求收集與分析過程，我們獲得了數據庫的3個視圖。
第一個視圖是人力資源管理視圖。每一個員工屬于一個部門。事業部是公司的基本單元，每個事業部包含多個部門。每一個部門和事業部都有一個經理，我們需要跟蹤每一個經理。這一視圖的ER模型如圖6所示。
(圖6 人力資源關系視圖)
第二個視圖定義了每個員工的頭銜，如工程師、技術員、秘書、經理等。工程師一般屬于某個專業協會，并可能被分配一臺工作站。秘書和經理會被分配臺式電腦。公司會儲備一些臺式電腦和工作站，以分配給新員工或當員工的電腦送修時進行出借。員工之間可能有夫妻關系，這也需要在系統中進行跟蹤，以防止夫妻員工之間有直接領導關系。這一視圖的ER模型如圖7所示。
（圖7 員工頭銜及電腦分配視圖）
第三個視圖如圖8所示，包含員工（工程師、技術員）分配項目的信息。員工可以同時參與多個項目，每一個項目可以在不同的地方（城市）設有總部。但一個員工在指定的地點只能做當地的一個項目。員工在不同的項目中可以選用不同的技能。
(圖8 項目分配及技能使用視圖)
#p#
全局ER圖
對三個視圖的簡單集成可得到全局ER圖，如圖9所示，它是構造范式化表的基礎。全局ER圖中的每一個關系都是基于企業中實際數據的一個可驗證斷言。對這些斷言進行分析導出了從ER圖到關系數據庫表的轉化。
(圖9 全局ER圖)
從全局ER圖中可以看到二元、三元和二元回歸關系;可選和強制存在性關系;泛化的分解約束。圖9中三元關系“skill-used”和“assigned-to”是必須的，因為使用二元關系無法描述相同的語義。
可選存在性的使用，Employee與Division或與Department之間是基于常識：大多數Employee不會是Division或 Department的經理。另一個可選存在性的例子是desktop或workstation的分配，每一臺desktop或workstation未必都會分配給一個人。總而言之，在把ER模型轉化為SQL表之前，所有的關系、可選約束、泛化層次都需要與系統的最終用戶進行確認。
總結來說，在關系數據庫設計中應用ER模型會帶來如下好處
1. 使用ER模型可幫助項目成員專注在討論實體之間的重要關系上，而不受其他細節的干擾。
2. ER模型把大量復雜的語言描述轉化為精簡的、易理解的圖形化描述。
3. 對原始ER模型的擴展，如可選和強制存在性關系，泛化關系等加強了ER模型對現實語義的描述能力。
4. 從ER模型轉化為SQL表有完整的規則，且易于使用。
實體關系(ER)模型參考資料
1. 基本實體關系模型構件——實體、關系、屬性、關系的度、關系的連通數、關系的屬性、關系中實體的存在性(http://www.cnblogs.com/DBFocus/archive/2011/04/24/2026142.html)
2. 高級實體關系模型構件——泛化、聚合、三元關系(http://www.cnblogs.com/DBFocus/archive/2011/05/07/2039674.html)
原文鏈接：http://www.cnblogs.com/DBFocus/archive/2011/06/26/2090567.html
【編輯推薦】
