关系数据库范文

关系数据库范文第1篇

【关键词】关系数据库；非关系数据库；NoSql

前言

从上个世纪60年代至今的半个世纪，数据库技术伴随着信息技术的发展不断发展，到目前共经历了人工管理阶段、文件系统阶段和数据库系统阶段，在数据库系统阶段又经历了网状数据库、层次数据库和关系数据库阶段，进二十来年，关系数据被广泛使用，发展成主流，但随着互联网技术的蓬勃发展，关系数据库使用遇到了一些新的问题，为应对这些新的问题，近两年来非关系数据库NOSql越来越引起人们的注视，得到了快速发展。

1 关系数据库

1.1 关系数据库的简介

支持关系模型的数据库系成之为关系数据库，是目前各类数据库中使用最为广泛的数据库系统。关系数据库在经过二十几年的发展，已经变的功能强大，使用广泛，产品成熟的数据库系统，现在使用主流的数据库都为关系型数据库，比较熟悉的如SQL Server、Mysql、Oracle、Sybase、Informix、DB2等。在网络上使用比较广泛的是Sql Server、Mysql和Oracle。

1.2 关系数据库的特点

关系数据库是支持关系模型的数据库系统。而关系模型是由二维表来表示实体和实体间联系的模型。使用二维表存储数据，对使用者来说很直观，更容易理解。使用关系数据库的优势主要表现在以下几个特性：

（1）操作方便性。通过开发应用程序和数据库连接，用户能方便的对数据库中数据进行操作，特别对没有数据库基础的人，也可以通过数据库管理系统，直接在数据库中操作。

（2）易于维护性。关系数据库在完整性约束中提供了实体完整性、参照完整性和用户定义的完整性，通过完整性约束可以大大降低了数据存储的冗余及数据不一致的概率。

（3）访问数据的灵活性。关系数据库中提供了诸如视图，存储过程，触发器，索引等对象，是访问数据更加灵活。

1.3 目前关系数据库面临的问题

随着互联网技术的发展，尤其是web2.0 技术使用，更注重用户和服务器以及用户和用户之间的交互作用，用户成为既是网站内容的浏览者，也是网站内容的制造者。例如：博客（BLOG）、社会网络（SNS）、以及现在比较热的微博等。对于在使用web2.0技术并且访问量比较大网站，使用传统关系数据库就会遇到一些问题，主要表现在以下几点：

（1）对数据库高并发读写的需求

Web 2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，无法使用动态页面静态化技术，因此数据库的并发负载非常高，往往要达到每秒上万次的的读写请求，此时服务器上的磁盘根本无法承受如此之多的读写请求。

（2）对海量数据的高效率存储和访问的需求

对于大型的社交网站网站，每天用户产生海量的用户动态，随着用户的不断增减，一个数据表中的记录可能有几亿条，对于关系型数据库来说，在一个有上亿条记录的表里面进行SQL询，效率是极其低下的。一些大型Web 网站的用户登录系统也是如此，如腾讯、163邮箱都有数亿的帐号。

（3）对数据库的高扩展性和高可用性的需求

在基于Web的架构中，数据库是最难进行横向扩展的，当用户量和访问量增加时， 数据库没有办法像Web Server 那样简单的通过添加更多的硬件和服务结点来扩展性能和负载能力，对于很多需要24 小时不间断服务的网站来说，对数据库系统的升级和扩展往往需要停机维护。

2 非关系数据库NoSql

2.1 NoSql概述

NoSql是应对关系数据库出现的问题而发展起来的，近几年随着web2.0技术的广泛应用，NoSQL 得到了快速的发展，NoSQL数据库指的是非关系性的、定义不是很明确的数据存储仓库。NoSQL数据库不再使用关系模型的概念，放弃了使用SQL语句对数据库进行操作。

NoSQL 数据库根据数据的存储模型和特点又分为很多种类。主要有

（1）面向列的存储系统。按列存储，区别于关系数据库中按行存储，容易扩展，适用与存储海量数据，对一个或几个字段进行查询的效率很高，但在复杂查询功能比较弱，如多表联合查询。此类数据库产品有BigTable、Hbase、assandra和Hypertable。

（2）面向文档存储系统。保证海量数据存储的同时，具有良好的查询性能。用JSON或类JSON格式进行存储，存储的内容是文档型的，文档中的格式是自由的。此类数据库产品有MongoDB和CouchDB。

（3）键-值（key/value）存储系统。是最简单的Nosql系统，具有极高的并发读写性能。通过key能够快速查询到value，并且不考虑value 的格式。此类数据库产品有Tokyo Cabinet/Tyrant、BerkeleyDB、MemcacheDB和Redis。

（4）图存储系统。图形关系的最佳存储模式。如Neo4J、FlockDB。

（5）对象存储。类似面向对象语言的语法操作数据库，通过对象的方式存取数据。此类数据库产品有db4o、Versant。

（6）xml 数据库。高效存储XML 数据，并支持XML的内部查询语法。此类数据库产品有Berkeley DBXML、BaseX。

2.2 NoSql数据库的优势

相对于关系数据库，Nosql数据库的优点主要表现在：

（1）容易扩展和高性能。NoSQL 数据库种类很多，但是都有一个共同的特点就是去掉关系型数据库的关系型特性。数据之间彼此无关系，这样就非常容易扩展。可以存储海量数据。同样由于数据之间无关系，数据库的结构简单，在处理大数据量时，NoSQL 数据库会有出色的读写性能。

（2）灵活的数据模型。NoSQL 数据库不使用传统的关系数据库模型，而是使用如key-value 存储、文档型的、列存储、图型数据库、xml 等方式存储数据模型，使用这些模型都无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。同时根据需求可以选择合适的模型。

（3）经济性

在数据量和访问量比较大的情况下，传统的关系数据库对服务器的要求比较高，甚至使用专用硬件设备，这样造价就比较高。而NoSQL数据库的易扩展的特点使配置较低服务器上运行，也可以使用低配服务器组成集群来使用，并且有研究证实使用NoSql数据库基于低配硬件的分布式存储解决方案比现在的高端关系数据库更加可靠。这样就极大的降低了投资成本。

2.3 NoSql的不足

（1）成熟度方面。NoSQL数据库的实际应用，近几年才逐渐开始使用，并且大部分NoSQL的产品都还处于实验和不断完善的阶段。在产品成熟度和稳定性方面，NoSq数据库远不及发展了二十多年且已被广泛使用的关系数据库。

（2）商业支持方面。大部分NoSQL数据库都是开源项目，没有专门的数据库厂商提供完善的服务，一旦出现故障，只能自己的能力解决，对于一般使用者来说风险比较大。

（3）使用习惯方面。软件开发人员已经习惯了关系数据库的模式，解决问题的思路已经被固定在关系模型上，而NoSQL数据库的开发以放弃了关系模型，要软件开发人员放弃原来的思路，而掌握和使用NoSql数据库是很困难的，导致使用NoSQL数据库的开发人员不可能在短时间内快速增加，这也成为NoSql数据库发展的一个障碍。

3 关系数据库与NoSQL 数据库结合使用

Web2.0时代，关系数据库不能满足对数据库高并发读写、海量数据的高效率存储和访问、高扩展性和高可用性方面的需求，而NoSql数据库可以解决这些问题，从而推动了NoSql数据库应用和发展，那是不是说NoSql数据库就能取代关系数据可了呢？从目前来看，基于NoSql数据库的不足，NoSql数据库还不能完全取代关系数据库，对NoSql数据库的使用，单独使用的情况很少，大多数情况下都是关系数据库和NoSql数据库结合使用。

关系数据库和NoSql数据库结合使用又分为两种模式：

（1）NoSql数据库作为辅助存储。在这种模式下，把所有的数据都存放在关系数据库中，可能被经常频繁读取的数据再存放在NoSql数据库中一份，其目的是提高数据的查询速度，减少关系数据库的并发访问负载。

（2）NoSql数据库作为主存储。在这种模式下，把所有的数据存储在NOSQL数据库中，为了一些特殊业务或功能的需要，在将数据存入NOSQL 的时候，同时存储到关系数据库一份。在数据存储和查询主要是由Nosql数据库完成，少量的数据是从关系数据库读取。

4 结语

目前关系数据库仍是主流数据库，仍被广泛使用，NoSQL数据库还不能完全取代关系数据库，虽然NoSql数据库打破了关系数据库存储的观念，采用创新的存储方式，在快速读写、海量存储，高扩展性上很好满足web2.0时代数据存储的要求，但NoSql数据库也有自己的缺陷。在现阶段的某些情况下，可以将关系型数据库和NoSQL数据库结合使用，相互弥补各自的不足。随着NoSql数据库的不断发展和完善，将来也有可能取代关系数据库成为主流数据库。

参考文献：

