上一篇：數據庫設計 Step by Step (3)

　　泛化（Generalization）：超類型與子類型

　　原始的ER模型已經能描述基本的數據和關系，但泛化（Generalization）概念的引入能方便多個概念數據模型的集成。

　　泛化關系是指抽取多個實體的共同屬性作為超類實體。泛化層次關系中的低層次實體——子類型，對超類實體中的屬性進行繼承與添加，子類型特殊化了超類型。

　　ER模型中的泛化與面向對象編程中的繼承概念相似，但其標記法（構圖方式）有些差異。

　　下圖表示員工與經理、工程師、技術員、秘書之間的泛化關系。Employee為超類實體，并包含共同屬性，Manager、Engineer、Technician、Secretary都是Employee的子類實體，它們能包含自身特有的屬性。

圖1  Employee與Manager、Engineer、Technician、Secretary之間的泛化關系

　　泛化可以表達子類型的兩種重要約束，重疊性約束（disjointness）與完備性約束（completeness）。

　　重疊性約束表示各個子類型之間是否是排他的。若為排他的則用字母“d”標識，否則用“o”標識（o -> overlap）。圖1中各子類實體概念上是排他的。

　　對員工、客戶實體進行泛化，抽象出超類實體個人，得到如下關系圖。由于部分Employee也可能是Customer，故子類實體Employee與Customer之間概念是重疊的。

圖2  Individual與Employee、Customer之間的泛化關系

　　完備性約束表示所有子類型在當前系統中是否能完全覆蓋超類型。若能完全覆蓋則在超類型與圓圈之間用雙線標識（可以把雙線理解為等號）。在圖2中子類實體Employee與Customer能完全覆蓋超類Individual實體。

　　聚合（Aggregation）

　　聚合是與泛化抽象不同的另一種超類型與子類型間的抽象。

　　泛化表示“is-a”語義，聚合表示“part-of”語義。聚合中子類型與超類型間沒有繼承關系。

　　聚合關系的標記法是在圓圈中標識字母“A”來表示。

　　下圖表示軟件產品由程序與用戶手冊組成。

圖3  Software-product與Program、User’s Guide之間的聚合關系

　　三元關系（Ternary Relationships）

　　當通過二元關系無法準確描述三個實體間的聯系時，我們需要使用三元關系。

　　三元關系中“連通數”的確定方法：

a) 以三元關系中的一個實體作為中心，假設另兩個實體都只有一個實例

b) 若中心實體只有一個實例能與另兩個實體的一個實例進行關聯，則中心實體的連通數為“一”

c) 若中心實體有多于一個實例能與另兩個實體實例進行關聯，則中心實體的連通數為“多”

　　注：什么時候需要使用三元關系的實例請參看：數據庫設計 Step by Step (3)中的“關系的度（Degree of a Relationship）”小節。關系的“連通數”概念請參看：數據庫設計 Step by Step (3)中的“關系的連通數（Connectivity of a Relationship）”小節。

　　我們來看幾個三元關系的實例，注意各個圖中關系的度，并理解其中的語義。

圖4  技術員在項目中使用手冊的關系

　　圖4中蘊含的語義為：

a) 一名技術員對于每一個項目使用一本手冊

b) 每一本手冊對于每一個項目屬于一名技術員

c) 一名技術員可能在做多個項目，對于不同的項目維護不同的手冊

　　用數學中的函數依賴表示圖4的關系：

a) emp-id, project-name -> notebook-no

b) emp-id, notebook-no -> project-name

c) project-name, notebook-no -> emp-id

圖5  員工被分配不同地點的項目之間的關系

　　圖5中蘊含的語義為：

a) 每一個員工在一個地點只能被分配一個項目，但可以在不同地點做不同的項目

b) 在一個特定的地點，一個員工只能做一個項目

c) 在一個特定的地點，一個項目可以由多個員工來做

　　用數學中的函數依賴表示圖5的關系：

a) emp-id, loc-name -> project-name

b) emp-id, project-name -> loc-name

圖6  經理管理項目與工程師的關系

　　圖6中蘊含的語義為：

a) 一名經理手下的一名工程師可能參與多個項目

b) 一名經理管理的一個項目可能會有多名工程師

c) 做某一個項目的一名工程師只會有一名經理

　　用數學中的函數依賴表示圖6的關系：

a) project-name, emp-id -> mgr-id

圖7  員工在項目中使用技能的關系

　　圖7中蘊含的語義為：

a) 一名員工在一個項目中可以使用多種技能

b) 一名員工的一種技能可以在多個項目中使用

c) 一種技能在一個項目中可以被多名員工使用

　　圖7各實體之間沒有函數依賴

　　上述4種形式的三元關系，連通數為“一”的實體數量與該三元關系反映的函數依賴語義的數目一致。

　　三元關系也能有屬性。屬性值由三個實體的鍵的組合唯一確定。

　　n元關系（General n-ary Relationships）

　　三元關系可以擴展到n元關系，描述n個實體之間的關系。

　　一般而言，n元關系中每一個連通數為“一”的實體的鍵都會出現在一個函數依賴表達式的右側。

　　對于n元關系，使用語言來表達其中的約束相對較為困難。建議使用數學形式即函數依賴（FD）來表現。

　　n元關系的函數依賴條目數量與關系圖中“一”端實體的數量相同（0～n條）。

　　n元關系的函數依賴表達式包含n個元素，n-1個元素出現在表達式左側，1個元素出現在右側。

圖8  n元關系圖例

　　排他性約束（Exclusion Constraint）

　　一般（默認）情況下，多種關系之間是兼容的“或”關系，即允許任意或所有實體參與這些關系。

　　在某些情況下，多種關系之間是非兼容性“或”關系，即參與關系的實體只能選擇其中一種關系，不能同時選擇多種關系。

　　下圖表示的語義為：一項工作任務要么被歸為外部項目中，要么被歸為內部項目中，不可能同時屬于外部項目和內部項目。

圖9  排他性約束關系圖例

　　我們對上一篇數據庫設計 Step by Step (3)與本篇的重點內容做一個總的回顧：

　　1. 我們討論了ER模型及構圖的基本概念

　　2. 一個實體可以是一個人，地方，東西或事件

　　3. 屬性是實體的描述信息

　　4. 屬性可以是唯一標識或非唯一的描述

　　5. 關系描述了實體之間“一對一”，“一對多”，“多對多”的聯系

　　6. 關系的度反映了參與關系的實體數量，如二元關系，三元關系，n元關系

　　7. 角色（名）定義了一個實體在一個關系中所具有的功能

　　8. 關系的存在概念表示一個實體在關系中是強制存在還是可選的

　　9. 泛化允許把實體抽象成超類與子類

　　10. 三元關系可使用函數依賴來定義