在本系列關於360°檢視的第一部分中，我們討論瞭如何修改資料的思維模型以便於在MongoDB中建立一個360°檢視。我們的示例場景是一家同時在網際網路和實體店中銷售產品的零售商。先回顧一下，以前的資料模型也許是這樣的：
傳統思維模型
（檢視大圖）
我們推薦的新模型是這樣的：
MongoDB思維模型
（檢視大圖）
記住這些，我們將討論實現這個新模型的一些細節。
360°檢視模式
在本系列的第一篇部落格中，我們提出了一些關於如何使用360°檢視需要回答的問題，然後我們基於這些問題設計了一個資料模型。在我們的示例中，使用者和產品模型也許會是這樣的：
文件結構
非常直接明瞭的文件結構，這裡有一些建議：
- 使用陣列儲存多重關係：單個使用者有多個位置，並且有可能附屬於多個組織。
- 使用有意義的、靈活的方式儲存資料。在這裡，我們不使用一個“家庭住址”的欄位和一個“工作地址”的欄位，而是使用一個單一欄位用於儲存所有相關地址的陣列。
- 可使用標籤描述一個使用者。例如，你可以使用“前10%”或者“存在潛逃風險”來標記一個顧客，從而基於這些標籤採取行動。
- 行為陣列是一個泛型容器，它允許配置檔案管理相關物件並且在合適的上下文環境中使用。這意味著什麼？例如，它可以儲存銷售或服務代表在他們的互動中最需要的資訊。
- 在使用者文件中，我們在產品陣列記憶體儲購買及互動細節。
- 但是，我們也可以鏈出到產品文件以獲得所有的產品細節。
- 相同地，產品文件也也可以儲存評論，然後將其鏈出到進行評論的顧客。
在JSON中，文件結構是什麼樣的呢？下面是一個使用者文件的案例。
你可以很容易清晰地看出文件的主要部分：使用者後設資料、行為以及產品（就像圖表中列出的）。
好的，你已經構建了一個工作原型。但是，還記得我們在第一部分中提到的構建原型然後快速迭代嗎？假設你想向第一個版本新增情感分析。沒問題，通過使用動態模式，改進你的資料模型將變得非常容易。下面是你可以採用整合一些情感分析的第一個版本。
文件結構+情感
在這個圖中，我們已經向使用者文件中新增了兩個欄位：一個用於個人情感（使用者一般的情感傾向）、一個用於對於你公司的特定情感。在產品文件中，我們使用一個陣列來儲存關於特定互動的更多細節。
再一次，使用JSON。下面是新的使用者文件。
正如你看到的，第一步實現非常簡單。我們在一個較高的層次總結了情感：客戶要麼是友好的（1）、中性的（0）或者是不友好的（-1），要麼喜歡我們（1）、沒有意見（0）或者是及其討厭我們（-1）。同樣地，隨著向情感分析模組新增更多細節以及評分規則，你可以容易地改進MongoDB中的儲存方式。
總結一下
接下來我們回到第一部分中的一些問題。當然，你設計模式的特定方法依賴於你的資料。但是，你應該經常回顧那些引導性的問題，從而設計出能夠對你自己的使用者案例有意義的東西。如果你已經閱讀完上面所有內容並且開始產生疑惑，或者如果你只是跳讀到這裡來看總結，你應該記好這兩個設計360°檢視的原則：
- 你360°檢視的中心是什麼？是使用者？還是產品？或者，和我們示例中一樣，兩個都是——伴隨著合適的連結及嵌入。
- 針對你的資料，你提出了什麼問題？訪問模式應該驅動資料模型。一旦你在MongoDB上構建了你的360°檢視，你如今不能回答的問題將會變成你的查詢，你的資料模型也應該為它們進行優化。
當然，這裡還有另外一個大問題並沒有在前兩個部分得到解決：資料目前存放在各個地方，你如何真正地把它匯入MongoDB？繼續閱讀即將到來的第三部分，尋找這個問題的一些答案。
在等待的同時，你可以下載白皮書以瞭解更多關於MetLife如何使用MongoDB構建一個360°顧客檢視的案例