[1]卢冬海，何先波.浅析NoSQL数据库 中国西部科技 2011年02期

[2]黄贤立.NoSQL 非关系型数据库的发展及应用初探 福建电脑 2010年7期

关系数据库范文第2篇

关键词：工作流技术；Notes数据库；关系数据库；转化方法

中图分类号：TP311文献标识码：A文章编号：1009-3044(2012)05-1002-02

A Brief Analysis of the Relationship between Notes Databases and Relational Databases

YE Hao-bo

(City College of Dongguan, University of Technology, Dongguan 523106, China)

Abstract: With the wide application of office automation system, the Notes database technology has become a hot issue for it’s suitable for office automation system workflow. This paper analysis the relationship between the Notes database and the relational database and their re? spective advantages at first; then desribe the transformation method between the Notes database and the relational database from the applica? tion angle.

Key words: workflow technology; notes databases; relational databases; transforming method

在科技不断发展的今天，办公室人员的工作已经发生了较大的变化，已经从原来的数据与文件为中心的个人独立工作方式发展到了以工作流为核心的团队工作上。现代化的办公体系正朝着高速的信息处理、统一的工作流程、先进的知识管理为一身的知识型方向发展，所以现代化办公自动化（OA）系统在现代化的企业管理中发挥的着越来越重要的作用。

OA系统的后台数据库产品有很多，从目前的软件开发的情况来看，主流产品是IBM的Notes数据库，正因为如此，Notes数据库已经成为大家关注的热点问题，而在办公自动化系统里有一部分功能的实现需要用到关系数据库，这两种数据库之间的关系及他们之间的转化方法是怎的呢？本文下面将作一个简单的分析。

1工作流技术

从OA系统的发展过程来看，我们可以清楚的认识到，办公自动化系统的核心技术是工作流技术。那么什么是工作流技术呢？它是在一个工作群组中，为了一个共同的目的或者某种任务，在这个群组的人员需要共同协作地去完成某一项工作，工作的方式可以是按先后顺序或者同时进行。它包含一组活动、活动之间的内在关系、活动开始和结束的条件、活动的功能描述等内容。概括来说，它是一个电子化的办公流程，能方便地处理办公系统中文档的收发、传递、审阅等操作。把工作流技术用在OA系统中可以对现代化管理提供帮助：

第一、它可以加强事务处理的各个环节的协同工作的能力，从而可以让工作的运作的非常通畅。

第二、工作流技术将各项事务的管理由原来的人工管理转变为工作流服务器来管理，所以办公人员可以从大量的繁琐的工作中解脱出来，从而可以将工作重点转换到怎么更好地做好事件。

第三、工作流技术对工作流程重组提供了非常实用的技术支持和分析方法。在快速发展的当今社会，管理水平和技术水平都在日益更新，对于办公室的工作流程发生变化的机会也在增多。所以办公自动化系统应该能够快速适应这种动态的变化。一般传统的技术或者方法不能适应这种变化，可是工作流技术和OA系统的结合就能很快适应这种动态变化，从而实现企业的协同办公。

2关系数据库与Notes数据库的比较与转化方法

2.1关系数据库和Notes数据库的比较

Notes数据库：它主要是以存储文本文档为其主要内容的数据库管理系统，也就是说它的数据的元组就是文本文档，是一种非数值型的数据。但是这种非数值型（非结构型）的数据对于Lotus Notes处理起来更为方便，如视频、声频、传真、OLE对象、图形、页面、表格等数据类型Notes处理起来会灵活一点。

对于数据的访问，Lotus Notes是通过全文检索方式访问数据库的数据，对于检索定位方面，Lotus Notes是通过视图定位数据的方式。

关系数据库：它是一个数值型的DBMS，主要通过数学公式来处理数据，所以对于一个事务型的流程，它必须先将其转化为严格 的数学公式以后，才能在数据库上进行处理，数据库中的表实际就是一张二维表，关系型数据库对一些结构化（数值型）的数据处理起来相当快捷。

对于数据的访问，关系型数据库是通过SQL语言访问数据库的数据，对于检索定位方面，关系型数据库是通过实时查询来定位数据。

通过上述的比较，两种数据库各有各的优势，而在办公自动化系统中有一些部门可能会用到一些复杂计算、数据处理等方面的功能，我们知道这些都是Notes不太善长的地方，又加之现在的JSP、ASP等脚本语言访问关系型数据库是十分方便的，所以要是能将两种数据库进行相互转化就能解决系统中的问题，下面本文介绍在本系统中他们之间的转换方法。

2.2两种数据库之间的转化方法

2.2.1 Notes数据库转化为关系数据库

为了与其他的管理信息系统进行信息的交换，在Notes数据库管理系统里面有一套专门针对和外部程序数据的扩展类库，也就是Lotus Script Data Object，，这套扩展类库由三个基本的类构成的一个整体，它们分别是ODBC Result Set、ODBC Query和ODBC Connection，通过他们来完成与外部数据之间的访问和修改，由于它所使用的标准是ODBC，就通过这样的标准来读取的修改外部数据库的数据的属性和相应的方法。这三种类主要分工是这样的，ODBC Connection是负责与外部数据库之间的连接，ODBC Query主要用于一个结构化查询语言语句的定义，而ODBC Result Set主要用于在通过SQL语句查询结果数据集上执行相应数据读取的操作，在数据库中我们主要利用RTF域存放Notes文档数据，而对于RTF域来说，我们可以在数据库的表单的任何位置放置它，正是因为RTF域可以包含无限制的数据的特点刚好可以满足文本的特性，所以对于文本中包含有图片、文字、独立的文件、甚至可以是一些对象。在关系型数据库中常处理的一些数据，如文件的名字、生成的时间、文字、日期等我们可以在关系型数据库直接处理。对于每一个程序文档完成后就执行QuerySave，使用Lotus脚本语言编写子程序模块QuerySave将查询的信息数据写到关系型数据库中。

综上所述，Notes数据库转化为关系数据库可以是以下几个过程；

第一步就是要创建三个类：即ODBC Connection、ODBC Query、ODBC Result Set；

第二步就是数据库的连接，即用ConnectTo函数连接到SQL数据库，同时使用查询语句进行查询操作；

第三步就是将查询的qry. Sql和结果集相连接，执行有关函数如result.execute查询到关系数据库中的情况，当result.currentrow等于零的时候，则可以写入新一批的数据，李不然就修改数据。

2.2.2关系数据库转化为Notes数据库

在Notes数据库中我们采取ODBC标准来访问各种不同数据类型的信息，我们可以利用Notes的内部函数或者相应的脚本语言，就可以将关系数据库中的有关数据写入到Notes文档中，把这些数据变换为Notes数据，我们具体的方法有两种：

方法一：将@Db函数引入到Notes有关的函数当中。Notes内部有三个函数，即@DbCommand、@DbLookup和@DbColumn，只要在上述函数在第一个参数使用了“ODBC，这样就是读取有关的关系型数据库中的表，这种方法也有很明显的不足之处，它对于信息的提取只能以列的方式进行，不能以行的方式进行。

方法二：采用Lotus Script数据对象LSX，同时利用Lotus脚本语言编写相关的数据读取函数，在Notes里面的ODBC Connection、ODBC Query、ODBC Result Set就是使用ODBC标准来读取外部的各种不同的数据。

上面两种方法进行比较，作者认为第二种方法更为科学，下面就简单谈谈这种方法的实现过程：

首先，在Notes数据库中，我们按照SQL数据库相应表单里的结构同样建立一个一样结构的表单，这样做的好处就在于能够将关系型数据库中的数据进行一一转换，并且容易理解，然后就建立相关的，用脚本语言写相应的转换程序；

然后，创建视图来执行上述的，从而可以实现将关系型数据库中有关的数据表单转换成notes数据库中的信息。

3结束语

本文在上面的叙述当中我们可以发现在OA系统的开发过程中，只要处理好数据库，就可以做到有的放矢，这就是说，我们可以根据系统的要求，在需要使用Notes数据库的模块里就Notes数据库，在需要使用SQL数据库的地方就使用关系型数据库，通过相应的转换办法，就可以实现它们之间的数据共享。

参考文献：

[1]秦佩君,杨学良.工作流技术在办公自动化系统中的应用[J].计算机工程与设计,2001(3).

[2]熊伟清,魏平.Lotus/domino/Notes的工作流技术剖析[J].计算机应用研究,2001(12).

关系数据库范文第3篇

摘要：XML可以用于实现异构数据库，同时也是一种中间件和数据承

