关系型数据库范文

导语：如何才能写好一篇关系型数据库，这就需要搜集整理更多的资料和文献，欢迎阅读由公务员之家整理的十篇范文，供你借鉴。

篇1

因特网发展提出的新挑战

自20世纪80年代以来，开发人员在开发企业级应用的时候，关系型数据库已经成为主流的选择，因为这种最初由E. F.Codd博士提出、并由IBM公司作为一种通用数据库而广泛推行的数据库技术已经相当成熟。关系型数据库可以提供高扩展性的高性能事务处理和多平台支持，同时还提供一个数据建模框架，其中很多框架都包括应用开发的脚本语言。

然而，20世纪90年代的因特网革命，使开发人员们已经开始接受新的数据模型和程序范本。一些封装在面向对象的程序理论，如数据与代码结合、信息与方法相结合等，已成为全新的开发路线，打破了传统的关系型数据库的工作模式。同时，因特网革命产生了更复杂的数据需求。数字数据通过因特网提供的大量数字信息在全球得以轻松传播，并因此产生了大量的数据文件或二进制大对象 (BLOBs)――这些都远不是传统的关系型数据模型所能解决的。

面向对象的数据库技术

面向对象是一种远比传统的关系模型强大得多的逻辑结构。一些面向对象的概念，如“对象继承”等，更强调用一种真实可行的角度来看待并处理现实世界的信息。其它概念，如“封装”和“多态”等，则提供了更强大的机制来管理对象，大大提高了可重用性和标准化等编程效率。面向对象还可以很经济地将代码、数据和BLOBs联系在一起，同时为基于因特网的快速应用开发（RAD）提供理想的基础。

绝大多数开发人员已经意识到面向对象理论的实用性和重要性，并已开始采用面向对象的程序语言。然而，面向对象的理论，在很大程度上仍然受制于传统的关系型数据库技术。以网络为中心的数据库必须拥有更强大的性能和伸缩性，这些都是存储信息型的关系型数据库永远不可能做到的。

面向对象的理论与关系型数据库技术的应用开发，产生了“抗阻不匹配”现象，即开发人员的逻辑（对象）结构与物理的二维（关系的）表不相匹配，而所谓的“对象关系映射”在许多应用开发项目中会消耗掉40％的成本。抗阻不匹配的现象，大大增加了开发和平台的成本，并降低了性能和伸缩性。应用越大，面向对象的关系型建模就越复杂，问题就会越严重。

面向对象的后关系型数据库

多年来令开发人员工作轻松的关系模型数据库正令他们越来越头疼。引导潮流的先驱们正不断地去寻求新的数据库管理系统的替代品。

面向对象的后关系型数据库管理系统也许是一个不错的选择。它所采用的灵活的物理结构，可以同时根据关系和面向对象来存储数据。开发人员可以在单一的数据库管理系统中选择最适合应用的开发范本、存储代码和BLOBs。表与对象在数据库层之间能够相互转换，可以作为一种不同系统与不同应用之间数据共享的通用机制来支持SQL。后关系型数据库会带来更低的软件和平台成本、更好的运行性能与伸缩性，并且降低用户跨应用、环境和平台的数据库管理成本。

篇2

关键词：非关系型数据库；无模式；聚合结构；实验教学；云计算

中图分类号：TP399 文献标识码：A 文章编号：1009-3044（2013）31-7046-03

云计算是现阶段计算机技术和网络技术发展的必然结果，是当今信息领域的重大变革，是解决信息时代大用户、大数据和大系统挑战的切实可行的方案[1]。当今世界发达国家或地区如美国、欧洲、日本等都是政府牵头推动云计算的发展，而中国政府的“十二五”规划中将云计算作为重点发展项目[2]，并鼓励企业推广开发应用，目前已获得了最大的经济效益和社会影响力。因此云计算是新一代信息技术的主流，在云计算的基础上可衍生出云制造、云服务及云媒体等技术。现代企业的市场竞争日趋激烈，所面对的用户数量和业务数据量与日激增，其业务系统日并发访问管理、海量数据的存储、复杂的系统架构等问题给企业带来了最大的管理压力，其开发成本也激烈上升，而物联网、移动互联网快速发展增加了这一趋势。在诸多问题中，海量数据库的设计、存储和访问显得尤为突出。而传统的关系型数据库在处理集群环境下的海量数据时已没有非关系型数据库那样优势明显和灵活，实际上使用非关系型数据库能构建性能更高、扩展性更好及更易编程的web系统。

因此在大数据时代下，数据库课程教学必须引入非关系型数据库的教学内容，其教学课时比重应与关系型数据库相当（48课时），这是当今用户业务系统的迫切需求和云计算技术发展对此类信息化人才大量需求的必然结果，也是目前高校实施信息化卓越工程师的重点解决方案[3]。

1 大数据时代非关系型数据库课程理论教学设计

以解决集群环境下的海量数据库的设计、存储和查询为目的的非关系型数据库在教学时可以参照关系型数据库的课程体系和教学方法[4]。以关系型数据库教学的主要内容包括关系理论、关系代数、规范化设计、SQL应用、储存过程、函数、触发器、事务与并发性、安全性及高级语言的开发等。与关系型数据库相比，非关系型数据库没有复杂的关系特性和严格的范式设计，更具灵活性，两者的比较如表1所示。

从表1可以得出，在大数据时代主要解决了数据库的并发负载问题、海量数据存储问题、高可扩展性与高可用性问题、读写实时性问题以及开发与维护成本问题。

由非关系型数据库的特点，设计的理论教学内容如下：

1）非关系型数据库的基本概念 主要包括该数据库的组成、分类、特征及作用、逻辑结构、集合、文档、键值对、聚合；课内教学大约占4课时。

2）非关系型数据库建模 与关系型数据库的ER模型不同，非关系型数据库集合之间主要采用聚合结构，因为聚合使得在集群中管理数据存储更为方便，当然设计的聚合模型会因人而异，图1是某CRM系统销售模块的数据库ER模型，而图2是其对应的非关系型数据库的聚合模型。这部分内容是重点，课内教学大约占8课时。

5）非关系型数据库的管理 主要包括用户的创建、授权机制；索引创建与维护；数据备份与恢复；事务及并发性等，这里的事务主要指一致性，海量存储中是靠很多节点来执行数据操作的，具有较好的事务一致性，要做的仅仅是在网络延迟与一致性之间取得平衡[5]。课内教学大约占4课时。

6）非关系型数据库系统网络架构 主要包括集群环境下复制集、分片技术的原理及由复制集加分片技术共同构建项目开发环境，可实现数据海量存储和高可用性需求，课内教学大约占4课时。

7）非关系型数据库的实例开发 主要内容包括使用Java或C#语言实现一个非关系型数据库小型系统的设计与实现，与开发关系型数据库使用JDBC或组件不同，非关系型数据库的开发使用专门的API接口，该接口简单易学易用。课内教学大约占6课时。

因此该课程的课内理论总课时为38，不足的部分学生可利用课外时间补充与完善所学知识点。

2 大数据时代非关系型数据库课程实验项目设计

该课程的实验设计依据是按照大数据时代下的信息系统的开发应用为前提。学生要能单独设计无模式的数据模型，进行文档对象的CRUD操作，掌握集群环境下的复制与分片技术，并能通过某种高级语言开发非关系型数据库。设计实验5个，每个实验2学时，共10学时。如表2所示。

3 结束语

高校作为先进信息技术研究、教学的最前端，应适应当今信息技术的快速发展，与时俱进。与其对应的课程应做出相应的改革和调整。关系型数据库作为传统的数据库课程一直占据信息化系列课程的主导地位，数十年没有动摇。但随着大数据时代的来临，非关系型数据库来势迅猛，大有取代前者的趋势，但关系型数据库在实时联机事务处理、数据仓库与数据挖掘、完整性约束等方面具有无可替代的优势，因此这两种数据库还将在一定时间内长期存在，现行系统的数据存储仍是混合式存储模式结构，因此早日引入非关系型数据库课程的教学有利于保持高校课程体系的先进性，有利于新技术人才的培养，有利于国家推动云计算的进展。

参考文献：

[1] 姚宏宇，田舒宁.云计算大数据时代的系统工程[M].北京：电子工业出版社，2013.

[2] 许守东.云计算技术应用与实践[M].北京：中国铁道出版社，2012.

[3] 刘鹏.云计算（第二版）[M].北京：电子工业出版社，2013.

篇3

【关键词】 VB6.0 C# SQL SERVER T-SQL 类

【中图分类号】G42 【文献标识码】A 【文章编号】2095-3089（2013）05-0243-03

前言

