資料庫設計/完整性規則和約束

約束是關係模型中一個非常重要的特性。事實上，關係模型支援對屬性或表的明確定義的約束理論。約束很有用，因為它們允許設計者指定資料庫中資料的語義。約束是強制 DBMS 檢查資料是否滿足語義的規則。

域完整性

域限制關係中屬性的值，是關係模型的約束。但是，如果僅使用域約束，則無法指定資料的現實世界語義。我們需要更具體的方法來陳述允許或不允許哪些資料值以及哪個格式適合屬性。例如，員工 ID (EID) 必須唯一，或者員工出生日期在 [1950 年 1 月 1 日，2000 年 1 月 1 日] 範圍內。此類資訊在稱為完整性約束的邏輯語句中提供。

完整性約束有幾種型別，如下所述。

實體完整性

為了確保實體完整性，要求每個表都有一個主鍵。主鍵或其任何部分都不能包含空值。這是因為主鍵的空值意味著我們無法識別某些行。例如，在 EMPLOYEE 表中，Phone 不能作為主鍵，因為有些人可能沒有電話。

參照完整性

參照完整性要求外部索引鍵必須具有匹配的主鍵，或者必須為空。此約束是在兩個表（父表和子表）之間指定的；它維護這些表中行之間的對應關係。這意味著從一個表中的一行到另一個表的引用必須有效。

公司客戶/訂單資料庫中參照完整性約束的示例

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

為了確保沒有孤立記錄，我們需要強制參照完整性。孤立記錄是指其外部索引鍵 FK 值在相應實體（主鍵所在實體）中找不到的記錄。回想一下，典型的連線是在 PK 和 FK 之間的。

參照完整性約束規定 Order 表中的客戶 ID (CustID) 必須與 Customer 表中的有效 CustID 相匹配。大多數關係資料庫都有宣告式參照完整性。換句話說，在建立表時，參照完整性約束就會設定。

以下是來自課程/班級資料庫的另一個示例

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

參照完整性約束規定 Class 表中的 CrsCode 必須與 Course 表中的有效 CrsCode 相匹配。在這種情況下，Class 表中的 CrsCode 和 Section 構成主鍵是不夠的，我們還必須強制參照完整性。

設定參照完整性時，重要的是主鍵和外部索引鍵必須具有相同的資料型別並來自同一個域，否則關係資料庫管理系統 (RDBMS) 將不允許連線。RDBMS 是一個流行的資料庫系統，它基於 E. F. Codd 在 IBM 聖何塞研究實驗室提出的關係模型。關係資料庫系統比其他資料庫系統更容易使用和理解。

Microsoft Access 中的參照完整性

在 Microsoft (MS) Access 中，透過將 Customer 表中的主鍵連線到 Order 表中的 CustID 來設定參照完整性。參見圖 9.1，瞭解如何在 MS Access 的“編輯關係”螢幕上完成此操作。

圖 9.1。MS Access 中的參照訪問，作者：A. Watt。

使用 Transact-SQL (MS SQL Server) 的參照完整性

使用 Transact-SQL 時，參照完整性是在使用 FK 建立 Order 表時設定的。下面列出的語句顯示了 Order 表中 FK 對 Customer 表中主鍵的引用。

CREATE TABLE Customer

( CustID INTEGER PRIMARY KEY,

CustName CHAR(35) )

CREATE TABLE Orders

( OrderID INTEGER PRIMARY KEY,

CustID INTEGER REFERENCES Customer(CustID),

OrderDate DATETIME )

外部索引鍵規則

在設定參照完整性時，可以新增其他外部索引鍵規則，例如在刪除或更改（更新）具有主鍵的記錄（在父表（Customer 表）中）時如何處理子行（在 Orders 表中）。例如，MS Access 中的“編輯關係”視窗（參見圖 9.1）顯示了 FK 規則的兩個附加選項：“級聯更新”和“級聯刪除”。如果未選擇這些選項，系統將阻止在父表（Customer 表）中刪除或更新主鍵值，如果存在子記錄。子記錄是指任何具有匹配主鍵的記錄。

在某些資料庫中，在選擇“刪除”選項時，還存在一個名為“設定為 Null”的附加選項。如果選擇此選項，將刪除主鍵行，但子表中的外部索引鍵將設定為 NULL。儘管這會建立一個孤立行，但它是可以接受的。

企業約束

企業約束 - 有時稱為語義約束 - 是使用者或資料庫管理員指定的附加規則，可以基於多個表。