>> XML文档与关系数据库数据转换的研究 基于DOM的XML文档到关系数据库的数据转换方法 基于关系数据库的XML存储技术 浅谈数据库记录与XML数据的转换 论XML文档数据库数据之间的转换原理及转换对象 基于．NET平台的关系数据库转换 WebService在LDAP与关系数据库之间数据同步的研究 基于XSD模式的XML文档与关系数据库的转换 一种模仿XML的灵活的关系数据库设计 基于关系数据库的时态XML存取研究 运用XML实现异构数据库的数据转换 浅析Notes数据库与关系数据库的关系 关系数据库的设计与测试 基于架构的关系数据库与云端数据库比较分析 XML文档与数据库表信息互相转换的方法研究与实践 关系数据库与非关系数据库 浅析关系数据库、数据仓库与数据挖掘的关系 浅谈关系数据库的数据保护策略 关系数据库查询优化策略与研究 关系数据库二进制存储图像数据的研究与应用 常见问题解答 当前所在位置：，1994.

[2]陈志炜.一种基于语义的将关系数据转换为XML数据的方法[D].南京：东南大学硕士学位论文，2004.

[3]萨师煊，王珊.数据库系统概论[M].第三版.北京：高等教育出版社，2005.

收稿日期：2016-11-25

基金项目：辽宁省普通高等学校优势特色专业（本科教改项目）；大连海事大学研究生教改项目（YJG201600）

关系数据库范文第4篇

关键词：非关系数据库；CouchDB；Map/Reduce

中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2013）14-3220-03

随着以社交网络、云计算为代表的Web2.0网站的兴起，非关系数据库（NoSQL）得到了广泛的关注[1-2]。这是因为传统的关系数据库在面对这类应用的时候暴露出许多问题，在处理超大规模的数据、应对高度并发的请求时显得力不从心。这种情况下非关系数据库得到了迅速的发展，成为业界和学界所探讨的热点问题。

CouchDB是在处理半结构化的文档中具有独特的优势，在CMS系统、大数据分析和挖掘中具有广泛的用途。该文首选对非关系数据库的特征及Map/Reduce的工作方式进行分析，然后详介绍了CouchDB的安装、配置及使用方法。

1 非关系数据库

1.1 非关系数据库的特点

非关系数据库是根据Web应用发展的需要而产生的，与传统关系数据库有很大的差异。关系数据库最为显著的是ACID特性，即原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。从分布式应用的CPA理论[3，4]的角度来看，关系数据库主要关注的是一致性和可用性，能够很好的满足传统的应用需求。但是在Web2.0时代，对数据处理的要求高并发性、海量数据的处理能力和访问需求，以及对数据库的高扩展性和高可用性要求。相对而言，关系数据库所关注的一致性、读写的实时性和复杂的SQL查询在新的应用中却并不需要[5]。

CPA理论认为一致性、可用性和分区容错性不可能同时实现。因此非关系数据库的主要特征为与ACID有着显著差异的BASE模型[6]。即基本可用（Basically Available）、软状态（Soft state）和最终一致（Eventually consistent），它允许系统在一段时间内有不一致性，而放宽至只要最终状态下数据是一致的就可以了，从而以牺牲高一致性为代价获得了高可用性。由于非关系数据库没有数据库模式的约束，从而具备了良好的可扩充性。

1.2 Map/Reduce机制

Map函数的输出为数据库中的文档或数据，输出为键值对。这里的键和值可以是系统支持的任何类型的数据，用户可以在Map函数中对文档数据加以处理，把所需的数据以键值的形式输出。Map函数会对数据库中所有数据进行处理，结果由主控制器按键进行分组，如果用户不指定Reduce函数则按键分组的结果直接输出。Reduce函数的功能是把键值组合进一步处理，比如统计、汇总等。

2 CouchDB的安装及应用

2.1 CouchDB简介

CouchDB是最著名的非关系数据库系统之一，它是Apache软件基金会的顶级开源项目。CouchDB使用Erlang语言开发，继承了其强大的强大的并发性和分布式的特征，因此在大数据处理及诸如社交网络等Web2.0应用开发中具有重要的应用价值。CouchDB的早期版本只能安装在POSIX系统之上，最新版本则提供了对Windows的支持。

CouchDB是一个面向文档的、分布式的数据库，支持REST接口访问。面向文档是指CouchDB中存储的是半结构化的JSON文档，而且可以方便的将文档对象映射为具体编程语言的对象。由于JSON在Ajax技术及社交网络应用中广泛应用，因此CouchDB在这类应用的数据存储和处理中具有良好的应用前景。CouchDB是分布式的数据库系统，源于Erlang极好的并发特性，CouchDB存储系统可以分布到多台计算机之上，每台计算机称为存储系统的一个节点。CouchDB能够很好的协调和同步多个节点之间的数据一致性和完整性，有效的应用系统应用中可能出现的各种错误。CouchDB支持REST接口访问，即可以通过GET、PUT、POST、HEAD和DELETE等标准的Http请求对数据库进行写入和查询分析等操作。因此，任何一种编程语言只要具备Http请求模块就可以方便的与CouchDB进行对接，甚至只要利用正确的URL地址只要运用浏览器就可以访问CouchDB得到所需要的数据。

与其他的非关系数据库一样，CouchDB利用Map/Reduce对数据进行插入、搜索等操作。CouchDB将键值对存储在B-树引擎之上，并根据键值进行排序，因此具有高效的查询和操作性能。需要注意的是，CouchDB是一个基于版本的数据库系统，即只能添加数据不能删除和修改数据，当数据需要更新时CouchDB只是增加了新的版本，所有的版本数据依旧保存在数据库中，且可以方便的得到。如果要删除数据则需要将整个数据库删除。

2.2 CouchDB的安装和配置

CouchDB在包括Windows在内的各种操作系统中安装都非常方便，几乎不需要做任何复杂的配置，特别是在Mac OS中，下载之后直接运行即可。CouchDB默认使用5984端口，在本机可使用http：//127.0.0.1：5984访问。在浏览器中访问该Url即可得到关于版本等信息的JSON格式的数据。CouchDB的管理控制台称为Futon，通过http：//127.0.0.1：5984/_utils访问并操作。在Futon中可以手工创建数据库、添加和查看文档，并管理CouchDB。默认情况下，CouchDB开放admin权限，为了安全起见需要添加用户名和密码。

2.3 CouchDB的操作

3）统计和汇总

对CouchDB进行更复杂的查询需要同时使用map函数reduce函数。图5所示的代码对数据库文档数量进行统计，程序运行输出结果为数据库中文档的总数。如果数据库中仅有图2所加入的数据，则图5输出结果为2。如果要进行汇总操作，只需改变map函数返回值为需要汇总的数值，并根据需要改变group参数的值为True。

结合map函数和reduce函数，可以在CouchDB数据库中实现传统关系数据库中的运算，如选择、投影、并、交、差，以及连接等。此外，与传统数据库一样，CouchDB也可以利用ViewDefinition将查询保存为视图，其使用参数与query较为类似。不同的是视图的信息要保存在设计文档之中，因此要指定相应的键值，在使用中，数据库根据这些键值生成url用于进行访问。

3 结论

CouchDB作为一种高性能的面向文档的非关系数据库具有广泛的用途，其开源、免费，以及易用使用的特点使其在Web2.0应用开发、大数据挖掘与分析等方面都有潜在的重要应用价值。该文对CouchDB的应用的分析，有助于深入了解非关系数据库的工作机制和使用方法。需要指出的是，尽管非关系数据库在处理大数据方面有很高的效率，但是它绝不是关系数据库的替代，在数据更新频繁的传统应用中关系数据库依旧是最优的选择。

参考文献：

[1] 蔡金花.浅析NOSQL及使用[J].电脑知识与技术，2012，7（12）：2757-2758.

[2] 柯栋梁，郑啸，李乔.云计算：实例研究与关键技术[J].小型微型计算机系统，2012，33（11）： 2321-2329.

[3] Brewer E A.Towards Robust Towards Robust Distributed Systems[C].Proceedings of the 19th Annual ACM Symposium on Principles of Distributed Computing， 2000.

[4] Gilbert S，Lynch N.Brewer's Conjeture and the Feasibility of Consistent， Available， Partition-Tolerant Web[J]. ACM SIGACT News， 2002， 33（2）：51-59.

[5] 范凯.NoSQL数据库探讨之——为什么要用非关系数据库？[EB/OL].（2009-11-25）. http：///topic/524977.

[6] Pritchett D. BASE：An Acid Alternative[J]. Queue - Object-Relational Mapping，2008， 6（3）：48-55.

关系数据库范文第5篇

【关键词】关系数据库；数据仓库；数据挖掘；关系

0 引言

