软件数据库设计报告文档模板Word下载.docx

软件数据库设计报告文档模板Word下载.docx

《软件数据库设计报告文档模板Word下载.docx》由会员分享，可在线阅读，更多相关《软件数据库设计报告文档模板Word下载.docx（13页珍藏版）》请在冰豆网上搜索。

●本项目的合同书；

●上级机关有关本项目的批文；

●本项目已经批准的打算任务书；

●用户界面风格指导；

●开发本项目时所要用到的标准；

●系统规格需求说明；

●利用实例文档；

●属于本项目的其它已发表文件；

●本数据库设计说明书中所引用的文件、资料；

●相关软件产品数据库设计说明书；

为了方便读者查阅，所有参考资料应该按必然顺序排列。

若是可能，每份资料都应该给出：

●标落款称；

●作者或合同签约者；

●文件编号或版本号；

●发表日期或签约日期；

●出版单位或资料来源。

2.数据库命名规那么

完整而且清楚的说明本数据库的命名规那么，在《南京市交通局信息化数据库建设标准》中已经给出了一个完整的数据库命名规那么，开发者应遵守执行，若是本数据库的命名规那么与该标准不完全一致，应作出说明。

3.数据库设计说明

3.1数据库逻辑设计

数据库设计人员依照《软件需求分析报告》，创建与数据库相关的实体关系图（E-R图）。

如采纳面对对象的分析和设计方式，那么此处的实体相当于类。

在此处，应给出逻辑设计的完整的E-R图。

3.2数据库物理设计

在此处应给出完整的数据库物理结构E-R图。

开发者应依照逻辑设计的结果，进行数据库的物理设计，并对表结构进行标准化处置（第一范式，第二范式，第三范式）。

3.3数据库散布

数据库散布采纳一张表格进行描述，其格式如下：

数据库

编号

管理系统

名称

版本号

英文名称

中文名称

安装

物理位置

其中：

●数据库编号

给出本系统中指定数据库的顺序编号。

假设本系统中只有一个数据库，那么本项内容不需要描述，本表内容也只有一行。

说明：

在一个系统中可能安装假设干个相同的或不同的数据库治理系统，

一个数据库治理系统也可能安装一个或多个数据库。

●数据库治理系统名称

给出本系统中指定数据库治理系统的商品名称。

假设本系统中只有一种数据库治理系统，那么本项内容不需要描述。

●数据库治理系统版本号

给出本系统中指定数据库治理系统的版本号。

假设本系统中只有一个版本的数据库治理系统，那么本项内容不需要描述。

●数据库英文名称

给出本数据库的英文名称，该名称是在应用软件中实际利用的名称，必需符合《南京市交通局信息化数据库建设标准》中相关命名标准。

●数据库中文名称

给出本数据库的中文名称，该名称是本数据库英文名称的说明。

●数据库安装物理位置

给出本数据库安装的实际位置，必需描述清楚该位置是在那个物理设备的哪一

个逻辑存储设备上，和存储文件的名称。

3.4基表设计

每一个基表采纳一张表格进行描述，其格式如下：

数据库编号：

基表编号：

基表英文名称：

基表中文名称：

字段编号

英文字段名

中文字段名

字段类型

备注

其中

含义同上。

●基表编号

给出本基表的顺序编号。

●基表英文名称

给出本基表的英文名称，该名称是在应用软件中实际利用的名称，必需符合命

名标准。

●基表中文名称

给出本基表的中文名称，该名称是本基表英文名称的说明。

●字段编号

该基表中，各个字段的顺序编号。

●英文字段名

该基表中，各个字段的英文名称，该名称必需符合《南京市交通局信息化数据库建设标准》中相关命名标准。

●中文字段名

该基表中，各个字段的中文名称，该名称是英文字段名的说明。

●字段类型

该基表中，各个字段的类型；

若是需要，在说明类型时，还需要说明字段长度。

●备注

该基表中，各个字段有关的限制性说明，需要描述的内容可能包括：

值域；

缺省值；

空字段限制；

显示格式与小数位数；

有效性规那么与约束；

题目；

等等

●说明

说明一些有关本表的、必需描述清楚的问题，需要描述的内容可能包括：

主关键字；

索引、排序方式和类型；

触发器；

数据复制；

3.5视图设计

每一个视图采纳一张表格进行描述，其格式如下：

视图编号：

视图英文名称：

视图中文名称：

相关基表和视图：

字段源

●视图编号

给出本视图的顺序编号。

●视图英文名称

给出本视图的英文名称，该名称是在应用软件中实际利用的名称，必需符合

命名标准。

●视图中文名称

给出本视图的中文名称，该名称是本视图英文名称的说明。

●相关基表和视图

列出成立该视图时，所用到的基表和视图。

该视图中，各个字段的顺序编号。

该视图中，各个字段的英文名称，该名称必需符合《南京市交通局信息化数据库建设标准》中相关命名标准。

该视图中，各个字段的中文名称，该名称是英文字段名的说明。

该视图中，各个字段的类型；

●字段源

该视图中，各个字段的来源，即该字段原先是那个表或那个视图中的那个字

段；

在某些情形下，字段可能来自一个特定的表达式。

该视图中，各个字段有关的限制性说明，包括：

等等。

说明一些有关本视图的、必需描述清楚的问题，需要描述的内容可能包括：

索引；

权限；

3.6索引设计

每一个数据库的所有采纳一张表格进行描述，其格式如下：

