阅读数:97 评论数:0

一、概述

事物处理技术主要包括数据库恢复技术和并发控制技术。

所谓事务是用户定义的一个数据库操作序列，这些操作要么全做要么全不做。事务通常以begin transaction开始，以commit或rollback结束。

二、事务的ACID

事务具有四个特性：原子性（Atomicity）、一致性（Consistancy）、隔离性（Isolation）、持续性（Durability），简称ACID特性。

（1）一致性：事务执行的结果必须使数据库从一个一致性状态变成另一个一致性状态。

（2）隔离性：一个事务的执行不能被其他事务干扰。

恢复的基本原理十分简单——冗余，建立冗余数据最常用的技术是数据库转储和登录日志文件。

为了保证数据库是可恢复的，登记日记文件必须遵循两条原则：

（1）登记的次序严格按并发事务执行的时间次序

（2）必须先写日志文件，后写数据库

多个事务并发执行是正确的，当且仅当其结果按某一次序串行地招待它们时的结果相同，我们称这种调度策略为可串行化的调度。

三、正规划

在数据库设计中，正规化是一种过程，旨在减少数据冗余和提高数据完整性。正规化的过程通常涉及将数据库结构分解成满足一定规则的关系（表）。

1、第一范式（1NF）

一个关系模式 R 满足第一范式，如果它的所有属性都是原子的，即每个属性不能再分解成更小的部分。在实践中，这意味着表中的所有字段值都必须是不可分割的。

这样做的好处：

• 数据结构的一致性：确保每个字段都是原子的，有助于简化数据结构，使得数据库操作更加一致。
• 简化查询：当数据是原子的，查询就可以更加简单和直接，不需要额外的逻辑来处理字段中的集合或多个值。
• 提高数据完整性：原子字段有助于实施数据完整性约束，如主键、外键等。

为了将数据库表转换为第一范式，你可能需要执行以下步骤：

• 消除重复列：如果表中存在一列的多个实例，需要将这些列合并或重构表。
• 消除组合字段：如果字段包含了多个值，比如一个名为 "电话号码" 的字段包含了家庭电话和移动电话，那么需要将这个字段分解为 "家庭电话" 和 "移动电话" 两个字段。
• 创建独立的表：对于包含集合或列表的字段，应创建一个独立的表，并通过外键与原表关联。

2、第二范式（2NF）

一个关系模式 R 满足第二范式，如果它已经在 1NF 中，并且每个非主属性完全函数依赖于任何候选键。完全函数依赖意味着属性依赖于整个候选键，而不仅仅是候选键的一部分。也就是消除非主属性对码的部分依赖。

这样做的好处：

• 减少数据冗余：通过消除部分函数依赖，可以减少数据的重复存储，从而减少冗余。
• 减少更新异常：当一个非主属性仅依赖于组合主键的一部分时，更新这个属性可能会导致数据不一致。2NF 通过确保所有非主属性完全依赖于整个主键来避免这种情况。
• 提高数据完整性：更好地组织数据，使得数据模型能够更准确地反映现实世界的规则。

为了将数据库表转换为第二范式，你可能需要执行以下步骤：

• 识别并消除部分函数依赖：检查组合主键中的每个属性，确保所有非主属性都依赖于整个组合主键而不是它的一部分。
• 分解表：如果发现部分函数依赖，可以通过分解表来消除它们。将依赖于主键一部分的非主属性移到新表中，并建立适当的关系。
• 重新定义主键：在新分解的表中，确保每个表都有一个适当的主键，并且所有非主属性都完全依赖于这个主键。

3、第三范式（3NF）

一个关系模式 R 满足第三范式，如果它已经在 2NF 中，并且其所有非主属性既不传递依赖于候选键也不部分依赖于候选键。传递依赖意味着一个非主属性依赖于另一个非主属性，而那个非主属性又依赖于候选键。

消除非主属性对码的传递函数依赖。

这样做的好处：

• 减少数据冗余：通过消除传递依赖，可以进一步减少数据的重复存储，从而减少冗余。
• 减少更新异常：当一个非主属性依赖于其他非主属性时，更新这些属性可能会导致数据不一致。3NF 通过确保非主属性只依赖于主键来避免这种情况。
• 提高数据完整性：更好地组织数据，使得数据模型更能反映现实世界的规则和约束。

为了将数据库表转换为第三范式，你可能需要执行以下步骤：

• 识别传递依赖：检查所有非主属性，确保它们不依赖于其他非主属性。
• 分解表：如果发现传递依赖，可以通过分解表来消除它们。将依赖于非主属性的属性移到新表中，并建立适当的关系。
• 重新定义主键和外键：在新分解的表中，确保每个表都有一个适当的主键，并且所有非主属性都只依赖于这个主键。同时，建立外键以维护表之间的关系。

4、Boyce-Codd范式（BCNF）

一个关系模式 R 满足 Boyce-Codd 范式，如果它已经在 3NF 中，并且每个决定属性集的属性集都是一个超键。BCNF 是对 3NF 的加强，它解决了在 3NF 中仍然可能存在的某些依赖异常。

BCNF：若R属于3NF，且如果X->Y且Y不包含于X时，X必含有码（消除主属性对码的部分和传递函数依赖）

5、第四范式（4NF）

它在Boyce-Codd范式（BCNF）的基础上进一步处理了多值依赖（Multi-valued Dependency，MVD）的问题。多值依赖是一种特殊类型的依赖，其中一个属性的多个值依赖于另一个属性，但这种依赖与其他属性无关。

多值依赖（Multi-Valued Dependency，MVD）是一种特定类型的数据依赖，它扩展了函数依赖的概念。

• 函数依赖：如果 ( $A \rightarrow B$ )，则对于每个 ( A ) 的值，( B ) 只能有一个关联的值。
• 多值依赖：如果 ( $A \twoheadrightarrow B$ )，则对于 ( A ) 的每个值，( B ) 可以有多个独立的值，而这些值不受 ( R ) 中其他属性的影响。

在4NF中，为了消除非平凡的多值依赖（即 ( A ) 不是超键的情况下的 ( $A \twoheadrightarrow B $)），通常需要将关系模式分解成多个较小的模式。

6、第五范式（5NF）

也称为投影-连接范式（Project-Join Normal Form，PJNF），是数据库正规化中的一个高级范式。它进一步处理了在满足第四范式（4NF）的基础上可能出现的联接依赖问题。

一个关系模式 ( R ) 满足第五范式（5NF）如果它首先满足4NF，并且每一个联接依赖在 ( R ) 上都是由候选键推导出来的。换句话说，只有当一个关系的所有非平凡的联接依赖都是由其候选键决定时，它才处于5NF。

联接依赖

一个关系 ( R ) 上的联接依赖是一个断言，表明 ( R ) 是一组较小的关系的完全联接（natural join）的结果。如果 ( R ) 可以被分解为多个关系 ( R1, R2, ..., Rn )，并且这些关系的完全联接是 ( R ) 本身，那么 ( R ) 被认为有一个联接依赖。

5NF是一个理论上的正规化目标，在实际中不常见。达到5NF可能会导致关系模式数量的增加，从而增加了数据库设计和维护的复杂性。此外，过度的分解可能会影响查询性能，因为它可能需要更多的联接操作。