以下是一些示例。

一個班級最多可以有 30 名學生。
一名教師每個學期最多可以教授四門課程。
一名員工不能參與超過五個專案。
一名員工的工資不能超過其經理的工資。

業務規則

業務規則是在收集需求時從使用者那裡獲得的。需求收集過程非常重要，其結果應在構建資料庫設計之前由使用者進行驗證。如果業務規則不正確，則設計將不正確，最終構建的應用程式將無法按使用者預期的方式執行。

以下是業務規則的一些示例

一名教師可以教授許多學生。
一個班級最多可以有 35 名學生。
一門課程可以教授很多次，但只能由一名教師教授。
並非所有教師都教授課程。

基數和連線性

業務規則用於確定基數和連線性。基數透過表示與相關實體的一個例項相關聯的實體例項的最小和最大數量來描述兩個資料表之間的關係。在圖 9.2 中，您可以看到基數由關係符號上的最內層標記表示。在此圖中，基數在右側為 0（零），在左側為 1（一）。

圖 9.2。關係符號上連線性和基數的位置，作者：A. Watt。

另一方面，關係符號的最外層符號表示兩個表之間的連線性。連線性是指兩個表之間的關係，例如一對一或一對多。唯一一次為零是在 FK 可以為空時。在參與方面，這些實體之間關係有三個選項：0（零）、1（一）或多。例如，在圖 9.2 中，連線性在該線的外部左側為 1（一），在外部右側為多。

圖 9.3 顯示了表示一對多關係的符號。

圖 9.3。

在圖 9.4 中，顯示了內部（表示基數）和外部（表示連線性）標記。該符號的左側讀取為最小 1 和最大 1。在右側，它讀取為：最小 1 和最大多。

圖 9.4。

關係型別

連線兩個表的線，在 ERD 中，表示表之間的關係型別：識別或非識別。識別關係將有一條實線（其中 PK 包含 FK）。非識別關係由一條虛線表示，並且 PK 中不包含 FK。有關更多解釋，請參閱第 8 章中討論弱關係和強關係的部分。

圖 9.5。識別和非識別關係，作者 A. Watt。

可選關係

在可選關係中，FK 可以為空，或者父表不需要有相應的子表出現。圖 9.6 中所示的符號說明了一種型別，它有一個零和三個叉（表示多），解釋為零或多。

圖 9.6。

例如，如果您檢視圖 9.7 右側的訂單表，您會注意到客戶不需要下訂單才能成為客戶。換句話說，多邊是可選的。

圖 9.7。零到多可選關係符號的示例用法，作者 A. Watt。

圖 9.7 中的關係符號也可以這樣讀取

左側：訂單實體必須包含客戶表中至少一個相關實體，最多一個相關實體。
右側：客戶可以下至少零個訂單，最多下多個訂單。

圖 9.8 顯示了另一種型別的可選關係符號，它有一個零和一個，表示零或一。一邊是可選的。

圖 9.8。

圖 9.9 給出了零到一符號如何使用的示例。

圖 9.9。零到一可選關係符號的示例用法，作者 A. Watt。

強制關係

在強制關係中，一個實體出現需要一個相應的實體出現。這種關係的符號顯示只有一個，如圖 9.10 所示。一邊是強制的。

圖 9.10

請參見圖 9.11 以瞭解只有一個強制符號如何使用的示例。

圖 9.11。一個和只有一個強制關係符號的示例，作者 A. Watt。

圖 9.12 說明了多邊為強制的一對多關係符號的樣子。

圖 9.12。

請參閱圖 9.13 以瞭解如何使用一對多符號的示例。

圖 9.13。一對多強制關係符號的示例，作者 A. Watt。

到目前為止，我們已經看到關係符號的最內側（圖 9.14 中符號的左側）可以具有 0（零）基數和多（顯示在圖 9.14 中符號的右側）的連線性，或一個（未顯示）。

圖 9.14

然而，它不能具有 0（零）的連線性，如圖 9.15 所示。連線性只能是 1。

圖 9.15。

連線性符號顯示最大值。因此，如果您從邏輯上考慮，如果左側的連線性符號顯示 0（零），那麼表之間將沒有連線。

讀取關係符號的方式，例如圖 9.16 中的符號，如下所示。

