数据库系统设计

数据库系统设计（精选12篇）

数据库系统设计 第1篇

关键词：需求分析,逻辑设计,存储过程,E-R图,关系模型

1 引言

近年来随着就业形式的严峻化,及时地了解当今的人才需求,人才结构,人才分布,人才基本信息成为单位、个人、人才服务机构的当务之急。对人才信息的研究与探索能够使就业走向一个良好的趋势,使人才资源得到最快最合理的配置。于是,人才信息系统便应运而生。

人才信息系统数据库可作为人才数据收集系统和人才数据统计系统的后台数据库。人才信息系统将使得人才调查工作从手工操作转为自动化操作,提高了收集信息的效率。利用信息化系统的特点,统计分析工作将更加方便。

2 需求分析

需求分析是系统设计的起点,为以后的具体设计做准备。通过对用户及用户行为的分析及本系统的业务流程分析的基础上,确定系统应实现的功能。

2.1 用户和用户行为分析

人才信息数据库系统,不同于面向普通公众的信息系统,它是面向特定的客户群体,提供人才信息的系统功能,主要用户群体包括有用人单位、求职者、以及人才市场等各类人才机构。

用人单位:他们需要通过此类数据库及时地了解当前的人才结构、人才分布、人才市场的走势,快速地搜索需要的合适的人选,及时地发布和更新招聘信息。另外通过要了解当前人才对各个单位的看法、意见以及需求,以便在政策上做出相应的调整,让资源得到最合理的配置。

求职者:对于个人来说,主要的需求就是发布求职信息,了解招聘信息及其招聘单位的信息,了解单位在招聘时候所考虑的因素,以利于求职.另外通过此系统也能清楚地发现当今人才的供求状况,对自己的职业生涯能做出很好的规划与选择。

人才市场等机构:对人才市场的人流量,对人才中心所提供的服务内容/方式是否得到社会肯定,对单位/个人的各方面信息进行调查统计,从而更好的拓展工作范围,调整工作重点,更好得为社会服务。

2.2 用户对人才信息系统数据库的要求

1)信息更新速度快

当前社会经济发展迅速,产业分工细致,就业人员基数大,人才供求还是红红火火,人才信息的更新速度非常快,每天都有新的招聘信息,新的求职信息,而先掌握这些信息就意味着抢到竞争的先机。这就要求数据库可以快速的更新数据。

2)查询方式多

要能从各个角度去查询数据,从人才的学历、人才的月薪要求、人才的工作经验;从招聘公司的所在地,招聘公司的性质,招聘公司提供的待遇等各种条件去查找合适的对象。

3)检索速度快

检索系统操作简单,使用人性化。

3 业务流程分析

人才信息系统数据库主要的研究目标和内容为:从调查问卷中采集数据,通过分析整理成规范化数据表,根据用户的需求设置属性,最终设计并提供给人才信息收集与统计系统一个完整的数据库。

基本的业务流程如图1分为四个部分:

第一部分:根据需求分析来设计有针对性的问卷。问卷主要内容是对单位与个人的基本信息、单位的招聘信息以及个人的应聘信息等。

第二部分:对问卷上的问题及其采集到的数据进行分析处理,消除噪声。这一步骤对数据库设计而言及其关键。首先必须根据用户的需求对问卷上的问题进行抽象,抽象出实体,关系,属性,这都将影响到整个数据库的结构。

第三部分:进行数据库设计与实现。对数据库进行概念、逻辑、物理结构上的设计,得出E-R图,然后再用SQL语言进行定义。

第四部分:对数据库进行调式与维护。在SQL Server 2000等数据库管理系统软件上调式运行数据库。用户与系统设计人员进行沟通,对数据库进行评价,并制定一定的维护与安全策略。

4 数据库设计与实现

4.1 概念结构分析

本人才信息系统数据库概念设计的表达工具采用E-R模型,基本过程如下:

1)确定局部应用范围,主要分为七大模块

单位招聘管理:对单位基本信息及其招聘信息进行管理;

单位调查管理:对单位基本信息及其单位调查信息进行管理;

个人求职管理:对个人基本信息及其应聘信息进行管理;

个人调查管理:对个人基本信息及其个人调查信息进行管理;

单位与招聘途径:对单位与其主要招聘途径进行调查;

个人与求职途径:对个人与其主要求职途径进行调查;

单位个人与互动信息七大模块:对单位与个人发布的留言进行管理。

2)确定实体集

在单位招聘管理中实体集合有:单位,招聘信息,行业,性质等实体集。

在单位调查管理中实体集合有:单位,单位调查信息,培训方式,培训内容等。

在个人求职管理中实体集合有:个人,应聘信息,行业,学历,职称,户口所在地,专业,职称,工作经验,婚姻状况1,月薪,选单位条件,工作地点等。

在个人调查管理中实体集合有:个人,个人调查信息等。

在单位招聘途径中实体集合有:单位,招聘途径等。

在个人求职途径中实体集合有:个人,求职途径。

在单位个人与互动信息中实体集合有:单位,个人,互动信息。

另外还有人才收藏,新闻,用户实体集等。

3)确定实体集之间的联系

分析不同实体之间的联系,便于设计数据库完整性约束。

4)确认实体和联系的属性

根据功能要求,合理设置各实体和联系的属性。

5)画出局部E-R图

分别画出单位和个人的局部E-R图,如图2和图3所示。

6)集成局部E-R模型,形成全局初步E-R模型

全局E-R图4所示(箭头表示实体间存在联系,联系名如局部E-R图中所示)。

4.2 逻辑结构设计

1)实体与联系转化为表

E-R模型向关系模型转化主要是利用范式理论,将实体和联系转化为表,将其属性转化为表中的属性,一般使用SQL建表语言描述表名、属性名、属性的数据类型等。

2)实现数据库完整性约束

使用SQL语言完成上述表格之间的实体完整性、参照完整性约束和用户自定义完整性约束。

3)数据库优化

使用SQL语言建立索引、基于存储过程方式优化查询功能和基于视图的优化查询功能。下面给出部分存储过程的代码:

5 结束语

数据库设计是信息系统开发过程中的重要环节,其质量决定信息系统是否具备健壮性、可扩展性,是系统成败的一个标志。本设计方案做了认真的需求分析,为后续人才信息系统的开发设计了良好的数据处理层,在实践中取得了很好的效果,具有一定的现实意义。

参考文献

[1]郭盈发,张红娟.数据库原理[M].西安:西安电子科技大学出版社,2003.社,2003.

图书管理系统数据库设计 第2篇

3.1 专门术语的定义

暂无

3.1.1 系统中常用的术语(或使用频率较高的术语)暂无

3.1.2 表格定义及规范 3.1.2.1数据约定

所有数据项都用英文、汉语拼音或缩写表示，数据库名称除外。

所有字段在设计时，除以下数据类型timestamp、image、datetime、smalldatetime、uniqueidentifier、binary、sql_variant、binary、varbinary外，必须有默认值。字符型的默认值为一个空字符值串；数值型的默认值为数值0；逻辑型的默认值为数值0；

其中：系统中所有逻辑型中数值0表示为“假”；数值1表示为“真”。datetime、smalldatetime类型的字段没有默认值，必须为NULL。当字段定义为字符串形时建议使用varchar而不用nvarchar。建议在大多数表中（如报销单，申请单），应都有以下字段： 字段名说明类型默认值 CreatorID创建者int CreatedTime创建时间DatetimeNULL 字符集采用 UTF-8，请注意字符的转换。

所有数据表第一个字段都是系统内部使用自动序列主键列，自增字段，不可空，名称为：id，确保不把此字段暴露给最终用户。

