数据库冗余数据分析

这是之前的文章了，以前在百度放着，发现各种的不方便，今天就拉了过来，读者阅过的就…………无视吧：）

数据库设计时需要考虑的一个问题是：由于各种原因导致的数据冗余，也就是在数据库中同一个信息由多于一个的存储，其弊端显而易见，有以下几种：

1、   浪费存储资源；

2、   在维护数据库时，耗费更多的时间与空间，具体体现在插入，修改，删除等操作；

但是，冗余数据的存在也有其有利的一面：

1、   保证数据安全；

2、   提高性能；

数据冗余具体体现在物理层面以及逻辑结构层面。

数据库物理层面的冗余指数据库存储的硬件资源的冗余，逻辑结构层面的冗余是指包括表、记录、字段、属性值以及索引、数据字典中的冗余，由于数据库逻辑实现的基础是各种硬件资源，所以物理层面的冗余影响数据库逻辑结构的设计，并且逻辑结构层面的冗余最终会体现在物理层面上。

在设计数据库时，冗余表和冗余记录很常见，像临时表（常用于复杂关系运算），一些可以通过其他表中数据通过函数运算得到的字段等。

属性冗余包括不同表属性以及同表属性冗余，不同表属性冗余常用于解决建立表与表之间的联系，同一表中的属性冗余应该尽力避免。

为了度量冗余度，规范化理论把关系分成以下几级：

第一范式：设 R 是一个关系模式，如果 R 中的每一个属性 A 的值域中的每个值都是不可分解的，则称 R 是属于第一范式的，记作 R ∈ 1NF。

第二范式：如果关系 R ∈ 1NF，并且 R 中每一个非主属性完全函数依赖于任一个候选码，则 R ∈ 2NF。

地三范式：如果关系 R ∈ 2NF，并且 R 中每一个非主属性对任何候选码都不存在传递函数依赖，则 R ∈ 3NF 。

随着时间发展，以后又提出了BCNF范式、4NF、5NF等。

最后给出关系数据库之父E.F.Codd提出的关系型数据库设计的十二个基本准则：

1、   信息准则：关系数据库中的所有信息都应在逻辑层上用表中的值显式的表示。

2、   保证访问准则：依于表名，主键和列名，保证能以逻辑方式访问数据库中的每个数据项。

3、   空值的系统化处理: RDBMS支持空值（不同于空的字符串或空白字符串，并且不为0）系统化的表示缺少的信息，且与数据类型无关。

4、   基于关系模型的联机目录：数据库的描述在逻辑上应该和一般数据采用同样的方式，使得授权用户可以使用查询一般数据所用的关系语言来查询数据库的描述信息。

5、   合理广泛的子语言准则：一个关系系统可以具有几种语言和多种终端使用方式（表格填空方式，命令方式等）。但是必须有一种语言，它的语句可以表示为具有严格语法规定的字符串，并能全面的支持以下功能：数据定义，视图定义，数据操作，完整约束，授权，事物控制。

6、   视图更新准则：所有理论上可更新的视图也应该允许由系统更新。

7、   高阶的插入，更新和删除：把一个基本关系或导出关系作为一个操作对象进行数据的检索以及插入，更新和删除。

8、   数据的物理独立性：无论数据库的数据在存储表示上或存取方法上做任何变化，应用程序和终端活动要都保持逻辑上的不变性。

9、   数据的逻辑独立性：当基本表中进行理论上信息不受损害的任何变化时，应用程序和终端和终端活动都要保持逻辑上的不变性。

10、  数据完整的独立性：关系数据库的完整性约束必须是用数据子语言定义并存贮在目录中的，而不是在应用程序中加以定义的。至少要支持以下两种约束：实体完整性：主键中的属性不允许为NULL ； 参照完整性：对于关系数据库中每个不同的非空的外码值，必须存在一个取自同一个域匹配的主键值。 

11、  分布的独立性：一个RDBMS应该具有分布独立性。用户不必了解数据库是否是分布式的。（无论数据库是否有部分处于复杂多重环境中）

12、  无破坏准则：若RDBMS有某种低级语言，这一低级语言不能违背或绕过完整性准则以及高级关系语言表达的约束。