1、关系型数据库设计之实践技巧 任何信息管理系统都离不开数据库的参与。本文结合实际项目中的数据库设计经验，介绍了关系型数据库树型结构、动态表字段、预留属性字段的设计技巧，为数据库设计中的常见问题提供了成熟的解决方案。 【关键词】关系型数据库 树型结构 动态表字段 预留属性字段 任何信息管理系统都离不开数据库的参与。现在的应用程序开发采用的数据库大多是关系型数据库。虽然各个信息管理系统在业务内容上有很大区别，但是从数据本质上看，主要包括数据的录入（增删改）、数据的查询排序、数据的导入导出、数据的统计分析、数据的打印、数据权限控制等。这种数据操作上的通用性，使得每个信息管理系统的数据库设计之间具备了可
2、借鉴的基础。 数据库设计最基本的原则就是遵循3NF设计。然而仅仅遵循3NF设计对实际开发应用系统来说是不够的，为了简化业务逻辑的复杂度和适应系统新增功能的要求，避免因业务扩展对原有的数据库表进行大换血，本文结合实际的经验介绍一些数据库设计的技巧。 1 树型结构的数据表的设计 信息管理系统中通常有树型关系的数据，例如分类目录表，即一个大类，下面有若干个子类，某些子类又有子类这样的情况。用户希望可以在任意类别下添加新的子类，或者删除某个类别和其下的所有子类，而且预计以后其数量会逐步增长，此时我们会用一个数据表来保存这些数据。如果严格的按照3NF会设计出类似如表1的数据表结构。 为了实现这样的列表显
3、示，就要对Table_Type表进行N次检索，整个程序的运行效率很低。由此可知，尽管满足3NF，但不一定是最佳的数据库设计，我们对该数据表扩充一个字段表示分类目录的级次，就只需一次检索显示出上面的列表，表2是扩充后的数据表结构： 按照这样的表结构，上面列表记录在表中的数据是如下显示的，用SELECT * FROM Table_Type_2 ORDER BY Type_layer检索。如表3所示。 这种数据表的设计明显优于刚才第一种的设计。新增加的Type_layer字段完全能够替代原来Type_father字段的功能，虽然删去Type_father字段依然可以满足用户的所有要求，但是再插入、删
4、除某个类别的时候，就得对Type_layer的内容进行比较繁琐的判定，所以这个字段应当保留，这就是数据库设计中适当保留特征数据用以降低程序复杂度的原则。 2 动态表字段的数据表的设计 例如档案管理系统中的档案信息对不同种类的档案来说是不固定的，同一种档案对不同企业的不同管理方法来说是不固定的。比如工程管理类档案案卷信息会有属性：案卷编号、案卷名称、份数、页数、编制单位、编制日期，设计出档案信息表如表4。 很可能档案馆在试运行的时候会要求再加一个“设备位号”的信息，将上面的数据表增加设备位号信息并修改所涉及的代码、测试；很可能再运行的时候会要求再加一个“版次”等信息，按照老办法，继续增加数据表并
5、再一次修改所涉及的代码、再一次测试。面对这种数据信息不固定的业务，如果数据表按照这种方式增长下去，程序按照这种方式修改下去肯定不行，必须找个解决方案能够自适应这种不可预见性的信息增长。增加属性信息表Talbe_FileProperty，如表5。 根据增加的这个档案属性表，在系统的后台管理功能中追加一项档案属性管理的功能，以后添加新的属性时，只需利用该功能往属性表里增加一条记录即可，不需要修改代码了。这种动态表字段的设计满足了系统扩展的需要。 3 预留属性字段的数据表的设计 在实际的系统开发中，如果能在设计数据表的初期全面的考虑到软件未来可能扩展的功能，预留出相应的字段，这样的数据库可扩展性较好
6、，对代码的影响也可以降到最低。以下谈几个增强可扩展性方面的技巧： 3.1 主键的设计技巧 通常的设计，主键往往选择与业务逻辑相关唯一标识。但是，这种设计并不好，往往无法满足未来需求的变更。比如在档案管理系统中，档案编号这个信息是可以唯一标识出档案的，按照主键设计的要求，完全可以用它来做主键。假设系统在运行了一段时间后，发现档案编号的规则需要调整，这时需要修改档案编号，但是发现其他模块的信息，比如借阅模块的信息中与档案编号是关联着的，如果一旦修改了档案编号，其他模块的所有关联就必须相应修改，这时需求的变更影响太大，在现有的设计下，要大换血才能够满足，当已存数据到达一定量的时候，这种修改的工作强度
7、几乎是不可完成的。 基于这个原因，每个表都定义一个与业务逻辑无关的“id”字段用作库表记录的唯一识别，不将业务逻辑牵扯到数据逻辑中，否则业务逻辑的变化将直接对底层数据逻辑产生根本的影响。因为与业务逻辑无关，所以主键不会存在需求变更，需求变更也不会影响主键，相应的也不会影响与主键相关联的数据表信息。 主键生成机制采用通过内存数据直接生成主键的方案比较好，比如uuid.hex（由Hibernate基于128位唯一值产生算法，根据当前设备IP、时间、JVM启动时间，内部自增量等参数生成十六进制数值作为主键），这种方式提供了最好的数据插入性能。而数据库提供的主键生成机制，往往是通过在一个内部表中保存当
8、前主键状态如当前的最大值和递增量，之后每次插入数据会读取这个最大值，然后加上递增量作为新记录的主键值，之后再把这个新的最大值更新回内部表，这样，一次Insert操作可能导致数据库内部多次表读写操作，同时伴随的还有数据的加锁解锁操作，对性能影响较大。 3.2 增加排序字段的设计 当做需求调研时，客户的着重点往往放在数据的流程与相互联系上，往往忽略了数据显示的问题，但是我们在设计数据表的时候要全面的考虑显示问题，显示的一个重要的方面就是显示顺序，在设计时，应预先设定排序字段。比如部门表，通常应该有部门名称，部门描述这样的信息，这些信息能够完全满足关联信息的需要，但如果统计模块要统计出部门里所包含的
9、用户，并且要按照部门级别显示，就需要增添排序字段。在设计数据表的初期就应当把排序字段加入，不管目前是否有排序的要求，这样的扩展可以减少业务变更时的影响。如表6所示。 3.3 基础数据表类别字段的设计 基础数据表是指一些被引用的数据表，比如用户表的信息，这个表往往被其他表引用。这种数据表的设计往往要增添区分数据类别的字段，比如用户表一般增添用户类别字段用以区分系统用户和普通用户，而且还能进行进一步的扩展。 3.4 部分基础数据表删除标识的设计 部分基础数据表的主键信息被其它表引用，如果删除此表中的记录，往往引起其他信息关联不上。对于这种情况，主要有两种设计思路，要根据具体情况选用适合的设计。 （
10、1）将关联表中的信息一并删除，这时要注意关联表中的信息是否允许删除，如果允许，这种方式合适使用，注意保证数据之间的完整性。 （2）将基础数据表中增加一个标识是否删除的字段，这种方案主要解决关联表中的信息不允许删除的情况。这种方法也要注意维护数据之间的完整性，比如分类目录与档案条目之间是一对多的关系，如果将分类条目里的是否删除的标识置为已删除，但是依然要维护档案信息表中的删除标识字段，统计档案总数的时候会将已删除的档案统计进去，出现错误。 参考文献 1王珊，萨师煊.数据库系统概论.高等教育出版社. 2夏昕.深入浅出Hibernate.电子工业出版社. 作者简介 李华娟（1980-），女，北京市人。硕士学位。现为工程师。主要研究方向为软件开发及项目管理。 作者单位 中海油信息科技有限公司北京分公司 北京市 100027第 6 页 共 6 页