中央广播电视大学的数据库应用技术教材是基于VB6.0和SQL SERVER2000实验环境下的，这为我们的数据库应用技术教学实践带来一些困扰和不便，尤其不便于学生课后更准确有效地自学教材。对此问题，笔者借助多年教学经验的积累，将中央电大本门课程的形考任务“数据库应用系统开发”在VB6.0、和C#多种环境下的实现进行了思考和实验，对不同环境下的数据库应用系统设计实现方法和关键技术进行了比较，能够有效地指导学生在不同应用程序开发环境下，以简捷的方式、方法，较快地设计、实现一个具备增、删、改、查询功能的小型数据库应用系统，同时满足了学生接受新事物、新技术的愿望，激发了他们搞好毕业设计的创作热情，为学生们后续毕业设计打下了坚实的基础。

实现

本系统是基于 C/S 结构的信息管理系统，分别使用 VB6.0、和C#作为开发语言，前端应用程序通过ADO、技术来与数据库进行连接，优点是易于使用、高速度、低内存支出和占用磁盘空间较少。

该数据库应用系统虽然规模小，但是已经具备增加、修改、删除、查询等系统功能。下面介绍一下系统开发的主要方法：

一、进行数据库设计

（一）需求分析

1.业务流程分析

“学生成绩管理系统”，主要目的是用以实现学生、课程以及成绩等多项管理。本系统管理的对象简单，每个数据之间都有较强的关联性，涉及过程并不复杂。因此，比较适合于数据库管理。

2.数据流程分析

图1学生成绩管理数据流程图

（二）概念结构设计

根据需求分析的结果，进行概念结构设计，依照收集信息标识对象（实体）标识每个对象需要存储的详细信息（属性）标识对象之间的关系的步骤，采用E-R图工具表示，设计结果如图2所示：

图2学生成绩管理E-R图

（三）逻辑结构设计和物理实现

逻辑结构设计的方法与步骤，是将概念结构设计的结果E-R图转换为某个DBMS所支持的数据模型，并对其进行优化的过程。具体过程为：

将各实体转化为对应的表，将各属性转化为各表对应的列；标识每个表的主键列；在表之间体现实体之间的映射关系，遵守参照完整性规则；根据范式理论，对表进行修改，尽量满足第三范式。

通过规范化数据库设计，可以减少存储的冗余数据量，减轻数据维护工作，减少存储的要求，提高数据库的完整性。

物理实现阶段的主要工作是，把设计好的数据库全局模式转换为相应的内模式。在此用以上方法建立一个名称为“学生成绩管理”的数据库，其中包含3张数据表，即学生情况表、课程情况表、学生成绩表。

二、操纵和访问数据库的基本SQL语句

SQL是关系数据库支持的标准查询语言，也是一种双重式语言，即用于查询和更新的交互式数据库语言（Interactive SQL），又是一种应用程序进行数据库访问时所采取的编程式数据库语言，即嵌入式SQL（Embedded SQL）[1]。嵌入式SQL是数据库应用程序的一种开发方法。它要将SQL语句直接嵌入到程序的源代码中，与其他程序设计语言语句混合使用。

开发的应用程序将针对上述数据库进行管理，主要有插入（insert）、修改（update）、删除（delete）、查询（select）和打印（print）等5种基本的操作。

三、界面设计

（一）创建项目工程

项目工程名称为“学生成绩管理”。

（二）创建主窗体

运用菜单技术创建主窗体。

（三）创建增加、删除、修改、查询功能窗体

使用标签、文本框、组合框、表格、命令按钮等控件，添加并创建“查询记录”、“增加新记录”、“修改记录”、“删除记录”等窗体。

四、代码设计

.NET框架的一个主要组成部分是类库，这些类被拆分为命名空间，它是类库的逻辑分区。类库所采用的命名空间是层次结构，即命名空间下又可以再分成子命名空间，每个命名空间都包含一组按照功能划分的相关的类。

在.NET环境下，必须指向包含所使用类的命名空间（例如Imports System.Data，Imports System.Data.SqlClient）才能激活相应的类；借助于封装，把常用的数据连接、数据库查询和对数据库操纵的功能模块定义为公共函数，包括createConn（）用于建立数据库连接的函数，sqlUpdate（）用于对数据库操纵的函数，sqlfind（）用于数据库查询的函数；使用时调用即可，避免相同功能模块的重复建设。针对该系统，笔者创建了SqlConnection、SqlCommand公共类的实例和系统常用的公共函数。

在不同模块的设计中都可以调用这些自定义函数，在此不再赘述。

五、报表设计

一个功能完整的数据库应用系统，除了具有数据维护、查询和显示功能外，还必须具有报表输出功能。Visual Studio2005报表体系结构图]，其ReportViewer控件负责解释RDLC报表定义、处理报表参数并按照各种用户可选格式提供报表的“报表处理器”。它既可以运行于“本地模式”也可以运行于“远程模式”[2]。由用户编写的存储过程负责管理连接或运行基于参数的查询；报表只驻留以报表为中心的Parameters集合，寻址远程报表服务并呈现给用户。

六、几种实现方法的比较

嵌入式SQL在VB6.0下和在下使用的基本形式和处理过程对比如下：

（一）在VB6.0环境下的具体实现

ADO是微软公司提出的第三种数据库访问对象，它把OLE DB封装在一个数据对象中，使得VB6.0程序可以方便地实现对数据库的访问。ADO对象模型共包含7个对象，即Connection，command，Recordset，Parameter，Property，Field和Error。

VB6.0应用程序中主要用Connection对象建立与数据库的连接，用Recordset和Field对象，对数据表进行操作，实现数据表增加、删除、修改等不返回结果集的操作，语法参阅文献[1]。

（二）在环境下的具体实现

是微软.NET Framework框架中针对与数据库进行交互的一组对象类的名称[3]。提供对Microsoft SQL Server、Oracle等数据源以及通过 OLEDB和XML公开的数据源的一致访问，也就是提供与数据源进行交互的相关的公共方法。应用程序可以使用来连接到这些数据源，并检索、操作和更新数据。

比ADO更适用于分布式应用环境，增加了更好的性能；它有更好的可操作性、它可以结合XML语言来开发数据库；它有更好的可维护性、可编程性和可伸缩性。

对象模型中包含五个主要的组件，即是Connection对象、Command对象、 Dataadapter对象、Datareader对象以及Dataset对象。架构图参见[3]。

其中Connection对象、Command对象、 DataAdapter对象和DataReader对象四个组件是负责建立联机与数据操作部分的，被称为数据提供组件 （Managed Providers）。而Dataset对象是非连接架构下把数据库中的数据映射到内存缓存中所构成的数据容器，是一个或多个DataTable 对象的集合。DataSet在使用时就像驻留在客户端计算机上的一个小型关系数据库，但又与任何具体的数据库完全无关。DataAdapter对象在后台数据库和前台Dataset对象之间起着桥梁作用。其Fill方法将后台数据库的数据取到前台客户端的Dataset对象中来。而其Update方法则按相反方向把前台对数据库的写操作写入数据库中去，它由应用程序在Dataset中添加、更改或删除的行对数据库进行更新，在使用DataAdapter时，需要将查出的数据起一个表名放到DataSet中。一个Dataset可以存放多个表，而TableAdapter的结果就是一个表，不能再继续添加表。

DataReader实现数据操作以及对数据的快速、只进、只读访问。Connection对象提供与数据源的连接。Command对象能够访问用于返回数据、修改数据、运行存储过程、发送或检索参数信息的数据库命令。DataReader从数据源中提供高性能的数据流。它需要与数据库保持连接，ExecuteReader（）函数返回一个SqlDataReader对象或OleDbDataReader对象，通过这个对象来检查查询结果，它是一种“单向”流，一次只能提供一行数据，就像高速传送带上的一排箱子，一旦它们被放在带子上，就无法对它们排序或过滤出选定的箱子，也因此占用内存少，执行效率高。当用户读取大量数据时，可以使用DataReader来提高性能。

根据应用程序所需功能和性能的要求，来确定是使用DataSet还是DataReader。

嵌入式SQL在环境下通过SqlCommand.ExecuteNonQuery（）方法，对连接执行SQL语句，并返回受影响的行数，当行数大于0时，命令执行成功，否则说明对数据库没产生影响。通过使用SqlCommand.ExecuteScalar（）方法来执行命令对象的SQL语句，从数据库中检索单个值，当值大于0时，命令执行成功，否则命令执行失败。该方法不接受任何参数，仅仅返回查询结果集中的第一行第一列。

在环境下通过调用以上定义的函数，就可以实现使用各种嵌入式SQL语句来操纵后台数据库的功能。

（三）C#语言环境下的设计实现

由于C#简单易学，而且可以跨平台使用，因此它正在成为程序开发人员使用的主流编程语言。[4] 它具有如下诸多优点：

C#遵守通用语言规范（common language specification，CLS）。

C#具备自动内存管理功能：CLR 内建垃圾收集器，当变量实例的生命周期结束时，垃圾收集器负责收回不被使用的实例占用的内存空间。

C#具有交叉语言处理能力：由于任何遵守通用语言规范的程序设计语言源程序，都可编译为相同的中间语言代码，不同语言设计的组件，可以互相通用，可以从其他语言定义的类派生出语言的新类。