关系数据库是20世纪70年代初提出来，经过数据库专家几十年的努力，理论和实践都取得了显著成果，标志着数据库技术的日益成熟。但它仍然难以实现对关系数据库中数据的分析，不能很好地支持决策，因此在80年代，产生了数据仓库的思想，90年代，数据仓库的基本原理、架构形式和使用原则都已确定。主要技术包括对数据库中数据访问、网络、C / S结构和图形界面，一些大公司已经开始构建数据仓库。针对数据仓库中迅速增长的海量数据的收集、存放，用人力已经不能解决，那么数据仓库中有用的知识的提取就需要数据挖掘来实现。数据挖掘与统计学子领域“试探性数据分析”及人工智能子领域“知识发现”和机器学有关，是一门综合性的技术学科。了解关系数据库、数据仓库与数据挖掘三者之间的区别与联系，使之更好的使用这3种技术，处理各种信息需求是非常必要和重要的。

1 关系数据库、数据仓库和数据挖掘之间的关系

1.1 关系数据库和数据仓库之间的联系与区别

关系数据库是面向事务的设计，数据仓库是一个面向主题的设计；关系数据库存储在线事务数据，数据仓库通常存储历史数据，关系数据库的设计将尽量避免冗余，但数据仓库是倾向于引入冗余；关系数据库设计用于捕获数据，数据仓库设计用于分析数据。传统的关系数据库面向以事务处理为主的系统应用，所以它无法满足决策支持系统的分析要求。事务处理和分析处理有非常不同的性质，他们有不同的需求数据。

1.2 数据仓库与数据挖掘之间的联系与区别

数据挖掘是基于数据仓库和多维数据库中的数据，找到数据的潜在模式进行预测，它可以对数据进行复杂处理。大多数情况下，数据挖掘是让数据从数据仓库到数据挖掘数据库中。从数据仓库中直接得到进行数据挖掘的数据有许多优点，因为数据仓库中数据的清理和数据挖掘中几乎是相同的，如果数据在数据仓库中已被清除，数据挖掘中不再被清除，并且数据不一致也得到了解决。数据仓库是数据挖掘的先期步骤，通过数据仓库的构建，提高了数据挖掘的效率和能力，保证了数据挖掘中的数据的宽广性和完整性。

1.3 关系数据库与数据挖掘之间的联系与区别

数据挖掘的数据源不一定是数据仓库。也可以是一个关系数据库中的数据，但要事先进行数据预处理，才能用于数据挖掘。数据预处理是数据挖掘的关键步骤，并且是数据挖掘过程中的主要工作部分。因此，数据仓库和数据挖掘没有必然的联系，有些人简单地认为，数据仓库是数据挖掘的准备，这种理解是不全面的，也可以使用关系数据库中的数据作为数据挖掘的数据源。

2 三种技术的应用

2.1 应用价值

2.1.1 关系数据库

关系数据库的主要价值体现在事务处理。关系数据库已经渗透到各行各业的日常事务，该事务管理离不开关系数据库的应用系统，这是对传统事务管理的一个重大突破，是社会甚至家庭不可或缺的工具，它对社会的应用价值是100%。

2.1.2 数据仓库

数据仓库的主要价值体现在为决策分析提供数据源。一方面，在一个事务中，用户要求高效的访问系统和数据库，操作时间应该短。在一个决策分析中，决策问题的一些请求可能会导致系统的操作，解决这一问题的决策分析需要遍历大多数数据库中的数据，这对一般日常事务处理系统是困难的，所以操作数据和决策分析数据应该分开。另一方面，决策数据需求问题。在决策分析时，由于不同的应用系统中，实体、字段存在数据类型、名称和格式的不符，需要在集成时进行转换，这个转换必须在决策之前完成；一些决策数据需要动态更新，需要经常进行汇总和总结，这些需求用事务处理系统解决比较繁琐。三是数据的操作模式问题。决策分析人员要以专业用户身份，使用各种工具以各种形式来操作数据，对数据操作的结果以商业智能的方式表达出来。事务处理系统不能满足这一要求，只有数据仓库系统能够满足数据挖掘技术对数据环境的要求，所以使用数据仓库中的数据省去了对数据预处理的步骤。

2.1.3 数据挖掘

面对日益激烈的市场竞争，客户对迅速应答各种业务问题的能力要求越来越高，对过量数据的及时处理要求越来越高，带来的挑战一方面大规模、复杂数据系统让用户感觉漫无头绪，无法开始；另一方面，这些大量数据背后隐藏很多有意义的有价值的决策信息。如计算机界都熟知的“啤酒与尿布”的故事，就是零售业巨头“沃尔玛”从大量销售数据中分析出来的规律：美国的男士在下班要去超市买婴儿尿布，同时他们还会买啤酒。“沃尔玛”就把这两种“毫不相干”的商品摆放在靠近的货架上，并且还摆放一些下洒小菜，使这些商品销量大增。所以应用数据挖掘从大量数据中发现规律，具有具体的指导意义。

2.2 应用领域

2.2.1 关系数据库

关系数据库应用领域非常广泛，如：证券行业、医院、银行、销售部门、公司或企业，以及政府、国防工业，科学和技术发展领域等等，这些领域都需要使用数据库来存储数据。例如：人事管理系统、工资管理系统，xxx部门信息管理系统，手机话费管理系统等，都需要关系数据库作为后台提供数据源。

2.2.2 数据仓库

数据仓库应用领域主要有两个方面：一是全局应用。因为数据仓库获得来自多方面的数据，所以在把数据向数据仓库输入时，要进行转换、计算和综合等集成处理。通过处理把来自不同地方的数据源转换成统一的格式，以促进全局应用。二是复杂系统。信息处理的要求越来越复杂，除了数据处理操作，如添加、删除、修改、和统计汇总，高级管理层也希望对历史的和现在的数据进行各种复杂性分析，以支持决策。数据仓库中就是存储了旧的历史数据，方便复杂分析、应用，为高层决策服务。

2.2.3 数据挖掘

数据挖掘的应用领域主要表现在特定应用问题和应用背景。数据挖掘技术已经应用于各行各业，如电信，保险，交通，学校、银行、超级市场等。例如：数据挖掘技术应用在大学。高校扩招，学生增加到几万人，但是学生的学习积极性不高，成绩不好，因此引入数据挖掘技术找出影响学生学习积极性和学习成绩的原因，制定措施，提高教育和教学质量。分析的数据源是考试成绩和成绩之外的影响因素，分析的方法是采用关联规则、模型库、去“噪”处理、粗糙集等进行数据挖掘，得出的结论是：传统的学习方法不能完全满足需要，改进教学方法和教学模式，从而调动学生学习的积极性，提高教学质量。

3 关系数据库、数据仓库与数据挖掘的融合

日常事务处理需要关系数据库，构建分析处理环境需要数据仓库，帮助决策者寻找数据之间的潜在的关联需要数据挖掘。他们之间是相互联系又有区别的，不能互相取代的，又需要相互融合。数据仓库中的数据并不是最新的，专有的，而是来源于其他关系数据库，它是建立在一个更全面和完善的信息应用的基础上，用于支持高层决策分析的数据基地。数据仓库是数据库新技术，到目前为止，数据仓库仍用关系数据库管理系统管理数据。数据挖掘是从大量存储在数据库、数据仓库或其他信息库中发现有趣知识的过程。只有这三个数据库技术互相融合，取长补短，各尽其责，才能更好的为广大用户所使用，为社会各个领域所应用。

【参考文献】

[1]华冠萍.数据仓库、数据挖掘及OLAP之两两关系[J].福建电脑，2007，8.

[2]牛承珍.马季兰.浅谈数据挖掘应用[J].山西科，2008.5.20.

关系数据库范文第6篇

关键词：XML；关系数据库；数据存储；存储策略

中图分类号：TP311　文献标识码：A　文章编号：1009-2374(2011)07-0088-02

在信息技术与网络技术高速发展的今天，网络已经成为新一代操作平台。信息正全面地以互联网方式展开，互联网的信息传播，极大地加速了人类发展的进程。随着WEB技术的日益发展，WEB已经成为信息制造、、加工和处理的主要平台。XML技术已日益受到更为广泛的关注，已经在电子商务、电子数据交换、科学数据表示、数据建模与分析和搜索引擎等领域有着广泛的应用。随着XML应用技术的深入，将会有大量的XML文档出现，并且现在在网络上已经积累了大量的XML文档。本文主要就基于关系数据库的XML存储技术相关问题进行探讨。

一、XML与关系数据库结构上的差异

