點選關注 異步圖書，置頂公衆号
每天與你分享 IT好書 技術幹貨 職場知識
本文大概
10624
字
讀完共需
30
分鐘
Tips 參與文末話題讨論，即有機會獲得異步圖書一本。
資料模組化是對現實世界各類資料進行抽象組織、界定資料庫需管轄的範圍、确定資料的組織形式等直至轉化成現實資料庫的過程。而資料模型是建構應用系統的核心，是盡可能精準地表示業務運轉的概念性架構。
資料模組化的過程是界定、分析、發現資料需求，再用可視化的形式（“模型”）表示這種資料需求的過程。資料模型是用于精确表示資訊領域溝通的一套符号和文字。任何景觀的模型都會包含某些内容（例如地圖就是地理景觀的模型），同時為了友善了解又排除某些内容。
“發現”是确定業務過程或應用中業務需要什麼資訊，例如了解到客戶和賬号是個重要的概念。“分析”是明确需求的過程，例如對客戶和賬戶逐漸有了清楚的定義，了解了客戶與他們的賬戶之間的關系。“界定範圍”涉及與業務合作來決定什麼對于特定的業務階段是最重要的。例如，第一階段是否同時需要“儲存”和“檢查賬号”，還是隻要“檢查賬号”就行了。“表示”是指要用清晰明确的語言展現出資訊景觀看上去是什麼樣的，例如可以用以下資料模型表示：
一個客戶可以有一個或多個賬号。
一個賬号必須由一個或多個客戶擁有。
一旦我們将這些需求寫成了資料模型文檔，就可以跟應用開發所涉及的業務和資訊技術（Information Technology，IT）人員進行溝通了，如業務使用者、業務分析師、資料模組化人員、資料架構師、資料庫管理者、開發者、測試人員以及管理人員。
資料模型是用于從業務到IT，IT内部從系統分析員、模組化人員、架構師到資料庫設計人員和開發人員之間溝通的主要媒介。無論要用的資料庫技術是關系資料庫管理系統（Relational Database Management System，RDBMS）（如ORACLE、Teradata），還是像MongoDB或Hadoop這樣的非關系型資料庫（Not Only SQL，NoSQL），都需要有種方式能用來溝通資料需求。是以，我們需要資料模型。
資料模型應該是高品質的，要能支援目前的需求同時又要能滿足未來的需要。資料模型記分卡是一個可以用來改進資料模型品質的工具。
許多我正在為他們提供咨詢服務的客戶都決定将資料記分卡應用到客戶的資料模型中，他們也推薦用資料模型記分卡來改進設計。
大資料就業挑戰月薪30K,本文将簡要介紹資料模型的組成，并教你如何看懂資料模型。
實體表示與業務有關的重要且有價值的事務的資訊集合。每個實體由一個名詞或名詞詞組來表示，一般适用于以下6種問題之一：誰、什麼、何時、哪裡、為什麼、如何。表1-1是這些實體類的定義并舉例說明。
表1-1 實體類的定義
分類
定義
舉例
誰
（Who）
能為企業帶來好處的個人或組織。“誰對業務很重要？”常常與角色有關，例如客戶或供應商
員工、病人、演員、嫌疑人、客戶、供應商、學生、旅客、參賽者、作者
什麼（What）
對企業有利的産品或服務。常常指能使組織保持業務運轉的産出物。“什麼是對業務至關重要的？”
産品、服務、原材料、貨物清單、課程、歌曲、照片、圖書
何時（When）
企業所關心的月曆或時間周期。“何時業務在運作？”
時間、日期、月份、季度、年、學期、會計期間、分鐘
哪裡（Where）
企業關心的位置。位置可以指實際的地理位置，也可以指虛拟的位置。“業務在哪裡開展？”
郵件位址、分布地點、網站的URL及IP位址
為什麼（Why）
企業所關心的事件或事務。事件會讓業務具有不确定性。“業務為什麼可以運轉？”
訂單、盈利、投訴、取錢、存錢、褒揚、問詢、交易、索賠
如何
（How）
将企業關心的事件記錄下來。可以用文檔記錄事件，如采購訂單用于記錄一個訂單事件。這就是”業務是如何跟蹤事件的？”
發票、合同、協定、購買訂單、收據、發票、裝箱清單、交易确認單
實體的執行個體是指特定實體的發生或實體的值。例如，表單就是一個實體，它的表頭的每個字段表示每個實體要記錄的資訊。每個有實際值的表單行表示一個實體執行個體。“客戶”實體可能會有多個有不同名字的客戶執行個體，如Bob、Joe、Jane等。“賬号”實體有Bob的支票賬戶執行個體、Bob的存款賬戶執行個體、Joe的傭金賬戶執行個體等。
實體可以從概念層、邏輯層、實體層進行描述。概念層是對一個業務過程或應用系統定義其範圍和重要術語。邏輯層是對一個業務過程或應用系統的業務解決方案進行較長的描述，實體層則是對一個應用系統的技術解決方案進行較長的描述。
一個與概念層相關的實體一定是對業務基本且關鍵的。至于什麼是“基本且關鍵的”主要因範圍不同而不同。在通用層面，某些概念是大多數公司都共有的，例如，客戶、産品和員工。稍微收窄這個範圍，特定的行業可能會有某個特定的概念。例如，廣告役，這在廣告行業是有個有效的概念，但在其他行業中卻不适用。在出版行業，作者（Author）、書（Title）和訂單（Order）是概念實體，如圖1-1矩形框中的名字。
圖1-1 用矩形框中的名字表示概念實體
邏輯層的實體比概念層更加詳細地表示了業務。經常會用一個概念實體表示多個邏輯實體。邏輯實體包含一些特性，我們叫作“屬性”，下一節會讨論。前面的概念實體可以由3個邏輯實體表示，如圖1-2所示。
圖1-2 邏輯實體
在實體層，實體與技術特定的對象有關，例如關系資料庫管理系統（Relational Database Management System，RDBMS）中的資料庫表或者非關系型資料庫（Not Only SQL，Nosgl）MongoDB中的集合。實體層與邏輯層相似，但可以包括彌補技術缺陷所需要的折中方案，一般是與性能或存儲有關的。
以下是前述邏輯實體的實體實體，如圖1-3所示。實體實體包含資料庫特定的資訊，例如，屬性的格式和長度（作者的姓氏，即Author Last Name是50個字元長度），該屬性是否必須有值（作者的稅号辨別，即Author Tax Identifier不能為空因而必須有值，作者的出生日期，即Author Birth Date是可空的，是以不要求一定有值）。
圖1-3 實體實體
在關系資料庫管理系統（Relational Database Management System，RDBMS）中，這些實體實體是資料庫表或視圖。在非關系型資料庫（Not Only SQL，NoSQL）中，這些實體實體根據所用的技術不同而不同。例如，在MongoDB這樣的文檔資料庫中，這些實體是集合。常用的術語“結構”是指資料庫元件，無論這種資料庫是RDBMS還是NoSQL類型。
屬性是用來識别、描述或度量實體執行個體的單個資訊單元。貨運單号（Claim Number）屬性辨別每個貨運單。學生姓氏（Student Last Name）屬性描述每個學生。訂單金額（Gross Sales Amount）屬性度量每筆交易的金額。
像實體一樣，屬性也可以在概念、邏輯和實體層描述。概念層的屬性必須是對業務基本且關鍵的。通常我們并不從概念層描述屬性，當然根據業務需求的不同，也可以作為概念層的屬性。我在一家通訊公司工作時，電話号碼是對業務非常重要的屬性，是以多個概念模型中都有電話号碼屬性。
邏輯模型的屬性表示業務特性。每個屬性顯示出它對業務解決方案的貢獻，并且獨立于任何軟硬體技術。例如，作者的姓氏（Author Last Name）就是一個屬性，因為它有重要的業務意義，無論這些記錄是儲存在紙質檔案裡還是能快速檢索的資料庫裡。實體模型的屬性代表資料庫的一列。作者的姓氏（Author Last Name）屬性可能在關系資料庫的AUTH表裡用AUTH_LAST_NM清單示，或者在MongoDB集合LibraryCardCatalog中用AuthorLastName表示。
一個屬性所有可能指派的全部集合叫作域。域包括一套可應用于不止一個屬性的驗證标準。例如，日期（Date）域含有可給以下這些屬性指派的所有可能的有效日期。
員工雇用日期
下單日期
交貨日期
課程開始日期
一個屬性一定不能包含其指派域以外的值。域值由特定的實際清單值定義或者由一套規則定義。例如，員工性别代碼，其值域限制為（男和女），員工雇用日期可能有預設的規則，這個域值隻能是有效的日期。是以，可能會有以下值，如：
2005-02-15
1910-01-25
20150410
2050-03-10
員工雇用日期必須是有效日期，例如不能是2月30号。還可以用附加的規則來限制屬性的域值。例如，将員工雇用日期域限制為必須早于今天的日期，這樣就能排除類似2050年3月10日這樣的日期。限制員工雇傭日期為YYYYMMDD格式（年、月、日連接配接），就能排除所有不符合日期格式的值，例如20152410就會違規。另外一種限制域值的方式是規定員工雇用日期隻能是周一、周二、周三、周四、周五的日期（即隻能是工作日）。
有3種基本的域類型。
格式化域：設定資料庫中可用的标準資料類型。如Character(30)和date，這些都是格式化域。
清單域：類似于下拉清單，列出幾個值可供選擇。清單域是格式化域的改良。訂單狀态代碼的格式化域可能是 Character(10)，這個域可以從清單域可能的值（打開，已運送，已關閉，已退回）中進行選擇。
範圍域：規定該域所允許的值在最小值和最大值之間。例如，訂單傳遞日期必須在今天和未來的幾個月之間。與清單域類似，範圍域也是格式化域的改良。
實體間的關系是指這些實體的執行個體可能以某種有意思的方式相關。每個關系都可以定義規則，包括何時相關以及有多少執行個體相關。關系可以用兩個實體間的一條線來描述。有些模組化還可以有兩個以上的關系，它們會有不同的描述。如果這兩個實體是員工和部門，他們之間的關系可以描述為“每個員工必須為一個部門工作”“每個部門可以有一個或多個員工”。
在兩個實體關系中，基數能記錄有多少執行個體從一個實體參與到與另一個實體執行個體的關系中，它由出現在關系線兩端的符号表示。基數指定一種可強制的資料規則。如果沒有基數，我們最多可以說關系是兩個實體以某種方式通過一個規則互相關聯。例如，員工和部門有某種關系，但我們知道的僅限于這點。注意，相同的兩個實體可以有不止一種相關方式；例如每個部門可以有一個或多個員工，但是可能還會有一個單獨的關系記錄着某個員工管理某個部門。
關于基數，我們可以選擇0、1或多（m）的組合。多（m）表示任何大于0的數。0或1可以記錄一個實體執行個體在一個關系中是否是必需的。1或多（m）可以表示有多少個特定的執行個體參與這個關系。
圖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是這兩種類型的關系。
圖1-5 兩種類型的關系
不依賴型實體以尖角矩形表示。依賴型實體以圓角矩形表示，如“書”在依賴型關系中的例子。不依賴型的實體是實體的每個執行個體都隻用它自己的屬性。例如在不依賴型關系中“書”的例子，可以由ISBN（國際标準書号）找到，ISBN是屬于“書”的一個屬性。依賴型實體隻能通過使用至少一個不同實體的屬性找到，如依賴型關系中的書和作者的稅号。我們可以改變基數試試，現在允許一本書可以由多個作者寫，如圖1-6所示。
圖1-6 一本書可以由多個作者寫
與前面一對多的例子相比，這是一個多對多關系的例子。這裡的業務規則是：
每個作者可以寫一本或多本書；
每本書必須由一個或多個作者寫。
“寫”在這兩個例子中，都可以當成關系标簽。有時候，反向标簽也會出現在關系線中，例如由X寫。我傾向于隻顯示一個關系标簽以減少模型中的混亂，同時也由于大多數情況我們能用相同的單詞結構做反向标簽：寫，由X寫。
有 3 種層級的粒度（概念、邏輯和實體）可應用于實體和屬性，也可用于連接配接實體的關系。概念關系是高層規則或連接配接概念的檢索路徑。邏輯關系是詳細的業務規則或邏輯實體間的強制規則的檢索路徑。實體關系則是詳細的技術依賴規則或有關系連接配接的實體結構間的檢索路徑。這些實體關系可能最終會變成關系資料庫管理系統中的資料庫限制，或文檔資料庫（如MongoDB）中的參照關系。
如果資料量很大，如何才能快速找到你要找的資料呢？這就是為什麼需要鍵了。鍵可以用來建立強制規則，還能高效地檢索資料的一個或多個屬性，此外可以用來從一個實體檢索另一個實體。這一節解釋了候選鍵（主鍵、替代鍵）、代理鍵、外鍵和第二鍵。
候選鍵是一個或多個能唯一識别一個實體執行個體的屬性。例如，給每本書配置設定一個國際标準書号（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
MM573483
Minnie
4/1/1986
LR731511
Lone
Ranger
10/21/1949
EM876253
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所示。
圖1-7 主鍵和替代鍵的資料模型
主鍵屬性在矩形框中的橫線之上。你會注意到有兩個數字跟在鍵的縮寫名“AK”之後，第一個數是替代鍵的一組數字，第二個數表示替代鍵中的屬性順序。是以學生實體屬性的替代鍵有3個屬性。
學生名、學生姓氏和出生日期。這也是将要建立的替代鍵索引的順序，因為學生名在冒号之後有個“1”，學生姓氏是“2”，出生日期是“3”。
出勤實體的主鍵是學生編号和課程全稱，這兩個字段看上去可以組成一個有效的主鍵。注意出勤實體的兩個主鍵屬性跟着一個“FK”，這是外鍵，後面很快會講到。
是以，簡單地說，一個候選鍵由一個或多個屬性組成，能唯一地識别一個實體執行個體。可以選擇能最好地識别實體中每個記錄的候選鍵作主鍵，其他的候選鍵則作為替代鍵。由多個屬性組成的鍵叫作組合鍵。在實體層，候選鍵常常轉換成唯一索引。
代理鍵是表的唯一辨別符，常用來計數，通常具有固定長度，一般由系統自動生成，沒有含義。是以代理鍵沒有任何業務含義。（換句話說，不能看到一個月份辨別符為1，就認為它代表月份實體的執行個體值一月）。代理鍵應該對業務是不可見的，但應該保留在背景以允許更高效的檢索，也友善應用之間的內建。
代理鍵也是高效的。你已經見過主鍵可能是多個實體屬性的組合。相對于必須指定3～4個（或5～6個）屬性來定位你要查找的一條記錄，使用單個代理鍵更高效。代理鍵有利于內建，內建的目的是為了建立一個唯一一緻的資料版本。像資料倉庫這樣的應用常常要儲存不止一個應用或系統的資料。一個實體執行個體在每個源系統中都有不同的辨別，這些實體執行個體的相關性從公共的辨別符看起來不太明顯，這時用代理鍵可以記錄同一個實體執行個體的資訊之間的互相關系。
使用代理鍵時，總是先确定自然鍵。自然鍵是能唯一識别實體的方式，這是業務要考慮的，然後将自然鍵定義為替代鍵。例如，如表1-5所示，假定一個代理鍵是比課程全稱更高效的主鍵，我們可以為課程實體建立課程編号代理鍵，在自然鍵課程全稱上定義一個替代鍵，如圖1-8所示課程的值。
圖1-8 在自然鍵課程全稱上定義一個替代鍵
表1-5 課程實體中的課程
課程編号
1
2
3
教網球初學者學習這個遊戲的關鍵
4
在實體的“1”那側的關系我們叫作父實體，在“多（m）”那側的關系叫作子實體。當我們建立一個從父實體到子實體的關系時，父實體的主鍵就被複制為子實體的外鍵。外鍵是一個或多個屬性，提供到另外一個實體的連結（也有種遞歸關系的情況，同一個實體的兩個執行個體是相關的，一個連結連到同一個實體）。在實體層面，外鍵允許關系資料庫管理系統從一個表到另外一個表進行檢索。例如，如果我們需要知道一個有賬号的客戶，我們就想把客戶編号放在賬号實體中。賬号實體中的客戶編号就是客戶實體的主鍵。使用外鍵傳回到賬号表可以讓資料庫管理系統從特定的賬戶檢索或者從賬号到客戶進行檢索，再或者找到每個有賬号的客戶。類似地，資料庫可以從特定的客戶到賬号檢索以找到某個客戶的所有賬号。當兩個實體間的關系确定了之後，資料庫模組化工具就自動地建立了外鍵。
在學生/課程模型中，出勤實體中有兩個外鍵，學生編号外鍵指向學生實體中特定的學生，課程編号外鍵指向課程實體中特定的課程，如表 1-6所示。
表1-6 課程編号外鍵指向課程實體中特定的課程
通過檢視這些值，回憶起表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）字段。
有時候需要從表中快速檢索資料來回答業務的問題或滿足響應時間的要求。次鍵是需要頻繁通路和快速檢索的一個或多個屬性（如果有多個屬性，就叫作組合次鍵）。次鍵也就是衆所周知的非唯一索引或反向條目（inversion entry，IE）。次鍵不必唯一、穩定，也不必非空。例如，我們可以給學生表（Student）增加學生姓氏（Student Last Name）字段作為從鍵，以允許無論何時需要查詢學生姓氏（Student Last Name）都能快速檢索，如圖1-9所示。
圖1-9 給學生表（Student）增加學生姓氏（Student Last Name）字段作為從鍵
學生姓氏（Student Last Name）不唯一，因為可能有兩個人都叫Murphys；它是不穩定的，會随着時間變更；盡管很少發生，但也可能會有我們不知道某人名字的時候，是以，它可能為空。
子類型允許将公用屬性、相似的關系或相關的實體分組。某些概念非常相似或者為了展示一些例子往往可以用子類型。在出版行業，一個作者可能會寫多部紙質版（PrintVersion）的書和多本電子版圖書（eBooks），如圖1-10所示。
圖1-10 一個作者可以寫多部紙質版和多部電子版圖書的模型
每個作者（Author）可以寫一本或多本紙質版（PrintVersion）的書。
每個紙質版（PrintVersion）的書必須由一個作者（Author）寫。
每個作者（Author）可以寫一本或多本電子書（eBook）。
每本電子書（eBooks）必須由一個作者（Author）寫。
接下來，讓我們來介紹子類型，如圖1-11所示。
圖1-11 子類型
每本書（Title）必須由一個作者（Author）寫。
每本書（Title）可以是紙質版（PrintVersion）或電子版（eBook）。
每個紙質版（PrintVersion）的書都有一個書名（Title）。
每個電子書（eBook）有一個書名（Title）。
子類型關系隐含了一個規則，即超類型的所有關系和屬性也應用到每個子類型。是以，從作者（Author）到電子書（eBook）有一種隐性的關系，從作者（Author）到紙質版（PrintVersion）也是如此。titleName、subtitleName和titleRetailPrice屬于紙質版（PrintVersion），也屬于電子書（eBook）。注意每個子類型的主鍵是到超類型的外鍵，是以它們有相同的屬性。在這個例子中，titleISBN是一本書的辨別符。
子類型不僅減少了資料模型上的備援，也能透過表面上唯一的和獨立的概念進而更容易溝通它們的相似性。
在某些情況下，一個子類型可以有多個子類型集合；例如，一個人可能是一個孩子、青少年或成年人，獨立于這些分類，一個人還可能是男性或女性。
在某些情況下，超類型可以沒有任何子類型也能存在，而在另一些情況下，卻不可以。每個超類型必須有一個子類型執行個體。
例如，一個人可能是一個司機，或者不是；無論哪種情況他仍然是一個人。但一個銀行賬号就必須總是某種特定子類型的賬号。
本文摘自《資料模型記分卡》
<a href="http://www.epubit.com/book/detail?id=7FE1995A-05F7-45AE-9923-8F9386827EDC"></a>
《資料模型計分卡》
【美】Steve Hoberman（霍伯曼）
點選封面購買紙書
作為一本經典大師級著作，本書非常适合對資料模組化感興趣的讀者以及從事資料庫等相關工作的專業人士參考閱讀。通過閱讀本書，讀者将對記分卡這一經典理論有更加全面、深入的了解。
本書介紹了Steve Hoberman的經典理論——資料模型計分卡。全書分為3各部分，共計16章内容。第一部分介紹了資料模組化及驗證，包括資料模組化、資料模型品質、資料模型計分卡概述等；第二部分介紹了資料模型計分卡理論，通過10個重要理論來介紹相關的知識要點；第三部分介紹了如何使用計分卡驗證資料模型。
今日話題
就業調查：你的行業平均年薪大概是多少？年齡+年薪形式？截止時間3月12日17時，留言+轉發本活動到朋友圈，小編将選出1名讀者贈送異步新書一本。
延伸推薦
<a href="http://mp.weixin.qq.com/s?__biz=MzA3NTIzMzIxNQ==&mid=2652796138&idx=1&sn=b8387b4f03c997d395a5c22204c389fd&chksm=8499763ab3eeff2c022078c646ad2e1d9add10b9898a1609bf5c378d756102567da35e6f5528&scene=21#wechat_redirect" target="_blank">AI經典書單| 入門人工智能該讀哪些書？</a>
點選關鍵詞閱讀更多新書：
長按二維碼，可以關注我們喲
每天與你分享IT好文。
在“異步圖書”背景回複“關注”，即可免費獲得2000門線上視訊課程；推薦朋友關注根據提示擷取贈書連結，免費得異步圖書一本。趕緊來參加哦！
掃一掃上方二維碼，回複“關注”參與活動！
<a href="http://mp.weixin.qq.com/s?__biz=MjM5NzUzODI1Mg==&mid=2652540878&idx=1&sn=2183abfb7eb56ec5c7c1c3bb404669d5&chksm=bd365f6d8a41d67b461e483aa5a760178b099f2ada8eda905e6d768345ca51cb23a70c80c172&scene=21#wechat_redirect" target="_blank"></a>
<a href="http://mp.weixin.qq.com/s?__biz=MjM5NzUzODI1Mg==&mid=2652541846&idx=1&sn=c365b93616eeaa0479b4a8e5044cee16&chksm=bd3643358a41ca23587c3ad3d58f8f1c6d99f86d190cb8260bb01081d4fa770783d74f920087&scene=21#wechat_redirect" target="_blank"></a>
<a href="http://mp.weixin.qq.com/s?__biz=MjM5NzUzODI1Mg==&mid=2652541195&idx=1&sn=a1662cfe0dedc99121159c7b2647b974&chksm=bd3641a88a41c8befb8eb7583b777eaf131255e42328cb1c4dbdce24ffe8d259fd67aba9b34e&scene=21#wechat_redirect" target="_blank"></a>
<a href="http://mp.weixin.qq.com/s?__biz=MjM5NzUzODI1Mg==&mid=2652541116&idx=1&sn=9438ac3e1085af59a2c3e09e291fb23c&chksm=bd36401f8a41c9094c12cf0c500100a289d068afa97b7d6e925a17d2b020a460e7e612977747&scene=21#wechat_redirect" target="_blank"></a>
<a href="http://mp.weixin.qq.com/s?__biz=MjM5NzUzODI1Mg==&mid=2652540968&idx=1&sn=48891f452290c20e8113428980a3b568&chksm=bd36408b8a41c99dcc38a00b07db0dd4c1f55843329c47f2c4f0064d9b2c5db096cce049b9ba&scene=21#wechat_redirect" target="_blank"></a>
<a href="http://mp.weixin.qq.com/s?__biz=MjM5NzUzODI1Mg==&mid=2652542107&idx=1&sn=5d45a9f602fbbfe4bbb7f9d5c86237bc&chksm=bd3644388a41cd2e3a2a7676000c63c6aa58b242d7a6d80aa7975b19a07dab9d7612d7948308&scene=21#wechat_redirect" target="_blank"></a>
<a href="http://mp.weixin.qq.com/s?__biz=MjM5NzUzODI1Mg==&mid=2652540628&idx=1&sn=8eb0c03f03baad8c29e1ace16c6bfbed&chksm=bd365e778a41d761b2e190c20c3a779d56fca0efbaaf82315af8238a257a09767972e6d155c5&scene=21#wechat_redirect" target="_blank"></a>
<a href="http://mp.weixin.qq.com/s?__biz=MjM5NzUzODI1Mg==&mid=2652541335&idx=1&sn=03ce90ca766f23240be51d86400d3864&chksm=bd3641348a41c822217deeffd30b06f6125ed4d6cdc7ecec1e57bb0761a0ace058ce1f358864&scene=21#wechat_redirect" target="_blank"></a>
點選下方閱讀原文，檢視更多
<a href="https://mp.weixin.qq.com/s?__biz=MzA3NTIzMzIxNQ==&mid=2652796779&idx=1&sn=064efd06a099426f12ff30267eec4028&chksm=849975bbb3eefcad77b92ecf11e1a9c007a8b35be806558549f62c8b5aa54db7f58085e408df&mpshare=1&scene=1&srcid=0312r9IiAF1GCPJS6r5JIwnp#%23">閱讀原文</a>