數據建模與業務建模
無論是企業信息系統還是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來實現的，所以請切實體會一下實際開發中流程的作用，你可能沒有使用工作流，但是我們所面對
的問題和解決的方式卻是大同小異的。