XML文档是半结构化的数据，是一个树模型，如果考虑到XML元素次序，则是一棵有序树模型，其数据结构是非结构化的，而关系数据库管理系统是采用二维表格作为存储数据的模型，表格由行和列组成，列被称作“字段”用于表示组成数据有效信息的属性，行则用于储存一条完整的数据记录。XML数据与关系表之间数据结构有很大的差异，具体来说，XML数据是有序的，而关系数据则是无序的，另外XML数据的模式往往经常变化，可是关系数据库的数据结构是固定不变的，XML数据可以无限层次嵌套，而关系数据则不能。虽然XML放松的类型限制和自描述性有利于数据之间的交换，但是却不利于数据存储。因此，XML的数据模型的半结构化、有序性与平坦、无序的关系模型之间存在固有的不匹配。另外遵循文档类型定义(DTD)或文档模式定义(XML SCHEMA)的XML文档也与遵循关系存储模式的关系数据在语法、结构以及约束等很多方面存在着固有的异构性，因此很难直接由XML数据产生关系模式。甚至即使多个XML文档实例都遵循同一个文档模式定义，它们也可能有不同的结构。可以看出，XML映射到关系数据库中存在固有的困难。映射时主要存在以下需要解决的问题：(1)如何利用可能有的XML文档模式(或类型)信息来采取各种不同的存储策略；(2)如何将XML文档无损地存入关系数据库；(3)如何从关系数据库中查询并重构XML信息。

二、基于关系数据库的存储策略

(一)　基于结构映射的策略

具体来说，基于结构的映射方法可以分为两个步骤来实现：

第一步：简化DTD并生成DTD图。因为XML DTD的元素是相当复杂的，需要对复杂的DTD进行简化。DTD的简化变换主要有以下三种方式：(1)平面化变换：将DTD内的层次嵌套关系打平，把嵌套的定义转换为非嵌套的定义；(2)简化变换：将连续的多个一元操作转换为一个一元操作；(3)聚集变换：将多个具有相同名称的子元素聚在一起，形成一个子元素。一个DTD图表示的是一个DTD的结构，图的结点表示DTD中的元素、属性或操作符，DTD中的元素在DTD图中只出现一次，属性和操作符在DTD图中出现的次数则与它们在DTD中出现的次数相同。

第二步：DTD图到关系模式的映射。从DTD图到关系模式的映射方法主要有：基本内联法、共享内联法和综合内联法。

首先，基本内联法。基本内联法的原则是在存储一个结点的时候，尽可能多地将这个元素的后代结点存储在一个表中。其次，共享内联法。共享内联法为以下三种DTD结点生成独立的关系：(1)DTD图中入度大于l或者等于0(根结点)的元素结点生成独立的关系；(2)DTD图中结点“幸”的孩子结点(将值集元素作为单独的关系保存)；(3)互为递归的入度均为1的元素结点，其中之一生成独立的关系。而其余的结点都生成关系属性。共享内联法相对减少了XML查询转换为SOL语句的数目，但增加了每个SOL查询中的连接运算。再次，综合内联法。综合内联方法在处理入度大于1的结点上与共享内联方法不同，综合内联法将所有入度大于1的元素结点也内联进入父结点所生成的关系表中，但是带回路的结点以及结点“}”或“+”的直接后继结点除外，该方法减少了子结点与父结点的连接运算。

(二)　基于模型映射的策略

模型映射的方法是用一个固有的模式来存储XML文档。它用固定的关系模式来存放任何格式的XML数据，而不考虑XML文档的模式(DTD或SCHEMA)，其实质是存储XML文档本身的结构信息。

第一，Edge方法。Edge方法圆的存储策略是把要存入的XML文档看做图形结构，每个图的边界都表示为图中的元组，把XML文档图中的所有边都存入到关系表Edge中，用表Edge(source，ordinal，target，label，flag，value)存储XML文档图中的边，其中的source字段和target字段分别用来存储边的源结点和目标结点的标识符；label域为目标结点的类型；flag用来区分目标结点；target是一个元素结点还是一个文本结点，如果该目标结点是文本结点，则文本值存储于value域中；ordinal字段指出target结点在source结点的所有孩子中的位置。由于Edge方法将所有XML数据都用Edge表存放，操作方法简单。但缺点是在Edge方法中每条边都是单独管理的，所以在用户进行查询操作时就需在大量的表上进行连接操作以形成路径。如果要判断祖先/后代关系就需要从祖先到后代(或与之相反)遍历所有的边，造成代价非常昂贵。

第二，XRel方法。XRel方法为了存储XML文档的所有信息，将XML文档树分解为一个个路径表达式，对于树中每一个结点，都将从根结点到其自身的路径存储。而在树中有可能有多个结点的路径是一样的，所以单个的简单路径表达式并不能够存储整棵XML文档树的信息。XRel模式是通过区间编码[start，end]来反映XML文档的模型结构，并根据结点类型来划分，分为元素结点表、属性结点表和文本结点表，同时将所有路径进行存储。因此，XRel模式由四个关系表组成如图1所示：

在Path表中，存储所有的不重复的路径，其中，PathID为标记路径的标识，pathexp域存储标记路径。为了实现路径表达式的字符串匹配操作，防止意外的结果出现，将标记路径中的“/”替换为“#/”进行存储。对于Element表、Attribute表和Text表，Attribute表和Text表中的value字段存储的分别是属性结点的值和文本结点的值。对于每一个路径表达式，查询过程都可以分为两部：第一步，利用字符串的匹配操作，能够快速的查找出与路径表达式相匹配的所有标记路径的标识；第二步，利用这些路径标识，能够快速的查找出隶属于这些路径终端的值。

XRel存储模式的特点可以总结如下：(1)用简单路径表达式和结点的区间编码(start，end)存储XML文档的所有信息；(2)分别为每一种结点类型创建一个对应的关系表；(3)用一个Path表把文档中所有不重复的路径都提取出来，有效地降低了数据库的存储容量。

第三，XParent方法。XParent模式和XRel模式一样，将文本数据路径独立出来，共包含四个关系表，如图2所示：

其中，表LabelPath中的pathexp字段用来存储所有不重复的标签路径，即模式路径。每一个标签路径被赋予一个标识符pathlD，length为标记路径的长度。Parent表存储的是双亲/孩子关系，pid和cid分别表示一个边的起始结点与结尾结点。did为XML文档中元素结点的标识，它也可以作为以该结点为终端点的数据路径的标识。

Parem表存储的是双亲/孩子关系，因此，为了检查数据路径需要进行连接操作。为了提高这种处理的效率，可以改用Ancestor表来存储祖先/后裔关系。Ancestor(did，ancestor，level)，利用Ancestor表能够快速的检测结点之间的祖先/后裔关系，但是它比Parent表需要更多的空间，而且由于存在冗余信息，修改代价也更高。XParent模式分别通过LabelPath表和Parent表来支持标记路径和数据路径。因此，XParent模式既具有基于结点的模型映射的特点，又具有基于边的模型映射的特点。

三、结语

关系数据库范文第7篇

策略进行了研究。

关键词关键词：关系数据库；数据查询；查询优化

中图分类号：TP392 文献标识码：A 文章编号文章编号：16727800（2013）008011102

作者简介作者简介：郭威（1993-），男，中南财经政法大学信息与安全工程学院学生，研究方向为信息系统。

0 引言

随着社会经济的不断发展，人们已经进入了一个信息爆炸的时代，随之而来的则是大量数据的存储与操作。如今，数据库管理系统已经深入到各行各业，具有代表性的是银行、证券行业。存储

在数据库里的数据存在巨大价值，对这些数据最频繁的操作就是查询。如何从数据库里存储的海量数据中以最快的速度找到想要的数据，直接关系到以数据库服务器作为后台的各大

信息系统的运行效率，该问题也即是如何对数据库的查询进行优化。因此，在此背景下，通过对市场占有率最多的关系型数据库进行探讨，来研究查询优化[1]。

1 关系数据库介绍

1.1 关系模型

关系模型是美国IBM公司San Jose研究室的研究员E.F.Codd于1970年首次提出，而关系模式的诞生也开创了数据库关系方法和关系数据理论研究的历史。简言之，关系模型是一种由二维表形式表示实体和实体间关系的数据模型，它是在集合代数的基础上发展的。在关系模型中，一个关系就没有重复行和重复列的二维表，二维表的每一行在关系中称为元组，每一列在关系中称为属性。关系运算作为关系模型的核心，主要有并（∪）、交（—）、差

（∩）、笛卡尔积（×）、连接（）、投影（π）、选择（）、除（÷）八种。

1.2 关系数据库

根据所使用数据模型的不同，可以将数据库进行分类，因此基于关系模型的数据库就是关系数据库。所谓关系数据库，其数据组织的逻辑结构一定是采用关系数据模型，即使用二维表格方式描

述实体及其相互间的关系，然后把这种关系逻辑结构采用一定方式向物理结构映射，并存储在某种存储设备上的数据库。

2 数据查询过程

关系数据库主要有查询、插入、删除和修改这四大常用操作，其中，查询是最主要、使用最频繁的操作。关系数据库管理系统对用户提交的查询操作进行处理的过程可以分为4个阶段：查询分析、查询检验、查询优化、查询执行[2]。

在查询分析阶段，RDBMS对用户提交的查询语句进行扫描检查，进行词法分析和语法分析，主要检测用户提交的查询语句是否满足SQL语句规范。

