2016-12-23

多种时态管理机制在房管系统中的应用

2016-12-23 | 0 评论

1    引言

    房屋管理的要点是建立房屋全生命周期的管理模式,即对房屋从立项新建到灭失注销这一生命进程的每一个阶段实施信息化管理。房管的五大阶段模块包括:规划建设阶段、市场管理阶段、确权登记阶段(测绘、登记)、使用维护阶段(物业管理等)和灭失注销阶段。而房屋全生命周期的具体实施方法是在房管系统五大阶段模块的数据库中保存和管理好相应的时态信息,所以如何构建房管时态数据库是重点。

    自从20世纪80年代时态数据库技术产生以来,其理论与模型等方面取得了丰硕成果[1-6],但时态信息产品还没有形成[7-10],其成果仍然局限于模型和原型系统阶段[11-13],迄今为止,各大数据库厂商还没有推出相关产品。目前的应用大多都是只借助时态数据库的一些概念,时态信息的管理与操作的实现还是采用传统的数据库技术与相关应用领域的技术相结合来完成的。

在房管系统中,时态信息需求与处理比较复杂,完全“统一”的时态模型难以实现。本文的研究方法是:首先提出一个基本的时态机制,可满足主要基础库(楼盘表等)的时态存储和管理需求;然后把它推广应用到其他业务系统板块,根据不同板块的具体情况对基本的时态机制做些调整和改动,使多种时态管理机制可共处于同一房管系统平台。

2 本文时态管理机制的要点

    当前时态数据库的研究工作存在的突出问题表现为:理论研究多、实际应用少;以模型划分的门派多,支持时态处理的厂商少;理论得不到实际应用的检验。本文基于时态数据库的几个关键点,结合房管应用,提出在传统关系数据库基础上的时态数据高效存储方法,以及时态信息管理机制,在可用性方面有独到之处。

2.1 事务时间与三库的结合

Ben-Zvi在其博士论文[14]中提出了双时态的概念,即有效时间和事务时间:有效时间指的是现实世界中一个事件发生的时间;事务时间指的是对一个数据库对象进行操作的时间。把事务时间的思想推广到时态库结构上,时态库可由三个子库组成:过程库、现势库、历史库。如图1所示。


1 三库在业务处理中的关系

过程库跟踪描述事件发生的过程。例如房屋未建成时入楼盘表的过程库,说明房屋未建成或正在建。

现势库:保存对象现在时态的属性。例如房屋建成后入楼盘表的现势库,说明房屋已建成、是真实存在的。

历史库保存对象的历史数据。当现势库中某对象在现实世界已消失或完全脱离了现实状态,则应该把该对象的属性数据从现势库中转移到历史库中。例如被拆迁的房屋信息应该入历史库。

如果我们在三库中的记录中添加事务时间属性(入三库的库时间),就可使用上面描述的三库机制管理时态信息。下面以登记系统模块的时态管理为例来说明“事务时间”与三库结合的方法。

房管的登记系统一般是以案卷为中心的:人与房、证与房、土地与房之间没有直接的联系,而都是通过案卷把他们联系在一起。每一笔登记业务都要通过流程进行办理,如果我们在案卷记录中添加时间属性:入过程库时间、入现势库时间、入历史库时间,就可以记录和管理它们在流程处理过程中的时态信息,或流程结束后的时态信息。对于登记系统而言,这种方法简单,但无法推广到其他业务模块:因为其他模块是以房屋楼盘表为中心的系统,如果需要查找某个房的历史变迁情况时,还得通过案卷逐条追溯,程序上就很难自动处理。其实以案卷为中心的登记系统,对房屋变化进行追溯查询时同样面临麻烦。事务时间与三库的结合的方法有一定的意义和作用,但过于宏观,无法精细表达现势库中对象随时间变化的过程。

2.2 有效时间与现势库的结合

下面我们以楼盘表子系统的时态管理为例,来说明“有效时间”与现势库结合的方法,见图2

3 楼盘表在房屋全生命周期中的变化情况图


房屋建成后,在现势库也可能会发生变化。例如又添加了一层楼,由版本1变成了版本2。如果在现势库中的对象添加了有效时间属性:描述版本的开始时间和结束时间,则我们可以在现势库中更加精细地保存楼盘变化的信息。如何进行有时间属性的版本管理?如何利用版本信息进行带时间条件的查询?我们还是以楼盘表为例,进行深入的分析。

3 时态楼盘表的设计楼盘表是对房屋物理属性的描述,是土地楼栋(自然幢和逻辑幢)—结构的数据建模方式。楼盘表是是房产信息系统中各子系统内部联系的关键桥梁,它与其它房屋业务系统五大模块都有紧密的联系。因此,如何构建时态楼盘表是所有房管系统中需要研究的问题。

