資料建模大資料就業挑戰月薪30K

非同步社群發表於2018-03-12

大資料就業

點選關注非同步圖書，置頂公眾號

每天與你分享 IT好書技術乾貨職場知識

本文大概

10624

字

讀完共需

分鐘

20180312103418490 Tips 參與文末話題討論，即有機會獲得非同步圖書一本。

20180312103428649

資料建模是對現實世界各類資料進行抽象組織、界定資料庫需管轄的範圍、確定資料的組織形式等直至轉化成現實資料庫的過程。而資料模型是構建應用系統的核心，是儘可能精準地表示業務運轉的概念性框架。

資料建模的過程是界定、分析、發現資料需求，再用視覺化的形式（“模型”）表示這種資料需求的過程。資料模型是用於精確表示資訊領域溝通的一套符號和文字。任何景觀的模型都會包含某些內容（例如地圖就是地理景觀的模型），同時為了方便理解又排除某些內容。

“發現”是確定業務過程或應用中業務需要什麼資訊，例如瞭解到客戶和賬號是個重要的概念。“分析”是明確需求的過程，例如對客戶和賬戶逐步有了清楚的定義，理解了客戶與他們的賬戶之間的關係。“界定範圍”涉及與業務合作來決定什麼對於特定的業務階段是最重要的。例如，第一階段是否同時需要“儲存”和“檢查賬號”，還是隻要“檢查賬號”就行了。“表示”是指要用清晰明確的語言展現出資訊景觀看上去是什麼樣的，例如可以用以下資料模型表示：

20180312103458165

一個客戶可以有一個或多個賬號。
一個賬號必須由一個或多個客戶擁有。

一旦我們將這些需求寫成了資料模型文件，就可以跟應用開發所涉及的業務和資訊科技（Information Technology，IT）人員進行溝通了，如業務使用者、業務分析師、資料建模人員、資料架構師、資料庫管理員、開發者、測試人員以及管理人員。

資料模型是用於從業務到IT，IT內部從系統分析員、建模人員、架構師到資料庫設計人員和開發人員之間溝通的主要媒介。無論要用的資料庫技術是關聯式資料庫管理系統（Relational Database Management System，RDBMS）（如ORACLE、Teradata），還是像MongoDB或Hadoop這樣的非關係型資料庫（Not Only SQL，NoSQL），都需要有種方式能用來溝通資料需求。因此，我們需要資料模型。

資料模型應該是高質量的，要能支援目前的需求同時又要能滿足未來的需要。資料模型記分卡是一個可以用來改進資料模型質量的工具。

許多我正在為他們提供諮詢服務的客戶都決定將資料記分卡應用到客戶的資料模型中，他們也推薦用資料模型記分卡來改進設計。

大資料就業挑戰月薪30K,本文將簡要介紹資料模型的組成，並教你如何看懂資料模型。

1.1　實體

實體表示與業務有關的重要且有價值的事務的資訊集合。每個實體由一個名詞或名詞片語來表示，一般適用於以下6種問題之一：誰、什麼、何時、哪裡、為什麼、如何。表1-1是這些實體類的定義並舉例說明。

表1-1　實體類的定義

分類	定義	舉例
誰（Who）	能為企業帶來好處的個人或組織。“誰對業務很重要？”常常與角色有關，例如客戶或供應商	員工、病人、演員、嫌疑人、客戶、供應商、學生、旅客、參賽者、作者
什麼（What）	對企業有利的產品或服務。常常指能使組織保持業務運轉的產出物。“什麼是對業務至關重要的？”	產品、服務、原材料、貨物清單、課程、歌曲、照片、圖書
何時（When）	企業所關心的日曆或時間週期。“何時業務在運作？”	時間、日期、月份、季度、年、學期、會計期間、分鐘
哪裡（Where）	企業關心的位置。位置可以指實際的地理位置，也可以指虛擬的位置。“業務在哪裡開展？”	郵件地址、分佈地點、網站的URL及IP地址
為什麼（Why）	企業所關心的事件或事務。事件會讓業務具有不確定性。“業務為什麼可以運轉？”	訂單、盈利、投訴、取錢、存錢、褒揚、問詢、交易、索賠
如何（How）	將企業關心的事件記錄下來。可以用文件記錄事件，如採購訂單用於記錄一個訂單事件。這就是”業務是如何跟蹤事件的？”	發票、合同、協議、購買訂單、收據、發票、裝箱清單、交易確認單