除特别说明外，所有字符串字段都采用varchar(50)类型，(无论汉字还是英文，都算一个字符）。

除特别说明外，所有小数的字段都采用 decimal(18,2)的形式表达。

除特别说明外，所有日期格式都采用 datetime 格式（根据需要提取时间格式）； 除特别说明外，所有整形都采用 bigint 格式。除特别说明外，所有字段默认都设置为 null。3.1.2.2表和表字段命名规范：

命名规则约束的范围包括：数据库的命名、表的命名及字段的命名。数据库相关的命名规则采用与通常的编程的变量命名规则原则一致，具体要求如下： 1）字段名及表名为典型的名词结构； 2）中文名称要求语言精练、文法严谨；

3）望文知意、易懂易用，禁止采用如：A002这种命名；

4）主体采用拼音字母的首写字母拼写构成，基于惯常法可适度采用无词义歧义性的英文命名；

5）长度不少于3个字母，不大于12个字母；

6）在对于拼音首字母类似的字段和表，为区别，添加下划线和数字如男性人数：NXRS，女性人数：NXRS_2。

3.2 数据设计

绘制数据流程图的目的是为了方便开发人员与用户的交流，以及为系统的设计提供依据。数据流程图的绘制过程通常采用自顶向下，逐层分解，直到功能细化为止，形成若干层次的数据流程图。3.2.1 数据流程图设计

0层数据流图

1层数据流图

3.2.2实体关系结构设计

图书实体关系

读者实体关系

图书借阅关系实体

用户实体关系

图书类别实体关系

3.3安全保密设计

3.3.1 逻辑上的安全保密

1、系统对非法使用者的安全保密处理措施

2、系统对正常使用者的安全保密处理措施

3、系统对管理员的安全保密 3.3.2 物理上的安全保密

1、数据库系统异常时的还原处理措施

2、设备遭异常毁坏时的安全防护措施

3、数据参数做到及时更新，保证系统正常运行

3.4 表格与功能模块相关性分析

3.5 表格定义

a.图书信息表

b.读者信息表

c.借阅表

d.管理员_书籍

防雷装置检测业务系统数据库设计 第3篇

关键词：数据库；ER模式；关系模式；数据流图

中图分类号：P4文献标识码：A文章编号：1007-9599 (2011) 03-0000-02

Lightning Protection Device Detection Business System

Database Design

Zhou Liwei1,Hao Mei1,Chang Shengwen1,Zhang Yuxia2

(1.Changji State Meteorological Bureau,Changji831100,China:2.China Mobile Communications Group Co.Ltd.Changji Branch of XinJiang Company,Changji831100,China)

Abstract:This paper analyse the method of lightning protection device check and measure system database design based on the need of data methods and data process.

Keywords:Database;ER modol;Relational model;Data flow diagram

一、系统物理模型描述

规范的防雷装置检测业务工作过程用系统流程图详细描述如图1所示。

防雷装置检测业务从受检单位向检测单位递交检测申请开始，检测单位受理申请后，首先对检测场所进行勘查，获得检测场所防雷装置情况；然后，依据防雷技术规范的技术要求，确定场所防雷装置的检测项目，根据检测项目的评定需要进行检测项目数据采样；最后，依据技术规范标准，对采集数据进行分析、评定，得出检测场所防雷装置各项技术指标的检测结论。

二、系统逻辑模型

防雷装置检测业务系统逻辑模型用数据流图（DFD）描述如图2所示。

主要的数据流包括检测申请报告、检测场所勘查表、场所勘查记录表、检测数据采集表、数据采集记录表、检测结果评定表、结果评定记录表、检测报告、检测评定报告、查询单、查询汇总表。

主要的加工过程说明简要介绍如下：

（一）检测场所勘察：完成检测场所及检测场所防雷装置安装信息的收集，标志着一次防雷装置检测的开始实施。

（二）检测数据采集：完成对检测场所防雷装置检测项目进行数据采样和收集。

（三）检测结果评定：依据勘查数据和采集数据，对防雷装置的每一检测项目以及检测场所整体防雷装置技术情况进行检测结果评定。

（四）生成检测报告：形成检测报告，对检测场所防雷装置技术情况，就本次检测进行部分或综合评定，并以文本的形式，给受检单位予以说明。

（五）生成检测结果评定报告：形成检测评定报告，对检测场所防雷装置情况，就本次检测，进行詳细、完整的说明。

图2.防雷装置检测业务系统数据流图(图表里面多个“场所”两字，请删掉)

（六）查询：完成对检测数据的查询，生成查询结果汇总、打印，满足业务对数据的应用需求。

（七）入库1、4、8、11：完成各类检测数据的录入和保存入数据库操作。

加工过程的输入、输出见图2所示，加工过程的其它内容在此不再做进一步叙述。

三、数据存储

为满足生成检测场所勘查表、检测数据采集表、结果评定表、结果评定报告、检测报告加工对数据使用的需要，建立检测方案文件和检测数据项与数据标记对应关系文件数据存储，其数据来源都来自数据库文件，以配置文件的形式进行组织，对这两个数据存储简要介绍如下：

名称：检测方案文件

简述：存放一个或一类检测场所防雷装置检测所有数据项

组织方式：索引文件，以检测方案文件名称为关键字

组成：｛项目号+数据项名称｝

名称：检测数据项与数据标记对应关系文件

简述：存放检测数据项与数据标记对应关系，供数据使用过程中的标记替换操作使用

组织方式：索引文件，对应关系文件名称为关键字

组成：｛项目号+数据项名称+数据标记｝

数据库文件主要由受检单位记录、检测场所记录、防雷装置记录、采集数据记录和检测结果评定记录构成，数据存储组成分别简要介绍如下：

名称：受检单位记录

简述：存放受检单位信息

组成：单位编号+单位名称+单位地址+单位性质+所属区域+主管领导+…+单位备注。

组织方式：索引文件，以单位编号为关键字，单位编号由单位名称唯一确定

输入数据流：检测申请报告

输出数据流：检测场所勘查表、检测数据采集表、检测结果评定表、检测评定报告、检测报告、查询汇总表

名称：检测场所记录

简述：存放检测场所信息

组成：场所编号+场所名称+场所地址+场所防雷雷别+联系人+联系电话+．．．+场所备注

组织方式：索引文件，以场所编号做为关键字，场所编号由受检单位名称和检测场所名称唯一确定

输入数据流：场所勘查记录表

输出数据流：检测数据采集表、检测结果评定表、检测评定报告、检测报告、查询汇总表

名称：组织检测记录

简述：存放组织实施检测和检测综合评定信息

组成：检测场所编号+勘查日期+勘查人员+勘查录入+检测单位+检测负责人+采集日期+采集人+采集录入+…+评定日期+结果评定人员+综合检测结论及整改意见

组织方式：索引文件，以检测场所编号和勘查日期组合做为关键字

输入数据流：检测场所勘查表、检测数据采集表、检测结果评定表

输出数据流：检测评定报告、检测报告、查询汇总表

名称：防雷装置勘查记录

简述：存放检测场所防雷装置信息

组成：防雷装置编号+防雷装置名称+型号+…+装置备注

组织方式：索引文件，以防雷装置编号做为关键字，防雷装置编号由所属检测场所编号和防雷装置名称唯一确定

输入数据流：场所勘查记录表

输出数据流：检测报告、查询汇总表

名称：采集数据及单项评定记录

简述：存放检测项目采集数据及检测项目单项评定数据

组成：防雷装置编号+勘查日期+检测项目编号+实测数值+单项结论+单项整改意见

组织方式：索引文件，以防雷装置编号、检测项目编号和勘查日期组合做为关键字

输入数据流：数据采集记录表、结果评定记录表

输出数据流：检测评定报告、检测报告、查询汇总表

名称：检测项目记录

简述：存放对防雷装置进行评定的检测项目

组成：检测项目编号+检测项目名称+检测项目采样数据单位+项目备注

组织方式：索引文件，以检测项目编号为关键字，检测项目编号由检测项目名称唯一确定

输出数据流：检测数据采集表、检测结果评定表、检测评定报告、检测报告、查询汇总表

四、数据库概念设计

受检单位、检测场所、防雷装置、检测项目、采集数据之间的关系为：检测场所归属于受检单位，由受检单位负责申请检测单位对检测场所进行检测，并配合检测单位组织的检测；防雷装置是安装在检测场所的防雷设施，对检测场所进行雷电防护，保护场所设施、人员等免受雷电灾害侵害；检测项目是对特定防雷装置某项指标进行技术评定的项目，决定对防雷装置的数据采样；采集数据是检测项目的技术数据取样，是对防雷装置进行技术评定的数据依据。

抽象出受检单位实体，以受检单位编号作为实体标识符，依据受检单位记录数据存储的组成，确定实体属性；抽象出检测场所实体，以检测场所编号作为实体标识符，依据检测场所记录数据存储的组成，确定实体属性；抽象出组织检测联系类型，在受检单位实体和检测场所实体之间建立1：N的联系，依据组织检测记录数据存储的组成，确定联系类型的属性；抽象出防雷装置实体，以防雷装置编号作为实体标识符，依据防雷装置记录数据存储组成，确定实体属性；抽象出场所勘查联系类型，在检测场所和防雷装置之间建立1：N的联系；抽象出检测项目实体，以检测项目编号作为实体标识符，依据检测项目记录数据存储组成确定实体属性；抽象出数据采集联系类型，在防雷装置和检测项目之间建立M：Ｎ联系，依据采集数据及单项评定记录数据存储组成，确定联系类型属性。

最后，将各局部ER模式合并，完成系统数据库ER模式设计，完整ER模式如图3所示。

五、数据库关系模式设计

根据防雷装置检测业务系统对数据处理的需求，系统数据库建立在SQL SERVER2000关系型数据库管理系统中，将ER模式转换为关系模式，以便在关系型数据库管理系统中实现。

将受检单位、检测场所、防雷装置、检测项目分别转换为一个关系模式，分别以各实体属性作為对应各关系模式的属性，分别以各实体标识符作为对应各关系模式的键。

受检单位和检测场所实体间为1：N联系，但考虑到每一检测场所的定期多次组织检测问题，将组织检测联系类型也转换成单独的关系模式，由检测场所编号加组织检测联系类型属性构成关系模式属性，以外键检测场所编号和勘查日期组合作为关系模式的键。

检测场所和防雷装置实体间为1：N联系，在N端防雷装置实体类型转换成的关系模式中加入1端实体检测场所关系模式的键，由检测场所编号和防雷装置编号组合构成关系模式的键。

防雷装置和检测项目实体间为M：N联系，将数据采集联系类型转换成关系模式，关系模式中属性加入M和N端实体关系模式的键，同样，由于检测场所的定期多次组织检测问题，增加勘查日期属性，和组织检测建立联系，由外键防雷装置编号、检测项目编号和勘查日期组合作为关系模式的键，添加联系类型属性到关系模式属性。

由图3ER图转换成的关系模式如表4所示，加黑的为关系模式的键。

六、数据库物理设计

在SQL SERVER2000数据库管理系统中建立防雷装置检测业务系统数据库，根据数据库关系模式，分别建立受检单位、检测场所、组织检测、防雷装置、检测项目、数据采集相应的关系表。以各关系模式的键作为表的主键，依据各关系模式属性分别设计各表的字段，根据数据存储中各数据项的要求确定表中各数据项的类型、长度等。确定数据库的访问方法，编制应用程序，完成数据库的设计。

参考文献：

[1]丁宝康,李大学.数据库原理[M].北京:经济科学出版社,2000,3

[2]杨仲江.防雷工程检测审核与验收[S].南京信息工程大学雷电防护系列教材,2005

[作者简介]

易通打字系统数据库设计 第4篇

电脑操作人员首先要解决中英文字符输入问题,随着计算机技术与互联网技术的普及,很多家庭有了电脑,并且与互联网相连,这些都需要英语或汉字的录入技术,这样,才能把计算机技术与互联网技术带给人们的好处充分发挥,使大家的交流更方便、快捷。结合易通码的编码理论,在安装易通输入法的基础上,开发以易通码为中心的中英文输入指法练习软件。

随着我国计算机应用的迅速发展,大批科技人员、大中专学生、管理人员,以及各行各业的在职人员都迫切要求学习计算机知识,人们已经认识到,计算机知识是当代知识结构中不可缺少的重要部分。为了给易通输入法的初学者提供一个比较好的练习环境,结合易通码的编码理论,开发一套专业的中文易通输入、英文指法测试软件。

1 易通打字的工作流程

(1)用户登录,可以选择用户或注册新用户进行登录,系统将用户名、使用次数和日期写入数据库。

(2)用户登录之后进入系统主界面,可根据需要选择练习或测试内容。

(3)练习或测试结束之后,系统将记录成绩。

(4)用户退出系统。

易通打字工作流程如图1所示。

2 易通打字系统的逻辑模型

2.1 逻辑模型

用数据流图和数据字典构造系统逻辑模型。在数据流图中没有任何具体的物理元素,只是用来描绘信息在系统中的流动和处理情况。根据操作流程,把数据流图中的源点和终点选定为用户,得到易通打字的基本系统模型,如图2所示。

根据基本系统模型,逐步细化,得到描绘逻辑系统细化后的数据流图,如图3所示。

2.2 数据字典

由系统需求得到数据字典的四类元素:数据流、数据流分量(即数据元素)、数据存储和数据处理,设计出系统数据字典。图4列出了该系统的主要数据字典。

2.3 数据表

根据数据字典设计三个数据表,表结构见表1、2、3。

3 易通打字系统数据模型设计

建立一个概念性的数学模型。

3.1 数据库建模

经过分析,能够提取出用户、成绩、练习内容和易通码几个实体。实体图如图5、6、7和8所示。

分析各实体之间的联系,得出所有实体的联系图,如图9所示。

3.2 关系描述的设计

根据以上各实体图和联系图,导出所有关系:

用户(用户名、使用次数、登录日期)关键字为用户名。

成绩(序号、练习内容、姓名、时间、正确率、成绩)关键字为序号。

练习内容(键位、部件、简码、词组、文章)。

易通码(汉字、简码、汉语拼音、使用频度、全码部件、部件情况、部件笔顺、键位、击键情况、汉字笔顺)关键字为汉字。

4 易通打字系统数据库的设计

在系统分析阶段已完成了数据分析。根据数据分析建立的概念模型,得出满足第三范式的若干个关系描述,现在要把前面数据分析转化为具体的数据库。从数据库的逻辑设计和物理设计两个方面进行设计。

4.1 数据库的逻辑设计

完成数据的概念模型设计,开始进行数据库的逻辑设计。数据库的逻辑设计要把满足第三范式的关系转化为特定的数据库管理系统下的数据表。根据前面得到的各个实体关系,把它们转化为“用户信息表”、“用户成绩表”和“汉字编码表”。

(1)用户信息表:用户名、使用次数、使用日期。

(2)用户成绩表:序号、练习内容、姓名、时间、正确率、成绩。

(3)汉字编码表:汉字、简码、汉字拼音、使用频度、全码部件、部件情况、部件笔顺、键位、击键情况、汉字笔顺。其中汉字中的单字包括一级简码、二级简码、三级简码、四级简码。汉字中的词组包括二字词组、三字词组、四字词组和多字词组。

4.2 数据库的物理设计

完成了数据库的逻辑设计,即可开始数据库的物理设计。该信息管理系统的数据库系统采用Microsoft Access 2003数据库系统。

用Microsoft Access 2003数据库系统创建ytm.mdb数据库,在ytm.mdb数据库中按照表1、表2、表3的结构创建3个数据表。

5 结束语

按照软件工程生命周期方法学原理,开发了《易通打字系统》。该研究成果增加了计算机输入汉字的一种输入法的学习和使用。让需要了解“易通输入法”的专家和想学习“易通输入法”的人士能够安装使用。

参考文献

[1]徐祖华.汉字形码输字技术的现状与易通输入法[J].保山师专学报.2006.

[2]徐祖华.论易通输入法适合当前中小学信息技术教育的主要依据[J].保山师专学报.2008.

[3]吴道荣,王善发.获取Unicode字符集中汉字的拼音和内码[J].现代电子技术.2009.

[4]王善发,吴道荣.易通输入法多版本多系统安装软件设计与实现[J].现代电子技术.2009.

[5]刘瑞新主编.Visual Basic管理信息系统开发毕业设计指导及实例[M].北京:机械工业出版社.2006.

[6]李志云.用VB设计中英文打字测试软件[J].电脑编程技巧与维护.2006.

教务管理系统 数据库实例设计 第5篇

本章以一个考务管理系统的设计过程为例，介绍在VB 6.0+SQL Server 2000环境中开发数据库系统的一般方法。

17.1 系统概述

17.1.1 系统功能

本系统用于从考生报名、产生准考证到录取考生和打印成绩单即对考生考试和录取全过程进行管理的考务系统，包含主要功能如下：

      考生报名，按报名顺序产生报名号

产生准考生号和以紧凑方式打印准考证 输入考生考试成绩和输入录取合格标准 根据合格标准录取上线考生 打印考生成绩单和考生录取通知书 设置系统用户和系统初始化

17.1.2 设计技巧

数据库系统设计 第6篇

关键词 实时数据库 数据采集 系统设计 实现

中图分类号：TP392 文献标识码：A

这些年，企业进行信息化建设是我国一些大型企业所面临的重大问题。自从新世纪以来，烟草企业也逐渐开始信息化建设。随着MES 系统逐渐被人们认可，在接下来的几年之内，卷烟企业进行战略性调整和信息化建设是关键的工作，这直接决定了中国烟草工业的命运。

1 数据中心框架结构和设计

1.1系统设计的目标

设计出来的实时数据采集系统达到的效果如下：能够建设符合各个领域里面的决策系统；集中了很多小规模范围里面的应用；能够有效分担其它的事物处理系统的负担，提高决策和事物处理的效率。这个系统建设是以公司的业务流程建立的一个管理机制，是可以提供准确相同的分析数据。整个系统采用的是大量数据集中在一起的方式，这样就可以实现数据的自动获取和积累，还有就是业务数据和信息在整个行业里面实现共享。这个系统还能够提供一个相当强大的数据处理平台，能够满足不同种类业务的分析。整个系统的建立还能够提高工作的效率和准确性。这个系统能够满足现代的企业管理模式，这样就可以使得业务流程化和规范化。这样就可以通过智能的商业技术对集团的信息进行分析预测，还可以实现业务的自动化，为企业领导分析决策提供一个准确的依据。

1.2系统的性能指标

在进行实时数据库系统设计的时候需要保证的系统性能如下：（1）可靠性和及时性，设计出来的系统必须能够二十四小时进行工作。这样就可以保证系统在任何情况之下都可以进行资源的分配，这样就可以保证各个板块的功能能够正常进行。（2）系统的整体性和效率性，设计的系统需要是一个高效的一体化管理系统，系统需要能够容纳大量的数据，而且数据的更新还需要在短时间之内完成。整个系统需要在短时间之内完成对数据的处理，而且还需要高效率高质量完成。（3）系统需要先进和实时，整个系统可以运用充分的资源，然后根据客户的要求，把高的工作效率和好的经济效益当作是主要要求，在这个基础上，为客户提供一系列业务服务平台。（4）系统的安全性和实时性，系统采集的数据安全是十分重要的，在系统的设计过程当中，设计人员需要采取严格的技术来对技术进行保密。设计人员需要通过保密技术来保证用户身份的真实性，数据的完整性。在网络连接良好的情况之下，对每一个IP地址请求的操作处理时间需要控制在一分钟时间之内。（5）整个系统需要支持集群技术，设计人员可以通过多个服务器来完成一个集群，当服务器上面的用户达到最大的时候，其它的服务器会开始工作。（6）整个系统需要有一个完好的信息输出端口，整个系统的目标是为了对数据进行分析，而分析的目的是为了借鉴使用。为了能够进行应用，就需要把分析得到的结果数据转化成不同的输出文本，有的人需要把它变成演讲文稿，有的人就需要获得一个Excel数据。一般的开发格式有Excel， PPT， HTML等。

2 系统的结构

烟草企业对过程的监控和数据出来了是通过紫金桥实时数据库来完成的，它把现场的各种数据集中在一起，这些数据包括了生产上面的数据、设备的数据和质量数据等，在此同时整个数据库还包括一个完整的数据查询和分析功能，这可以为企业的生产和决策提供一个可靠的依据。还有生产过程出现状况的时候，系统还能够随时发出警报，这样就能够很方便采取处理解决的措施。整个系统还需要提供各种接口，比如说S Q L 接口、AP I接口等，通过这些接口就可以把各种组件连接到一起，这样就可以实现数据库能够正常工作。

3 实时数据库的功能

实时数据库的作用是对烟草企业的生产过程实施监控管理，但是它在这个系统的作用不只是储存数据，它还需要处理现场采集获得的数据，对获得的数据进行加工分析，一旦出现异常情况发出警报。它需要实现的功能如下：（1）事故的追忆功能。这就需要系统对和事件有关的状态进行记录，这样在事件产生之后就能够进行原因分析了。事件的数量、时间范围等都是可以自由设定的。（2）数据的压缩备份功能，中心的服务器刷新的时间是1 s ，在这样的情况之下，数据库不进行压缩的话是无法容纳这么多数据的。这就要求数据库进行压缩运算，这就可以解决数据量大的问题。（3）物料平衡，系统需要对实际的投料数据、收率数据等进行计算，然后对不同的时间数据进行统计分析。实时数据库当中的数据也是可以来自现场的，也可以通过人工输入的方式。（4）趋势分析，趋势功能主要包括了用户可以选择查看一些含有PID 数值的趋势图，也可以把趋势图打印出来，或者是把图片保存成图片的格式。用户还可以输入开始和结束的时间来查看数据的走向。趋势图如图1 所示。（5）系统还需要有班组考核功能，主要通过对重要工艺数据的追踪，发现生产过程当中的问题，然后提出改进意见。（6）系统还需要有统计分析功能，这样就可以全程监控产品质量。（7）系统还需要有报表系统，这样就可以制作各种各样的报表。

4 总结

考虑到我国烟草企业的规模大，所以系统的点数要多，这样就要有好的数据采集和储存，还需要制定大量的趋势图和报表。实施数据库需要有良好的性能和繁多的数据接口，这样不仅能够满足项目要求，还能够对烟草企业做出评价，推动烟草企业的信息化发展。

参考文献

[1] 张俊良，薛振兴.烟草企业数据中心系统的设计与实现[J].安徽：电脑知识与技术，2009（5） ： 2316.

[2] 付文，范广辉.实时数据库实现烟草行业过程管理实时监控系统[J].江苏：工业控制计算机，2009（3） ： 17-18.

[3] 徐毅博.烟草一号工程工业数据采集系统设计与实现[J].北京：硅谷，2012（7） ： 170-172.

会计信息系统数据库加密设计 第7篇

会计信息系统 (accounting information system, AIS) 是指一个通过人或计算机对物流、资金流、信息流实施管理的信息系统, 其目标是将会计数据转换为会计信息。会计信息系统作为各企、事业单位的核心系统, 有着极高的重要性。

随着网络技术的迅速发展及应用领域的不断拓宽, 使会计信息系统出现了许多不安全的因素。数据库集中存储着关键信息, 容易成为攻击的对象, 特别对持有敏感信息的会计信息系统来说更是如此。因此为了使得会计信息系统在网络环境下安全有效地运行, 研究网络环境下的会计信息系统数据库安全隐患及控制是必要的。

研究会计信息系统数据库安全性之前, 有必要先了解信息安全的定义及其组成部分。

1.1 信息安全的3个组成部分

信息安全是指信息在产生、传输、处理和存储过程中不被泄露或破坏, 确保信息的可用性、保密性、完整性和不可否认性, 并保证信息系统的可靠性和可控性。

其中有3个非常重要的组成部分:机密性 (Confidentiality) 、完整性 (Integrity) 和可用性 (Availability) 。

机密性确保计算机的相关资源仅被合法用户访问。也就是说, 只有那些有权访问资源的用户才能得到实际的资源访问。

完整性是指所有资源只能由授权方或以授权的方式进行修改。

可用性是指所有资源在适当的时候可以由授权方访问。换句话讲, 如果某些人或系统有访问某个资源的合法权限, 那么访问就不能被拒绝。

1.2 传统系统的安全策略及安全隐患

传统的会计信息系统通过用户权限来限制用户可以访问的数据, 并将系统与外网断开连接, 从而达到保护数据的目的。但是对数据库本身的保护却没有涉及, 财务数据以明文的形式保存在数据库中。

数据库作为存放财务数据的主要形式, 面临的安全威胁可用图1来说明。

数据库面对着各方面的严重威胁, 就要保证数据库环境的两个主要安全问题:完整性和机密性。

2 数据库安全性要求

2.1 数据库的完整性

数据库的完整性是DBMS、操作系统和计算机系统管理者共同的责任。数据库管理程序必须进行访问控制, 确保只有经批准的用户才能更新或删除数据, 另外, 数据库系统还必须防范人为的外力灾难。从操作系统和计算机系统管理者的角度看, 数据库和DBMS分别是文件和程序。因此对整个数据库的一种保护形式是对系统上的所有文件周期性地做备份。数据库的周期性备份可以减少由灾祸造成的损失, 并能在系统出错后重建数据库, 因此DBMS必须维护对事务的记录。在发生数据库系统失败的事故时, 由数据库的备份开始重新处理记录之后的所有业务。

2.2 元素的完整性

数据库元素的完整性是指它们的正确性和准确性。由于用户在搜集数据计算结果和输入数值时可能会出现错误, 所以DBMS必须帮助用户在输入时能发现错误, 并在插入错误数据后能纠正他们。

DBMS用3种方式维护数据库的每个项目的完整性。

(1) 字段检查:这种检查可以防止在向数据库输入时可能出现的简单错误。

(2) 访问控制:通过访问控制来维护数据库的完整性、真实性和一致性。一个数据库可能包含几种来源的数据, 而在开发一个数据库之前, 可能在许多表中存储了重复的数据, 这就需要一种策略来解决可能发生的数据冲突问题。

(3) 更改日志:它是数据库每次改变的记录文件, 日志包括原来的值和修改后的值。数据库管理员可以根据日志撤消任何错误的修改。

2.3 可审计性

在某些应用中, 可能需要产生对数据库的所有访问 (读或写) 的审计记录, 这种记录可以协助维持数据的完整性, 或者至少可以帮助在事后发现谁在影响以及何时影响过什么值。攻击者可能会以逐次递增的方式形成对被保护数据的访问, 不是单用一次访问来获取被保护的数据, 而是用一组访问来获取一些敏感的数据。在这种情况下, 审计踪迹可以作为分析攻击者线索的依据。

2.4 访问控制

数据库通常根据用户访问权限进行逻辑分割。例如, 一般用户访问一般数据——市场部可以得到销售数据, 人事部门可以得到工资数据等。

DBMS必须实施访问控制策略, 指定哪些数据允许被访问或者禁止访问;指定允许谁访问哪些数据, 这些数据可以是字段或记录, 甚至是元素。DBMS批准某个用户对某个进程有权读取、修改、删除、附加一个值, 增加或删除整个字段或记录, 或者重新组织完全的数据库。

对数据库的访问控制和操作系统的访问控制有根本的区别。数据库中更为复杂, 因为数据库中的记录字段和元素是互相关联的, 用户只能通过某个文件而确定文件内容, 但却有可能通过读取数据库中的某些元素确定数据库中的另一个元素, 也就是说, 用户可以通过推理的方法从某些数据值得到另外一些数据值。

2.5 用户认证

DBMS会要求用户进行严格的用户认证——一个DBMS可能要求用户传递指定的通行字和时间日志检查。这一认证是在操作系统完成的认证之外另加的。DBMS在操作系统之外作为一个应用程序被运行, 这意味着它没有与操作系统可信赖的互操作路径, DBMS必须怀疑它所收到的任何数据, 包括用户认证。因此, DBMS最好有自己的认证机制。

2.6 可用性

DBMS的可用性。数据库中的数据并不是任何时候都可以访问, 例如一个用户在对几个字段更新时, 其他用户对这几个字段的访问请求将被禁止, 当更新完毕, 其他用户便可允许对这些字段进行访问。

3 数据库加密的一般策略

3.1 加密层次的选择

数据库加密模块可以选择在3个不同层次实现, 这3个层次分别是OS (操作系统) 、DBMS内核和DBMS外层。

3.1.1 OS层

在OS层加密, 其加密粒度是整个文件, 十分粗糙, 无法辨认数据库文件中的数据关系, 因而无法根据数据关系对数据进行合理的加密。所以, 在OS层直接对数据库文件进行加密, 对于大型数据库来说, 目前还难以实现。

3.1.2 DBMS内核层

在DBMS内核层加密, 是指数据在物理存取之前完成加解密工作。这种方式势必造成DBMS和加密器 (硬件或软件) 之间的接口需要DBMS开发商的支持。这种加密方式的优点是加密功能强, 并且加密功能几乎不会影响DBMS的功能。其缺点是在服务器端进行加/解密运算, 加重了数据库服务器的负载。

在DBMS内核层加密, 是指数据在物理存取之前完成加解密工作。这种方式可以更有效和DBMS内部的各种功能结合起来, 但是需要对DBMS的内核进行修改, 需要DBMS开发商的支持。本文所举的Oracle数据库加密实例, 以Oracle提供的安全包为基础制定加密策略, 所采取的加密层次就是DBMS内核层加密。

3.1.3 DBMS外层

采用DBMS外层加密方式时, 加/解密运算、密钥的管理等工作在DBMS外层执行, 不会加重数据库服务器的负载并且可以根据需要灵活配置数据库加密, 但是加密功能会受到一些限制。

3.2 加密算法的选择

目前常用的加密算法可分为2类:对称加密算法 (DES) 和非对称加密算法 (AES) 。

对称加密算法的加密和解密密钥相同, 具有加解密速度快、保密度高等优点。对称加密算法按加密模式又可分为序列密码和分组密码两大类, 序列密码以字符为单位进行加密变换, 每一字符数据的加密与报文的其他部分无关;分组加密时, 明文按固定长度分组, 对各组数据用不同的密钥加密。

非对称加密算法加密和解密使用不同的密钥, 加解密速度较慢。

数据库加密系统要求所使用的加密算法安全性高的同时加解密速度足够快, 尽量不影响用户使用, 并且加密后, 数据量不应该明显增加。因此选择使用对称密钥的分组加密算法。

3.3 数据库加密的范围

一方面, 经过加密的数据库须经得起来自OS和DBMS的攻击;另一方面, DBMS要完成对数据库文件的管理和使用, 必须具有能够识别部分数据的条件。因此, 只能对数据库中的数据进行部分加密。数据库中不能加密的部分包括:

(1) 索引字段不能加密。为了达到迅速查询的目的, 数据库文件需要建立一些索引, 他们的建立和应用必须是明文状态, 否则将失去索引的作用。

(2) 关系运算的比较字段不能加密。DBMS要组织和完成关系运算, 参加并、差、积、商、投影、选择和连接等操作的数据一般要经过条件筛选, 这种“条件”选择项必须是明文, 否则DBMS将无法进行比较筛选。

(3) 表间的连接码字段不能加密。数据模型规范化以后, 数据库之间存在着密切的联系, 这种相关性往往是通过“外部编码”联系的, 这些编码若加密就无法进行表与表之间的连接运算。

4 Oracle密文数据库系统设计

4.1 加密软件包及功能

Oracle数据库是会计信息系统的常用数据库, 与Sysbase、SqlServer等数据库管理系统一样, Oracle数据库管理系统的主要功能仍然是实现对数据的管理及操作, 数据加密只是为了提高存储数据的安全性而附加的功能。Oracle数据库加密功能的实现由数据库平台提供的软件包来支持。

Oracle 10.2g提供了透明数据加密DBMS_CRYPTO程序包, 该包包含2个基本的加密函数ENCRYPT和解密函数DE-CRYPT, 它能够加密日期、字符串、数字等基本的Oracle数据类型, 也能支持大对象LOB和RAW十六进制字符串类型。该程序包提供了多种加密方法, 针对所选择的密钥可进行大量选项组合, 增加了密钥破解的复杂度。

DBMS_CRYPTO支持的密码特性如表1所示:

4.2 加密算法

从表1可以看出, 在软件包DBMS_CRYPTO中, 加密算法不仅支持DES以及3倍DES (DES3) , 而且还支持256位的高级加密标准AES等, 使用户有了更多的选择, 也使加密数据可以达到更高的安全强度。软件包中支持的算法属于分组密码算法, 其分组大小是固定的。如果加密信息长度不在分组边界, 就需要附加数据填充, 使它充满整个分组。填充的方法有固定值填充、随机填充、PKCS填充。固定值填充最常用的填充值是0x00/0x80加0、1字符串, 不常用的填充值是0xff;随机填充采用随机位来填充;PKCS (Public Key Cryptography Standard, 公开密钥密码标准) 填充使用信息长度编码, 因此不需要预先知道信息长度就可以去掉填充。O-racle 10g中, 可以根据需要用不同的参数来确定所选择的填充类型。在运算模式上, Oracle 10g中支持ECB、CBC、CFB及OFB。

4.3 密钥存储和管理

在数据加密中, 密钥的存储和管理是非常重要的, 它直接影响到数据加密的安全性。但是, 在数据库管理系统内核层加密策略中, 并没有提供密钥存储的方法, 这也是在以Oracle提供的安全包为基础制定加密策略时最难解决的部分。在制定密钥的存储和管理方案时, 要确保以下两点: (1) 密钥存储足够可靠, 以确保能够保护数据; (2) 要保证合法用户且只有合法用户可以获取密钥。在数据库加密中, 密钥通常存在数据库中、文件系统中或用户自身的存储设备中。Oracle数据库加密中、文件系统中或用户自身的存储设备中。Oracle数据库加密中, 密钥仍然是以数据表形式存放在数据库中。如果密钥以明文形式存放在数据库中, 那么攻击者只要进入数据库系统中, 就很容易找到破解密文的密钥。如果密钥以密文形式存放在数据库中, 那么加密密钥的密钥如何存放就成了需要解决的新问题。

本例的解决方法是采用多级密钥存储管理, 把用户密钥与数据密钥结合使用, 提高数据库加密的安全性。

4.4 加密实例

下面用一个例子介绍如何利用Oracle软件包DBMS_CPYPTO提供的功能, 保护工资查询系统中的数据库。

4.4.1 数据表结构

本例中用到两个数据表 (为了便于理解, 省略了其余字段) , 其中表emp_salary_enc存放职工薪资信息, Emp_id为职工工号, Salary_enc为加密后的薪资。而表emp_salary_keys中, Emp_id存放的仍然是职工的工号, 它与表emp_salary_enc中的工号是一致的, key中存放的是加密相应职工薪资的密钥。其表结构如表2、表3所示。

4.4.2 数据查询及更新

为了查询职工薪资信息, 首先需要生成视图vw_emp_salary, 生成语句:

在建立视图后, 可以把其权限授予其他用户, 并建立一个视图的同义词。这种情况下, 用户只能从视图中查找数据。

当需要插入或修改客户数据时, 则可以通过一个触发器来更新表emp_salary_enc的信息。对表emp_salary_enc操作的触发器定义:

4.4.3 加密及解密函数

在上述操作中, 函数get_enc_val及get_dec_val的功能分别是对数据库进行加密及解密。在函数中, 利用了Oracle软件包DBMS_CRYPTO中支持的加密函数、运算模式及填充模式。

(1) 加密函数

(2) 解密函数

在加密与解密函数中, 分别用到了函数UTL_IL8N.STRING_TO_RAW (e_val, ‘AL32UTF8’) 及UTL_IL8N.RAW_TO_CHAR (d_val, ‘AL32UTF8’) , 其作用是进行字符类型与RAW类型的转换。由于Oracle 10g中加密函数Encrypt () 仅支持RAW类型的变量, 因此在数据加密时需要先把其他类型的数据转换成RAW类型, 而解密后则需要相反的操作。

4.5 测试密文数据库性能

在工资查询系统中, 建立100000条数据, 记录插入记录和查询记录所使用的时间, 如表4所示。

从表4可以看出, 数据库加密模块对数据库系统效率的影响并不是很大, 用户可以接受等待的时间。

5 结语

介绍了会计信息系统的定义和其组成部分, 列举了数据库安全的基本要求和保护方式, 并通过一个密文Oracle数据库系统实现实例, 详细分析了密钥存储和管理这一关键问题, 利用数据库自带软件包DBMS_CPYPTO实现数据库的加密与解密, 最后给出了这种方式构造的密文数据库系统不仅提高了数据库中敏感数据的安全性, 并且查询时间没有明显降低。以后研究工作重点一方面是考虑如何在压缩索引技术下提高查询效率, 另一方面是在现有数据库加密系统的基础上实现更强的用户身份认证 (如IC卡、Skey等) 、与操作系统的安全机制紧密衔接等系统功能, 从而保证数据库加密系统在一个更加安全的环境下运行。

摘要：介绍了数据库的安全技术, 讨论了数据库安全设计问题, 提出了通过加密数据库来提高会计信息系统的安全性。

关键词：会计信息系统,数据库加密,信息安全

参考文献

[1]Matt Bishop, Computer Security Art and Science, Publishing House of Electronics Industry, 2005.

[2]Charles P.Pfleeger&Shari Lawrence Pfleeger, Security in Computing Third Edition, Publishing House of Electronics In-dustry, 2004.

[3]毛元青, 李秀丽.会计信息系统.科学出版社, 2007.

[4]施伯乐, 丁宝康, 汪卫.数据库系统教程.第2版.高等教育出版社, 2003.

[5]李海泉, 李健.计算机系统安全技术.人民邮电出版社, 2001.

监测系统数据库备份机制设计 第8篇

近年来, 随着监测业务的发展和信息化水平的提高, 数据库在监测系统中的应用越来越广泛。报警信息、运行图信息、指标测量信息和用户信息等重要监测数据都存储在数据库中, 这些数据支撑着监测系统的正常运行。因此对上述数据的可靠、稳定、安全提出了更加苛刻的要求, 如何尽最大可能为各种数据提供安全保障, 并提供快速的数据恢复能力, 保证数据的完整性、正确性就成为当前数据库维护人员首要解决的问题。

目前, 大型分布式网络化数据库, 其主流的数据保护措施为依托网络建立高可用性与高可靠性的数据库安全备份系统, 所采用的备份方式主要有联机备份和脱机备份两种。

联机备份方式通常使用在业务系统不能接受数据库停机运行的情况下。在进行联机备份前, 需要启动ARCH数据库进程对重做日志文件进行归档, 重做日志文件存储着系统执行任务时对数据库所做的所有更改, 在联机备份时, 需要备份数据文件、控制文件和重做日志文件, 如果需要恢复数据, 可以使用重做日志文件进行恢复。

若数据库可以停止运行或采用主从模式时, 则可采用脱机方式进行备份。该方式一般均采用操作系统的物理拷贝来完成数据库的备份, 在备份前不需要对重做日志文件进行备份, 备份文件包括数据库物理文件和控制文件等。

相比联机方式, 脱机方式备份速度快, 且发生故障的概率小。但是, 目前监测系统数据库均要求7×24小时不间断运行, 因此, 数据库备份必须采用联机备份方式, 在该种方式中, 数据库进程与备份任务同时进行。

2 数据库备份机制设计

设计数据库备份机制是实施数据库备份的核心环节, 备份机制是指在备份过程中, 通过分析影响备份的各种因素的相互关系、产生的影响及其运行方式, 对各种因素进行合理的调整和配置的过程, 是数据库备份所必需遵守的基本规则。要保证数据库备份任务真正实现, 就必须设计一套灵活、高效的备份机制。本文通过对数据库联机备份工作原理进行深入研究并参考一些设计案例, 对数据库备份机制的设计进行了分析。

2.1 规划存储磁带卷组

数据库备份数据均保存在磁带机的磁带中, 通常一个备份磁带机要同时对多个数据库系统提供备份数据服务, 为提高磁带的使用率, 特别是便于日后进行磁带的归类管理和数据库灾难性恢复, 首先需要为每个数据库系统建立存储磁带卷组, 并对数据库系统备份数据量进行计算, 按备份数据量的不同为每个卷组合理分配磁带。数据库备份数据包括:归档日志文件和数据库全备文件, 备份数据总量以不超过卷组中磁带总存储容量的80%为宜。

另外, 在实际工作中发现, 在某些极端情况下 (如:短时间内大量数据上报或大规模的节点接入等) , 备份数据量会激增, 原有的磁带卷组会因无法存储超量数据而造成数据丢失, 给备份系统的正常运行带来隐患。因此, 建议对剩余未分配的磁带也应进行配置, 建立应急动态分配磁带组, 该磁带组的作用是:一旦某业务磁带组因突发性的大规模数据增加而导致存储空间用尽时, 可自动分配空磁带至该组中, 保障数据备份的正常进行。

2.2 设定备份任务执行频率

数据库备份包括有:归档日志文件备份和数据库全备两种模式, 针对不同备份模式设定备份任务执行频率是设计机制的核心内容, 适合的备份执行频率即可以完全保证数据的安全性和有效性, 又不会对数据库系统的正常运行产生影响。因此, 在设定执行频率时, 需要综合全面地考虑备份数据量、备份任务执行时间、链路传输速率、备份节点数量及对数据库系统压力等多方面因素。

2.2.1 归档日志文件备份

归档日志文件备份是指对数据库每日产生的归档日志文件进行备份, 归档日志文件中记录对数据库所做的修改, 包括:插入、删除、更新数据等, 只有对数据库的归档日志文件进行正常备份, 才可以对数据库进行灾难性恢复。

由于归档日志文件备份数据量较小, 备份任务执行时间较短, 且任务执行过程中对数据库系统压力较小, 不会影响业务系统的正常运行, 因此建议在周一至周五工作时间进行, 每天执行一次, 可以根据节点数量进行平均分布, 每个整点时间并发执行若干个节点备份任务。

2.2.2 数据库完全备份

数据库完全备份不仅包括归档日志文件的备份, 还包括数据文件和控制文件的备份。由于相对归档日志备份文件, 完全备份文件数据量较大, 需要执行时间较长, 对数据库系统压力较大, 因此建议在非工作时间进行。同时, 数据库全备作为一段时间的数据库完全镜像, 不需要每天执行。因此建议根据实际数据文件的增长情况, 以1周或2周为时间单位, 在周末执行全备任务。

需要注意的是, 如果备份数据库节点分布在全国, 各个节点的网络环境和传输速率可能会存在较大差异, 建议首先对各节点网络传输速率进行测试, 将传输速率较慢的节点备份任务安排在最后执行, 确保不会因个别节点备份速率慢而影响其他节点备份的正常进行。

2.3 确定备份数据保存时间

备份数据保存时间需要根据所备份数据类型及实际业务需求, 同时要参考磁带库的可用磁带容量进行设定。

如果备份数据为数字化视频文件、音频文件或图片等多媒体信息, 则为保障多媒体信息在视频点播、交互式视频服务和远程教育等应用中的持续有效性, 一般备份保存时间设置较长, 并需要根据多媒体数据内容组织分类存储, 便于日后快速检索与恢复, 某些特别重要多媒体信息可不设置保存时间, 进行永久保存。

若备份数据为文本数据和数值数据等, 由于每日会对数据库进行归档文件备份, 定期还会进行数据库全备, 通过归档备份文件和全备文件, 备份系统可在任意时刻对数据库数据进行恢复, 因此可将备份保存时间设置较短, 超过保存时间, 新的备份数据自动将原有数据覆盖。

3 数据库备份机制设计实例

为提高监测系统数据库的安全性, 对监测系统数据库实施了数据库备份操作。现以该数据库备份实例为例, 详细描述数据库备份机制设计过程。

3.1 监测系统数据库特点

根据监测业务需要, 监测系统数据库按照分布式网络化体系结构进行设计, 规模较大。采用中心-分中心两级层次结构, 中心数据库负责处理各分中心上报的监测数据;各分中心数据库负责汇总、处理本省的监测数据并通过国干网与中心数据库进行数据传输与同步。

监测系统负责对全国各地市的多媒体业务进行内容与播出质量的监测工作。由于监测前端数量较多、监测业务覆盖面广、监测数据总量及每日新增的监测数据均较大, 且由监测业务的性质决定, 因此监测业务需要不间断运行。

3.2 数据库运行情况分析

设计建立合理的备份机制是整个数据库备份系统的核心工作, 建立备份机制要充分考虑数据库系统自身运行情况及特点。现结合监测系统数据库特点, 首先对数据库运行情况进行分析:

3.2.1 备份数据量统计

打开数据库归档模式后, 经计算, 分中心数据库每日产生的归档日志文件数据量约为20GB;中心数据库每日产生的归档日志文件数据量约为15GB, 周一至周五所有数据库共产生175GB归档日志文件。分中心数据库全备一次产生75GB数据;中心数据库全备一次产生207GB数据, 数据库全备一次共产生282GB数据。

3.2.2 备份用时计算

分中心数据库采用SDH网络进行数据传输, 单个分中心产生的归档日志平均为344MB, 最大归档日志为405MB。按最大备份数据量进行测试, 备份一个分中心节点用时5分钟左右。单个分中心全备产生的数据量约为归档日志数据量的3倍, 因此全备一个分中心节点需要用时约15分钟左右。中心数据库均采用百兆以太网方式进行备份数据传输, 通过分析得知, 每日生成归档日志最大为2GB, 每次全备数据量最大为40GB。经测试, 归档日志备份用时10分钟左右, 数据库全备用时约为归档日志备份用时4倍。

3.3 数据库备份机制

通过前期对备份数据库节点数量、数据库软件类型、操作系统类型、服务器类型和网络传输模式等环境信息统计, 并考虑备份数据量大小和备份用时, 制定适合监测系统的数据库备份机制是非常必要的。

3.3.1 划分存储磁带组

监测系统备份采用HP MSL4048磁带机, 包括2个磁带驱动器、47盘磁带和1盘清洗带, 可用存储空间为37.6TB, 完全可满足数据库备份需要。

监测系统分中心数据库备份磁带组配置13盘磁带, 存储空间为10.4TB, 占可分配总资源的27.66%;中心数据库系统备份数据量稍小, 配置12盘磁带, 占可分配总资源的25.53%;剩余未分配磁带占可分配总资源的46.81%, 组成应急动态分配磁带组。

3.3.2 设定备份执行时间

监测系统周一至周五, 在白天进行报警数据采集与分析处理、数据同步及其他日常监测工作;在夜间进行报警数据采集与分析处理工作;在周末进行报警数据采集与分析处理工作。因周末监测业务较少, 对数据库系统压力较小, 因此, 将对数据库系统压力较大的数据库全备工作安排在周末进行, 而将对数据库系统压力较小的归档日志文件备份工作安排在周一至周五进行。

(1) 归档备份执行时间

周一至周五每天均需要执行归档日志文件备份。经前期计算可知, 分中心数据库每日生成归档日志文件较小, 备份时间相对较短, 因此将分中心数据库归档日志文件备份安排在周一至周五每日0:00开始执行, 每个整点顺次执行4个分中心归档日志备份, 每个备份任务执行时间为4小时, 保证即使出现大量归档日志需要进行备份时, 也有充足的时间完成备份工作。

当完成分中心归档日志文件备份后, 在周一至周五每日的17:00开始执行中心数据库归档日志备份。由于中心数据库归档日志较大, 需要备份时间相对较长, 所以从17:00开始, 每个整点执行2个中心数据库归档日志备份, 每个备份任务执行时间为4小时。预计每个工作日23:59分以前可以完成所有数据库归档日志文件备份操作。

(2) 全备执行时间

数据库全备在每周六、日执行。监测系统分中心数据库全备在每周六0:00开始执行, 每个整点顺次执行2个分中心数据库全备, 每个备份任务执行时间为6小时, 预计在每周日12:00之前可完成所有分中心数据库全备;在每周日12:00执行监测系统中心数据库全备, 备份任务执行时间4小时, 预计每周日16:00之前可完成中心数据库全备操作。

另外, 因为分中心数据库采用SDH方式将备份数据传输回北京中心, 传输速率受当地网络环境影响差异较大, 因此根据前期测试结果, 将传输速率较慢的分中心备份工作安排在最后执行, 确保不会因个别分中心备份速度慢而影响其他备份任务正常进行。

3.3.3 设定数据保存时间

根据监测业务实际需求, 同时考虑到磁带库容量, 由于备份数据均为文本数据和数值数据, 不包含多媒体数据, 因此将备份数据保存时间设置为3个月。超过3个月, 新的备份数据自动将原有数据覆盖。

4 目前存在的问题

2008年年末, 监测业务数据库备份机制设计完毕并投入使用至今, 已经有1年左右时间, 累计完成近2万次数据库归档日志备份和3千余次数据库全备, 备份数据总量约22TB。实践证明, 该备份机制设计合理, 能满足监测系统使用要求, 使监测业务数据得到了全面保护。

但在使用中也发现随着监测节点数量增加和监测业务的扩展, 新生成的备份数据量相比设计时有明显的增加, 原先规划的磁带卷组存储容量逐渐无法满足备份数据量增长需求, 导致在备份过程中越来越频繁地调用应急动态分配组磁带。因此, 在今后使用中, 需结合监测业务的发展, 定期对磁带卷组存储容量进行调整。

5 结束语

管理信息系统数据库安全体系设计 第9篇

关键词：信息系统,网络安全,网络安全审计,入侵检测

实时安全分析可帮助人们即时获取关于系统高层次、整体性的安全信息, 进而从整体了解系统的安全态势。目前, 基于实时安全分析对大型复杂系统进行安全监控正成为国际上安全性研究的热点。将实时安全分析应用于系统安全监控的一个难点问题是缺乏有效的安全监控体系。管理信息系统也可以称为较为复杂的系统, 它涉及到事务计划、个人身份资料、事务处理情况以及其他极其重要的日常管理信息, 是企业运作的关键所在。由于企业的后台操作环境是在一个局域网内进行的, 在该环境下MIS的安全问题受到高度关注。因此, 基于局域网的管理信息系统安全监控体系的研究显得尤为重要。

1 数据库对MIS安全的影响

在对整个系统进行安全配置时, 除了对系统基础架构上进行安全配置研究外, 对数据库的安全配置也应给予更多关注。事实上, 攻击者的主要目标往往就是数据库, 通常MIS后台数据库使用的是Oracle数据库。目前, Oracle 11g功能强大, 应用广泛, 是使用得最多的数据库之一。虽然它已通过了美国政府定义的C2安全认证, 但针对其所出现的安全问题也层出不穷, 常见的安全问题包括有利用缓冲区溢出、攻击 (端口和客户端) 、密码猎取、物理数据文件损坏或被盗、不够完善的备份策略以及可能被利用去执行系统命令的扩展存储过程等。

2 安全配置策略的实施

2.1 局域网中信任区域的设置

MIS数据库服务器是网络安全保护的关键区域, 因此, 必须将可访问的服务器群设置为一个信任区域, 同时将用户和客户端设置为一个内部网络区域。

内部网络是指MIS内部的局域网, 外部网络指的是其中的校园网。对基于局域网的MIS而言, 外部网络是绝对不可信任区域, 必须禁止所有从该区域到数据库服务器的连接和访问。通过配置路由器上的防火墙和包过滤, 禁止所有来自外部网络的连接。

防止服务器IP地址暴露在外部网中的方法利用网络地址转换 (NAT) 屏蔽服务器和其他内部网的IP地址, 使内部网相对于外部网来说变为不可见。在内部网络中则使用动态主机配置协议 (DHCP) 为各个终端分配IP地址, 同时为了在局域网中管理各个终端, 必须将各个终端的IP和网卡MAC进行绑定。

为了方便对数据库和服务器的管理, 需要打开操作系统和Oracle数据库的远程访问端口。但必须限制远程访问端口的可信任区域。为了减少这类端口被利用和被攻击的可能性, 可更改此类端口为数据库服务器上尚未被使用的其他端口或者隐藏数据库通信端口, 同时利用防火墙安全策略来禁止非可信任区域对服务器该端口的连接和保证可信任区域对该端口的安全连接。

2.2 权限分配策略和用户认证

MIS数据库用户主要有3个:一个是MIS中连接数据库的用户。该用户对一般使用者来说是不可见的, 它是MIS数据库的合法用户, 用来使应用服务器成功连接上数据库服务器。但它只对MIS数据库具有合法的访问权限, 即该用户只能访问MIS数据库, 而不具有其他数据库 (如用来保存记录追踪的数据库等) 的访问权限, 更没有数据库管理的权限。另一个则是数据库管理员用户。该用户除了拥有MIS数据库的访问权限之外, 也可以访问其他数据库和对数据库进行管理。第三个则是Oracle服务和代理服务的启动用户。这三种系统用户的权限对终端用户来说是不可见的, 这样设置能有效防止终端用户直接访问数据库。

除了对系统登录进行认证之外, 还对关键数据所在模块, 例如业务输入模块等, 实行区别于系统登录的二次认证, 以防止用户由于疏忽没有退出如管理界面, 被他人利用进行数据破坏的工作。其次在口令认证上, 通过在应用程序中自定义的加密函数对用户输入的口令在本地进行加密, 加密后的口令在网络上传输到服务器端, 在存储过程中通过相应的解密函数解密该口令, 这样口令以密钥的形式在网络上传输, 以加密后的形式存储在数据库中, 不仅减少了口令在网络传输时被捕获的可能性, 也大大降低口令被盗取的可能性。

2.3 记录追踪功能的设置

资金数据是MIS中最为敏感、最为重要和可能产生疑义最多的部分, 它要求能在疑义产生时判断该疑义记录的来龙去脉, 掌握该记录曾经存在的状态、时间以及变更原因等。这就需要对资金记录进行历史追踪, 通过在客户端程序和数据库触发器中设置控制程序追踪记录, 以解决对疑义数据的分析和用户操作的日志查询。

记录的内容一般包括:操作类型 (如修改、查询、删除) 、操作终端标识与操作者标识、数据库操作日期和时间以及操作所涉及到的相关数据 (如基本表、视图、记录、属性等) 。利用这些信息可以在疑义产生时迅速查找到和该疑义记录相关的所有操作记录, 有利于在短时间内分析解决问题。

2.4 复合操作系统和数据库的安全配置

Oracle 11g提供了TCP/IP协议进行通讯, 此时, 用户名和密码可能不经过加密就在网络上传输, 若不加密, 网络包嗅探器可以读取这个信息。在Oracle 11g中可以采用与超级网络套接字网络库集成在一起的SSL加密协议, SSL的加密层位于数据库引擎和网络库之间, 使用SSL加密时, 由加密层负责对客户与服务器之间传输的数据进行加密与解密, 且通信的管理负担很少。

3 数据库安全设置

3.1 启用审核功能

Oracle 11g审核方式主要有两种:标准审核和细粒度审核。在标准审核方式下, Oracle 11g管理一个内部审核日志, 该日志主要是查看语句审核、权限审核、对象审核和用户审核的情况。细粒度审核则是更严厉的基于值的审核标准, 在该标准中, 每个数据库操作都是可以审核的, 因此它是系统管理员允许查询及审核时使用得比较好的方法。

Oracle数据库的审核可以通过 Oracle Audit Vault软件进行自动化审计收集、监视和报告流程, 并将审计数据转变为关键的安全资源以检测未授权的活动。通过Oracle Audit Vault Reports界面, 管理员可以访问常用报表以及图表功能。

3.2 警报系统

Oracle性能监视器对Oracle 11g提供了包括锁、内存管理器、访问方法、SQL统计及复制日志读取器在内非常多的计数器。利用这个特性, 可创建数据库文件大小、登录、锁请求在内的计数器, 在这些计数器超过一定值时触发警报。

在管理信息系统中可利用ORACLE提供的警报来进行非法活动检测及性能检测。在警报发生的时候, 通过网络发送一个警报消息给系统管理员, 如果有必要的话, 可以在该警报的响应中执行一个作业, 通过该作业首先记录下这个非法登录企图, 然后再发出警报消息。利用这个特性, 可以在数据库发生超过一定严重度的错误时和非法登录企图时触发警报。

4 备份策略和灾难恢复

除了以上所做的安全策略之外, 另一个保证数据安全性和可用性的必要手段就是做好数据的备份工作, 以便在灾难发生时可以及时进行数据还原, 在最短的时间内恢复正常工作。

数据备份策略体系需要考虑信息系统的实际情况, 综合各方面因素制定备份策略。根据实际情况可以采取:1) 数据库维护计划, 利用Oracle的数据库维护计划自动对数据库分别进行完全和事务日志备份;2) 双机热备份。

