關係數據庫（Relational Database）是建立在關係模型基礎上的數據庫，藉助於幾何代數等數學概念和方法來處理數據庫中的數據。所謂關係模型是一對一、一對多或者多對多等關係，常見的關係型數據庫有 Oracle、SQL Server、DB2、MySQL 等。
而文檔型數據庫是一種非關係型數據庫，非關係型數據庫（Not Only SQL，NoSQL）正好與關係型數據庫相反，它不是建立在“關係模型”上的數據庫。文檔型數據庫的典型代表是 MongoDB。
我們本課時的面試題是，關係型數據庫和文檔型數據庫有什麼區別？
典型回答
關係型數據庫屬於早期的傳統型數據庫，它有着標準化的數據模型，以及事務和持久化的支持、例如，關係型數據庫都會支持的 ACID 特性，也就是原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）和持久性（Durability），具體含義如下。
- 原子性（Atomicity）：是指一個事務中的所有操作，要麼全部完成、要麼全部不完成，不會存在中間的狀態。也就是說事務在正常的情況下會執行完成；異常的情況下，比如在執行的過程中如果出現問題，會回滾成最初的狀態，而非中間狀態。
- 一致性（Consistency）：是指事務從開始執行到結束執行之間的中間狀態不會被其他事務看到。
- 隔離性（Isolation）：是指數據庫允許多個事務同時對數據進行讀寫或修改的能力，並且整個過程對各個事務來說是相互隔離的。
- 持久性（Durability）：是指每次事務提交之後都不會丟失。
關係型數據庫一般遵循三範式設計思想，具體內容如下。
第一範式（The First Normal Form，1NF）：要求對屬性的原子性，也就是說要求數據庫中的字段需要具備原子性，不能再被拆分。
比如，用戶表中有字段：用戶 ID、用戶名、電話；而其中電話又可以分爲：家庭電話和移動電話等。因此，此表不符合第一範式，如下圖所示：
第二範式（The Second Normal Form，2NF）：例如訂單詳情表有這些字段：訂單 ID、產品 ID、產品名稱、產品單價、折扣。其中，訂單 ID 和產品 ID 爲聯合主鍵，但這個表中的產品名稱和產品單價兩個字段只依賴產品 ID，和訂單 ID 就沒有任何關係了，因此這個表也不符合第二範式。
我們可以把原來的訂單表拆分爲訂單表和產品表，其中訂單表包含：訂單 ID、產品 ID、折扣等字段；而產品表包含：產品 ID、產品名稱、產品單價等字段。這樣就消除了產品名稱和產品單價多次重複出現的情況了，從而避免了冗餘數據的產生。.
第三範式（The Third Normal Form，3NF）：想要滿足第三範式必須先滿足第二範式，第三範式要求所有的非主鍵字段必須直接依賴主鍵，且不存在傳遞依賴的情況。
例如，有一個學生表中包含了：學生 ID、姓名、所在學院 ID、學院電話、學院地址等字段。這個表的所有字段（除去主鍵字段）都完全依賴唯一的主鍵字段（學生 ID），所以符合第二範式。但它存在一個問題，學院電話、學院地址依賴非主鍵字段學院 ID，而不是直接依賴於主鍵，它是通過傳遞才依賴於主鍵，所以不符合第三範式。
我們可以把學生表分爲兩張表，一張是學生表包含了：學生 ID、姓名、所在學院 ID 等字段；另一張爲學院表包含了：學院 ID、學院電話、學院地址等字段，這樣就滿足第三範式的要求了。
可以看出，使用三範式可以避免數據的冗餘，而且在更新表操作時，只需要更新單張表就可以了。
但隨着互聯網應用的快速發展，我們需要應對日益複雜且快速迭代的數據庫，以應對互聯網快速發展的趨勢，於是誕生了以 MongoDB 爲代表的文檔型數據庫。它提供了更高效的讀/寫性能以及可自動容災的數據庫集羣，還有靈活的數據庫結構，從而給系統的數據庫存儲帶來了更多可能 性。
當然 MongoDB 的誕生並不是爲了替代關係型數據庫，而是爲系統的快速開發提供一種可能性，它和關係型數據庫是一種互補的關係，可供開發者在不同的業務場景下選擇相對應的數據庫類型。
考點分析
本課時的面試題考察的是面試者對數據庫整體概念的理解與區分，這個問題看似簡單，但包含着衆多小的知識點，面試者需要真正的理解關係型數據庫和非關係型數據庫以及文檔型數據庫之間的區別才能靈活應對。與之相關的面試題還有：
- 非關係型數據庫和文檔型數據庫有什麼區別？
- MongoDB 支持事務嗎？
知識擴展
非關係型數據庫 VS 文檔型數據庫
非關係型數據和文檔型數據庫屬於包含關係，非關係型數據包含了文檔型數據庫，文檔型數據庫屬於非關係型數據。
非關係型數據通常包含 3 種數據庫類型：文檔型數據庫、鍵值型數據庫和全文搜索型數據庫，下面分別來看每種類型的具體用途。
1. 文檔型數據庫
文檔型數據庫以 MongoDB 和 Apache CouchDB 爲代表，文檔型數據庫通常以 JSON 或者 XML 爲格式進行數據存儲。
以 MongoDB 爲例，它是由 C++ 編寫的一種面向文檔的數據庫管理系統，在 2007 年 10 月 由 10gen 團隊所開發，並在 2009 年 2 月首度推出。MongoDB 是以二進制 JSON 格式存儲數據的，MongoDB 對 JSON 做了一些優化，它支持了更多的數據類型，這種二進制存儲的 JSON 我們也可以稱之爲 BSON（Binary JSON）。
BSON 具備三個特點：輕量、可遍歷以及高效，它的缺點是空間利用率不是很理想。MongoDB 使用 BSON 進行存儲的另一個重要原因是 BSON 具備可遍歷性。
MongoDB 存儲結構示例如下：
{"_id":ObjectId(“57ce2d4cce8685a6fd9df3a3"),"name":"老王","email":['[email protected]','[email protected]']}
其中，“_id”爲 MongoDB 默認的主鍵字段，它會爲我們生成一起全局唯一的 id 值，並且這個值在做數據分片時非常有用。
文檔型數據庫的使用場景如下。
- 敏捷開發，因爲 MongoDB 擁有比關係型數據庫更快的開發速度，因此很多敏捷開發組織，包括紐約時報等都採用了 MongoDB 數據庫。使用它可以有效地避免在增加和修改數據庫帶來的溝通成本，以及維護和創建數據庫模型成本，使用 MongoDB 只需要在程序層面嚴格把關就行，程序提交的數據結構可以直接更新到數據庫中，並不需要繁雜的設計數據庫模型再生成修改語句等過程。
- 日誌系統，使用 MongoDB 數據庫非常適合存儲日誌，日誌對應到數據庫中就是很多個文件，而 MongoDB 更擅長存儲和查詢文檔，它提供了更簡單的存儲和更方便的查詢功能。
- 社交系統，使用 MongoDB 可以很方便的存儲用戶的位置信息，可以方便的實現查詢附近的人以及附近的地點等功能。
2. 鍵值型數據庫
鍵值數據庫也就是 Key-Value 數據庫，它的典型代表數據庫是 Redis 和 Memcached，而它們通常被當做非持久化的內存型數據庫緩存來使用。當然 Redis 數據庫是具備可持久化得能力的，但是開啓持久化會降低系統的運行效率，因此在使用時需要根據實際的情況，選擇開啓或者關閉持久化的功能。
鍵值型數據庫以極高的性能著稱，且除了 Key-Value 字符串類型之外，還包含一些其他的數據類型。以 Redis 爲例，它提供了字符串類型（String）、列表類型（List）、哈希表類型（Hash）、集合類型（Set）、有序集合類型（ZSet）等五種最常用的基礎數據類型，還有管道類型（Pipeline）、地理位置類型（GEO）、基數統計類型（HyperLogLog）和流類型（Stream），並且還提供了消息隊列的功能。
此數據庫的優點是性能比較高，缺點是對事務的支持不是很好。
3. 全文搜索型數據庫
傳統的關係型數據庫主要是依賴索引來實現快速查詢功能的，而在全文搜索的業務下，索引很難滿足查詢的需求。因爲全文搜索需要支持模糊匹配的，當數據量比較大的情況下，傳遞的關係型數據庫的查詢效率是非常低的；另一個原因是全文搜索需要支持多條件隨意組合排序，如果要通過索引來實現的話，則需要創建大量的索引，而傳統型數據庫也很難實現，因此需要專門全文搜索引擎和相關的數據庫才能實現此功能。
全文搜索型數據庫以 ElasticSearch 和 Solr 爲代表，它們的出現解決了關係型數據庫全文搜索功能較弱的問題。
MongoDB 事務
MongoDB 在 4.0 之前是不支持事務的，不支持的原因也很簡單，因爲文檔型數據庫和傳統的關係型數據庫不一樣，不需要滿足三範式。文檔型數據庫之所以性能比較高的另一個主要原因，就是使用文檔型數據庫不用進行多表關聯性查詢，因爲文檔型數據庫會把相關的信息存放到一張表中。因此，無需關聯多表查詢的 MongoDB，在這種情況下的查詢性能是比較高的。
把所有相關的數據都放入一個表中，這也是 MongoDB 之前很長一段時間內不支持事務的原因，它可以保證單表操作的原子性，一條記錄要麼成功插入，要麼插入失敗，不會存在插入了一半的數據。因此，在這種設計思路下，MongoDB 官方認爲“事務功能”的實現沒有那麼緊迫。
但在 MongoDB 4.0 之中正式添加了事務的功能，並且在 MongoDB 4.2 中實現了分佈式事務的功能，至此 MongoDB 開啓了支持事務之旅。
小結
本課時我們首先講了關係型數據庫的 ACID 特性以及設計時需要遵循的三範式設計思想；然後介紹了以 MongoDB 爲代表的文檔型數據庫與關係型數據庫的不同；最後還講了 MongoDB 的事務功能，以及文檔性數據庫與非關係型數據庫的關係，希望本課時的內容對你有幫助。