一个关于系统建模的探讨（一）

前言

写一篇系统建模领域的文章，是怀着忐忑不安的心情来写，不敢亵渎这个领域的思考者，因为特定场合下工作良好的思路/模式在另外的场合下可能会失败得很惨。如果存在普遍适用的方法/模式，软件将会只提供该种方法/模式的支持了，为什么还要让人操心呢？

在谈论复杂的时间建模的案例前，我们先来看看一个简单的系统模型，不存在时间纬度的需要，看看需要考虑的问题。我在十年前在某OA产品中使用过，因为产品的思考，尽量通用性的考虑，采用过以下类似的通用数据模型，目的是“最大化灵活度”，用SQL语句来表达的建模结果如下：

/* 存放类的实例（对象）的表，每个对象在此表中以一条记录表示 */

create table objects ( oid int primary key , name varchar2(255) );

/* 存放类属性定义的表，每个属性在此表中以一条记录表示 */

create table attributes ( attrid int primary key , attrName varchar2(255), datatype varchar2(25) );

/* 存放类的实例（对象）的表，每个对象的每个属性在表中用一条记录表示 */

create table object_attributes ( oid int , attrid int , value varchar2(255) , primary key (oid , attrid ));

我老婆非常欣赏Tom Hans，假如要表达电影明星，论证模型如下：

/* attributes表中，有三条记录分别如下 */

insert into attributes values ( 1 , 'BirthDate' , 'DATE');

insert into attributes values ( 2 , 'FirstName' , 'STRING');

insert into attributes values ( 3 , 'LastName' , 'STRING');

/* objects和object_attributes分别有1和3条数据如下 */

insert into objects values ( 1 , 'Movie Star' );

insert into object_attributes ( 1 , 1 , '1956-07-09');

insert into object_attributes ( 1 , 2 , 'Tom' );

insert into object_attributes ( 1 , 3 , 'Hans' );

SQL语句的水平高的人，可以写出把影星查找出来的语句。呵呵，看上去不错，这样的灵活度很大，特别在OA系统中需要支撑自定义表单字段。读者，你们说这样的模型怎么样，应该如何评判？

什么是时间建模？ 

08年倒数最后一天，同事Z谈到了系统R存在的问题。经过询问，我知道了系统R需要表达的模型中需要时间建模。什么是时间建模呢？打个比方，在IT系统的用户管理模型上，表达用户和组织架构的部门关系，使用1:0的关系来表达基本上就足够了（数据库为什么不能表达1:1的模型，在本场景中确实应该用1:0）。但是如果你建造的是一个人力资源管理系统，那么不止需要管理H现在在行业中心服务，还需要记录，H在08年5月前在NET应用部门，在07年7月到9月间在HR部门进行新员工培训。如果你的模型需要表达这类问题，那么就是时间建模。

系统R是怎么建模的？

系统R中在表达时间建模方面，在应用物理表中，增加了begin_time和end_time两个属性来表达。在前面举的例子中，在UserProfile表中，增加了begin_time和end_time；当然在DeptProfile表中，也响应地增加了begin_time和end_time来表达。

在建模的时候还采用了其他的声明完整性约束，包括begin_time not null， check  (end_time is null)  or (end_time >= begin_time)。有读者已经看出来：需要时间建模的实体，记录不删除，只有增加和修改，主键userid/deptid都是序列自增值。还有读者会问，人员UserProfile和组织机构DeptProfile物理表还建立外键关系吗？答案是建立。

当然有些读者已经知道这样的模型，声明一致性表达逻辑意义和现实世界存在出入，譬如，系统允许记录人员H在08年5月1日起到目前的有效记录（UserProfile记录id=2198/begin_time=2008-05-01/end_time=null）引用部门NET（DeptProfile记录id=654/begin_time=2004-03-01/end_time=2008-03-01，从记录上看该部门目前已经被取消）。当然，为了保证数据本身的价值，以上的逻辑保证还必须由应用或者中间层来保证。

访问当前时间Now有效的数据，必须过滤掉DeptProfile历史记录，也必须过滤掉还没有生效的新记录，譬如该部门机构从3月1日开始工作（记住现在是2月7日），因此过滤条件是：begin_time<=sysdate and (end_time is null or end_time>sysdate)。在系统R中使用以上的过滤条件，建立了一些视图view来表达当前的有效记录。

系统R的这种建模方式，是很多IT设计开发同事在面对时间建模问题时所采用的通用模式。在这个通用模式中，也有充分的灵活度，可以表达时间最小颗粒度可以精细到数据库表达Datetime类型的最小间隔interval。请读者思考一下，如果在类似的时间模型中，采用这种方式，会有那些副作用或者问题，而这些会有危害吗？

（未完待续）