基于上述备份策略, 一旦有灾难性的数据损失发生时, Oracle可以采用灵活的恢复方式, 将相关的备份数据进行系统还原。对于采用Flashback技术做UNDO处理的Oracle数据库, 可以随时将数据库恢复到UNDO影像预设的时间点上。对于需要进行数据库完全恢复的情况, 可以采用RMAN或IMP方式将最近的完全备份恢复到数据库中。

5 结束语

局域网的管理信息系统安全监控体系相对于其系统设计本身而言, 显得更为重要, 因为系统安全与否直接关系到系统的应用质量和持久性。本文的研究在于结合实际从信息系统权限分配策略和用户认证、设置记录追踪功能、使用SSL协议作为数据库连接的通讯协议、启用细粒度审核、设置警报系统以及数据备份和恢复等方面设计了针对MIS的完整有效的安全监控体系。

实施本文设计的安全体系之后, 系统管理员能够实时对管理信息系统的运行动态进行监视、记录安全事件、发现安全隐患。可极大地增强MIS系统的安全防范能力, 也提高了MIS系统的管理水平。

参考文献

[1]PAPADOPOULOS Y.MCDERMID J.Automated safety moni-toring:A review and classification of methods[J].International Journal of Condition Monitoring and Diagnostic Engineering Man-agement, 2001, (4) :1-32.

