資料庫設計/實體關係資料模型

實體關係 (ER) 資料模型 已經存在超過 35 年。它非常適合用於資料庫的資料建模，因為它相當抽象，易於討論和解釋。ER 模型很容易轉換為關係。ER 模型，也稱為 ER 模式，由 ER 圖表示。

ER 建模基於兩個概念

實體，定義為儲存特定資訊（資料）的表
關係，定義為實體之間的關聯或互動

以下是一個示例，說明這兩個概念如何在 ER 資料模型中結合使用：Ba 教授（實體）講授（關係）資料庫系統課程（實體）。

在本節的剩餘部分，我們將使用一個名為 COMPANY 資料庫的示例資料庫來說明 ER 模型的概念。該資料庫包含有關員工、部門和專案的資訊。需要注意的重要事項包括

公司有多個部門。每個部門都有唯一的標識、名稱、辦公室位置和特定負責管理該部門的員工。
部門控制著多個專案，每個專案都有唯一的名稱、唯一的編號和預算。
每個員工都有姓名、身份證號碼、地址、工資和出生日期。員工被分配到一個部門，但可以加入多個專案。我們需要記錄員工在每個專案的開始日期。我們還需要知道每個員工的直屬主管。
我們想要跟蹤每個員工的受撫養人。每個受撫養人都有姓名、出生日期和與員工的關係。

實體、實體集和實體型別

實體是現實世界中具有獨立存在的物件，可以與其他物件區分開來。一個實體可能是

具有物理存在的物體（例如，講師、學生、汽車）
具有概念性存在的物體（例如，課程、工作、職位）

實體可以根據其強度進行分類。如果實體的表存在依賴，則該實體被認為是弱實體。

也就是說，它不能在沒有與另一個實體的關係的情況下存在
它的主鍵是從父實體的主鍵派生的
- COMPANY 資料庫中的 Spouse 表是一個弱實體，因為它的主鍵依賴於 Employee 表。如果沒有相應的員工記錄，配偶記錄將不存在。

如果一個實體可以獨立於其所有相關實體而存在，則該實體被認為是強實體。

核心是強實體。
沒有外部索引鍵或包含可以為空的外部索引鍵的表是強實體

另一個需要了解的術語是實體型別，它定義了類似實體的集合。

實體集 是在特定時間點對某個實體型別的實體的集合。在實體關係圖 (ERD) 中，實體型別由框中的名稱表示。例如，在圖 8.1 中，實體型別為 EMPLOYEE。

圖 8.1。具有實體型別 EMPLOYEE 的 ERD。

存在依賴

一個實體的存在依賴於相關實體的存在。如果它具有強制外部索引鍵（即不能為空的外部索引鍵屬性），則它是存在依賴的。例如，在 COMPANY 資料庫中，Spouse 實體存在依賴於 Employee 實體。

實體的種類

您還應該熟悉不同種類的實體，包括獨立實體、依賴實體和特徵實體。這些將在下面介紹。

獨立實體

獨立實體，也稱為核心，是資料庫的支柱。其他表都是基於它們的。核心具有以下特徵

它們是資料庫的基礎。
主鍵可以是簡單的，也可以是複合的。
主鍵不是外部索引鍵。
它們的存在不依賴於另一個實體。

如果我們回到我們的 COMPANY 資料庫，獨立實體的示例包括 Customer 表、Employee 表或 Product 表。

依賴實體

依賴實體，也稱為派生實體，依賴於其他表以獲得其含義。這些實體具有以下特徵

依賴實體用於將兩個核心連線在一起。
據說它們存在依賴於兩個或多個表。
多對多關係成為具有至少兩個外部索引鍵的聯結表。
它們可能包含其他屬性。
外部索引鍵標識每個關聯表。
主鍵有三種選擇
1. 如果唯一，使用關聯表的複合外部索引鍵
2. 使用複合外部索引鍵和限定列
3. 建立一個新的簡單主鍵

特徵實體

特徵實體 提供有關另一個表的更多資訊。這些實體具有以下特徵

它們代表多值屬性。
它們描述其他實體。
它們通常具有從一對多的關係。
外部索引鍵用於進一步識別特徵表。
主鍵選擇如下
1. 使用外部索引鍵加限定列的組合
2. 建立一個新的簡單主鍵。在 COMPANY 資料庫中，這些可能包括
  - Employee (EID, Name, Address, Age, Salary) – EID 是簡單主鍵。
  - EmployeePhone (EID, Phone) – EID 是複合主鍵的一部分。這裡，EID 也是外部索引鍵。

屬性

每個實體由一組屬性描述（例如，員工 = （姓名、地址、出生日期（年齡）、工資）。