C#更加安全：C#语言不支持指针，一切对内存的访问都必须通过对象的引用变量来实现，只允许访问内存中允许访问的部分，这就防止病毒程序使用非法指针访问私有成员，也避免指针的误操作产生的错误。

C#软件的安装更加容易：在.NET 中这些组件或动态连接库不必在注册表中注册，每个程序都可以使用自带的组件或动态连接库，使软件的安装更加容易。

C#是完全面向对象的：C#语言中所有的函数、变量和常量都必须定义在类中，避免了命名冲突。C#语言不支持多重继承。

在开发项目中以类的形式来组织、封装一些常用的方法和事件，不仅可以提高代码的重用率，也大大方便了代码的管理。

本系统中using System.Data.SqlClient命名空间包含有关专门操作SqlServer数据库的类，如SqlConnection，SqlCommand，SqlDateAdapter等，System.Data命名空间包含数据库操作所需要用到的普通数据，如数据表，数据行等；DbHelperSQL类定义了与数据库的连接配置、执行SQL语句的公用方法等。调用并且构建这些类的实例设计完成系统主窗体和系统的增、删、改、查询功能。

七、结论

（一）在不同高级语言环境下创建应用程序的过程都一样。

（二）在不同环境下使用的SQL语句都完全一样，可以实现同样的数据库操纵功能。

（三）在VB6.0环境下编写的应用程序，搬到.NET环境下不能使用。

（四）NET开发平台具有更加强大的内部函数库，.NET编程很大程度上依靠程序库中提供的可重用源代码，.NET框架提供了2500多个可重用的类。公共语言运行时库（CLR）提供了执行程序的服务，实现了编程语言的统一。.NET程序需要经过两次编译才能在CPU上运行，首先编译生成与CPU无关的中间语言（MSIL）程序，在CLR的支持下，中间语言程序被编译成由本地CPU指令组成的程序，实现了.NET跨平台运行的目标。[5]

（五）NET采用数据访问技术，支持离线的数据访问功能，同时提供了只进的、一次只能读取一条记录的消耗资源极小的DataReader对象，提高了应用程序对数据库访问的性能。更适用于分布式数据库应用系统的应用。

（六）和C#生成的代码可以完全通用。VB提供了很多类型转换函数型运算符，如CInt（）， CSng（）， CStr（）等，在C#中只要用（int） ， （float）， （String）即可； VB支持两种形式的异常，即.net框架的异常和VB自己的错误号码，而C#只支持第一种。用到VB自己的错误号码的程序几乎无法移植到C#中。

（七）VB支持模块，C#不支持。在C#中制造一个abstract类，共享所有成员，就和模块一样了。C#不能像VB一样直接访问模块中的成员，需要使用“类名.成员名”的用法。

（八）C#代码更加简洁，像一样简单，像C++一样强大， 是第一流的面向组件的语言。C#语言是.NETFrame Work 中新一代的开发工具，是一种现代的、面向对象的语言，它简化了C++语言在类、命名空间、方法重载和异常处理等方面的操作，摒弃了 C++的复杂性，更易使用，更少出错。它使用组件编程，和VB一样容易使用。C#语法和 C++、JAVA 语法非常相似。所有的.NET Framework中的基类库（Base Class Library）都由C# 编写。

参考文献：

[1]刘世峰.数据库应用技术（本科）[M].中央广播电视大学出版社，2008，103

[2]顾晓梅.数据库应用技术教程[M]，上海电视大学教材， 2010， 171

[3]吕军.软件项目综合实训（.NET篇）[M]，清华大学出版社，2010，96～97

篇4

[关键词]关系数据库SQL查询对策

中图分类号:TP3文献标识码:A文章编号:1671-7597(2009)1210080-01

在各类大型应用软件的数据库中,都存在大量的数据信息和记录,经常要对它们进行各种数据操作。SQL(Structrued Query Language)作为结构化查询语言,是大型计算机操作关系数据库的标准查询语言,同时也广泛地应用到小型计算机的数据库管理系统中。它是一种高度非过程化的语言,即只要用户按其语法规则写出符合操作要求的语句,而并不需要告诉系统应如何执行SQL语句,就可得到所要求的结果。随着数据库技术的广泛应用,在数据库程序的开发过程中,大量的工作是要进行数据查询和检索处理。本文从SQL查询语句执行的过程入手,对其执行效率进行分析,并给出参考性建议和优化策略。

一、SQL语句执行过程解析

在平时书写SQL查询语句时,虽然每个人的写法不尽相同,而且有时个别子句顺序并不影响操作结果,但是在各种数据库管理系统中,标准的SQL的解析顺序为:

1.FROM子句,组装来自不同数据源的数据;

2.WHERE子句,基于指定的条件对记录进行筛选;

3.GROUP BY子句,将数据划分为多个分组;

4.使用聚合函数进行计算;

5.使用HAVING子句筛选分组;

6.计算所有的表达式;

7.使用ORDER BY对结果集进行排序。

通过以上SQL语句的解析过程,我们可以对SQL查询语句进行优化处理。SQL查询语句的核心结构是SELECT…FROM…WHERE,了解了这个基本结构,我们可以从以下几个方面对其进行优化处理。

二、效率分析及优化对策

(一)从From子句入手

From子句后面接单表或者多表,通常情况下接受来自不同数据源的多表。如果是单表,一般情况下对表进行快速全表扫描。如果是多表的情况,查询设计优化器将采取自右向左的顺序依次读取数据表。如以下语句:“From table1,table2,table3”,优化器将优先读取table3表,然后是table2表,最后是table1表。在进行From子句的多表连接时,就需要结合条件子句WHERE进行分析,需要遵循下面的规则:1. 当WHERE后面接的条件能够一次性过滤某个表的大量记录时,应优先处理该表。2. 如果WHERE后面接的条件不能过滤掉大量记录时应该优先考虑处理记录数最少或者索引关键值最少的表。

(二)从条件子句WHERE入手

WHERE子句后面通常接过滤条件,对表的记录进行筛选,筛选出符合条件的记录。如果SELECT查询语句没有WHERE子句,则无须对表记录进行过滤。若后面接单个表,则通常顺序扫描全表。若后接多表或者大量记录表时,则可以考虑用索引来减少查询的时间。所以在查询前可对各个表建立比较的索引。对WHERE子句中出现的条件,可以依据以下原则首先来驱动查询。

(1)建立索引字段的列比没有建立索引的要快;(2)主索引要比普通索引快;(3)单索引要比符合索引快;(4)有条件约束要比没有条件约束要快。

此外,WHERE子句通常采用自下而上的顺序解析WHERE子句,根据这个原理,表之间的连接必须写在其他WHERE条件之前,那些可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾。根据以上原则,我们可以判断出以下四个语句中哪个选项语句效率最高。

Select * Frommobilewhere (mobileno='13775637677') andbegINtime>

{^2009-1-308:20:11} andbegintime

B) SELECT*Frommobilewhere(mobileno='13775637677' )andbegINtime

{^2009-1-30 8:20:11} andbegintime>{^2009-1-30 8:20:11}

C) SELECT*Frommobilewherebegintime

{^2009-1-308:20:11}and(mobileno='13775637677' )

很显然,综合以上原则C选项效率最高。

(三)从GROUP BY和HAVING子句入手

在SELECT语句中,GROUP BY语句的作用是对记录进行分组(划分成较小的组),使用聚合函数返回每一个组的汇总信息,而HAVING子句限制返回的结果集。在一个SQL语句中可以有WHERE子句和HAVING子句。HAVING与WHERE子句类似,均用于设置限定条件。WHERE子句的作用是在对查询结果进行分组前,将不符合WHERE条件的记录过滤掉,而HAVING子句的作用是筛选满足条件的组,即在分组之后过滤数据,但它不能单独使用,只能配合GROUP By语句使用,该条件中经常包含聚组函数,使用HAVING条件显示特定的组,也可以使用多个分组标准进行分组。虽然HAVING子句可以起到过滤的作用,但是要尽量避免使用HAVING子句,HAVING只会在检索出所有记录之后才对结果集进行过滤。这个处理需要排序,总计等操作。如果能通过WHERE子句限制记录的数目,而且能尽早地把不满足条件的记录过滤掉,那就能减少这方面的开销。

(四)从谓词等方面入手

在SELECT语句中,由于实际需要,查询语句会经常出现谓词。常用的谓词有EXIST,NOT EXSIT,IN,NOT IN等,巧用谓词也会提高SQL语句的执行效率,可参考以下原则编写SQL语句。

1.Where子句中尽量不要使用IS NULL或IS NOT NULL的语句,因为它们不会使用索引。

2.WHERE子句尽量不要将通配符(%)放在搜寻词首出现,通配符(%)在搜寻词首出现不会使用索引。

3.用EXISTS代替IN。在许多基于基础表的查询中,为了满足一个条件,往往需要对另一个表进行联接。在这种情况下,使用EXISTS(或NOT EXISTS)通常将提高查询的效率。

