數據結構設計淺談

　　相信無論是產品經理還是項目經理，都遇到過項目數據結構的設計相關的事情，說說個人對于數據結構設計的理解。

　　

　　工欲善其事必先其器，先給大家介紹幾個我比較熟悉數據結構設計的工具：

　　(1)Axure RP7.0

　　可以用來做用例及頁面原型設計。

　　頁面原型可以直接預覽查看。

　　(2)Visual Paradigm 13.0

　　可以用來做UML設計，我個人比較喜歡用它來畫業務流程圖。

　　也可以用來做類圖，用例圖。不過導出數據字典的話就麻煩了。

　　(3)表結構設計器EZDML

　　使用很方便，方便進行表結構設計，重要的是可以直接導出數據字典。建表的時候中英文直接對照在一起。個人推薦表結構設計用這個工具，后面例子的截圖都是使用這個工具做的。

　　其次，數據結構必須有比較確定的業務實施范圍(業務用例)及用戶行為(業務活動流程圖)。

　　有了以上結合頁面原型設計，我們可以開始數據結構設計了。

　　如何進行數據結構設計

　　那數據結構設計要怎么做呢?結合電商購物商城幫助大家進行理解。

　　拿大家在網上買過東西，形成訂單管理流程為例，進行一下簡單說明：

　　

　　消費者通過購買商品，填寫訂單信息，選擇優惠信息，提交訂單，付款。商家進行發貨，消費者收貨，評價，完成訂單交易。

　　第一要分析表結構關系

　　第一要分析表結構關系，消費者和訂單的關系，訂單和商品的關系，商家和商品的關系，商家和訂單的關系，當前購買場景下各自的關系。

　　1. 業務上有一對一，一對多，多對多3種關系

　　京東上一個消費者可以購買多個商家的多個商品，一個商品當前只會屬于一個訂單，可以同時對多個商家的商品合并結算，生成一個主訂單，多個子訂單。

　　淘寶上一個消費者可以購買多個商家的多個商品，一個商品當前只會屬于一個訂單，可以同時對多個商家的商品合并結算，生成多個訂單。

　　從消費者購買的訂單來看，京東的訂單表結構中存在父子結構或者說訂單存在一對多的引用關系。淘寶的訂單表結構中不存在自引用關系或者說父子訂單關系，

　　提到自引用關系，可以通過自引用達成樹結構顯示。例如如菜單，用戶層級，行政區域，訂單如果建立父子結構也可以樹狀結構顯示。

　　

　　本文訂單表結構邏輯參考淘寶，即消費者一次購買過程中，按商家生成訂單，一個訂單可以購買多件商品，即訂單有子表訂單項，一個訂單可以有多個訂單項。

　　*此流程中沒有多對多關系，若兩個對象之間存在多對多的關系，則應消除這種關系。消除的辦法是，在兩者之間增加第三個對象。這樣，實現一個多對多的關系，變為兩個一對多的關系。

　　舉個例子，在購買商品的詳情頁上顯示文章，一個文章可以涉及多個商品，一個商品可能和多篇文章有關。這時候我們就需要去消除多對多的關系。

　　

　　第二是表的設計

　　2. 對象(表)的主鍵設計

　　流程中設計到的對象(表)主鍵Id皆用GUID類型。

　　不要用業務關系字段作為表的主鍵，更不要用組合字段做表的聯合主鍵。這樣便于將來表業務變化和表數據遷移，盡量減少依賴關系。

　　3. 弄清楚表里設計的每個字段

　　表里設計每個字段的時候一定要想清楚，這個字段什么時候插入，是否會更新，是否必須字段，整個表的數據是否可以刪除。是否要建立主外鍵關系。(結合頁面原型模擬用戶行為進行判斷)

　　4. 數據結構盡量簡單

　　可以計算得出的字段，前期建議不要插入。例如：訂單里的應付總額，可以通過購買商品的單價和數量算出，這個總額不必存儲。

　　表里引用另一個表的主鍵作為外鍵，可以通過查詢得到值的，前期也不需要存儲。例如：訂單表里的收貨地址，包括省市區及詳細地址，只需要存儲地址ID，即可獲得詳細地址字段。

　　5. 枚舉設計

　　基本結構里不需要維護的字段建議做成枚舉類型，不建議存儲。例如訂單狀態。比如訂單狀態，已下單，已付款，已發貨，已收貨，已評價，已完成。

　　6. 增加備注字段，以備不時之需。這里Order表里的Remarks字段。

　　7. 重要的基礎數據不要物理刪除

　　Order表里的Enable字段，控制數據有效性，這樣便于以后數據分析。

　　8. 下圖是訂單的表結構設計，訂單表結構設計的另一個要點是，訂單是消費者的消費記錄，同時也是對商家結算的費用依據。本設計里對訂單狀態是“已完成”的訂單進行結算。

　　訂單業務流程里還有退款和退貨，本流程里退款和退貨有另外的表進行設計，再此不做闡述。

　　

　　另外幾點數據結構設計的技巧：

　　(1)復雜的邏輯關系可以考慮進行抽象表結構設計，體現繼承關系，組合關系

　　繼承關系的數據結構，當父對象抽象出來的字段，子對象不要再去創建，盡量保持父子鍵GUID相同。例如：user表有UserID，UserName，Customer繼承User表，Customer表的CustomerID要存儲為UserID的值。當生成訂單時，存儲UserID來獲得UserName即可，無需去調用Customer表。

　　(2)在數據冗余和處理速度之間找到合適的平衡點

　　冗余數據何時填入，可以依據業務經驗或者顧客提出的業務需求及項目維護時的數據監測結果進行調整。

　　最后，表結構設計與業務流程和頁面原型息息相關。總的來說，隨著開發進展，業務不斷漸進明細，數據結構也就漸漸穩定下來了。

　　作者：陳蜀，無錫東方云峰科技有限公司項目經理，7年項目管理經驗，豐富的服裝、物流ERP管理軟件設計開發經驗。