數據庫設計
泛化（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. 三元關系可使用函數依賴來定義
留言列表