4.用表连接代替EXISTS。通常来说,采用表连接的方式比EXISTS更有效率。

5.用EXISTS代替DISTINCT。当提交一个包含一对多表信息(比如班级表和学生表)的查询时,避免在SELECT子句中使用DISTINCT。一般可以考虑用EXIST替换。

6.WHERE子句尽量少使用NOT或是,应该成OR来实行,使用OR时应该把结果集小的条件放在前面。

7.UNION改用UNION ALL,UNION要对合并的结果进行排序,UNION ALL不排序。

8.ORDER BY子句中尽量不要使用非索引列。

三、结语

通过对SQL查询语句执行过程的分析,可以从以上几个方面对其进行优化改进,从而提高了数据库查询和检索的效率。当然,具体的查询语句还要根据具体需要,并结合具体的数据库系统而定。只有多总结多积累才能写出高质量高效率的查询语句,当然这只是提高数据检索的一个方面,在其他方面的设计也要进行优化,如对表建立必要的索引,减少表之间的连接,或尽量在索引属性列上建立连接等。总之,通过以上几个方面的综合优化,一定会使数据库查询与检索效率有很大的提高。

参考文献:

[1]王振辉、吴广茂,SQL查询语句优化研究[J].计算机应用,2005,25(12).

[2]徐凤梅,关系数据库中SQL查询语言的优化策略[J].广西轻工业,2009,126(5).

[3]邓文艳,基于关系数据库的查询优化技术[J].太原科技,2007(12).

[4]杨克昌,Visual FoxPro程序设计教程[M].长沙:湖南科学技术出版社,2004.

[5]李莹、代勤,关系代数运算与SQL查询的对应关系[J].内蒙古农业大学学报(自然科学版),2003,24(3).

篇5

【关键词】Mysql数据库 图书管理 系统安全 研究

SQL（结构化查询语言）是世界上最流行的和标准化的数据库语言。Mysql可以说是目前最为流行的开源数据库管理系统软件，是一个真正的多用户、多线程SQL数据库服务器。Mysql开放源码，快捷灵活、稳定和容易使用等优点决定了其在中小型管理系统应用的优势。本文以基于Mysql网络数据库的图书管理系统为例，从安全稳定性要求和采取的安全策略等方面进行分析研究。

1 Mysql在信息管理系统的应用与优势

1.1 Mysql的基本特性与应用

Mysql与其他大型数据库Oracle、DB2、SQL Server等相比，有自身的不足之处，但是没有影响到Mysql在信息管理系统的应用。在个人或者是中小型的企业，Mysql发挥了自身的优势与作用。Mysql开放源码，具有快捷灵活、稳定和容易使用等优点，并有效的提供了PHP、C，C++，JAVA和HTML等主流前端开发软件的API接口。支持多种操作系统包括Windows 、Linux 、Solaris、Mas OS等。目前，搭建动态网站或者服务器的开源软件组合有典型的网络架构LAMP，极大地方便了开发者。Mysql应用非常广泛，Google、facebook、等使用Mysql作为网络数据库。

1.2 Mysql应用于图书管理系统的优势

Mysql应用于图书管理系统的优势主要分为三个方面，一是免费开源优势，如果再使用linux操作系统，可以减少购买操作系统和数据库的开销。二是多种平台支持的优势，Mysql可以与多个平台进行有效的连接，实现信息资源的共享。三是中小型数据库灵活稳定的优势，在设计Mysql程序的时候，加入了SQL中没有的一些补充条件，更加的适用于在中小型数据库中使用。图书管理系统通常要保存用户信息、图书信息和借阅信息，以及建立相关的书籍查询等，数据仓库并不是很庞大，因此，使用Mysql来管理数据非常合适。

2 基于Mysql的图书管理系统安全稳定性分析

高校图书管理系统是基于互联网的网络数据库，通常采用B/S的体系结构，因此，在浏览器层、Web 服务器层、数据库服务器层都会存在安全性要求，以及在操作系统、网络技术等方面的安全问题。只有控制好图书管理系统的安全问题，才能保证信息资源的有效共享。

基于网络数据库的图书管理系统的安全稳定性具有以下几个特点：

（1）较高的稳定性，包括操作系统的稳定性和数据库系统的稳定性，要保持Mysql数据库的正常运行轨迹。

（2）数据的保密性能，对客户信息、访问浏览量、客户端等进行有效的保密。

（3）运行的速度很快，包括浏览器端、数据库服务器端的访问速度，以保证数据信息在查找、修改等方面的快速反应。

（4）数据的备份与数据的恢复功能。数据库服务器中，包括图书信息、借阅图书记录、客户账号等在内的相关数据的安全问题，是保证图书管理系统正常运转的重要因素。要采取严格的防范措施，同时，当发生数据故障的时候，要在最短的时间内恢复数据与系统。

3 基于Mysql的图书管理系统安全稳定性策略

图书管理系统通常采用三层B/S结构模式，即用户层、Wed服务器层和数据库层。图书管理系统要注意提高数据库安全、操作系统安全和网络安全技术等方面的安全策略。

3.1 优化数据库设计

比如，在遵循关系模式规范化的基础上，优化表设计适当增加中间表或增加冗余字段以减少连接查询所花的时间，优化JOIN操作和子查询尽量使用全连接避免产生中间表，尽量避免LIKE 关键字和通配符进行查询。另外，还可以修改my.ini文件，对相关参数如sort_buffer_size 、read_buffer_size 、query_cache_size、max_connections等，设置合适的缓冲区大小和MySQL允许的最大连接进程数，以优化服务器提高系统性能，提高保证图书信息资源查询效率。

3.2 数据容灾与备份机制

要定期地进行数据备份，保护图书书目数据、流通数据、客户信息等。定期的进行数据库的重组工作，增强数据库的使用性能。用好MYSQL的容灾与备份机制，比如：建立主从数据库集群，采用 MySQL 复制；制定数据库备份/恢复计划；启动数据库服务器的二进制变更日志；定期检查数据表；定期对备份文件进行备份；把 MySQL 的数据目录和备份文件分别放到两个不同的驱动器中，等等。

3.3 帐户安全策略

可以从账户安全检查、系统内部安全措施、哈希加密等方面着手进行。比如，检查用户表mysql.user是否有匿名空账号（user=‘’ ），如有应将其删除。使用哈希加密帐户密码。加强客户的登录认证，尤其是服务器主机的登录认证。在主数据库创建从数据库操作所用的用户，并指定使用SLL 认证等等。

3.4 网络安全和操作系统安全策略

在网络安全策略方面，利用NAT技术，有效的防止发生来自网络外部的攻击现象，将局域网络内部的计算机系统进行隐蔽。正确设置计算机操作系统，确保客户使用真实身份，登录具有合法性。此外，还可以设置系统的实时监控，优化网络防火墙、文件加密以及杀毒软件技术的升级，等等。

4 结语

综上所述，要确保基于Mysql在图书馆管理系统的安全稳定性能，要考虑很多种因素的影响，在数据库设计、数据库服务器、数据容灾与备份、帐户安全，以及计算机网络、操作系统等方面进行优化配置。图书管理系统的安全与稳定性能保证了信息数据的安全、稳定性与高效，保证了客户在不同的时间、地点、平台中有效的使用图书馆的资源信息共享。

参考文献

[1]晋征.论基于网络数据库的图书馆管理系统安全性研究与实现[J].网络安全技术与应用，2015（3）：27-29.

[2]阳学军.基于网络和人工智能的图书馆信息管理系统研究[J].岳阳职业技术学院学报，2005（3）：59-61.

[3]林爱鲜.基于神经网络的图书馆管理系统的构建研究[J].电脑与电信，2012（4）：48-50.

[4]田华.图书馆分布式数据库安全技术研究[J].现代情报，2007（4）：161-163

篇6

数据库技术发展至今已有40多年的历史,它作为数据管理的有效手段,大大促进了计算机应用技术的发展。从早期的文件系统到层次数据库和网状数据库,从关系数据库到面向对象数据库,以及面向不同应用的时态数据库、演绎数据库等等,均向人们展示了数据库技术的广阔应用前景[2]。关系数据库,顾名思义是建立在关系数据库模型基础上的数据库,借助于集合代数、离散数学等概念和方法来处理数据库中的数据。关系数据库是一个被组织成一组拥有正规描述的表格,该形式表格作用的实质是装载着数据项的特殊收集体。这些表格中的数据以许多不同的方式被存取或重新召集而不需要重新组织数据库表格[3]。除了相对容易创建和存取之外,关系数据库具有容易扩充的优势。在最初数据库创造之后,一个新的数据种类能被添加而不需要修改所有的现有应用软件。目前主流的关系数据库有Oracle、SQL、Aceess、DB2、MySQL、SQLServer、Sybase等等[4]。根据本校办学规模和处理信息量,采用ACEESS作为本系统数据库的管理工具。

2数据库模型建立

2.1应用需求抽象

