数据库的设计原则

规范化－数据库设计原则

关系数据库设计的核心问题是关系模型的设计。本文将结合具体的实例，介绍数据库设计规范化的流程。

摘要

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

序言

本文的目的就是通过详细的实例来阐述规范化的数据库设计原则。在DB2中，简洁、结构明晰的表结构对数据库的设计是相当重要的。规范化的表结构设计，在以后的数据维护中，不会发生插入（insert）、删除（delete）和更新（update）时的异常。反之，数据库表结构设计不合理，不仅会给数据库的使用和维护带来各种各样的问题，而且可能存储了大量不需要的冗余信息，浪费系统资源。

要设计规范化的数据库，就要求我们根据数据库设计范式――也就是数据库设计的规范原则来做。但是一些相关材料上提到的范式设计，往往是给出一大堆的公式，这给设计者的理解和运用造成了一定的困难。因此，本文将结合具体形象的例子，尽可能通俗化地描述三个范式，以及如何在实际工程中加以优化使用。

规范化

在设计和操作维护数据库时，关键的步骤就是要确保数据正确地分布到数据库的表中。使用正确的数据结构，不仅便于对数据库进行相应的存取操作，而且可以极大地简化使用程序的其他内容（查询、窗体、报表、代码等）。正确进行表设计的正式名称就是"数据库规范化"。后面我们将通过实例来说明具体的规范化的工程。关于什么是范式的定义，请参考附录文章 1.

1. 原始单据与实体之间的关系

可以是一对一、一对多、多对多的关系。在一般情况下，它们是一对一的关系：即一张原始单据对应且只对应一个实体。在特殊情况下，它们可能是一对多或多对一的关系，即一张原始单据对应多个实体，或多张原始单据对应一个实体。这里的实体可以理解为基本表。明确这种对应关系后，对我们设计录入界面大有好处。

〖例1〗：一份职工履历资料，在人力资源信息系统中，就对应三个基本表：职工基本情况表、社会关系表、工作简历表。这就是“一张原始单据对应多个实体”的典型例子。

2. 主键与外键

一般而言，一个实体不能既无主键又无外键。在E－R 图中, 处于叶子部位的实体, 可以定义主键，也可以不定义主键(因为它无子孙), 但必须要有外键(因为它有父亲)。

主键与外键的设计，在全局数据库的设计中，占有重要地位。当全局数据库的设计完成以后，有个美国数据库设计专家说：“键，到处都是键，除了键之外，什么也没有”，这就是他的数据库设计经验之谈，也反映了他对信息系统核心(数据模型)的高度抽象思想。因为：主键是实体的高度抽象，主键与外键的配对，表示实体之间的连接。

3. 基本表的性质

基本表与中间表、临时表不同，因为它具有如下四个特性：

(1) 原子性。基本表中的字段是不可再分解的。

(2) 原始性。基本表中的记录是原始数据〔基础数据〕的记录。

(3) 演绎性。由基本表与代码表中的数据，可以派生出所有的输出数据。

(4) 稳定性。基本表的结构是相对稳定的，表中的记录是要长期保存的。

理解基本表的性质后，在设计数据库时，就能将基本表与中间表、临时表区分开来。

4. 范式标准

基本表及其字段之间的关系, 应尽量满足第三范式。但是，满足第三范式的数据库设计，往往不是最好的设计。为了提高数据库的运行效率，常常需要降低范式标准：适当增加冗余，到达以空间换时间的目的。

一、命名要简洁，并体现其应用或功能。如库名BxxCRM，Bxx为公司简称，CRM为Crm系统中的主数据库；为了防止被分析破解，表名建议采用子系统简写＋功能单词首字母，如BOM子系统中：BOMMD，该表的字段名为MD001，MD002......MD022并预留五到十字段供扩展，对常用表还应定义十个以上的自定义字段，供客户自定制，自定义字段统一命名UDF01...UD99。表和字段都应该在数据字典作标准，实际开发时，用向导从数据字典生成具体应用数据绑定窗口和控件。

二、与第一条相关，在开发应用之前，一定必须先输入数据字典。这条是血泪教训（之前我的SB老板，我制定了一些标准，那Sb不执行不重视，现在公司快倒了吧！这是题外话）。没有字典，维护和表的共用都是问题，且直接影响开发效率！而且开发框架一般都和数据字典集成的！

三、嵌套关系的数据表，一定要在数据字典中注明，并备注好关键字段。注意这里嵌套并不一定是主从表。如工单表，一个成品对应一张工单，该成品由N个半成品制成，又是N张工单，N个半成品可能又可细分若干层的半成品。一般就由单头单身表二个表表示这样的数据，也可用一张表。

四、数据字典的设计，表和视图都必须记录在字典中；其对应的触发器和存储过程也必须备注中对应的表中；表、视图必须按模块分类管理。

五、严格控制存储过程的使用，这是血泪教训呀，我们公司的HR有600多个存储过程，三四个人二三批维护修正了十个月都没完全搞定。这就是开发时的随意和图修改方便造成的恶果，那个别人开发的HR在我看来是垃圾，我都不碰那个东西。建议，除非大数据量的处理，则不用存储过程！业务逻辑封装到程序业务类中，或将SQL语句放在配置文件或数据库中，动态装入执行。

六、尽量少用自增长字段，有人不以为然，认为自增长字段在表的数据量巨大时速度快。但它不稳定，特别是D7中支持不是太好，而且处理麻烦。更有甚者是其更新的问题，及需要读写该字段的值时更是麻烦，所以建议还是不用为妙。遇到大数据表时，多设计几个关键字段和索引应该问题不大！ [ 注：在甲骨文数据库中，根本就不须自增长字段，因为它的每个表都有辅助列！]

4。3.1数据库设计原则

数据库设计的基本原则是在系统总体信息方案的指导下，各个库应当为它所支持的管理目标服务，在设计数据库系统时,应当重点考虑以下几个因素:

1、数据库必须层次分明，布局合理.

2、数据库必须高度结构化，保证数据的结构化，规范化和标准化，这是建立数据库和进行信息交换的基础。数据结构的设计应该遵循国家标准和行业标准，尤其要重视编码的应用。

3、在设计数据库的时候，一方而要尽可能地减小冗余度，减小存储空间的占用，降低数据一致性问题发生的可能性，另一方面，还要考虑适当的冗余,以提高运行速度和降低开发难度。

4、必须维护数据的正确性和一致性。在系统中，多个用户共享数据库，由于并发操作，可能影响数据的一致性。因此必须用“锁”等办法保证数据的一致性。

5、设定相应的安全机制,由于数据库的信息、对特定的用户有特定的保密要求，安全机制必不可少。