3.1 ER图建模楼盘表

ER图建模楼盘表,图3中椭圆范围是楼盘表的实体和联系,其中的属性过多,所以没有在图中表示。

              3  红线椭圆范围是楼盘表

 楼盘表有以下特点:

1)楼盘表在数据库中由多个表组成,每个表描述了相应的实体或联系。

2)楼盘表并非一成不变,它会随时间的变化而变化。

3)楼盘表的数据量可能会很大。

   给定任意一时间点,系统应该可以查询到该时刻的楼盘表情况。所以有必要把不同时刻的楼盘表信息都保存下来。大体上来分,有全数据复制和增量数据复制两种方法。全数据复制:数据任意一部分变化,就把全部数据复制一份,并记下新的版本号。这种做法当然可以记下所有的数据变化,不会遗失数据,但数据冗余很大。增量数据复制的思想是只记录产生变化的数据版本,不会产生数据冗余,它可以实现楼盘表信息的“局部更新,整体还原”。我们在下面给出的方法就是一种增量数据复制法。

3.2 带时间标记的版本管理机制

在房屋全生命中的楼盘表一般会有多个版本,它们是如何得到的呢?可以在某楼盘表发生变化的时刻前拍照,得到照片序列:照片1,照片2……照片n,它们分别对应不同的版本: 楼盘表V1, 楼盘表V2, …楼盘表Vn

    把版本号带上时间标记:开始版本时间和结束版本时间。一个版本中的楼盘表表示的是各部件不变的信息,任一版本号的时间区间由它的开始版本时间和结束版本时间来确定。

 “版本号+时间”的方法把楼盘表的“不变照+变化时刻”都记录下来了。这种版本管理机制有3个要点:

1)楼盘表中每个部件对象(部件表的记录)都用二个属性保存版本信息:开始版本号和结束版本号,它们表示了该部件在现势库中的一段连续的版本号信息。例如:

[开始版本号,结束版本号]=[2, 5]

代表了v2v3v4v5 这四个连续的版本号。某部件的不变照就是“版本号+部件表的信息”。

2)楼盘表的版本号更新时(VàV+1),①仅仅变化部件对象(被淘汰记录)的结束版本信息要更新(标记为V),表示它被淘汰;②新部件对象(插入新记录)的开始版本信息标记为V+1,结束版本为空;③不变部件对象的版本不更新(开始版本不变,结束版本为空)。这正反映了楼盘表增量数据复制法的思想:在楼盘表里每张表里都添加了“开始版本号”和“结束版本号”属性,由它们结合版本表,可以实现楼盘表的局部更新,整体还原。

3)除了楼盘表中各实体或联系的表外,添加版本表和版本明细表,专门用于管理楼盘表的版本和时间信息:

版本表(幢身份标签,版本号,版本开始时间,版本结束时间,版本变更原因)

版本明细表(幢身份标签,变更表名,变更部件,变更部件类别)

由于我们用关系数据库保存楼盘表以及版本表,所以在版本表和楼盘表的每张表中都添加了“幢身份标签”这个属性;即对一个自然幢,无论它的版本如何变化,它和其部件(逻辑幢、层、单元、户、构成联系)都贴上了同样的标签。这个属性值在楼盘表初始建盘的时候由自然幢最初的主键(自然幢编号)确定,以后一直唯一存在,楼盘灭失还存在。添加这个属性,可以在楼盘表中区分具体的幢和其部件,方便实现楼盘表新旧记录的统一查询。

  下面我们结合版本表,由某一时间点,实现某一楼盘表(例如测绘学院楼)的整体还原。例1:查询2011-5-1时间点的测绘学院楼盘表。

下面是示意性的SQL查询:

1) 由时间查找版本号(示意性的)

 use楼盘表_现势库

 select 版本号 into BBH from 版本表

where  版本表.幢身份标签 = 测绘学院 and 

版本表.版本开始时间 < "2011-5-1"

and 版本表.版本结束时间 > "2011-5-1"

2)由版本号整体还原测绘学院楼盘表(示意性的)

  select.*,层.*,户.*  from  幢表, 层表, 户表

where幢表.幢身份标签=测绘学院 and层表.幢身份标签=测绘学院

and户表.幢身份标签=测绘学院

and  BBH >= 幢表.开始版本号and  BBH <=幢表.结束版本号

and  BBH >= 层表.开始版本号and  BBH <=层表.结束版本号

and  BBH >= 户表.开始版本号and  BBH <=户表.结束版本号

3.3楼盘表的创建和变更

1)对一新的楼盘表:楼竣工后,经过测绘、审核,过程库的楼盘表进现势库(所有部件的开始版本号是1, 所有部件添加幢身份标签)过程库的楼盘表被删除,并在楼盘表版本表中插入一条记录(版本1)