實體的例項是指特定實體的發生或實體的值。例如，表單就是一個實體，它的表頭的每個欄位表示每個實體要記錄的資訊。每個有實際值的表單行表示一個實體例項。“客戶”實體可能會有多個有不同名字的客戶例項，如Bob、Joe、Jane等。“賬號”實體有Bob的支票賬戶例項、Bob的存款賬戶例項、Joe的佣金賬戶例項等。

實體可以從概念層、邏輯層、物理層進行描述。概念層是對一個業務過程或應用系統定義其範圍和重要術語。邏輯層是對一個業務過程或應用系統的業務解決方案進行詳細描述，物理層則是對一個應用系統的技術解決方案進行詳細描述。

一個與概念層相關的實體一定是對業務基本且關鍵的。至於什麼是“基本且關鍵的”主要因範圍不同而不同。在通用層面，某些概念是大多數公司都共有的，例如，客戶、產品和員工。稍微收窄這個範圍，特定的行業可能會有某個特定的概念。例如，廣告役，這在廣告行業是有個有效的概念，但在其他行業中卻不適用。在出版行業，作者（Author）、書（Title）和訂單（Order）是概念實體，如圖1-1矩形框中的名字。

20180312103512107

圖1-1　用矩形框中的名字表示概念實體

邏輯層的實體比概念層更加詳細地表示了業務。經常會用一個概念實體表示多個邏輯實體。邏輯實體包含一些特性，我們叫作“屬性”，下一節會討論。前面的概念實體可以由3個邏輯實體表示，如圖1-2所示。

20180312103523694

圖1-2　邏輯實體

在物理層，實體與技術特定的物件有關，例如關聯式資料庫管理系統（Relational Database Management System，RDBMS）中的資料庫表或者非關係型資料庫（Not Only SQL，Nosgl）MongoDB中的集合。物理層與邏輯層相似，但可以包括彌補技術缺陷所需要的折中方案，一般是與效能或儲存有關的。

以下是前述邏輯實體的物理實體，如圖1-3所示。物理實體包含資料庫特定的資訊，例如，屬性的格式和長度（作者的姓氏，即Author Last Name是50個字元長度），該屬性是否必須有值（作者的稅號標識，即Author Tax Identifier不能為空因而必須有值，作者的出生日期，即Author Birth Date是可空的，所以不要求一定有值）。

20180312103532969

圖1-3　物理實體

在關聯式資料庫管理系統（Relational Database Management System，RDBMS）中，這些物理實體是資料庫表或檢視。在非關係型資料庫（Not Only SQL，NoSQL）中，這些物理實體根據所用的技術不同而不同。例如，在MongoDB這樣的文件資料庫中，這些實體是集合。常用的術語“結構”是指資料庫元件，無論這種資料庫是RDBMS還是NoSQL型別。

1.2　屬性

屬性是用來識別、描述或度量實體例項的單個資訊單元。貨運單號（Claim Number）屬性標識每個貨運單。學生姓氏（Student Last Name）屬性描述每個學生。訂單金額（Gross Sales Amount）屬性度量每筆交易的金額。

像實體一樣，屬性也可以在概念、邏輯和物理層描述。概念層的屬性必須是對業務基本且關鍵的。通常我們並不從概念層描述屬性，當然根據業務需求的不同，也可以作為概念層的屬性。我在一家通訊公司工作時，電話號碼是對業務非常重要的屬性，所以多個概念模型中都有電話號碼屬性。

邏輯模型的屬性表示業務特性。每個屬性顯示出它對業務解決方案的貢獻，並且獨立於任何軟硬體技術。例如，作者的姓氏（Author Last Name）就是一個屬性，因為它有重要的業務意義，無論這些記錄是儲存在紙質檔案裡還是能快速檢索的資料庫裡。物理模型的屬性代表資料庫的一列。作者的姓氏（Author Last Name）屬性可能在關聯式資料庫的AUTH表裡用AUTH_LAST_NM列表示，或者在MongoDB集合LibraryCardCatalog中用AuthorLastName表示。