每個屬性都有一個名稱，並與一個實體和一個合法值的域相關聯。但是，有關屬性域的資訊不會顯示在 ERD 上。

在實體關係圖中（如圖 8.2 所示），每個屬性由一個包含名稱的橢圓表示。

圖 8.2. 屬性在 ERD 中的表示方式。

屬性型別

您需要熟悉幾種型別的屬性。其中一些保持原樣，但一些需要調整以方便在關係模型中表示。本節將討論屬性型別。稍後我們將討論將屬性修復以正確適應關係模型。

簡單屬性

簡單屬性是從原子值域中提取的屬性；它們也被稱為單值屬性。在 COMPANY 資料庫中，一個例子是：Name = {John}；Age = {23}

複合屬性

複合屬性是由屬性層次結構組成的屬性。使用我們的資料庫示例，如圖 8.3 所示，Address 可能由 Number、Street 和 Suburb 組成。因此這將被寫為 → Address = {59 + ‘Meek Street’ + ‘Kingsford’}

圖 8.3. 複合屬性示例。

多值屬性

多值屬性是每個實體都有值集的屬性。來自 COMPANY 資料庫的多值屬性示例（如圖 8.4 所示）是員工的學位：BSc、MIT、PhD。

圖 8.4. 多值屬性示例。

派生屬性

派生屬性是包含從其他屬性計算得出的值的屬性。如圖 8.5 所示，Age 可以從 Birthdate 屬性派生。在這種情況下，Birthdate 被稱為儲存屬性，它被物理儲存到資料庫中。

圖 8.5. 派生屬性示例。

鍵

對實體的一個重要約束是鍵。鍵是一個屬性或一組屬性，其值可以用來唯一標識實體集中單個實體。

鍵型別

鍵有幾種型別。這些在下面描述。

候選鍵

候選鍵是唯一且最小的簡單鍵或複合鍵。它是唯一的，因為表中的兩行不能在任何時候都具有相同的值。它是最小的，因為需要每列才能獲得唯一性。

從我們的 COMPANY 資料庫示例中，如果實體是 Employee(EID, First Name, Last Name, SIN, Address, Phone, BirthDate, Salary, DepartmentID)，可能的候選鍵是

EID、SIN
First Name 和 Last Name - 假設公司中沒有其他人具有相同的姓名
Last Name 和 DepartmentID - 假設兩個姓氏相同的人不在同一個部門工作

複合鍵

複合鍵由兩個或多個屬性組成，但它必須是最小的。

使用候選鍵部分的示例，可能的複合鍵是

First Name 和 Last Name - 假設公司中沒有其他人具有相同的姓名
Last Name 和 Department ID - 假設兩個姓氏相同的人不在同一個部門工作

主鍵

主鍵是由資料庫設計人員選擇的候選鍵，用作整個實體集的識別機制。它必須唯一標識表中的元組，並且不能為 null。主鍵在 ER 模型中透過下劃線屬性來表示。

候選鍵由設計人員選擇以唯一標識表中的元組。它不能為 null。
鍵由資料庫設計人員選擇用作整個實體集的識別機制。這被稱為主鍵。此鍵在 ER 模型中透過下劃線屬性來表示。

在以下示例中，EID 是主鍵

Employee(EID, First Name, Last Name, SIN, Address, Phone, BirthDate, Salary, DepartmentID)

次要鍵

次要鍵是專門用於檢索目的的屬性（可以是複合屬性），例如：Phone 和 Last Name。

備用鍵

備用鍵是所有未被選為主鍵的候選鍵。

外部索引鍵

外部索引鍵 (FK)是表中引用另一個表中主鍵的屬性，或者可以為 null。外部索引鍵和主鍵必須具有相同的資料型別。

在下面的 COMPANY 資料庫示例中，DepartmentID 是外部索引鍵

Employee(EID, First Name, Last Name, SIN, Address, Phone, BirthDate, Salary, DepartmentID)

空值

空值是一個特殊符號，獨立於資料型別，表示未知或不適用。它不表示零或空白。空值的特徵包括

沒有資料條目
主鍵中不允許
應避免在其他屬性中使用
可以表示
- 未知屬性值
- 已知但缺失的屬性值
- “不適用”條件
在使用 COUNT、AVERAGE 和 SUM 等函式時可能會導致問題
在關聯錶鏈接時可能會導致邏輯問題

注意：當任一引數為 null 時，比較運算的結果為 null。當任一引數為 null 時，算術運算的結果為 null（忽略 null 的函式除外）。

null 使用示例

使用圖 8.6 中的 Salary 表 (Salary_tbl) 作為 null 使用示例。

