数据建模与业务建模

 

无论是企业信息系统还是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来实现的，所以请切实体会一下实际开发中流程的作用，你可能没有使用工作流，但是我们所面对的问题和解决的方式却是大同小异的。