范式&数据库保护

什么是范式呢？

概念：

 

范式（normal form，NF）是衡量关系模式的优劣的标准。范式有很多种，与数据依赖有着直接的联系。

第一范式1NF

如果关系模式R中，每个分量是不可分的数据项，就称R属于第一范式。

第二范式2NF

若关系模式R属于1NF，且每个非主属性完全函数依赖于候选关键字，则称R属于第二范式。

第三范式3NF

若关系模式R属于1NF，且每个非主属性都不传递依赖于R的候选关键字，则称R属于第三范式。

这里的主属性是指键的属性，而不是任何键的属性就是非主属性

BC 范式BCNF

若关系模式R属于1NF，且每个属性都不传递依赖于R的候选关键字，则称R属于BC范式。

由上可知，4种范式之间的关系：BCNF<3NF<2NF<1NF

BC 范式和第四范式

BC范式： 关系模式R<U，F>∈1NF，如果对于R的每个非平凡函数依赖X→→Y（Y  X），X都含有候选码，则R∈BCNF。 第四范式： 关系模式R<U，F>∈1NF，如果对于R的每个非平凡多值依赖X→→Y（Y  X），X都含有候选码，则R∈4NF。 （X→Y） 如果R ∈ 4NF， 则R ∈ BCNF 不允许有非平凡且非函数依赖的多值依赖 允许的是函数依赖（是非平凡多值依赖）   **************************************** 数据库保护 **************************************** 概述 在数据库系统运行时， DBMS 要对数据库进行监控，以保证整个系统的正常运转，保证数据库中的数据安全可靠、正确有效，防止各种错误的产生，这就是对数据库的保护，有时也称为“数据控制”。这具体包括以下四个方面：     数据库的恢复      完整性控制（主键约束，外键约束，属性的值域约束）       并发控制（琐机制）        安全性控制（存储控制，审计，视图保护和日志监视）        事务         事务在数据库里面是一个十分重要的概念。数据库系统运行的基本工作单位是事务。它相当于操作系统中的进程，一个事务由应用程序中的一组操作序列组成。 实际上，事务可以看作是一个原子，是一个不可分割的操作序列。事务中包括的所有操作要么都执行，要么都不执行。 事务通常以 BEGIN TRANSACTION 语句开始，它主要涉及两个语句。、        事务提交语句 COMMIT        事务回滚语句 ROLLBACK 事务的特性： 事务具有四个特性：原子性（ Atomicity ）、一致性（ Consistency ）、隔离性（ Isolation ）和持续性（ Durability ）。这个四个特性也简称为 ACID 特性。 1 ．原子性：事务是数据库的逻辑工作单位，事务中包括的诸操作要么都做，要么都不做。 2 ．一致性：事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此当数据库只包含成功事务提交的结果时，就说数据库处于一致性状态。如果数据库系统运行中发生故障，有些事务尚未完成就被迫中断，系统将事务中对数据库的所有已完成的操作全部撤消，滚回到事务开始时的一致状态。 3 ．隔离性：一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对其他并发事务是隔离的，并发执行的各个事务之间不能互相干扰。 4 ．持续性：持续性也称永久性（ Permanence ），指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其执行结果有任何影响。 数据库恢复： 尽管数据库系统中采取了各种保护措施来防止数据库的安全性和完整性被破坏，保证并发事务的正确执行，但是计算机系统中硬件的故障、软件的错误、操作员的失误以及恶意的破坏仍是不可避免的，这些故障轻则造成运行事务非正常中断，影响数据库中数据的正确性，重则破坏数据库，使数据库中全部或部分数据丢失，因此数据库管理系统（恢复子系统）必须具有把数据库从错误状态恢复到某一已知的正确状态（亦称为一致状态或完整状态）的功能，这就是数据库的恢复。 故障的种类： 一、事务内部的故障    事务内部的故障有的是可以通过事务程序本身发现的（见下面转帐事务的例子），有的是非预期的，不能由事务程序处理的。 二、系统故障    系统故障是指造成系统停止运转的任何事件，使得系统要重新启动。例如，特定类型的硬件错误（ CPU 故障）、操作系统故障、 DBMS 代码错误、突然停电等等。这类故障影响正在运行的所有事务，但不破坏数据库。这时主存内容，尤其是数据库缓冲区（在内存）中的内容都被丢失，所有运行事务都非正常终止。发生系统故障时，一些尚未完成的事务的结果可能已送入物理数据库，有些已完成的事务可能有一部分甚至全部留在缓冲区，尚未写回到磁盘上的物理数据库中，从而造成数据库可能处于不正确的状态。为保证数据一致性，恢复子系统必须在系统重新启动时让所有非正常终止的事务回滚，强行撤消（ UNDO ）所有未完成事务。重做（ Redo ）所有已提交的事务，以将数据库真正恢复到一致状态。 三、介质故障    系统故障常称为软故障（ Soft Crash ），介质故障称为硬故障（ Hard Crash ）。硬故障指外存故障，如磁盘损坏、磁头碰撞，瞬时强磁场干扰等。这类故障将破坏数据库或部分数据库，并影响正在存取这部分数据的所有事务。这类故障比前两类故障发生的可能性小得多，但破坏性最大。 四、计算机病毒    计算机病毒是具有破坏性、可以自我复制的计算机程序。计算机病毒已成为计算机系统的主要威胁，自然也是数据库系统的主要威胁。因此数据库一旦被破坏仍要用恢复技术把数据库加以恢复。 恢复策略： 1 ．事务故障的恢复     事务故障是指事务在运行至正常终止点前被中止，这时恢复子系统应利用日志文件撤消（UNDO）此事务已对数据库进行的修改。事务故障的恢复是由系统自动完成的，对用户是透明的。系统的恢复步骤是： ⑴. 反向扫描文件日志（即从最后向前扫描日志文件），查找该事务的更新操作。 ⑵. 对该事务的更新操作执行逆操作。即将日志记录中“更新前的值”写入数据库。这样，如果记录中是插入操作，则相当于做删除操作（因此时“更新前的值”为空）。若记录中是删除操作，则做插入操作，若是修改操作，则相当于用修改前值代替修改后值。 ⑶. 继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理。 ⑷. 如此处理下去，直至读到此事务的开始标记，事务故障恢复就完成了。 2 ．系统故障的恢复    前面已讲过，系统故障造成数据库不一致状态的原因有两个，一是未完成事务对数据库的更新可能已写入数据库，二是已提交事务对数据库的更新可能还留在缓冲区没来得及写入数据库。因此恢复操作就是要撤消故障发生时未完成的事务，重做已完成的事务。    系统故障的恢复是由系统在重新启动时自动完成的，不需要用户干预。 系统的恢复步骤是： ⑴. 正向扫描日志文件（即从头扫描日志文件），找出在故障发生前已经提交的事务（这些事务既有BEGIN TRANSACTION记录，也有COMMIT记录），将其事务标识记入重做（REDO）队列。同时找出故障发生时尚未完成的事务（这些事务只有BEGIN TRANSACTION记录，无相应的COMMIT记录），将其事务标识记入撤消(UNDO)队列。 ⑵. 对撤消队列中的各个事务进行撤消(UNDO)处理。 进行UNDO处理的方法是，反向扫描日志文件，对每个UNDO事务的更新操作执行逆操作，即将日志记录中“更新前的值”写入数据库。 ⑶. 对重做队列中的各个事务进行重做(REDO)处理。    进行REDO处理的方法是：正向扫描日志文件，对每个REDO事务重新执行日志文件登记的操作。即将日志记录中“更新后的值”写入数据库。 3 ．介质故障的恢复    发生介质故障后，磁盘上的物理数据和日志文件被破坏，这是最严重的一种故障，恢复方法是重装数据库，然后重做已完成的事务。具体地说就是： ⑴. 装入最新的数据库后备副本（离故障发生时刻最近的转储副本），使数据库恢复到最近一次转储时的一致性状态。    对于动态转储的数据库副本，还须同时装入转储开始时刻的日志文件副本，利用恢复系统故障的方法（即REDO+UNDO），才能将数据库恢复到一致性状态。 ⑵. 装入相应的日志文件副本（转储结束时刻的日志文件副本），重做已完成的事务。即：    首先扫描日志文件，找出故障发生时已提交的事务的标识，将其记入重做队列。    然后正向扫描日志文件，对重做队列中的所有事务进行重做处理。即将日志记录中“更新后的值”写入数据库。 这样就可以将数据库恢复至故障前某一时刻的一致状态了。 介质故障的恢复需要DBA介入。但DBA只需要重装最近转储的数据库副本和有关的各日志文件副本，然后执行系统提供的恢复命令即可，具体的恢复操作仍由DBMS完成。 n        并发控制 在多用户共享系统中，许多事务可能同时对同一个数据进行操作，这时候就产生了并发控制的问题。 DMBS 的并发控制子系统负责协调并发事务的执行，保证数据库的完整性不受破 坏，同时避免用户得到不正确的数据。 同时并发方式：在多处理系统中，每个处理机可以运行一个事务，多个处理机可以同时运行多个事务，实现多个事务真正的并行运行，这种并行方式称为同时并发方式。 并发控制机制是衡量一个数据库管理系统性能的重要标志之一。 数据库的并发操作通常可能带来以下的问题：        丢失更新问题        不一致分析问题（读过时的数据）        依赖于未提交更新问题（读“脏”数据） 处理并发控制的主要方法是采用封锁技术。封锁是实现并发控制的一个非常重要的技术。 封锁：所谓封锁就是事务T在对某个数据对象例如表、记录等操作之前，先向系统发出请求，对其加锁。加锁后事务T就对该数据对象有了一定的控制，在事务T释放它的锁之前，其它的事务不能更新此数据对象。    基本的封锁类型有两种:排它锁(Exclusive Locks，简记为X锁) 和共享锁(Share Locks，简记为S锁)。 排它锁：排它锁又称为写锁。若事务T对数据对象A加上X锁，则只允许T读取和修改A，其它任何事务都不能再对A加任何类型的锁，直到T释放A上的锁。这就保证了其它事务在T释放A上的锁之前不能再读取和修改A。 共享锁：共享锁又称为读锁。若事务T对数据对象A加上S锁，则事务T可以读A，但不能修改A，其它事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。这就保证了其它事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。有两种类型：        排他型封锁（ X 封锁）        共享型封锁（ S 封锁） 在运用X锁和S锁这两种基本封锁，对数据对象加锁时，还需要约定一些规则，例如应何时申请X锁或S锁、持锁时间、何时释放等。我们称这些规则为封锁协议（Locking Protocol）。对封锁方式规定不同的规则，就形成了各种不同的封锁协议。下面介绍三级封锁协议。对并发操作的不正确调度可能会带来丢失修改、不可重复读和读“脏”数据等不一致性问题，三级封锁协议分别在不同程度上解决了这一问题。为并发操作的正确调度提供一定的保证。不同级别的封锁协议达到的系统一致性级别是不同的。 一级封锁协议是： 事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放。事务结束包括正常结束（COMMIT）和非正常结束（ROLLBACK）。 二级封锁协议是： 一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，读完后即可释放S锁。二级封锁协议除防止了丢失修改，还可进一步防止读“脏”数据 三级封锁协议是 ：一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，直到事务结束才释放。三级封锁协议除防止了丢失修改和不读‘脏’数据外，还进一步防止了不可重复读 和操作系统一样，封锁的方法可能引起活锁和死锁。 一．活锁 活锁：如果事务T1封锁了数据R，事务T2又请求封锁R，于是T2等待。T3也请求封锁R，当T1释放了R上的封锁之后系统首先批准了T3的请求，T2仍然等待。然后T4又请求封锁R，当T3释放了R上的封锁之后系统又批准了T4的请求，......，T2有可能永远等待，这就是活锁的情形 二．死锁 死锁：如果事务T1封锁了数据R1，T2封锁了数据R2，然后T1又请求封锁R2，因T2已封锁了R2，于是T1等待T2释放R2上的锁。接着T2又申请封锁R1，因T1已封锁了R1，T2也只能等待T1释放R1上的锁。这样就出现了T1在等待T2，而T2又在等待T1的局面，T1和T2两个事务永远不能结束，形成死锁。 死锁的预防：    在数据库中，产生死锁的原因是两个或多个事务都已封锁了一些数据对象，然后又都请求对已被其他事务封锁的数据对象加锁，从而出现死等待。防止死锁的发生其实就是要破坏产生死锁的条件。预防死锁通常有两种方法： 一次封锁法 ： 一次封锁法要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行。一次封锁法虽然可以有效地防止死锁的发生，但也存在问题，一次就将以后要用到的全部数据加锁，势必扩大了封锁的范围，从而降低了系统的并发度。 顺序封锁法： 顺序封锁法是预先对数据对象规定一个封锁顺序，所有事务都按这个顺序实行封锁。顺序封锁法可以有效地防止死锁，但也同样存在问题。事务的封锁请求可以随着事务的执行而动态地决定，很难事先确定每一个事务要封锁哪些对象，因此也就很难按规定的顺序去施加封锁。    可见，在操作系统中广为采用的预防死锁的策略并不很适合数据库的特点，因此DBMS在解决死锁的问题上普遍采用的是诊断并解除死锁的方法。 2. 死锁的诊断与解除 ① 超时法    如果一个事务的等待时间超过了规定的时限，就认为发生了死锁。超时法实现简单，但其不足也很明显。一是有可能误判死锁，事务因为其他原因使等待时间超过时限，系统会误认为发生了死锁。二是时限若设置得太长，死锁发生后不能及时发现。 ②等待图法    事务等待图是一个有向图G=(T,U)。 T为结点的集合，每个结点表示正运行的事务；U为边的集合，每条边表示事务等待的情况。若T1等待T2 ,则T1、T2之间划一条有向边，从T1指向T2。事务等待图动态地反映了所有事务的等待情况。并发控制子系统周期性地（比如每隔1分钟）检测事务等待图，如果发现图中存在回路，则表示系统中出现了死锁。    DBMS 的并发控制子系统一旦检测到系统中存在死锁，就要设法解除。通常采用的方法是选择一个处理死锁代价最小的事务，将其撤消，释放此事务持有的所有的锁，使其它事务得以继续运行下去。当然，对撤消的事务所执行的数据修改操作必须加以恢复。 如果一个事务运行过程中没有其他事务同时运行，也就是说它没有受到其他事务的干扰，那么就可以认为该事务的运行结果是正常的或者预想的。因此将所有事务串行起来的调度策略一定是正确的调度策略。虽然以不同的顺序串行执行事务可能会产生不同的结果，但由于不会将数据库置于不一致状态，所以都是正确的。 定义：多个事务的并发执行是正确的，当且仅当其结果与按某一次序串行地执行它们时的结果相同。我们称这种调度策略为可串行化（Serializable）的调度。 另外，在封锁技术方面， SQL 提供事务的四种一致性级别，从高到低分别是：        serializable （可串行化）        repeatable read （可重复读）        read committed （读提交数据）        read uncommitted（可读未提交数据）