接下来是查询检验阶段，尽管这时用户提交的查询语句已满足语法规定，但是还需要根据用户定义的数据字典进行语义合法性检查。主要检查语句中除了SQL语言之外的数据库对象是否真正存在。通过检查之后，RDBMS就将SQL查询语句转化成关系代数表达式。

在查询执行前，还需要进行查询优化。在这一阶段，RDBMS会选择一个效率较高的查询策略。查询优化一般可以分成代数优化和物理优化，代数优化一般是通过改变代数表达式，用等价的、更高效的代数表达式替换当前表达式来提高查询效率；物理优化主要是通过对存取路径和底层操作算法的选择来优化查询。

最后的查询执行阶段，通过代码生成器执行查询代码，完成查询工作，返回查询结果。

3 数据库查询优化策略

虽然在查询优化阶段系统会自动对查询进行一定的优化，但如果给数据库提交的查询语句过于糟糕，尽管经过优化，查询效率依旧会很低，所以应该从自身角度出发，对查询进行优化，进一步提高查询操作的效率。

查询优化的方法有很多种，本文主要从两个大的方面出发：一是将查询语句的关系代数式用等价的、高效的代数表达式进行替换，也就是对关系表达式进行优化[3]；二是采取一些可行的策略或方法让查询变得高效。

3.1 关系表达式优化

如果想要查询效率大幅度提高，对关系表达式进行代数变化和替换十分重要。如果关系代数式的运算顺序不当，虽然可以得到期望的结果，但是效率可能大打折扣。因此，需要根据关系代数表达式的等价变换规则，将已有关系表达式用更优的、等价的关系表达式来替代。

经过总结，基于等价变换规则，总结出对关系表达式优化的主要规则有如下几条：

（1）如果有选择运算，尽量先进行选择运算。因为这样可以提前排除数据中不满足条件的元组，从而使处理的数据量大大下降。

（2）如果存在不止一个选择运算或投影运算，尽量让这些运算一起进行。因为存在一些对同一代数关系式进行操作的选择、投影运算，同时进行操作可以减少扫描相应表的次数，减少查询时间。

（3）投影运算左右如果有其它双目运算，让投影运算与其结合起来同时执行。投影运算与其它双目运算结合起来，在连接过程中进行投影运算，这样可以避免投影时再扫描一次表。

（4）将选择运算与它前面执行的笛卡尔积运算结合起来。选择运算与笛卡尔积结合，这样可以减少连接过程中记录的行数，加快连接速度。

（5）按照能够减少中间运算结果的程度来执行运算。因为中间结果越少，接下来处理所需的时间就越少。

下面以一个例子来详述代数表达式优化所带来的效果。在数据库中存在3张表，学生表Sdt（Sno， Sname， Ssex， Sage， Saddress， Sclass）、课程表Cs（Cno， Cname， Cteacher）、选课表SC（Sno，Cno，Grade），现在需要找出选了课程号为c1004课程的女生姓名。

现在有两种代数表达式都可以实现这一查询目标，方案一是先让Sdt和SC两表做笛卡尔积运算，接着一步一步按条件选出满足的元组，最后投影得出姓名；方案二是首先同时对Sdt表和SC表进行选择运行，然后使用自然连接选择满足条件的元组，最后投影得出结果。两种方案分别如下：

经过分析发现，按第一种方案处理时，笛卡尔积连接基数过大，会使得中间结果过于庞大，使得查询效率大大降低，而第二种方案首先缩小集合，之后再进行等值连接，可以加快查询速度。

3.2 查询策略的使用

3.2.1 合理使用索引

索引是对数据库表中一个或多个字段进行排序而创造的一种分散存储结果，它可以帮助用户更快速地存储数据。使用索引可以加速数据的存取，能够减少对数据文件的磁盘读写，从而改善数据库查询的性能[4]。

在数据库表中建立索引的一般原则如下：

（1）在经常进行连接、但是没有指定为外键的列上建立索引，而不经常连接的字段则由数据库优化器自动生成索引。

（2）在频繁进行排序或分组（即进行group by或order by操作）的列上建立索引。

（3）在条件表达式中经常用到的不同值较多的列上建立索引，在不同值少的列上不要建立索引。

（4）如果待排序的列有多个，可以在这些列上建立复合索引。

3.2.2 使用视图和存储过程

视图是一个虚拟表，并不表示任何物理数据，只是用来查看数据的窗口，使用视图，可以简化操作[5]。可以将经常使用的连接、投影、联合查询和选择查询定义为视图，这样在需要进行这些操作时，就可以直接对视图进行查询，缩小了查询范围，加快了查询速度。

存储过程是数据库服务器上一组预编译的TSQL语句，用于完成某项任务，它可以接受参数、返回状态值和参数值，并且可以嵌套调用。而存储过程中用户自定义的存储过程可以由用户自行编写以满足自身需要，完成某一特定功能。当创建存储过程时，它得到了分析和优化，在第一次执行后，存储过程就驻留在内存中，省去了重新分析、重新优化和重新编译等工作，所以如果预先将经常使用的查询以存储过程的方式实现，以后就可以直接调用存储过程，从而大大加快查询速度。

3.2.3 适当的数据冗余

在数据库中，如果存在数据冗余，则可能被认为是该数据库设计得不合理，应该进行存储结构的优化，使其满足第三范式或者BCNF范式。但是，有时候可以适当从违反数据库设计范式的规则出发，让数据库中适当存在一些多余的数据。比如说A表需要与B表进行连接查询才能得到结果，数据库表的连接会花费相对较多的时间，于是可以在A表中增加一些B表中的属性，这样虽然存在数据冗余，但是可以不通过连接查询就得到所需查询结果，提高了数据库的查询效率。

关系数据库范文第8篇

关键词：关系数据库；查询优化；方法

中图分类号：TP311文献标识码：A 文章编号：1009-3044(2008)16-21188-02

On Optimization Method for Query in Relational Database

YIN Mei-gui

(Heyuan Polytechnic, Heyuan 517000, China)

Abstract: In the database application MIS, query process is the most frequent. Whether query process is good or bad will directly affect the performance of database application system. Therefore, query in database should be optimized. This article suggests some methods of how to realize the optimization by making use of the technology of query in relational database.

Key words: RDBMS; query optimization; methods

1 引言

数据库系统是管理信息系统的核心，基于数据库的联机事务处理（OLTP）以及联机分析处理（OLAP）是企业、银行、政府部分最为重要的计算机应用之一。从大多数数据库系统的应用实例来看，查询操作是所有数据库操作中所占据比重最大的操作。当数据库系统积累到一定程度（如税务系统的账户达到上百万甚至上千万条记录），全表扫描一次往往需要数十分钟，甚至数小时。如果采用比全表扫描更好的查询策略，往往能降低查询时间。如何设计数据库，采取什么样的查询方法，提高查询效率，这就是查询优化要解决的问题。

2 合理使用索引

索引是数据库一个常用的数据库对象，优化查询的重要方法是建立索引，也是数据库同时预先将数据分类导入到多表格的方式。在关系数据库的表上建立合适的索引，可以提高数据库数据查询的速度，改善数据库的性能。除了集簇索引，每一索引的使用都以磁盘容量作为代价，当使用一个索引，数据库引擎必须执行两个数据读取，这两个数据读取是数据库记录所必需的，第一个数据被读取到实际数据指针的索引，第二个数据被读入到指针指定的位置。因此创建索引时必须要与实际应用系统的查询需求密切结合，才能达到优化查询的目的。

2.1 建索引的必要性

判断索引必要性的最终标准是判断这些索引是否对数据库的工作效率有所帮助。在实际的应用过程中，应该为优化工作做以下几点准备：

首先观察数据库应用程序中所有的SQL语句，并从中统计出常用且可能对性能有影响的部分语句，然后分析、归纳出作为Where条件子句的字段及其各种组合方式；在这一基础上可以初步判断出哪些表的哪些字段应该建立索引。其次，必须了解应用程序，要了解哪些表是数据操作频繁的表；哪些表经常与其他表进行连接；哪些表中的数据量可能很大；数据量大的表中各个字段的数据分布情况如何等等。对于满足上述条件的这些表，必须重点关注。因为建立在这些表上的索引，将对SQL语句的性能产生举足轻重的影响。

2.2 使用索引的规则

索引的使用要恰到好处，其使用原则如下：

（1）在经常进行连接，但是没有指定为外键的列上建立索引，而不经常连接的字段则由优化器自动生成索引。

（2）在主键索引方面，不应有超过25%列成为主键，而普通列很少，这会浪费索引空间。

（3）在条件表达式中经常用到的不同值较多的列上建立检索，在不同值少的列上不要建立索引。

（4）在频繁进行排序或分组（即进行group by 或 order by 操作）的属性上建立索引。

