引言：《一步一步設計你的數(shù)據(jù)庫三》中我們討論了基本實體關系模型構件及其語義。這些概念非常重要，是今天這一講的基礎，在開始本文內容之前建議大家可以再回顧一下上一篇的內容。今天我們將討論高級實體關系模型構件，與上一篇一起涵蓋了ER模型構圖的大部分內容。三元關系是今天這一講的難點，大家可以重點關注。

[[28214]] 

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

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

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

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

下圖表示員工與經(jīng)理、工程師、技術員、秘書之間的泛化關系。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之間的泛化關系

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

聚合（Aggregation）

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

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

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

下圖表示軟件產(chǎn)品由程序與用戶手冊組成。

 

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

三元關系（Ternary Relationships）

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

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

1.  以三元關系中的一個實體作為中心，假設另兩個實體都只有一個實例
2. 若中心實體只有一個實例能與另兩個實體的一個實例進行關聯(lián)，則中心實體的連通數(shù)為“一”
3. 若中心實體有多于一個實例能與另兩個實體實例進行關聯(lián)，則中心實體的連通數(shù)為“多”

注：什么時候需要使用三元關系的實例請參看：《一步一步設計你的數(shù)據(jù)庫三》中的“關系的度（Degree of a Relationship）”小節(jié)。關系的“連通數(shù)”概念請參看：《一步一步設計你的數(shù)據(jù)庫三》的“關系的連通數(shù)（Connectivity of a Relationship）”小節(jié)。

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

 

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

圖4中蘊含的語義為：

1. 一名技術員對于每一個項目使用一本手冊
2. 每一本手冊對于每一個項目屬于一名技術員
3. 一名技術員可能在做多個項目，對于不同的項目維護不同的手冊

用數(shù)學中的函數(shù)依賴表示圖4的關系：

1. emp-id, project-name -> notebook-no
2. emp-id, notebook-no -> project-name
3. project-name, notebook-no -> emp-id

 

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

圖5中蘊含的語義為：

1. 每一個員工在一個地點只能被分配一個項目，但可以在不同地點做不同的項目
2. 在一個特定的地點，一個員工只能做一個項目
3. 在一個特定的地點，一個項目可以由多個員工來做

用數(shù)學中的函數(shù)依賴表示圖5的關系：

1. emp-id, loc-name -> project-name
2. emp-id, project-name -> loc-name

 

圖6  經(jīng)理管理項目與工程師的關系

圖6中蘊含的語義為：

1. 一名經(jīng)理手下的一名工程師可能參與多個項目
2. 一名經(jīng)理管理的一個項目可能會有多名工程師
3. 做某一個項目的一名工程師只會有一名經(jīng)理

用數(shù)學中的函數(shù)依賴表示圖6的關系：

1. project-name, emp-id -> mgr-id

 

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

圖7中蘊含的語義為：

1. 一名員工在一個項目中可以使用多種技能
2. 一名員工的一種技能可以在多個項目中使用
3. 一種技能在一個項目中可以被多名員工使用

圖7各實體之間沒有函數(shù)依賴

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

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

n元關系（General n-ary Relationships）

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

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

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

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

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

 

圖8  n元關系圖例

排他性約束（Exclusion Constraint）

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

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

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

 

圖9  排他性約束關系圖例

 

我們對上一篇《一步一步設計你的數(shù)據(jù)庫三》與本篇的重點內容做一個總的回顧

1. 我們討論了ER模型及構圖的基本概念
2. 一個實體可以是一個人，地方，東西或事件
3. 屬性是實體的描述信息
4. 屬性可以是唯一標識或非唯一的描述
5. 關系描述了實體之間“一對一”，“一對多”，“多對多”的聯(lián)系
6. 關系的度反映了參與關系的實體數(shù)量，如二元關系，三元關系，n元關系
7. 角色（名）定義了一個實體在一個關系中所具有的功能
8. 關系的存在概念表示一個實體在關系中是強制存在還是可選的
9. 泛化允許把實體抽象成超類與子類
10. 三元關系可使用函數(shù)依賴來定義

原文鏈接：http://www.cnblogs.com/DBFocus/archive/2011/05/07/2039674.html

 

【編輯推薦】

1. 一步一步設計你的數(shù)據(jù)庫一
2. 一步一步設計你的數(shù)據(jù)庫二
3. 一步一步設計你的數(shù)據(jù)庫三
4. 數(shù)據(jù)庫設計，你了解多少
5. 幾步走，教你創(chuàng)建簡單訪問數(shù)據(jù)庫方法