概念數(shù)據(jù)建模步驟

讓我們進一步仔細觀察應在需求分析和概念設計階段定義的基本數(shù)據(jù)元素和關系。一般需求分析與概念設計是同步完成的。

使用ER模型進行概念設計的步驟包括：

辨識實體與屬性

識別泛化層次結(jié)構(gòu)

定義關系

下面我們對這三個步驟一一進行討論。

辨識實體與屬性

實體和屬性的概念及ER構(gòu)圖都很簡單，但要在需求中區(qū)分實體和屬性不是一件易事。例如：需求描述中有句話，“項目地址位于某個城市”。這句話中的城市是一個實體還是一個屬性呢?又如：每一名員工有一份簡歷。這里的簡歷是一個實體還是一個屬性呢?

辨別實體與屬性可參考如下準則：

實體應包含描述性信息

多值屬性應作為實體來處理

屬性應附著在其直接描述的實體上

這些準則能引導開發(fā)人員得到符合范式的關系數(shù)據(jù)庫設計。

如何理解上述的三條準則呢?

實體內(nèi)容：實體應包含描述信息。如果一個數(shù)據(jù)元素有描述型信息，該數(shù)據(jù)元素應被識別為實體。如果一個數(shù)據(jù)元素只有一 個標識名，則其應被識別為屬性。以前面的“城市”為例，如果對于“城市”有一些如所屬國家、人口等描述信息，則“城市”應被識別為一個實體。如果需求中的 “城市”只表示一個城市名，則把“城市”作為屬性附屬與其他實體，如附屬Project實體。這一準則的例外是當值的標識是可枚舉的有限集時，應作為實體 來處理。例如把系統(tǒng)中有效的國家集合定義為實體。在現(xiàn)實世界中作為實體看待的數(shù)據(jù)元素 有：Employee，Task，Project，Department，Customer等。

多值屬性：把多值屬性作為實體。如果一個實例的某個描述符包含多個對應值，則即使該描述符沒有自己的描述信息也應作為實體進行建模。例如：一個人會有許多愛好，如：看電影、打游戲、大籃球等。愛好對于一個人來說就是多值屬性，則愛好應作為實體來看待。

屬性依附：把屬性附加在其最直接描述的實體上。例如：“office-building-name”作為“Department”屬性比作為“Employee”的屬性合適。識別實體與屬性，并把屬性附加到實體中是一個循環(huán)迭代的過程。

識別泛化層次

如果實體之間有泛化層次關系，則把標識符和公共的描述符(屬性)放在超類實體中，把相同的標識符和特有的描述符放在子類實體中。舉例來說，在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等。

定義關系

在識別實體和屬性之后我們可以處理代表實體之間聯(lián)系的數(shù)據(jù)元素即關系。關系在需求描述中一般是一些動詞如：works-in、works-for、purchases、drives，這些動詞聯(lián)系了不同的實體。

對于任何關系，需要明確以下幾個方面。

關系的度(二元、三元等);

關系的連通數(shù)(一對一、一對多等);

關系是強制的還是可選的;

關系本身有些什么屬性。

冗余關系

仔細分析冗余的關系。描述同一概念的兩個或多個關系被認為是冗余的。當把ER模型轉(zhuǎn)化為關系數(shù)據(jù)庫中的表時，冗余的關系可能造成非范式化的表。需要注意的是兩個實體間允許兩個或更多關系的存在，只要這些關系具有不同的含義。在這種情況下這些關系不是冗余的。

舉例來說，如下圖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三元關系圖)

注：三元關系的語義分析可參看一步一步設計你的數(shù)據(jù)庫之縱覽高級ER模型，這里不再贅述。

 

我們假設要為一家工程項目公司設計一個數(shù)據(jù)庫來跟蹤所有的全職員工，包括員工被分配的項目，所擁有的技能，所在的部門和事業(yè)部，所屬于的專業(yè)協(xié)會，被分配的電腦。

單個視圖的ER建模

通過需求收集與分析過程，我們獲得了數(shù)據(jù)庫的3個視圖。

第一個視圖是人力資源管理視圖。每一個員工屬于一個部門。事業(yè)部是公司的基本單元，每個事業(yè)部包含多個部門。每一個部門和事業(yè)部都有一個經(jīng)理，我們需要跟蹤每一個經(jīng)理。這一視圖的ER模型如圖6所示。

(圖6 人力資源關系視圖)

第二個視圖定義了每個員工的頭銜，如工程師、技術員、秘書、經(jīng)理等。工程師一般屬于某個專業(yè)協(xié)會，并可能被分配一臺工作站。秘書和經(jīng)理會被分配臺式 電腦。公司會儲備一些臺式電腦和工作站，以分配給新員工或當員工的電腦送修時進行出借。員工之間可能有夫妻關系，這也需要在系統(tǒng)中進行跟蹤，以防止夫妻員 工之間有直接領導關系。這一視圖的ER模型如圖7所示。

（圖7  員工頭銜及電腦分配視圖）

第三個視圖如圖8所示，包含員工（工程師、技術員）分配項目的信息。員工可以同時參與多個項目，每一個項目可以在不同的地方（城市）設有總部。但一個員工在指定的地點只能做當?shù)氐囊粋€項目。員工在不同的項目中可以選用不同的技能。

(圖8 項目分配及技能使用視圖)

全局ER圖

對三個視圖的簡單集成可得到全局ER圖，如圖9所示，它是構(gòu)造范式化表的基礎。全局ER圖中的每一個關系都是基于企業(yè)中實際數(shù)據(jù)的一個可驗證斷言。對這些斷言進行分析導出了從ER圖到關系數(shù)據(jù)庫表的轉(zhuǎn)化。

(圖9 全局ER圖)

從全局ER圖中可以看到二元、三元和二元回歸關系;可選和強制存在性關系;泛化的分解約束。圖9中三元關系“skill-used”和“assigned-to”是必須的，因為使用二元關系無法描述相同的語義。

可選存在性的使用，Employee與Division或與Department之間是基于常識：大多數(shù)Employee不會是Division或 Department的經(jīng)理。另一個可選存在性的例子是desktop或workstation的分配，每一臺desktop或workstation未 必都會分配給一個人。總而言之，在把ER模型轉(zhuǎn)化為SQL表之前，所有的關系、可選約束、泛化層次都需要與系統(tǒng)的最終用戶進行確認。

總結(jié)來說，在關系數(shù)據(jù)庫設計中應用ER模型會帶來如下好處

1. 使用ER模型可幫助項目成員專注在討論實體之間的重要關系上，而不受其他細節(jié)的干擾。

2. ER模型把大量復雜的語言描述轉(zhuǎn)化為精簡的、易理解的圖形化描述。

3. 對原始ER模型的擴展，如可選和強制存在性關系，泛化關系等加強了ER模型對現(xiàn)實語義的描述能力。

4. 從ER模型轉(zhuǎn)化為SQL表有完整的規(guī)則，且易于使用。

實體關系(ER)模型參考資料

1. 基本實體關系模型構(gòu)件——實體、關系、屬性、關系的度、關系的連通數(shù)、關系的屬性、關系中實體的存在性(http://www.cnblogs.com/DBFocus/archive/2011/04/24/2026142.html)

2. 高級實體關系模型構(gòu)件——泛化、聚合、三元關系(http://www.cnblogs.com/DBFocus/archive/2011/05/07/2039674.html)

分享到

hanrui

相關推薦