（5）在作为最小值等聚集函数的属性上考虑建立索引。

索引的建立、维护和使用都需要付出代价，应合理使用索引。错误的索引不会使数据库性能得到预期的提高，往往还会产生一些负面影响。

3 SQL语句优化

要对查询进行优化，一个简单直接有效的方法是对SQL语句进行调整，减少计算量，提高查询的效率。以下是一些书写SQL的一些经验。

3.1 避免相关子查询

查询嵌套层数每增加一层，查询的效率成几何级的降低。要想提高嵌套语句的执行效率，则应减少嵌套语句的嵌套的层次。所以在实际应用中，若可以用连接查询代替的子查询，则用连接查询实现。

例：查询选修了“3-105”号课程的学生基本信息

用子查询的方法如下所示：

SELECT * FROM student WHERE SNO IN (SELECT sno FROM sc WHERE cno=’3-105’)

改写成连接查询如下：

SELECT student.* FROM student,sc WHERE stuent.sno=sc.sno AND cno=’3-105’

3.2 用UNION替换OR

合理建立索引有助于提高查询效率。有时尽管在所有的检索列上都有索引，但有些形式SELECT查询语句可能不会促使查询优化器使用索引，从而降低查询效率。如果对查询语句进行改写，用UNION替换OR，可以强迫优化器按索引路径处理。如：假定分别在“职工”关系中的“年龄”和“月工资”字段上创建了索引，对以下SQL语句

SELECT 姓名，年龄，月工资 FROM 职工 WHERE 年龄>45 OR 月工资

可替换为：

SELECT 姓名，年龄，月工资 FROM 职工 WHERE 年龄>45

UNION

SELECT 姓名，年龄，月工资 FROM 职工 WHERE月工资

3.3 使用临时表优化查询

在涉及相关查询的某些情形中，构造临时关系可以提高查询效率。如：查询每个部门中月工资最高的“职工号”

SELECT 职工号 FROM 职工 AS e1 WHERE 月工资=(SELECT MAX(月工资)FROM 职工 AS e2 WHERE e1.部门号=e2.部门号)

以上的查询对于外层的职工关系e1中的每一个元组，都要对内层的整个职工关系e2进行检索，因此查询效率不高。可以构建临时关系提高查询效率。

SELECT MAX（月工资） AS 最高工资，部门号 INTO temp FROM职工 GROUP BY 部门号

SELECT 职工号 FROM 职工，temp WHERE 月工资=最高工资 AND 职工.部门号=temp.部门号

3.4 避免在索引列上使用计算

WHERE子句中，如果索引列是函数的一部分。优化器不使用索引而使用全表扫描。如

SELECT * FROM职工 WHERE 月工资*12>20000

可改为：

SELECT * FROM 职工 WHERE 月工资>20000/12

3.5 谓词的等价变换

由于执行引擎对各种谓词的处理方法不同，把逻辑表达式重写成等价的且效率较高的表达式是提高效率的有效方法，同时也是切实可行的。针对执行引擎对各种谓词执行效率的不同，总结如下谓词转换规则：

1）将BETWEEN转化为AND 连接的谓词

把BETWEEN．．．AND．．．形式改写为用AND连接的两个谓词，效率往往

有一定的提高。

例如：月工资 BETWEEN 1000 AND 2000 改为： 月工资>=1000 AND 月工资

2）避免使用In语句

当查询语句中有In关键词时，优化器采用OR并列条件。

如：职工号IN (‘1001’,’2001’) 改为：职工号=’1001’ OR 职工号=’2001’

4 结束语

查询处理是数据管理系统的核心，而查询优化技术是查询处理的关键技术。查询优化就要抓住关键问题。在数据库的开发和维护过程中，查询优化设计可以提高系统的性能，尤其对于数据量大的数据库系统最为重要。本文提到一些优化方法是根据自己的经验，并查阅了大量的资料。在具体的使用时候要根据实际情况，才能合理制定出良好的优化方法，实现快速、高效的数据查询。

参考文献：

[1] 萨师煊，王珊．数据库系统概论[M].高等教育出版社, 2002.5.

[2] 周志易,江海．数据库系统理论与新技术[M]．北京理工大学出版社,2001.

关系数据库范文第9篇

关键字：优化查询；SQL查询；关系数据库

数据库查询操作是数据库操作的核心操作，对数据的查询效率及处理速度已成为衡量数据库性能的一个重要指标。数据库查询技术也是学生对《数据库原理与应用》这门课程所必须掌握的知识和技能，数据库查询技术的精通也为以后课程的学习（如：C#.NET程序设计）中的数据库应用程序的设计打下良好的基础。

为了优化数据库的性能，简单、有效的方法就是优化查询。

1优化原理和实质

数据查询处理的代价通常取决于对磁盘的访问，因为磁盘比内存的访问速度要慢。对于一个给定的查询，有许多可能的处理策略，复杂查询更是如此[1]。查询优化的实质是在结果正确的前提下，找出与已有表达式等价，但查询效率更高的表达式。

2在教学中要注重的几种典型的优化方法

2.1建立视图

视图可简化用户操作数据的方式，使用户能着重于所感兴趣的特定数据和所负责的特定任务。如果该视图数据规模小于定义的基本表，则基于视图的查询比原查询的速度会快得多。

例：要查询每门课程成绩最高的学生的学号

SELECT 学号，课程号，成绩

FROM 成绩表 A

WHERE 成绩=（SELECT MAX（成绩）

FROM 成绩表B

WHERE A..课程号=B.课程号）

语句缺点：这属嵌套查询，子查询的结果集将作为外层查询的条件，查询效率不高。

解决方案：可先建立视图，求得每门课程的最高分，再与成绩表中比较，获取与视图中最高分数据相等的记录，这就减少了内层连接的数据量，从而提高了检索速度。

用SQL语句优化的步骤为：

首先，创建视图

GREATE VIEW V_max_cnoscore AS

SELECT 课程号，Max(成绩) AS 最高分数

FROM 成绩表 GROUP BY 课程号

其次，利用视图检索数据

SELECT 学号，A.课程号，A.成绩

FROM 成绩表A，V_max_cnoscore B

WHERE A.成绩=B.最高分数 AND A.课程号=B.课程号

2.2查询条件Where子句的优化

2.2.1合理设置WHERE条件的先后顺序。多数数据库都是按从左到右的顺序处理条件，把能过滤更多数据的条件放在前面，过滤少的放后面，便可提高检索速度。

例：SELECT * FROM student

WHERE ssex=’女’ --条件1过滤的数据较少

AND sdept=’计算机系’ --条件2过滤数据比条件1多

上面的SQL就不符合上述原则，可改为：

SELECT * FROM student

WHERE sdept=’计算机系’

AND ssex=’女’

对同一表格进行多个选择运算，选择条件的排序对性能有较大影响，不仅影响索引的选取，而且关系到临时表的大小[2]。因此，要提高查询速度，可将较严格的条件写在前面，较弱的放在后面。

2.2.2避免使用“< >”或“NOT”操作符。“< >”或“NOT”均属于排斥性操作符，不是包括性操作符，这会使系统在搜索数据时无法使用索引，只能直接搜索表中的数据，例：

（1）SELECT 学号 FROM 成绩表 WHERE 成绩< >80

（2)SELECT 学号 FROM 成绩表 WHERE NOT(成绩80)

（3)SELECT 学号 FROM 成绩表 WHERE成绩< 80 OR 成绩>80

比较以上三条语句，可知第3条可使用索引查询，它的查询速度最快。

2.2.3恰当运用“OR扩展”技术。该技术是把在Where子句中带有OR的查询转换成包含多个UNION ALL的查询。

例：查询计算机系县年龄不大于20岁的学生。

常规的SQL语句：

SELECT 学号，姓名 FROM 学生表 WHERE 系名=’计算机系’ OR 年龄

假定表中“系名”和“年龄”两个字段上创建了索引，以上的查询可能不会使查询优化器使用索引，从而查询效率降低，可改进为：

SELECT 学号，姓名 FROM 学生表 WHERE 系名='计算机系'

UNION ALL SELECT 学号，姓名 FROM 学生表 WHERE 年龄

2.2.4合理减少LIKE条件的使用。在SQL查询中，LIKE条件使用的神奇之处在于其与通配符匹配所提供的模糊查询功能。但在字符串的比较中，有时大量字符的逐个比较，也会大大降低查找效率。

例：图书按26个英文字母分为26类，查找所有属于‘A’类图书的销售金额。

SELECT 图书类号, SUM (数量*单价) FROM 销售

WHERE 图书类号LIKE′A%′GROUP BY图书类号

优化为精确查询：

SELECT 图书类号，SUM(数量*单价) FROM销售

WHERE 图书类号>=′A′AND图书类号