1.3　域

一個屬性所有可能賦值的全部集合叫作域。域包括一套可應用於不止一個屬性的驗證標準。例如，日期（Date）域含有可給以下這些屬性賦值的所有可能的有效日期。

員工僱用日期
下單日期
交貨日期
課程開始日期

一個屬性一定不能包含其賦值域以外的值。域值由特定的實際列表值定義或者由一套規則定義。例如，員工性別程式碼，其值域限制為（男和女），員工僱用日期可能有預設的規則，這個域值只能是有效的日期。因此，可能會有以下值，如：

2005-02-15
1910-01-25
20150410
2050-03-10

員工僱用日期必須是有效日期，例如不能是2月30號。還可以用附加的規則來限制屬性的域值。例如，將員工僱用日期域限制為必須早於今天的日期，這樣就能排除類似2050年3月10日這樣的日期。限制員工僱傭日期為YYYYMMDD格式（年、月、日連線），就能排除所有不符合日期格式的值，例如20152410就會違規。另外一種限制域值的方式是規定員工僱用日期只能是週一、週二、週三、週四、週五的日期（即只能是工作日）。

有3種基本的域型別。

格式化域：設定資料庫中可用的標準資料型別。如Character(30)和date，這些都是格式化域。
列表域：類似於下拉選單，列出幾個值可供選擇。列表域是格式化域的改良。訂單狀態程式碼的格式化域可能是 Character(10)，這個域可以從列表域可能的值（開啟，已運送，已關閉，已退回）中進行選擇。
範圍域：規定該域所允許的值在最小值和最大值之間。例如，訂單交付日期必須在今天和未來的幾個月之間。與列表域類似，範圍域也是格式化域的改良。

1.4　關係

實體間的關係是指這些實體的例項可能以某種有意思的方式相關。每個關係都可以定義規則，包括何時相關以及有多少例項相關。關係可以用兩個實體間的一條線來描述。有些建模還可以有兩個以上的關係，它們會有不同的描述。如果這兩個實體是員工和部門，他們之間的關係可以描述為“每個員工必須為一個部門工作”“每個部門可以有一個或多個員工”。

在兩個實體關係中，基數能記錄有多少例項從一個實體參與到與另一個實體例項的關係中，它由出現在關係線兩端的符號表示。基數指定一種可強制的資料規則。如果沒有基數，我們最多可以說關係是兩個實體以某種方式通過一個規則相互關聯。例如，員工和部門有某種關係，但我們知道的僅限於這點。注意，相同的兩個實體可以有不止一種相關方式；例如每個部門可以有一個或多個員工，但是可能還會有一個單獨的關係記錄著某個員工管理某個部門。

關於基數，我們可以選擇0、1或多（m）的組合。多（m）表示任何大於0的數。0或1可以記錄一個實體例項在一個關係中是否是必需的。1或多（m）可以表示有多少個特定的例項參與這個關係。

因為我們的圖示僅有3種基數符號，所以無法指定一個準確的數字[1]（除非通過文件），如“一輛車有4個輪胎”。我們只能說“一輛車可以有多個輪胎”，以作者和書為例，每種基數符號如圖1-4所示。

20180312103547484

圖1-4　基數的符號表示

這個例子中的業務規則是：

每個作者（Author）可以寫一本或多本書（Title）。
每本書（Title）必須只能由一個作者（Author）寫。

短豎線表示1（看上去像個1，是吧），圓圈表示0（看上去也像個0），0表示可選，但並不排除值1，所以在上面的例子中，一個作者（Author）只能寫一本書（Title）。三角形中間有一根線意思是多個（m）。有人把m符號叫作魚尾紋（crow’s foot）。

關係線上通常有標籤用來說明關係和關係所表示的規則。資料模型是一種通訊工具，如果你還記得實體是個名詞，關係標籤就是一個現在時態動詞。因此，讓我們讀下面這句話。

每個作者可以寫一本或多本書。

每個關係都有一個父實體和一個子實體。父實體出現在關係的1那邊，子實體出現在關係的多（m）那邊。這個例子中，父實體是作者（Author），子實體是書（Title）。當我讀一個關係的時候，我會從關係1那邊的實體（父實體）開始。“每個作者可以寫一本或多本書。”然後再從關係中多的那端讀“每本書必須由一個作者寫。”

