nosql技術與傳統的關聯式資料庫相比，最明顯的轉變是拋棄了關係模型。nosql主要有四種模型：
前三種都是面向聚合的
2.1 聚合
關係模型：元組（行）是受限的結構：只能包含一系列的值，不能巢狀另外的元組和列表。
所有操作都以元組為目標，而且其返回值必須是元組。
面向聚合：是nosql運算元據時所用的單元，其結構比元組複雜，這種結構可以存放列表或巢狀其他記錄。
聚合是「領域驅動設計（ddd）」中的術語:把一組相互關聯的物件視為乙個整體單元來操作，這個單元叫聚合。一般通過原子操作更新聚合的值，並且在與資料儲存通訊時，也以聚合為單位。以聚合為單位來複製和分片比較自然。
2.1.1 關係模型和聚合模型示例
如果用聚合的話，如下圖：主要有兩個聚合：客戶和訂單。
客戶與訂單之間的關聯不在某個聚合結構內部，它們算是兩個聚合之間的關係。
這裡id為77的位址出現三次，在關係型中，id在三個地方用（如果要拿到位址的具體值，需要用join，優點是，位址變了，好維護。）；在聚合中，位址的值被複製了三分（這樣就不用join表了，但是缺點是：位址改的話，要改很多地方）。
聚合中，產品名稱直接寫入訂單項。這種做法在聚合模型中更常見，因為在資料互動的時候儘量減少所需訪問聚合的個數（個人覺得這個和資料庫中冗餘列的設計思想類似，缺點是一樣的： 如果產品名稱發生變化了，如何去更新冗餘列）。
其實還有另外一種方式畫出聚合的邊界，就是把客戶下的全部訂單放到客戶聚合中：這樣就只有乙個聚合了。
對於如何劃分聚合沒有標準答案，取決於你想如何處理資料：如果想一次性訪問客戶全部訂單，那就放到乙個大的聚合裡；反之，
2.1.2 面向聚合的影響
聚合的邊界很難劃定。
某種聚合模型，在有些場景下，很合適，在另外的場景下可能不合適。
因此在運算元據時，如果沒有佔主導地位的結構，採用聚合無知的關係型資料結構可能更適合。
聚合模型適合在集群上執行（聚合在理想情況下，代表乙個對內高內聚，對外和其他聚合低耦合的結構，這樣，每乙個聚合獨自部署在乙個節點上，和其他節點的聚合不關聯，這樣可以降低分布式事務類的操作。）
一般，面向聚合的資料庫不支援跨越多個聚合的acid事務。取而代之的是，它每次只能在乙個聚合結構上執行原子操作。如果想按照原子的方式操作多個聚合，就必須自己組織應用程式的**。在實際中，大多數原子操作都可以侷限於某個聚合結構內部。
2.2 健值資料模型與文件資料模型
二者都面向聚合（
面向聚合的實質就是可以巢狀包含，而sql資料庫的列不能巢狀包含，也不能包含列表，所有sql資料庫必須用外來鍵去關聯，也就是用join，面向聚合的資料庫的理想效果是沒有join，在聚合內部包含所有的資料！
）
兩種模型的區別是：健值的聚合不透明，文件的聚合是透明的，其他的都很相似。健值的value可以是任意值，而文件的結構相對要嚴格一些，文件型的nosql可以訪問特定的列，而健值資料庫的value是個整體，不夠靈活。（也就是：健值資料庫，要訪問聚合內容，只能通過健來查詢。而文件型資料庫，則可以用聚合中的字段查詢，可以只獲取一部分聚合，而不用獲取全部內容。此外，資料庫還可以按照聚合內容建立索引）。
2.3 列族儲存
"列儲存資料庫"：大部分資料庫以行為單元儲存資料，尤其是在需要提高寫入效能的場合更如此。然而，有些情況下寫入操作執行得很少，但是經常需要一次性讀取若干行中的很多列。這種情況下，將所有行的某一組列作為基本資料儲存單元，效果會更好。
「列族模型」： 可以看作是兩級聚合，第一級類似健值儲存，第二級可以包含更加詳細的資訊。
列族資料庫將列組織為列族。每一列都必須是某個列族的一部分，而且訪問資料的單元也得是列。這樣設計的前提是，某個列族中的資料經常需要一起訪問。
列族可以包含超列，也就是列裡面可以巢狀列。
2.4 總結
三種nosql的共同點是：都是用聚合這一概念。聚合都有乙個索引鍵。集群上執行時，聚合是中心環節，資料庫保證聚合內的資料放在通過乙個節點上。聚合還是更新操作的最小資料單元，對事務控制來說，以聚合為操作單元，正好合適。
三者差別：鍵值資料模型的聚合是不透明的整體；文件模型的聚合是透明的，可以查詢獲得一部分資料。不過，文件沒有模式，因此想優化儲存並獲取聚合中的部分內容時，資料庫不太好調整文件結構。
NoSQL聚合資料模型
聚合資料模型的特點就是把經常訪問的資料放在一起 聚合在一塊 這樣帶來的好處很明顯，對於某個查詢請求，能夠在與資料庫一次互動中將所有資料都取出來 當然，以這種方式儲存不可避免的會有重複，重複是為了更少的互動 選用nosql資料庫，首要的工作就是設計鍵名及存放的資料 設計的原則是儘量減少所需要訪問的聚合...
第二章 資料模型和查詢語言
本章開始介紹了關係型資料庫，非關係型資料庫，圖模型資料。首先解釋了關係模型和文件模型是什麼，然後指出了從資料庫模型到應用程式物件模型之間的不匹配 稱為物件關係不匹配 我們通常使用 orm 框架來解決從資料庫模型到程式物件的轉換。接著引出了一對多 多對 一 多對多關係以及查詢的區域性性。和 json ...
第二章 建立資料模型 ER模型 完整性約束
在進行資料庫建立之前，我們需要對實際問題進行模型的建立，我們需要將現實世界中事物和事物的性質以及事物之間的聯絡抽象出來，而這一過程最常用的手段就是e r模型設計 本章內容最重要的兩件事就是掌握 er模型的設計和er模型向關係模型的轉化 幕布鏈結 稍微區分下概念模型和資料模型，兩者本質上都是對現實世界...