Ⅰ 数据库需求分析
用户的需求具体体现在各种信息的提供、保存、更新和查询，这就要求数据库结构能充分满足各种信息的输出和输入。收集基本数据、数据结构以及数据处理的流程，组成一份详尽的数据字典，为后面的具体设计打下基础。
在本系统设计中，由于考虑到各种数据信息均具有空间属性，即与区域或位置相关，因此在数据库设计时，使用空间数据库和属性数据库共同管理数据的方式，实现空间数据属性和非几何属性的协同管理。
Ⅱ 需求规格说明书包括哪两个部分
三、需求规格说明书
1．引言 1
1.1编写目的 1
1.2项目背景 2
1.3定义 2
1.4参考资料 2
2．任务概述 2
2.1目标 2
2.2运行环境 2
2.3条件与限制 2
3．数据描述 3
3.1静态数据 3
3.2动态数据 3
3.3数据库介绍 3
3.4数据词典 3
3.5数据采集 3
4．功能需求 3
4.1功能划分 3
4.2功能描述 3
5．性能需求 3
5.1数据精确度 3
5.2时间特性 3
5.3适应性 4
6．运行需求 4
6.1用户界面 4
6.2硬件接口 4
6.3软件接口 4
6.4故障处理 4
7．其它需求 4
1．引言
1.1编写目的
【阐明编写需求说明书的目的，指明读者对象。】
为明确软件需求、安排项目规划与进度、组织软件开发与测试，撰写本文档。
本文档供项目经理、设计人员、开发人员参考。
1.2项目背景
a. 项目的委托单位、开发单位和主管部门
b. 该软件系统与其他
1.3定义
【列出文当中所用到的专门术语的定义和缩写词的原文。】
1.4参考资料
a. 项目经核准的计划任务书、合同或上级机关的批文
b. 项目开发计划
c. 文档所引用的资料、标准和规范。列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源
2．任务概述
2.1目标
2.2运行环境
操作系统：Microsoft Windows 2000 Advanced Server
支持环境：IIS 5.0
数 据 库：Microsoft SQL Server 2000
2.3条件与限制
3．数据描述
3.1静态数据
3.2动态数据
【包括输入数据和输出数据。】
3.3数据库介绍
【给出使用数据库的名称和类型。】
3.4数据词典
3.5数据采集
4．功能需求
4.1功能划分
4.2功能描述
5．性能需求
5.1数据精确度
5.2时间特性
【如响应时间、更新处理时间、数据转换与传输时间、运行时间等。】
5.3适应性
【在操作方式、运行环境、与其它软件的接口以及开发计划等发生变化时，应具有的适应能力。】
6．运行需求
6.1用户界面
【如屏幕格式、报表格式、菜单格式、输入输出时间等。】
6.2硬件接口
6.3软件接口
6.4故障处理
7．其它需求
【如可使用性、安全保密、可维护性、可移植性等。】
Ⅲ 怎么写需求说明书
需求说明书范文
汉语编程企业管理应用软件
需求说明书
1 引言
对软件需求完全理解对于软件开发工作的成功是至关重要的，需求说明的任务是发现、规范的过程，有益于提高软件开发过程中的能见度，便于对软件开发过程中的控制与管理，便于采用工程方法开发软件，提高软件的质量，便于开发人员、维护人员、管理人员之间的交流、协作，并作为工作成果的原始依据，并且在向潜在用户传递软件功能、性能需求，使其能够判断该软件是否与自己的需求相关。
1.1 编写目的
1.1.1 为开发人员、维护人员、客户之间提供共同的协议而创立基础，对企业管理软件功能的实现作使命描述。
1.1.2 本说明书的预期读者为客户、业务或需求分析人员、测试人员、用户文档编写者、项目管理人员。
1.2 背景及范围
1.2.1 工程的名称：汉语编程企业管理应用软件 1.2.2 工程产品的名称：汉语编程企业管理应用软件 1.2.3 工程的组织者：北京元易达科技发展有限责任公司 产品的生产者：汉语编程企业管理应用软件开发课题组 产品的设计者：汉语编程企业管理应用软件开发课题组
1.2.4 产品的所有权：汉语编程企业管理应用软件开发课题组
1.3 定义,术语,缩写词和略语 企业管理应用系统软件：它是由企业管理应用系统软件课题组完全自主开发的企业管理软件，以企业各部门为基本元素的、用汉语编程来实现其功能的软件。 需求：用户解决问题或达到目标所需的条件或功能；系统或系统部件要满足合同、标准，规范或其它正式规定文档所需具有的条件或权能。
需求分析：包括提炼，分析和仔细审查已收集到的需求，以确保所有的风险承担者都明其含义并找出其中的错误，遗憾或其它不足的地方。
模块的独立性：是指软件系统中每个模块只涉及软件要求的具体的子功能，而和软件系统中其他的模块的接口是简单的。 1.4 参考资料
《汉语程序设计语言》---- 沈志斌 编着 电子工业出版社
《 计算机系统导论》 ---- 刘瑞挺 编着 高等教育出版社
《 数据库原理与方法》---- 郑若忠 王鸿武 编着 湖南科学技术出版社 《 软件需求 》 ---- （美） Karl E.Wiegers 着
陆丽娜 王忠民 王志敏 等译
2 项目概述
2.1 目标
本软件的目标使企业管理电子化、简单化，以节省企业管理方面的不必要的资源浪费。对于企业管理应用系统软件最终用户为企业的管理人员。 2.1.1 开发意图
目前中小企业在日常工作中采用人工管理，因而存在着大量的浪费和多余，本软件根据此要求进行开发。 2.1.2 应用目标
企业管理应用系统软件将解决企业管理人工化，工作繁余的问题，实现企业管理电子化。
2.1.3 作用及范围
本企业管理应用系统软件是应用于中小企业的。目前，中小企业管理比较落后，它将产生的影响将使中小企业管理从人力化到数字化进展，使管理人员思想上向数字化转变，能使企业的管理在机制上转换，人员上得到精简。 2.1.4 背景
企业管理应用系统软件以汉语编程为开发语言，各部门以模块的形式完成。 2.2 产品描述
本产品开发语言核心为汉语编程语言，具体实现是汉语编程和VF数据库技术相结合开发而成的。本产品面向中小企业，易懂好学，帮助企业管理人员从手工劳动向电子化、数字化转变。 2.2.1 相关关系
本产品是一项独立的软件，全部内容自含。 2.2.2 子集说明
本产品分别有五个模块组成，每个模块各有不同的功能。但都能完成查询和存储功能，各模块的数据都存放在数据库中。数据的调用和连接都有程序来完成，硬件外部设备需奔腾133以上的pc机，内存需16兆以上。
2.3 产品功能 2.3.1 外部功能
企业管理应用系统软件外部功能包括可视化窗口，查找存储。 2.3.2 内部功能
企业管理应用系统软件内部功能：过滤、定位、使用库等。 2.3.3 功能表
2.3.4 功能表述图
2.4 用户特点
汉语编程企业管理应用软件面向于中小企业，其使用人员应为具备一定的计算机基础知识和企业管理基本知识。而本产品的维护人员需要具备有汉语编程知识。
2.5 一般约束
a. 本系统开发人员为12人。
b. 有CPU133、16兆内存配置的计算机就可运行本系统。 c. 在管理方针、并行操作、安全与保密方面无约束。
2.6 假设与依据
本软件在开发的过程中，分为技术实现与软件工程两大部分，两部分都有侧重点，若技术支持出现故障或疑难问题无法解决、程序开发出现偏差，会延误工程进度，影响工程的按期完工。若软件工程陈述出现问题，部分描述含混不清，
则会影响系统的完整性与可继承性。在管理方面，如管理者没有预见性，对出向的问题无法采用可行的解决手段，都会影响开发模块之间的互动，从而影响工程的顺利开展，导致工程无法按期完工。 3 具体需求 3.1 功能需求 3.1.1 使用库
3.1.1.1 规格说明
3.1.1.2 引言
显示所调用的数据库。 3.1.1.3 输入
指定的库文件名。 3.1.1.4 加工
调用指定的数据库。 3.1.1.5 输出
显示所指定的数据库的库结构。 3.1.2 编辑框控制 3.1.2.1 规格说明
生成编辑框。 3.1.2.3 输入 编辑框名称。 3.1.2.4 加工 生成编辑框。 3.1.2.5 输出
显示生成的编辑框。 3.1.3 为当前记录 3.1.3.1 规格说明
3.1.3.2 引言
将指定的记录置为当前记录，下一步可以开始对此记录进行操作。 3.1.3.3 输入
指定的项名及库文件名。 3.1.3.4 加工
将指定的数据库里指定的记录置为当前记录。 3.1.4 建库文件 3.1.4.1 规格说明
输入库文件名,使用"建库文件"命令，建立一个新的数据库。 3.1.4.3 输入 库文件名。 3.1.4.4 加工
建立新的数据库。 3.1.4.5 输出 新建的数据库。 3.1.5 开始尺寸 3.1.5.1 规格说明
3.1.5.2 引言 在程序中，在"开始尺寸"前给出参数值，能确定指定的对象的开始尺寸的大小。
3.1.5.3 输入 参数值。 3.1.5.4 加工
确定指定对象在窗体中的开始尺寸的大小 3.1.5.5 输出
确定开始尺寸的四个参数 3.1.6 开始位置 3.1.6.1 规格说明
3.1.6.2 引言 在程序中，在"开始位置"前给出参数值，能确定指定的对象的开始尺寸的大小。
3.1.6.3 输入 参数值。 3.1.6.4 加工
确定指定对象在窗体中的开始位置。 3.1.6.5 输出
确定开始位置的四个参数 3.1.7最大尺寸 3.1.7.1 规格说明
3.1.7.2 引言 在程序中，在"最大尺寸"前给出参数值，能确定指定的对象在窗体中的最大尺寸。
3.1.7.3 输入 参数值。 3.1.7.4 加工
确定指定对象在窗体中的最大尺寸。 3.1.7.5 输出
确定指定对象最大尺寸的四个参数。
3.1.8 最小尺寸 3.1.8.1 规格说明
3.1.8.2 引言 在程序中，在"最小尺寸"前给出参数值，能确定指定的对在窗体中的最小尺寸。
3.1.8.3 输入 参数值。 3.1.8.4 加工
确定指定对象在窗体中的最小尺寸。 3.1.8.5 输出
确定指定对象最小尺寸的四个参数 3.1.9 查词编辑框（编辑框控制） 3.1.9.1 规格说明
3.1.9.2 引言
主要是定义的一个编辑框，供用户输入一个词名，为程序生成查找条件做准备。
3.1.9.3 输入
在查词编辑框中输入要查找的词名。 " 编辑框控制 查找编辑框 " 3.1.9.4 加工
用输入的词名以供程序生成查找条。 3.1.9.5 输出
地址、长度。 。
3.1.10 内容编辑框（编辑框控制） 3.1.10.1 规格说明
3.1.10.2 引言
主要是定义的一个编辑框，将程序查找到的用户所输入词的相关内容显示出来，为用户提供帮助信息。 3.1.10.3 输入
数据库中查找到的记录的项的内容的地址、长度。 " 编辑框控制 内容编辑框 " 3.1.10.4 加工 置控制标题或值。 3.1.10.5 输出
显示用户所输入词的相关内容（如该词的格式、用法……）。 3.1.11 过滤
3.1.11.1 规格说明
3.1.11.2 引言
定义用户输入的词名与内容库中的词名字段中的词名进行串比较，即定义词名字段为过滤字段。 3.1.11.3 输入 用户输入的词名。 3.1.11.4 加工
把代码写入过滤条件指针之中。 3.1.11.5 输出 查找条件。
3.1.12 执行过滤 3.1.12.1 规格说明
3.1.12.2 引言
将定义的过滤作为内容库的过滤条件。 3.1.12.3 输入 查找条件。
3.1.12.4 加工
与查找编辑框中的内容比较。 3.1.12.5 输出 库过滤显 。 3.1.13 取低字 3.1.13.1 规格说明
3.1.13.2 引言
取数摞中的一个32位数的低16位放在数摞上。 3.1.13.3 输入
调用WINDOWS API 函数。 3.1.13.4 加工 3.1.13.5 输出 相应的执行功能 3.1.14 白线框 3.1.14.1 规格说明
3.1.14.2 引言
定义查看区一个白颜色的线框。
3.1.14.3 输入
参数、颜色
3.1.14.4 加工
空心矩形： 设备描述表
3.1.14.5 输出
线框。
3.2.1 动态数值需求
预处理的窗口正常情况下和峰值工作条件下为20个，一定时间周期中要处理的数据的数量：窗口开始尺寸2个数据，开始位置2个数据，最大尺寸2个数据，最小尺寸2个数据，编辑框位置4个数据，按钮位置4个数据，平均处理的数据约为16个数据。
3.2.2 静态数值需求
a. 支持的终端数为1台；
b. 支持并行操作的用户总数为5位；
c. 处理5个文件及10条记录；
d. 表或文件的最小为266字节,最大为4字节；
3.2.3 精度需求
在进行向数据库文件提取数据时，要求数据记录定位准确，在往数据库文件数组中添加数时，要求输入数准确。
3.2.4 时间特性需求
a. 响应时间应在人的感觉和视觉事件范围内；
b. 更新处理时间，随着汉语编程系统的版本升级，汉语编程企业管理应用系统将相应的进行更新；
3.2.5 灵活性
当需求发生某些变化时，汉语编程企业管理应用软件操作方式、数据结构、运行环境基本不会发生变化，变化只是将对应的数据库文件内的记录改变，或将过滤条件改变即可。
3.2.6 数据管理能力需求
汉语编程企业管理应用软件需要管理5个文件和10条记录，表文件的大小平均约为1.5k字节，汉语编程企业管理应用软件基本约用10 M字节空间，所有文件均放置在数据库中，调用，查询数据，文件，记录时，通过库文件名直接进行操作。
3.2.7 故障处理需求
无故障。
3.3 设计约束条件
3.3.1 技术约束
本工程产品的约束条件包括：
a. 数据库、各种控键的使用和消息的调用；
b. 汉语数据库过滤完成、编辑框的触发等；
3.3.2 环境约束
运行本软件需要奔腾133以上 PC，内存需要在16兆以上，对使用设备的速度、规模要求不高。
3.3.3 标准约束
汉语编程企业管理应用软件完全按照北京元易达科技发展有限责任公司企业标准开发，包括硬件、软件和文档规模。
3.4 接口需求
3.4.1 用户接口
本工程产品通过PC机进行运行、操作，对报表、菜单的打印将使用汉语编程编辑器或调入WORd进行打印。输出、输入的相对时间将由pc机本身处理速度来决定。对程序的维护，需进行必要的备份。
3.4.2 硬件接口
本工程产品不需要特定的硬件或硬件接口进行支撑。
3.4.3 软件接口
本工程产品的软件接口由汉语编程操作系统、汉语编程数据库以及汉语编程企业管理应用软件的词典和数据结构组成。
3.4.4 通讯接口
本工程产品的没有特殊的通讯接口，通讯接口由所使用的pc机决定。
3.5 属性
3.5.1 可用性
本软件是完全由汉语程序设计语言开发的，汉语编程最大特点编译解释和一，它可以进行单步跟踪。一旦出现错误就可以通过单步跟踪进行查找处理，所以本软件也可以通过单步跟踪的操作进行检查处理。
3.5.2 安全性
本软件大量的参数及文本内容全部放于汉语编程数据库中，所以参数不容易被错改、破坏，万一参数受到破坏也不会影响源程序。
3.5.3 可维护性
本软件利用数据库进行编程，系统结构由程序基本确定，大量的参数及文本内容全部放于汉语编程中。修改、更新数据只要在数据库进行修改添加，而不需要对系统结构进行修改，这样系统维护性、升级都十分方便。
3.5.4 可转移、可转换性
汉语编程的兼容性很高，在windows95/98 .windowsNT .windows1700 .操作系统都可以直接运行。
3.5.5 注释
通过"看数摞"、"看内存"、"印字符"三条汉编基本指令，就可以将所有汉编
成程序进行调试和检查。本系统的大量参数和文本全部放在数据库中，通过"使用库"、"库显"等一些汉编数据库基本操作就可以查看、添加、修改系统。 4 支持信息
4.1 支持软件
本软件开发是使用汉语编程编写，编译系统为"32位汉语编程系统"，版本号为2.01.0061。在库调用时兼容Visual Foxpro 6.0英文版，源程序的测试是使用汉语编程自身含有的"看数摞、看内存、看词"的方法进行测试，即支持测试的软件也是汉语编程操作系统本身。由于汉语编程本身的特点，它的关键词、命令等全部为中文，所以在使用汉语编程系统时需要中文输入法的支持。
4.2 设备
a. 具有奔腾133、16兆内存配置的计算机；
b. Microsoft鼠标或其它兼容鼠标；
c. 最少15MB的硬盘空间，常规安装需要100MB硬盘空间，完全安装需要240MB硬盘空间。
d. 最少8MB的RAM存储器。
e. VGA显示器或更高。
f. Windows95中文版或Windows NT中文版或更高。
g. 一般计算机外设，如：打印机、扫描仪。如要配置网络环境，还需网络连接设备。
4.3 控制
本软件是在汉语编程系统的支持下，展示界面由主窗口与子窗口嵌套而成，窗口操作通过按钮控制，不同的按钮进行不同的操作实现不同的功能。
4.4 接口
本软件在库的调用时兼容Visual Foxpro 6.0英文版的表结构文件，但不能与Visual Foxpro 6.0英文版在一个操作系统环境中同时运行。
4.5 文档 本系统相关的文档为： 《汉语编程企业管理应用软件可行性研究报告》 编号：MNQB01-QG-01 《汉语编程企业管理应用软件需求说明书》 编号：MNQB03-QG-01 《汉语编程企业管理应用软件操作手册》 编号：MNQB11-QG-01
4.6 附录
a. 输入输出格式样本采用IPO表逐项定量的叙述对本系统软件提出的功能需求，如下图：
b. 本系统软件的背景信息如下：
汉语编程是本公司自行开发，自主版权的以汉语为描述语言的计算机程序设计语言。该语言绝非曾流行过的任何一种计算机语言的简单汉化，或是为某种软件制造一个中文环境。这是一个完全由本公司自行开发，由本公司掌握全部源代码，从形式到内容全面符合中国人的思维方式，使用汉文字表达的计算机程序设计通用语言。Windows环境下的汉语编程，可以用于Windows窗口程序、多媒体应用、数据库开发、网络传输、电子商务等应用领域。对于较初级计算机用户，在极短的时间内，可以达到很高的编程水平。
Ⅳ 基于asp,access数据库的图书管理系统需求规格说明书
摘要 介绍了信息中心图书管理系统数据库的设计。该系统是运行在学校内的图书管理系统，实现了图书资料的计算机管理和图书查询功能。
关键词 图书 网络 管理系统 数据库
1 引言
一直以来人们使用传统的人工方式管理图书馆的日常工作，对于图书馆的借书和还书过程，想必大家都已很熟悉。在计算机尚未在图书馆广泛使用之前，借书和还书过程主要依靠手工。一个最典型的手工处理还书过程就是：读者将要借的书和借阅证交给工作人员，工作人员将每本书上附带的描述书的信息的卡片和读者的借阅证放在一个小格栏里，并在借阅证和每本书贴的借阅条上填写借阅信息。这样借书过程就完成了。还书时，读者将要还的书交给工作人员，工作人员根据图书信息找到相应的书卡和借阅证，并填好相应的还书信息，这样还书过程就完成了。
以上所描述的手工过程的不足之处显而易见，首先处理借书、还书业务流程的效率很低，其次处理能力比较低，一段时间内，所能服务的读者人数是有限的。利用计算机来处理这些流程无疑会极大程度地提高效率和处理能力。我们将会看到排队等候借书、还书的队伍不再那么长，工作人员出错的概率也小了，读者可以花更多的时间在选择书和看书上。
为方便对图书馆书籍、读者资料、借还书等进行高效的管理，特编写该程序以提高图书馆的管理效率。使用该程序之后，工作人员可以查询某位读者、某种图书的借阅情况，还可以对当前图书借阅情况进行一些统计，给出统计表格，以便全面掌握图书的流通情况。
本次作业设计题目：“图书管理系统”主要目的是利用数据库软件编制一个管理软件，用以实现图书、读者以及日常工作等多项管理。同时对整个系统的分析、设计过程给出一个完整论证。
图书管理系统是一种基于集中统一规划的数据库数据管理新模式。在对图书、读者的管理，其实是对图书、读者数据的管理。本系统的建成无疑会为管理者对图书管理系统提供极大的帮助。
2 系统设计
2.1 系统指导思想和建设目标
2.1.1 系统指导思想
立足于校园实际，着眼于未来发展，建成符合标准化协议、通用性较强、实用的系统，以提高图书信息的现代化管理水平，实现信息资源的共享。
2.1.1 系统建设目标
（1）要解决的问题：（以某学校为参照） 随着办公自动化水平的不断提高，现在学校管理学生信息也逐步从手工转到计算机自动化信息处理阶段。设计一个功能完整、操作简便、界面友好的学生信息管理系统已经是势在必行的了。
（2）系统开发的目的：提高图书管理工作的效率，减少相关人员的工作量，使学校的图书管理工作真正做到科学、合理的规划，系统、高效的实施。
（3）系统名称：图书管理系统
2.2 总体功能设计
系统要能实现如下功能：
l 登录系统：注销用户、系统退出。
l 管理：用户管理、图书管理、读者管理、借阅管理。
l 查询：图书查询、读者查询、借阅查询。
l 报表打印：所有图书、借出图书、库存图书、所有读者。
l 帮助：使用说明、关于。
3 数据库设计
3.1 数据库系统的选择
本系统是一个中小型管理系统，运行环境是Windows2000 server，因此使用Windows环境下最容易使用且功能还可以的Microsoft Access 2000 作为后台的数据库系统。
3.2 需求分析
图3 图书流通数据流图
1．2
判断能
否借书
索书
信息
读 者
1．2
办理借
书手续
读者信息
查询结果
借书申请
被借图书
借书结果
借书信息
被借图书复本量
(b) 借书
借阅
3
读者
1
图书
5
1．1
图书
查询
借书信息
查询
4
判断
2
判断结果
索书
信息
图书信息
读 者
1
借书
2
还书
读 者
申请借书
还书申请
借书结果
还书结果
(a) 顶层数据流图
3
办借
书证
读者信息
办证信息
需求分析是数据库设计首先要做的工作，通过需求分析，我们作出了图书管理系统的各层数据流图，图3是图书流通数据流图（图中省略了“还书”和“办理借书证”的数据流图）。
在数据流图的基础上，定义数据字典。数据字典是关于数据库中数据的描述，它的作用是在软件分析和设计过程中为有关人员提供关于数据描述信息的查询，以保证数据的一致性。下面在图3的基础上举例说明数据字典的定义。
图3中涉及很多数据项，其中数据项“读者编号”可以描述如下：
数据项名：读者编号
别名：读者条码
含义：唯一标识每个读者
类型：字符型
取值范围：00000000至99999999
取值含义：顺序编号
“读者”一个数据结构，它可以描述如下：
数据结构名：读者
含义说明：是图书管理系统的数据结构之一，定义了一个读者的有关信息
组成：读者编号，姓名，性别，单位
数据流“借阅记录”可描述如下：
数据流名：借阅记录
说明：读者的借书记录
数据来源：办理借阅手续
数据去向：借阅
数据结构：读者编号、图书馆藏号、借阅日期
数据存储“借阅”可以描述如下：
数据存储名：借阅
说明：记录读者的借书情况
流出数据流：借阅记录
流入数据流：借阅记录
数据描述：读者编号、图书馆藏号、借阅日期
数据量：每年5000条以上
存取方式：随机存取
处理过程“判断能否借书”可描述如下：
处理过程“判断能否借书”
说明：根据读者的已借书情况可被借图书的馆藏情况判断读者能否借书
输入：借阅记录、读者信息、被借图书信息
输出：能否借书的标志
处理：读者提出借书请求后，先判断该读者以前的借书量是否达到了10本，如果达到了10本，则不能再借书，如果没有达到10本，则再判断读者要借的图书的可借量是否为0，如果不为0，则该书可以借出。
3.3 数据库设计
在图书管理系统中，数据库设计占重要位置，数据库设计质量的优劣，可直接影响到数据库数据的冗余度、数据的一致性、数据丢失等问题。下面就系统数据库规范化设计进行说明。
3.3.1 数据库设计的理论指导
数据库设计的理论指导是范式理论，其主要内容如下：
1）如果关系模式R，其所有的域为单纯域则称R是规范化的关系，或称第一范式 (1NF)
2）如果关系模式R为第一范式，且每个非主属性完全函数依赖于码，则模式R为第二范式（2NF）。
3) 如果关系模式R为第二范式，且每个非主属性非传递依赖于码，则称关系模式R为第三范式(3NF)。
4)关系模式R为第一范式，满足函数依赖集合F，X和A均为R的属性集合，且X不包含A，如果R满足X－>A且X必包含R的码，称关系模式R为BCNF范式。
3.3.2 数据库设计
图书管理系统数据库常常要设计含有如下数据项：借书证号、姓名、单位、馆藏号(馆藏号为每本书上的条形码号)、书名、分类号、作者、价格等。如何进行模式的设计呢？下面以图书流通模块所涉及的数据库为例来说明。
图 书
读 者
借阅
m
n
借阅时间
馆藏号
书名
分类号
作者
价格
借书证号
姓名
性别
图4 图书流通的E-R图
属于
单 位
1
n
单位名称
单位编号
先设计图书流通的实体－关系图(E-R图)。E-R图由3个相关联的部分构成，即实体、实体与实体之间的关系以及实体和关系的属性。图书流通过程中实体“图书”与“读者”之间的关系是借阅和被借阅的关系，实体“读者”与“单位”之间的关系是属于和被属于的关系，“图书”的属性有“馆藏号”、“书名”、“分类号”、“作者”、“价格”，“读者”的属性有“借书证号”、“姓名”、“性别”，“单位”的属性有“单位编号”和“单位名称”，“借阅”属性“借书日期”，由此得出E-R图如图4。
从图中可以知道：
①“借书证号”是唯一的，所以“借书证号”决定“姓名”，每位读者应只属于一个性别，所以“借书证号”也决定“性别”；
②“馆藏号”是唯一的，所以“馆藏号”决定“书名”、“分类号”、“作者”、“价格”；
③ “单位编号”是唯一的，所以“单位编号”决定“单位名称”；
④ 每位读者在一个时间只能借一本书，所以“借书证号” +“馆藏号”决定“借阅时间”。
如果将这些数据项置于一个关系模式中，根据范式理论，该关系模式属于1NF（第一范式），它存在删除异常和冗余等问题，不是理想的模式，因此要把它分解成满足3NF或BCNF的关系模式。根据范式理论和E-R图转换成关系模型的规则，上面的E-R图可转换为4个关系模式：①图书（馆藏号、书名、分类号、作者、价格）；②读者（借书证号、姓名、性别、单位编号）；③借阅（借书证号、馆藏号、借阅时间），④单位(单位编码、单位名称)，其中打下划线的为码，这样就解决了插入、删除和数据冗余等问题。
我们对数据的结构进行详细的分析，按照上述的设计思想，共设计了读者表，书目表，馆藏表，流通表等百余张数据表，然后创建视图和存储过程。下面举例说明：
读者表：借书证号、姓名、单位、读者类别、职称等字段；
书目表：馆藏号、ISBN、题名、作者、出版社、复本数、语种、文献类型、版次等字段；
馆藏表：馆藏号、索书号、分类号、种次号、馆藏位置、单价、出版日期等字段；
流通表：借书证号、馆藏号、借期、还期、续借、应还期、操作员等字段；
借阅规则表：读者类别编码、图书类别编码、限借册数、每期天数、续借天数、过期日期、罚金等字段。
读者类别表：读者类别编码、读者类别等字段。
图书类别表：图书类别编码、图书类别等字段。
3.4 数据库索引
建立索引是加快查询速度的有效手段，数据库的每一个表建立了主键，主键由一个或几个字段组成，每一个表都按主键建立了索引，部分表为了满足查询和排序的需要，除建立主索引外，还建立了次索引。例如在查询时要用到“馆藏号”、“作者”、“题名”等条件来查找图书，因此，在书目表上除了对主键“馆藏号”建立了主索引外，也对“作者”、“书名”等建立了次索引。
3.5 视图
视图是从一个或几个基本表导出的表，它是定义在基本表之上的，它是一个虚表，数据库中只存放视图的定义，而不存放视图对应的数据，数据仍然存放在原来的基本表中。通过定义视图，可以使用户眼中的数据库结构简单、清晰，并可以简化用户的数据查询操作。由于本系统数据表较多，表中的字段多，为了简化对表的操作，我们创建了图书_按书名查询、期刊_按刊名查询、期刊_按编辑部查询、借阅规则查询、待还书查询、超期记录查询等30余个视图。
3.6 存储过程
存储过程是一段经过编译的程序代码，存放在数据库服务器端。通过调用适当的存储过程，可在服务器端处理大量数据，再将处理结果送到客户端。这样可减少数据在网络上的传送，消除网络阻塞现象；例如：要查询某条记录，若该记录在表中的顺序号是10000，不采用存储过程，服务器将从1至于10000条记录数据逐条送至客户端，采用存储过程后，由于过程是经过编译的并且是在本地，不需要通过网络，因此能很快查出所需记录并将结果送到客户端，大大减少了网上数据传输量。存储过程另一好处是可供不同的开发工具调用，如PB、VB、ASP、Delphi等开发工具均可调用。在流通模块和WEB查询模块上均有图书检索功能，实际上调用同一存储过程完成的。本系统建立了60多个存储过程，实现诸如借还书处理、新书入库统计、编目入馆藏、读者统计、生成索书号等功能。
3.7 数据库调用
采用ODBC接口实现数据库的调用，采用ADO接口调用。
4 条形码的使用
条形码具有唯一性和一次输入后就可反复使用的优点，利用条形码技术作为信息快速输入的手段可迅速且不易发生错误地处理图书管理业务。本系统使用条形码作为图书和读者的标识，实现标识的唯一性。
使用条码后，能够使图书管理工作更加简单、快捷、不易出错。例如，当一本书具有唯一条形码标识，每位读者也具有唯一条形码标识时，图书的借阅、查询就十分便捷了。应用条形码取代了以往填写书袋卡、借书证，核对借阅时间等繁琐的手工劳动。读者在借书时只要将借书证给工作人员，工作人员只需登录借书系统，用条形码阅读器扫描读者借书证上的条形码，屏幕就会显示出该读者的信息，包括读者姓名、单位、可借几本书、已借几本书、是否过期、有无罚款等。如可以借书，工作人员只需用条形码阅读器扫描该读者所需借的书上的条形码符号后，该书的书名和条形码等信息都从数据库中调出显示在屏幕上，自动记录在该读者的借阅档案中，借书工作即告完成。一般借一本书仅需 1至 2秒钟。操作完后，计算机自动地将该借阅者和借阅的图书号码输入对应数据库中，并自动提示借阅期限。
参考文献
[1] 王珊着、数据库系统原理教程，清华大学出版社，2002.1
[2] 齐治昌等着、软件工程，高等教育出版社，2002.1
[3] 网络资源
Ⅳ 数据库编写书店系统
我有书店系统的课程设计
Ⅵ 在软件开发中，需求规格说明书和系统设计说明书有什么区别
1、内容有区别
需求规格说明书主要是描述软件系统应该完成的功能，包含硬件、功能、性能、输入输出、接口需求、警示信息、保密安全、数据与数据库、文档和法规的要求等等。
设计说明书是说明如何实现这些功能、性能的。设计书中会对功能进行重新的分解，并需要描述这些功能如何实现，甚至包括如何用代码实现。
2、目的不同
需求规格说明书的作用在于便于用户、开发人员进行理解和交流，反映出用户问题的结构，可以作为软件开发工作的基础和依据，并作为确认测试和验收的依据。
系统设计说明书编制的目的是说明对程序系统的设计考虑，包括程序系统的基本处理流程、程序系统的组织结构、模块划分、功能分配、接口设计、运行设计、安全设计、数据结构设计和出错处理设计等，为程序的详细设计提供基础。
3、阅读对象不同
需求规格说明书主要从用户角度（需求或市场人员根据用户要求编写）描述软件需要实现的功能。
系统设计说明书主要从软件开发（程序员）角度描述软件需要实现功能。
Ⅶ 急！高分求做SQL Server数据库设计【达人请进】
下述十四个技巧，是许多人在大量的数据库分析与设计实践中，逐步总结出来的。对于这些经验的运用，读者不能生帮硬套，死记硬背，而要消化理解，实事求是，灵活掌握。并逐步做到：在应用中发展，在发展中应用。
1. 原始单据与实体之间的关系
可以是一对一、一对多、多对多的关系。在一般情况下，它们是一对一的关系：即一张原始单据对应且只对应一个实体。在特殊情况下，它们可能是一对多或多对一的关系，即一张原始单证对应多个实体，或多张原始单证对应一个实体。这里的实体可以理解为基本表。明确这种对应关系后，对我们设计录入界面大有好处。
〖例1〗：一份员工履历资料，在人力资源信息系统中，就对应三个基本表：员工基本情况表、社会关系表、工作简历表。这就是“一张原始单证对应多个实体”的典型例子。
2. 主键与外键
一般而言，一个实体不能既无主键又无外键。在E?R 图中, 处于叶子部位的实体, 可以定义主键，也可以不定义主键(因为它无子孙), 但必须要有外键(因为它有父亲)。
主键与外键的设计，在全局数据库的设计中，占有重要地位。当全局数据库的设计完成以后，有个美国数据库设计专家说：“键，到处都是键，除了键之外，什么也没有”，这就是他的数据库设计经验之谈，也反映了他对信息系统核心(数据模型)的高度抽象思想。因为：主键是实体的高度抽象，主键与外键的配对，表示实体之间的连接。
3. 基本表的性质
基本表与中间表、临时表不同，因为它具有如下四个特性：
(1) 原子性。基本表中的字段是不可再分解的。
(2) 原始性。基本表中的记录是原始数据(基础数据)的记录。
(3) 演绎性。由基本表与代码表中的数据，可以派生出所有的输出数据。
(4) 稳定性。基本表的结构是相对稳定的，表中的记录是要长期保存的。
理解基本表的性质后，在设计数据库时，就能将基本表与中间表、临时表区分开来。
4. 范式标准
基本表及其字段之间的关系, 应尽量满足第三范式。但是，满足第三范式的数据库设计，往往不是最好的设计。为了提高数据库的运行效率，常常需要降低范式标准：适当增加冗余，达到以空间换时间的目的。
〖例2〗：有一张存放商品的基本表，如表1所示。“金额”这个字段的存在，表明该表的设计不满足第三范式，因为“金额”可以由“单价”乘以“数量”得到，说明“金额”是冗余字段。但是，增加“金额”这个冗余字段，可以提高查询统计的速度，这就是以空间换时间的作法。
在Rose 2002中，规定列有两种类型：数据列和计算列。“金额”这样的列被称为“计算列”，而“单价”和“数量”这样的列被称为“数据列”。
表1 商品表的表结构
商品名称 商品型号 单价 数量 金额
电视机 29? 2,500 40 100,000
5. 通俗地理解三个范式
通俗地理解三个范式，对于数据库设计大有好处。在数据库设计中，为了更好地应用三个范式，就必须通俗地理解三个范式(通俗地理解是够用的理解，并不是最科学最准确的理解)：
第一范式：1NF是对属性的原子性约束，要求属性具有原子性，不可再分解;
第二范式：2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性;
第三范式：3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余.
没有冗余的数据库设计可以做到。但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，允许冗余。
6. 要善于识别与正确处理多对多的关系
若两个实体之间存在多对多的关系，则应消除这种关系。消除的办法是，在两者之间增加第三个实体。这样，原来一个多对多的关系，现在变为两个一对多的关系。要将原来两个实体的属性合理地分配到三个实体中去。这里的第三个实体，实质上是一个较复杂的关系，它对应一张基本表。一般来讲，数据库设计工具不能识别多对多的关系，但能处理多对多的关系。
〖例3〗：在“图书馆信息系统”中，“图书”是一个实体，“读者”也是一个实体。这两个实体之间的关系，是一个典型的多对多关系：一本图书在不同时间可以被多个读者借阅，一个读者又可以借多本图书。为此，要在二者之间增加第三个实体，该实体取名为“借还书”，它的属性为：借还时间、借还标志(0 表示借书，1表示还书)，另外，它还应该有两个外键(“图书”的主键，“读者”的主键)，使它能与“图书”和“读者”连接。
7. 主键PK的取值方法
PK是供程序员使用的表间连接工具，可以是一无物理意义的数字串, 由程序自动加1来实现。也可以是有物理意义的字段名或字段名的组合。不过前者比后者好。当PK是字段名的组合时，建议字段的个数不要太多，多了不但索引占用空间大，而且速度也慢。
8. 正确认识数据冗余
主键与外键在多表中的重复出现, 不属于数据冗余，这个概念必须清楚，事实上有许多人还不清楚。非键字段的重复出现, 才是数据冗余!而且是一种低级冗余，即重复性的冗余。高级冗余不是字段的重复出现，而是字段的派生出现。
〖例4〗：商品中的“单价、数量、金额”三个字段，“金额”就是由“单价”乘以“数量”派生出来的，它就是冗余，而且是一种高级冗余。冗余的目的是为了提高处理速度。只有低级冗余才会增加数据的不一致性，因为同一数据，可能从不同时间、地点、角色上多次录入。因此，我们提倡高级冗余(派生性冗余)，反对低级冗余(重复性冗余)。
9. E--R图没有标准答案
信息系统的E--R图没有标准答案，因为它的设计与画法不是惟一的，只要它覆盖了系统需求的业务范围和功能内容，就是可行的。反之要修改E-- R图。尽管它没有惟一的标准答案，并不意味着可以随意设计。好的E?R图的标准是：结构清晰、关联简洁、实体个数适中、属性分配合理、没有低级冗余。
10. 视图技术在数据库设计中很有用
与基本表、代码表、中间表不同，视图是一种虚表，它依赖数据源的实表而存在。视图是供程序员使用数据库的一个窗口，是基表数据综合的一种形式, 是数据处理的一种方法，是用户数据保密的一种手段。为了进行复杂处理、提高运算速度和节省存储空间, 视图的定义深度一般不得超过三层。若三层视图仍不够用, 则应在视图上定义临时表, 在临时表上再定义视图。这样反复交迭定义, 视图的深度就不受限制了。
对于某些与国家政治、经济、技术、军事和安全利益有关的信息系统，视图的作用更加重要。这些系统的基本表完成物理设计之后，立即在基本表上建立第一层视图，这层视图的个数和结构，与基本表的个数和结构是完全相同。并且规定，所有的程序员，一律只准在视图上操作。只有数据库管理员，带着多个人员共同掌握的“安全钥匙”，才能直接在基本表上操作。请读者想想：这是为什么?
11. 中间表、报表和临时表
中间表是存放统计数据的表，它是为数据仓库、输出报表或查询结果而设计的，有时它没有主键与外键(数据仓库除外)。临时表是程序员个人设计的，存放临时记录，为个人所用。基表和中间表由DBA维护，临时表由程序员自己用程序自动维护。
12. 完整性约束表现在三个方面
域的完整性：用Check来实现约束，在数据库设计工具中，对字段的取值范围进行定义时，有一个Check按钮，通过它定义字段的值城。参照完整性：用PK、FK、表级触发器来实现。用户定义完整性：它是一些业务规则，用存储过程和触发器来实现。
13. 防止数据库设计打补丁的方法是“三少原则”
(1) 一个数据库中表的个数越少越好。只有表的个数少了，才能说明系统的E--R图少而精，去掉了重复的多余的实体，形成了对客观世界的高度抽象，进行了系统的数据集成，防止了打补丁式的设计;
(2) 一个表中组合主键的字段个数越少越好。因为主键的作用，一是建主键索引，二是做为子表的外键，所以组合主键的字段个数少了，不仅节省了运行时间，而且节省了索引存储空间;
(3) 一个表中的字段个数越少越好。只有字段的个数少了，才能说明在系统中不存在数据重复，且很少有数据冗余，更重要的是督促读者学会“列变行”，这样就防止了将子表中的字段拉入到主表中去，在主表中留下许多空余的字段。所谓“列变行”，就是将主表中的一部分内容拉出去，另外单独建一个子表。这个方法很简单，有的人就是不习惯、不采纳、不执行。
数据库设计的实用原则是：在数据冗余和处理速度之间找到合适的平衡点。“三少”是一个整体概念，综合观点，不能孤立某一个原则。该原则是相对的，不是绝对的。“三多”原则肯定是错误的。试想：若覆盖系统同样的功能，一百个实体(共一千个属性) 的E--R图，肯定比二百个实体(共二千个属性) 的E--R图，要好得多。
提倡“三少”原则，是叫读者学会利用数据库设计技术进行系统的数据集成。数据集成的步骤是将文件系统集成为应用数据库，将应用数据库集成为主题数据库，将主题数据库集成为全局综合数据库。集成的程度越高，数据共享性就越强，信息孤岛现象就越少，整个企业信息系统的全局E?R图中实体的个数、主键的个数、属性的个数就会越少。
提倡“三少”原则的目的，是防止读者利用打补丁技术，不断地对数据库进行增删改，使企业数据库变成了随意设计数据库表的“垃圾堆”，或数据库表的“大杂院”，最后造成数据库中的基本表、代码表、中间表、临时表杂乱无章，不计其数，导致企事业单位的信息系统无法维护而瘫痪。
“三多”原则任何人都可以做到，该原则是“打补丁方法”设计数据库的歪理学说。“三少”原则是少而精的原则，它要求有较高的数据库设计技巧与艺术，不是任何人都能做到的，因为该原则是杜绝用“打补丁方法”设计数据库的理论依据。
14. 提高数据库运行效率的办法
在给定的系统硬件和系统软件条件下，提高数据库系统的运行效率的办法是：
(1) 在数据库物理设计时，降低范式，增加冗余, 少用触发器, 多用存储过程。
(2) 当计算非常复杂、而且记录条数非常巨大时(例如一千万条)，复杂计算要先在数据库外面，以文件系统方式用C++语言计算处理完成之后，最后才入库追加到表中去。这是电信计费系统设计的经验。
(3) 发现某个表的记录太多，例如超过一千万条，则要对该表进行水平分割。水平分割的做法是，以该表主键PK的某个值为界线，将该表的记录水平分割为两个表。若发现某个表的字段太多，例如超过八十个，则垂直分割该表，将原来的一个表分解为两个表。
(4) 对数据库管理系统DBMS进行系统优化，即优化各种系统参数，如缓冲区个数。
(5) 在使用面向数据的SQL语言进行程序设计时，尽量采取优化算法。
总之，要提高数据库的运行效率，必须从数据库系统级优化、数据库设计级优化、程序实现级优化，这三个层次上同时下功夫。
Ⅷ 软件需求说明怎么写
如何写需求分析报告（软件需求说明书GB856T-88）
近来学校的一些科研项目又在申报了，一些学弟开始Q我一些软件工程上书面的问题。大概的总结了下，写到这里。本文涉及到的是需求分析部分的书写，主要是根据国家标准文档中的要求来的。
在互联网公司或者一些敏捷开发的公司里，其实大家都是秉承着重开发，重讨论，而轻文档的态度。这个轻文档并不是指没有文档或者几乎不做文档，而是在严格的文档流程中解脱出来，只把最最实际的部分写出来。这个特征是有互联网本身迭代周期短，版本发布快等特点决定的。而在实际的兼职项目的时候，同学们就要注意了，最重要的应该就是在签合同的时候一定要附上最清楚的一份需求分析，虽然这份需求说明可能不是按照某些标准文档而来的，描述清楚每个功能达到的效果，而这个效果一定要让客户点头确认，而不能出现“应该是”、“可能是”、“也许是”这样的模糊回答。否则在项目后期就会比较难过了。在学校申请的项目和大型公司项目开发中，是重视文档流程的，一部一部来。所以还是看情况来对待文档的深度和标准。
一、目录：目录要用word的“引用”—>”目录”，自动生成目录，一般都是要三级目录。通常这部分基本都不需要改结构，直接更新页码即可。
二、内容部分。国家标准软件需求说明书G856T-88下载
1引言
1.1编写目的
说明编写这份软件需求说明书的目的，指出预期的读者。
（这部分说明需求分析报告的概况，例如：本X需求分析报告是为S系统而编写的。+S系统的两句话概述。+本X报告旨在使U1（需求者）明确S系统的要求和细节，给U2(开发人员)了解需求实现的难度和困难，最终提供给U3（审核人、管理者）讨论和审核，达到沟通效果）
1.2背景
说明：
a．待开发的软件系统的名称；
b．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；
c．该软件系统同其他系统或其他机构的基本的相互来往关系。
（这部分可以将a,b,c分为2部分，例子如下：
1.2.1项目概况
本需求分析报告所预期开发的软件系统是:S。S是（不是则无）SS系统的某一个功能子模块，S和S1、S2等系统之间的联系，以及概述其他系统的状态等等。
1.2.2任务分配
a.任务提出者：xxx
b.软件开发者：xx
c.产品使用者：xx
d.文档编写者：xx
e.预期产品使用者：xx
）
1.3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
（这部分很简单，就是描述专业词汇，比如
1. XML(Extensible Markup Language)即可扩展标记语言,它与HTML一样,都是SGML(Standard Generalized Markup Language,标准通用标记语言)。
2. Word2,解释。。。
）
1.4参考资料
列出用得着的参考资料，如：
a．本项目的经核准的计划任务书或合同、上级机关的批文；
b．属于本项目的其他已发表的文件；
c．本文件中各处引用的文件、资料、包括所要用到的软件开发标准。列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2任务概述
2.1目标
叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。|
（
本模块开发主要是为SS的整体服务，完成SS工作中的XX部分以及相关的工作。其涉及的范围就是，从下达A、B命令后，到给出C结果的过程。具体描述：B1，来完成B11功能；B2，来完成B22功能；等等。本部分是（否）耦合在分词工具包其他部分中的，主要为嵌入方式和先后方式相互交互。
图
图1.该系统的组成同其他各部分的联系和接口
）
2.2用户的特点
列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使甩频度。这些是软件设计工作的重要约束
（例如：二次开发和系统调用人员：具有很高的专业知识水平，理解XX的运行机制。可以对开放代码进行阅读和分析，以完成其系统独特的需求，提供给这部分用户开放API手册和Debug版本的源代码即可；预期这部分用户会占本系统总用户量的多大部分。
xx使用者：具有一定的计算机操作能力和知识，了解xx领域的相关概念和用途。提供给这部分用户操作手册即可。预期这部分使用者主要是来简单的xx操作。
维护人员：具有较高的计算机专业水平，可以对常见的系统Bug进行追踪和分析，具有一定的测试能力。这部分用户主要是采用了本系统之后的后期工作维护者。
等等
）
2.3假定和约束
列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。
（这部分重要是对你有的技术力量、资金状况、人力资源等情况的假设，以使得你可以在什么样的情况和时间范围内完成工作。工期约束，经费约束，人员约束，地理约束，设备约束等几个方面列举说明。）
3需求规定
3.1对功能的规定
用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户数。
（例如：
INPUT输入
PROCESS处理
OUTPUT输出
LOAD负载量
A
预处理,做怎样的动作，
AA
CC
B
BBBB
Bb
v
C
CCCC
cc
v
表一、xx模块IPO表
对IPO表的简单文字描述。
）
3.2对性能的规定
3.2.1精度
说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。
（例如：
Xx目标处理：1Byt–10M，包括左右边界值。
yy精度范围：….
ZZ的精度：由于xx的特殊性，本系统均采用xx型来进行字符统计运算，概率部分以及其他比率部分精度精确到0.0x%。
）
3.2.2时间特性要求
说明对于该软件的时间特性要求，如对：
a．响应时间；
b．更新处理时间；
c．数据的转换和传送时间；
d．解题时间；等的要求。
(这部分只要一一列举就可以：
由于xxx过程中，需要大量xxxx操作或怎样，故xx解题时间占总时间的最大部分。其次就是xx转换和存储的开销。其具体时间特性要求，如下：
a．xx响应时间：xxms左右；
b．yy更新处理时间：yy；
c．zz数据的转换和传送时间：zz；
d．vv解题时间：vv。
等等
)
3.2.3灵活性
说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：
a．操作方式上的变化；
b．运行环境的变化；
c．同其他软件的接口的变化；
d．精度和有效时限的变化；
e．计划的变化或改进。
对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。
（这部分按列举来即可，由于本模块第一目的是用于xxx，其次则是xxxx。故本模块的灵活性在于实际应用者的不同。当需求发生某些变化时，该软件对这些变化的适应能力。具体情况如下：
f．操作方式上的变化：采用集成运行制和独立运行制两种模式，集成运行制是把本模块嵌入到分词工具包的主框架中，提供给用户具有一定UI的可操作软件；独立运行制是可以独立运行于后台，并提供给各种程序调用的模式的工作方式，以增强其生命力。
g．运行环境的变化：主采用Windows平台的编译版本运行和调试，在时间允许的情况下，同步开发支持SUSE Linux的服务器版本。；
h．同其他软件的接口的变化：在尽量保证接口不出现变动的情况下，允许接口的重载和再定义。但接口的命名规则是统一的；
i．精度和有效时限的变化：精度在必须调整的条件下，可以上下浮动10个百分点；有效时限则依据现实的测试情况允许稍大范围的变化。
j．计划的变化或改进：工作时间安排会存在必然的浮动，这部分要协同分词工具包课题设计组其他成员一同来进行商定，前期的计划可以稍微有些变动，后期的安排尽量按照计划执行。
等等
）
3.3输人输出要求
解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。
（这部分可以把输入输出分为3.3.1输入要求和3.3.2输出要求，如下给出一个单元的例子。
XXX输出
数据名称：XXX输出数据
实际含义：用于XX,表示XXXX
数据类型：Character(字符串)
数据格式：XX
数据约束：由于xxx,，大小在xx以内
）
3.4数据管理能力要求
说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作出估算。
（
根据实际系统要求列举即可
Name名称
Number数量
Size大小
Increase增长
词典xx
xx
xxxx
并行执行，其大小依据实际xx大文本而增长
）
3.5故障处理要求
列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。
（包括软件压力，内存不足，硬件损坏等，这部分可以根据网络到其常见故障。）
3.6其他专门要求
如用户单位对安全保密的要求，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。
（例如安全保密性：密钥更换等；预期扩展：扩展兼容等；OS更换：Slackware转SUSE等
）
4运行环境规定
4.1设备
列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括：
a．处理器型号及内存容量；
b．外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量；
c．输入及输出设备的型号和数量，联机或脱机；
d．数据通信设备的型号和数量；
e．功能键及其他专用硬件
（列举说明即可）
4.2支持软件
列出支持软件,包括要用到的操作系统、编译（或汇编）程序、测试支持软件等。
（操作系统和版本：xxxx
支撑环境和版本：xxxx
备用IDE环境和版本：xxxx
与该软件有关的软件组件：xxxx
后续可能扩展环境：xxxx
）
4.3接口
说明该软件同其他软件之间的接口、数据通信协议等。
(例如：
a．用户和主程序调用接口(图中接口1)。这个接口采用封装API形式和函数调用形式，分别以外部调用和内部调用的方式为不同用户提供使用本机械分词工具的入口。例如以xxxx方式调用DLL文件，以xxxx方式调用函数。如下图2所示。
图2.软件接口调用图
b.xx接口(图中接口2)。这里是一个xxx的接口调用过程。xxxx
)
4.4控制
说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。
(例如：
下面通过图表的形式，将本模块以及涉及到本模块的软件模块的运行方法、控制信号，以及这些控制信号的来源，其中箭头所指方向对应的模块的控制信号来自箭头另一方向的模块，具体情况如下：
图3 .控制流程图
图3的具体说明情况如下表所示：
Name模块名称
Method运行方式
Signal控制信号
Forward控制去向
主程序模块
运行框架
用户调用或运行
1.调用xx模块
2.调用xx方法
3.调用标准输出模块
xxx模块
xxx
xxx调用
Xxx模块
)
附录：软件设计文档国家标准(GB8567–88)软件设计文档国家标准(GB8567–88)GB8567——88
操作手册（GB8567——88）.doc 数据库设计说明书（GB8567——88）.doc
测试分析报告（GB8567——88）.doc 数据要求说明书（GB856T——88）.doc
测试计划（GB8567——88）.doc 图1.doc
概要设计说明书（GB8567——88）.doc 文件给制实施规定的实例（GB8567-88）.doc
开发进度月报（GB8567——88）.doc 详细设计说明书（GB8567——88）.doc
可行性研究报告（GB8567——88）.doc 项目开发计划（GB856T——88）.doc
模块开发卷宗（GB8567——88）.doc 项目开发总结报告（GB8567——88）.doc
软件需求说明书（GB856T——88）.doc 用户手册（GB8567——88）.doc
Ⅸ 简述数据库应用系统的设计步骤
数据库设计的基本步骤：
1、系统需求分析与设计。
2、概念结构分析与设计。
3、逻辑结构分析与设计。
4、物理结构分析与设计。
5、系统实施。
6、系统维护。
(9)数据库系统需求说明书扩展阅读：
数据库设计技巧：
1、原始文件与实体的关系
它可以是一对一，一对多，多对多的关系。一般来说，它们是一对一的关系：一个原始文档只对应于一个实体。在特殊情况下，它们可以是一对多或多对一关系，即一个原始文档对应于多个实体，或者多个原始文档对应于一个实体。
这里的实体可以理解为基本表。在对应关系明确后，对输入接口的设计非常有利。
2、主键和外键
一般来说，实体不能既没有主键也没有外键。在E－R图中，叶中的实体可以定义主键或不定义主键（因为它没有子代），但它必须有外键（因为它有父项）。
主键和外键的设计在全局数据库的设计中起着重要的作用。当全球数据库的设计完成后，一位美国数据库设计专家说：“钥匙无处不在，只有钥匙。”。这是他数据库设计的经验，也体现了他对信息系统核心（数据模型）高度抽象的理念。
因为：主键是一个高度抽象的实体。主键和外键的配对表示实体之间的连接。
3、基本表的属性
基本表不同于中间表和临时表，因为它具有以下四个特点：
原子性。基本表中的字段不可分解。
原始主义。基本表中的记录是原始数据（基本数据）的记录。
演绎的。所有输出数据都可以从基本表和代码表中的数据导出。
稳定。基本表的结构比较稳定，表中的记录要长期保存。
在了解基本表的性质之后，在设计数据库时，可以将基本表与中间表和临时表区分开来。
Ⅹ 什么是数据库系统的一份重要文件是系统开发的标准和依据
数据库应用系统的开发是一项软件工程。一般可分为以下几个阶段：
1.规划 2.需求分析 3.概念模型设计 4. 逻辑设计5.物理设计 6.程序编制及调试 7.运行及维护。 这些阶段的划分目前尚无统一的标准，各阶段间相互联接，而且常常需要回溯修正。 在数据库应用系统的开发过程中，每个阶段的工作成果就是写出相应的文档。每个阶段都是在上一阶段工作成果的基础上继续进行，整个开发工程是有依据、有组织、有计划、有条不紊地展开工作。
1.规划规划的主要任务就是作必要性及可行性分析。 在收集整理有关资料的基础上，要确定将建立的数据库应用系统与周边的关系，要对应用系统定位，其规模的大小、所处的地位、应起的作用均须作全面的分析和论证。 明确应用系统的基本功能，划分数据库支持的范围。分析数据来源、数据采集的方式和范围，研究数据结构的特点，估算数据量的大小，确立数据处理的基本要求和业务的规范标准。 规划人力资源调配。对参与研制和以后维护系统运作的管理人员、技术人员的技术业务水平提出要求，对最终用户、操作员的素质作出评估。 拟定设备配置方案。论证计算机、网络和其他设备在时间、空间两方面的处理能力，要有足够的内外存容量，系统的响应速度、网络传输和输入输出能力应满足应用需求并留有余量。要选择合适的os,dbms和其它软件。设备配置方案要在使用要求、系统性能、购置成本和维护代价各方面综合权衡。 对系统的开发、运行、维护的成本作出估算。预测系统效益的期望值。 拟定开发进度计划，还要对现行工作模式如何向新系统过渡作出具体安排。 规划阶段的工作成果是写出详尽的可行性分析报告和数据库应用系统规划书。内容应包括：系统的定位及其功能、数据资源及数据处理能力、人力资源调配、设备配置方案、开发成本估算、开发进度计划等。 可行性分析报告和数据库应用系统规划书经审定立项后，成为后续开发工作的总纲。 2.需求分析需求分析大致可分成三步来完成。 (1) 需求信息的收集, 需求信息的收集一般以机构设置和业务活动为主干线，从高层中层到低层逐步展开 (2) 需求信息的分析整理, 对收集到的信息要做分析整理工作。数据流图(dfd, data flow diagram)是业务流程及业务中数据联系的形式描述。图4.1是一个简单的dfd 示例。 数据字典(dd, data dictionary)详细描述系统中的全部数据。 数据字典包含以下几个部分。 数据项：是数据的原子单位。 数据组项：由若干数据项组成。 数据流：表示某一数据加工过程的输入/输出数据。 数据存储：是处理过程中要存取的数据。 数据加工过程 数据加工过程的描述包括：数据加工过程名、说明、输入、输出、加工处理工作摘要、加工处理频度、加工处理的数据量、响应时间要求等。 数据流图既是需求分析的工具，也是需求分析的成果之一。数据字典是进行数据收集和数据分析的主要成果。 (3) 需求信息的评审. 开发过程中的每一个阶段都要经过评审，确认任务是否全部完成，避免或纠正工作中出现的错误和疏漏。聘请项目外的专家参与评审，可保证评审的质量和客观性。 评审可能导致开发过程回溯，甚至会反复多次。但是，一定要使全部的预期目标都达到才能让需求分析阶段的工作暂告一个段落. 需求分析阶段的工作成果是写出一份既切合实际又具有预见的需求说明书，并且附以一整套详尽的数据流图和数据字典。 3.概念模型设计概念模型不依赖于具体的计算机系统，他是纯粹反映信息需求的概念结构。 建模是在需求分析结果的基础上展开，常常要对数据进行抽象处理。常用的数据抽象方法是‘聚集’和‘概括’。 er方法是设计概念模型时常用的方法。用设计好的er图再附以相应的说明书可作为阶段成果 概念模型设计可分三步完成。 (1) 设计局部概念模型 ① 确定局部概念模型的范围 ② 定义实体 ③ 定义联系 ④ 确定属性 ⑤ 逐一画出所有的局部er图，并附以相应的说明文件 (2) 设计全局概念模型 建立全局er图的步骤如下： ① 确定公共实体类型 ② 合并局部er图 ③ 消除不一致因素 ④ 优化全局er图 ⑤ 画出全局er图，并附以相应的说明文件。 (3) 概念模型的评审 概念模型的评审分两部分进行 第一部分是用户评审。 第二部分是开发人员评审。 4.逻辑设计逻辑设计阶段的主要目标是把概念模型转换为具体计算机上dbms所支持的结构数据模型。 逻辑设计的输入要素包括：概念模式、用户需求、约束条件、选用的dbms的特性。 逻辑设计的输出信息包括：dbms可处理的模式和子模式、应用程序设计指南、物理设计指南。 (1) 设计模式与子模式 关系数据库的模式设计可分四步完成。 ① 建立初始关系模式 ② 规范化处理 ③ 模式评价 ④ 修正模式 经过多次的模式评价和模式修正，确定最终的模式和子模式。 写出逻辑数据库结构说明书。 (2) 编写应用程序设计指南 根据设计好的模式和应用需求，规划应用程序的架构，设计应用程序的草图，指定每个应用程序的数据存取功能和数据处理功能梗概，提供程序上的逻辑接口。 编写出应用程序设计指南。 (3) 编写物理设计指南。 根据设计好的模式和应用需求，整理出物理设计阶段所需的一些重要数据和文档。例如，数据库的数据容量、各个关系(文件)的数据容量、应用处理频率、操作顺序、响应速度、各个应用的lra和tv、程序访问路径建议，等等。这些数据和要求将直接用于物理数据库的设计。 编写出物理设计指南。 5.物理设计物理设计是对给定的逻辑数据模型配置一个最适合应用环境的物理结构。 物理设计的输入要素包括：模式和子模式、物理设计指南、硬件特性、os和dbms的约束、运行要求等。 物理设计的输出信息主要是物理数据库结构说明书。其内容包括物理数据库结构、存储记录格式、存储记录位置分配及访问方法等。 物理设计的步骤如下： (1) 存储记录结构 设计综合分析数据存储要求和应用需求，设计存储记录格式。 (2) 存储空间分配 存储空间分配有两个原则： ①存取频度高的数据尽量安排在快速、随机设备上，存取频度低的数据则安排在速度较慢的设备上。 ②相互依赖性强的数据尽量存储在同一台设备上，且尽量安排在邻近的存储空间上。 从提高系统性能方面考虑，应将设计好的存储记录作为一个整体合理地分配物理存储区域。尽可能充分利用物理顺序特点，把不同类型的存储记录指派到不同的物理群中。 (3) 访问方法的设计 一个访问方法包括存储结构和检索机构两部分。存储结构限定了访问存储记录时可以使用的访问路径；检索机构定义了每个应用实际使用的访问路径。 (4) 物理设计的性能评价 ① 查询响应时间 从查询开始到有结果显示之间所经历的时间称为查询响应时间。查询响应时间可进一步细分为服务时间、等待时间和延迟时间。 在物理设计过程中，要对系统的性能进行评价。性能评价包括时间、空间、效率、开销等各个方面。 ⊙ cpu服务时间和i/o服务时间的长短取决于应用程序设计。 ⊙ cpu队列等待时间和i/o队列等待时间的长短受计算机系统作业的影响。 ⊙ 设计者可以有限度地控制分布式数据库系统的通信延迟时间。 ② 存储空间 存储空间存放程序和数据。程序包括运行的应用程序、dbms子程序、os子程序等。数据包括用户工作区、dbms工作区、os工作区、索引缓冲区、数据缓冲区等。 存储空间分为主存空间和辅存空间。设计者只能有限度地控制主存空间，例如可指定缓冲区的分配等。但设计者能够有效地控制辅存空间。 ③ 开销与效率 设计中还要考虑以下各种开销，开销增大，系统效率将下降。 ⊙ 事务开销指从事务开始到事务结束所耗用的时间。更新事务要修改索引、重写物理块、进行写校验等操作，增加了额外的开销。更新频度应列为设计的考虑因素。 ⊙ 报告生成开销指从数据输入到有结果输出这段时间。报告生成占用cpu及i/o的服务时间较长。设计中要进行筛选，除去不必要的报告生成。 ⊙ 对数据库的重组也是一项大的开销。设计中应考虑数据量和处理频度这两个因数，做到避免或尽量减少重组数据库。 在物理设计阶段，设计、评价、修改这个过程可能要反复多次，最终得到较为完善的物理数据库结构说明书。 建立数据库时，dba依据物理数据库结构说明书，使用dbms提供的工具可以进行数据库配置。 在数据库运行时，dba监察数据库的各项性能，根据依据物理数据库结构说明书的准则，及时进行修正和优化操作，保证数据库系统能够保持高效率地运行。 6.程序编制及调试在逻辑数据库结构确定以后，应用程序设计的编制就可以和物理设计并行地展开 程序模块代码通常先在模拟的环境下通过初步调试，然后再进行联合调试。联合调试的工作主要有以下几点： (1) 建立数据库结构 根据逻辑设计和物理设计的结果，用dbms提供的数据语言(ddl)编写出数据库的源模式，经编译得到目标模式，执行目标模式即可建立实际的数据库结构。 (2) 调试运行 数据库结构建立后，装入试验数据，使数据库进入调试运行阶段。运行应用程序，测试 (3) 装入实际的初始数据 在数据库正式投入运行之前，还要做好以下几项工作： (1) 制定数据库重新组织的可行方案。 (2) 制定故障恢复规范 (3) 制定系统的安全规范 7.运行和维护数据库正式投入运行后，运行维护阶段的主要工作是： (1) 维护数据库的安全性与完整性。 按照制定的安全规范和故障恢复规范，在系统的安全出现问题时，及时调整授权和更改密码。及时发现系统运行时出现的错误，迅速修改，确保系统正常运行。把数据库的备份和转储作为日常的工作，一旦发生故障，立即使用数据库的最新备份予以恢复。 (2) 监察系统的性能。 运用dbms提供的性能监察与分析工具，不断地监控着系统的运行情况。当数据库的存储空间或响应时间等性能下降时，立即进行分析研究找出原因，并及时采取措施改进。例如，可通修改某些参数、整理碎片、调整存储结构或重新组织数据库等方法，使数据库系统保持高效率地正常运作。 (3) 扩充系统的功能 在维持原有系统功能和性能的基础上，适应环境和需求的变化，采纳用户的合理意见，对原有系统进行扩充，增加新的功能。