在讀關係的時候，我也總是使用“每個”從父實體那邊開始。使用“每個”這個單詞的原因是你想要指定一個實體平均有多少個例項與另一個實體的例項相關。

有兩種型別的關係：依賴型（identifying）和不依賴型（non-identifying）。依賴型（identifying）關係用實線表示，意思是m一側的實體（子）總是1一側的實體（父）的依賴型實體。虛線的意思是m一側的實體（子）不依賴於1一側的實體（父）。圖1-5是這兩種型別的關係。

20180312103601323

圖1-5　兩種型別的關係

不依賴型實體以尖角矩形表示。依賴型實體以圓角矩形表示，如“書”在依賴型關係中的例子。不依賴型的實體是實體的每個例項都只用它自己的屬性。例如在不依賴型關係中“書”的例子，可以由ISBN（國際標準書號）找到，ISBN是屬於“書”的一個屬性。依賴型實體只能通過使用至少一個不同實體的屬性找到，如依賴型關係中的書和作者的稅號。我們可以改變基數試試，現在允許一本書可以由多個作者寫，如圖1-6所示。

20180312103609321

圖1-6　一本書可以由多個作者寫

與前面一對多的例子相比，這是一個多對多關係的例子。這裡的業務規則是：

每個作者可以寫一本或多本書；
每本書必須由一個或多個作者寫。

“寫”在這兩個例子中，都可以當成關係標籤。有時候，反向標籤也會出現在關係線中，例如由X寫。我傾向於只顯示一個關係標籤以減少模型中的混亂，同時也由於大多數情況我們能用相同的單詞結構做反向標籤：寫，由X寫。

有 3 種層級的粒度（概念、邏輯和物理）可應用於實體和屬性，也可用於連線實體的關係。概念關係是高層規則或連線概念的檢索路徑。邏輯關係是詳細的業務規則或邏輯實體間的強制規則的檢索路徑。物理關係則是詳細的技術依賴規則或有關係連線的物理結構間的檢索路徑。這些物理關係可能最終會變成關聯式資料庫管理系統中的資料庫約束，或文件資料庫（如MongoDB）中的參照關係。

1.5　鍵

如果資料量很大，如何才能快速找到你要找的資料呢？這就是為什麼需要鍵了。鍵可以用來建立強制規則，還能高效地檢索資料的一個或多個屬性，此外可以用來從一個實體檢索另一個實體。這一節解釋了候選鍵（主鍵、替代鍵）、代理鍵、外來鍵和第二鍵。

候選鍵（主鍵、替代鍵）

候選鍵是一個或多個能唯一識別一個實體例項的屬性。例如，給每本書分配一個國際標準書號（International Standard Book Number，ISBN）。ISBN唯一地識別每本書，因此可以作為書的候選鍵。當把本書的ISBM編號“9781634620826”輸入到多種搜尋引擎或資料庫系統時，結果就返回了本書的實體例項《資料模型記分卡》（你可以試試）。稅號可以是一些國家的組織機構候選鍵，如美國。賬號程式碼可以是賬號實體的候選鍵。車輛標識號（Vehicle Identification Number，VIN）可以識別一輛車。有時候只用一個屬性就能識別一個實體例項，例如用ISBN識別書名。有時候卻需要多個屬性來唯一識別一個實體例項。例如：必須通過促銷型別程式碼和促銷開始日期一起來唯一識別一個促銷。當多個屬性組成一個鍵時，我們用術語“組合鍵”表示這種鍵。因此，促銷型別程式碼和促銷開始日期一起構成促銷的組合候選鍵。候選鍵有以下4個主要的特徵。

唯一的。一個候選鍵一定不能識別出多於一個實體例項（一個真實世界的物品）。
強制的。候選鍵不能為空，每個實體例項必須由一個候選鍵標識。所以，候選鍵的所有不同值的數目總是等於全部不同實體的數目。例如用ISBN作為書的候選鍵，如果有500個書的例項，那麼就有500個唯一的ISBN。
不變的。實體例項上的候選鍵應該永遠不變。
最短的。候選鍵應該只包含那些可以唯一識別的實體例項的屬性。如果有4個屬性列出來作為一個實體的組合候選鍵，但只有3個是標識唯一性所必需的，那麼就只需要由這3個屬性組成候選鍵。

