数据库设计与优化
摘   要：数据库技术是计算机科学中发展最快的领域之一，也是应用最广的技术之一，它已成为计算机信息系统与应用系统的核心技术和重要基础。本文讨论数据库设计流程的所有重要方面，包括需求分析阶段；概念设计阶段；逻辑设计阶段；物理设计阶段；数据库实施阶段；数据库运行维护阶段的六个阶段，并提出数据库设计中所出现的各种问题，并归纳分析了解决这些问题的种种途径。

关键词：数据库设计；数据冗余；数据库管理系统

引言：近年来，随着多媒体技术、空间数据库技术和计算机网络的飞速发展，数据库系统的发展十分迅速，应用领域愈来愈广，企事业单位、政府部门的行政管理、办公自动化；企业生产计划管理；军队物资管理；银行财务管理；铁路、民航飞机票预定系统；铁路车次调度系统；宾馆、酒店房间预定系统；图书馆管理；政府部门的计划和统计系统；人口普查；气象预报；地震，勘探等大量数据的贮存和统计分析；以及最近google推出的全球卫星定位系统、手机GPRS定位系统，其背后都是一个规模巨大的数据库。
如何合理高效地为政府管理人员或企业高层决策人员、设计数据库管理系统服务已成为当务之急。好的灵活的数据库设计，既能给前台应用程序的设计带来简便，又能给后台数据库的编码和扩充，和系统的维护带来极大的便利。现在关系型数据库已成为业界的主流，而我们讨论的也主要是基于关系型数据库的。
目前设计数据库系统主要采用的是以逻辑数据库设计和物理数据库设计为核心的规范设计方法。其中逻辑数据库设计是根据用户要求和特定数据库管理系统的具体特点，以数据库设计理论为依据，设计数据库的全局逻辑结构和每个用户的局部逻辑结构。物理数据库设计是在逻辑结构确定之后，设计数据库的存储结构及其他实现细节。
在数据库设计开始之前，数据库设计人员将始终参与数据库设计，他们的水平直接影响了数据库系统的质量：用户在数据库设计中也举足轻重的，他们主要参加需求分析和数据库的运行维护，他们的积极参与不但能加速数据库设计，而且是决定数据库设计的质量的又一因素。程序员和操作人员则在系统实施阶段参与进来，分别负责编制程序和准备软硬环境。

数据库设计的总流程
一、 数据库设计的六个阶段
各种规范化设计方法在设计步骤上存在差别，各有千秋。通过分析、比较与综合各种常见的数据库规范化设计方法，一般将数据库设计分为以下六阶段：需求分析阶段；概念设计阶段；逻辑设计阶段；物理设计阶段；数据库实施阶段；数据库运行维护阶段。（如下图所示）

二、 需求分析
要设计一个有效的数据库，必须用系统工程的观点来考虑问题。在系统分析阶段，设计者和用户双方要密切合作，共同收集和分析数据管理中信息的内容和用户对处理的需求。在调研中，首先要了解数据库所管理的数据将覆盖哪些工作部门，每个部门的数据来自何处，它们是依照什么样的原则处理加工这些数据的，在处理完毕后输出哪些信息到其他部门。其次要确定系统的边界，在与用户充分讨论的基础上，确定计算机数据处理范围，确定哪些工作要由人工来完成，确定人机接口界面。最后得到业务信息流程图。信息流程图中的每个子系统都可抽象为以下所示的框图。