訂單表中的 CustID 必須在客戶表中至少出現 0 次，最多出現 1 次。
0 表示訂單表中的 CustID 可以為空。
最左邊的 1（在代表連線性的 0 之前）表明，如果訂單表中存在 CustID，它只能在客戶表中出現一次。
當您看到基數的 0 符號時，您可以假設兩件事：T
1. 訂單表中的 FK 允許空值，並且
2. FK 不是 PK 的一部分，因為 PK 必須不包含空值。

圖 9.16。客戶表和訂單表之間的關係，作者 A. Watt。

關鍵詞

業務規則: 從使用者收集需求時獲得，用於確定基數

基數: 表示與一個相關實體出現相關聯的實體出現的最小和最大數量

連線性: 兩個表之間的關係，例如一對一或一對多

約束: 強制 DBMS 檢查資料是否滿足語義的規則

實體完整性: 要求每個表都有一個主鍵；主鍵或其任何部分都不能包含空值

識別關係: 主鍵包含外部索引鍵；在 ERD 中由實線表示

完整性約束: 邏輯語句，說明允許或不允許哪些資料值，以及哪個格式適合屬性

強制關係: 一個實體出現需要一個相應的實體出現。

非識別關係: 主鍵中不包含外部索引鍵；在 ERD 中由虛線表示

可選關係: FK 可以為空，或者父表不需要有相應的子表出現

孤兒記錄: 其外部索引鍵值在相應的實體中找不到的記錄 - 實體，主鍵所在的位置

參照完整性: 要求外部索引鍵必須具有匹配的主鍵，或者必須為空

關係資料庫管理系統 (RDBMS): 一種流行的資料庫系統，基於 E. F. Codd 在 IBM 聖何塞研究實驗室提出的關係模型

關係型別: ERD 中兩個表之間關係的型別（識別或非識別）；這種關係由連線兩個表的線表示。

練習

閱讀以下描述，然後回答最後的第 1-5 題。

圖 9.17 中的游泳俱樂部資料庫旨在儲存註冊游泳課程的學生的資訊。儲存以下資訊：學生、註冊、游泳課程、舉辦課程的游泳池、課程的教練以及各種游泳課程級別。使用圖 9.17 回答問題 1 到 5。

圖 9.17。問題 1-5 的 ERD。（作者 A. Watt 繪製。）

主鍵在下面標識。以下資料型別在 SQL Server 中定義。

tblLevels

Level - Identity PK

ClassName - text 20 - 不允許空值

tblPool

Pool - Identity PK

PoolName - text 20 - 不允許空值

Location - text 30

tblStaff

StaffID - Identity PK

FirstName - text 20

MiddleInitial - text 3

LastName - text 30

Suffix - text 3

Salaried - Bit

PayAmount - money

tblClasses

LessonIndex - Identity PK

Level - Integer FK

SectionID - Integer

Semester - TinyInt

Days - text 20

Time - datetime（格式化為時間）

Pool - Integer FK

Instructor - Integer FK

Limit - TinyInt

Enrolled - TinyInt

Price - money

tblEnrollment

LessonIndex - Integer FK

SID - Integer FK（LessonIndex 和 SID）主鍵

Status - text 30

Charged - bit

AmountPaid - money

DateEnrolled - datetime

tblStudents

SID - Identity PK

FirstName - text 20

MiddleInitial - text 3

LastName - text 30

Suffix - text 3

Birthday - datetime

LocalStreet - text 30

LocalCity - text 20

LocalPostalCode - text 6

LocalPhone - text 10

在 SQL Server 或訪問中實現此模式（您需要選擇可比資料型別）。提交您在資料庫中 ERD 的螢幕截圖。

解釋每種關係的關係規則（例如，tblEnrollment 和 tblStudents：學生可以註冊多個課程）。
假設以下規則，識別每種關係的基數
- 游泳池可能永遠不會有課程，也可能會有課程。
- 級別表必須始終與至少一個課程相關聯。
- 員工表可能從未教授過課程。
- 所有學生必須註冊至少一個課程。
- 課程必須有學生註冊。
- 該課程必須有有效的池。
- 該課程可能沒有指定講師。
- 該課程必須始終與現有級別相關聯。
哪些表格是弱表格，哪些表格是強表格（在前面的章節中介紹過）？
哪些表格是非標識表格，哪些是標識表格？

圖片歸屬

圖 9.3、9.4、9.6、9.8、9.10、9.12、9.14 和 9.15 由 A. Watt 繪製。

參考文獻

BCOpenCampus：資料庫設計

← 實體關係資料模型

資料庫設計

ER 建模 →