例如，每個學生可以學習一門或多門課程，每門課程可以有一個或多個學生。表1-2～表1-4是兩個實體的一些簡單例項。

表1-2　學生表

學生編號	學生名	學生姓氏	出生日期
SM385932	Steve	Martin	1/25/1958
EM584926	Eddie	Murphy	3/15/1971
HW742615	Henry	Winkler	2/14/1984
MM481526	Mickey	Mouse	5/10/1982
DD857111	Donald	Duck	5/10/1982
MM573483	Minnie	Mouse	4/1/1986
LR731511	Lone	Ranger	10/21/1949
EM876253	Eddie	Murphy	7/1/1992

表1-3　出勤表

出勤日期
5/10/2015
6/10/2015
7/10/2015

表1-4　課程表

課程全稱	課程簡稱	課程描述
資料建模基礎	資料建模101	一門介紹性課程，介紹資料建模的基本概念和原則
資料建模進階	資料建模301	一門技術類的進階課程，如高階正規化和不規則層次結構
網球基礎	網球	教網球初學者學習這個遊戲的關鍵方面
雜技		學習如何能同時保持讓3個球在空中

根據我們對候選鍵的定義（候選鍵的特徵是唯一的、穩定的和最小的），應該選擇什麼欄位作為這些實體的候選鍵呢？

對於學生實體，學生編號看上去是個有效的候選鍵。有 8 個學生和 8個唯一的學生編號值。不像學生名和學生姓氏有重複值，如名字 Eddie Murphy就有重複。而學生編號 Student Number 是唯一的。出生日期也有重複值，如5/10/1982，Mickey Mouse和Donald Duck的出生日期都有這個值。學生名、學生姓氏和出生日期這3個欄位的組合也像一個有效的組合候選鍵，但請注意我們不推薦使用這樣的鍵，因為這在某些系統中可能會有問題。

出勤實體，現在缺少了候選鍵。在這個簡單的資料表中儘管出勤日期是唯一的，我們可能需要知道在特定的日期裡哪個學生上了哪門課程，所以這個出勤實體的定義是不完全的。

課程實體，初看似乎任何屬性都是唯一的，都可以做候選鍵。然而，雜技這門課程沒有課程簡稱，因此，鑑於課程簡稱可以為空所以不能當做候選鍵。此外，候選鍵的另一個特徵是不變性。根據我的教學經驗，描述可能會變。因此，課程描述也需要從候選鍵中排除，只有課程全稱才是候選鍵的最好選擇。

儘管一個實體可能有多個候選鍵，但對於一個實體我們也只能選擇一個候選鍵做主鍵。主鍵是從候選鍵中首選的能唯一標識實體的候選鍵。替代鍵是候選的，儘管也有唯一性、穩定性和最小的特點，卻不能作為主鍵，儘管替代鍵也可以用來查詢特定的實體例項。

在課程實體中只有一個候選鍵，所以課程全稱就變成主鍵。而學生實體需要做個選擇，因為它有兩個候選鍵。應該用哪個候選鍵作主鍵呢？

選擇哪個候選鍵作為主鍵，需要考慮簡潔和私密性。簡潔意味著如果有幾個候選鍵，要選那個屬性最少和長度最短的。而私密性，有可能候選鍵中的一個或多個屬性含有敏感資料，檢視這樣的資料會受限。需要避免實體主鍵中含有敏感資料，因為主鍵可能繁衍成外來鍵，因此會將這個敏感資料傳播到整個資料庫範圍。

在我們的例子中如果考慮簡潔性和安全性，我會選擇學生編號，而不是學生名、學生姓氏和出生日期。因為前者更簡潔且含有更少的敏感資訊。

這是我們的主鍵和替代鍵的資料模型，如圖1-7所示。

20180312103620747

圖1-7　主鍵和替代鍵的資料模型

