数据库 设计 原则

 

关系型数据库是当前广泛应用的数据库类型，关系数据库设计是对数据进行组织化和结构化的过程，核心问题是关系模型的设计。对于数据库规模较小的情况，我们可以比较轻松的处理数据库中的表结构。然而，随着项目规模的不断增长，相应的数据库也变得更加复杂，关系模型表结构更为庞杂，这时我们往往会发现我们写出来的SQL语句的是很笨拙并且效率低下的。更糟糕的是，由于表结构定义的不合理，会导致在更新数据时造成数据的不完整。因此，就有必要学习和掌握数据库的规范化流程，以指导我们更好的设计数据库的表结构，减少冗余的数据，借此可以提高数据库的存储效率，数据完整性和可扩展性。本文将结合具体的实例，介绍数据库规范化的流程。

　　随着市场竞争的加剧和信息社会需求的发展，人们对信息的处理、获取、发布、存储等提出了更高的性能要求。主要体现在以下几个方面：一、信息的存储，如何面对各种形式的信息（如字符、图形、声音等），以及日益膨胀的历史数据。二、信息的检索，各种各样的用户如何从一个数据库中快速的查询到所需的信息。三、数据的完整性和一致性如何保证。显然传统的数据库系统很难满足这种需求。随着客户/服务器（Client/Server）技术的成熟和大型关系型数据库（LDBMS）技术的发展,出现了Oracle ，Sybase，Informix，DB2，Ms Sqlserver等一些著名的数据库产品，使得这些问题得到完美的解决。但是，一个好的数据库产品不等于就有一个好的应用系统，如果不能设计一个合理的数据库模型，不仅会增加客户端和服务器段程序的编程和维护的难度，而且将会影响系统实际运行的性能。一般来讲，在一个MIS系统分析、设计、测试和试运行阶段，因为数据量较小，设计人员和测试人员往往只注意到功能的实现，而很难注意到性能的薄弱之处，等到系统投入实际运行一段时间后，随着数据的日益膨胀，才发现系统的性能在降低，这时再来考虑提高系统性能则要花费更多的人力物力，而整个系统也不可避免的形成了一个打补丁工程。

         规范化的表结构设计，在以后的数据维护中，不会发生插入（insert）、删除（delete）和更新（update）时的异常。反之，数据库表结构设计不合理，不仅会给数据库的使用和维护带来各种各样的问题，而且可能存储了大量不需要的冗余信息，浪费系统资源。

         要设计规范化的数据库，就要求我们根据数据库设计范式――也就是数据库设计的规范原则来做。但是一些相关材料上提到的范式设计，往往是给出一大堆的公式，这给设计者的理解和运用造成了一定的困难。

      提出以下一些设计准则，供同仁们参考:

