開始資料模型設計，一般通過分析業務需求就可以提取出需要建立的節點和關系，然後使用節點和關系畫出框圖，即可完成資料模型的設計。下面通過兩個執行個體來簡要說明資料模型的設計過程。
在一個通路控制系統中，它的業務需求可以簡單地描述為：怎樣控制一個使用者的通路權限。即一個使用者登入系統後，他對系統的哪些資源具有通路權限。通過分析和結合以往的經驗，我們可能需要四個節點，分别是使用者、部門、角色和資源；三個關系，分别是隸屬、擁有和權限。這樣，我們就可以畫出下圖的使用者通路控制資料模型。
這個資料模型是否合理、是否符合業務需求？我們可以用這個簡單框圖模拟一下業務流程，簡單地測試一下它的合理性。首先看看從這個框圖中能不能讀出類似這樣的資訊：隸屬于一個部門的一個使用者擁有哪些角色就能對哪些資源具有通路權限。如果可以，就可以說明這個模型設計是可行的。
很明顯，這個資料模型設計的業務流程是通順的。因為對于這個框圖，我們可以這樣讀出它的流程：部門具有一些隸屬使用者，使用者擁有一些角色，角色對一些資源具有通路權限。
有了這個資料模型之後，就可以對節點和關系進行模組化了。在模組化中再來确定節點和關系的屬性，例如，使用者節點可能需要使用者名、密碼、性别、郵箱、建立日期等屬性，同時還要确定關系的對等方式，例如，是一對一、一對多還是多對多等。對于這個執行個體來說，使用者與部門的隸屬關系是多對一關系，使用者與角色的擁有關系和角色與資源的權限關系都是多對多關系。
如果覺得上面的資料模型簡單了一點，那麼接下來我們使用一個業務需求比較複雜的執行個體來試一試，比如一個購物網站。購物網站的業務需求大概具有這樣的流程：首先商家上架了商品，然後顧客浏覽或查找商品，顧客找到自己需要的商品之後，确定購買，接着使用他的賬戶支付款項，商家收到貨款後，将商品快遞給顧客，進而完成一筆交易。根據這個業務流程，我們畫出下圖的資料模型。
使用這個資料模型，我們同樣也可以先測試一下，即看一看它能不能通順地讀出一個購物網站的基本流程。比如完成一個完整的購物流程，首先是商家的庫存要上架商品，然後是顧客購買商品，即商品出售形成訂單；接下來是顧客結算訂單，使用賬戶付款，形成支付記錄，同時商家賬戶收到款項，并且訂單進入發貨狀态，同時生成物流記錄；這時候，商家的庫存辦理商品出庫，這樣商品就通過快遞進入送貨過程之中；最後顧客從收貨位址收到商品，并對訂單執行确認收貨操作，同時對商品進行評價，至此完成一次購物流程。這就可以說明，這個資料模型所表現的業務流程是通順的，是以它的設計是合理的。
一般的購物網站還有購物車這一項，以滿足顧客一次選購多個商品的需求，是以還必須設計一個購物車，即在上述流程中插入一個挑選商品到購物車的過程。其中購物車隻是顧客與商品的一個關聯關系。
這下應該很完整了吧？這個模型的整個流程可以通過資料庫來表示。下圖是一個網上書店的模拟資料。
其中“顧客1”挑選了兩本書到他的購物車中，“顧客2”購買了一本小說，完成了一個完整的購物流程。
不過，如果再仔細想想，則可能會發現，上面的流程還需要更多的細化。比如，上面的資料模型雖然可以表現一個正常交易的流程，但是如果出現不正常的交易情況，那這個資料模型就走不通了。例如，顧客下單後，有可能又不要了，是以，這就需要有撤銷訂單流程。又如，顧客收到商品之後，可能因為品質問題需要退貨和退款，是以，還需要增加相應的退貨和退款處理流程。另外，商家售賣的一種商品中還有可能具有型号、顔色、價格和庫存數量等不同分類，是以，對于商品節點還有必要進行細分。
不難看出，對上面的資料模型還必須再進行加工和細化。當然，除了這些，還可能有其他各種各樣的情況。不過，不管是什麼情況，都可以通過簡單框圖對資料模型進行細化和加工。至于最終怎麼建立起一個完整的購物網站資料模型，這裡就不再深入探索了。
想及時獲得更多精彩文章，可在微信中搜尋“博文視點”或者掃描下方二維碼并關注。