[2]LUCAP.ENRICO Z.JOHN V.Risk-informed optimization of rail way tracks inspection and maintenance procedures[J].Relia-bility Engineering and SystemSafety, 2006, (91) :20-35.

[3]Frank J.Artificial Intelligence and Intrusion Detection:Current and Future Directions。In Proceedings of the17th National Com-puter Security Conference (Baltimore, MD) , 1994-10:11-14.

[4]SCAMBRAY J, McClure S.Windows Server2003黑客大曝光[M].北京:清华大学出版社, 2004.

[5]Lunt T.A Real time Intrusion Detection Expert System (IDES) Technical Report, Computer Science Laboratory, SRI Internation-al, 1990-05.

[6]ANDREWS C, LITCHFIELD D.ORACLE11g安全性[M].北京:清华大学出版社, 2004.

图书管理系统的数据库设计 第10篇

目前, 国内大部分大型的公共图书馆和高校图书馆都实现了网络管理, 中小型图书馆 (包括企业图书馆) , 也在朝着这个方向发展。在本文中, 我们虚拟为某公司建立的图书馆管理系统进行数据库设计, 目的在于使该系统的运行能提高该公司的资料管理水平和现代化管理水平。本系统是一个中小型管理系统, 运行环境是Windows2003 server, 因此使用Windows环境下最容易使用且功能又比较强大的Microsoft SQL Server 2000 作为后台的数据库系统。

