數(shù)據(jù)模型不僅對軟件編寫方式，還對如何思考待解決的問題都有影響。

大多數(shù)應(yīng)用程序都是通過疊加一層層的數(shù)據(jù)模型構(gòu)建而來 。因此每層都面臨問題：如何將其用下一層表示？如：

1. 作為一名開發(fā)，觀測現(xiàn)實世界（包括人員、組織 、貨物 、行為、資金流動、傳感器等） ，通過對象或數(shù)據(jù)結(jié)構(gòu)及操作這些數(shù)據(jù)結(jié)構(gòu)的API來對其建模，這些數(shù)據(jù)結(jié)構(gòu)往往特定于該應(yīng)用

2. 當(dāng)需要存儲這些數(shù)據(jù)結(jié)構(gòu)時，可采用通用數(shù)據(jù)模型（例如JSON XML文檔、關(guān)系數(shù)據(jù)庫中的表或圖模型）來表示

3. DBA接著決定用何種內(nèi)存、磁盤或網(wǎng)絡(luò)的 節(jié)格式來表示上述JSON/XML/關(guān)系/圖形數(shù)據(jù)。數(shù)據(jù)表示需要支持多種方式的查詢詢、搜索、操作和處理數(shù)據(jù)（系列三時介紹）

4. 在更下一層，硬件工程師則需要考慮用電流、光脈沖、磁場等來表示字節(jié)

復(fù)雜的應(yīng)用程序可能會有更多的中間層：如基于API來構(gòu)建上層API ，但基本思想一樣：每層都通過提供一個簡潔的數(shù)據(jù)模型來隱藏下層的復(fù)雜性。這些抽象機制使得不同團隊可高效協(xié)作，例如數(shù)據(jù)廠商的工程師和使用數(shù)據(jù)庫的開發(fā)很好的協(xié)作。

數(shù)據(jù)模型有很多類型，每種都有其最佳實踐?？紤]到數(shù)據(jù)模型對其上的軟件應(yīng)用有巨大影響（ 哪些可以做、不能做），因此需慎重選擇適合業(yè)務(wù)的數(shù)據(jù)模型。

本本會介紹一些用于數(shù)據(jù)存儲和查詢的通用數(shù)據(jù)模型 （上面提到的第2點）。尤其，將比較關(guān)系模型 、文檔模型和一些基于圖的數(shù)據(jù)模型。還討論多種查詢語言并比較使用場景。

1.關(guān)系模型與文檔模型

如今SQL是最著名的數(shù)據(jù)模型 ，它基于Edgar Codd 1970年提出的關(guān)系模型：數(shù)據(jù)被組織成關(guān)系（relations），在SQL中稱為表（table），其中每個關(guān)系都是元組（tuples）的無序集合（SQL中稱為行）。

關(guān)系模型曾經(jīng)只是理論建議， 很多人懷凝它是否能被高效實現(xiàn)。但20世紀(jì)80年代中期，關(guān)系數(shù)據(jù)庫管理系統(tǒng)（ RDBMS ）和SQL已成為大多數(shù)需要存儲、查詢具有某種規(guī)則結(jié)構(gòu)的數(shù)據(jù)的首選工具。關(guān)系數(shù)據(jù)庫的主導(dǎo)地位持續(xù)至今已有三十多年，算得上是計算機史的不朽傳奇。

關(guān)系數(shù)據(jù)庫核心在于商業(yè)數(shù)據(jù)處理， 20世紀(jì)60年代和70年代主要運行在大型計算機。如今來看，用例很常見，主要是：

• 事務(wù)處理（包括輸入銷售和銀行交易、訂票 、倉庫庫存 ）
• 批處理（例如客戶發(fā)票、工資單 、報告

當(dāng)時的其他數(shù)據(jù)庫迫使開發(fā)人員考慮數(shù)據(jù)的內(nèi)部表示。關(guān)系模型的目標(biāo)就是將實現(xiàn)細節(jié)隱藏在更簡潔的接口下。20世紀(jì)70年代和80代初期，網(wǎng)絡(luò)模型和層次模型是兩個主要選擇，但最終關(guān)系模型主宰該領(lǐng)域。

對象數(shù)據(jù)庫曾在20世紀(jì)80年代后期和90年代初期起起伏伏。XML數(shù)據(jù)庫則出現(xiàn)在21世紀(jì)初，但也僅限于利基市場。關(guān)系模型的競爭者都曇花一現(xiàn)。

如今關(guān)系數(shù)據(jù)庫超出它們最初的商業(yè)數(shù)據(jù)處理范圍，推廣到各種案例：在線發(fā)布、論壇、社

交網(wǎng)絡(luò)、電子商務(wù) 游戲、 SaaS。

2.NoSQL

