DB2表设计的原则与考量

表设计的原则与考量

表设计成败关键在于规范化，而规范化也是在逻辑设计中最重要的规则。 E.F.Codd为他的追随者制定了规范化的游戏规则---范式(Normal Forms)，你读了他的论文会很快吸收理解，而读了后人的教科书，许多人就晕头转向。下面我们来看看进行表设计时需要遵循哪些原则。
1） 合理运用规范化
优良的数据库，一定是恰当的数据，在恰当的时刻被分布到恰当的表中，这需要使用恰当的数据结构，既方便对数据的存取操作，也会显著简化应用程序的其他内容（查询、窗体、报表、代码等）。而规范化，在这种操作过程中起到至关重要的作用。
规范化的目的有几个：
• 消除冗余数据，例如在多个表中存储相同的数据。
• 通过在表中只存储相关数据来强制有效数据的依赖，并把关系数据拆分到多个相关表中。
• 将系统在数据结构和未来增长中的灵活性最大化
我们看看表设计规范化带来的好处。无冗余数据占据着最少的空间，并且具有最好的完整性。然而，无冗余数据并不能提供最好的性能。为了消除一点点的冗余，需要创建额外的表，这使得查询时需要额外地结合这额外创建的表，从而增加查询的复杂性。在平衡这两方面的需求时，需要有正确的判断。通常，通过生成冗余数据可以增加性能，但是这要采取一种受约束的方式，即冗余数据所采取的形式必须是索引和汇总表。如果要经常访问汇总数据，那么后者可以明显增加性能。
E.F.Codd的论文写道：第一范式1NF不能拆分，第二范式2NF不能重复，第三范式不能冗余。
 
其中第三范式(3NF)通常被认为在性能、扩展性和数据完整性方面有着突出的效用。比如，3NF规定：1.表内的每一个值都只能被表达一次。2.表内的每一行都应该被唯一的标识（有唯一键）。3.表内不应该存储依赖于其他键的非键信息。按属性间依赖情况来区分，关系规范化的程度为第一范式,第二范式,第三范式和第四范式等。第三范式在在线交易处理（OLTP）和很多通用数据库中使用，包括企业数据仓库（也叫做原子仓库）。 星型模式和雪花模式是规范化的三维模式，并且在数据仓库和 OLAP 中经常使用。 
而将一个表反规范化（de-normalize）的意思是，违反该表之前遵从的一种或多种范式，从而修改规范化的设计。这种反标准化的过程常常是由于性能的原因而进行的。规范化只关注数据的意义，而没有考虑对于访问数据的应用程序的性能需求。完全规范化的数据库设计在性能方面要受到质疑。
这种性能问题的最常见的例子是连接（join）操作。通常，规范化过程最终将相关的信息放入不同的表中。于是应用程序需要从多个这样的表中访问数据。关系数据库为SQL语句提供了从一个以上的表中访问信息的能力，这是通过连接多个表来完成的。连接操作可能要消耗大量的资源和时间，这取决于表的数量以及这些表各自的长度。对于具有经常被请求的列的多个表，一种是复制其中的数据，一种是执行表连接，两者谁的成本更高呢？在逻辑数据库设计过程中，您可以毫无保留地规范化数据模型，然后再加入一定程度的反规范化，作为潜在的性能调优的一种选择。如果您确实打算反规范化，那么一定要为此制作完整文档：较详细地描述您所采取的反规范化步骤背后的原因。
数据冗余的代价，首先是空间代价，其次是管理代价（主要是增删改异常），维护数据的完整性。而它的好处是：减少查询所要连接表的个数，减少了I/O和CPU时间,加速了查询。因此，做反规范时，一定要权衡利弊，仔细分析应用的数据存取需求和实际的性能特点。
• 优化策略：数据应当按访问和修改的频率和重要性进行组织
• 原则：查询带来的收益应该大于两次查询之间进行维护所需要的额外时间
• 常用的反规范技术有增加冗余列、增加派生列、重新连接表和分割表

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25714550/viewspace-756952/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/25714550/viewspace-756952/