1 需求分析

需求分析是数据库设计的重要工作, 通过需求分析, 对整个系统的主要需求描述如图1所示:

2 数据库设计

在图书管理系统中, 数据库设计占重要位置, 数据库设计质量的优劣, 可直接影响到数据库数据的冗余度、数据的一致性、数据丢失等问题。下面就系统数据库规范化设计进行说明。

2.1 数据库设计的理论指导

数据库设计的理论指导是范式理论, 其主要内容如下:①如果关系模式R, 其所有的域为单纯域则称R是规范化的关系, 或称第一范式 (1NF) ;②如果关系模式R为第一范式, 且每个非主属性完全函数依赖于码, 则模式R为第二范式 (2NF) ;③如果关系模式R为第二范式, 且每个非主属性非传递依赖于码, 则称关系模式R为第三范式 (3NF) ;④关系模式R为第一范式, 满足函数依赖集合F, X和A均为R的属性集合, 且X不包含A, 如果R满足X->A且X必包含R的码, 称关系模式R为BCNF范式。

2.2 数据库设计

图书管理系统数据库常常要设计含有如下数据项:借书证号、姓名、单位、馆藏号 (馆藏号为每本书上的条形码号) 、书名、分类号、作者、价格等。如何进行模式的设计呢?下面以图书流通模块所涉及的数据库为例来说明。

