點擊關注 異步圖書，置頂公眾號

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

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

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

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

• 一個客戶可以有一個或多個賬號。

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

一旦我們將這些需求寫成了數據模型文檔，就可以跟應用開發所涉及的業務和信息技術（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　實體類的定義

實體的實例是指特定實體的發生或實體的值。例如，表單就是一個實體，它的表頭的每個字段表示每個實體要記錄的信息。每個有實際值的表單行表示一個實體實例。“客戶”實體可能會有多個有不同名字的客戶實例，如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類型。

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所示。

圖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）中的參照關系。

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　學生表

表1-3　出勤表

表1-4　課程表

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

對于學生實體，學生編號看上去是個有效的候選鍵。有 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.6　代理鍵

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

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

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

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

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

1.7　外鍵

在實體的“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）字段。

1.8　次鍵

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

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

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

1.9　子類型

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

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

• 每個作者（Author）可以寫一本或多本紙質版（PrintVersion）的書。

• 每個紙質版（PrintVersion）的書必須由一個作者（Author）寫。

• 每個作者（Author）可以寫一本或多本電子書（eBook）。

• 每本電子書（eBooks）必須由一個作者（Author）寫。

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

圖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）中的類圖，就可以指定準確的基數。

本文摘自《數據模型記分卡》

延伸推薦

點擊下方閱讀原文，查看更多