21世紀(jì)，NoSQL成為推翻關(guān)系模式主導(dǎo)地位的有力競爭者。NoSQL名字不恰當(dāng)，因為它其實并不代表具體技術(shù)，最初只是作為吸引人眼球的Twitter標(biāo)簽頻頻出現(xiàn)在2009年的開源、分布式及非關(guān)系數(shù)據(jù)庫的見面會?，F(xiàn)在很多新興數(shù)據(jù)庫系統(tǒng)總是會打上NoSQL標(biāo)簽，而其含義也已經(jīng)被逆向重新解釋為“不僅僅是SQL”。

采用NoSQL數(shù)據(jù)庫的驅(qū)動因素：

• 比關(guān)系數(shù)據(jù)庫更好的擴展性需求包括支持超大數(shù)據(jù)集或超高寫入吞吐量
• 普遍偏愛免費和開源軟件而非商業(yè)數(shù)據(jù)庫產(chǎn)品
• 關(guān)系模型不能很好支持一些特定查詢
• 對關(guān)系模式某些限制性感到沮喪，渴望更具動態(tài)和表達力的數(shù)據(jù)模型

不同應(yīng)用程序有不同需求，沒有銀彈技術(shù)，可預(yù)見的將來，關(guān)系數(shù)據(jù)庫仍將繼續(xù)與各種非關(guān)系數(shù)據(jù)存儲一起使用，這種思路有時也被稱為混合持久化。

3.對象－關(guān)系不匹配

現(xiàn)在大多數(shù)應(yīng)用開發(fā)都采用OOP編程語言 ，由于兼容性問題，普遍對SQL數(shù)據(jù)模型抱怨：若數(shù)據(jù)存儲在關(guān)系表，則應(yīng)用層代碼中的對象與表、行和列的數(shù)據(jù)庫模型之間需要一個笨拙的轉(zhuǎn)換層。模型之間的脫離有時被稱為阻抗失諧（電子學(xué)術(shù)語：每個電路的輸入和輸出都有 一定的阻抗（交流電阻） 一個電路的輸出連接到另一個電路的輸入時，若兩個電路的輸出和輸入阻抗匹配，則連接上的功率傳輸將被最大化，阻抗不匹配會導(dǎo)致信號反射和其他故障）。

像Hibernate對象關(guān)系映射（ORM） 框架減少了此轉(zhuǎn)換層的樣板代碼，但也無法完全隱藏兩個模型之間差異。

簡歷案例

如下展示了關(guān)系模式表示LinkedIn簡歷：

圖一

整個簡歷可通過唯一標(biāo)識符user id標(biāo)識。像first_name、last_name字段在每個用戶中只出現(xiàn)一次，所以建模為users表中的列。而大多數(shù)人在他們的職業(yè)中有一個以上工作，且可能有多個教育階段和任意數(shù)量的聯(lián)系信息。用戶與這些項目之間是一對多，可用多種方式表示：

• 在傳統(tǒng)SQL模型（ SQL1999之前）， 最常見的規(guī)范化表示是將職位、教育和聯(lián)系信息放在單獨表，并使用外鍵引用users表。
• 之后的SQL標(biāo)準(zhǔn)增加了對結(jié)構(gòu)化數(shù)據(jù)類型和XML數(shù)據(jù)的支持。這允許將多值數(shù)據(jù)存儲在單行內(nèi)，井支持在這些文檔中查詢和索引。Oracle、DB2、SQLServr、PostgreSQL都不同程度支持這些功能。一些數(shù)據(jù)庫也支持JSON，如DB2、MySQL和PostgreSQL。
• 將工作、教育和聯(lián)系信息編碼為JSON或XML，存儲在數(shù)據(jù)庫的文本列，并由應(yīng)用程序解釋其結(jié)構(gòu)和內(nèi)容。對于此方法，通常不能使用數(shù)據(jù)庫查詢該編碼列中的值。

簡歷這樣的數(shù)據(jù)結(jié)構(gòu)，主要是個自包含的文檔（ document ），因此用JSON表示非常合適：

面向文檔的數(shù)據(jù)庫（如MongoDB）都支持該數(shù)據(jù)模型。

有人覺得JSON模型減少了應(yīng)用程序代碼和存儲層之間的阻抗失配。然而，JSON作為數(shù)據(jù)編碼格式也存在問題。缺乏模式常常被認(rèn)為是一個優(yōu)勢~

JSON表示比關(guān)系模式表示的多表模式具有更好的局部性。若要在關(guān)系模式中讀取一份簡歷，則：

? 要么執(zhí)行多個查詢（通過user_id查詢每個表）

? 要么在users表及其從屬表之間執(zhí)行混亂的多路聯(lián)結(jié)

而JSON表示方法，所有的相關(guān)信息都在一個地方，一次查詢即可。