先设计图书流通的实体-关系图 (E-R图) 。E-R图由3个相关联的部分构成, 即实体、实体与实体之间的关系以及实体和关系的属性。图书流通过程中实体“图书”与“读者”之间的关系是借阅和被借阅的关系, 实体“读者”与“单位”之间的关系是属于和被属于的关系, “图书”的属性有“馆藏号”、“书名”、“分类号”、“作者”、“价格”, “读者”的属性有“借书证号”、“姓名”、“性别”, “单位”的属性有“单位编号”和“单位名称”, “借阅”属性“借书日期”, 由此得出E-R图如图2所示:

从图中可以知道:①“借书证号”是唯一的, 所以“借书证号”决定“姓名”, 每位读者应只属于一个性别, 所以“借书证号”也决定“性别”;②“馆藏号”是唯一的, 所以“馆藏号”决定“书名”、“分类号”、“作者”、“价格”;③“单位编号”是唯一的, 所以“单位编号”决定“单位名称”;④每位读者在一个时间只能借一本书, 所以“借书证号” +“馆藏号”决定“借阅时间”。

如果将这些数据项置于一个关系模式中, 根据范式理论, 该关系模式属于1NF (第一范式) , 它存在删除异常和冗余等问题, 不是理想的模式, 因此要把它分解成满足3NF或BCNF的关系模式。根据范式理论和E-R图转换成关系模型的规则, 上面的E-R图可转换为4个关系模式:①图书 (馆藏号、书名、分类号、作者、价格) ;②读者 (借书证号、姓名、性别、单位编号) ;③借阅 (借书证号、馆藏号、借阅时间) , ④单位 (单位编码、单位名称) , 其中打下划线的为码, 这样就解决了插入、删除和数据冗余等问题。