根据学员信息管理的具体任务,按照管理功能进行业务划分和模块化设计。按照简单性、独立性及完整性原则,学员信息管理系统后台可以分为以下几个子系统:即学员档案管理子系统、课程管理子系统、成绩管理子系统、中队管理子系统、管理统计子系统、系统管理子系统、系统维护子系统。(1)学员档案管理子系统学员档案管理主要有学员管理、批量学员添加、按中队批量学员添加等功能。(2)课程管理子系统课程管理子系统主要有课程管理、批量课程添加、任课管理、任课添加等功能。(3)成绩管理子系统成绩管理子系统完成成绩管理、批量成绩添加、按中队成绩添加功能。(4)中队管理子系统中队管理子系统完成中队管理、中队批量添加两个子模块功能。(5)管理统计子系统管理统计子系统显示学校基本信息,包括年级数、中队数、学员数、教师数、课程数、用户浏览统计等相关信息,还可完成学员统计、排名统计功能。(6)系统管理子系统系统管理子系统包括修改管理员密码、帐号管理、干部管理、年级管理、学期管理功能。(7)系统维护子系统系统维护子系统主要完成系统的相关设置功能,包括站点名称,站点LOGO设置,网站主体表格属性设置,年级变迁(这里主要是对年级进行批量升级操作,也可以在中队管理下单个进行升级)。

2.2数据库表关系建立

关系数据库模式的建立,离不开数据表之间关系的建立,只有建立表之间的关系,整个数据库才能形成一个系统,提供强大的信息存储、查询、和处理功能[5]。对比应用需求说明和现实学校各部门的业务流程,设计数据库表之间的关系如图1所示。(1)学员和评语之间存在一对多的对应关系,即一个学员可以有多条来自不同老师的评语;学员和家长存在一对多的对应关系,即一个学员可以对应一个家长,方便家长对学员相关信息进行查询。学员和平时成绩存在一对多的对应关系,即一个学员可以有多种平时成绩;同时,学员还和中队有多对一对应关系,即一个中队可以有多个学员。(2)中队和成绩有一对多的对应关系,即一个中队可以有多条成绩;中队和年级有一对一的对应关系,即一个中队属于一个年级。中队和大队有一对一的对应关系,即一个中队属于一个大队,中队和任课信息有一对多的对应关系即一个中队有多条任课关系与之对应。大队和中队有一对多的对应关系,即一个大队对应多个中队。(3)任课信息表中的教师ID和教师信息表中ID存在一一对应关系。教师表中ID和任课教师信息表中的ID存在一对多的关系。即一个教师可以有多个任课关系。任课教师表中的课程ID和课程表中的课程ID存在一一对应关系。任课信息表中的学期和学期ID存在一一对应关系。即一个任课信息对应一个学期。成绩表中的课程ID和课程信息表中的ID存在一一对应关系,成绩表中的学期ID和学期表中的学期ID存在一一对应关系。

2.3数据库模式设计

2.3.1关系数据库设计中存在问题

(1)数据冗余:在一个数据集合中重复的数据称为数据冗余。例如在设计时没有把教师信息表Teacher和任课信息表tea_sub分开,那么每存储一条任课信息tea_sub(tsid、ts_tea_user、ts_sub_id、ts_ter_id、ts_cla_id)教师表中的其他信息也要重复存储[4]。(2)更新异常:更新异常分为插入异常和删除异常。插入异常:比如学员信息表student,如果不知道学号,那么插入再多的其他信息都是没有意义的。例如一个刚入职的教师理所当然要在任课信息表中有其相关数据,但此时他还没有任课,即他对应的元组是不完全的,只有而没有,不能将他的信息放到数据库中。因此无法注册该教师的任课信息,这与实际需求不符。这样的操作是不合理的,将这种现象称为插入异常。删除异常:例如在没分解的教师信息表中的任课信息中,相应的任课关系解除。那么删除整条记录,该教师的其他信息也被删除,在查询的时候无法查阅该教师相关信息,这也与实际需求相悖,将这种现象称为删除异常。数据库的性能优化包括硬件优化,查询优化和设计优化三个方面。本文着重介绍设计优化即模式优化,模式优化重点解决数据冗余和更新异常问题。

2.3.2数据库模式的规范化

在对数据库进行模式设计时,对关系的分解并不是盲目的,分解的目的在于减少关系模式的规模,避免不必要的存储及操作的冗余和数据更新异常。为了清除异常,需要对关系模式进行合理地分解。为此,人们设计数据库设计的规范化理论,以便能够设计出异常尽可能少的数据库模式[4]。据参考文献[4]所述,数据库模式分为6级,具体的定义见参考书目。分别是1NF:是关系数据 库对模式的基本要求,即要求属性的值必须是原子属性不可再分。2NF:消除了数据库模式中非主属性对码的部分依赖。3NF:消除了数据库模式中非主属性对码的传递依赖。BCNF:消除了数据库模式中一切属性对码的传递依赖。4NF:消除了数据库模式中非平凡的和非码所隐患的多值依赖。5NF:消除了数据库模式中非平凡的和非码所隐患的连接依赖[4]。范式的级别由小到大分别是有1NF到5NF。范式的级别越低,冗余与更新异常就越容易产生[6]。(1)满足1NF的学员信息表分解,在学员信息表中每一个属性都该是原子属性,故对部职别进行分解。由消防部队的编制特点,每个省、自治区、直辖市均有相应的消防总队;每个地级市、自治州、区都有相应的消防支队。学校学员来自五湖四海,故对学员信息表中的部职别属性进行分解。由于有的学员来自总队和支队机关,故把部职别分为总队和部职别两个属性,即分解为,province为province表中的省份ID。总队表设计为province(pid、pname)。在学员信息表中只要存储省份ID就行。不用再存储省份名。最长总队名新疆维吾尔族自治区消防总队所占字节为26Btye,所占ID为2Byte。按新疆总队有学员121名计算,模式分解前学员原部别信息中存储总队信息需用26Btye×121=3164Byte;而模式分解后存储ID信息占用2Btye×121=242Byte。(2)满足BCNF的教师信息表分解,在2.4.1节数据库设计存在问题中提到数据冗余和删除异常,在没分解的教师信息表的任课信息中,相应的任课关系解除。那么删除整条记录,该教师的其他信息也被删除,在查询的时候无法查阅该教师相关信息,这也与实际需求相悖。要解决删除异常,即把教师信息表Teacher分解为教师基本信息表teacher和任课教师信息表tea_sub(tsid、ts_tea_user、ts_sub_id、ts_ter_id、ts_cla_id)。这样的分解既解决了数据冗余的问题,也解决了删除异常的问题。分解后Teacher和tea_sub关系模式都是1NF,且在其中不存在这样的属性A,A传递依赖与Teacher和tea_sub的码、由于关系模式Teacher={R1,R2…,Rn}和tea_sub={R1,R2…,Rn}中Ri(i=1,2,…,n)为BC范式,则关系模式Teacher和tea_sub也满足BCNF。数据库的规范化设计还有很多,根据系统应用需求的变更和数据规模的递增,需要设计相应的数据模式来优化昆明消防指挥学校学员综合信息管理系统的数据库性能,使之满足应用需求,更好地为学校教师、学员和管理人员提供便捷的信息化服务。

篇7

关键词 分布式异构数据库；高校；数字图书馆

中图分类号：G258.6 文献标识码：B

文章编号：1671-489X（2015）11-0078-02

在我国高校数字图书馆的建设过程中，由于各个数字图书馆在建设的过程中缺乏协调性以及统一性，导致不同高校之间的数字图书馆的资源共享出现严重的阻碍，不利于各高校数字图书馆之间的数据交流。各高校数字图书馆之间封闭的特性，导致资源的浪费，也影响了广大用户的正常使用。以中间件技术作为基础可以建立高校数字图书馆之间的分布式异构数据库检索模型，能够为解决当前高校数字图书馆之间的资源共享问题提供可行性的技术方案。

1 分布式异构数据库的概念

分布式数据库技术是伴随着信息技术的发展而出现，是数据库技术与信息网络技术相互结合的产物。分布式异构数据库技术实现了诸多数据库系统的结合，可以实现不同数据库之间的资源的共享，同时又不损害任何一个数据库系统的整体性与安全性。在实现资源共享的同时，每一个数据的完整性、独立性以及安全性并不会受到人为威胁。异构数据库的异构性主要体现在三个方面：计算机结构的异构性、DBMS的异构性以及操作系统的异构性。异构数据库所要实现的最终目标是不同数据库之间的信息资源、硬件资源以及人力资源的共享。目前，我国数字图书馆在建设的过程中呈现明显的独立性的特点，不利于各高校之间信息资源的共享，造成严重的资源浪费现象。因此，分布式异构数据库信息检索模型在高校数字图书馆中的应用有利于提高资源的利用率。

2 分布式异构数据库的技术研究

分布式异构数据库的主要技术包含两种：一种是中间技术，负责服务器与数据库之间的连接；一种是数据查询处理技术，负责信息资源的查询。