在系统分析过程中，要确定数据管理的信息要求和处理要求。信息要求是指用户需要从数据库中获得信息的内容与性质。由用户的信息要求可以导出数据要求，即在数据库中需要存储哪些数据。处理要求是指用户要求完成什么处理功能，对处理的响应时间有什么要求，处理方式是批处理还是联机处理。新系统的功能必须满足用户的信息要求，处理要求，安全性和完整性要求。这一阶段的工作是否能准确地反映实际系统的信息流程情况和用户对数据库系统的要求，直接影响到以后各阶段的工作，并影响到数据库系统将来运行的效率，因为分析阶段的工作是整个数据设计的基础。
三、 概念设计
在需求分析阶段数据库设计人员充分调查并描述了用户的应用需求，但这些应用需求还是现实世界的具体需求，应该首先把他们抽象为信息世界的结构，才能更好地、更准确地用某个DBMS实现用户的这些需求。将需求分析得到的用户需求抽象为信息结构即概念模型的过程就是概念结构设计。概念结构独立于数据库逻辑结构，也独立于支持数据库的DBMS。它是现实世界与机器世界的中介，它一方面能够充分反映现实世界，包括实体和实体之间的联系，同时又易于向关系、网状、层次等各种数据模型转换。它是现实世界的一个真实模型，易于理解，便于和不熟悉计算机的用户交换意见，使用户易于参与。当现实世界需求改变时，概念结构可以很容易地作出相应调整。因此概念结构设计是整个数据库设计的关键所在。概念结构设计一般需要两个阶段：第一个阶段是根据用户对数据和处理的需求，为产生全局视图，得到每个用户各自的局部视图，对每个用户的局部数据结构进行描述。第二阶段是在定义了各用户的局部视图的基础上，利用一定的工具分析各个局部视图，并把它们合并成一个统一的全局数据结构，即全局视图。全局视图被称为数据库概念模型。实际上，概念设计得到的实体模型。由于实体模型（如用E-R方法）不易描述，故实体模型通常是用一些原始表格来描述，这样比较直观。
四、 逻辑设计
概念结构是各种数据模型的共同基础，它比数据模型更独立于机器，更抽象，从而更加稳定。但为了能够用某一DBMS实现用户需要，还必须将概念结构进一步转化为相应的数据模型，这正是数据库逻辑结构设计所要完成的任务。从理论上讲，设计逻辑结构应该选择最适于描述与表达相应概念的结构模型，然后对支持这种数据模型的各种DBMS进行比较，综合考虑性能、价格等各种因素，从中选出最合适的DBMS。但在实际当中，往往是已给定了某台机器，设计人员没有选择DBMS的余地。目前DBMS产品一般只支持关系、网状、层次3种模型中的某一种，对某一种数据模型，各个机器系统又有许多不同的限制，提供不同的环境与工具。所以设计逻辑结构的一般要分3步进行：
 将概念结构转化为一般的关系、网状、层次模型。
 将转化来的关系、网状、层次模型向特定DBMS支持下的数据模型转换。
 对数据模型进行优化。
一般数据库逻辑设计的结果要符合下面的准则：
 把以同样方式使用的段类型存储在一起。
 按照标准使用来设计系统。
 在用于例外的分离区域。
 最小化表空间冲突。
 将数据字典分离。
五、 物理设计
对于给定的逻辑数据模型选取一个最适合应用环境的物理结构的过程为物理设计。数据库的物理结构主要指数据库的存储记录格式、存储记录安排和存储方法，这些都依赖于所使用的系统。在网状模型和层次模型系统中，这一部分内容较复杂，因为它们是用指针表示记录的联系。关系模型系统比较简单一些，仅包含索引机制、空间大小、块的大小等内容。在设计物理结构时，应先确定数据库的物理结构，然后对物理结构进行评价。评价的重点是时间和空间的效率。数据的存储决定了数据库占用多少空间，数据的处理决定了操作时间的效率。物理结构设计应尽量减少存储空间的占用，也应尽量减少操作次数，做到相应时间越快越好。如果评价结果满足原设计要求，则转向物理实施。否则，就要重新修改或重新设计物理结构，有时甚至要回到逻辑设计阶段修改数据模型。物理设计完成之后，就应该得到详细的磁盘分配方案、存储方案、各种基表的详细信息等。根据这些信息就可以上机建立数据库。
六、 数据库实施
对数据库的物理设计初步评价完后，就可以开始建立数据库了。数据库实施主要包括：用DDL定义数据库结构，组织数据入库，编制与调试应用程序，数据库试运行。所谓使用DDL定义数据库结构，就是使用DBMS的建库命令建立相应的用户数据库结构。组织数据库入库就是将装载在其他介质上的数据输入到数据库中去。为了完成相应的操作和检索，需要编制很多程序，形成一个程序系统来使用该数据库，这部分是程序设计的任务。一切就绪之后，就可以试运行数据库了。
七、 系统管理和维护
数据库试运行结果符合设计目标后就可以真正投入运行了。数据库投入运行标志着开发任务基本完成和维护工作开始，并不意味着设计过程的终结。由于应用环境在不断地变化，数据库运行过程中物理存储也不会不断变化。对数据库设计进行评价、调整、修改等维护工作是一项长期的任务，也是设计工作的继续和改进。
在数据库运行的阶，对数据库经常性的维护工作主要由DBA完成，这包括以下内容：
 数据库的转储和恢复
 数据库的安全性、完整性控制
 数据库的性能监督、分析和改进
 数据库的重组织和重构造

解决数据库设计中存在的问题