我们对数据的结构进行详细的分析, 按照上述的设计思想, 共设计了读者表, 书目表, 馆藏表, 流通表等百余张数据表, 然后创建视图和存储过程。下面举例说明:①读者表:借书证号、姓名、单位、读者类别、职称等字段;②书目表:馆藏号、ISBN、题名、作者、出版社、复本数、语种、文献类型、版次等字段;③馆藏表:馆藏号、索书号、分类号、种次号、馆藏位置、单价、出版日期等字段;④流通表:借书证号、馆藏号、借期、还期、续借、应还期、操作员等字段;⑤借阅规则表:读者类别编码、图书类别编码、限借册数、每期天数、续借天数、过期日期、罚金等字段;⑥读者类别表:读者类别编码、读者类别等字段;⑦图书类别表:图书类别编码、图书类别等字段。

3 数据库索引

建立索引是加快查询速度的有效手段, 数据库的每一个表建立了主键, 主键由一个或几个字段组成, 每一个表都按主键建立了索引, 部分表为了满足查询和排序的需要, 除建立主索引外, 还建立了次索引。例如在查询时要用到“馆藏号”、“作者”、“题名”等条件来查找图书, 因此, 在书目表上除了对主键“馆藏号”建立了主索引外, 也对“作者”、“书名”等建立了次索引。

4 视图

视图是从一个或几个基本表导出的表, 它是定义在基本表之上的, 它是一个虚表, 数据库中只存放视图的定义, 而不存放视图对应的数据, 数据仍然存放在原来的基本表中。通过定义视图, 可以使用户眼中的数据库结构简单、清晰, 并可以简化用户的数据查询操作。由于本系统数据表较多, 表中的字段多, 为了简化对表的操作, 我们创建了图书_按书名查询、期刊_按刊名查询、期刊_按编辑部查询、借阅规则查询、待还书查询、超期记录查询等30余个视图。

5 存储过程

存储过程是一段经过编译的程序代码, 存放在数据库服务器端。通过调用适当的存储过程, 可在服务器端处理大量数据, 再将处理结果送到客户端。这样可减少数据在网络上的传送, 消除网络阻塞现象;例如:要查询某条记录, 若该记录在表中的顺序号是10000, 不采用存储过程, 服务器将从1至于10000条记录数据逐条送至客户端, 采用存储过程后, 由于过程是经过编译的并且是在本地, 不需要通过网络, 因此能很快查出所需记录并将结果送到客户端, 大大减少了网上数据传输量。存储过程另一好处是可供不同的开发工具调用, 如PB、VB、ASP、Delphi等开发工具均可调用。在流通模块和WEB查询模块上均有图书检索功能, 实际上调用同一存储过程完成的。本系统建立了60多个存储过程, 实现诸如借还书处理、新书入库统计、编目入馆藏、读者统计、生成索书号等功能。

6 数据库调用

Client/Server采用ODBC接口实现数据库的调用, Browser/Server采用ADO接口调用。

摘要：虚拟为某公司建立的图书馆管理系统进行数据库设计, 目的在于使该系统的运行能提高该公司的资料管理水平和现代化管理水平。本系统是一个中小型管理系统, 运行环境是Windows2003server, 因此使用Windows环境下最容易使用且功能又比较强大的Microsoft SQL Server 2000作为后台的数据库系统。

关键词：图书管理系统,数据库,设计

参考文献

[1]宫昌利.图书管理系统的设计与实现[D].山东大学, 2009.

[2]顾俐.图书馆图书管理系统的设计[J].中国科技信息, 2007 (11) .

[3]赵晨.图书管理系统[D].吉林大学, 2009.

[4]陈杰志.图书管理系统[D].华南理工大学, 2011.

[5]黄剑樱.高校图书管理系统的设计与实现[D].电子科技大学, 2007.

[6]栾丁.图书管理系统设计与实现[D].吉林大学, 2010.

[7]花昀峤.基于面向对象技术的图书管理系统研究[D].吉林大学, 2010.

数据库系统设计 第11篇

关键技术，包括构建全文索引、构建数据库模式图、查询语言及查询结果生成等等。通过分析相关检索系统的实现策略，给出了面向关系数据库的关键字查询的形式化描述，设计了支持关键字检索的系统架构和核心构成组件，主要包括数据库索引、关键字检索和结果生成。

关键词：关系数据库  关键词查询  数据库索引

1 系统总体设计

人们在求解一个复杂问题时，通常采用的是逐步分解、分而治之的方法。也就是把一个大问题分解成若干个比较容易求解的小问题，然后分别求解。设计一个复杂的系统时，往往也是把整个系统划分为若干个功能较为单一的功能模块，然后分别予以设计、实现，这就是模块化设计。本系统也采用这种模块化设计方式。

■

图1  面向关系数据库关键字查询系统框图

2 数据库设计

本系统为面向关系数据库的关键字查询系统，在实验中本文选取了IMDB 数据集，为了进行实验，将数据集整理为以下七个表数据结构。

实验数据集（电影信息数据库）：

create table Actor（     //演员表

actorname varchar（50） Primary Key ;   //演员姓名key

sex varchar（2）;     //性别

mvname varchar（50）;    //出演电影或电视剧名

mvyear varchar（10）;    //电影上映时间

mvactorname varchar（10）;   //电影中人物姓名

position varchar（20）;    //电影中人物排名

made varchar（10）;   //TV 或是Video

setname varchar（50）;     //出演电视剧集名

episode varchar（10）;   //出演电视剧集

date varchar（10）;     //电视剧播出日期

classification varchar（30）;  //（achieve football）

）

creat table Consume（    //设计师

consumename varchar（20） Primary Key;     //设计师姓名key

mvname varchar（20）;     //电影名或电视剧名

mvyear varchar（10）;     //上映日期

setname varchar（20）;    //电视剧集名