2) 如果现势库的楼盘表有修改(例如一户A,变2B, C:

a) 在过程库生成2个新户记录;

测绘、登记、审核后,下面是入库的存储过程步骤:

b)  2个新户记录的开始版本号和结束版本号为当前版本号,并添加属性幢身份标签,进现势库;并在现势库中添加有关的新联系记录(开始版本号为当前版本号,并添加幢身份标签)

c) 过程库的2个新户记录(包括有关的旧联系记录)被删除;

d) 所有结束版本号为当前版本号的部件(除户A外),其结束版本号加1, 当前版本号加1

e) 在现势库的被修改的户记录--A(包括有关的联系记录)不进历史库, 继续保存在现势库中, 它的版本号没有变化,由其结束版本号<当前版本号, 即可知道它是旧的部件。

4 时态楼盘表的推广和普适性

    上面描述的时态楼盘表可以推广应用到其他时态管理系统中去吗?答案是肯定的!为抛开楼盘表本身的业务细节,把本文时态楼盘表的思想方法更加简捷的表达出来,下面我们用一个汽车更新例子进一步解释其“局部更新、整体还原”的时态存储和管理机制。

4.1 “局部更新、整体还原”的核心思想

    2:汽车的“局部更新、整体还原”方法。简化的汽车由车身和二个车轮构成。

出厂时的汽车在其车身和车轮上都打上版本V1的标记,见图4所示。


     图4 出厂时的汽车

   5更换了前车轮的汽车

汽车版本V1的开始版本时间和结束版本时间为2014-1-12015-5-1,在201551日,汽车更换了前车轮,见图5所示。被淘汰的车轮放在一边,新换上的车轮打上V2的标记,没有变更的部件(车身和后车轮)也打上V2的标记。车身和后车轮既是汽车版本V1的部件,又是汽车版本V2的部件,没有冗余,这正是“局部更新”的含义。

    在关系数据库中,我们用车轮表和车身表来保存简化的汽车。见表1--4所示。

1: 车轮表(出厂时)

车轮属性

身份标签

开始版本号

结束版本号

前车轮1

car1

V1

 

后车轮1

car1

V1

 

 2: 车身表(出厂时)

车身属性

身份标签

开始版本号

结束版本号

车身1

car1

V1

 

 3: 车轮表(更换了前车轮)

车轮属性

身份标签

开始版本号

结束版本号

前车轮1

car1

V1

V1

后车轮1

car1

V1

V2

前车轮2

car1

V2

 

 4: 车身表(更换了前车轮)

车身属性

身份标签

开始版本号

结束版本号

车身1

car1

V1

V2

    所有汽车的部件都保存在车身表和车轮表中。如果上面表中还保存了其他汽车的部件,其身份标签就不是car1了。由此可见,表中身份标签属性是用于区分不同汽车的。参照例1,由车身表和车轮表,很容易“整体还原”出任一版本的某汽车来。限于篇幅,汽车的版本表没有在此列出。

    时态楼盘表的版本管理机制其实是一个通用的机制,它可以推广到其它子系统的时态管理中。例如开发企业资质核准系统,与楼盘表类似,它也是由多个部件构成的一个整体:企业基本表与楼盘表中的自然幢表对应,所以要在子系统数据库的所有表中添加“开发企业身份标签”属性,它与楼盘表的“幢身份标签”是对应的;子系统的每个部件也用开始版本号和结束版本号二个属性保存版本信息。由于开发企业资质核准系统较为复杂,我们选择更为简单的自然人和法人库作为例子,解释本文时态机制的变化和推广应用。

4.2 自然人和法人库的时态管理

自然人和法人的ER建模如图6所示,其中的属性没有在图中表示。

          6 自然人和法人ER

自然人和法人有联系,但不是互为部件的关系,所以它们各用自己的版本管理。首先我们分析自然人。当自然人的姓名或身份证件发生变更,才会触发自然人的版本变更,而联系地址仅仅是自然人的附属,它的变化不会导致自然人版本变化。所以,可以把有多个联系地址的自然人看成是单实体对象。对无多个部件的单实体对象,时态机制可以更为简化:用“版本号”替代开始版本号和结束版本号属性。其原因是:单实体对象只有一个实体,它每次变更,代表了整体变更,所以用一个版本号即可;其他的可以照搬楼盘表的方法来处理。同理,法人也可看成是单实体对象,其时态机制与自然人的相同。

4.3 跨界联系表的管理

一个联系表,如果它分别属于二个以上系统(或子系统),则称为跨界联系表。例如坐落联系表就是一个跨界的联系表:它既在楼盘表内,也在GIS系统的宗地子系统中。当自然幢更新了,坐落联系表也要更新;但宗地不更新。宗地更新了,坐落联系表也要更新;但自然幢和楼盘表的其他部件不更新。为了达到这个目的(某系统的版本变化了不会影响其它系统部件的变化),所以对跨界联系,即使它是1对多(或11)联系,也用实际的物理表来实现它,而不是把与其它表合并。

