系统架构设计·数据库系统·模式分解、并发控制和封锁协议

 一、数据库系统

1.1 模式分解

        模式分解:是关系数据库规范化设计中的一个重要概念。它指的是通过对关系模式进行拆分,来消除模式中的混合组合依赖,达到将模式分解为更小的模式的过程。一般分为以下两种:

        是否保持函数依赖分解:对于关系模式R,有依赖集F,若对R进行分解,分解出来的多个关系模式,保持原来的依赖集不变,则为保持函数依赖的分解。另外,注意要消除掉冗余依赖(如传递依赖)

        有损无损分解:分解后的关系模式能够还原出原关系模式,就是无损分解,不能还原就是有损 

        是否保持函数依赖案例:设原关系模式R(A,B,C),依赖集F(A->B,B->C,A->C),将其分解为两个关系模式R1(A,B)和R2(B,C),此时R1中保持依赖A->B,R2保持依赖B->C,说明分解后的R1和R2是保持函数依赖的分解,因为A->C这个函数依赖实际是一个冗余依赖,可以由前两个依赖传递得到,因此不需要管。

        当分解为两个关系模式,可以通过以下定理判断是否无损分解

        定理:如果R的分解为p={R1,R2},F为R所满足的函数依赖集合,分解p具有无损连接性的充分必要条件是R1∩R2->(R1-R2)或者R1∩R2->(R2-R1)。

        当分解为三个及以上关系模式时,可以通过表格法求解,如下:

1.2 并发控制

        事务:由一系列DML操作组成,这些操作,要么全做,要么全不做,它从第一个DML操作开始,rollback、commit或者DDL结束,拥有以下四种特性,详解如下: 

        1、(操作)原子性:要么全做,要么全不做,例如银行转账,在没到最后一步完成转账之前,前面的所有操作都是无效的。

        2、(数据)一致性:事务发生后数据是一致的,例如银行转账,不会存在A账户转出,但是B账户没收到的情况。

        3、(执行)隔离性:任一事务的更新操作直到其成功提交的整个过程对其他事务都是不可见的,不同事务之间是隔离的,互不干涉。

        4、(改变)持续性:事务操作的结果是持续性的。 事务是并发控制的前提条件,并发控制就是控制不同的事务并发执行,提高系统效率,但是并发控制中存在下面三个问题:

        丢失更新:事务1对数据A进行了修改并写回,事务2也对A进行了修改并写回,此时事务2写回的数据会覆盖事务1写回的数据,就丢失了事务1对A的更新。即对数据A的更新会被覆盖。

        不可重复读:事务2读A,而后事务1对数据A进行了修改并写回,此时若事务2再读A,发现数据不对。即一个事务重复读A两次,会发现数据A有误。

        读脏数据:事务1对数据A进行了修改后,事务2读数据A,而后事务1回滚,数据A恢复了原来的值,那么事务2对数据A做的事是无效的,读到了脏数据。

1.3 封锁协议

        X锁是排它锁(写锁):若事务T对数据对象A加上x锁,则只允许T读取和修改A,其他事务都不能再对A加任何类型的锁,直到T释放A上的锁。 

        S锁是共享锁(读锁):若事务T对数据对象A加上S锁,则只允许T读取A,但不能修改A,其他事务只能再对A加S锁(也即能读不能修改),直到T释放A上的S锁。

        共分为三级封锁协议,如下:

        ◆一级封锁协议:事务在修改数据R之前必须先对其加X锁,直到事务结束才释放。可解决丢失更新问题

        ◆二级封锁协议:一级封锁协议的基础上加上事务T在读数据R之前必须先对其加S锁,读完后即可释放S锁。 可解决丢失更新、读脏数据问题。 

        ◆三级封锁协议:一级封锁协议加上事务T在读取数据R之前先对其加S锁,直到事务结束才释放。 可解决丢失更新、读脏数据、数据重复读问题。 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值