1）中间件（Middleware）是计算机软件系统与应用软件系统之间实现连接的软件系统。中间件的存在，方便了电脑系统各个部分之间的沟通，特别是应用软件对于系统软件的集中的逻辑，在现代信息技术应用框架（如Web服务和面向服务的体系结构等）中应用比较广泛。中间件为实现服务器与数据库之间的连接提供服务。这类服务系统都有十分标准的程序接口以及网络服务协议。目前在市场上流通的中间技术主要有OMG公司所提供的CORBA，本文的主要设计就是立足于CORBA。

2）数据查询处理技术。数据查询处理技术指的是用户根据自己的实际需求在客户端进行搜索并获得自己所需要的新的技术。数据查询技术主要是通过科学地选择有效的方法，根据客户输入的条件以获得满足条件的信息资源反馈给用户。就一般情况而言，数据库查询技术主要包括四个方面：首先是信息转化，就是将用户输入的内容转化为内部语言；其次，把语法树转换成标准（优化）形式；再次，选择低层的存取路径；最后，选择科学合理的查询计划进行查询，并最后反馈查询结果。

3 系统模型的建构

CORBA的英文全称是Common Object Request Broker Architecture，即公共对象请求体系结构，构成当前主要的三大中间技术之一。在设计之初，CORBA就被当作是远程体系结构，是为了解决不同地区之间的计算机的通信问题。就一般而言，CORBA分为三个不同的主要层次系统。

1）处于最底层的系统是对象请求，构成CORBA系统的软总线，规定了分布对象的定义以及对语言的映射，得以实现远距离对象之间的通信以及相互操作。

2）公共服务对象。CORBA的公共服务对象包含有很多内容，如为客户提供位置服务、安全服务等多样化的服务。

3）位于最上层的公共设施，它明确规定了CORBA的组件结构以及协作服务中的有效协议。

由于目前CORBA为客户提供多样化的服务，所以使用范围十分广泛，已成为主流的分布式平台。

分布式异构数据库的信息检索模型 分布式异构数据库的信息检索模型是建立在现代高校数字化图书馆的基础之上的，其主要的图形结构如图1所示。

该系统模型可以依据现在学校的网络，无需另行设计，通过互联网可以有效地整合各高校数字图书馆之间的资源为客户提供服务。同时，服务终端和服务器可以处于不同的网络地点和环境。ORB不再负责完成用户与数据库之间透明的同时，并不会对各高校数字图书馆的完整性以及安全性造成任何的威胁。

CORBA中间件层次结构体系 把CORBA作为基础的中间件结构，主要分为四个层次分明的结构体系：用户端与ORB之间主要处理用户与系统之间的交互，为用户提供统一的、具体的服务；ORB层主要通过ORB为客户提供透明的路径搜索服务；应用服务层主要通过相关技术为客户提供具体的搜索服务；数据库层主要完成对数据的存储以及处理。

4 分布式数据库系统模型在高校数字图书馆中的实现

CORBA的应用是在Java平台基础之上实现的，原因是Java可以跨越平台，以及Java技术本身所具有的可解释性、可移植性、高性能和面向对象的编程语言以及运行环境等特性。CORBA是一项集成技术，它为已有高校数字图书馆提供各种模块及组成，通过链接技术，CORBA间不同的数字图书馆的信息资源与用户实现透明性。在应用的过程中，CORBA发挥的作用不仅仅是对象请求，同时也构成一个对象分布式的整体。通过CORBA，Java在各种环境中的使用得到极大的拓展。Java所创建的可移动的对象，可以通过CORBA的连接作用，与数据库等对象实现相互集成。

建立在CORBA基础上的分布式的系统模型，用户在进行使用时，可以使用网络上的统一的检索平台，从各高校的数字图书馆中选择符合自己实际需要的信息资源。这些服务的实现主要是由Java Beans及JSP来完成的。在Web服务器上选用VisiBroker For Java为该数据库提供安全的、可靠的、健全的ORB通信服务。Gatekeerper允许向驻留在Web服务器上的对象发出操作请求，并可接收对象的回调。利用Smart Agent搜索并且定位已注册的CORBA对象， 为客户端程序和服务端对象通信建立好连接，并提供CORBA对象负载平衡和容错能力。

5 结语

由于高校在数字图书馆的建设过程中缺少沟通，导致各高校数字图书馆在资源共享方面存在一定阻碍。如何实现不同高校之间信息资源的跨库检索，已经成为图书馆管理工作中的一个重点。根据信息技术发展的最新成果，利用分布式数据库技术可以实现各高校数字图书馆之间信息资源的共享，可以有效提高信息资源的利用率。

参考文献

[1]孔祥疆.软件开发方法与建立异构数据库使用平台模型[D].乌鲁木齐：中国科学院新疆理化技术研究所，2005.

[2]罗林球，孔祥疆，李晓.基于CORBA/数据字典/JDBC的异构数据库检索系统实现[J].计算机应用，2006（6）.

[3]朱学芳.国内外异构数据库统一检索系统的比较研究[J].情报检索，2005（12）.

篇8

【关键词】电网地理信息系统；关系型数据库；图数据库；拓扑遍历

随着中国电力行业生产管理信息化的不断推进，大多数电网企业已经建立起基于地理信息系统的输电网络、配电网络规划、营销、生产、巡检、抢修、调度等的系信息化系统。目前常用的地理信息系统对电力设备的信息存储管理都是架构在传统的关系型数据库系统（RMDBS）之上。传统的关系型数据库系统应用模式深入人心，已为广大系统用户及软件开发厂商所熟悉。基于传统的关系型数据库系统可以快速的开发出能满足业务需求的应用系统。

但是，当电力企业对电网的管理粒度越来越细致、电力企业业务对地理信息系统依赖程度越来越高、地理信息系统存储的数据量越来越大时，传统的关系型数据逐渐暴露出其先天的局限性，其中的一些局限无法简单地通过应用程序优化得到解决。这时，探讨另辟蹊径、使用合适的数据存储系统显得适时与必要。

1 地理信息系统数据库在电网设备管理上的应用现状

电网线路及各型设备整体上具备显著的地理位置相关性，在地理信息系统中，电网线路及设备一般分为三类模型：点模型、线模型、面模型。典型的点模型有杆塔、开关等；典型的线模型有架空线、电缆等；典型的面模型有配电房、变电站（根据不同的管理粒度，如不需对变电站内设备进行管理，则变电站可以表达为点模型）等。基于地理信息系统的电网管理系统，一般包含对电网设备模型的属性信息的管理功能，包括浏览、查找、增加、编辑、删除等操作，系统存储着管理中需要的设备属性信息。其中非常重要的的属性信息包括：设备所在地理坐标，各设备之间的连接关系，各设备之间的从属关系，设备本身的状态信息（例如开关的开合状态）。所有这些电网设备属性以及电网设备间的关联从属关系，均存放在关系型数据库中，通常，各企业均采用关系型数据库（例如Oracle），将这些属性信息及关系信息存储在关系表中，通过标准的SQL操作对信息进行新建、检索、更新。

1.1 主要应用点

地理信息系统通过企业数据总线，与各业务系统进行了松耦合的服务集成和交互，为各业务应用提供各类电网空间信息服务，提供的业务支撑包括以下领域：生产管理、营销管理、调度管理、抢修管理、综合停电、电网规划等。

生产管理应用有：设备图形描绘录入、设备属性编辑、设备连接从属关系录入等。

营销业务应用有：设备查询定位、电网拓扑分析、专题图展示、户变关系交互、业扩报装辅助决策、负荷迁移辅助决策等。

调度业务应用有：专题图展现、专题图审核与、电网图形数据交换等。

抢修管理应用：应急资源查询定位、电网拓扑关系分析、热点查询定位、专题图展示等。

电网规划业务应用：电网规划模型管理、规划图管理、电网现状分析、区域负荷分析、变电站选址辅助决策、线路供电廊带等。

综合停电业务应用：为综合停电提供电网拓扑数据、停电影响用户数据。

可以看出，以上应用点可以归类为三类基本的电网地理信息系统服务：

（1）设备属性、图纸录入维护；对应的业务应用是：生产管理应用。

（2）设备定位查询、图纸查询；对应的业务应用是：营销业务应用、调度业务应用、抢修管理应用等。

（3）电网拓扑连接分析。对应的业务应用是：营销业务应用、抢修管理应用、电网规划业务应、综合停电业务应用。

1.2 主要的局限性及传统应对方法

1.2.1 电网设备大并发读写性能不高

一般关系型数据库使用关系表级别的查询缓存，每次表中的一个记录被更新，整个表的缓存即告失效，需要重新进行加载，这是一种大粒度的缓存。由于日常使用中生产管理系统会频繁地调用第一类电网地理信息系统服务“设备属性、图纸录入维护”，直接导致数据库缓存被频繁更新，造成系统I/O频繁，影响到第二类和第三类电网地理信息系统服务。