在图6中,“工作”和“代表” 都是自然人和法人的联系,它们都是跨界联系。“代表”联系在ER图中是11的, 但在时态数据库中,自然人有多个版本(由于姓名变更,身份变更),法人也有多个版本(由于企业名变更等),所以在时态数据库中跨界联系本质上都是多对多联系!所以对跨界联系, 用表实现联系是必然的。楼盘表的跨界联系表有:坐落、市场开发、安维、保障、物业、登记管理。它们都属于楼盘表,也分别属于其他板块的表。

5 结束语

本文前面提出的版本管理方法在逻辑上易于理解,但在物理实现上要提高效率,则要根据具体情况进行改进。例如对各部件的“结束版本号”开始不为空,而是赋予一个大数maxintmaxint=2147483647,表示当前版本),版本更新时,仅仅变化部件的结束版本信息要更新;不变部件的版本不更新。结束版本号为maxint 的即为当前最新版本。

本文中的时态管理机制在武汉市住房保障和房屋管理局“智慧房管”主数据库设计和建设项目中得到应用,在不同板块和子系统中,根据情况对时态管理机制有不同的改动,形成多种时态管理机制共处同一平台的情况。

参考文献

[1] 刘云生. 现代数据库技术[M]. 北京: 国防工业出版社, 2001.

[2] 汤庸编著.时态数据库导论[M]. 北京: 北京大学出版社, 2004

[3] 何新贵等著.特种数据库技术[M]. 北京: 科学出版社, 2000

[4] A TanselJ CliffordS Gadia et a1Temporal DatabasesTheoryDesign and ImplementationDatabase Systems and Applications Series[M]BenjaminCummingsRedwood CityCA1993

[5] kistian T0rpChristian S JensenRichard T SnodegrassEffective timestamping in databases[J]The VLDB Journal20008(3-4)267-288

[6] 刘冬宁,汤庸.  时态数据库时间轴的动态逻辑模型[J]. 软件学报. 2010(04)

[7] 张师超.  时态数据库述评[J]. 计算机科学. 1992(03)

[8] 唐常杰.时态数据库的沿革、特色与代表人物——时态数据库二十年回顾之--[J1.计算机科学,199926(2)27-29

[9] 唐常杰.时态数据库的成果、缺陷与未来——时态数据库二十年回顾之二[J].计算机科学,199926(3)63-65

[10] 汤庸,汤娜,叶小平.时态信息处理技术研究综述【J】.中山大学学报(自然科学版)200342(4)4

[11] Christian S JensenTemporal Database Managementhttp:/www.CS.aan.dk-csjthesis

[12] TimeDBA Temporal Relmional DBMShttp:/www.timeconsuh.comsoftwaresoftwarehtml

[13] TIGERhttp://www.CS.aan.dk/~tigeradmindexhtml

[14] Ben-Zvi J. The Time Relational Model. Ph.D. Dissertation, Computer Science Department, UCLA, (1982).

 [8] 刘宁,郝忠孝.  时态数据库初等关键字范式问题的研究[J]. 哈尔滨理工大学学报. 2005(03)

[9] 江涛.  时态数据库中事件变更处理[J]. 淮南师范学院学报. 2004(05)

[10] 惠玲.  主动时态数据库中事件的时态语义研究[J]. 汉中师范学院学报(自然科学). 2004(06)

[13] ZhiCheng Li(2012): Study on the complex spatio-temporal databases query methods. Huazhong University of science and technology [D]

[14] K.Torp,C.S.Jensen,R.T.Snodgrass. Modification semantics in now-relative databases. Information Systems(ACM) . 2004

[15] Gabbay D M,Hodkinson I,Reynolds M. Temporal Logic: Mathematical Foundations and Computational Aspects. . 1994

15.何新贵,唐常,李霖.特种数据库技术[M】.北京:科学出版社,2000

16.刘云生.现代数据库技术[MI.北京:国防工业出版社,2001

18.刘大有,胡鹤,王生生等.时间推理研究进展.软件学报,200415(8)

作者简介:李军(1962-),男,湖北人,武汉大学测绘学院高级工程师,从事空间数据库等方面的研究、开发和教学工作。

E-mailgblijun@qq.com

收稿日期2015-03-15

基金项目:武汉市住房保障和房屋管理局信息化建设公开招标采购项目: “智慧房管主数据库设计及一期建库 WHZC-2014-075A(221024152416)

添加评论

武汉大学测绘学院空间信息工程研究所版权所有 地址:武汉市洪山区珞瑜路129号 邮编:430079