用戶簡歷到用戶的職位、教育歷史和聯(lián)系信息的 對多關(guān)系，意味著數(shù)據(jù)存在樹狀結(jié)構(gòu)，JSON表示將該樹結(jié)構(gòu)顯式化，一對多的關(guān)系形成樹狀結(jié)構(gòu)：

4.多對一、多對多

上面案例的region_id、indu0stry_id 定義為ID ，而非純文本字符串，如"Greater Seattle Area Philanthropy"，why？

若用戶界面是可以輸入地區(qū)或行業(yè)的自由文本字段，則將其存儲為純文本字符串更有意義。但擁有地理區(qū)域和行業(yè)的標(biāo)準(zhǔn)化列表，并讓用戶從下拉列表或自動填充器中進行選擇更有優(yōu)勢：

• 所有簡歷保持樣式和輸入值一致。
• 避免歧義（例如，若存在一些同名城市）
• 易于更新：名字只保存一次，因此，若需要改變（例如，由于政治而更改城市名稱），易全面更新。
• 本地化支持：當(dāng)網(wǎng)站被翻譯成其他語，標(biāo)準(zhǔn)化的列表方便本地化，因此地區(qū)和行業(yè)可以用查看者的母語顯示。
• 更好的搜索支持：例如，搜索華盛頓州的慈善家可匹配到過個簡歷，因為地區(qū)列表可以將西雅圖屬于華盛頓的信息編碼進來（而從“大西雅圖地區(qū)”字符串中并不能看出西雅圖屬于華盛頓）。

無論是存儲ID or 文本字符串，都涉及內(nèi)容重復(fù)問題：

• 使用ID ，對人類有意義的信息（例如慈善這個詞）只存儲在一個地方，引用它的所有內(nèi)容都使用ID（ID只在數(shù)據(jù)庫中有意義。
• 直接存儲文本時， 則使用它的每條記錄中都保存了一份這樣的可讀信息。

使用ID的好處：對人類沒有任何直接意義，所以永遠不需要直接改變。即使ID標(biāo)識的信息變化，他也能繼續(xù)保持不變。任何對人類有意義的東西都可能變更。若這些信息被復(fù)制 ，則所有副本都得更新。這會導(dǎo)致更多寫開銷，且存在數(shù)據(jù)不一致風(fēng)險。消除這種重復(fù)，也正是數(shù)據(jù)庫規(guī)范化的核心思想。

而這種數(shù)據(jù)規(guī)范化需要表達多對一關(guān)系（許多人生活在同一地區(qū)， 在同一行業(yè)工作），這并不是很適合文檔模型：

• 關(guān)系數(shù)據(jù)庫由于支持聯(lián)結(jié)操作，可方便通過ID引用其他表中的行
• 文檔數(shù)據(jù)庫中， 一對多的樹狀結(jié)構(gòu)不需要聯(lián)結(jié)，支持聯(lián)結(jié)通常也很弱

若數(shù)據(jù)庫本身不支持聯(lián)結(jié)，則必須在應(yīng)用程序代碼中，通過對數(shù)據(jù)庫進行多次查詢來模擬聯(lián)結(jié)（對于上述例子，地區(qū)和行業(yè)的列表很小且短期內(nèi)不大可能變化， 應(yīng)用程序可將其緩存在內(nèi)存。但無論如何，聯(lián)結(jié)工作其實從數(shù)據(jù)庫轉(zhuǎn)移到了應(yīng)用層。

即使應(yīng)用程序的初始版本非常適合采用無聯(lián)結(jié) 文檔模型 但隨著應(yīng)用支持越來越多功能，數(shù)據(jù)也變更互聯(lián)一體化。例如，考慮可能對簡歷進行的變更：

• 組織和學(xué)校作為實體 前面定義中， organization（用戶所在公司）、school_name （用戶所在學(xué)校 ）都是字符串。也許他們應(yīng)該定義為實體的引用？然后每個組織、學(xué)校或大學(xué)都擁有自己的網(wǎng)頁 (logo 、新聞發(fā)布源等） 。每個簡歷都能鏈接到相關(guān)組織和學(xué)校，包括他們的logo和其他信息
• 推薦假設(shè)添加這樣一個新功能：一個用戶能推薦其他用戶。推薦顯示在被推薦者的簡歷上，并附上推薦人的姓名和照片。若推薦人更新了他們的照片， 他們所寫的任何推薦都需顯示新照片。因此，推薦需要有一個到作者簡歷的引用。

如下圖展示了這些新功能如何定義多對多。每個虛線矩形框數(shù)據(jù)可組織為一個文檔，但指向組織、學(xué)校及其他用戶的關(guān)系則需表示為引用，并且在查詢時，需要聯(lián)結(jié)操作。多對多關(guān)系來擴展簡歷：

? ?