文档介绍：DOC. NO.
Confidential
(秘密)
数据库结构文档模板
后台管理部分
Version
2003-10-11
All Rights Reserved
目录
文档更新记录
更新内容
更新人员
日期
修改说明
文档创建
饶贵翔
2004-09-30
文档修改
总体思路
设计原则
数据表分布的无关性
如果子系统比较多,数据库结构设计时,应该能够不同业务子系统可以分布在不同数据用户下,同事也可以根据需要合并在同一个数据用户,同时,再数据需要整合到统一信息平台时,能够在信息平台上,按照原来的表名与原来的业务系统数据表一一对应。
在同一个数据用户下不同业务子系统的数据表应能保证
不同业务子系统的数据表的命名,应保持全局唯一性,不应出现同名的数据表。
通过数据表的前缀,区分不同子系统、不同的业务分组。
数据表命名规则:
前缀符_数据表名
前缀符的命名规则,根据项目实际情况制定。
举例:
D 标识公文管理子系统 F 表示公文管理的流程部分;流转内容表可为
DF_Content
数据结构可读能力
数据结构可读能力主要体现在,不需要查询数据库文档:
通过命名就能够得知数据表、数据字段的含义、作用。
通过命名就能够得知不同数据表之间的关联关系。
通过命名、组织方式,就能够基本得知数据表的数据填写规则。
主要方法:尽可能使用英文命名,不使用中文或者简写。
每个英文单词一般都有比较固定、确切的含义,即使使用的单词一时不认识,也可以通过查阅英汉字典既可得知;英汉字典是一个大众化的工具,随处可得。中文拼音存在一下缺陷:
同音字太多。同样的一个拼音,就可能有多个含义;采用中文拼音,数据结构就可能会发生歧义。
如果使用拼音简写,就更加会发生歧义的现象。
因此,不使用中文拼音或者拼音简写。
使用英文单词,可能存在的问题:
公安专业的英文一般有其专业规定,设计人员不一定能够熟知公安专业英语的要求。
有些英文单词比较长
有些中文描述很难找到准确的英文描述。
解决方案:
英文命名不一定要精确的反映业务表、字段的准确含义,只需要基本描述出其含义、作用既可。
可以使用英文简写,并建立简写对照表,供查阅。
英文简写有:业界通用的英文简写以及没有通用的简写。
如果存在业界通用简写或者英语通用简写,应遵照其简写习惯。
数据可阅读可追溯能力
数据编码体系中有不少是采用数字编码。数字编码需要查阅数据字典,才能得知代码代表的含义,可读性不强;在查询时,还需要与数据字典关联,才能得知数据属性,执行效率低。
措施:
为了加强数据数据可阅读能力、提高查询效率,在数据库设计时,一般用一个字段存储编码,另外一个字段存储明文解释。
档案类数据引用。
一个业务数据表往往有用到档案类数据(如商品档案、人员档案、部门档案、单位档案等)。
通常做法是只保留档案编码;这种方法会存在如下问题:
档案类的数据,编码一般只有规则,单个代码并没有明确的对照关系。如果数据表为历史业务资料,当档案中编码对应的对象解释发生改变时,历史信息也随之发生改变。但是,作为历史资料,它应该记载该资料发生时当前的状态;档案数据的变化,将破坏这种状态.。
数据查询时需要关联引用档案数据,才能够得到代码的解释,执行效率慢。
状态类编码、事物分类性编码,如果没有部标规定,建议使用明码。
部标一般规定事物分类性的编码。
事物性编码,可以采用数字编码+明文的方式。
业务历史数据表的设计原则
业务历史数据表主要指记载业务历史信息;业务信息发生后,一般不发生动态变化。如业务受理历史等信息。
业务历史数据表的编码一般采用编码字段+ 明文字段的原则。
历史数据表,要求能够单表脱离原来的关联环境,依然能够还原数据的含义。
例如:
某业务对象的归属单位,一般设计原则是只存放归属单位代码。
这种情况会导致以下现象发生;
a) 归属单位代码所对应的单位名称发生变化,此时
动态数据表的设计原则
数据是动态变化的,如库存数据表等。
这种表的编码一般只需要编码字段。
数据结构的统一性
数据结构的统一包括:标识符命名的统一、逻辑结构的统一。相同业务含义的标识符命名统一。不同业务子系统、不同数据表的字段,如果业务含义相同,其命名相同。
如“性别”字段的统一命名部标编码字段:sexCode , 明文字段:sex
与不同系统可交互能力
公安有非常多的子系统,为了加强数据交互能力,公安部制定了不少编码标准、数据标准。为了保证与其他系统的数据交互能力,凡是存在公安部标准的,都应该使用公安部标准。
性能设计原则
数据库的结果,SQL 条件中不应出现函数
数据库设计的结果,