主鍵屬性在矩形框中的橫線之上。你會注意到有兩個數字跟在鍵的縮寫名“AK”之後，第一個數是替代鍵的一組數字，第二個數表示替代鍵中的屬性順序。所以學生實體屬性的替代鍵有3個屬性。

學生名、學生姓氏和出生日期。這也是將要建立的替代鍵索引的順序，因為學生名在冒號之後有個“1”，學生姓氏是“2”，出生日期是“3”。

出勤實體的主鍵是學生編號和課程全稱，這兩個欄位看上去可以組成一個有效的主鍵。注意出勤實體的兩個主鍵屬性跟著一個“FK”，這是外來鍵，後面很快會講到。

所以，簡單地說，一個候選鍵由一個或多個屬性組成，能唯一地識別一個實體例項。可以選擇能最好地識別實體中每個記錄的候選鍵作主鍵，其他的候選鍵則作為替代鍵。由多個屬性組成的鍵叫作組合鍵。在物理層，候選鍵常常轉換成唯一索引。

1.6　代理鍵

代理鍵是表的唯一識別符號，常用來計數，通常具有固定長度，一般由系統自動生成，沒有含義。所以代理鍵沒有任何業務含義。（換句話說，不能看到一個月份識別符號為1，就認為它代表月份實體的例項值一月）。代理鍵應該對業務是不可見的，但應該保留在後臺以允許更高效的檢索，也方便應用之間的整合。

代理鍵也是高效的。你已經見過主鍵可能是多個實體屬性的組合。相對於必須指定3～4個（或5～6個）屬性來定位你要查詢的一條記錄，使用單個代理鍵更高效。代理鍵有利於整合，整合的目的是為了建立一個唯一一致的資料版本。像資料倉儲這樣的應用常常要儲存不止一個應用或系統的資料。一個實體例項在每個源系統中都有不同的標識，這些實體例項的相關性從公共的識別符號看起來不太明顯，這時用代理鍵可以記錄同一個實體例項的資訊之間的相互關係。

使用代理鍵時，總是先確定自然鍵。自然鍵是能唯一識別實體的方式，這是業務要考慮的，然後將自然鍵定義為替代鍵。例如，如表1-5所示，假定一個代理鍵是比課程全稱更高效的主鍵，我們可以為課程實體建立課程編號代理鍵，在自然鍵課程全稱上定義一個替代鍵，如圖1-8所示課程的值。

20180312103632819

圖1-8　在自然鍵課程全稱上定義一個替代鍵

表1-5　課程實體中的課程

課程編號	課程全稱	課程簡稱	課程描述
1	資料建模基礎	資料建模101	一門介紹性課程，介紹資料建模的基本概念和原則
2	資料建模進階	資料建模301	一門技術類的進階課程，如高階正規化和不規則層次結構
3	網球基礎	網球	教網球初學者學習這個遊戲的關鍵
4	雜技		學習如何能同時保持讓3個球在空中

1.7　外來鍵

在實體的“1”那側的關係我們叫作父實體，在“多（m）”那側的關係叫作子實體。當我們建立一個從父實體到子實體的關係時，父實體的主鍵就被複製為子實體的外來鍵。外來鍵是一個或多個屬性，提供到另外一個實體的連結（也有種遞迴關係的情況，同一個實體的兩個例項是相關的，一個連結連到同一個實體）。在物理層面，外來鍵允許關聯式資料庫管理系統從一個表到另外一個表進行檢索。例如，如果我們需要知道一個有賬號的客戶，我們就想把客戶編號放在賬號實體中。賬號實體中的客戶編號就是客戶實體的主鍵。使用外來鍵返回到賬號表可以讓資料庫管理系統從特定的賬戶檢索或者從賬號到客戶進行檢索，再或者找到每個有賬號的客戶。類似地，資料庫可以從特定的客戶到賬號檢索以找到某個客戶的所有賬號。當兩個實體間的關係確定了之後，資料庫建模工具就自動地建立了外來鍵。

在學生/課程模型中，出勤實體中有兩個外來鍵，學生編號外來鍵指向學生實體中特定的學生，課程編號外來鍵指向課程實體中特定的課程，如表 1-6所示。

表1-6　課程編號外來鍵指向課程實體中特定的課程