为应对这个局限性，确保大部分第二类和第三类服务的性能，一般采取对编辑录入结果延（例如在凌晨进行）的方法，以使缓存更新错开系统业务高峰。

1.2.2 电网模型属性增减不灵活

关系型数据库里，由于所有记录是按行存储，原则上是假设记录的长度（即字段个数及长度）是固定的，增删字段会引表的重构并导致性能的损失。即使采用字典表的组织形式（如Oracle），也会在日积月累的字段增减使得整个表存储结构的零碎化，慢慢的导致访问性能下降。如果生产管理上经常对设备属性进行调整，这个局限会影响到了前文提到的所有三类服务。

为了减轻这个局限带来的影响，地理信息系统一般采取预先分配字段的方式，建表时先添加多于实际需要的字段，以应付以后的字段增长需求。这样的设计能有效抵消属性字段增减带来的负面影响，但是造成存储空间上额外开销。

1.2.3 电网拓扑分析性能低下

由于地理信息系统所采用的关系型数据库的特点，每一对电网设备的连接关系都被表达成一个二元组的形式，并被按行存储在存储介质中。如图1所示。

图1 关系型数据库中设备逻辑的存储

关系型数据库均没有自带内嵌的节点物理遍历存储过程或方法，当要遍历一次设备连接链时，必然要通过应用程序会存储过程经过对每一个设备节点进行查找才能完成遍历。假设该连接表建有索引，对每个节点的查询时间复杂度即为对索引的查询复杂度

O（nlogn）（1）

由于这个遍历过程由应用程序执行，因此执行效率还会受应用程序与数据库系统间数据传递开销影响。

常见的应对方法是尝试由应用程序将整个连接表导入内存中以减少遍历过程中对数据的访问次数。理论上这种方法是可行的，但实际上由于一条设备连接链逻辑节点会分布在表中的各个位置而不是集中在一起，而且整个数据库的设备总数十分大，把整个连接表导入内存并不可行。此问题也是关系型数据库在电网设备地理信息系统上难以解决的问题，对第三类服务的执行效率造成很大影响。

2 图数据库在电网地理信息系统上的应用前景

前文提到关系型数据库在电网地理信息系统上的应用局限性，虽然大部分局限性均有办法通过应用程序优化进行减轻，但由此带来的应用开发难度提升、软硬件资源的额外消耗，增加了应用系统的建设成本。并且，这些减轻措施并非真正解决根本问题，当遇到极限场合时，这些局限性又会不可控制地爆发。然而，随着数据库技术的不断发展，关系型数据库的这些局限性均可以通过使用新型数据库进行有效地解决。

2.1 图数据库的技术特点

为了解决的关系型数据库的种种局限性，业界研发了大量能解决这些问题且各自具有鲜明特点的不同技术，它们可以与现有关系型数据库相互配合或代替关系型数据库，它们被统称为NOSQL数据库（Not Only SQL-databases）。其中，图数据库（Graph Database），是这些NOSQL数据库中基于大型稠密网络结构的一种数据库技术，其技术特点，刚好可以切合电网地理信息系统的种种需求。

2.1.1 图数据库的逻辑结构

图数据库里的信息建模使用三种构造单元：

节点；

边；

属性。

以上三种单元以以下规则进行组织：

节点和边有可变的属性列表；

边具有方向和类型；

两个节点间可以存在多条边。

为更感性的了解这个逻辑结构可以参考图2。

图2 图数据库的逻辑结构

每一个节点相当于关系型数据库中的一个记录，节点中的属性则对应着关系型数据库中记录中的字段。由于节点的属性表是可变的，应用程序随时可以为一个节点添加删减属性，添加属性不会影响现有代码任何逻辑。

另外，图数据库与关系型数据库最大的不同点在于，在关系型数据库中使用连接表（另一个关系表）来表达的连接和从属关系，在图数据库中已经作为一个基本单元来进行表达。

2.1.2 图数据库的物理存储结构

为了支撑前文提到的逻辑结构，开发者对图数据库的物理存储进行了针对性的设计。

节点是按固定大小的记录顺序存储在物理介质上；

节点带有两个固定指针，分别指向其第一个边和第一个属性；

边记录包含两个指针，分别指向边两端的两个节点；

属性除了属性值外，还带有两个指针，分别指向前同一节点（或边）的前一个属性和后一个属性。

为简便起见，图3对图2中的设备1和设备2在图数据库中的存储进行了表述，其他设备只提及被设备2指向的连接。

图3 图数据库的物理存储结构

由以上结构可知，由于设备节点是顺序存储的定常结构，节点到边以及边到节点又是以指针形式存储，图数据库对单个节点或边的访问均是直接定位到存储位置的，不需要进行额外的物理存储读写来对节点或边进行访问。

2.2 图数据库的优劣势

2.2.1 优势

由于图数据特殊拥有网络化的逻辑结构及物理存储结构，在图数据库中对节点根据连接关系进行遍历十分迅速，由于连接关系在数据录入时就已经建立完毕并且直接反映到物理存储结构中，对节点网络的遍历（无论是深度优先遍历还是广度优先遍历）时间复杂度是常数级的，即

O（n）（2）

同时，由于图数据库每个节点均有独立的属性列表，因此，可以在如数据库任意添加或删除属性（对应与关系数据库中的字段），而不对整个数据库造成负面影响，从而实现良好的伸缩性。

另外，由于图数据库不存在表，缓存也是针对节点级别的，因此，数据更新对缓存的总体命中率的影响比关系型数据库在相同场景下要轻微。

这些优点，恰恰能解决前文提到的关系型数据库在电网地理信息系统中应用的三个局限性。

2.2.2 劣势

在众多优点的光环下，图数据库依然有其短板。首先，其不存在关系表，因此数据节点的组织在数据库层面的逻辑联系不显而易见，开发者往往要阅读应用程序才能完全明白数据间的关系，造成对数据理解的额外开销。其次，由于图数据库以节点及边为基础的物理存储方式，真对某一属性进行全量数据的分类检索可能会十分缓慢，不适合用作属性检索类的应用基础。因此，图数据库不能完全替代关系型数据库，在实际应用场景中，图数据库应与关系型数据库互补长短，才能发挥出系统的最大功效。

3 结论

本文对关系型数据库在电网地理信息系统中的应用局限进行了分析，并针对这些缺陷结合图数据库技术特点探讨了应用图数据库的可行性，得出以下结论：

（1）图数据库的优势可以有效解决现在电网地理信息系统中由于关系型数据库局限性遇到的问题。

篇9

【关键词】智能电网；海迅数据库；PI实时数据库

0.引言

信息化、自动化和互动化是智能电网的三大特征，这其中，信息化是基础，是解决智能电网可观测，继而实现可控与在控的重要途径。随着智能电网建设的不断深入，越来越多的智能测量装置遍布整个电网，尤其是各网省公司和直属单位输变电设备状态监测、用电信息采集、配电自动化、发电集团信息化等项目的试点与推广，产生了大量实时数据。实时数据沉淀生成海量历史数据，连同调度生产控制大区生成的电网运行方式、关口电量、保护、雷电等历史/实时数据一起，这些数据是重要财富，是实现精益化管理的重要基础。如何高效地采集、处理、存储、检索和利用这些海量信息，已经成为建设智能电网所要面临的首要问题。关系型数据库和实时数据库是目前数据库市场上应用较为广泛的两类数据库，故数据的存储一般采用关系型数据库或者实时数据库存储。本文先介绍这两个类型数据库的定义及特点。

1.实时数据库与关系数据库

1.1关系数据库的介绍

关系型数据库，是建立在关系模型基础上的数据库，以关系模型组织数据并借助于集合代数等数学概念和方法来处理数据库中的数据，用二维表的形式来表示实体和实体间联系的数据模型。关系模型由关系数据结构、关系操作集合、关系完整性约束三部分组成，具有数据结构简单、查询与处理方便、数据独立性高、理论基础坚实等特点。关系模型也是目前技术最成熟、应用最广泛的数据库技术，设计和实现风险较低，但由于关系模型提供了较高的数据独立性和非过程化的查询功能，系统的查询速度和查询效率较低，但其仍是数据存储的传统标准。

1.1.1关系型数据库组件

关系型数据库通常包含下列组件：

（1）客户端应用程序（ Client ）。

（2）数据库服务器（ Server）。

（3）数据库（ Database）。

1.1.2关系型数据库优缺点分析（相比实时数据库）

关系型数据库相比实时数据库而言，有着以下优点：

（1）容易理解。二维表结构是非常贴近逻辑世界的一个概念，建立在严格的数学概念基础上，数据结构简单、清晰。因此，关系模型相对其他模型来说更容易理解。

（2）使用方便。通用的SQL语言易学易懂，程序员、数据管理员可以方便地在逻辑层面操作数据库，而完全不必理解其底层实现。其提供的诸如视图、存储过程、触发器、索引等对象使数据访问趋于便利。

（3）易于维护。丰富的完整性大大降低了数据冗余和数据不一致的概率。

（4）安全性高。登录身份验证功能完善，提高安全性。