episode varchar（10）;   //电视剧集

productiondate varchar（10）;  //电视剧播放日期

classification varchar（30）;     //（as M...）

made varchar（10）;    ///（V/TV/uncredited）

）

creat table Director（   //导演信息

directorname varchar（20） Primary Key;   //导演姓名key

mvname varchar（20）;      //电影或电视剧名

mvyear varchar（10）;       //上映日期

setname varchar（20）;    //电视剧集名

episode varchar（20）;    //电视剧集

made varchar（10）;    //（V/TV/VG）

explantaion varchar（30）;      //（as M...）

）

creat table Business（     //投资

mvname varchar（20） Primary Key;      //电影名key

productiondate varchar（20）;  //拍摄日期

company varchar（50）;      //出品公司

studiodate varchar（50）;     //上映日期

masterpiece varchar（1000）;///OW

budget varchar（20）;      //预算

ad varchar（50）;     ///AD

general_revenue varchar（20）;   //收入

wg varchar（50）;  //WG

）

creat table Editor（    //编辑

editorname varchar（20）  Primary Key;     //编辑名

mvname varchar（20）;       //电影或电视剧名key

mvyear varchar（10）;      //上映日期

made varchar（10）;   //（V/TV/video）

setname varchar（20）;   //电视剧集名key

episode varchar（20）;   //电视剧集key

explantaion varchar（30）;   //（as M...）

）

creat table Color {  //颜色信息

mvname varchar（20）;    //电影或电视剧名key

mvyear varchar（10）;     //上映日期

setname varchar（20）;   //电视剧集名key

episode varchar（20）;  //电视剧集key

color varchar（20）;   //颜色分类color或black and white

explantaion varchar（10）; //颜色分类之后的（）中有（HD）等，（HD）是高清

Primary Key（mvname，setname，episode）;

}

creat table Keyword（     //关键词

mvname varchar（20）;    //电影或电视剧名key

mvyear varchar（10）;    //上映日期

setname varchar（20）;    //电视剧集名key

episode varchar（10）;    //电视剧集key

keyword varchar（50）;    //关键词

Primary Key（mvname，setname，episode）;

）

3 数据库索引设计

由于关系型数据库对于文本属性上全文索引的支持，所以在文本属性可以直接利用数据库中的全文索引。对于给定的关键字k，全文索引能检索出查询关键字所在位置。

对于数据库中的表属性，构建索引的方式比较简单，依赖于DBMS的IR索引。对于数据库中具有文本属性的列，在该列上建立全文索引。在进行关键字查询时，对于给定的关键字，通过数据库的全文索引，会返回包含该关键字的元组集合。

在进行关键字查询的时候，对于用户给定查询关键字，系统首先要对给定的关键字进行定位，确定关键字所匹配的信息是模式项还是数值项。

例如，关键字{“Color”“Director”}的索引结构如表1所示。

表1  关键字{“Color”“Director”}的索引结构

■

4 关键字检索设计

在搜索引擎行业，所谓关键字，就是用户在使用搜索引擎时输入的、能够最大程度概括用户所要查找的信息内容的字或者词，是信息的概括化和集中化。关键字检索作为一种易于使用的检索方式，为大量普通用户所喜爱。本文从关键字个数角度介绍现有的关键字检索技术中最常见的单关键字查询和多关键字查询这两种关键字检索形式。

5 结果生成设计

在本文中，将查询结果定义为元组连接树。

元组连接树（Joined Tuple Tree）是给定一个数据库模式图GS，一个元组连接树T是一棵元组树。其中，T中的每一条边（ti，tj）（ti∈Ri，tj∈Rj）满足以下两个要求：

①（Ri，Rj）∈RS，

②ti∞tj∈Ri∞Rj。

同时这些元组连接树满足以下条件：

①完整性：用户提交的所有关键字均出现在元组连接树上;

②最小性：从元组连接树中移除任何元组后的元组连接树都不具有完整性。

6 结束语

通过分析相关检索系统的实现策略，设计了支持关键字检索的系统架构和核心构成组件，主要包括数据库索引、数据库模式图、关键字检索和结果生成。

参考文献：

[1]吴清怡，马良荔，孙煜飞.基于数据关系表的XML查询算法[J].辽宁工程技术大学学报（自然科学版），2013（01）.

[2]林子雨，杨冬青，王腾蛟，张东站.基于关系数据库的关键词查询[J].软件学报，2010（10）.

在线数据库系统的设计与实现 第12篇

一、系统架构和功能设计

在线数据库系统设计的关键在于支持大部分常用的关系数据库软件, 对用户输入的数据库操作信息进行检查和过滤, 然后把服务端数据库操作结果用友好的界面展示给用户。

系统的整体架构如图1所示, 其中最上层为Web接口, 提供用户访问的Web接口和友好的界面。中间层中的数据安全、权限验证这些基本模块验证用户请求的权限, 并完成数据操作安全的处理, 然后调用下一层的相关功能响应用户请求;用户管理是对用

户基本信息的增删改查, 数据库管理完成对系统中数据库信息的管理, 该层通过调用数据库访问层完成数据库的基本操作, 然后将其结果返回给上层。系统中可同时部署多种不同的数据库软件, 数据库访问层提供了对不同数据库的统一访问接口。

系统用户分为普通用户和管理员两类, 系统为用户提供的主要功能如图2所示。

1. 用户功能:普通用户注册、登录、注销, 查看个人的权限、操作历史等信息, 并可以修改密码和个人资料。

2.数据库功能:普通用户从系统提供的多种数据库软件中进行选择, 提交自己需要完成的数据库操作命令并查看运行结果。

3. 管理员功能:管理员对普通用户的信息进行增删改查, 并管理数据库软件的加入和退出, 配置数据库软件的基本信息, 管理数据库软件的加入和退出。

整个系统以Web服务的形式在服务器中进行部署, 然后由系统维护人员在服务器上安装数据库软件以提供服务端的数据库服务。系统管理员登录系统进行数据库的基本配置, 最后用户使用浏览器访问系统, 即可完成对数据库表、视图、存储过程等内容的操作。

二、系统详细设计与实现

系统基于B/S架构, 以跨平台性强的Java语言作为开发语言, 充分利用了Java技术在Web开发中的优点, 采用了流行的Spring3和Struts2作为Web框架, 可迅速完成其开发、部署和测试。系统分为前端和后端两部分, 按照MVC设计思想, 系统的整体架构可更详细地划分为页面显示层、应用层、服务层、模型层、数据持久化层、数据库连接层这六层。下面结合图3对各个层的设计进行详细介绍。

页面显示层:基于JSP, 采用包括CSS层叠样式表和Java Script在内的多种动态网页制作技术实现的Web页面。页面显示层将用户请求通过HTTP协议传递给服务器端的应用层, 并将服务端返回的结果在浏览器中显示出来, 页面显示层完成与用户的全部交互。

应用层:对应于图3中的Action包 (“包”是Java中功能相似或相关的类和接口的集合) , 其中基类Base Action类封装了获取web页面请求参数、过滤非法数据以及验证用户权限的基本方法, 对于来自Web页面的HTTP请求, 首先获取其中的请求参数中所包含的用户信息及数据库操作信息, 然后对用户权限进行校验, 对数据库操作信息进行检查, 防止SQL注入攻击。Authentication Action类提供用户注册、登录、退出等功能方法, User Action类提供用户增删改查管理的功能方法, Data Base Action类提供数据库信息管理的功能方法。应用层的类调用服务层的类实现系统功能, 为页面显示层服务, 是整个系统服务端的应用功能的总接口。

服务层:对应于与图3中的Service包, 其中包含数据库服务和用户服务两部分, 应用层通过接口I-Database Service和IUser Service来调用服务。接口类的加入, 使上层调用服务层功能方法的类与服务层具体的实现类隔离开来。Userservice类通过调用下层的IUser Dao接口完成用户信息管理, Database Service类通过调用下层的IDatabase Dao和IDb Connect实现数据库信息的管理, 以及数据库的访问操作。

数据持久化层:对应于图3的DAO包, 包含Database Dao和User Dao两部分, 将系统中的用户信息以及数据库信息持久化到系统数据库中, 在访问数据库时需要调用Db Operation包中的接口。

数据库连接层:对应于图3的Db Operation包, 由于系统中可以部署多种不同的数据库软件, 需要有相应的类完成与其的连接, 这些类均继承IDb Connect接口以保持一致。数据库连接类基于JDBC技术, 实现了与多种关系数据库的连接、验证和SQL服务调用, 并将其中的基本方法进行了封装和扩展, 使其更加灵活易用。

模型层:对应于图3的Model包, 其中的类均是对一些基本属性的封装, Database类封装数据库软件名称、数据库名称、SQL语句等信息, User类封装普通用户的用户名、密码、权限等信息, Admin封装了管理员的用户名、密码等信息。应用层、服务层和数据持久层都对模型层有依赖关系。

此外, 系统对于在应用层和服务层中出现的异常也进行了封装, 对所有的异常进行统一管理 (见图3的Exception包) 。系统的分层设计, 使程序的各模块之间高内聚、低耦合的特性增强, 符合软件工程的基本思想, 使系统的架构趋于稳定, 更能适应需求的变化。

三、系统运行与测试

1. 运行环境。

系统的运行环境如表1所示, 其中服务器端的配置为系统目前部署测试时所采用的配置。

2. 功能测试。

按照软件测试的基本步骤, 采用黑盒测试的错误推测法和错误推测法对系统的各个功能模块进行测试, 以测试用户登录模块为例, 预期当在界面中输入用户名或密码错误时, 页面提示“用户名或密码错误, 请重新输入”, 并不进行页面跳转, 正确时跳转到系统主页面, 经测试实际输出结果与预期一致。

3. 性能测试。

对系统的性能测试采用负载测试和压力测试相结合的方法展开, 选取每分钟增加若干用户请求和混合加压作为测试数据。测试的结果表明系统可支持2500用户并且响应时间小于3秒, 压力测试结果显示CPU和内存占用率在86%和88%以内。

四、总结与展望

本文所设计和实现的在线数据库系统, 立足于简化在数据库基础知识教学过程中数据库环境搭建的烦琐步骤, 为教师和初学者提供简单方便在线的关系数据库服务。系统架构合理, 运行状况稳定, 简单易操作, 从目前的反馈结果来看, 系统在一定程度上提高了课堂教学质量, 可以推广使用。但是, 系统在用户数据库操作结果的页面显示效果还需要优化, 用户权限控制等方面仍存在不足, 同时教师在实践过程中发现了数据库在线测试试题、学生与教师互动等新的需求, 这将是系统下一步改进与完善的方向。

摘要：为了提高数据库基础知识教学的质量, 教师常常在课堂教学中演示数据库操作, 但是数据库环境的部署往往费时费力。在线数据库系统基于B/S模式, 可集成多种数据库环境, 仅用浏览器即可完成基本数据库操作, 为初学者提供了方便, 提高了数据库教学的效率。