一、需求分析采集
设计一个数据库，第一件的事情就是搞好用户需求分析，需求分析是对现实世界深入了解的过程，数据库能否正确地反映现实世界，主要决定于需求分析。而需求分析的采集主要是由设计人员和该单位有关工作人员合作进行的。需求分析的结果整理成需求说明。需求说明是数据库技术人员和应用单位的工作人员取得共识的基础，必须得到有关管理人员确认。需求说明经过评审后，才成为正式的需求文档，为下一步的数据库设计打好基础。在定义数据库表和字段需求（输入）时，首先应检查现有的或者已经设计出的报表、查询和视图（输出）以决定为了支持这些输出哪些是必要的表和字段。假如客户需要一个报表按照邮政编码排序、分段和求和，你要保证其中包括了单独的邮政编码字段而不要把邮政编码糅进地址字段里。
二、考察现有系统
在需求分析采集的过程中，不仅要耐心地和用户讨论业务需求而且还要考察现有的系统。大多数数据库项目都不是从头开始建立的；通常，机构内总会存在用来满足特定需求的现有系统（可能没有实现自动计算）。显然，现有系统并不完美，否则你就不必再建立新系统了。
三、分析各种可能的变化
在具体设计每一个字段时一定要从长远角度考虑它以后的扩充，给出一定的预留空间。这样你设计的数据库的伸缩性就非常好。以后在系统升级维护时就非常容易，不至于重构整个系统。这方面的一个典型例子就是：身份证的长度问题，以前是15位，现在是18位，如果你当时设计成15位的话，为那3位的扩充你将会付出多大代价啊。
四、数据库逻辑性设计
键选择原则：
1.键设计原则为关联字段创建外键。所有的键都必须唯一；避免使用复合键。外键总是关联唯一的键字段。
2.使用系统生成的主键。设计数据库的时候采用系统生成的键作为主键，那么实际控制了数据库的索引完整性。这样，数据库和非人工机制就有效地控制了对存储数据中每一行的访问。采用系统生成键作为主键还有一个优点：当拥有一致的键结构时，找到逻辑缺陷很容易。
五、关系模式规范化的度
对数据库进行关系模式规范化不仅有助于消除数据库中的数据冗余、删除、插入等异常出错的可能性，而且，还使你的设计比较科学、规范，同时也使你的系统的伸缩性，以及后期维护特别容易。
3NF通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。其定义为：关系R中若不存在这样的码X、属性组Y及非主属性Z(Z包含于Y)使得X决定Y、Y不依赖于X、Y决定Z成立，则称R属于3NF。
此外，还有BCNF，4NF、5NF等更高层次的关系规范化，但是不是关系规范化的程序越高， 就越实用呢，就越能满足我们的要求呢？我只能用不一定来回答，因为这要视情况而定。其实，在有些项目中是非常慎用关系模式的。因为如果规范化的程序越高，势必要将一个大表拆分成几个小表，在这些小表中用一些键值进行联接，在查询时就需要对多个表进行连接，而联接时最易产生迪卡尔积，这样查询结果集就成几何倍增，非常影响查询的效率。所以为了追求效率我们有时不对表进行关系规范化也是必要的，这样的例子很多。
六、要为尽量减轻前台的编码而工作
不要养成对数据库的复杂操作都放到前台来管理的习惯，这样会使你的程序的可读性非常差，同时也造成数据的不一致，而且会对后期的维护带来很大隐患。这一块完全应该是DBA的工作。这方面的典型例子就是数据的更新和删除操作。如果我们把这两种操作都放在前台来管理的话，就需要对多个表进行操作，操作不当的话，就会造成数据不一致。而如果DBA在后台对这几个表搭建关系的话，你在前台只要对一个主表进行操作，那么其他的几个从表就会自动更新。由此可见DBA的工作的重要性。所以，请不要把数据的管理工作都放到前台来做，因为这不是体现你编程能力的时机。
七、合理使用数据类型
我们要合理使用一些常规的数据类型，这样不仅能减少数据冗余，而且也能使你的设计更加科学、明确，同时也能使你的数据更加准确。如Oracle9i中有一个float类型，它并没有限定小数位，如果你输入时带小数位的话，它会将它精确得很长，虽然你在往数据库中存放时限定了小数位，但当你在前台进行输出时，就有可能出现小数位精度过度的情况，所以可用numeric来替代。但同时又有另一个问题发生了：例如我们用asp开发网站时用的vbscript就不支持该类型（它只认float）。所以我们应该综合考虑多种因素酌情设计。
八、用视图隐藏细节
我们考虑这样的情况，当我们在进行数据库模式设计时需要将一张大表拆分为几张小表，而在进行查询时又需要将几张小表合并为一张大表。如果表比较多的话，我们就要编写复杂的SQL语句，有没有一种机制将这几张小表一次合并为一张虚表，然后对一张表查询，这样操作起来就会简单得多。答案是肯定的。在Oracle9i中可以用视图解决。视图是在你的数据库和你的应用程序代码之间提供另一层抽象，你可以为你的应用程序建立专门的视图而不必非要应用程序直接访问数据表。这样做还等于在处理数据库变更时给你提供了更多的自由，同时也对数据的一些底层操作进行了隐藏。

结论

总之，我们在进行数据库设计时，一定要综合考虑多种因素，具体问题具体分析，既要考虑当前实现的可行性，又要考虑以后的升级维护；既要减轻前台编码的负担，又要让后台的管理简单易行；既要让前台的查询效率高，又要让后台的实现方便可行。数据库设计是一项综合性设计，决非一朝一夕之功，只有在工作、学习中多思考、多动脑、多总结、灵活运用所学知识，综合考虑各种因素，平衡把握每个细节，这样数据库设计才会更加科学、合理。