报刊订阅管理系统设计.docx
《报刊订阅管理系统设计.docx》由会员分享，可在线阅读，更多相关《报刊订阅管理系统设计.docx（31页珍藏版）》请在冰点文库上搜索。
报刊订阅管理系统设计
1．需求分析
1.1、系统需求分析
1.1.1系统调查
随着社会不断的发展，人们的生活水平越来越高，人们对知识的和对时事的渴求也越来越高，而获得知识的一个主要途径就是通过阅读书籍，所以人们希望能够方便快捷地订阅各种报刊杂志。
通过对某些企业的报刊订阅业务进行调查，发现目前是通过以下3种方式订阅报刊：
一是读者可到全市邮政支局办理报刊订阅业务，办理订阅后可按读者要求送达地址进行投送。
二是读者通过单位报刊发行站集体订阅，由单位发行人员登记汇总后集中到邮局办理报刊订阅。
三是读者也可拨打邮政服务热线“11185”电话，办理报刊订阅（一般适用于新订户）。
读者拨打“11185”接通后：
根据语音提示，话务员就可为你办理所需要的邮发报刊的订阅预约，并通知相关邮局按读者约定的时间内上门办理报刊订阅手续。
通过调查得知，过去这些企业的报刊订阅人工操作占绝大部分，操作起来很费时而且很容易出错，数据的存储很不科学，订阅数据随时间的推移很容易丢失。
如果订户因工作调动、搬迁或其它原因要更改投送地址，为此订户要持原报刊费收据或单位证明信，到邮局申请办理改址手续，在填写“报刊改寄单”时，新旧户名、住址一定要填写详细、清楚，而且这样的改址只限于本省（市、区）范围。
这样的操作给订户带来很大的不便。
为适应当前网络技术新形势的发展，把报刊订阅与网络技术与数据库技术结合起来，我们要开发一个适合现代企业报刊订阅的管理系统，实现更加数字化和自动化的管理，该系统兼有数据备份和数据恢复的功能，使订阅的数据更加安全。
1.1.2用户需求
要设计一个性能良好的管理系统，明确用户的应用环境对系统的要求是首要的和基本的。
本系统从以下六个功能对用户需求进行了分析：
（1）登录功能：
登录系统为身份认证登录。
分为管理员登录和一般用户登录，分别通过不同的用户名和密码进入报刊订阅管理界面。
（2）录入功能：
对于管理员，包括新用户信息和新报刊信息的录入功能，信息一旦提交就存入到后台数据库中，普通用户自行注册并可以修改个人信息。
（3）订阅功能：
用户可以订阅报刊，系统自动计算所需金额，并显示在界面上，管理员不可以订阅报刊，必须以用户身份订阅报刊。
（4）查询功能：
用户可以查询并显示自己所订阅的信息，管理员可以按人员、报刊、部门分类查询。
查询出的信息显示在界面上，并且可以预览和打印出结果。
（5）统计功能：
管理员可以按人员、部门、报刊统计报刊的销售情况，并对一些重要的订阅信息进行统计，普通用户可以统计出自己的订阅情况，并且可以预览和打印出结果。
（6）系统维护：
数据的安全管理，主要是依靠管理员对数据库里的信息进行备份和恢复，数据库备份后，如果出了什么意外可以恢复数据库当时备份的状态，这提高了系统和数据的安全性，有利于系统的维护。
1.1.3可行性分析
MicrosoftSQLServer2000数据库管理系统是微软公司研制开发的关系型数据库管理系统。
该系统支持并扩展了SQL语言标准，可以运用标准SQL语句对数据进行操作，也可以使用功能强大的GUI工具进行灵活的数据管理。
同时，系统还提供功能完善的API，可以在应用程序中调用这些API来实现与数据库系统的链接以及相关数据的操作。
我们的报刊订阅管理系统正是基于SQL2000操作的。
该系统是一种比较智能化的管理系统，它面向所有企业部门的职工用户，但具有比较高的安全性能。
它能够实现报刊订阅的基本功能，包括新刊信息的录入、订阅、查询等操作以及后台数据库的备份和恢复，用户合法注册后必须输入有效密码才能成功进入此系统，可以进行订阅报刊、查询信息、统计信息等系统，对于非法操作，系统有识别和防护措施。
为了克服人工管理造成的困难，本系统使用程序代码标准化，软件统一化，确保软件的可维护性和实用性，删除不必要的管理冗余，实现管理规范化、科学化；界面友好、简单化，做到实用、方便，尽量满足报刊订阅中用户的需要。
1.1.4系统业务流程图
业务流程图的符号说明如图1所示：
1、2、2、33、4、5、
系统中人员实体或单据实物或信息流处理数据存储
图1业务流程图图例
详细调查之后，结合现行考试模式，为开发本系统而绘制出的报刊订阅管理流程图如图2所示。
图2报刊订阅管理系统流程图
1.2系统逻辑方案
系统分析的主要成果是系统的逻辑模型。
本系统的逻辑模型主要是以系统的数据流图和数据字典为主要描述工具。
即在报刊订阅管理方式和业务流程进行认真分析和研究的基础上，排除现有组织机构和业务分工所造成的信息障碍。
1.2.1数据流图（简称DFD）
数据流图是组织中信息运动的抽象。
是在调研的基础上，从系统的科学性、管理的合理性、实际运动的可行性角度出发。
将信息处理功能和彼此之间的联系自顶向下，逐层分解，从逻辑上精确地描述系统应具有的数据加工功能、数据输入、数据输出、数据存储及数据来源和去向（外部实体）等项目
首先，分析报刊订阅管理系统的总体情况，划分系统边界，识别系统的数据来源和去处，确定外部实体，得出系统的顶层数据流程图。
然后划分出几个主要的信息管理功能，并明确各功能之间的联系，绘制出数据流程图。
数据流程图的符号说明如图3所示。
报刊订阅管理系统的顶层数据流程图如图4所示。
图5是报刊订阅管理系统第2层数据流图。
（由于我负责的是管理员与订阅2两张表，所以只画出订阅2的第2层数据流图）
图3数据流程图的符号
统计请求
查询请求
订阅确认
信息返回
信息输入
系统维护
统计信息
统计请求
查询结果信息
查询请求
信息返回
信息输入
图4报刊订阅管理系统的顶层数据流程图
新增部门
图5订阅2的第2层数据流图
1.2.2数据字典（简称DD）
绘制DFD,只是对数据处理和彼此之间的联系进行了说明。
为进一步明确数据的详细内容和数据加工过程,应将数据流图中的全部数据流及其组成部分的数据元素，数据存储，数据加工，通过数据字典描述清楚,以便于此后系统设计的进行。
这就需要开发人员编写详细的数据字典,来描述系统开发过程的细节。
下面列出本系统中的数据项、数据流、数据存储、加工处理和数据结构的数据字典。
数据字典可采用图表格式或较紧凑的记录格式描述，本文采用的是图表格式。
数据项的DD表列举如下：
表1数据项表
编号
标识符
类型
长度
所属表名
同义名
1
AdminNum
Varchar
20
Administer
管理员账号
2
AdminPass
Varchar
10
Administer
管理员密码
3
DepName
Varchar
20
Department
部门名
4
NewsSno
Varchar
10
Information
报刊代号
5
OrderData2
Datetime
20
Order2
下订日期2
6
Quantity2
Int
10
Order2
订阅数量2
（注：
上述表也只是列出我所负责的两个表所需要用到的数据项）
表2数据流
编号
名称
来源
去向
组成
1
信息输入
管理员
管理系统
管理员账号+管理员密码
3
信息返回
管理系统
管理员
4
查询请求
管理员
管理系统
待查询对象标识符（如Uid,NewsSno）
5
查询结果信息
管理系统
管理员
被查询对象具体信息
6
统计请求
管理员
管理系统
识别符（Uid,NewsSno）+管理类型
7
统计信息
管理系统
管理员
被管理对象处理结果
8
系统维护
管理员
系统维护
9
信息输入
用户
管理系统
用户编号+用户密码
10
信息返回
管理系统
用户
11
查询请求
用户
管理系统
待查询对象标识符
12
统计请求
用户
管理系统
被查询对象标识符
13
订阅确认
用户
管理系统
数据结构：
管理员=管理员名+管理员密码
用户=用户编号+用户名+用户电话+用户地址
数据存储：
按用途分类可把本系统文件分成以下几种：
（1）主文件：
系统中的主文件是最重要的共享文件，主要存放具有固定值属性的数据。
它需要长期保存，并不断更新。
如用户登录文件（管理员和一般用户）、录入文件、系统维护文件。
（2）处理文件：
处理文件包含下一次更新文件所需要的全部记录，本系统中的处理文件如订阅文件、查询文件、统计文件、。
1.3系统功能模块设计
通过对系统的数据流图进行分析，进一步进行功能分解，直到分解成含义明确，功能单一的功能模块，从而得到系统的功能模块结构图。
如图1.3.1所示
图1.3.1系统功能模块结构图
2概念结构设计
2.1设计方法和步骤
采用自底而上的设计方法，先自顶向下地进行需求分析，对报刊订阅管理系统的需求进行逐步细化；然后再自底而上地设计概念结构，最终将各个局部应用的概念结构集合成为全局概念。
2.2概念结构E-R图
构造的四条基本原则：
1）原则1（确定实体）能独立存在的是事物，例如人、物、事、地、团体、机构、活动、事项等等，在其有多个数据项描述的特性需要关注时，就应把它作为实体。
2）原则2（确定联系）两个或两个实体间的关联与结合，如用户，管理员，报刊等等，当需要予以关注时，应作为联系。
实体间的联系可以分为一对一、一对多、多对多等三类，在确定联系时还要确定其类型。
3）原则3（确定属性）实体的属性是实体的本质特征。
实体应有标识属性（能把不同个体区分开来的属性组），并指定其中一个作为主标识。
联系的属性是联系的结果或状态。
4）原则4（一事一地）信息分析中得到的数据项要在且仅在实体联系图中的一个地方作为属性出现。
根据上述原则，该系统的实体有部门、管理员、报刊类别、报刊信息，先画出各个实体的分E-R图，如下图。
图2.2.1部门E-R图图2.2.2E-R管理员E-R图
图2.2.3用户E-R图
图2.2.4报刊E-R图
接下来合并各个分E-R图，生成初步E-R图，消除不必要的冗余，可以得到以下报刊订阅管理系统的E-R图。
图2.2.5整体E-R图
3逻辑结构设计（E-R图向关系模型的转换）
E－R图向关系模型的转化要解决的问题是如何将实体和实体间的联系转换为关系模式，如何确定这些关系横式的属性和码。
对于实体间的联系我们分不同的情况讨论：
（1）若实体间的联系是1:
1，可以在两个实体转换成的两个关系中任意一个关系的属性中加入另一个关系的码。
（2）若实体间联系为1:
n，则在n端实体转换成的关系中加入1端实体转换成的关系码。
（3）若实体间联系为n:
m，则将联系转换为关系，关系的属性为诸个实体的码加上联系具有的属性，而关系的码则为诸实体的码的组合。
由以上三点，可转换为关系模型。
每个关系的码用下划线表示。
管理员（管理员账号，密码）
用户（用户编号，用户名，用户地址，用户电话，密码，部门号）部门号是外码
部门（部门号，部门名）
报刊（报刊编号，报刊名称，分类编号，内容介绍，出版报社，报刊报价）
订阅1（下订日期，订阅数量1，报刊编号，用户编号）报刊代号和用户编号是外码
订阅2（下订日期2，订阅数量2，报刊编号，部门号）报刊代号和部门号是外码
基于以上关系模型，本系统中关于数据库表结构设计如下：
在服务器上用SQLSever2000建立名为Newspaper的数据库。
其中包括以下表：
管理员Administer，部门Department，用户User1，报刊Information
下面将具体介绍数据库中各个表的结构。
表3-1Administer管理员表
字段名称
字段类型
允许空
说明
AdminNum（主码）
Varchar（20）
否
管理员账号
AdminPass
Varchar（10）
否
管理员密码
表3-2User1用户表
字段名称
字段类型
允许空
说明
Uid（主码）
Varchar（20）
否
用户编号
UserName
Varchar（20）
否
用户名
Address
Varchar（20）
否
用户地址
Phone
Varchar（20）
否
用户电话
UserPass
Varchar（10）
否
用户密码
DepNumber（外码）
Varchar（10）
可以
部门号
表3-3Information报刊信息表
字段名称
字段类型
允许空
说明
NewSno（主码）
Varchar（10）
否
报刊代号
NewsName
Varchar（20）
否
报刊名称
Classifyno
Varchar（20）
否
分类编号
Introduction
Varchar（20）
否
内容介绍
Publish
Varchar（20）
否
出版报社
Price
Float（10）
否
报刊报价
表3-4Department部门表
字段名称
字段类型
允许空
说明
DepNumber（主码）
Varchar（10）
否
部门号
DepName
Varchar（20）
否
部门名
表3-5Order1订阅1表
字段名称
字段类型
允许空
说明
NewSno（外码）
Varchar（10）
可以
报刊代号
Uid（外码）
Varchar（20）
可以
用户编号
OrderData1
Varchar（20）
否
下订日期1
Quantity1
Varchar（20）
否
订阅数量1
表3-6Order2订阅2表
字段名称
字段类型
允许空
说明
NewSno（外码）
Varchar（10）
可以
报刊代号
DepNumber（外码）
Varchar（10）
可以
部门号
OrderData2
Varchar（20）
否
下订日期2
Quantity2
Varchar（20）
否
订阅数量2
4物理结构设计
数据库物理结构依赖于选定的数据库管理系统，此次报刊管理系统中使用的数据库管理系统是SQL-SERVER2000，数据库的物理结构设计主要任务是关系模式存储方法和确定数据库存储结构
4.1索引的选择建立
由于系统可能要涉及大量数据的操作，所以索引的建立就成为一种必要。
我们可以在最经常查询的列上建立索引可以提高查询效率。
而在这个系统中，我们经常要按用户编号、报刊代号、部门查询，所以我们可以为这三个表建立索引。
SQL语句如下：
（这几个都是字符型）
CreateuniqueindexUserNumonUser（Uid）
CreateuniqueindexdepNumonDepartment（DepNumber）
CreateuniqueindexonIndataonInformation（NewSno）
4.2数据存放位置
本系统的数据和索引存放在磁盘中
4.3确定系统配置
根据具体需要配置。
5数据库的实施和维护
5.1数据库的完整性和安全性
在实现数据库SQL语句操作前，先考虑数据库的完整性和安全性。
（1）、数据库的完整性是指数据的正确性和相容性。
数据库管理系统（DBMS）用一定的机制来检查数据库中的数据是否满足规定的条件——完整性约束条件，数据的约束条件是语义的体现，将作为模式的一部分存入数据库中
本系统中定义了表与表之间的联系有助于实现完整性规则，一般在程序中实现具体的完整性控制。
实体完整性：
要求主键属性的值不为空且唯一。
参照完整性：
维护实体间的联系，保证关系模式间属性的正确引用。
（2）、数据库的安全性是指保护数据库以防止不合法的使用所造成的数据泄漏、更改或破坏。
在数据库系统中，大量的数据集中存放，而且为许多用户直接共享，是宝贵的信息资源，系统的安全保护措施就显得更为重要，它保护数据库防止恶意的破坏和非法的存取。
本系统包括数据库的安全和服务器的安全。
采用管理员表示和鉴定的方法实现数据库的安全，此安全管理措施并不在前台开发工具中实现，而是在后台数据库中实现。
在登录数据库时，系统让管理员户表示自己的身份，不同的管理员权限不同，系统进行核实，鉴别此管理员是否为合法用户，若是，系统进一步核实用户，通常要求用户输入口令，系统和对用户口令以鉴别用户身份。
服务器的安全也是通过用户在登录服务器时输入合法的用户名和密码来实现的。
这是一种简单可行的方法，实现起来比较方便。
没有采用更加复杂的系统安全管理措施是因为本管理系统一般是应用在校园网中，采用安全管理措施主要是为了防止没有修改权限的用户无意间修改了数据，因此采用用户标识和鉴定的安全管理措施就能够保障数据库的安全性。
5.2数据库操作（SQLServer2000语句完成）
数据库的选择和部分重要SQL代码
5.2.1创建数据库
createdatabaseNewspaper/*创建报刊订阅管理系统*/
useNewspaper
go
createtableAdminister/*创建管理员表*/
（AdminNumvarchar（20）,AdminPassvarchar（10）notnull,
primarykey（AdminNum））
go
createtableDepartment/*创建部门表*/
（DepNumbervarchar（10）,DepNamevarchar（20）notnull,primarykey（DepNumber））
go
createtableUser1/*创建用户表*/
（Uidvarchar（20）,UserNamevarchar（20）notnull,Phonevarchar（20）notnull,
Addressvarchar（20）notnull,UserPassvarchar（10）notnull,DepNumbervarchar（10）,
primarykey（Uid）,foreignkey（DepNumber）referencesDepartment（DepNumber））
go
createtableInformation/*创建报刊表*/
（NewSnovarchar（10）,NewsNamevarchar（20）notnull,Classifynovarchar（20）notnull,
Introductionvarchar（20）notnull,Publishvarchar（20）notnull,Pricefloat（10）notnull,
primarykey（NewSno））
go
createtableOrder1/*创建订阅1表*/
（NewSnovarchar（10）,UidVarchar（20）,OrderDatavarchar（20）notnull,
Quantity1varchar（20）notnull,primarykey（NewSno,Uid）,
foreignkey（NewSno）referencesInformation（NewSno）,
foreignkey（Uid）referencesUser1（Uid））
go
createtableOrder2/*创建订阅2表*/
（NewSnovarchar（10）,DepNumberVarchar（10）,OrderData2varchar（20）notnull,
Quantity2varchar（20）notnull,primarykey（NewSno,DepNumber）,
foreignkey（NewSno）referencesInformation（NewSno）,
foreignkey（DepNumber）referencesDepartment（DepNumber））
5.2.2建立存储过程向表中插入、修改、删除数据
（1）插入数据的存储过程
/*插入数据的存储过程*/
createprocAdmin_proc@AdminNumvarchar（20）,@AdminPassvarchar（10）
as
insertintoAdminister（AdminNum,AdminPass）values（@AdminNum,@AdminPass）
execAdmin_proc'2000','637074'
execAdmin_proc'2001','637075'
execAdmin_proc'2002','637076'
execAdmin_proc'2003','637077'
execAdmin_proc'2004','637078'
createprocDepart_proc@DepNumbervarchar（20）,@DepNamevarchar（10）
as
insertintoDepartment（DepNumber,DepName）values（@DepNumber,@DepName）
execDepart_proc'1005','管理部'
execDepart_proc'1007','信息部'
execDepart_proc'1003','工程部'
execDepart_proc'1009','技术部'
execDepart_proc'1004','财务部'
execDepart_proc'1006','工程部'
execDepart_proc'1002','工程部'
createprocUse_proc@Uidvarchar（20）,@UserNamevarchar（20）,@Phonevarchar（20）,
@Addressvarchar（20）,@UserPassvarchar（10）,@DepNumbervarchar（10）
as
insertintoUser1（Uid,UserName,Phone,Address,UserPass,DepNumber）
values（@Uid,@UserName,@Phone,@Address,@UserPass,@DepNumber）
execUse_proc'200812','郑建娜','1586830','温州乐清','10010','1005'
execUse_proc'200813','戎婷婷','1586831','杭州萧山','10011','1007'
execUse_proc'200814','王友文','1586832','浙江衢州','10012','1003'
execUse_proc'200815','胡焕婷','1586833','宁波余姚','10013','1009'
execUse_proc'200816','吴志红','1586834','浙江丽水','10014','1004'
execUse_proc'200817','鲁玉娇','15
升级会员 