GROUP BY图书类号

2.3正确使用子查询“展平”技术子查询“展平”技术就是指将子查询转变为半连接，连接或者反连接，从而将查询优化。

例：找出成绩大于等于90分的学生的姓名。

SELECT 姓名 FROM 学生表 WHERE 学号IN

(SELECT 学号FROM 成绩表WHERE 成绩>=90)

语句缺点：需要搜索学生表的每一行，来查找所有满足子查询条件的记录。

解决方案：将学生表作为连接的内表，查询将作为通常的连接来执行。

优化后的SQL语句：

SELECT 姓名FROM (SELECT 学号 FROM 成绩表

WHERE成绩>=90) A，学生表 B WHERE A.学号=B.学号

2.4善于使用存储过程

存储过程是SQL语句和可选控制流语句的预编译集合，一个名称存储并作为一个单元处理。善于使用存储过程，将使SQL变得更加灵活和高效。

例：查询某个学生某门课程的考试成绩，列出学生的姓名、课程名及成绩

CREATE PROC pro_student_degree

@stu_name char(12)，@course_name char(18) AS

SELECT sname，cname，degree

FROM student A INNER JOIN sc B ON A.sno=B.省略o=o

WHERE sname=@stu_name AND cname=@course_name

以上是一个带有两个输入参数的简单存储过程，只需执行一个简单的SQL语句――“EXEC pro_student_degree‘刘娜’,’数据库原理’”就可完成查询。

编写性能优化的SQL语句是提高数据库系统的重要因素，随着数据库管理系统中数据量的增大，如何提高查询速度与效率也是计算机软件开发的一个时代要求。实现优化查询的方法很多，在使用中，要根据具体情况权衡利弊，使数据库查询性能最优。在学生的教学中要注重培养学生的动手能力，使学生养成编写优化的SQL语句的习惯。

参考文献：

[1]王振辉,吴广茂.SQL查询语句优化研究[J].计算机应用，2005，（12）:208.

[2]SQL查询优化注意where条件的顺序.. 2009-06-18.

[3]李增祥.数据库SQL查询技术的优化策略[J].消费导刊，2009，（05）:205.

关系数据库范文第10篇

关键词：关系数据库 会计账务数据库 结构分析

数据库是以某种数据模型所确定的数据结构方式来组织和存储某个组织（或部门）相互关联的数据集。数据库管理系统是一种帮助用户建立、使用、管理和维护数据库的计算机系统软件。

一、数据模型及其建立

数据模型是对现实世界数据特征进行抽象的工具，用来描述和处理现实世界中的数据和信息。数据模型要能较真实地模拟现实世界，既要便于人们理解，又要便于在计算机上实现。数据模型主要由数据结构、数据操作、数据完整性规则三个部分组成。数据结构描述了组成数据库的基本成分；数据操作描述了对数据结构允许执行的操作集合；完整性规则描述了对数据结构所具有的约束和存储规则。

二、关系数据模型结构及数据库中的数据文件之间的对应关系

下面我们通过会计科目代码表来介绍关系数据模型的基本概念及其与数据库中的数据文件之间的对应关系：

（一）关系、二维表、数据文件。关系数据模型中用关系来表述现实世界中能够相互区别的要管理的数据对象集。每一个关系都有一个关系名和一组表述其特征的属性集，人们就是通过这些属性集区别不同的关系。如记账凭证、会计科目、总账都可以称之为关系，它们都是要管理的数据对象集，都有各自的属性集。一个关系用一张二维表表示，表名对应关系名。二维表由有限个不重复的行组成，表中的每一列不可再分。一张二维表在关系数据库中用一个数据文件存储。

（二）记录。二维表中的每一行称为一个记录，描述了关系中一个具体的个体，在数据文件中是一个记录值。如表中第一行为现金账户的记录，描述了现金账户在会计科目代码文件中所有属性的取值（特征）。

（三）属性、列、字段。二维表中的每一列是一个属性，描述了关系的一个特征。一个二维表的所有列构成了一个关系的属性集，通过它可以区别不同的二维表（关系）。二维表中的每一列的数据属于同一类型。每一列的列名对应关系的属性名，同时对应数据文件中的字段名。如表中用6个列表示会计科目代码的属性，其中第三列表示属性“科目性质”，当某条记录取值为1时，表示是资产类科目。

（四）主码、主关键字。指二维表中的某个列（属性）或某几个列（或属性组），它们的值能够唯一确定表中或数据文件中的一个记录。如表中的“科目代码”属性可以作为主码（或主关键字），用来唯一识别表中的每一个会计科目。

（五）域。描述二维表中每一列属性或数据文件的某一字段的取值类型和范围。表中每一列的列名下面的括号中的内容表示该列的取值类型和范围，其中第四列“底层明细标志”表示某个科目是不是最底层明细科目（不再有下层科目），只有两种取值T（真）和F（假）。

（六）关系模式。一个关系模式由一个关系名及它所有的属性构成，它对应一个二维表的表名和表头栏目行（列的集合），构成了一个二维表的框架，同时也是设计该二维表的数据文件结构的依据。

三、关系数据模型的数据操作（二维表）

从数学的角度看，关系数据模型的数据操作是基于集合的操作，操作对象和操作结果都是集合。从数据处理的角度看，数据操作的对象和结果都是二维表。对二维表的操作主要有：

（一）对表中的行（记录）进行操作。指对一张表中指定范围的记录进行有条件的操作，操作的结果组成一张新表。例如，从“会计科目代码表”中筛选出资产类科目组成新的“资产类科目代码表”，操作的范围是整个“会计科目代码表”，条件是“科目性质等于1”。对表中的行进行操作后的结果表的结构与原表相同，记录数小于或等于原表。

（二）对表中的列（属性）进行操作。指对一张表中指定的列进行有条件的操作，操作的结果组成一张新表。例如，从“会计科目代码表”中选出“科目代码”、“科目名称”两列，组成新的科目代码对应表，新表只有“科目代码”和“科目名称”两列。显然，列操作后的结果表的结构与原表不同，结果表小于或等于原表。

（三）连接。对两张表或多张表进行有条件的连接操作，生成一张新表。连接操作后的结果表大于等于操作前的表。

从应用的角度看，对二维表中的数据操作功能主要包括更新（增加、修改、删除）数据和检索（查询）数据，即对二维表填入和修改数据，并从表中检索出数据进行加工应用。

四、关系数据模型的数据完整性规则

数据完整性是指数据库中存储的数据是有意义的或正确的。关系数据模型中的数据完整性规则是指对二维表的定义和操作过程中要遵循的某些约束条件。主要包括：

（一）实体完整性。指每张表都必须有主码，而且表中不允许存在无主码值的记录和主码值相同的记录。每一个记录都必须有科目代码，并且不能有相同科目代码的记录和无科目代码的记录。

（二）参照完整性。指一张表的某列的取值受另一张表的某列的取值范围约束，描述了多张表之间的关联关系。例如，记账凭证表中的“科目代码”列的取值受到会计科目代码表的“科目代码”取值范围的限定。

（三）用户定义完整性。指针对某一具体应用定义的数据库约束条件，反映某一具体应用所涉及的数据必须满足应用语义的要求。即限制属性的取值类型及范围，防止属性的值与应用语义矛盾。

五、关系数据模型得到的启示

（一）数据的二维表及二维表之间的关联设计。基于关系数据模型的会计账务数据库是以二维表为基本部件构建的，数据库中的每一个数据文件对应一张二维表，数据文件之间的关联也可以用二维表之间的关联来表示，对二维表的定义和数据操作必须满足数据完整性约束条件。构建一个会计账务数据库首先要将会计账务管理的对象，如会计科目、记账凭证、日记账、明细账、总账及它们之间的关系抽象成二维表的形式，弄清了它们的二维表结构也就弄清了它们的数据文件结构，即电子账结构。因此，会计账务数据库结构设计可以转变成会计账务数据的二维表及二维表之间的关联设计，而一张二维表的表头栏目（属性集）反映了表的结构特征，是设计数据文件结构的依据。

（二）关系数据库管理系统软件版本。依据关系数据模型研发的关系数据库管理系统是开发和管理会计数据库系统的工具软件，也是支持所开发的会计数据库系统运行的平台，任何一个会计账务数据库都必须在某一个关系数据库管理系统的在线管理下运行。由于不同的数据库软件公司提供的关系数据库管理系统软件的各个版本的功能强弱、所适应的计算机系统的运行环境（单机、网络等）、所提供的对表的操作命令等都有所不同。

参考文献：

[1]王新明、郑春玲.基于关系数据库策略驱动的网络安全评估系统[J].计算机工程与应用，2004，40（2）：15.

[2]钱梅、汪斌.面向对象模型对复杂结构知识的表示方法[J].计算机工程与科学，2002，24（3）：26.