圖 8.6. null 示例的 Salary 表，作者：A. Watt。

首先，查詢所有在 Sales (jobName 列下) 的員工 (emp#) ，其薪資加上佣金大於 30,000。

SELECT emp# FROM Salary_tbl
WHERE jobName = Sales AND
(commission + salary) > 30,000 –> E10 和 E12

由於佣金列中的 null 值，此結果不包含 E13。為了確保包含帶有 null 值的行，我們需要檢視各個欄位。透過將 E13 的佣金和薪資相加，結果將為 null 值。解決方案如下。

SELECT emp# FROM Salary_tbl
WHERE jobName = Sales AND
(commission > 30000 OR
salary > 30000 OR
(commission + salary) > 30,000 –>E10 和 E12 和 E13

關係

關係是將表格連線在一起的紐帶。它們用於連線表格之間相關的資訊。

關係強度基於相關實體的主鍵的定義方式。如果相關實體的主鍵不包含父實體的主鍵元件，則存在弱關係或非識別關係。公司資料庫示例包括

Customer(CustID, CustName)
Order(OrderID, CustID, Date)

如果相關實體的主鍵包含父實體的主鍵元件，則存在強關係或識別關係。示例包括

Course(CrsCode, DeptCode, Description)
Class(CrsCode, Section, ClassTime…)

關係型別

以下是各種關係型別的描述。

一對多 (1:M) 關係

一對多 (1:M) 關係應該是任何關係資料庫設計的規範，並且存在於所有關係資料庫環境中。例如，一個部門有多個員工。圖 8.7 顯示了其中一名員工與部門的關係。

圖 8.7. 一對多關係示例。

一對一 (1:1) 關係

一對一 (1:1) 關係是一個實體與另一個實體之間僅存在一種關係，反之亦然。它在任何關係資料庫設計中都應該很少見。實際上，它可能表明兩個實體實際上屬於同一個表。

來自 COMPANY 資料庫的示例是，一個員工與一個配偶相關聯，一個配偶與一個員工相關聯。

多對多 (M:N) 關係

對於多對多關係，請考慮以下幾點

它不能在關係模型中這樣實現。
它可以更改為兩個 1:M 關係。
它可以透過分解來實現，以生成一組 1:M 關係。
它涉及組合實體的實現。
建立兩個或多個 1:M 關係。
組合實體表必須至少包含原始表的主鍵。
連結表包含外部索引鍵值的多次出現。
可以根據需要分配其他屬性。
它可以透過建立組合實體或橋接實體來避免 M:N 關係固有的問題。例如，一名員工可以參與多個專案，或者一個專案可以有多名員工參與，具體取決於業務規則。或者，一名學生可以選修多門課程，一門課程可以容納多名學生。

圖 8.8 顯示了 M:N 關係的另一個方面，即員工在不同專案中具有不同的開始日期。因此，我們需要一個包含 EID、Code 和 StartDate 的 JOIN 表。

圖 8.8. 員工在不同專案中具有不同開始日期的示例。

對映 M:N 二元關係型別的示例

對於每個 M:N 二元關係，識別兩個關係。
A 和 B 代表參與 R 的兩個實體型別。
建立一個新關係 S 來表示 R。
S 需要包含 A 和 B 的 PK。這些可以一起成為 S 表中的 PK，或者這些與新表 R 中的另一個簡單屬性一起可以成為 PK。
主鍵 (A 和 B) 的組合將構成 S 的主鍵。

一元關係 (遞迴)

一元關係，也稱為遞迴關係，是同一個實體集的例項之間存在關係的一種關係。在這種關係中，主鍵和外部索引鍵相同，但它們表示兩個具有不同角色的實體。請參見圖 8.9 中的示例。

對於一元關係中的一些實體，可以建立一個單獨的列，該列引用同一實體集的主鍵。

圖 8.9. 一元關係示例。

三元關係

三元關係是涉及三個表之間多對多關係的關係型別。

請參見圖 8.10 中對映三元關係型別的示例。注意n 元表示關係中的多個表。（記住，N = 多個。）

對於每個 n 元 (> 2) 關係，建立一個新關係來表示該關係。
新關係的主鍵是參與實體的主鍵的組合，這些主鍵包含 N (多個) 一側。
在大多數 n 元關係的情況下，所有參與實體都包含多個方面。

圖 8.10. 三元關係示例。

關鍵詞

備用鍵: 所有未被選為主鍵的候選鍵

候選鍵: 一個簡單或複合鍵，它是唯一的（表中沒有兩行可以具有相同的值）並且是最小的（每列都是必要的）

特徵實體: 提供有關另一個表的更多資訊的實體

複合屬性: 由屬性層次結構組成的屬性

複合鍵: 由兩個或多個屬性組成，但它必須是最小的

從屬實體: 這些實體依賴其他表來獲取其含義

派生屬性: 包含從其他屬性計算得出的值的屬性

派生實體: 參見從屬實體

EID: 員工識別碼 (ID)

實體: 現實世界中具有獨立存在並且可以與其他物件區分開來的事物或物件

實體關係 (ER) 資料模型: 也稱為 ER 架構，由 ER 圖表示。它們非常適合用於資料庫的資料建模。

實體關係架構: 參見實體關係資料模型

實體集: 在某個時間點，實體型別的實體集合

實體型別: 類似實體的集合

外部索引鍵 (FK): 表中引用另一個表的主鍵的屬性，或者可以為 null

獨立實體: 作為資料庫的構建塊，這些實體是其他表的基礎

核心: 參見獨立實體

鍵: 屬性或屬性組，其值可用於唯一標識實體集中的單個實體

多值屬性: 每個實體都有一組值的屬性

n 元: 多個表之間的關係

空: 一個特殊的符號，獨立於資料型別，表示未知或不適用；它不表示零或空白

遞迴關係: 參見 *一元關係*

關係: 實體之間的關聯或互動；用於連線表之間相關的資訊

關係強度: 基於相關實體主鍵的定義方式

次要鍵: 嚴格用於檢索目的的屬性

簡單屬性: 從原子值域中提取

SIN: 社會保險號

單值屬性: 參見 *簡單屬性*

儲存屬性: 物理儲存到資料庫中

三元關係: 一種關係型別，涉及三個表之間多對多關係。

一元關係: 同一實體集的發生之間存在關係。

練習

ER建模基於哪兩個概念？
圖 8.11 中的資料庫由兩個表組成。使用此圖回答問題 2.1 到 2.5。圖 8.11. 導演和戲劇表，用於問題 2，作者 A. Watt。
1. 識別每個表的主鍵。
2. 識別 PLAY 表中的外部索引鍵。
3. 識別兩個表中的候選鍵。
4. 繪製 ER 模型。
5. PLAY 表是否具有引用完整性？為什麼或為什麼不？
定義以下術語（您可能需要使用網際網路查詢其中一些）：模式主機語言資料子語言資料定義語言一元關係外部索引鍵虛擬關係連線複合鍵連結表
RRE 貨運公司資料庫包含圖 8.12 中的三個表。使用圖 8.12 回答問題 4.1 到 4.5。圖 8.12. 卡車、基地和型別表，用於問題 4，作者 A. Watt。
1. 識別每個表的主鍵和外部索引鍵。
2. TRUCK 表是否具有實體和引用完整性？為什麼或為什麼不？解釋你的答案。
3. TRUCK 表和 BASE 表之間存在什麼關係？
4. TRUCK 表包含多少個實體？
5. 識別 TRUCK 表候選鍵。圖 8.13. 客戶和圖書訂單表，用於問題 5，作者 A. Watt。
假設您正在使用圖 8.13 中的資料庫，它由兩個表組成。使用圖 8.13 回答問題 5.1 到 5.6。
1. 識別每個表中的主鍵。
2. 識別 BookOrders 表中的外部索引鍵。
3. 兩個表中是否有任何候選鍵？
4. 繪製 ER 模型。
5. BookOrders 表是否具有引用完整性？為什麼或為什麼不？
6. 表中是否包含冗餘資料？如果是，哪個表以及冗餘資料是什麼？
檢視圖 8.14 中的學生表，列出所有可能的候選鍵。為什麼您選擇這些？圖 8.14. 用於問題 6 的學生表，作者 A. Watt。圖 8.15. 學校資料庫的 ERD，用於問題 7-10，作者 A. Watt。使用圖 8.15 中的學校資料庫的 ERD 回答問題 7 到 10。
識別 ERD 中的所有核心和從屬和特徵實體。
哪些表有助於弱關係？強關係？
檢視圖 8.15 中的學校資料庫中的每個表，哪個屬性可能具有 NULL 值？為什麼？
哪些表是由於多對多關係而建立的？

另請參見 *附錄 B：樣本 ERD 練習*

歸屬

這章 *資料庫設計*（包括影像，除非另有說明）是 Nguyen Kim Anh 創作的 *使用實體關係模型的資料建模* 的衍生作品，授權協議為知識共享署名許可證 3.0 版

以下內容由 Adrienne Watt 撰寫

空值部分和示例
關鍵詞
練習

參考文獻

BCOpenCampus：資料庫設計

← 關係資料模型

資料庫設計

完整性規則和約束 →