1.2实时数据库的介绍

实时数据库是数据库系统发展的一个分支，是一种专用的处理海量实时信息的基于测点模型的数据库，针对实时采集的具有时序特征的海量数据具有极高的事务处理能力、数据压缩比和查询检索速度。实时数据库是基于先进控制和优化控制而出现的，对数据的实时性要求比较高，因而实时、高效、稳定是实时数据库最关键的指标。

1.2.1实时数据库的逻辑结构

实时数据库逻辑上包含实时数据库、历史数据库和测点数据库三部分。实时数据库维护实时数据，实时数据是每个测点时间戳最大的量测值（也就是当前值）；历史数据库维护历史数据，历史数据由实时数据不断归档沉淀后产生，实时数据库中往往采用压缩的方式存储历史数据；测点数据库则维护所有测点的各种信息。

1.2.2实时数据库在处理实时数据上的优势

实时数据库具有实时数据写入和访问速度快、历史数据归档和访问速度快、历史数据高效压缩、数据以及接口符合测点模型等优点。但实时数据库对测点数有限制，而且往往按测点数收费，导致等量数据的管理成本相对关系型数据库偏高。

实时数据库在数据通信、数据组织、数据存储、数据检索、数据访问、数据处理、数据展现等方面的专业化及产品化，为构建基于大容量实时历史数据之上的分析应用提供了便捷稳定的数据支撑，使应用系统可以从更高更深层次充分利用宝贵的生产实时历史数据。

1.3实时数据库的和关系数据库的对比

从下表对关系型数据库和实时数据库在数据组织方式、访问方式、压缩方式、应用领域等的比较结果可见，实时数据库产品更适合供电企业生产的需要。这是因为电力生产具有生产、传输和使用同时完成的特点，生产过程中产生大量的时序数据，应用也需要大量围绕着这些实时/历史数据。实时数据库在处理时序数据时具有的存储速度快、数据压缩比大、节省存储空间等有点，在供电企业的生产应用中具有不可替代的优势。

2.实时数据库产品的介绍

目前市面上比较有名的实时数据库产品有PI实时数据库，eDNA实时数据库，iHistorian 实时数据库，此外，SyncBASE、海迅和安捷（Agilor）在数据库市场中也占有一定份额。其中，国际市场占有率最大的PI实时数据库。另外，我国自主研发的数据库产品海迅实时数据库也在配调自动化等领域暂露头角，取得了较大份额。因此下面重点对比这两个产品。

2.1 PI实时数据库

PI是由美国OSI Software公司开发的一套基于C/S架构的实时数据库软件应用平台，主要应用于存储和获取时间序列的实时数据，是工厂底层控制系统与上层管理信息系统连接的桥梁。一方面，PI用于工厂数据的自动采集、存贮和监视，作为大型实时数据库和历史数据库，PI可存贮每个过程点的多年数据，并提供清晰、精确的操作情况画面，用户既可浏览工厂当前的生产情况，也可查看过去的生产情况；另一方面，PI为最终用户和应用软件开发人员提供了快捷高效的工厂信息，PI在业务管理和实时生产之间起到了桥梁作用。

2.2海迅实时数据库

海迅实时数据库管理系统是江苏瑞中数据股份有限公司研发的国内拥有完全自主知识产权的大型通用实时数据库，该软件在全面总结国内外同类产品优缺点的基础上按照智能电网、工业自动化系统以及物联网特点和实际需求精心设计、潜心研制而成，是进行海量历史/实时数据处理的专业平台。 （下转第249页）

（上接第155页）3.海迅实时数据库与PI实时数据库的对比

以下为PI和瑞中的海迅数据库在服务器端模块部署方式，性能指标、组态工具、应用领域、市场占有率等方面的对比介绍。

海迅数据库有着分布式体系架构和跨平台特性，让它在各厂商的实时数据库产品中格外突出。分布式体系架构使得它能支持更多的测点容量，达到更高的性能。跨平台特性使它的应用领域更广泛，使用更安全高效。

篇10

关键词：云计算 数据模型 云数据库 NoSQL数据库

0 引言

从2006年Google提出“云计算”的概念至今，云计算正以史无前例的速度发展，国内外各大IT企业都在开署各自的云计算平台，云计算的应用更趋多样化，目前在互联网上我们看到的很多应用都可以看到“云”的身影，诸如“云存储”、“云安全”、“云物联”、“云邮件”、“云输入法”等等。总的来说云计算包括三个层次的服务：基础设施即服务（IaaS），平台即服务（PaaS）和软件即服务（SaaS）。云服务模式实现了资源集中配置和管理，实现按需采购、配置，避免资源浪费，能够更好满足用户不断变化的需求。同时降低管理维护成本，随着云计算技术的不断发展，系统的可靠性、扩展性、稳定性也会更好，云计算将影响传统数据库的发展趋势，云服务模式将逐步得到市场认可，反过来讲，传统数据库必须能更好适应云计算环境的需求。传统的关系型数据库由于其天生的限制，已经越来越无法满足目前时代的要求，云计算时代对数据库技术提出了新的需求，主要表现在海量数据处理，大规模集群管理，低延迟读写速度，建设及运营成本。虽然它在数据存储方面占据了不可动摇的地位，但对数据扩展、读写速度、支撑容量以及建设和运营成本的要求方面，就稍显逊色。下面我们来探讨适应于云计算的数据库所支持的数据模型。

1 云数据模型的类型

无论是关系型数据库还是非关系型数据库，都是某种数据模型的实现，不同的数据模型可以满足不同的应用需求。数据模型会影响客户端通过API对数据的操作，决定了客户端如何对数据进行编码存储。云数据库的设计可以采用不同的数据模型，目前适应于云计算平台的数据模型有以下几类：

1.1 基于云计算的关系模型。关系型云数据库的数据模型涉及行组和表组等相关概念。此模型的数据结构为一个表是一个逻辑关系，它包含一个分区键，用来对表进行分区。具有相同分区键的多个表的集合称为表组。在表组中，具有相同分区键值的多个行的集合称为行组。一个行组中包含的行总是被分配到同一个数据节点上。每个表组会包含多个行组，这些行组会被分配到不同的数据节点上。一个数据分区包含了多个行组。因此，每个数据节点都存储了位于某个分区键值区间内的所有行。微软的SQL Azure云数据库就是基于此模型的。

1.2 NoSQL数据库数据模型。由于在设计上和传统的关系型数据库相比有很大的不同，故称此类数据库为“NoSQL（Not only SQL）”系列数据库，即非关系型的数据库。与关系型数据库相比，此类数据库非常关注对数据高并发读写和海量数据的存储，在架构和数据模型方面做了简化，而在扩展和并发等方面做了增强。此类数据库种类繁多，且各有优缺点，其数据模型有如下四类：①键值（key-value）存储模型。使用一个哈希表，这个表中有一个特定的键和一个指针指向特定的数据。其数据模型为一系列的键值对。它能提供非常快的查询速度、大的数据存放量和高并发操作，非常适合通过主键对数据进行查询和修改等操作，缺点是存储的数据缺少结构化，不支持复杂的操作。运用此模型的数据库有BigTable、Tokyo cabinet/Tyrant、Redis、Voldmort、Berkeley DB等。②列式存储模型。列式存储和关系模型相似，与关系模型存储记录不同，列式存储以流的方式在列中存储所有的数据。其数据模型为以列簇式存储，将同一列数据存放在一起。属于同一列的数据会尽可能地存储在硬盘同一个页中，而不是将属于同一个行的数据存放在一起。使用列式数据库，将会节省大量I/O，并且大多数列式数据库都支持Column Family这个特性，能将多个列并为一个小组。总体而言，这种数据模型的优点是查找速度快，可扩展性强，更容易进行分布式扩展，缺点是功能相对局限。运用此模型的数据库有Cassandra、HBase、Riak等。③文档模型。在数据结构上，文档型和键值型很相似，也是一个key对应一个value，但是这个Value主要以JSON或者XML等格式的文档来进行存储，是有语义的，并且文档数据库一般可以对Value来创建Secondary Index来方便上层的应用，而这点是普通键值数据库所无法支持的。这种数据模型的优点是对数据结构要求不严格，缺点是对查询性能不高，而且缺乏统一的查询语法。运用此类模型的数据库有MongoDB、CouchDB等。④图形模型。图形结构的数据库同其他行列以及刚性结构的SQL数据库不同，它是使用灵活的图形模型，并且能够扩展到多个服务器上。其数据模型为图结构，其优点是可以很方便地利用图的相关算法，缺点是需要对整个图做计算才能得出结果，不容易做分布式的集群方案。运用此类模型的数据库有Neo4J、InfoGrid、Infinite Graph等。数据模型有着各自的优缺点，它们适用于不同的领域。不管选择关系模型，还是非关系模型，都要根据实际应用的场景做出选择。有时候单一的数据模型并不能满足我们的需求，对于许多大型的应用可能需要集成多种数据模型。