索引编号

基表名称

索引名称

字段集名称

●索引编号

给出本项索引的顺序编号。

●基表名称

给出本项索引所在的基表名称。

●索引名称

给出本项索引的名称。

●字段集名称

给出本项索引所在的字段名称或字段集名称。

描述有关本项索引中，其它需要说明的事项，例如：

排序方式、等等。

3.7完整性约束

每一个数据库的完整性约束采纳一张表格进行描述，其格式如下：

●约束编号

给出本项完整性约束的顺序编号。

●完整性约束名

给出本项完整性约束的名称。

●基表名

给出本项完整性约束所在的基表名称。

●字段名

给出本项完整性约束所在的字段名称。

●约束表达式

给出本项完整性约束的逻辑表达式。

描述有关本项完整性约束中，其它需要说明的事项。

3.8授权设计

每一个数据库的授权采纳一张表格进行描述，其格式如下：

授权编号

用户名称

对象名称

权限

●授权编号

给出本项授权的顺序编号。

●用户名称

给出本项授权的用户名称，那个地址的用户不必然是具体用户，也能够是用户组。

●对象名称

给出本项授权的对象名称，例如：

基表、字段、等等。

必需注意到，一个用户可能存在多项授权，应该逐项描述。

●权限

被授权用户在该对象上拥有的访问权限，例如：

查询权、修改权、等等。

描述有关本项授权中，其它需要说明的事项。

3.9触发器设计

●触发器编号

给出本触发器的顺序编号。

●触发器英文名称

给出本触发器的英文名称，必需符合《南京市交通局信息化数据库建设标准》中相关命名标准。

●触发器中文名称

给出本触发器的中文名称，该名称是本触发器英文名称的说明。

●触发器条件

给出该触发器产生触发的条件。

●触发器结果

给出该触发器被触发后所执行的动作内容。

3.10存储进程设计

存储过程编号：

存储过程英文名称：

存储过程中文名称：

存储过程内容：

●存储进程编号

给出本存储进程的顺序编号。

●存储进程英文名称

给出本存储进程的英文名称，该名称是在应用软件中实际利用的名称，必需符

合命名标准。

●存储进程中文名称

给出本存储进程的中文名称，该名称是本存储进程英文名称的说明。

●存储进程内容

给出该存储进程算法或描述详细内容，若是需要，应该辅以流程图说明。

描述本存储进程需要说明的一些事项。

3.11数据复制设计

每项数据复制采纳一张表格进行描述，其格式如下：

数据复制编号：

复制英文名称：

复制中文名称：

源数据库编号：

目标数据库编号：

复制说明：

执行方式：

源数据库名称

目标数据库名称

字段名称

备注：

●数据复制编号

给出本数据复制的顺序编哥

●数据复制英文名称

给出本数据复制的英文名称，该名称是在应用软件中实际利用的名称，必需符

●数据复制中文名称

给出本数据复制的中文名称，该名称是本数据复制英文名称的说明。

●源数据库编号

作为复制数据源的数据库编号，编号含义同上。

●目标数据库编号

作为复制目标的数据库编号，编号含义同上。

●复制说明

给出该复制的详细描述，若是需要，应该辅以示用意说明。

●执行方式

给出该复制的执行方式，描述时应该说明：

●自动执行

必需说明执行周期或执行条件。

●挪用执行

必需说明被那个模块挪用，和是手动挪用，仍是条件挪用。

●源数据库名称

给出对应源数据库编号的源数据库名称。

●目标数据库名称

给出对应目标数据库编号的目标数据库名称。

别离给出源数据库和目标数据库中，进行对应复制的源基表名称和目标基表名

事例。

●字段名称

别离给出源基表和目标基表中，进行对应复制的源字段名称和目标字段名称。

描述本复制中需要说明的一些特殊事项。

4.辞汇表

列出本文件顶用到的专业术语的概念，和有关缩写的概念（如有可能，列出相关的

外文原词）。

为了便于非软件专业或非运算机专业人士（例如：

文档编写人员等等。

）

阅读数据库设计说明书，要求利用非软件专业或非运算机专业的术语进行描述。

因此那个地址所指的专业术语，是指业务层面上的专业术语，而不是软件专业或运算机专业的术语。

可是，关于无法回避的软件专业或运算机专业术语，也应该列入辞汇表，而且加以准肯概念。

5.历史数据处置

严格说来，历史数据处置并非属于数据库设计范围。

可是关于大多数数据库来讲，若是历史数据处置不妥，少那么数月、多那么数年，最终将使数据库无法正常运行。

这段时刻的长短取决于数据库设计容量大小，和数据流强度（即在单位时刻内进入数据库的数据记录数量）高低。

因此应该设计专门的归档数据库，并依照历史数据需要保留备查的时刻长短，按期将历史数据转移到归档数据库中。

设计归档数据库时，需要依照具体情形进行考虑，下面列出一些可能需要考虑的内容：

●历史数据需要备查的时刻长短。

●数据转移周期的时刻单位

例如：

日、周、旬、月、季、年、等等。

●数据转移的方式

手动、自动、条件、等等。

●历史数据保留的细节

多数情形下，归档的历史数据并非需要保留全数细节，能够去掉部份细节，采

用紧缩归档处置的方式减少归档数据库的占用空间。

注意：

若是紧缩数据时，去掉了不该去掉的细节，将是无可挽回的。

●其它需要说明的问题