我是靠谱客的博主 勤恳西装,最近开发中收集的这篇文章主要介绍触发器的几种应用,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

摘 要 列举了触发器的几种代表性应用:数据分散—集中式模型的设计,历史数据的导出,应用系统间的数据接口。并对如何设计这些触发器进行了探讨。
   关键词 触发器,数据分散—集中模型,历史数据导出,数据接口

1 引言
  在大型数据库设计中,会经常用到触发器。它的特点是:一旦被定义,就存在于后台数据库系统(server,服务器方)中,并会在相应条件下自动地隐式执行,从而使得它的设计既与前台(client,客户机方)的平台无关,又免除了前台相关的数据操作设计。
  在文献[1]中,列举了触发器的几种应用:审计;复杂的完整性约束;复杂的安全性授权;事件登录;列值导出;分布式数据库中表复制。

2 触发器的另外几种应用
2.1 数据分散——集中式模型设计
  在实际开发过程中,经常遇到这样的数据维护要求:单位由多个部门组成,要求各部门只能维护本部门的数据,但另一方面,又需要将分散到各部门的数据集中起来进行汇总,得到本单位的汇总数据。如一个学校有多个系,学校需要各系的成绩汇总;一个工厂有多个生产车间,工厂需要各车间的产量汇总;一个公司有多个销售部门,公司需要各部门的销量汇总等等。
  在这种情况下,如果不使用触发器的话,数据库设计就存在困难:
  . 如果为每个部门都建立一个表,显然难以得到汇总的数据(在这种情况下,无法利用视图机制);
  . 如果所有的部门都共享一个表的话(这时,这张表中的数据实际就是汇总的数据),因为每个部门需要维护数据,所以都对这个表有修改权,因此在数据安全上难以控制。
  使用触发器的话,上述问题便可迎刃而解:为每个部门建立一个表(该部门的所有权限只限于对此表有修改权),再为汇总数据也建立一个表,然后在每个部门表上建立触发器,使得部门表上有数据更新时,便会对应地更改汇总表中的相关数据(见图1)。

 (3337 bytes)

图1 触发器应用于数据分散——集中式模型

  在这种模型中,要注意设计好部门表相关字段的完整性约束,使各部门表内的数据是唯一的,以防止不同部门表出现相同的数据记录,从而导致在汇总表中出现混乱。

2.2 历史数据导出
  数据库中的表只记载最新的数据,而不记载历史数据。但在很多情况下,历史数据的记载与分析反而比现实数据更有意义(这也正是数据仓库与数据库的区别之一),比如学校中学号的变动,工厂定额的更改,公司产品和原材料价格的变化、股票的升跌等等,它们都需要记录历史数据。
  如何使数据库也能记载历史数据呢?使用触发器可以解决这类问题。
  建立这类触发器的步骤是:建立数据表后,再建立对应的历史表(一般而言,历史表在字段组成上是数据表的超集,即在原数据表字段上再增加有关时间的字段),然后在两者之间设立触发器(见图2)。这样,每当数据表有数据变动,触发器便将变动的数据记入历史数据表中,从而达到自动记录历史数据的目的。

(1237 bytes)

图2 历史数据的导出模式

2.3 应用系统间的数据接口
  一个完整的信息系统的建设一般不是一步到位的,往往是分期分批完成,而不同期次的系统往往又会有数据传递,然而由于需求发生变化或是其他原因,不同期次系统的数据库设计在表结构甚至字段上的设计都可能会互不一致(即使是在同一期的开发过程中,由于总体设计或数据字典方面的偏差或不足,或者需要集成多家系统,这种现象也会经常出现)。在不可能重建这些系统的情况下,它们之间的数据能无缝传递吗?换言之,它们之间能够做到无缝连接吗?

  在这种情况下,触发器可以是一种较好的解决方式:建立中间表,中间表的设计符合需方应用系统的设计格式,而它的数据又与供方应用系统的数据保持一致。(见图3)

(3678 bytes)

图3 中间作为不同应用系统间的数据接口

  要注意的一点是:图示应用系统间的数据是单向流动的(即数据传递);如果数据需要双向流动(即数据交换),那么在触发器设计中应有退出机制,以避免发生触发器的递归。

 

最后

以上就是勤恳西装为你收集整理的触发器的几种应用的全部内容,希望文章能够帮你解决触发器的几种应用所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(67)

评论列表共有 0 条评论

立即
投稿
返回
顶部