　　* 命名的规范。不同的数据库产品对对象的命名有不同的要求，因此，数据库中的各种对象的命名、后台程序的代码编写应采用大小写敏感的形式，各种对象命名长度不要超过30个字符，这样便于应用系统适应不同的数据库平台。
　* 游标（Cursor）的慎用。游标提供了对特定集合中逐行扫描的手段，一般使用游标逐行遍历数据，根据取出的数据不同条件进行不同的操作。尤其对多表和大数据表定义的游标（大的数据集合）循环很容易使程序进入一个漫长的等特甚至死机.在有些场合，有时也非得使用游标，此时也可考虑将符合条件的数据行转入临时表中，再对临时表定义游标进行操作，可使得性能得到明显提高。
　　* 索引(Index)的使用原则。创建索引一般有以下两个目的：维护被索引列的唯一性和提供快速访问表中数据的策略。大型数据库有两种索引即簇索引和非簇索引，一个没有簇索引的表是按堆结构存储数据，所有的数据均添加在表的尾部，而建立了簇索引的表，其数据在物理上会按照簇索引键的顺序存储，一个表只允许有一个簇索引，因此，根据B树结构，可以理解添加任何一种索引均能提高按索引列查询的速度，但会降低插入、更新、删除操作的性能，尤其是当填充因子（Fill Factor）较大时。所以对索引较多的表进行频繁的插入、更新、删除操作，建表和索引时应设置较小的填充因子，以便在各数据页中留下较多的自由空间，减少页分割及重新组织工作的产生的概率。
　　* 数据的一致性和完整性。为了保证数据库的一致性和完整性，设计人员往往会设计过多的表间关联（Relation），尽可能的降低数据的冗余。表间关联是一种强制性措施，建立后，对父表（Parent Table）和子表(Child Table)的插入、更新、删除操作均要占用系统的开销，另外，最好不要用Identify 属性字段作为主键与子表关联。如果数据冗余低，数据的完整性容易得到保证，但增加了表间连接查询的操作，为了提高系统的响应时间，合理的数据冗余也是必要的。使用规则（Rule）和约束（Check）来防止系统操作人员误输入造成数据的错误是设计人员的另一种常用手段，但是，不必要的规则和约束也会占用系统的不必要开销，需要注意的是，约束对数据的有效性验证要比规则快。所有这些，设计人员在设计阶段应根据系统操作的类型、频度加以均衡考虑。
　　* 事务的陷阱。事务是在一次性完成的一组操作。虽然这些操作是单个的操作，SQL Server能够保证这组操作要么全部都完成，要么一点都不做。正是大型数据库的这一特性，使得数据的完整性得到了极大的保证。
众所周知，SQL Server为每个独立的SQL语句都提供了隐含的事务控制，使得每个DML的数据操作得以完整提交或回滚，但是SQL Server还提供了显式事务控制语句
BEGIN TRANSACTION 开始一个事务
COMMIT TRANSACTION 提交一个事务
ROLLBACK TRANSACTION 回滚一个事务
事务可以嵌套，可以通过全局变量@@trancount检索到连接的事务处理嵌套层次。需要加以特别注意并且极容易使编程人员犯错误的是，每个显示或隐含的事物开始都使得该变量加1，每个事务的提交使该变量减1，每个事务的回滚都会使得该变量置0，而只有当该变量为0时的事务提交（最后一个提交语句时），这时才把物理数据写入磁盘。
　　* 数据库性能调整。在计算机硬件配置和网络设计确定的情况下，影响到应用系统性能的因素不外乎为数据库性能和客户端程序设计。而大多数数据库设计员采用两步法进行数据库设计：首先进行逻辑设计，而后进行物理设计。数据库逻辑设计去除了所有冗余数据，提高了数据吞吐速度，保证了数据的完整性，清楚地表达数据元素之间的关系。而对于多表之间的关联查询（尤其是大数据表）时，其性能将会降低，同时也提高了客户端程序的编程难度，因此，物理设计需折衷考虑，根据业务规则，确定对关联表的数据量大小、数据项的访问频度，对此类数据表频繁的关联查询应适当提高数据冗余设计。
数据库模实体生成后，应根据应用系统的事物大小、服务器的性能调整数据库服务器的系统参数，一般来讲，有两个系统参数锁（Locks）的数量、内存（Memory）和过程高速缓存（Procedure cache）大小应加以提高，可以提高数据库的操作性能。
　　* 数据类型的选择。数据类型的合理选择对于数据库的性能和操作具有很大的影响，有关这方面的书籍也有不少的阐述，这里主要介绍几点经验。

1. Identify字段不要作为表的主键与其它表关联，这将会影响到该表的数据迁移。
2. Text 和Image字段属指针型数据，主要用来存放二进制大型对象（BLOB）。这类数据的操作相比其它数据类型较慢，因此要避开使用。
3. 各种类型字段的均有众多的相关函数支持，例如日期型函数，在日期的大小比较、加减操作上非常简单。但是，在按照日期作为相等条件的查询操作也要用函数，而使用函数作为查询的条件时，服务器无法用先进的性能策略来优化查询而只能进行表扫描遍历每行,因此，在选择大数据表的关键字段数据类型时应根据在选择查询策略尽可能避开使用函数的原则加以考虑。