資料建模與業務建模

 

無論是公司資訊系統還是web網站，各種大小程式的原始功能都是對資料的操作，可以看做是某一群體對一些資料的各種需求造就了一個又一個的程式，或者說是軟體系統。

回頭想想，第一刻起我們就開始和資料打交道了，新項目開始的時候我們先要做什麼呢？用第三方依賴搭個架構，設計目錄結構嗎？不對，這些都是技術儲備，應該是在項目啟動之前就完成的了。項目啟動的一刻我們在做的工作總是對資料的分析。

我們要分析資料結構，理清資料關係，確定資料類型，還要兼顧資料量的大小，現在至少不用考慮資料的儲存媒介了，因為十有八九都要用資料庫，除了極少數情況應該不會有人選擇自己編寫檔案系統進行資料的儲存了吧？

上面的這些步驟就叫做資料建模，搞程式的同志們肯定相當輕車熟路了，從拿到使用者的第一個表單開始，在ER圖中拖出第一個Table，我們就開始進行資料模型的設計，設計好的資料模型將固化在某一種媒介中（基本都是資料庫），應用系統的用途就是為使用者提供一個介面，讓他們對固化在媒介中（一般都是資料庫）的資料進行操作。

怎麼才算是良好的資料模型呢？首先它要滿足資料固化的基本要求，所有必須的資料都必須能夠儲存在資料庫裡，其次這些資料的結構應該是容易被應用程式操作的，無論是增刪查改、資料校正、資料安全、搜尋查詢、統計匯總、資料匯出等等功能都是可以實現的，而且效率不能太低。如果能夠實現以上兩條，基本就可以算是一個良好的資料模型了，這樣使用者就可以藉助應用程式對資料庫中自己所需的資料進行管理、操作。

但是還有一個問題，是否只要提供了這些功能就足以滿足使用者的要求了呢？從上面列出的功能中我們就可以瞭解到，無論是CRUD增刪查改，還是查詢統計，無非是 “更新（update）”，“查詢（Read）”，“校正（Check）”三個基本操作的實現，這些操作都是基於待用資料的單步操作，應用程式只是在資料外面簡單封裝了薄薄的一層，使用者面對的和要操作管理的依然是後面整個資料模型。

這個問題可以歸結到：我們解決了使用者想要什麼（What），但是並沒有瞭解使用者需要怎麼做（How）。

資料建模解決了資料如何儲存，儲存的格式，以及怎麼獲得已經儲存的資料的問題，資料建模完成了資料固化和檢索的任務，資料建模歸根結底是對待用資料的建模，給你一張ER圖，你很容易就可以瞭解到資料的類型、資料的關係，但是你無法從這些資料格式資料關係中弄明白客戶到底需要利用這些資料完成什麼樣的任務。不清楚這些資料從何而來，到何處去，也就決定了你編寫的應用系統只能包含一個錄入介面，一個查詢介面，無法再為終端使用者提供更多的功能，因為你手中只有靜止不動的資料而已。

因此，為了讓應用系統可以肩負起更多的功能，我們需要在業務模型的基礎之上進行業務建模，比如一個文章發布系統中的表結構如下所示：

從表結構中可以看到一個文章包含主鍵（ID），作者（author），內容（content），狀態（status），建立時間（create_time）和修改時間（update_time）。狀態（status）欄位類型為整形，可能的值為0, 1, 2, 3四種。單單從數值上來說，除了建表的人誰也搞不清楚這四個狀態到底有什麼作用，但是只要配合下面的流程圖這個問題就可以迎刃而解了。

業務建模的目標是在資料模型的基礎上，讓應用程式協助終端使用者解決實際業務中出現的問題，它所感興趣的方面資料的流向和狀態的變遷，從上面的流程圖我們就可以看到，雖然status擁有4個狀態，但是這4個狀態並不是可以隨意轉換的，“文章起草”（status=0）只能轉變為“提交待審批” （status=1），而“審批完成”（status=2）作為一個終止狀態是不能再發生改變的。這些功能需求都是資料建模階段無法解決的，只有通過對商務邏輯，商務程序的梳理分析才能在應用程式中為終端使用者提供這些功能。

業務建模讓資料模型變得有血有肉，結合了業務的資料不再是單薄的骨架，而是變成了鮮活的生靈。

我們藉助一個最簡單的發文審批次程序向大家介紹了資料建模與業務建模的關係，希望大家能夠藉此瞭解軟體開發中商務程序與資料模型之間的關係，別小看文章表結構中的status狀態位，它已經初具了有限狀態機器（FSM, Finite State Machine）的雛形，很多簡易的工作流程引擎都是基於FSM來實現的，所以請切實體會一下實際開發中流程的作用，你可能沒有使用工作流程，但是我們所面對的問題和解決的方式卻是大同小異的。