學生編號	課程編號	出勤日期
SM385932	1	5/10/2015
EM584926	1	5/10/2015
EM584926	2	6/10/2015
MM481526	2	6/10/2015
MM573483	2	6/10/2015
LR731511	3	7/10/2015

通過檢視這些值，回憶起表1-6中的樣例資料，我們瞭解到Steve Martin和Eddie Murphy兩人在2015年10月5號都聽了資料建模基礎這門課。Eddie Murphy還和Mickey Mouse、Minnie Mouse一起聽了2015年10月6日的高階資料建模這門課。Lone Ranger在2015年10月7日上的是網球基礎（跟往常一樣，還是他一個人）。

另外，注意出勤表（Attendance）當前的主鍵是假定一個學生只能參加一門課程一次。如果業務規則說明一個學生能參加一門課程一次或多次，我們就需要修改出勤表的主鍵，增加出勤日期（Attendance Date）欄位。

1.8　次鍵

有時候需要從表中快速檢索資料來回答業務的問題或滿足響應時間的要求。次鍵是需要頻繁訪問和快速檢索的一個或多個屬性（如果有多個屬性，就叫作組合次鍵）。次鍵也就是眾所周知的非唯一索引或反向條目（inversion entry，IE）。次鍵不必唯一、穩定，也不必非空。例如，我們可以給學生表（Student）增加學生姓氏（Student Last Name）欄位作為從鍵，以允許無論何時需要查詢學生姓氏（Student Last Name）都能快速檢索，如圖1-9所示。

20180312103650349

圖1-9　給學生表（Student）增加學生姓氏（Student Last Name）欄位作為從鍵

學生姓氏（Student Last Name）不唯一，因為可能有兩個人都叫Murphys；它是不穩定的，會隨著時間變更；儘管很少發生，但也可能會有我們不知道某人名字的時候，所以，它可能為空。

1.9　子型別

子型別允許將公用屬性、相似的關係或相關的實體分組。某些概念非常相似或者為了展示一些例子往往可以用子型別。在出版行業，一個作者可能會寫多部紙質版（PrintVersion）的書和多本電子版圖書（eBooks），如圖1-10所示。

20180312103701327

圖1-10　一個作者可以寫多部紙質版和多部電子版圖書的模型

每個作者（Author）可以寫一本或多本紙質版（PrintVersion）的書。
每個紙質版（PrintVersion）的書必須由一個作者（Author）寫。
每個作者（Author）可以寫一本或多本電子書（eBook）。
每本電子書（eBooks）必須由一個作者（Author）寫。

接下來，讓我們來介紹子型別，如圖1-11所示。

20180312103714847

圖1-11　子型別

每個作者（Author）可以寫一本或多本書（Title）。
每本書（Title）必須由一個作者（Author）寫。
每本書（Title）可以是紙質版（PrintVersion）或電子版（eBook）。
每個紙質版（PrintVersion）的書都有一個書名（Title）。
每個電子書（eBook）有一個書名（Title）。

子型別關係隱含了一個規則，即超型別的所有關係和屬性也應用到每個子型別。因此，從作者（Author）到電子書（eBook）有一種隱性的關係，從作者（Author）到紙質版（PrintVersion）也是如此。titleName、subtitleName和titleRetailPrice屬於紙質版（PrintVersion），也屬於電子書（eBook）。注意每個子型別的主鍵是到超型別的外來鍵，所以它們有相同的屬性。在這個例子中，titleISBN是一本書的識別符號。

子型別不僅減少了資料模型上的冗餘，也能透過表面上唯一的和獨立的概念從而更容易溝通它們的相似性。

在某些情況下，一個子型別可以有多個子型別集合；例如，一個人可能是一個孩子、青少年或成年人，獨立於這些分類，一個人還可能是男性或女性。

在某些情況下，超型別可以沒有任何子型別也能存在，而在另一些情況下，卻不可以。每個超型別必須有一個子型別例項。

例如，一個人可能是一個司機，或者不是；無論哪種情況他仍然是一個人。但一個銀行賬號就必須總是某種特定子型別的賬號。

[1]　注意：如果使用統一建模語言（Unified Modeling Language，UML）中的類圖，就可以指定準確的基數。

本文摘自《資料模型記分卡》