" Z: h! R g6 X这个问题可以归结到:我们解决了用户想要什么(What),但是并没有了解用户需要怎么做(How)。 + z% f! p S7 y. d" I5 E' E ^9 A3 c o9 N0 Q
数据建模解决了数据如何存储,存储的格式,以及怎么获得已经存储的数据的问题,数据建模完成了数据固化和检索的任务,数据建模归根结底是对静态数据的建模,给你一张ER图,你很容易就可以了解到数据的类型、数据的关系,但是你无法从这些数据格式数据关系中弄明白客户到底需要利用这些数据完成什么样的任务。不清楚这些数据从何而来,到何处去,也就决定了你编写的应用系统只能包含一个录入界面,一个查询界面,无法再为最终用户提供更多的功能,因为你手中只有静止不动的数据而已。9 _; M O) L0 [
/ z, m5 E' \& b) x: D& n9 C因此,为了让应用系统可以肩负起更多的功能,我们需要在业务模型的基础之上进行业务建模,比如一个文章发布系统中的表结构如下所示:9 f: U4 d$ `2 g$ L
f Q% B3 [& R0 o, {5 t8 |$ R, X, {0 D& K0 A* [1 z
9 s2 S. s% B; l" a3 B- s8 |: u
从表结构中可以看到一个文章包含主键(ID),作者(author),内容(content),状态(status),创建时间(create_time)和修改时间(update_time)。状态(status)字段类型为整形,可能的值为0, 1, 2, 3四种。单单从数值上来说,除了建表的人谁也搞不清楚这四个状态到底有什么作用,但是只要配合下面的流程图这个问题就可以迎刃而解了。' R* R/ p# c6 `
* W0 Z; Y8 a+ b# r+ _0 d4 H6 T' [9 s7 G( B& o
/ C; n( |8 j/ ~4 G. ^业务建模的目标是在数据模型的基础上,让应用程序帮助最终用户解决实际业务中出现的问题,它所感兴趣的方面数据的流向和状态的变迁,从上面的流程图我们就可以看到,虽然status拥有4个状态,但是这4个状态并不是可以随意转换的,“文章起草”(status=0)只能转变为“提交待审批” (status=1),而“审批完成”(status=2)作为一个终止状态是不能再发生改变的。这些功能需求都是数据建模阶段无法解决的,只有通过对业务逻辑,业务流程的梳理分析才能在应用程序中为最终用户提供这些功能。 ' H( r4 w: p/ I9 _ G/ a6 ?9 y* R# N7 i5 ?+ b
业务建模让数据模型变得有血有肉,结合了业务的数据不再是单薄的骨架,而是变成了鲜活的生灵。 / p, k# I s, z 9 H7 m% ^) |8 r- C我们借助一个最简单的发文审批流程向大家介绍了数据建模与业务建模的关系,希望大家能够借此了解软件开发中业务流程与数据模型之间的关系,别小看文章表结构中的status状态位,它已经初具了有限状态机(FSM, Finite State Machine)的雏形,很多简易的工作流引擎都是基于FSM来实现的,所以请切实体会一下实际开发中流程的作用,你可能没有使用工作流,但是我们所面对的问题和解决的方式却是大同小异的。4 k [! k3 u$ ~& Q' r
--------------------- " C$ `4 }/ Q* R) T# x, P4 G作者:shmily2038 1 |4 b+ }2 Y7 I/ a9 A
来源:CSDN ; q; a: J" q& v, @! C3 u
P7 l* O! j+ T9 A( L! n3 w8 x