关系数据库范文1
关键词：NoSQL数据库；关系型数据库；CAP理论
中图分类号：TP311文献标识码：A文章编号：1009-3044(2011)20-4802-03
Relational Database and NoSQL Database
ZHANG Hua-qiang
(Anhui Nari Jiyuan Software CO.,LTD., Hefei 230088,China)
Abstract: This paper introduces a database called NoSQL,thoughout the descriptions of the traditional relational database and its present problems, meanwhile,points out the characteristics of NoSQL datebase and the current application situations; finally, summarizes how to usein combination with NoSQL database and the traditional relational database in some scenes and illustrates with some examples.
Key words: relational database; NoSQL database; CAP theory
回顾数据库的发展历程，数据库技术从60年代末开始，经历了层次数据库、网状数据库和关系数据库而进入数据库管理系统( DBMS)阶段至今, 数据库技术的研究也不断取得进展。最近几十年, 关系型数据库成为发展的主流, 几乎所有新推出的DBMS产品都是关系型的。关系型数据库在计算机数据管理的发展史上是一个重要的里程碑。但最近NoSQL数据库却风声鹊起，引起了人们的极大关注。NoSQL数据库并不是最近才出现的，很多NoSQL数据库实现都已经存在了十多年了，有很多成功案例，是什么原因让它们比以前更受欢迎了呢？NoSQL数据库会不会替代现有的关系型数据库呢？本文将一一为你做出解答。
1 关系型数据库
1.1 关系型数据库概述
关系型数据库是支持关系模型的数据库系统，他是目前各类数据库中最重要，也是使用最广泛的数据库系统。关系型数据库从诞生到现在经过几十年的发展，已经变的比较成熟，目前市场上主流的数据库都为关系型数据库，比较知名的如Sybase，Oracle，Informix，SQL Server，DB2等。
1.2 关系型数据库的优势
关系型数据库相比其他模型的数据库而言，有着以下优点：
容易理解：关系模型中的二维表结构非常贴近逻辑世界，相对于网状、层次等其他模型来说更容易理解。
使用方便：通用的SQL语言使得操作关系型数据库非常方便，只需使用SQL语言在逻辑层面操作数据库，而完全不必理解其底层实现。
易于维护：丰富的完整性（实体完整性、参照完整性和用户定义的完整性）大大降低了数据冗余和数据不一致的概率。
1.3 关系型数据库存在的问题
传统的关系型数据库具有不错的性能，高稳定型，久经历史考验，而且使用简单，功能强大，同时也积累了大量的成功案例。在90年代的互联网领域，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。在那个时候，更多的都是静态网页，动态交互类型的网站不多。可是最近几年，互联网Web2.0网站开始快速发展。火爆的论坛、博客、微博逐渐引领web领域的潮流。传统的关系型数据库在应付这些超大规模和高并发的纯动态网站显得力不从心，暴露了很多难以克服的问题。
数据库高并发读写：高并发的纯动态网站一般都是根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。
海量数据的高效率存储和访问：上述提到的Web2.0网站，每天用户会产生海量的动态信息，对于关系数据库来说，在一张数以亿计条记录的表里面进行SQL查询，效率是极其低下，难以忍受的。
数据库的高可扩展性和高可用性：基于web的架构当中，数据库无法通过添加更多的硬件和服务节点来扩展性能和负载能力，对于很多需要提供24小时不间断服务的网站来说，数据库系统升级和扩展却只能通过停机来实现，这无疑是一个艰难的决定。
2 NoSQL数据库
2.1 NoSQL数据库概述
NoSQL数据库是非关系型数据存储的广义定义，它打破了长久以来关系型数据库与ACID理论大一统的局面。NoSQL 数据存储不需要固定的表结构，通常也不存在连接操作。NoSQL数据库不使用传统的关系数据库模型，而是使用如key-value存储、文档型的、列存储、图型数据库、xml等方式存储数据模型。 其中用的最多的是： key-value存储。
2.2 NoSQL数据库优势
易扩展：NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系型数据库的关系型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。
大数据量，高性能: 同样由于数据之间无关系，数据库的结构简单，在大数据量下，NoSQL数据库表现出非常高的读写性能。
灵活的数据模型：NoSQL数据库无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系型数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直难以想象。
2.3 NoSQL数据库应用现状
NoSQL数据库并不是最近才出现的，很多NoSQL数据库实现都已经存在了十多年了，有很多成功案例，是什么原因让它们比以前更受欢迎了呢？首先是由于社会化网络和云计算的发展，一些原先只有很高端的组织才会面临的问题，如今已经成为普遍问题了。其次，已有的方法已经被发现无法跟随需求一起扩展了。并且成本的压力让很多组织需要去寻找更高性价比的方案，并且研究证实基于普通廉价硬件的分布式存储解决方案甚至比现在的高端数据库更加可靠。所有这些导致了对NoSQL数据库的需求。
Web2.0技术在网络中的广泛应用为NoSQL数据库发展提供了充足的动力，市场上先后出现了十多种比较流行的NoSQL产品，例如：Redis，Tokyo Cabinet，Cassandra，Voldemort，MongoDB，Dynomite，HBase，CouchDB，Hypertable， Riak，Tin， Flare， Lightcloud， KiokuDB，Scalaris， Kai， ThruDB，...... 这些NoSQL数据库都有自己的独到之处。有满足极高读写性能需求的Kye-Value数据库：Redis，Tokyo Cabinet， Flare；还有满足海量存储需求和访问的面向文档的数据库：MongoDB，CouchDB；以及满足高可扩展性和可用性的面向分布式计算的数据库：Cassandra，Voldemort；在此就不详细介绍每款NoSQL数据库了。
3 关系型数据库与NoSQL数据库结合
伴随着越来越多的NoSQL产品涌现出来， NoSQL数据库会不会替代现有的关系数据库？在说明之前，我们先简单了解下CAP理论，以及ACID、BASE。
3.1 CAP理论
CAP:
C: Consistency 一致性
A: Availability 可用性 (指的是快速获取数据)
P: Tolerance of network Partition 分区容忍性 (分布式)
ACID：
ACID事务提供以下几种保证：
Atomicity（原子性），事务中的所有操作，要么全部成功，要么全部不做。
Consistency（一致性），在事务开始与结束时，数据库处于一致状态。
Isolation（隔离性），事务如同只有这一个操作在被数据库所执行一样。
Durability（持久性），在事务结束时，此操作将不可逆转。
BASE：
Basically Available（基本可用）
Soft-state（软状态/柔性事务）
Eventual Consistency（最终一致性）
BASE模型是传统ACID模型的反面，不同与ACID，BASE强调牺牲高一致性，从而获得可用性，数据允许在一段时间内的不一致，只要保证最终一致就可以了。
互联网Web2.0网站由于数据库存在高并发读写、高可扩展性、高可用性，所以要求设计成分布式存储，而在设计一个分布式存储系统时，根据CAP理论，一致性(C)，可用性(A)，分区容错性(P)，三者不可兼得，最多只能同时满足其中的两个。而关系型数据库保证了强一致性(ACID模型)和高可用性，所以要想实现一个分布式数据库集群非常困难，这也解释了为什么关系型数据库的扩展能力十分有限。而NoSQL数据库则是通过牺牲强一致性，采用BASE模型，用最终一致性的思想来设计分布式系统，从而使得系统可以达到很高的可用性和扩展性。
对Web2.0网站来说，可用性与分区容忍性优先级要高于数据一致性，一般会尽量朝着 A 、P 的方向设计，但事实上，数据库系统最大的优势就对一致性的保证，单纯为了P(分布式)而放弃C（一致性）也是不可取的，所以需要通过其它手段来保证对于一致性的商务需求。
3.2NoSQL数据库实际应用缺陷
缺乏强有力的商业支持：大部分的NoSQL数据库都是开源项目，没有世界级的数据库厂商提供完善的服务，如果出现故障，只能自己解决，风险较大。
成熟度不高： NoSQL数据库的实际应用不多，大部分NoSQL产品都在小范围应用。成熟度不高，目前还很难在企业中广泛应用。
NoSQL数据库在设计时难以体现实际：关系型数据库中的关系模型对于数据库设计是很有帮助的，而NoSQL数据库缺乏这种关系，难以体现业务的实际情况，对于数据库的设计与维护都增加了很大难度。
3.3 关系型数据库与NoSQL数据库结合
从上面的CAP理论来看，分布式存储系统更适合用NoSQL数据库，现有的Web2.0网站遇到的性能以及扩展性瓶颈也会迎刃而解，但是目前NoSQL数据库的实际应用缺陷又让我们难以放心。这时我们考虑是否可以将NoSQL数据库与关系型数据库结合使用，在强一致性(C)，高可用性场景我们采用ACID模型，在高可用性和扩展性场景，我们就采用BASE模型，答案是肯定的，目前的NoSQL数据库还难以与关系型数据库一争高下，但它却可以对关系数据库在性能和扩展性上进行弥补，所以我们可以把NoSQL和关系数据库进行结合使用，各取所长，需要使用关系特性的时候我们使用关系数据库，需要使用NoSQL特性的时候我们使用NoSQL数据库，各得其所。
下面举个典型的例子加以说明：
在Web2.0网站中比较典型就是用户评论的存储，评论表大致可分为评论表主键ID、被评论用户ID、评论用户ID、评论时间、评论内容等字段。结合关系型数据库与NoSQL数据库的特点，我们可将需要查询的字段，比如评论表主键ID、被评论用户ID、评论用户ID、评论时间等数据、时间类型的小字段存储于关系型数据库中，根据查询建立相应的索引，而评论内容是个大文本字段，我们肯定不会通过文本内容进行查询，所以我们把评论内容存储在NoSQL数据库中。这种让关系型数据库专门负责处理擅长的关系存储，NoSQL数据库作为数据的存储的结合使用方式，首先节省了关系型数据库的IO开销，提高了数据库的数据备份与恢复速度；其次由于NoSQL数据库的Cache往往都是行级别的，所以对评论内容字段也更容易做Cache，最后由于NoSQL数据库天生就容易扩展，经过这种结合优化，关系型数据库的性能也能得到提高。这种结合方式实现起来比较容易，却能取得不错的效果。关系型数据库与NoSQL数据库结合并不局限于这种方式，应该根据具体的应用场景灵活组合使用。
4 结束语
关系数据库已经流行了几十年了，NoSQL数据库想在短期内取而代之显然是不可能的，但是NoSQL数据库的发展势头也不容小觑。在当前阶段的某些场景下，可以将NoSQL数据库与关系型数据库结合使用，相互弥补各自的缺陷，这种数据库组合对解决目前Web2.0网站所遇到的性能、扩展性等问题具有指导意义。
参考文献：
[1] 李莉莎.关于NOSQL的思考[J].中国传媒科技,2010(4):40-41.
关系数据库范文2
关键词:关系数据库;云端数据库;Bigtable;时间戳
中图分类号:TP399文献标识码:A文章编号:1009-3044(2009)25-7090-03
Comparison and Analysis for Relational Database and Cloud Database Based on Architecture
ZHANG Zhen-yong, WEN Jing-hua
(Guizhou College of Finance and Economics, Guiyang 550004,China)
Abstract: Aiming at the shortcoming that relational database processes a large number of video,audio,images and complex data types, this thesis compared and analyzed relational database and Bigtable representing cloud database and based on architecture. The results showed that cloud database was more advantageous than relational database in precessing a great mass of data and complex data types. With the development of the cloud database technology,cloud database will be superseding the relational database as the mainstream of the database.
Key words: ralational database; cloud database; bigtable; timestamp
关系数据库从1970年发展至今,虽功能日趋完善,但对数据类型的处理大多采用数字、字符等基本数据类型,对多媒体信息的处理只是停留在简单的二进制代码文件的存储。随着信息技术的发展,互联网上数据量高速增长,非结构化数据的应用日趋扩大,再加上用户应用需求的提高、硬件技术的发展和Web2.0提供的多彩的多媒体交流方式,用户对多媒体处理的要求从简单的存储上升为识别、检索和深入加工等高级应用。关系数据库在处理这类数据时,逐渐暴露出了一些缺陷。
如何来高效处理占数据总量70%的声音、图像和视频等复杂数据类型是目前互联网界亟待解决的问题。正是在这种状态下,云端数据库便应运而生并开始发展起来。目前云端数据库技术在云计算中的应用有Google的Bigtable系统[1]、Amazon公司的Dynamo系统、Hadoop的一个子项目Hbase、微软的Live Mesh系统等等。无论是Bigtable还是Hbase都是采用通用的云端数据库架构,只是核心技术不同。所以本文就以Google的Bigtable架构为代表与传统的关系数据库架构进行比较和分析。
1关系数据库
1.1关系数据库概念及特点
关系数据库在一个给定的应用领域中,所有实体及实体之间联系的关系的集合。它是建立在集合代数基础上,应用数学方法来处理数据库中的数据,现实世界中的各种实体以及实体之间的各种联系均用关系模型来表示,也就是说关系数据库是建立在关系模型基础上的数据库[2]。
关系数据库具有数据结构化、最低冗余度、较高的程序与数据独立性、易于扩充、易于编制应用程序等优点,目前较大的应用软件系统都是建立在结构化数据库设计之上的。
1.2关系数据库系统的架构
关系数据库的架构包括六个部分[3]:
1) 查询语言接口
查询语言接口通过使用SQL语言对数据库进行特设查询数据。
2)交互式查询工具
交互式查询工具是用于访问,修改以及更新一个或多个关联的数据表,并以视图的方式返回给用户。
3) 核心软件
该核心软件用于控制查询处理,存取数据路径,用户访问管理,存储管理,索引,交易处理和读取/更新信息。
4) 公用机制
公用机制主要用于输入/输出/备份调整工具及参数/报告撰写。
5) 存储机制
存储机制主要进行数据库写入,归档,用户管理器,服务器管理,重做日志文件。
6) 数据库
数据库的特点是以数据文件的方式对数据对象进行物理存储,包含了系统目录即数据目录,一个或多个数据文件以结构化形式存储组成集合即二维表,并将不同数据集通过主键和外键进行关联。
关系数据库的架构如图1所示。
1.3关系数据库的缺陷
通过对关系数据库架构的分析,可以发现关系数据库的一些不足,概括如下四点:
1) 数据类型表达能力差
因为关系数据库所处理的是结构化的数据,所以关系数据库缺乏直接构造与现代软件应用有关的信息的类型表达能力。随着信息技术的飞速发展,图像、视频、音频以及文档等非结构化的数据已被应用到人们的日常生活当中,利用关系数据库来处理这些非结构化的数据已经显得有点力不从心了。因此目前大多数RDBMS产品所采用的简单类型在重构复杂数据的过程中将会出现性能问题;数据库设计过程中的额外复杂性;RDBMS产品和编程语言在数据类型方面的不协调,需要通过较复杂的程序化进行数据类型之间的转换来达到数据类型的一致性。
对于工程应用来说,关系数据库不能支持复杂数据类型的典型结果就是需要额外地分解数据结构工作,这些被分解的结构不能直接表示应用数据,且从基本成分重构时也非常繁琐和费时间。
2) 复杂查询功能比较差
在关系数据库中,利用SQL语言进行查询数据。虽然SQL语言为数据查询提供了很好的定义方法,但是当用于复杂信息的查询时可能会非常繁琐。这是由于在工程应用时规范化的过程通常会产生大量的简单表,从而降低数据的冗余度。那么在这种环境下由存取信息产生的查询必须处理大量的表和复杂主键和外键之间的联系以及连接运算,会影响系统的查询效率。
3) 支持长事务能力差
由于RDBMS记录锁机制的颗粒度限制,对于支持多种记录类型的大段数据的登记和检查来说,简单的记录级的锁机制是不够的,但基于键值关系的较复杂的锁机制来说却很难推广也难以实现。
4) 环境应变能力差
在要求系统改变的环境下,关系数据库从一种系统移植到另一个系统上的成本高且修改困难。再加上,关系数据库和编程语言所提供的数据类型的不一致,使得从一个环境转换到另一个环境时需要多至30%的附加代码。
正是由于关系数据库的这些缺陷,才推动了数据库技术的发展,产生了云端数据库技术,进而弥补了关系数据库的不足。
2 云端数据库
2.1 Bigtable的介绍
Google在 2004 年初就开始研发了BigTable,到了2005年大概有100个左右的服务使用BigTable。BigTable 让Google在提供新服务时的运行成本降低,最大限度地利用了计算能力。
Bigtable是一个大型,容错,自我管理的分布式存储系统,并用于管理分布在成千上万台服务器上的结构化数据[4]。它是建立在GFS分布式文件系统[5]、Scheduler分布式集群调度、Lock Service分布式的锁服务[6]和 MapReduce编程模式[7]基础之上的系统。
2.2 Bigtable的架构
1) Bigtable的数据模型
一个Bigtable(大表)是一个稀疏的,分布的,持续的以及多维的排序的数据映射。这个映射由行主键,列主键和时间戳进行索引[4]。每一项值在映射中是一系列不被解释的字节元组即(row:string,column:string,timestamp:int64)string。
在Bigtable的数据模型中,所有的数据都存放在表格单元中,每一行表示一个事物的数据内容,其所在列表示这个事物的唯一标志,其所对应的时间戳表示这个事物在某个时间上的状态即具体的数据内容。关系数据库只能反映当前时间上事物所处的状态,而Bigtable不仅能显示事物当前所处的状态,而且还可以记录某个事物的过去某个时间所处状态。Bigtable的数据模型如图2所示。
2) Bigtable的架构
与目前的关系数据库类似,BigTable也是客户端和服务器端的联合设计,使得性能能够最大程度地符合应用的需求。
BigTable系统依赖于集群系统的底层结构,一个是 Google的分布式文件系统(GFS),一个是分布式的集群任务调度(scheduler),还有一个分布式的锁服务(Lock Service)。BigTable使用Lock Service来保存根数据表格的指针,即客户端用户可以首先从Lock Service锁服务器中获得根表的位置,进而对数据进行访问。BigTable使用一台服务器作为主服务器,用来保存和操作元数据。主服务器除了管理元数据之外,还负责对tablet服务器(即一般意义上的数据服务器)进行远程管理与负载调配。客户端通过编程接口与主服务器进行元数据通信,与tablet服务器进行数据通信[8]。
Bigtable的架构由Bigtable master、Bigtable tablet servers和Bigtable client library三部分组成,如图3所示。
Bigtable master存储了许多由大量的tablets组成的表。主要负责指派tablet到tablet的各个服务器上,并检测tablet服务器的增减和服务程序装载满与否,进行实时的分配任务,使tablet服务器负载均衡并回收GFS文件系统中的垃圾文件。此外,它还处理模式更改,如表和列簇的创建。
每一个tablet服务器用于管理一部分tablets,通常有10-1000个tablet和处理客户端用户的读/写请求。tablet是由大表以行为单位分隔而成的。每个tablet保存了连续的行,然后别分配到各个tablet服务器上。
Bigtable client library是客户端用户和Bigtable服务器通信的接口。用户通过Bigtable client library接口来读数据和写数据等操作。
3 关系数据库与云端数据库的比较
3.1 两者架构的区别
关系数据库架构与云端数据库中的Bigtable架构主要区别如表1所示。
3.2 基于架构的比较分析
通过对关系数据库架构和云端数据库中的Bigtable架构的分析,可以从以下几个方面对两者进行比较:
1) 数据模型
在关系数据库中创建的表是一张二维表包括行和列,使用简单的数据类型对结构化的数据进行存储。但对于非结构化的数据的存储,因为关系数据库要保持数据冗余度低这一优点,所以关系数据库的设计会比较复杂且困难。而Bigtable创建的类似于二维表,但事实上不是二维表,它是由行主键、列主键、时间戳三个域组成的多维map。虽然Bigtable存储数据的冗余度比较高,但是Bigtable比关系数据库的二维表多了一个域――时间戳域,时间戳域可以记录事物的不同时间时的状态。另外Bigtable是以一条记录为原子对数据进行操作的,所以Bigtable不仅可以对事物的当前状态进行更新,还可以对事物的过去状态进行查询。在这一点上,关系数据库是不支持历史查询的。
2) 数据的存取方式
在关系数据库中用户对数据进行查询、添加、修改及删除等的操作是使用SQL语言。对于处理海量及复杂数据时,使用SQL语言对多个关联表进行操作就可能会显得非常繁琐。Bigtable并非支持SQL语言的数据库,而是以map 函数方式的,以列导向的数据库。Bigtable对数据的存取是以一行记录为原子进行的,不必关联其他的表,那么数据存取的速率要比关系数据库要高。
3) 数据迁移能力
关系数据库提供了一些简单的数据类型,在环境发生变化比如应用平台或者是编程语言所提供的数据类型与关系数据库所提供的不一致时,那么数据之间的转化过程将会相当复杂而且还会增加成本。而Bigtable所提供的数据类型只有字符串类型,所有数据都是以字符串的形式进行处理,因此Bigtable在进行数据迁移时相比关系数据库要容易并且成本也要比关系数据库要低得多。
4) 支持事务
关系数据库为了保持数据的完整性和一致性,提供了事务处理功能。关系数据库在处理简单事务方面,显现出了关系数据库的优势。但是在处理繁琐的事务方面,比如执行了n条SQL语句来对多个关联的数据表进行处理,执行效率就会显得比较低。目前,Bigtable还不支持事务处理功能,但是Google已经考虑到了该功能,一旦Bigtable支持了多行数据的事务支持,执行效率将会大大提高。
总之,云端数据库在处理非结构化数据时要比关系数据库的效率高,更适宜在多节点的服务器集群上工作,比关系数据库更适应环境的变化,最大的优点是使用成本比关系数据库要低得多。
4 结束语
本文通过对关系数据库架构和云端数据库架构的比较分析,可以得出云端数据库在许多方面要比关系数据库占优势,也就是说云端数据库技术具有很大的发展前景。虽然云端数据库技术还不够成熟,再加上各大关系数据库供应商对关系数据库技术的不断改进以及对查询算法进行优化,但是随着云端数据库技术的不断成熟,将会得到广泛的应用,进而逐步会取代关系数据库成为数据库中的主流。
参考文献:
[1] Chang F,Dean J,Ghemawat S,Hsieh WC,Wallach DA,Burrows M,Chandra T,Fikes A,Gruber RE.Bigtable:A distributed storage system for structured data.In:Proc.of the 7th USENIX Symp.on Operating Systems Design and Implementation.Berkeley:USENIX Association,2006:205-218.
[2] 瞿裕忠 胡伟 郑东栋 仲新宇. 关系数据库模式和本体间映射的研究综述[J].计算机研究与发展,2008,45(2):300-309.
[3] Fay Chang,Jeffrey Dean,Sanjay Ghemawat,Wilson C.Hsieh,Deborah A.Wallach Mike Burrows, Tushar Chandra, Andrew Fikes,Robert E.Gruber.Bigtable: A Distributed Storage System for Structured Data,OSDI,2006:1-5.
[4] Ghemawat S,Gobioff H,Leung ST.The Google file system.In:Proc.of the 19th ACM Symp.on Operating Systems Principles.New York:ACM Press,2003.29-43.
[5] Dean J,Ghemawat S.MapReduce:Simplified data processing on large clusters.In:
关系数据库范文3
中图分类号： G250.74 文献标识码： A 文章编号：
第一章绪论
当今社会，传统的GIS将属性数据与空间数据分离的数据组织形式已经不能满足现有的GIS数据管理的需要，将属性数据和空间数据统一起来存放在关系数据库并进行有效的管理的技术，已经显得越来越重要了。
地理信息系统（GIS）不仅具备一般计算机系统所具有的功能，如采集、管理、分析和表达数据等功能。 还拥有分析和表达地理空间数据的能力。由此，可以简单地定义地理信息系统是一种用来采集、模拟、处理、检索、分析和表达地理空间数据的计算机信息系统。是有关空间数据管理和空间信息分析的计算机系统。
当前，分离的数据组织形式以不能满足现今的GIS数据管理的需要，所以空间和属性数据要求进行一体化的管理，本文将对此作出分析研究。
第二章地理信息系统数据库
2.1GIS数据库中的地理数据
2.1.1 空间数据
空间数据（Spatial Data）：描述地理数据中空间特征部分的数据。
点
线
面
复杂空间数据类型
复杂空间数据类型是由点、线或面等空间数据类型组合而成，但不能简单地归为点、线、面类型的一种特殊数据类型，一般结构比较复杂。
图2-1 河流A
如图:河流A就不能用线类型数据简单地归类，而应该属于复杂空间数据类型。
2.1.2 属性数据
属性数据（Attribute Data）：又指非空间数据。描述地理数据中属性特征部分的数据。
2.2GIS数据库系统模型
在过去的10年中，GIS数据管理方法的发展主要有以下4种类型
1 对不同的应用模型开发独立的数据管理服务，是一种基于文件管理的处理方法。
2 在商业化的DBMS基础上开发附加系统。开发一个附加软件用于存储和管理空间数据和空间分析，使用DBMS管理属性数据。
3 使用现有的DBMS，通常是以DBMS为核心，对系统的功能进行必要扩充，空间数据和属性数据在同一个DBMS管理之下。需要增加足够数量的软件和功能来提供空间功能和图形显示功能。
4 重新设计一个具有空间数据和属性数据管理和分析功能的数据库系统。如图：
图2-2GIS数据库系统模型
通过数据库系统几种模型的比较我们可以看出，用标准的DBMS来存储空间数据，不如用扩展的RDBMS存储表格数据那样好。主要是因为，GIS需要一些复杂的图形功能，一般的RDBMS不能支持；再就是DBMS难以实现对空间数据的关联、连通、包含和叠加等基本操作。所以说，关系型数据库是当前管理空间地理数据最行之有效的管理模式（我们使用C应用模型）。
第三章 Oracle数据库中的数据管理
3.1基于ArcSDE的空间数据的一体化管理
数据进入数据库的的方式是通过管理系统(Oracle)管理工具以及第三方软件（ArcSDE for Oracle）转换和加载的。
ArcSDE存储和组织空间数据的方式是通过将空间数据类型加入到关系数据库（Oracle）来组织、存储和管理地理数据的。ArcSDE并不改变和影响现有的数据库或应用，它仅仅只是在现有的（属性）数据表中加入图形数据项（Shape Column），以方便软件管理、访问与其关联的空间数据。空间图形数据和空间图形索引放在另外的数据表中，通过关键项空间可用表、空间图形表、图形索引表实现关联。通过将层从逻辑上分成一个个小块来对数据库中各层的所有要素建立索引，层中的要素则分解到各单元中描述，最后将此描述信息写到索引表中。落到多个单元上的要素，将在每个单元对应的索引记录中加以描述，没有数据的单元不包括在索引表中。
简单说来， ArcSDE就是将底层的空间几何数据和空间属性数据关联起来，使空间数据在客户端表现为是一个连续地、无缝地地理实体，达到一体化的效果。
ArcSDE for Oracle是一个基于Oracle数据库基础上的地理数据库服务器，是对Oracle关系型数据库的一个扩展。采用ArcSDE管理地理信息数据，大大提高了空间数据的安全性、易用性和可维护性。
一体化空间数据管理的优势
借助数据库系统的逻辑检查功能，保证数据的录入和编辑质量。
支持大型数据库。arcSDE利用统一的数据模型，维护关系数据库中的空间和属性数据，管理近乎无限的空间特征，如:全国范围的土地利用现状和历史数据。
提供了网络环境下的数据操作。对复杂的空间查询来说，使用互操作处理的客户机/服务器模式在网络上得以实现，客户机与服务器共同完成这一工作。客户机主要是响应空间分析操作，服务器则进行数据搜索和检索。这种互操作处理方法使得动态空间叠加成为可能，当大量增加客户机的时候，利用对称多处理结构或调整计算机缓冲区大小，可以把客户机带来的性能下降到最小。
客户端工具的广泛性。用空间数据库所提供的API接口，客户端可采用任何GIS工具调用API服务，开发应用程序。
特征组是连续的，借助于底层的关系数据库强大的数据管理功能，实体—关系数据模型能容纳连片的数据区域，实现连续地理实体的物理级无缝存储。
支持多用户并发操作。许多用户能同时编辑地理数据。地理数据库数据模型支持多用户并发操作。
第四章 结论
4.1主要内容
运用ArcSDE8.2 for Oracle 将客户端程序和数据库关联起来,使Oracle数据库能够对空间数据进行一体化管理,完成客户端空间数据和属性数据的相关数据查询、空间分析等。
4.2 优点
使用ArcSDE数据模型将空间几何数据和空间属性数据关联起来，从而使空间数据在逻辑上形成一体化，简化了从数据底层到WEBGIS的过程,使结构更加紧凑。
4.3 存在的问题
SDE数据模型没有显式地存储空间拓扑关系，从而使空间分析过分依赖于客户程序(ArcMap)，对客户程序造成一定负担。
参考文献：
[1] Goodchild M. Future directions for geographic information science. Geographic Information Science, 1995 (1):1~7
[2] TAMAS ABRAHAM and JOHN F RODDICK. Survey of spatio-temporal databases. GeoInformatica, 1999,3(1):61~99
[3] ESRI.Spatial Database Engine. .1999.
[4] J.E.McCORMACK and J.HOGG.. Virtual-memory tiling for spatial data handling in GIS. COMPUTER & GEOSCIENCE, 1997, Vol.23(4): 659~669
[5] 边馥苓. 地理信息系统原理和方法. 北京:测绘出版社，1996，5
[6] 龚健雅. 当代GIS的若干理论与技术. 武汉:武汉测绘科技大学出版社，1999，44-46
关系数据库范文4
数据库技术在计算机网络设计中的应用类型根据模型的分类有关系数据模型数据库、层次数据库以及网状数据库等等。关系数据库在其中可以说是数学模型最完善，最利于管理复杂数据的一种数据库模型，才外，管理数据库还具有易于构建管理系统，编辑工具完整等特点和优势，因此，关系数据库模型被人们广泛的应用在计算机网络设计中。简捷的管理系统和完善的编辑工具是计算机网络技术数据处理有效性的决定因素，c语言程序设计是关系数据库中应用于计算机网络设计的主要部分，可以满足相关设计要求。计算机数据库包含两个数据访问系统，例如两个面向用户的独立系统：数据访问对象和开放数据库连接性，其中，前者是计算机网络设计的数据库机制，一个有多个数据访问对象构成的体系结构中，各个数据访问对象之间存在着协调工作的关系，因此操作方法更加优化，数据访问对象有相关的对象模型接口，数据访问对象不仅可以作为计算机的数据库操作机制，而且能提供嵌入数据和对象链接的数据访问接口，当数据库独立操作时会使得计算机网络设计的相关数据管理更加清晰和优化；后者定义了sQL语法规则以及c语言和SQL数据库间的程序设计接口，可以通过编程c语言程序来对开放数据库连接性的数据库管理系统进行访问，然而，由于关系数据库和应用程序之间存在开放数据库连接性的驱动器，再加上开放数据库连接性禁止利用数据库管理系统，导致数据库的访问速度有所减慢。关系数据库的应用能够有效地将相关设备的配置协议进行录入，其编程工具操作简捷的特点也时计算机网络设计的相关工作更加简单，方便操作。
2关系数据库在计算机网络设计中的功能和应用优势
2.1关系数据库在计算机网络设计中的功能
数据库的功能有很多，关系数据库在计算机网络设计中的主要功能就是辅助设计工作，计算机网络设计的资源来自于数据库，数据库的数据数据量大，而且具有特定的描述特征。将相关数据进行赋值与组合，得到计算机网络设计的参数信息，以便于计算机网络数据的输入，并解决相关设计问题。光纤是计算机网络设计中必不可少的应用，网络数据库的存在使光纤设计过程中的相关设备的数据能够结合并以较快的速度传播。在计算机网络设计中，关系网络数据库不仅能有效的将光纤传播速度、生产厂家、接入设备以及宽带和码率范围进行高效的输入，而且能准确的录入复杂的信息和相关设备的参数信息。总之，关系数据库在计算机网络设计中的应用不仅使设计操作简单方便不易出错，而且能够及时的发现数据输入时出现的错误并及时的解决，随着现代信息化的迅速发展和信息数据的不断更新，关系数据库也有助于计算机网络设计中网络拓扑映像的建立。
2.2关系数据库在计算机网络设计中的应用优势
关系数据库在计算机网络设计中的应用优势主要有两点，首先是关系数据库具有强大的数据存储功能，能够储存海量的数据，而且有利于数据快速有效的调用。在计算机的网络设计过程中能够利用关系数据库的辅助作用对大量且复杂的数据进行管理和操作，随着计算机网络数据的信息量不断增大，传统的数据管理方式不能有效、准确的进行管理，而利用关系数据库的辅助作用既有利于大量有关参数的管理，而且相关网络设计人员能够有效的将数据库中的数据进行录入，实现高效、快速的工作；其次，关系数据库有利于数据之间的转换，使计算机网络设计工作更加便捷。
3总结
关系数据库范文5
关键词:关系型数据库;加密;加密算法;粒度
中图分类号:F062.5文献标志码:A文章编号:1673-291X(2009)32-0258-02
数据库技术是信息系统的核心和基础,它的出现极大地促进了计算机应用向各行各业的渗透。数据库的建设规模、数据库信息量的大小和使用频度已逐渐成为衡量一个国家信息化程度的重要标志。在众多数据库模型中关系型数据库是现今使用最广泛、最容易理解和使用的数据库模型。大多数的企业级系统数据库都采用关系型数据库。下面本文就将对关系型数据库加密进行一些探讨性的研究。
1关系型数据库加密的必要性
关系型数据库系统的安全不仅依赖自身内部的安全机制,还与外部网络环境、应用环境、从业人员素质等因素息息相关。因此,从广义上讲,数据库系统的安全框架可以划分为三个层次,即网络系统层次、宿主操作系统层次、数据库管理系统层次。
这三个层次构筑成数据库系统的安全体系,与数据安全的关系是逐步紧密的,防范的重要性也逐层加强,从外到内、由表及里保证数据的安全。但是,值得注意的是OS和DBMS对数据库文件本身仍然缺乏有效的保护措施,无法阻挡对数据文件本身的攻击。最简单的,如有人偷走了存放数据文件的硬盘,则文件中的信息将被泄露。
据有关资料报道,80%的计算机犯罪来自系统内部。在传统的关系型数据库系统中,数据库管理员的权力是至高无上,他既负责各项系统管理工作,又可以查询数据库中的一切信息。为此,不少系统以种种手段来削弱系统管理员的权力。实现关系型数据库加密以后,各用户(或用户组)的数据由用户用自己的密钥加密,数据库管理员获得的信息无法进行正常解密,从而保证了用户信息的安全。
2关系型数据库加密的要求与限制
2.1关系型数据库加密的要求
由于关系型数据库本身的特点和实际应用需求,对关系型数据库加密一般应实现以下功能:
(1)由于关系型数据库数据信息的生命周期一般比较长,所以加强加密的力度,难以破译;
(2)数据信息在加密后,不能明显地扩大存储空间;
(3)不能影响数据库的使用速度,即加/解密速度都应足够快;
(4)加密系统应同时提供一套安全的、灵活的密钥管理机构,提供灵活的加密要求满足;
(5)加密后的关系型数据库仍能满足用户在不同类别程度上的访问。
2.2关系型数据库加密的限制
数据加密通过对明文进行复杂的加密操作,以达到无法发现明文和密文之间、密文和密钥之间的内在关系,复杂性已经破译的难度要求足够高,也就是说经过加密的数据经得起来自DS和DBMS的攻击。另一方面,DBMS要完成对数据库文件的管理和使用,必须具有能够识别部分数据的条件。因此,只能对数据库中数据进行部分加密。以下几点是我们在给关系型数据库加密时应该注意的问题。
(1)索引字段不能加密
为了达到快速查询的目的,关系型数据库文件需要建立一些索引,它们的建立和应用必须是明文状态,否则将失去索引的作用。
(2)关系运算的比较字段不能加密
DBMS要组织和完成关系运算,运算的数据一般都要经过条件筛选,这种“条件”选择项必须是明文,否则DBMS将无法进行比较筛选。
(3)表间的连接码字段不能加密
关系型数据库中表之间存在着密切的联系,这种相关性往往是“外部编码”联系的,这些编码若加密就无法进行表与表之间的连接运算。
3关系型数据库加密方式
关系型数据库加密方式数据库加密,主要分为两种方式:DBMS外部加密和DBMS内部加密。
3.1 DBMS外部加密
DBMS外部加密的优点是,不需要修改DBMS,只需要在应用程序或者操作系统中增加相应的加/解密模块即可。但是,这种方法也有一些缺点,首先它不能支持各种加密粒度。其次,它仅仅对用户数据进行加密,而不能对元数据、索引数据、日志等进行加密。因此,安全性受到影响。再者,数据的完整性检查需要应用程序来完成,不能尽量发挥DBMS的作用,因为数据加密后,没有办法在DBMS完整性检查,而需要在应用程序中增加这项功能,实现起来非常麻烦。
3.2 DBMS内部加密
一般选择在数据物理存取之前进行加/解密操作。这种方法的优点是,由于DBMS能够区分各种粒度的数据,所以,可以支持各种粒度的加密,加密粒度可以灵活地选择。另外,在DBMS内部实现加密,可以更有效地利用DBMS内部的访问控制机制、授权机制等各种功能。更重要的是,关系型数据库一个重要特点是被多个应用共享,这种方法的加解密都是在DBMS内部完成,对应用程序是透明的,不需要在多个应用中进行修改,使用起来比较方便,且容易保持数据的一致性,缺点是需要修改DBMS的内核。关系型数据库的关键术语有:数据库、表、字段、行和数据元素。基本上可以针对这几方面形成一种加密的方法。
(1)数据库级
加密的对象是整个数据库,对数据库中所有的对象进行加密处理。这种加密方法只需要对存储在磁盘中的相应数据库文件进行加密处理即可,密钥的数量少,便于管理。但是,采用此加密粒度,对性能会带来很大的影响。即使只需要查询一条记录,也需要对整个数据库进行解密。这样,访问的速度不可避免的要降低。
(2)表级
加密的对象是数据库中的基本元素表。关系型数据库包含多个表,并不是所有的表都有很高的安全需要,因而只需要对其中一些包含敏感信息的表进行加密。与数据库级加密相比,采用表级加密粒度,系统的查询性能会有所改善,因为对于未加密表的查询,系统性能不会受到影响,对于加密表的查询,只需要解密对应的加密表,而不要解密整个数据库。但是,这种方法与DBMS集成时,需要对DBMS内部一些核心模块进行修改,这些工作是很困难完成的。
(3)记录级
加密的对象是数据表中的记录,即对整条记录一起进行加密处理。在实现记录级加密时,通过调用专门的加密函数,对记录进行加密。与数据库和表级加密相比,这种加密的粒度更细,可选择的灵活性更好。但是,它和表级加密一样,这种方法也需要对DBMS内核进行修改。
(4)字段级
加密的对象是关系中的某个字段,即表中的列。一张表包含多个字段,在某些时候,并不是所有的字段都需要加密。因为在实际生活中,一些重要和敏感的信息往往出现在关系中的某些列,只需要对这些重要数据进行加密保护,而不用对所有字段。在实现字段级加密时,可以采取多种方式,既可以在DBMS外部完成,也可以在DBMS内部完成。
(5)数据项级
加密的对象是记录中的某个字段值,它是数据库加密的最小粒度。数据项级加密的方法更为灵活,它的实现方式与字段级加密相似,但其密钥管理将会更加复杂。
4加密算法比较
加密算法是一些公式和法则,它规定了明文和密文之间的变换方法。密钥是控制加密算法和解密算法的关键信息,它的产生、传输、存储等工作是十分重要的。
DES算法,DES(Data Encryption Standard)是把64位的明文输入块变为64位的密文输出块,它所使用的密钥也是64位,但只用到其中56位。Des的密码学缺点是密钥长度相对比较短,因此,人们又想出了一个解决其长度的方法,即采用三重DES,三重DES是DES的一种变形。
RSA算法,它是第一个既能用于数据加密也能用于数字签名的算法。RSA的重大缺陷是无法从理论上把握它的保密性能如何,而且密码学界多数人士倾向于因子分解不是NPC问题,RSA算法是第一个能同时用于加密和数字签名的算法,也易于理解和操作。
AES算法,将在未来几十年里代替DES在各个领域中得到广泛应用,总体来说,AES作为新一代的数据加密标准汇聚了强安全性、高性能、高效率、易用和灵活等优点。AES设计有三个密钥长度:128、192、256位,相对而言,AES的128密钥比DES的56密钥强1 021倍。AES算法主要包括三个方面:轮变化、圈数和密钥扩展。
5结束语
上面介绍的只是关系型数据库加密方法的一些探讨性研究,这些论述还远远没达到关系型数据库安全需要,比如现在的关系型数据库基本都给与网络架构,网际的安全传输等,也是要重点考虑的方面,等等。一个好的安全系统必须综合考虑如何运用这些技术,以保证数据的安全。
参考文献:
[1]胡志奇.数据库安全与加密技术研究[J].计算机与现代化,2003,(11):24-3.
[2]王晓峰,王尚平,秦波.数据库加密方法研究[J].西安理工大学学报,2002,(6):68-73.
关系数据库范文6
关键词：查询优化；代数优化；查询树
中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2016）26-0008-02
1 引言
关系数据库是当今应用最广泛的数据库系统。关系数据库支持关系数据模型。关系数据结构非常单一，现实世界中的实体及实体之间的联系都是用关系来表示，在用户看来，关系数据结构就是二维表。常用的关系操作包括查询操作和插入、删除、修改操作两大部分，其中查询操作的表达能力最重要。数据查询是数据库应用中非常重要的组成部分，数据查询是否具备较高的执行效率和反应速度受到数据库设计者和用户的极大关注。
2 不同查询方案代价对比
关系模型中的查询语言早期通常是用代数方法或逻辑方法来表示，分别称为关系代数和关系演算，随后出现一种介于关系代数和关系演算的语言称为结构化查询语言，简称SQL。SQL语言作为关系数据库的标准语言向用户提供了易于掌握、高度非过程化得查询语言。大多数商用数据库都支持SQL语言，用户只需指明“干什么？”不需指出“怎么干。”对同一个查询要求有不同的查询解决方案，查询优化就是尽量在不同的解决方案中找到效率高、代价小的方案。
为了提升数据库系统性能对数据查询进行优化成了必须解决的问题，查询优化技术的发展与应用，也助推了数据库技术的推广与普及。
下面我们通过一个实例对比不同查询方案所花费的代价。
商品销售管理数据库
销售点信息表（销售点编号，城市、地址，联系电话，开设时间）
产品信息表（产品编号，产品名，类型，规格，生产厂家，进货价格）
销售情况表（销售点编号，产品编号，销售量，销售单价）
求销售产品编号为’JD051’这种产品的销售点信息？
用SQL语言表达该查询：
Select 销售点信息表.*
From 销售点信息表 ， 销售情况表
Where 销售点信息表.销售点编号=销售情况表.销售点编号 and 产品编号=’JD051’
SQL语言是高度的非过程化语言，同一个查询要求可以有不同的执行方式。下面针对上述查询要求运用关系代数表达式来表示不同的执行方式。
方案1
Π销售点信息表.*（σ销售点信息表.销售点编号=销售情况表.销售点编号∧销售情况表.产品编号=’JD051’（销售点信息表×销售情况表））
第一种方式需要占用内存空间保留广义笛卡尔积的中间结果，读取数据量过多及耗时较长；
方案2
Π销售点信息表.*（σ产品编号=’JD051’（销售点信息表∞销售情况表））
第二种方案相比第一种方式减少了中间结果，使用自然连接相比笛卡尔积大大减少了中间结果；
方案3
Π销售点编号（σ产品编号=’JD051’ （销售情况表））∞销售点信息表
第三种方式减少了数据读取量，中间结果相比第二种情况更少。总的查询时间最短、查询代价最少。
以上三种表达式虽然等价，但其执行的查询策略不同，数据规模越大，查询所花费的代价差别就越大。通过三种不同查询方式的对比，说明查询优化的必要性，选择合适的查询策略将大大减少查询时间、降低查询代价，因此查询优化问题一直是数据库研究的重点。
3 关系数据库查询处理过程
当用户发出查询请求，要采用不同的处理步骤对原始查询进行转换，这些转换工作必须在系统处理查询请求和返回查询结果前完成。关系数据库查询处理过程如图1所示。
图1
主要步骤：语法分析与翻译处理，查询优化处理，执行。
4 查询优化技术分类
查询优化技术一般分为代数优化和非代数优化（物理结构优化）。
1）代数优化，通过对查询语句进行变换，改变基本操作的次序，使查询语句执行起来更有效，这种查询优化仅涉及查询语句本身，而不涉及实际存取路径，称为独立于存取路径的优化，或代数优化。
查询是由高级查询语言表示的对数据库的一个或一组操作的集合，通常由投影、选择、连接、笛卡尔积等操作符组成。通过语法分析功能分析查询语句的正确性、完整性、有效性，并将其转换为等价关系代数查询树，如图2。
根据关系代数等价变换规则，查询树可以按以下方法进行变换：
方法1：下移选择和投影运算，以减少中间结果的元组数和参与运算的关系的规模；
方法2：将某些选择运算与笛卡尔积运算相结合；
方法3：同时执行同一个关系上的选择、投影运算，减少对关系的扫描次数；
方法4：将连接运算与投影运算结合起来执行。
图2可变换为图3。
对比图2和图3选择运算和投影运算优先执行，减少了查询中间结果的元组数，大大降低了参与连接运算的关系规模。
在制定具体的查询策略时应尽量减少对数据表的访问，减少对磁盘的访问次数，访问磁盘所需的时间大大长于对内存的访问时间，减少对磁盘的访问次数将大大降低系统的响应时间。选择运算尽可能提前做，往往可以使执行时间降低几个数量级，通过选择运算减少中间结果。在执行连接操作前，对关系进行适当的预处理，在连接的字段上建立索引以及对关系进行排序，加快查询速度。
关系代数优化的一般步骤：[3]
（a）把查询转换成语法树；（b）优化语法树；（c）选择低层次的存取路径；（d）选择代价较小的查询方案。
2）非代数优化，也称物理结构优化。数据库物理结构是整个数据库存储的基础，物理结构设计是在逻辑结构设计的基础上完成的，应确保数据库存储和访问或操作数据表具有较高的执行效率。物理结构优化是指为数据库系统的数据推荐合适的物理存储位置或存储结构，以及为查询推荐合适的存取路径，进而提升系统的整体性能。
5 小结
查询优化技术是数据库中一项重要的技术。对于的查询要求，我们应该根据数据规模大小，具体的物理存储结构等因素进行分析，选择合适的查询策略。具体的SQL查询语句应根据代数优化的相关原则进行变换，提高查询效率。查询优化目的是为了提升系统的性能，如果进行优化本身需要花费的代价过大，反而会降低系统的性能。所以只有兼顾了查询效率、控制系统开销、保障数据库安全等诸多方面才能真正地优化系统的性能。
参考文献：
[1] 冯卫兵.关系数据库的查询优化[J].现代计算机，2010（1）.
[2] 王能斌.数据库系统原理[M].北京：电子工业出版社，2001.
[3] 萨师煊，王珊. 数据库系统概论[M].3版.北京：高等教育出版社，2000.
[4] 谷震离.关系数据库查询方法研究[J].微计算机信息，2006.
[5] 崔跃生，张勇，曾春，等.数据库物理结构优化技术[J].软件学报，2013，24（4）.
