时间性能数据库的运用-数据库理论论文-计算机论文

相关主题
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

时间性能数据库的运用-数据库理论论文-计算机论文

——文章均为WORD文档,下载后可直接编辑使用亦可打印——

1背景介绍

将数据库中的数据和时间属性进行特殊处理的必要性在上世纪七十年代就被理解和提出.支持这种处理的数据库被称为时间数据库.快速数据恢复和更新(即在线访问即时信息的可能性)是数据库管理系统最重要特征之一.自上世纪七十年代起的二十年中,时间数据库已经被非常详尽的研究,但还没有一种广泛应用的商业数据库管理系统支持时间属性,而且将时间属性工具加入到结构化查询语言(SQL)标准中的尝试也失败了.时间属性工具的缺乏造成了人们对时间数据功能的研发与执行的不完善,其严重缺陷表现在以下几方面:

*对完整性约束的应用,复杂且效率低;

*对开发者来说执行查询的逻辑有模糊的连接,有些数据库管理功能在应用中才能被实现;

*由于缺乏明确的设计模式,使程序的执行产生多样性,甚至在同一个应用中就显示出不同;

*同样的功能被重复执行.需要注意的是,几乎所有关于时间数据库的研究都存在着对支持时间数据的手段已包含在数据库管理系统中并被执行的假设.虽然这样的假设保证了查询语言所必需的功能可以使用,但是时间属性在数据库管理系统水平上全面执行的代价非常昂贵,且没有现成可用的解决方案.

本文将论述如何在广泛应用的商业数据库管理系统构架中局部实施时间功能.因为不能对已确立的信息系统程序设计和已开发好的程序做出重大的改变,所以提出了一种在构架中利用现有技术工具来实施的方法,这项课题的主要目的阐述如下:

*提供在传统关系或对象关系的数据库管理系统的构架中使用时间属性手段;

*对在应用程序设计和数据库已确立的方法中进行细微改变的限制; *执行程序不能降低系统中没有使用时间数据的那些部分的性能;

*不对使用传统方式来保证数据完整性的控制造成妨碍;*执行程序的

成本必须低廉.

2基本执行法则

2.1对于历史数据的要求

历史数据的存储是系统的需求,这一需求可能对应用的各个领域至关重要.系统的主要逻辑模块可以在应用程序的时间层面上进行的设计与开发.从本质上讲,支持历史数据更改同支持事务完整性和经授权的数据访问,都属于系统的基本功能.在本文中,使用的是区间时间的数据表达形式.假设一实体,它的任何历史改变都必须存储下来,并同这实体的当前状态(即事物对象的普通状态)一起,表现出这个实体的表达形式.当表达形式有效时,除普通属性外,它成为了一个被用于研究区间时间的抽象概念.在对象级别上,有效和时间的表达形式之间的关系通常取决于执行程序.时间属性的支持不会影响到系统事物逻辑分析和设计,并且不需要任何特殊的开发程序.需要存储历史数据的应用程序的设计必须包括下列步骤:

*设计系统的事物逻辑;

*增加对保留某些事物实体的历史变化的要求.

因此,设计步骤须指定实体以及之间关系.对于这些实体及关系,必须保留修改历史.统一建模语言(UML)模板便是例子之一.应用程序必须能够处理历史数据,这就要求开发特殊的界面来进行数据访问,开发图形界面向终端用户呈现历史数据.应用程序的进程逻辑在时间面上的叠交状态,仅意味着概念上支持历史更改要求的数据模型可被地进行设计.包含系统实体有效状态的数据模型称为基本模型,对于历史更改的基本模型来说,添加属性的数据模型称为时间模型.在本文中将就关系数据库中的时间表达做出详细的描述.支持历史数据的方法不需要附加编码.存储历史改变的表和表中更新数据的触发器可以从基本模型的模式中自动生成.

2.2对于历史数据的表达

我们对实体及其关系进行定义以便创建时间模式,这些实体和关系的历史更改必须被存储下来.在基本模式中,这些实体及其关系是与关系表相关联的.对每一个这样的表,我们用与基本模式同样的文件名创建一个附加表,并加以H前缀.例如,对文件名为EMPLOYEE的表,我们创建了以HEMPLOYEE为名的表.这个新的表包含了与基本表同样的列,以及两个额外的列——时间区间的开始与结束,在这一区间中,表中每行的数值都是有效的.这两个额外列的名字分别由基本表中的名字加以FTS(实施时间标记)后缀和XTS(终止时间标记)后缀来构成.每一个H表都具有主键和外键.主键由基本表的主键和FTS列构成.例如(图1)表

HEMPLOYEE,主键为:Primarykey(ID,EMPLOYEE-FTS)基本表的主键则被用做H表的外键:Foreignkey(ID)referencesEMPLOYEE(ID)H表中的数据自动更新,因此,时间模式里不存在完整性约束.

2.3对于更改历史的更新

现在来考虑在H表中插入和更新记录重要的规则是应用程序不可直接更新这些表中的数据,H表应进行自动更新.自动更新可由触发器执行或者作为应用程序构架中的功能.以下是数据更新的规则:

*当一个记录插入到基本模式表中时,同样的数据也被插入到相应的时间模式H表中FTS字段的数值被设成当前的日期和时间,XTS字段的数值设成一个远离的时间点.

*当一个记录在基本模式表中被更新时,在H表中相应的记录(具有同样的主键和XTS字段等于ENDDATE)也随之更新.之后,这一记录将不再有效,同时XTS字段被设为当前时间.一个具有当前字段值的新记录随即插入到H表,FTS字段设成当前时间,XTS字段重新设成ENDDATE;

*当基本模式表中的记录被删除时,H表中相应的记录(XTS字段为ENDDATE)也随即进行更新,将XTS字段设为当前时间.H表保留了所有数据更改的历史.每一个H表中的记录在区间[FTS,XTS]中都是有效的.

更改历史是连续的,前面描述的带有同样主键的记录的FTS字段值与XTS字段值在同一时间进行改变.H表的主键由基本表的主键和FTS字段构成.由于时间是离散的,上面描述的模式不能保证主键的值是唯一的.

这一问题可以通过附加检查得以解决.如果另一个具有当前FTS值的记录已经存在,那么至少在新的记录中FTS有一位有效值会被增加.尽管基本模式中的所有数据在时间模式中都存在,基本模式仍是有用的,理由如下:

*完整性约束在时间模式中没有定义,并且可以不被数据库管理系统进行核实;

*时间模式表可能比基本模式表大很多;

*对于一些查询,时间模式中的数据连接不如基本模式表中的连接有效.

以上提出的执行方法对于其他类型的冗余也进行了假设,冗余的程度经过了选择,从而更易实行有效查询.很明显,为了能够有效执行查询,数据库需要进行细微的调整.特别是时间表上应选择一组索引.不过,这一问题超出了本文论述的范围,在此不详叙述.我们强调不同的完整

相关文档
最新文档