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