《数据库设计说明书(XXXXX项目).》由会员分享，可在线阅读，更多相关《数据库设计说明书(XXXXX项目).（19页珍藏版）》请在金锄头文库上搜索。
1、DOC. NO. Confidential(秘密)数据库结构文档模板后台管理部分Version 1.0.02003-10-11All Rights Reserved目录文档更新记录更新内容更新人员日期修改说明文档创建饶贵翔2004-09-30文档修改1. 总体思路1.1. 设计原则1.1.1. 数据表分布的无关性如果子系统比较多，数据库结构设计时，应该能够不同业务子系统可以分布在不同数据用户下，同事也可以根据需要合并在同一个数据用户，同时，再数据需要整合到统一信息平台时，能够在信息平台上，按照原来的表名与原来的业务系统数据表一一对应。 在同一个数据用户下不同业务子系统的数据表应能保证1） 不同
2、业务子系统的数据表的命名，应保持全局唯一性，不应出现同名的数据表。2） 通过数据表的前缀，区分不同子系统、不同的业务分组。数据表命名规则： 前缀符_数据表名前缀符的命名规则，根据项目实际情况制定。举例： D 标识公文管理子系统 F 表示公文管理的流程部分；流转内容表可为 DF_Content1.1.2. 数据结构可读能力数据结构可读能力主要体现在，不需要查询数据库文档： 通过命名就能够得知数据表、数据字段的含义、作用。 通过命名就能够得知不同数据表之间的关联关系。 通过命名、组织方式，就能够基本得知数据表的数据填写规则。主要方法：尽可能使用英文命名，不使用中文或者简写。每个英文单词一般都有比较
3、固定、确切的含义，即使使用的单词一时不认识，也可以通过查阅英汉字典既可得知；英汉字典是一个大众化的工具，随处可得。中文拼音存在一下缺陷：1) 同音字太多。同样的一个拼音，就可能有多个含义；采用中文拼音，数据结构就可能会发生歧义。2) 如果使用拼音简写，就更加会发生歧义的现象。3) 因此，不使用中文拼音或者拼音简写。使用英文单词，可能存在的问题：1) 公安专业的英文一般有其专业规定，设计人员不一定能够熟知公安专业英语的要求。2) 有些英文单词比较长3) 有些中文描述很难找到准确的英文描述。解决方案：1) 英文命名不一定要精确的反映业务表、字段的准确含义，只需要基本描述出其含义、作用既可。2) 可
4、以使用英文简写，并建立简写对照表，供查阅。英文简写有：业界通用的英文简写以及没有通用的简写。如果存在业界通用简写或者英语通用简写，应遵照其简写习惯。1.1.3. 数据可阅读可追溯能力1) 数据编码体系中有不少是采用数字编码。数字编码需要查阅数据字典，才能得知代码代表的含义，可读性不强；在查询时，还需要与数据字典关联，才能得知数据属性，执行效率低。措施：为了加强数据数据可阅读能力、提高查询效率，在数据库设计时，一般用一个字段存储编码，另外一个字段存储明文解释。2) 档案类数据引用。一个业务数据表往往有用到档案类数据(如商品档案、人员档案、部门档案、单位档案等)。通常做法是只保留档案编码；这种方法
5、会存在如下问题：a) 档案类的数据，编码一般只有规则，单个代码并没有明确的对照关系。如果数据表为历史业务资料，当档案中编码对应的对象解释发生改变时，历史信息也随之发生改变。但是，作为历史资料，它应该记载该资料发生时当前的状态；档案数据的变化，将破坏这种状态.。b) 数据查询时需要关联引用档案数据，才能够得到代码的解释，执行效率慢。3) 状态类编码、事物分类性编码，如果没有部标规定，建议使用明码。部标一般规定事物分类性的编码。事物性编码，可以采用数字编码明文的方式。4) 业务历史数据表的设计原则业务历史数据表主要指记载业务历史信息；业务信息发生后，一般不发生动态变化。如业务受理历史等信息。业务历
6、史数据表的编码 一般采用 编码字段 明文字段 的原则。历史数据表，要求能够单表脱离原来的关联环境，依然能够还原数据的含义。例如： 某业务对象的归属单位，一般设计原则是只存放归属单位代码。 这种情况会导致以下现象发生； a) 归属单位代码 所对应的单位名称发生变化，此时5) 动态数据表的设计原则数据是动态变化的，如库存数据表等。这种表的编码 一般只需要 编码字段。1.1.4. 数据结构的统一性数据结构的统一包括：标识符命名的统一、逻辑结构的统一。相同业务含义的标识符命名统一。不同业务子系统、不同数据表的字段，如果业务含义相同，其命名相同。如“性别”字段的统一命名部标编码字段：sexCode ,
7、明文字段：sex 1.1.5. 与不同系统可交互能力 公安有非常多的子系统，为了加强数据交互能力，公安部制定了不少编码标准、数据标准。为了保证与其他系统的数据交互能力，凡是存在公安部标准的，都应该使用公安部标准。1.1.6. 性能设计原则1.1.6.1. 数据库的结果，SQL 条件中不应出现函数数据库设计的结果，以在SQL条件语句中数据库字段不出现在函数中为原则。 如： 可以根据 员工号码 的前三位 是部门号。 非法设计： Create table U_wk( WkNo VARCHAR2 (20) , WkNa VARCHAR2(50); 该表将导致查找 某部门 的员工时，会出现SQL SEL
8、ECT * FROM U_Wk WHERE SUBSTR( WkNo , 1 , 3) = ? ; 合法设计： Create table U_wk( WkNo VARCHAR2 (20) , WkNa VARCHAR2(50) , DeptNo VARCHAR2(3) ); 此设计中，保持WkNo 的编码原则不变，增加一个字段DeptNo , 数值 = SUBSTR( WkNo,1,3) 这种设计一方面提高性能，另外一方面可以加强可读性。1.1.6.2. 外键与外键关键词同表原则外关联比较多的数据表，外键的关键词应同时收列到该表中。有利于提高查询速度以及数据的可读性。1.1.6.3. 建索引的
9、原则 经常需要被放在条件语句中字段，或者业务中经常需要列入查询条件的，可以建立索引。 多个经常被组合在一起使用的字段，可以把这些字段建立组合索引。 多字段组合索引的顺序：取值范围大的字段放在左边，小的放在右边。这种方式，有利于数据库系统更加的迅速定位到所需要的记录。 除非有特殊需要，取值范围不超过10个值的字段，不建立独立索引。1.1.6.4. 巨字段的分割原则。如果一个业务数据表包含BLOB 、CLOB 、LONG RAW 、LONG 等巨字段，应把巨字段应该独立于其他业务数据，单独建立一个数据表存放巨字段，以提高系统查询速度。原理分析： 巨字段将占用大量存储空间，而且一般是非线形存储，而是
10、链型存储。从上一条记录移位到下一条记录，将耗费大量的系统资源与处理时间，从而导致系统查询效率低下；特别是查询条件中，存在无法使用索引的字段，此时查询效率将非常的低下。非法： CREATE TABLE doc_Doc( DocId VARCHAR2(12), DocName VARCHAR2 VARCHAR2 , DocTitle VARCHAR2(200) , CreateTime DATE , CreateDeptNo VARCHAR2,DocContent BLOB ) ; 合法： CREATE TABLE doc_Doc( DocId VARCHAR2(12), DocName VARC
11、HAR2 VARCHAR2 , DocTitle VARCHAR2(200) , CreateTime DATE , CreateDeptNo VARCHAR2 ) ; CREATE TABLE Doc_DocContent( DocId VARCHAR2(12) , DocContent BLOB ) ; 1.1.6.5. 数据库存储设计原则(碎片规避原则)1) 经常被修改的数据表，应单独放置在独立的表空间，不能与其他业务表混合放在同一个表空间。这种表，一般原则是数据表一个表空间，索引一个表空间。原理分析： 经常修改的数据表容易造成数据表空间的存储碎片，不仅会导致数据表本身会有大量不连续空间
12、存在，而且会导致其他数据表存在大量不连续空间，导致数据遍历效率下降。2) 数据量比较大的数据表，应单独放置在独立的表空间，不能与其他业务表混合放在同一个表空间。这种表，一般原则是数据表一个表空间，索引一个表空间。原理分析： 数据量比较大的数据表，如果其存储能够连续存储，将能提高它的处理效率。 如果与其他数据表混合在同一个表空间，其他表的修改活动产生的大量碎片，会导致大数据量数据表的存在大量的不连续空间，从而影响其遍历效率。3) 存在BLOB字段的数据表，应在独立的表空间中。4) 经常会发生修改操作的大数据表，在数据库性能设计时。应周期性的重建索引，以清除索引中存在的碎片。应周期性的倒出数据表，
13、再导入数据表，以清除数据表中存在的碎片。1.1.7. 死锁规避设计原则1） 如果一次事务中的需要修改多个数据表的记录，应有一个关键表；关键表的一条记录，可以唯一的对应事务中多个数据表的记录。2） 如果一次事务中，需要修改一张表的多条记录，应有一个关键表；关键表的一条记录，可以唯一对应事务中的多条记录。3） 在数据库设计中，应根据业务特点，明文约定业务处理中：a) 不同数据表的处理顺序。b) 同一张表的多条记录修改时的排序字段。1.1.8. s国标/行标字段的使用1.1.8.1. 背景1） 公安部门目前制定了不少行业标准的编码体系。2） 目前单位存储容量的价格已经非常便宜；可以考虑适当的冗余，换
14、取较高的系统响应性能、数据可阅读性能。1.1.8.2. 目标1) 每个库结构应该具备公安编码字段，以加强后期与公安不同系统之间可交互能力。2) 每个库结构同时具备编码字段、明文字段。公安标准一般为数字编码，本身没有实际意义；为加强系统查询执行效率，避免过多取值关联造成的查询效率的下降，同时加强系统记录的可读能力，在具备编码字段的同时，每个编码字段都应该具备一个明文字段。如：性别，公安部有编码标准；此时应该有两个字段：sexCode 性别编码 sex 性别明文。1.1.8.3. 命名规则公安部编码字段，一般采用 xxxCode ，明文字段为 xxx 如：性别编码字段 sexCode , 性别明文字段 sex 1.2. 标识符命名的基本原则1.2.1. 总则数据库主要标识符包括：表名、字段名、索引名称等。1) 尽可能采用英文命名，不能采用中文简写或其他无法准确表达标识符含义的方法。2) 为了增加数据结构的可读性，标识符的命名必须能够大致准确表达标识符所表达的作用或内容；不允许出现意义模糊的命名方式，特别是不允许出现一些毫无含义的标识符。举例 合法：D_SrcOrg - 源库所在机构表D_SrcTable - 源库定义
