关系数据库模式

关系数据库模式（通用10篇）

关系数据库模式 篇1

摘要：时空数据库技术的研究,是“数字城市”信息共享领域中极其重要的基础性研究,本文通过分析比较现有空间数据库建设模式的优劣,提出一种基于“后关系数据库”的“时空数据库”新模式,并进行了实验验证。

关键词：后关系数据库,时空数据模型,模式研究

随着“数字城市”建设进程的不断加快,空间信息与各行业应用领域处于相互融合的快速变化中,要求空间数据库不仅能更加快捷、更加便利、更加真实地表述地理空间世界,而且能表示空间世界随时间的变化。因此,深入研究面向对象的时空数据库技术及其建设模式十分必要。

1 时空数据模型及其建库模式分析

1.1 时空数据模型基本概念

时空数据模型是对地理空间世界的抽象,是时空数据库设计的基础。从地理世界到计算机世界,可粗略地划分成两个层次:第一层是时空数据概念模型,其目的在于提取地理世界的主要特征(空间、时间、属性);第二层是时空数据组织模型,是时空数据概念模型在计算机中的具体实现[1]。时空数据模型除了具备静态GIS的所有功能外,还应具备如下特点:

(1)时空特征:不仅可表达地理实体的空间分布,还可以反映实体的状态和演变过程;

(2)历史回溯:利用GIS数据的时间记录,实现任意时刻的历史回溯;

(3)时序分析:以原始为基准,考察变化,预测未来,提供辅助决策;

(4)动态更新:时态的引入,将使地理空间实体具备“动态更新”的先天条件。

1.2 时空数据建库模式分析

根据目前数据库技术现状,时空数据库模式可分为三类:

(1)基于对象关系映射技术(OR)

在关系数据库占据了统治地位的背景下,人们采用关系概念存储面向对象的数据。GIS也不例外,例如:ArcSDE、SuperMap SDX+、Oracle Spatial等都是在RDBMS基础上,通过对象关系映射技术实现空间对象的存储和访问[2]。

虽然目前有较成熟的市场产品,但它不能很好地模拟地理实体的时空特征,一些扩充了时态属性、专题属性与GIS核心结构难成一体,不同部门针对自己的需求不得不建立了各自独立的GIS应用系统,这是造成信息孤岛的主要原因之一。

(2)基于面向对象数据库管理系统(OODBMS)

面向对象数据库管理系统,以纯粹的面向对象语言为基础, 它利用类的设施来描述复杂对象。在表达时空数据类型时可以做到游刃有余,在应用系统开发速度和维护等方面也有极大的优越性。但这种纯粹的面向对象数据库系统并不支持SQL语言,在兼容性方面失去了优势。

(3)基于XML数据库管理系统(XBS)

XML数据库是随着Internet的迅速发展以及XML语言的出现,而产生的新型数据库。代表性产品有九十年代末德国Software AG发布的“原状XML数据库系统”:Tamino,有关学者在Tamino中存入GML数据,但实验表明:若要构建大型的空间数据库系统,性能尚不如人意 [3]。

2 后关系数据库管理系统(Post RDBMS)简介

后关系数据库是以网络为中心的第三代数据库,代表产品是InterSystems公司 Caché,它采用稀疏数组为基础的多维数据库架构,取代了传统的两维表形式,既是一种高性能的面向对象数据库,又针对市场的需要其内部集成了SQL访问[4]。主要特点是:

(1)全面采用了面向对象模型,包括封装、嵌入对象、多继承、多态性和集合,对象世界的一切特点它都具备,并且实现得很好,Caché数据模型使之存储的数据更接近现实世界。

(2)通过使用稀疏数组方案,不需要进行复杂而耗时的表联接就可以访问或者更新数据,使数据库上的处理消耗大大降低,据有关文献记载它们的平均性能比关系型数据库提高了20倍。

(3)全面支持SQL的访问方式,Caché通过统一数据结构,提供了对ODBC和JDBC的高性能驱动程序,在应用端可以象访问关系数据库一样访问Caché数据库。

由此可见,对于构造时空数据库而言,Caché比其它数据库系统更为有利。

3 基于Caché的时空数据库设计与实现

3.1 时空数据模型选择

STC(Space-Time Composite)和STO(Spatio-Temporal Object)是矢量型时空数据的代表性模型。STO 模型认为世界是由一个个时空原子(Spatio-Temporal Atom) 组成,时空原子为时间、空间和属性相同的均质实体。从建立数据模型的角度,时空原子可看作是空间对象(Spatial Object:SO)、时态对象(Temporal Object:TO)和属性对象(Attribute Object:AO)的抽象[5][6],即:

STO =〈 STOid, SO, AO, TO 〉,其中STOid 为时空对象的唯一标识。

以下是本文具体采用时空数据结构:

(1)STOid:本文采用全球唯一标识。

(2)SO:为具有一般性,采用业界广泛接受的OGC执行标准:OpenGIS Simple Features Specification Revision 1.1 [7] ,如图1所示。

(3)AO:根据专题应用的具体内容而设计,例如:世界地图City图层的属性结构包括:CityName、AdminName等等。

(4)时态数据类型可定义为时间点( Instant) 、时态区间( Interval) 、时变序列(Sequence)、时态周期(Period)四种基本类型。其中, Instant有日期(Date)、时间(Time)、日期时间 (DateTime) 三种形式;Interval 则由一个称其为起始时间( Ts) 和终止时间( Te)构成的左闭右开实数区间;Period 由多个互不相交的Interval 序列构成,它刻画客观对象间歇性的再现现象,如地震灾害等。

另外为保证时间参考标准的一致性,需要扩展一个时态参考对象,保存系统采用的时间标准、时间粒度等信息。

时态对象的层次模型如图2所示。

3.2 STO模型在Caché Studio中实现

Caché数据库提供了完全面向对象数据库设计环境 Caché Studio, Caché类不仅支持常规属性和方法,还支持索引和SQL查询。以下列举“城市对象”的实现代码如下:

Class Spatial.City Extends %Persistent [ Owner = _SYSTEM ]

{

//标识:

Property STOid As GUID;

//空间:

Property Geometry As Point;

//时态:

Property Temporal As Interval;

//属性:

Property CityAttr As Attribute;

//时间索引:

Index TsIndex On Interval->Ts;

Index TeIndex On Interval->Te;

//空间索引:

……

//空间查询

Query QueryByRectangle (Xmin As %Float, Ymin As %Float, Xmax As %Float, Ymax A s %Float ) As %SQLQuery

{...... }

//时间查询

Query QueryByTemporal ( T0 As %DateTime ) As %SQLQuery

{...... }

}

为使空间查询过程简单化,仅建立了时空对象的矩形(Rectangle)索引,同时定义以下查询功能:

(1)QueryByRectangle:可查询指定矩形区域的时空数据;

(2)QueryByTemporal:实现T0时刻的历史回溯,数学表达式是:

Dataset(T0)= { 时空数据库:Ts < T0 ∩ Te > T0 }

4 建库试验及其性能评价

4.1 试验系统的建立

为验证上述时空模型的正确性,作者使用InterSystems公司提供的 Cache Provider Managed for .Net工具,实现了Caché时空数据库存储、查询、获取等操作接口,同时利用GIS开源代码Sharp Map实现时空数据的浏览(如图3所示)。以上功能均在Microsoft .NET Studio 2005 环境下开发完成,由于采用完全面向对象的方法,避免了传统关系型数据库复杂的数据库操作,代码量很少。

4.2 性能评价

采用福州市1:500地形图shape数据2KM2试验数据,进行存取操作,存入时用事务时间模拟时空对象的起始时间。将试验结果与Esri ArcSDE的同类操作时间比较(如表1),初步结论:完全面向对象Caché存入和获取效率不如ArcSDE,访问效率相当。

5 结论与展望

综上所述,本文主要研究结论可归纳如下几点:

(1)Caché数据库系统提供的完全面向对象的数据模型,方便地实现了时空对象的时间、空间、属性三者的统一,使我们可以更加真实表达地理空间世界。

(2)由于采用完全面向对象的方法,避免了传统关系型数据库复杂的数据库操作,开发效率较高,系统管理维护简单。

(3)综合运行效率尚不如商业SDE,数据模型有待于优化。

本文的研究,是对Caché技术与GIS技术相互融合的初步探索,还有许多问题需要进一步研究才能满足工程应用的需要,例如:建立更高级的空间索引;实现更加科学的时态功能;以及Caché特性的充分利用等。谨此抛砖引玉,希望引起有关学者的关注。

参考文献

[1]99-AS-RFP009(Frozen 24 June 1999).OGC,OpenG IS AbstractSpecification[S].

[2]冯敏,尚庆生,郭建文,盖迎春.空间数据库引擎ArcSDE访问接口的.Net环境封装研究.遥感技术与应用.2004,19(05):368-373.

[3]史婷婷,李岩,王鹏.基于GML空间数据存储方法研究与实现.计算机应用,2006,26(10):2408-2412.

[4]Intersystem Inc.Caché5.1技术白皮书.2006年7月.

[5]易宝林,冯玉才,吴永英.一种集成时空数据模型及语义扩展.华中科技大学学报(自然科学版),2004,32(7):7-9.

[6]曹志月,刘岳.一种面向对象的时空数据模型.测绘学报,2002,31(1):87-91.

[7]99-AS-RFP009(Frozen 24 June 1999).OGC,S imple FeaturesSpecification Revision 1.1[S].

关系数据库模式 篇2

关键词 XML 关系数据库 映射

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

由于数据库技术本身的发展和数据库市场的变化，使得越来越多的应用需要在异构数据源之间进行访问，XML技术便应运而生。然而，目前大部分应用的数据存储在关系数据库中，XML数据又以XML文档形式存在，因此，研究XML文档与关系数据库的转换对异构数据源之间的数据集成非常重要。

1 XML与关系数据库的比较

由于传统的各数据库管理系统之间的异构性及其所依赖操作系统的异构性，很难实现在异构数据库之间进行通信，同时对关系数据库的访问还依赖于系统对ODBC的支持程度，即便如此，很多防火墙不允许这种信息转换，而且还容易被攻击。XML具有无可比拟的优势，一方面，利用XML文档，开发人员可以编码任何关系数据库中的面向记录的数据，并很好地保持这些数据的逻辑结构，甚至可以根据实际应用的需要更改这些数据的逻辑结构。另一方面，XML文档具有透明性和平台无关性，独立于传输协议，可以使用FTP、HTTP、RPC 等多种方式传输，发送端和接受端无须关心数据是来自于什么平台以及是如何产生的。

但是，XML作为一种形式语言，以文本的形式对数据进行描述，存在管理和检索上的困难，仍然无法完全取代数据库。首先，数据库具有灵活而高效率的数据操作手段，可以处理海量的数据信息。就XML文档而言，目前主要通过XML解析器提供的API来实现对文档数据的访问，但随着XML文档的数据量增大，这种方法的效率明显不如访问数据库的效率高，而且XML文档数据的维护也更加困难。其次，从并发性来说，关系数据库本来就被设计为允许多个用户同时处理信息，但目前对XML文档的访问不具备并发性。最后，从安全性来说，数据库拥有一个很好的安全控制体系，允许用户对数据进行不同级别的处理，而这也是XML文档所不具备的。

2 XML数据的关系存储

XML数据源有XML纯文本文档、关系型数据库以及其他应用数据几类。由于XML数据源的不同，关于XML存储的研究目前大致分为四个方向：利用文件系统存储XML数据的研究；利用面向对象数据库存储XML数据的研究；用关系数据库存储XML 数据的研究；专门设计的XML（NXD） 存储策略。针对于XML具体应用，在存储XML文档的数据库技术上，形成了两大阵营。一种阵营主张在原有的传统关系数据库基础上，通过扩展XML支持模块或中间件，来完成XML数据和数据库之间的格式转换和传输；另一种阵营主张利用NXD技术来解决XML文档的存储管理。用关系数据库来存储XML数据，可以利用现有数据库的存储管理、并发控制、恢复、版本机制等技术有效地管理数据，并使用SQL查询作为数据存取的方法，所以用关系数据库来保存和处理XML数据是很有效的方法。利用关系数据库来存储XML数据的方法是XML半结构数据转换为结构化数据后存储于二维表中，来实现对XML数据的存储和管理。由于XML和关系数据库数据模式的互异性，不能简单地将XML文档存储于关系数据表中，为了实现在XML文件和数据库之间交换数据，必须提供一个XML映射层，将XML文档模式（DTD、XML Schema）映射到关系数据库模式。

3 XML与关系数据库的映射方法

一个具体的XML模式到关系模式的数据转换需要涉及较为复杂的XML格式分析处理及相应的数据库操作和有效性校验。两者之间的映射为双向映射，根据映射关系的建立方式不同，主要存在两种方法：基于模板驱动的映射和基于模型驱动的映射。

（1）基于模板驱动的映射

XML文档包含简单元素和复杂元素两类，简单元素包含的内容是不具层次结构的简单内容，而复杂元素可包含属性、子元素，还可以包含多个子元素，其中子元素还可以是复杂元素。基于模板驱动的转换方法是一种浅层映射，只能用于从其他类型数据到XML文档之间的数据传递，并不支持面向对象之间或者关系与对象之间的信息交互，它无需提前定义好XML文档和其他数据之间的映射，只需在XML文档模板中嵌入一些SQL命令，这些命令在转换时被系统识别和执行，把执行的结果替换到指令的位置，生成最终的XML文档即可。

（2）基于模型驱动的映射

关系数据库模式 篇3

一、XML及DTD技术简单介绍

XML是互联网环境中跨平台、依赖于内容的技术,是当前处理结构化文档信息的有力工具,它使用一系列简单的、用户可自行定义的标记描述数据;以文本文件的形式存储数据,不受操作系统和软件平台的限制,非常适合于异构数据的交换,目前大量的业务系统都采用XML技术进行数据的交换、存储和展示。

DTD(Document Type Definition)是一套关于XML的语法规则,在XML1.0版中,它是XML技术的一部分,它描述和规范了XML文档的逻辑结构、提供了XML文档的验证机制(关于XML的规范、验证技术还有XML Schema),使得XML能够成为数据交换的标准。(图1和图2给出了XML和DTD的样例)

从图1的示例可以看出,XML文档以树状层次结构组织数据,其根元素(orders)包含了若干个子元素(order),子元素(order)又包含了其他的子元素(cust_id,acct_id,inst_id,acc_nbr,fee),结构十分清晰,且各个元素可以由用户自行定义,含义明确,具有良好的开放性和扩展性。

XML以DTD(或XML Schema)来描述、定义其逻辑结构(包括定义XML中的元素、元素类型、元素的上下级关系、属性及其顺序关系等等,如图2)。

而对于XML文档数据的解析、存取,从编程接口来说,有DOM和SAX两种主流的操作方式:DOM(Document Object Model)以树形结构加载整个XML文档,提供了直接获取和操作文档中各个组成部分的API;而SAX(Simple API for XML)则提供了一种事件驱动型的XML标准接口,不需要在内存中构建整个XML树,但是不允许开发人员实际更改原始XML文档中的数据。

二、关系型数据库中的两种XML存储模式

关系型数据库技术是当前最为成熟的数据库技术。商用关系型数据库系统都具有高性能的查询引擎、良好的可扩展性、安全性和健壮性,因此利用关系型数据库系统管理XML数据可以重用数据库的查询优化器和事务处理机制,能够保证XML数据的一致性和完整性;同时,目前大量的应用系统的数据主要都是存放在关系数据库中,将XML数据存储在关系数据库中,可以将XML数据融入到应用系统的其他数据中,便于系统数据的管理和使用。

由于XML采用树型结构组织数据,而关系型数据库采用平面的二维关系存储数据,两者在数据组织结构方面存在差异,所以利用关系型数据库存储XML数据的基本思想就是通过将XML模式向关系模式进行映射来完成数据的存储,而从映射的粒度来说,可以分为文档存储模式和元素存储模式两种(下文中关于关系型数据库的描述以oracle数据库为例)。

1. 文档存储模式:

文档存储模式是将整个X M L文档作为存储对象,直接将XML文档构造为数据库中的一个字段。如图1中的文档可以直接映射为一张关系数据表t_orders的order字段,具体的操作方式如下:

①首先创建关系表:Create t able t_orders(id number(10),odr blob);

②然后将orders.xml的内容直接写入到odr字段中(blob是oracle数据库用来存储大对象的字段类型,其他商用关系型数据库对大对象都有类似支持)。数据库中的存储结构如图3:

2. 元素存储模式:

元素存储模式则是按照xml数据的结构,在关系型数据库中建立起与其结构对应的、具备父子关系的多张关系表,如图1中的文档可以映射为t_orders表和t_order表,具体操作如下:

①首先创建关系表:

②然后将orders.xml的内容根据结构关系写入到表中。数据库中的存储结构如图4:

三、两种存储模式的对比分析

上述两种存储模式虽然都是采用关系型数据库的表来存储XML数据,但在具体操作上有本质的区别,且各有不同的应用场景和数据使用方法:

第一种模式将整个XML作为一个整体存储,不利于利用关系型数据库的标准查询语言进行数据元素的检索,然而在具体应用系统中,特别是在不同应用系统之间利用XML格式进行数据交互的场景下,由于在生产环境下数据库表结构的修改很多时候比XML结构的修改成本更高;而且在复杂的应用环境下,确实有时候是需要利用XML存储半结构化或者非结构化数据的;另外很多商用关系型数据库(如oracle)本身提供了利用XPath等技术对XML文档进行操作的手段,所以该模式也还是有其应用场景的。

第二种模式将XML数据映射成了关系型数据库中的若干张表,也就自然而然地继承了关系型数据在数据检索、查询优化、事务管理等方面的诸多优势,在纯粹利用XML存储结构化数据的场景下有很大的优势。

所以在实际的应用系统设计过程中,针对XML数据的存储方案需要根据实际的应用情况来确定,只有对系统情况进行了详细分析,才能在不同的应用场景下采用最合适的存储方案,另外,也可以尝试一种折中的存储模式即文档存储模式与元素存储模式相结合的方式,具体可以参考文献[5]等相关技术资料。

四、结束语

应用系统的日新月异推动了数据表示和存储技术的发展,XML的易扩展性、灵活性使得其在当前应用系统的数据表示和存储方面发挥了巨大的作用。利用关系型数据库进行XML数据的存储,更是提高了数据的安全性和检索速度,另外由于目前大部分应用系统的业务数据都是存储在关系型数据库上的,所以利用关系型数据库存储XML数据也可以将整个系统的数据类型、查询方式、管理手段统一起来,有利于系统的数据管理。

参考文献

[1]罗军珍,XML在关系数据库中存储方法的研究,重庆大学,May2005。

[2]翁亮,曾昭平,XML技术分析,计算机与网络。2000(1):24-25。

[3]严海兵.基于数据集的X M L数据存储技术[J].2006,23(3):68-70。

[4]万常选,XML数据库技术。清华大学出版社,2005。

[5]杜向华.几种X M L数据存储技术[J].科技信息,2007,(2):190-190.

关系数据库模式 篇4

关键词：面向对象；关系型数据库；映射；类；属性

中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2016）20-0012-02

1 引言

面向对象（Object Oriented，OO）是把面向对象的思想应用于计算机软件开发中，以对象为内核，以类、继承、封装、多态等概念构造系统，进行客观事物的软件开发设计的一种方法。面向对象，对象其实就是一个封装体，包含数据和控制命令。随着计算机技术和开发软件的不断升级，面向对象的方法和应用已经不仅仅局限于软件开发和程序设计，已经逐渐扩展到数据库系统、分布式系统、网络管理、人机交互等计算机领域，甚至对人工智能、计算机辅助工具、信息系统等產生深远影响。计算机和网络都离不开数据库，面向对象的广泛应用，也给数据库技术增添了新鲜血液。面向对象方法与数据库技术，尤其是关系型数据库如何有效结合，更好的支持数据库的应用，是一个非常值得研究的课题。

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

2.1 关系型数据库

电子商务、云存储、云计算等计算机信息系统，已经是当今信息技术的重要手段，而数据库技术是计算机系统的重要组成部分和核心内容。数据库类型有网状、层次和关系几类，其中关系型数据库以其集合的操作方式得到了最为广泛的应用。关系型数据库是一种建立在关系数据库模型基础上的数据库，用集合代数方法对数据库单元中数据进行处理，是一组相互之间有关联关系的表，表的关系通过相关字段进行关联，表中的数据可以根据需求情况进行存取且不用重新组织数据库表格。新建一个关系型数据库时，每一行包含一个数据实体，是被列定义的种类。目前应用较多的数据库有oracle、sqlserver、mysql等。

2.2面向对象分析法

面向对象分析法（Object-Oriented Analysis，OOA），是指一个软件开发项目在开发过程中，首先要对业务情况进行调研，然后用面向对象的思想对该项目业务进行归纳、分类、分析。OOA强调的是业务对象之间的关系以及对象的属性和行为。面向对象分析法使用户和设计者之间的沟通更容易，设计者能够更好地理解用户的需求，设计者了解了用户的需求，才能更好地设计出用户与数据库之间的映射方式，从而设计出用户满意的数据库。

OOA方法的程序设计，从结构框架来说，一个是针对开发者的外部层，外部层是应用程序的整体设计；内部层针对物理存储，称为物化视图，是基于远程表格的，也可以称之为快照；概念层介于外部层和内部层之间，是内外部的映射，用DDL表示，概念层是关系型数据库的真正表现形式。对象与关系型数据库通过映射发生关系，映射方法就是将关系型数据库进行概念层的设计。从对象到关系型数据库的映射内容包括：属性与列的映射，关系型数据库中的继承，类与表的映射，映射的关联，聚合和组合以及实现关系等。

将对象建模和映射的过程就是将对象转换成概念层的数据库模型，对象模型转换为关系型数据库的映射有如下关系：

1）每个对象是唯一的，有唯一的标识符，具有唯一性。对象的标识一般用主键或者是系统自动生成的伪标识符来标识，而不是通过描述对象的属性来标识。

2）类与关系型数据库中的表的转换，可以通过直接调用表的名称，或者可以通过在类的名称前加前缀的方式修改成表的名称来实现。

3 基于面向对象技术的关系数据库的设计方法

3.1 整体思路

基于面向对象技术的关系型数据库的设计方法，首先要确定应用程序中的领域类，领域类中将数据信息和对数据的操作、调用方法进行了封装。领域类实例化，就得到对象，因此，需要提前把对象的存储、地址、检索方法、调用方法等问题设计好，做好准备工作。

在面向对象的关系型数据库中，数据通过对象形式存储到数据库中，并且对象之间的关联关系是自动存储的。关系型数据库本身不存在集合和分解的问题，可以由与对象相关的状态图像构成。面向对象的关系型数据库是通过对对象进行查询、检索、调用的，不存在对某个表的一行或一列进行某些操作。因此需要提前定义对对象的各种操作方法。比如：writeObject（）是一个写入并存储一个对象及所有对象相关；read Object（）是读取一个对象及所有对象相关。每个对象有唯一的标识ID，在写入和读取时通过唯一的标识ID进行。

以消费者对电子账户的写入、读取操作为例子，来说明面向对象数据库数据存储模式，如图1所示。将消费者对电子账户的操作对象的属性描绘成字段，指向其他对象需要映射到相应的外部关键字上，此处的操作动作不能封装。数据库中的每一个表对应一个类，对数据库中的表的操作设定为函数。

3.2 对象映射成关系数据库

RDBMS的表都是二维表，一个二维表是一个管理单元，二维表及表与表之间的关联关系用来描述对象模型的属性，即对象模型与关系型数据库的映射关系。将每个对象的类存储到数据库的表中，一个类对应一个对象实例，并进行存储。不仅对象实例映射到关系型数据库中，对象之间的关联关系也要映射到关系型数据库中，这样才能进行后续的操作。

对象之间的关系有四种：关联、继承、聚合、组成。关联是关系型数据库中对象之间的关联关系，聚合不仅需要对关系型数据库的整体进行操作，还需要对部分进行操作，即读取时需要整体读取的同时也需要在部分数据中进行读取。关联是不需要的，在关联中存储和读取的执行操作不明显。关联和聚合的区别在于对象之间的联系程度不同。

对关系型数据库中的数据不但有存储、调用等动作，还有删除的动作，那么将数据库对对象的存储和删除也是一样，对象映射成关系型数据由一些规则，如下：

1）一个类与一个库表对应映射，也可以多个类与一个库表对应映射。

2）类中存在父子关系的类，映射关系时可以分别与父和子类分别映射，或者不对父类进行定义，让子类具有父类的属性；不对子类进行定义，让父类具有子类的属性。

3）映射关系定义为一个表，包含一对一、一对多、多对多等关联关系，也可在类表之间定义外键。

4）聚合的方式有两种：一种是用一张表将所有对象类的属性合并；一种是分别用两张表分别将对象类的整体和部分分别合并，利用外键关联整体与部分的关系。

5）有些类是没有属性的，没有属性则没有映射表。

6）映射后的关系型数据库表需要进行冗余操作，使其关系范式合理。

4 结论

面向对象的关系型数据库系统以其模型简单、数据独立的优势，成为数据库技术发展的主流方向，本文针对面向对象的技术和关系型数据库的特点，将两者相结合，研究了将面向对象技术方式应用于关系型数据库，进行系统设计方法的研究，重点描述了对象映射成关系数据库的方法。

参考文献：

[1] 杨玉芬，李明明.高晓旸对象管理在面向对象数据库中的应用研究[J].吉林大学学报（信息科学版），2013，9（5）：548-553.

[2] 肖刚.面向对象数据库在教学信息管理系统中的应用[J].硅谷，2012（6）：79.

[3] 陆登，李善平，郑春昭. 基于对象数据库的扩展Java集合框架[J].计算机应用与软件，2011（1）：133-136.

[3] 陈文宇.面向对象的关系数据库设计[J].电子科技大学学报，2002（1）：53-56.

多维关系数据库的应用研究 篇5

关系数据库是应用数学方法来处理数据库中的数据[1]。传统关系数据库主要用于事务处理[2]。在事务处理上存在以下的问题:(1)海量数据事务处理性能低;(2)数据冗余度大。

数据仓库能从多维的角度上解决海量数据的查询分析和存储冗余问题。但数据仓库是为决策支持系统的实现而提供的全面的、丰富的信息环境,它除了存储海量的数据以外,为决策支持的联机分析处理提供服务是它最重要的任务之一。因此数据仓库不适用于实际海量数据的事务处理。

但如果借用数据仓库多维思想来建立一种新的多维关系数据库模型,就能解决传统关系数据库存在的以上两个问题。

1 多维数据库技术的体系结构

1.1 关系数据库模型

关系模型的数据结构非常单一,在用户看来,关系模型中数据的逻辑结构就是一张二维表[3]。用二维表格表示实体集,用关键码进行数据导航的数据模型称为关系模型[4]。如表1所示。

1.2 多维数据库模型

由表1可以看出,关系数据库模型存在很大的数据冗余。多维关系数据库模型是在关系数据库模型的基础上发展起来的,但不同于传统关系数据库系统的组织结构形式,它是从原有的关系数据库模型中,提取出数据冗余量较大的属性组成维表,并以维表的笛卡尔积组成表集,再用原关系模型里的属性按除维表属性外剩下的属性进行投影,由该投影组成表集里的事实表。如图1所示,这是由表1组成的多维数据模型实例。

1.3 多维关系数据库的数据存储结构

多维数据模型主要应用在数据仓库和OLAP分析中[5,6,7]。在多维数据模型中,一部分数据是数据测量值,如核定金额。而这些数据测量值是依赖于一组‘维’的,这些‘维’提供了测量值的上下文关系。如核定金额与核费年度、核费月份、所属工商所有关,这些相关的‘维’唯一决定了核定金额测量值。因此,多维数据视图就是在这些‘维’构成的多维空间中,存放着数据测量值。如图2所示的小格内存储的数据就可以是应用系统业务数据中的核定金额、实收金额等数据。

对于逻辑上的多维数据模型,借助数据仓库里的星型模型思想,由事实表和一个维表来进行存储。事实表中存储数量非常大的数据(数量数据),如果组织不恰当则处理时间就会是个严重的问题。维表中存放描述性数据,维表是围绕事实表建立的较小的表,再利用维表的每一条记录值的组合建立一个数据库表的表名。例如:所属工商所、核费年度、核费月份的取值(即维表的一条记录)为吴家、2006、10,则其表名取为吴家-2006-10。这样表集里的全部记录之和就是原来关系库里的记录,但因每条记录没有‘维’属性的记录,因此就达到了数据压缩的目的,如图2所示。

2 算法设计

基于多维关系数据库的思想主要是用于海量数据的事务处理的。是传统的关系数据库技术和数据仓库技术的结合,充分利用了两者的优势,为比较多维关系数据库的优势,现把传统关系数据库和多维关系数据库的事务处理算法设计如下。

设已经预处理好的数据保存在Excel电子表格中,其数据实例如表1所示。现要把该海量电子表格数据导入到SQLServer2000数据库里。根据应用系统业务的要求:每条数据记录在导入时必须判断原SQLServer2000数据库里是否存有该记录,如果不存在,则插入该记录,如果原库里存有该记录,则要进一步判断,看该记录是否有与待导入的数据记录相同,如果相同则数据不变,否则更新该记录。为了加快算法的速度,数据导入时是先检查数据库中是否存在该记录,如果存在则删除该记录,不存在则不用删除,然后再插入一条新的待导入的该记录。

根据以上的数据导入要求,用传统的关系数据库系统导入时,首先设计一个二维的数据表,其字段组成如表1所示。这样的表与待导入的电子数据表格结构是一一对应的,这也是查询系统业务处理所要求的,因此比较直观。数据导入的过程是先检查数据库中是否存在该记录,如果存在则删除该记录,不存在则不用删除,然后再插入一条新的待导入的该记录。具体的算法过程如下:

算法1传统关系数据库业务数据导入算法

从上面的数据导入算法中可以看出,对于少量的数据导入,这项导入工作简单方便,但当导入数据量很大时,其导入的时间就很大,不能满足应用系统业务工作需求。同时,由表1的数据结构可以看出,表中的数据冗余度非常大。

为此,考虑借用数据仓库里的多维思想来重新组织数据,如以所属工商所、核费年度、核费月份三个字段来建立三维的数据关系数据库,即如图1所示建立维表,利用维表的每一条记录值的组合建立一个数据库表的表名。例如:所属工商所、核费年度、核费月份的取值(即维表的一条记录)为吴家、2006、10,则其表名取为吴家-2006-10。以此表为事实表存储数据,则该事实表的结构如图1所示的事实表结构。如此就达到了去掉冗余数据的目的,而同时在数据的导入过程中的删除数据记录过程也避免了不必要的数据查询判断工作,因此也达到了降低算法的时间复杂度的目的。算法的思想是:删除记录时,根据记录的维表直接找到要删除的记录所在表,并把该记录删除掉,然后再在该表中增加新记录。其具体的算法如下:

算法2基于多维的关系数据库业务数据导入算法

3 算法的时间和空间复杂度分析

3.1 时间复杂度分析

用n表示导入数据的记录数,w1、w2、…wk表示导入数据表中用作为维表的k个字段,d1、d2、…dk为这k个字段中每个字段(即k个维表中)的记录个数,m=d1×d2×…×dk。

算法1的时间复杂度如下:

(1)数据库的连接复杂度为:T1=〇(1)。

(2) Excel数据调入内存记录集rse复杂度为:T2=〇(1)。

(3)算法的关键是把所有的记录导入到库中的删除工作,因为每条记录的删除都必须查看表中是否存在该记录,因此删除每条记录的复杂度为〇(n),添加一条记录的时间复杂度为〇(1),则导入一条记录的时间复杂度为〇(n+1)=〇(n)。所以导入n条记录的时间复杂度为:T3=n×〇(n)=〇(n2)。

(4)算法的总的时间复杂度为:T=T1+T2+T3=〇(1)+〇(1)+〇(n2)=〇(n2)。

算法2的时间复杂度如下:

(1)数据库的连接复杂度为:T1=〇(1)。

(2) Excel数据调入内存记录集rse复杂度为:T2=〇(1)。

(3)寻找表名的时间复杂度为:T3=n×〇(1)=〇(n)。

(4)算法的关键是把所有的记录导入到库中的删除工作,因为每条记录的删除都必须查看表中是否存在该记录,由算法2的第4、5条语句可以看出,用到的全部表的数量为m=d1×d2×…×dk个,而这m个表里的记录总数是记录总数n,因此每个数据表里的数据记录量平均为n/m条。因此删除每条记录的复杂度为〇(n/m),添加一条记录的时间复杂度为0(1),则导入一条记录的时间复杂度为〇(n/m+1)=〇2(n/m)。所以导入n条记录的时间复杂度为:T4=n×〇(n/m)=〇(n2/m)。

(5)算法的总的时间复杂度为:T=T1+T2+T3+T4=〇(1)+〇(1)+〇(n)+〇(n2/m)=〇(n2/m+n)。

由上面的时间算法复杂度分析可以看出,多维关系数据库技术的时间算法复杂度〇(n2/m+n)比传统关系数据库技术的时间算法复杂度〇(n2)要低。业务处理的时间效率得到了明显提高。并且随着维数的增加,时间效率提高得就越多。

3.2 空间复杂度分析

用n表示导入数据的记录数,w1、w2、…wk表示导入数据表中用作为维表的k个字段,d1、d2、…dk为这k个字段中每个字段(即k个维表中)的记录个数,f1、f2、…fk为这k个字段中每个字段(即k个维表中)所占用的存储空间,s1、s2、…sp表示导入数据表中用作为事实表的p个字段,t1、t2、…tp为这p个字段中每个字段所占用的存储空间。

算法1的空间复杂度分析如下:

由于表中共有k+p个字段,每个字段所占用的存储空间分别为f1、f2、…fk、t1、t2、…tp,故每条记录占用的存储空间为(f1+f2+…+fk+t1+t2+…+tp)。

又因为表中总的数据量有n条记录,因此空间存储量为:

S=n×(f1+f2+…+fk+t1+t2+…+tp)。

算法2的空间复杂度分析如下:

由于每个事实表中共有p个字段,每个字段所占用的存储空间分别为t1、t2、…tp,故每条记录占用的存储空间为(t1+t2+…+tp)。

又因为由算法2的第4、5条语句可以看出,用到的全部表的数量为m=d1×d2×…×dk个,而这m个表里的记录总数就是算法1里的记录总数n,因此算法2的总的空间存储量为:

S=n×(t1+t2+…+tp)。

由上面的空间算法复杂度分析可以看出,用多维关系数据库技术的存储空间S=n×(t1+t2+…+tp)比用传统关系数据库技术的存储空间S=n×(f1+f2+…+fk+t1+t2+…+tp)要低。业务处理的空间效率也得到了明显提高。并且随着维数的增加,数据的冗余量越小,空间效率提高得就越多。

4 实验及分析

为了验证基于多维数据库的算法的正确性和有效性,利用工商部门的实际应用系统数据进行实验,。实验过程中,我们选择了从记录数据为4000到40000的数据分别进行了导入实验,同时为了验证海量数据导入时间与多维关系数据库技术选择的‘维’数的关系,分别用一维、二维的情况与传统关系数据库技术的算法用同样的数据在同样的环境下进行了实验。所有这些实验均在主频2.0GHz、内存256M的Pentium计算机上完成。实验对比结果图3所示。

图3是传统关系数据库技术的算法和多维关系数据库技术的算法进行海量数据导入的时间随导入的数据量变化的比较曲线,横坐标为导入数据量(单位:万条),纵坐标为数据导入时间(单位:s)。从图中可见,传统关系数据库技术的算法和多维关系数据库技术的算法的导入时间随着导入数据量的增加而增加,但多维关系数据库技术的算法增长幅度较小。同时随着维数的增加,导入同样的数据量需要的时间就越小,并且二维就已经能有很有效的导入时间了。

5 结论

针对现有的传统的关系数据库应用系统中存在的海量数据导入运算速度慢和数据冗余的问题,提出了在传统的关系数据库事务处理技术基础上,借用数据仓库的多维思想来建立的多维关系数据库事务处理技术。从理论上解决了海量数据导入运算速度慢和数据冗余的问题,并以实际的业务数据进行了实验对比。对具有海量数据处理的应用系统的优化提供了一条思路。

摘要：针对传统的关系数据库技术在处理海量数据事务上存在的处理速度慢和存储冗余量大的问题，结合支持决策分析的数据仓库的多维思想，提出了一种多维关系数据库模型。对新旧模型从时间复杂度和空间复杂度两个方面分别进行了理论推导，证实了新的多维关系数据库模型较传统的关系模型在时间和空间上都有了很大的提高，并用实验对该理论结果进行了验证，证明了新模型的可行性和优越性。

关键词：关系数据库,多维关系数据库,OLAP,数据仓库

参考文献

[1]钱学忠，黄学光，刘肃平．数据库原理及应用[M]．北京：北京邮电大学出版杜，2005．

[2]陈文伟．黄金才．数据仓库与数据挖掘[M]．北京：人民邮电出版社，2004．

[3]马惟哲，吕红兵．Web数据库系统物理模型的优化策略[J]．计算机应用与软件，2005，22(1)：35-97．

[4]施伯乐，丁宝康．数据库技术[M]．北京：科学出版社，2002．

[5]刘宁，宋哗．数据仓库中CUBE大小估计算法[J]．计算机工程与应用，2004，4：193-215．

[6]李盛恩，王珊．多维数据模型ER[J]．计算机学报，2005，28(12)：2059-2067．

关系数据库查询优化策略研究 篇6

目前, 随着信息化的不断发展, 数据库作为信息管理系统的后台, 广泛应用于各企事业单位[1], 主要负责信息的处理和存储, 有着举足轻重的地位。据调查, 大部分数据库在应用过程中常会出现延迟、等待处理时间长等问题, 这都可以归结为数据库的效率问题。在数据库对信息的处理中, 以查询所占的比例最大, 那么查询的效率将是数据库信息处理效率的关键所在。良好的查询优化策略, 将大幅提高数据库效率, 例如一些商业海量数据库, 某些原本需要执行数十分钟, 甚至1个小时的查询, 在适当的优化策略下, 执行时间可缩短为几分钟。如何根据实际情况制定适合的查询优化策略, 也正是本文的切入点。本文将通过分析数据库查询效率低的原因, 结合数据库理论知识、数据库应用的经验, 阐述数据库查询优化的策略。

2 影响数据库查询效率的因素分析

影响数据库查询效率的因素有很多, 可简单归纳为以下方面:

2.1 硬件性能方面

这里的硬件主要指数据库服务器, 由一台或多台主机和DBMS (数据库系统管理软件) 共同构成。“工欲善其事, 必先利其器”, 数据库系统服务器的硬件等级, 服务器的相关设置, 直接影响数据库的查询效率。

2.2 查询方案方面

现代的关系数据库的查询以关系代数为理论基础, SQL (Structured Query Language) 语言为手段完成和数据库的通信。用户编写SQL语句, DBMS (数据库系统管理软件) 编译并结合索引等数据库对象执行SQL语句, 返回查询结果实现用户对数据库的查询操作[2]。高效的查询方案可以将数据库的查询效率提高10倍以上, 海量数据更为明显。很多程序员、数据库操作员却并未认识到这点, 以为写出SQL语句能实现查询功能就可以了。

3 查询优化策略研究

数据库的查询优化有多种途径, 这里根据影响数据库查询效率的因素, 分别从硬件性能方面和查询方案两个角度来谈数据库查询优化策略。

3.1 基于硬件性能的查询优化

3.1.1 服务器硬件优化

提高服务器的工作效率, 升级硬件是最直接、有效的一个方法。针对数据库服务器的特点, 硬件升级时应考虑下列内容:

1) 加大内存

对于数据库服务器性能来说, 内存是最重要的因素。因为访问内存中的数据要比访问磁盘中的快, 所以可以通过加大内存, 把更多的数据保存在内存缓冲区, 从而减少磁盘的I/O, 提高数据库效率。

2) 配置多处理器

多处理器数据库系统中, 每个处理器可以运行一个事务, 实现多个事务真正意义上的并行运行, 也可以实现更加复杂的并发机制, 如果不考虑资金的问题是最理想的并发方式。

3) 配置高效硬盘

从磁盘读取数据的时候, 高转速的磁盘可以减少等待时间, 提高相应速度。另外, 可采用磁盘陈列, 优化磁盘的I/O分配使之均衡, 减少资源竞争, 达到提高数据库效率的目的。

3.1.2 服务器设置优化

1) 调整操作系统

服务器的运行离不开操作系统, 操作系统的性能直接影响着服务器的性能。

可通过操作系统规划使数据库服务器占有系统资源最大化, 设置合适虚拟内存的比例, 设置服务器进程优先级等手段提高数据库效率。

2) 调整服务器的缓冲区

数据在内存中的访问速度要高于硬盘中的访问速度, 所以可以通过相应参数设置服务器的缓冲区容量, 让数据和索引更长时间停留在内存中, 减少硬盘I/O, 提高数据库效率, 下面以Oracle为例, 介绍缓冲区的调整。

系统全局域SGA (System Global Area) 是Oracle数据库存放系统信息的内存区域, 是实例Oracle Instance的基本组成部分, 在实例启动时分配。它主要由数据高速缓冲区、日志缓冲区、共享池三部分组成。SGA存在的意义就是把数据放在内存中快速存取, 因此SGA要尽可能都进入内存但不要超过内存的容量, 否则会发生磁盘和内存的页面交换, 反而影响了效率。可以通过语句SHOW SGA

查看SGA内存分配的结构和大小。

数据高速缓冲区的大小应该根据该缓冲区的命中率来调整, 命中率高说明该缓冲区缓存够用, 性能良好。命中率是通过下面公式来计算的:高缓区合中率=1- (physical reads/ (db blockgets+consistentgets) )

公式中涉及的参数是Oracle运行时统计的数据存取情况, 放在V$SYSSTAT表中。physical reads是磁盘文件存取总数, db block gets是数据请求总数, consistent gets是内存缓冲区能够满足的请求总数。可以通过下面的语句查询这几个参数, 如图1。如果命中率低于85%, 将影响数据存取的效率, 可以通过增大初始化参数db_block_buffers的值 (它的最大值为65535) , 来增加高速缓冲区的容量。

共享池由库缓冲区和数据字典缓冲区组成, 它们的大小应根据缓冲区的不命中率来调整。库缓冲区的不命中率应该接近于0, 数据字典缓冲区的不命中率应该低于10%, 否则会影响数据存取效率。它们的不命中率公式如下:

可通过下面语句查询相应的参数, 如图2。如果不命中率过高, 可以通过字典区不合中率=错误请求数sum (getmisses) /相应项请求数sum (gets) 调整初始化参数shared_pool_size来重新调整分配给共享池的内存容量。

3.2 基于查询方案的优化

3.2.1 关系代数的等价变换优化

等价关系代数优化是查询优化的理论基础和前提。关系代数表达式等价主要是指用同样的关系实例代替两个表达式中相应关系时所得到的结果是一样的, 也就是指得到相同的属性集和相同的元组集[3]。等价关系代数优化就是找出等价的关系代数表达式, 从中选出执行效率最高的一个, 并以此为基础写出相应的SQL语句。

常用的等价关系代数规则如表1所示。

注释:E1、E2、E3是关系代数表达式, A1、A2...An, B1、B2...Bm是属性, F、F1、F2、F3是条件表达式

从查询优化的角度分析, 规则1、2的等价变换不会对查询效率产生影响, 而规则3-10的等价变换的查询效率则有所不同。经总结, 等价关系代数优化应遵循以下原则:

1) 根据情况尽量将选择、投影操作提前, 缩小关系的范围

2) 根据情况尽量将同一关系上的选择、投影操作一起进行, 避免关系的重复扫描。

3) 根据情况将选择或投影和连接结合起来进行, 以减少关系范围

3.2.2 合理的创建索引

索引是数据库中重要的数据结构, 它就像书的目录一样可以辅助快捷的访问数据库中的数据, 而不需要对数据库表进行遍历。索引的使用是由DBMS (数据库管理系统) 操作的, 作为数据库的设计者或操作人员, 关注的应该是如何创建合理的索引, 合理的索引设计要建立在对各种查询的分析和预测上。索引创建的不合理, 会有相反的效果。通常创建索引时, 要遵循以下原则:

1) 在频繁操作的列上建立索引。这样的列指的是多表查询时的表连接属性, 分组GROUP BY, 排序ORDER BY的依据属性。常用于分组、排序的列可以考虑建立聚集索引 (clustered index) 。

2) 在条件表达式中经常用到的取值范围大的列上建立检索, 取值范围低的列上不要建立索引。如属性“婚否”的取值范围只有“是”与“否”两个不同值, 就没必要建立索引。建立索引反而会降低更新速度。

3) 如果经常多列同时存取, 并且每一列都含有重复的值, 可以考虑建立组合索引 (compound index) ;

4) 对于不经常作为关键字查询的列则少创建或者不创建索引:对于频繁删改的表, 尽量少创建索引。

3.2.3 合理使用存储过程

存储过程 (Stored Procedure) 是一组具有特定功能的由流控制和SQL语句编写的程序块, 经编译和优化后存储在数据库服务器中, 具有灵活、性能高的特点。在数据库的应用中, 可以将数据库中常用的复杂查询操作写在存储过程中, 查询的时候调用相应过程就可以了。常规的SQL语句数据库系统是要编译后才可以执行的, 存储过程是经过编译和优化的, 用户在调用它进行查询的时候节省了编译时间;另外, 存储过程是存放在数据库中的, 这样查询的时候直接调用减少了系统的I/O, 提高了查询效率。可能存储过程每一次调用节省的时间很少, 但是如果对于多用户访问的海量数据库, 将是一个很大的性能提升。

3.2.4 合理编写SQL语句, 避免对表的顺序遍历

1) 尽量避免在SQL语句中对属性进行NULL值的判断, 防止DBMS将放弃索引进行全表遍历。如下面的查询SELECT NAME FROM EMP WHERE SAL IS NULL可进行如下优化, 将EMP表的SAL属性默认值设置为0, 让该属性没有NULL值, 查询语句变为SELECT NAME FROM EMP WHERE SAL=0

2) 尽量避免在SQL语句中使用OR作为查询条件的连接词, 防止DBMS跳过索引全表遍历。如下面的查询SELECT NAMEFROM EMP WHERE SAL=1000 OR

SAL=2000可以进行如下优化, 用UNION ALL代替OR, 查询语句变为SELECT NAME FROM EMP WHERE SAL=1000 UNIONALL SELECT NAME FROM EMP WHERE SAL=2000

3) 尽量避免在SQL语句中使用IN、<>或NOT关键字, 它们都会使DBMS放弃索引, 全表遍历。IN谓词可以用EXISTS谓词替代, 因为IN谓词引导的子查询返回是一个结果集, 而EXIXTS谓词引导的子查询返回的是’TRUE’或‘FALSE’, 然后子查询的结果再作为条件参与父查询, 显然EXISTS谓词引导子查询的效率会更高。如下面的查询SELECT SNAME FROM S WHERE SNO IN

(SELECT SNO FROM SC WHERE GRADE>80) 可优化为SELECT SNAME FROM S WHERE

EXISTS (SELECT 1 FROM SC WHERE SC.SNO=S.SNO AND GRADE>80) 。

4) 尽量避免在WHERE字句中对属性进行公式、函数操作, 如下面的查询SELECT NAME FROM EMP WHERE SAL*3=3000可以优化为SELECT NAME FROM EMP WHERE SAL=3000/3;SELECT JOB FROM EMP WHERE substring (name, 1, 3) ='smt'可以优化为SELECT JOB FROM EMP WHERE NAME LIKE‘smt%’

5) 尽量避免对表进行全属性SELECT*查询, 查询要精确写每个属性, 全属性也不例外。

3.2.5 合理运用查询优化器

查询优化器是数据库系统的一个组件, 简单的说, 它会根据已有的索引和查询信息的统计, 对SQL语句进行优化, 得到它认为性能最好的, 查询最高效的执行方案。通常, 查询优化器所作的工作用户看不到, 默认执行。但是, 有些时候我们也可以根据实际情况通过参数设置查询优化器, 让它更高效的运行。

以Oracle为例, 查询优化器认为性能最优的标准有两点, 一是Best throughput, 即从SQL开始执行到结束的时间最短, 二是Bes Response time, 即从SQL开始执行到返回第一条记录的时间最短。两个标准可以根据我们的需要设置参数Optimizer_mode来确定它们的优先级。设置参数为All_Rows表示希望以Best throughput的方式来优化, 设置参数为First_Rows_N表示希望以Best Response time的方式来优化。

4 结论

在大型数据库广泛应用的时代, 数据库查询优化已成为一门关键技术, 运用合理, 可以大幅提升数据库系统的效率[5]。提升硬件方面的优化是要衡量开销的, 使用优化器等软件优化仅是常规的优化, 在实际的应用中, 我们最需要关注和探索的是发掘现有服务器的潜能, 对数据查询方案作有效的分析并整理出高效率的数据查询方案。

参考文献

[1]杨小艳.Oracle数据库查询优化方法研究[J].计算机与现代化, 2008 (4) :4-7.

[2]李俊民.精通SQL-结构化查询语言详解[M].北京:人民邮电出版社.2008 (8) .

[3]梁志宏等.等价关系代数查询优化方法的研究[J].山西师范大学学报, 2004 (18) :34-38.

[4]盖国强等.Oracle数据库性能优化[M].北京:人民邮电出版社, 2005.

关系数据库模式 篇7

关键词：大数据,数据新闻,相关关系

一、数据新闻理念

大数据的力量影响了多个行业和领域。早在2003年, 计算机专家奥伦·埃齐奥尼就创立了一个预测系统,根据旅游网站上的数据推测机票价格;而在2009年甲型H1N1出现时,谷歌公司就利用自己所掌握的庞大的用户搜索数据、数据处理能力和统计技术,先于官方数据预测出了这场流感的传播;亚马逊通过分析海量的顾客购买清单,预测出顾客接下来的购买行为,进而有选择地为客户推荐相关产品。

大数据时代必须具备大数据思维。维克托·迈尔 - 舍恩伯格在Big Data中提出在“大数据”时代的三个思维转变: 一是全数据模式,样本 = 总体;二是接受混杂,允许不精确, 三是探求“是什么”,而不是“为什么”,即相关关系比因果关系能更好地了解这个世界。真正的革命并不在于分析数据的机器,而在于数据本身和我们如何使用数据。大数据时代,数据新闻蕴藏着巨大的潜力。对于媒体而言,数据时代新闻生产须具备数据新闻思维,重视对数据的挖掘和分析。

其一,需要有更大更全的思考角度。海量的数据和数据分析技术能更接近于全面真实客观的新闻报道要求,更接近于事件的真相。大量的开放性免费数据获取便捷,媒体的信源渠道拓宽,数据新闻的数据基数不断扩大,通过掌握大量的数据可以作出更有宽度、广度和深度的全方位新闻报道。

其二,信息获取方式的转变是新闻工作者工作重点的转变。在数据丰富的前提下,记者的工作重点不再是寻找信源获取可报道的信息,而是通过快速的数据分析获得大致的轮廓和发展脉络,并通过统计分析数据挖掘其背后的故事,实现新闻生产的高效性。

其三,数据新闻是从海量的数据中发现新闻线索,相关性成为新闻价值的判断重点。在大数据时代,新闻内容不一定就是新近发生或发现的事实,而是通过对海量的数据进行挖掘,发现事物的相关性。相关事实发生得越频繁,越多的事件具有相关性就越有新闻价值。

二、数据新闻生产

大数据时代,在丰富的数据资源的基础上,新闻可通过人机合作完成。对数据的收集、整理、分析、解读,成为媒体未来新闻生产的重要举措。及时提供准确、充分、有用的信息始终是新闻生产的目标,是公众对新闻业的期待和认知。媒体必须转变新闻生产方式以适应和满足公众对信息的需求,以更加多元的手段履行传播消息的功能和职责。

第一,数据挖掘:新闻生产的新方式。王光宏认为,数据挖掘就是“通过仔细分析大量数据来揭示有意义的新的关系、趋势和模式的过程 !”。大数据时代媒体面对海量的数据, 必须从中迅速挖掘有用信息,利用大数据挖掘技术实现报道内容创新,通过新媒体平台实现PGC和UGC内容交互聚合, 让新媒体报道反哺传统报道,采用大数据挖掘技术,将数据资源转化为报道生产力,发现人力难以发现的新闻。1

第二,可视化新闻叙事。网络技术和新媒体的发展培养了公众新的信息接受思维,媒体的新闻呈现方式考虑公众的接收习惯,即将传递信息的功能与信息呈现方式相结合。可视化新闻叙事就是通过大数据技术对复杂的问题和数据进行分析和处理,利用图表、视频、互动地图等能调动人们视觉参与的方式将数据以一种简洁、直观、易于被大众接受的方式呈现。

第三,链接延伸阅读。新闻报道始终存在有限的报道面和无尽的信息的冲突和悖论。大数据时代,新闻工作者应注重对新闻事实的分析和解释,媒体通过数据挖掘技术从海量信息中理出重要的公众应知的信息,通过可视化新闻叙事将信息加以整合,使信息能迅速被公众理解,而链接就是对有限的报道空间的延伸,对相关信息的进一步解释或深度剖析。

三、反思

关系数据库模式 篇8

关键词：关系数据库,实时数据,数据压缩,Oracle

0 引 言

在工业实时数据库的发展历程中, 早期的实时数据库使用封闭的文件系统, 目前先进的实时数据库系统直接使用开放的关系数据库如Oracle或SQL Server等存储历史数据, 这样实时数据库就可以直接融入上层应用信息系统。但是, 这种信息化应用的前提是, 企业必须购买专门的实时数据库系统。是否可以在关系数据库中直接存储实时数据, 这是值得探讨的问题。

由于实时数据具有不间断、数据量大的特点, 并且需要高速的历史数据定位访问能力, 故在关系数据库中, 采用传统的方式, 进行数据存储和访问, 是不可行的, 需要考虑数据压缩。

将要探讨的实时数据的压缩存储是在Oracle 10g数据库内部, 采用数据库自身的语言PL/SQL (Program language/Structured Query Language) 实现。为了提高数据压缩率, 提出了逻辑压缩和物理压缩两种方式, 其中物理压缩采用的是数据库层面的进制转换技术, 即对长时间的历史数据处理成二进制数进行合并存储, 达到减少数据表记录数的目的, 这种方式具有一定的新颖性;逻辑压缩为针对实时数据的有损压缩, 采用的是Swinging Door (旋转门) 压缩技术, 达到减少数据存储量的目的。所不同的是, 将旋转门技术嵌入关系数据库内部实现, 这种方式, 在国内尚未有文献报道。

1 数据压缩的原理及实现

如上所述, 实时数据在关系数据库中的压缩, 涉及逻辑压缩和物理压缩两个方面, 其中前者为有损压缩, 即数据被还原时有损失, 后者为无损压缩。

1.1 逻辑压缩

逻辑压缩采用旋转门算法, 该算法主要应用在基于时间序列的工业历史数据上, 通过旋转门压缩方法后, 能够消除小信号扰动, 达到过滤噪声的功能, 且增加数据的平滑度, 有利于进行数据分析和挖掘。但它是一种有损压缩, 通过丢弃一些数据的方法来达到减少存储容量的要求。这些被丢弃的数据在一定误差内必须不影响过程历史数据的重构[1]。

旋转门压缩技术的实现方法是, 系统每接收到一个新值 (即当前值) , 都会和最近保存值 (即图1的最近保存点) 一起构造出一个有两条边同X轴垂直的平行四边形, 该平行四边形也称为压缩偏移覆盖区。如果在新值和最近保存值之间只要存在一个值, 落在平行四边形外, 那么就存储新值的上一个值, 否则就继续接收新值, 没有任何数据点被保存。如图1在对测试点C进行压缩测试时, 发现不再满足旋转门压缩算法的条件, 则说明点B未通过压缩测试, 存储该点并作为最近保存点, 并继续下一轮的压缩测试。如图1所示, 平行四边形垂直方向的边长是压缩偏移量的两倍, 压缩偏移量可由用户设定, 并且每个信号点 (数据采集点) 均可以有自己的压缩偏移量[2]。压缩偏移量取得越大, 数据的压缩率就越高, 反之, 压缩偏移量越小, 则压缩率越底, 但是, 解压的精度和压缩率成反比。图1按第1到第7点的顺序说明了旋转门压缩算法的原理。旋转门算法步骤的具体文字描述可参见文献[3]。

(1) 旋转门算法的PL/SQL程序实现

/*首先对原有S1、S2的斜率值初始化*/

OldS1 number:= -1; OldS2 number:=1;

/*对某采集点的给定所有值循环压缩, 在压缩测试值到达最后一个时停止循环, 变量v_CurrSub为当前压缩值下标, v_Num为待压缩值的个数*/

While v_CurrSub<v_Num loop

v_CurrSub:=v_CurrSub+1;

/*求取斜率S1、S2、S, v_RecoTab是以记录为元素的数组, 记录含有值 (value) 和时间 (time) 两项, v_LastSub为最近保存值的下标, CompDif为压缩偏移量, TimeDif为等距时间。*/

S1:= (v_RecoTab (v_CurrSub) .value- (v_RecoTab (v_LastSub) .value+CompDif) ) /TimeDif;

S2:= (v_RecoTab (v_CurrSub) .value- (v_RecoTab (v_LastSub) .value-CompDif) ) /TimeDif;

S:= (v_RecoTab (v_CurrSub) .value- v_RecoTab (v_LastSub) .value) /TimeDif;

if S1>OldS1 then OldS1:=S1; end if;

if S2<OldS2 then OldS2:=S2; end if;

if S<OldS1 or S>OldS2 then

/*将前一个测试点作为新的保存点*/

v_LastSub:=v_CurrSub-1;

end if;

end loop;

(2) 旋转门算法的实用解压方式

通常, 采用的历史数据解压缩算法要与采用的压缩算法相对应, 一个常用的、简单的解压缩方法是线性插值算法。如图1所示, 直线AB连接A和B两个测量点, 它们之间的任何测量值可以用下面的公式进行线性插值:

$y{}_i=y{}_1+\frac{y{}_n-y{}_1}{t{}_n-t{}_1}(t{}_i-t{}_1)(1)$

这个估计作为t时刻的历史数据y的解压缩值。记yi为i时刻的解压缩值, $k{}_n=\frac{y{}_n-y{}_1}{t{}_n-t{}_1}$为直线AB的斜率。

1.2 物理压缩

同样所提出的物理压缩, 也主要应用在基于时间序列的工业历史数据上, 并且这些数据必须等距时间。物理压缩的基本原理是, 对于某个采集点, 将一段等距时间序列的数据, 用一个特定的且区别于小数点的符号连接成规定长度的字符串 (该处的特定符号可称为连接符) , 再将该字符串转换成二进制串, 使用关系数据库中存储二进制的大对象类型 (比如在Oracle数据库中可采用BLOB类型) , 对此串进行存储。由于压缩后的数据为二进制串, 所以对重要的工业数据具有一定的保密性。

(1) 物理压缩步骤的文字描述

1) 设置当前数据采集点的数值连接串为空字符串, 并记录该采集点将要参加压缩数据的起始时间点 (BegTim) ;

2) 将当前时间点的值及一个连接符 (如逗号) 接入连接串, 并记录下当前时间点 (EndTim) ;

3) 如当前采集点的数值连接串的长度小于最大设定值 (如2KB) 则转入2 (否则, 去掉最后多余连接符并转入4) ;

4) 将当前采集点对应的数值连接串转换为二进制串存入关系数据库表;

5) 对新的时间点的值, 重复以上过程。

(2) 物理压缩对应解压方法及实现

解压时分两种情况, 一是解压时间点 (DcompTim) 的值位于字符连接串 (ConnStr) 的首或尾时, 直接求子串即可得到。二是解压时间点的值位于连接串中间时, 则用解压时间减去连接串的起始时间, 接着用该时间差除以各值之间的等距时间 (TimDif) , 从而求出需解压值在连接串中的位置 (DcompPos) , 利用该位置值算出需解压值前一个连接符 (ConnLab) 的位置 (BegPos) 和后一个连接符的位置 (EndPos) , 最后结合两个连接符的位置值求出给定时间点的解压值。解压对应的部分PL/SQL程序如下:

DcompPos:= (DcompTim-BegTim) *24*60*60/TimDif;

BegPos:=INSTR (ConnStr, ConnLab, 1, MidPos) ;

EndPos:=INSTR (ConnStr, ConnLab, 1, MidPos+1) ;

/*由解压点的值在连接串中的开始位置下标BegPos+1及长度EndPos-BegPos-1, 通过求子串求出字符类型解压值*/

StrVal:=SUBSTR (ConnStr, BegPos+1, EndPos-BegPos-1) ;

/*将字符类型的解压值转换为Number类型*/

NumVal:=TO_NUMBER (StrVal) ;

1.3 混合压缩

为了得到更高的压缩率, 在介绍了物理压缩和逻辑压缩的原理, 自然会想到将它们结合起来, 这里称为混合压缩, 从而得到更好的压缩效果。例如某一采集点一段连续时间的数值是:6.1、6.1、6.2、6.1、6.2、6.3 (如各数值间的等距时间为5分钟) , 直接利用物理压缩的数值连接串为:“6.1, 6.1, 6.2, 6.1, 6.2, 6.3”, 采用压缩偏移量为0.1进行逻辑压缩后仅得到两个数值6.1和6.3, 再结合物理压缩的思想将这两个数值用逗号连接成串:“6.1, , , , , 6.3”, 其中逗号为连接符 (当解压时发现两个连接符号之间没有值, 则找到最近两个存在的值6.1和6.3, 利用时间差进行线性插值解压) 。最后将该字符串转换成二进制串存入表1的压缩连接串值字段 (当然在解压时首先要将该二进制串转换成字符串再进行解压) 。

2 压缩性能分析

为了对历史数据在关系数据库中的压缩性能作进一步分析, 笔者对实际发生的数据压缩情况进行了跟踪。表2分别对逻辑、物理及混合压缩进行了压缩性能分析, 其中原始 (数据) 记录和逻辑压缩后的记录采用相同形式的存储表设计, 对应数据库表均包含采集点、时间和值三个字段, 所以某采集点一个时间点的值对应一条记录。而物理压缩和逻辑压缩采用表1的存储形式, 故某采集点一段时间内值的连接串构成一条记录 (连接串的长度一般不大于2KB) , 总记录数相对逻辑压缩急剧减少。表2列举了五个采集点作为实验对象, 在第一栏给出了每个采集点不同的编号, 表中数据格式表示数值的有效位数, 采集点FI-1134的数据变化频繁, 而FIC-1111比较平稳, 其余三个采集点变化相对稳定, 代表了普遍情况。各采集点的采样频率均为5分钟, 时间跨度为30天, 原始记录数为8640个。

如表2所示, 采集点FIC-1111逻辑压缩后的记录数为3975, 与原始记录数8640相比后得到压缩率约为46%。可见旋转门算法对变化不频繁采集点的压缩率是相当高的, 而五个采集点的平均压缩率约为65%。由于采集点FI-1134的数值变化比较频繁, 另外三个采集点数值变化适中, 所以此平均压缩率可在一定程度上反映实际应用情况。物理压缩是在原始记录的基础上将一段时间内的数值连接成串进行存储, 故记录数急剧减少。而采用混合压缩方式, 是在物理压缩的基础上运用了逻辑压缩, 使得一段时间间隔内的压缩连接串相比物理压缩时更短, 因此减少了记录数。可见以上的压缩方式对于基于时间序列的工业历史数据具有良好的压缩性能和一定的实用价值。

3 结束语

综上所述, 关系数据库中, 实现实时数据的压缩存储和访问是可行的。经过数据压缩, 显著提高了数据存储量及访问效率, 能够实现关系型数据库对历史数据长时间、高频率的存储。由于采用纯数据库技术, 提出的方法可推广至Oracle 10g以外其他版本或其他类型的关系数据库。

参考文献

[1]汪勇.流程工业历史数据库的研究[D].杭州:浙江大学信息科学与工程学院, 2005.

[2]彭春华, 林中达.PI实时数据库及其在电厂SIS系统中的应用[J].工业控制计算机, 2003, 16 (6) :28-33.

关系数据理论的教学实践探索 篇9

关键词：关系数据理论；关系模式；模式分解

作者简介：吕鸣（1957-），男，吉林省吉林市人，国防科技大学机电工程与自动化学院，高级工程师；王萍（1979-），女，河北元氏人，国防科技大学机电工程与自动化学院，讲师。（湖南?长沙?410073）

中图分类号：G642.0?????文献标识码：A?????文章编号：1007-0079（2012）28-0079-02

关系数据库理论是“数据库系统原理”课程教学的重点和难点，其内容涉及的概念、定义、定理、推理较多，同时在教学中要求学员能够运用相关的理论和知识解决在数据库应用设计中遇到的实际问题。

一、关系数据理论的教学主要内容及教学要求

关系数据理论用于指导建立良好的关系模式，在关系操作过程中尽可能避免或较少地产生异常。其主要的教学内容包括：规范化理论（包含依赖关系及范式）、公理系统（包含基本公理、推理、覆盖及闭包）和模式分解。在教学要求上提出掌握规范化理论的定义及概念，熟悉Armstrong公理系统并熟练应用推导，针对具体问题能够运用所学理论进行模式分解；其教学的重点为Armstrong公理系统、函数依赖和范式；其教学难点和目标设定为模式分解。关系数据理论的主要教学内容及其相互间的联系如图1所示。

二、教学方法的研究探索

关系数据理论的教学以关系模式为核心展开，围绕关系模式中的属性集U和函数依赖集F介绍相关知识，最终实现掌握模式分解的基本方法。

1.以属性间的联系为关系数据理论的重要始点

应用关系数据库理论构造关系模式离不开对关系模式中属性的探讨。对于某一事物或对象而言，根据现实需求而提取或筛选出的刻画事物或对象特征的诸属性间有着不同性质的联系。因此，将属性间的一对一、一对多和多对多三种基本联系作为关系数据理论的始点有助于学生理解和掌握函数依赖、范式以及闭包等知识点的学习，并打下良好的基础。

2.以关系模式为关系数据理论教学的核心

围绕关系模式R（U，F）展开关系数据理论的教学主要把握以下知识点的学习：

（1）采用直观的图示法清晰展示函数依赖关系。在关系数据理论中函数依赖关系对范式的理解有着至关重要的作用。各种函数依赖关系的定义通常以文字表达的方式予以说明，在理解上带来一定的难度。在实际教学中探索使用图示的方法刻画函数依赖关系的定义，对学生理解定义的实质起着事半功倍的作用。图2～图5给出了部分相关函数依赖定义的示意图。

（2）消除操作异常和数据冗余的重要手段——规范化。在数据模式的构造中需要关注和解决数据的插入异常、更新异常、删除异常以及数据冗余问题，这也是规范化的意义所在。因此，合理地构造关系模式就显得尤为重要，而规范化理论则为解决这一问题提供了理论工具和手段。在关系模式各种规范化形式（范式）之间有着不同的要求和联系，这是在教学过程中必须把握并阐述清楚的。为此，在实际教学中结合各种范式的定义，选取适当的范例并结合图6所示的范式联系及规范化过程实施教学。

（3）公理系统——模式分解的重要理论基础。公理系统是关系数据理论的重要基础，合理、有效地运用公理系统求解函数依赖集的闭包及最小函数依赖集是教学的重要要求之一。在教学中采用把握基础、灵活运用、明确目标的教学原则。这就是把握公理系统的推理规则，灵活运用推理规则求解闭包，为模式分解奠定知识基础。在公理系统的教学中要重点强调求解属性（集）的闭包和函数依赖集的闭包之意义和作用。求解属性（集）的闭包可以从理论上判定该属性（集）是否适合作为关系模式的候选码；求解函数依赖集的闭包并判定两个函数依赖集是否等价对确定模式分解能否保持函数依赖的等价具有重要意义。因此将公理系统部分的教学视为模式分解的重要理论基础。

3.以模式分解为关系数据理论学习的重要目标

模式分解的过程就是运用关系数据理论及其规范化的方法解决模式中的操作异常和数据冗余问题的过程。在实际的教学中注意把握两个要点：一是模式分解中的三个等价的定义及其内涵；二是既保持无损连接又保持了原有函数依赖的等价的判断方法。通过示例分别说明模式分解的三个等价的定义，进而分析其异同点，尤其关注分解后所得到的模式是否与原模式保持了等价关系，使原模式的函数依赖及原有信息不产生本质上的变化这一重要问题。这就是模式分解中要达到既保持无损连接又保持了原有函数依赖的等价。在教学中既要学生掌握模式分解的方法，也要学会并掌握如何判断分解后的模式是否保持无损连接且又保持了原有函数依赖的具体方法，将模式分解作为关系数据理论学习的重要目标。

三、结束语

关系数据理论的教学是“数据库系统原理”课程中的重要教学内容之一。以关系模式为核心、以模式分解为目标、以规范化理论和公理系统为主要内容展开教学可以以点成线、以线成面形成一个较为完整的知识体系，有利于学生较为全面地、系统地理解和掌握关系数据理论的知识，尤其是各知识点的相互之间的联系和作用。如何更好地开展关系数据库理论的教学依然是值得“数据库系统原理”课程教学探讨的课题之一，需要在实践中不断地探索和总结，以期更好地提高关系数据理论的教学效果。

参考文献：

[1]张海燕,陈志泊,王春玲.《高级数据库技术》课程教学改革的探讨[J].教育教学论坛,2011,(9):126-127.

[2]马金忠,田彦山.数据库原理课程教学中的几个重难点问题的多解探讨[J].高师理科学刊,2011,(4):90-94.

[3]王珊,萨师煊.数据库系统概论[M].第4版.北京:高等教育出版社,

2006.

[4]吴伟芬,任北上.《数据库应用系统设计》课程教学改革探索[J].广西师范学院学报(自然科学版),2010,(3):114-116.

关系型数据库与NoSQL数据库 篇10

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 No SQL数据库

2.1 No SQL数据库概述

No SQL数据库是非关系型数据存储的广义定义,它打破了长久以来关系型数据库与ACID理论大一统的局面。No SQL数据存储不需要固定的表结构,通常也不存在连接操作。No SQL数据库不使用传统的关系数据库模型,而是使用如key-value存储、文档型的、列存储、图型数据库、xml等方式存储数据模型。其中用的最多的是:key-value存储。

2.2 No SQL数据库优势

易扩展:No SQL数据库种类繁多,但是一个共同的特点都是去掉关系型数据库的关系型特性。数据之间无关系,这样就非常容易扩展。也无形之间,在架构的层面上带来了可扩展的能力。

大数据量,高性能:同样由于数据之间无关系,数据库的结构简单,在大数据量下,No SQL数据库表现出非常高的读写性能。

灵活的数据模型:No SQL数据库无需事先为要存储的数据建立字段,随时可以存储自定义的数据格式。而在关系型数据库里,增删字段是一件非常麻烦的事情。如果是非常大数据量的表,增加字段简直难以想象。

2.3 No SQL数据库应用现状

No SQL数据库并不是最近才出现的,很多No SQL数据库实现都已经存在了十多年了,有很多成功案例,是什么原因让它们比以前更受欢迎了呢?首先是由于社会化网络和云计算的发展,一些原先只有很高端的组织才会面临的问题,如今已经成为普遍问题了。其次,已有的方法已经被发现无法跟随需求一起扩展了。并且成本的压力让很多组织需要去寻找更高性价比的方案,并且研究证实基于普通廉价硬件的分布式存储解决方案甚至比现在的高端数据库更加可靠。所有这些导致了对No SQL数据库的需求。

Web2.0技术在网络中的广泛应用为No SQL数据库发展提供了充足的动力,市场上先后出现了十多种比较流行的No SQL产品,例如:Redis,Tokyo Cabinet,Cassandra,Voldemort,Mongo DB,Dynomite,HBase,Couch DB,Hypertable,Riak,Tin,Flare,Lightcloud,Kioku DB,Scalaris,Kai,Thru DB,......这些No SQL数据库都有自己的独到之处。有满足极高读写性能需求的Kye-Value数据库:Redis,Tokyo Cabinet,Flare;还有满足海量存储需求和访问的面向文档的数据库:Mongo DB,Couch DB;以及满足高可扩展性和可用性的面向分布式计算的数据库:Cassandra,Voldemort;在此就不详细介绍每款No SQL数据库了。

3 关系型数据库与No SQL数据库结合

伴随着越来越多的No SQL产品涌现出来,No SQL数据库会不会替代现有的关系数据库?在说明之前,我们先简单了解下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模型)和高可用性,所以要想实现一个分布式数据库集群非常困难,这也解释了为什么关系型数据库的扩展能力十分有限。而No SQL数据库则是通过牺牲强一致性,采用BASE模型,用最终一致性的思想来设计分布式系统,从而使得系统可以达到很高的可用性和扩展性。

对Web2.0网站来说,可用性与分区容忍性优先级要高于数据一致性,一般会尽量朝着A、P的方向设计,但事实上,数据库系统最大的优势就对一致性的保证,单纯为了P(分布式)而放弃C(一致性)也是不可取的,所以需要通过其它手段来保证对于一致性的商务需求。

3.2 No SQL数据库实际应用缺陷

缺乏强有力的商业支持:大部分的No SQL数据库都是开源项目,没有世界级的数据库厂商提供完善的服务,如果出现故障,只能自己解决,风险较大。

成熟度不高:No SQL数据库的实际应用不多,大部分No SQL产品都在小范围应用。成熟度不高,目前还很难在企业中广泛应用。

No SQL数据库在设计时难以体现实际:关系型数据库中的关系模型对于数据库设计是很有帮助的,而No SQL数据库缺乏这种关系,难以体现业务的实际情况,对于数据库的设计与维护都增加了很大难度。

3.3 关系型数据库与No SQL数据库结合

从上面的CAP理论来看,分布式存储系统更适合用No SQL数据库,现有的Web2.0网站遇到的性能以及扩展性瓶颈也会迎刃而解,但是目前No SQL数据库的实际应用缺陷又让我们难以放心。这时我们考虑是否可以将No SQL数据库与关系型数据库结合使用,在强一致性(C),高可用性场景我们采用ACID模型,在高可用性和扩展性场景,我们就采用BASE模型,答案是肯定的,目前的No SQL数据库还难以与关系型数据库一争高下,但它却可以对关系数据库在性能和扩展性上进行弥补,所以我们可以把No SQL和关系数据库进行结合使用,各取所长,需要使用关系特性的时候我们使用关系数据库,需要使用No SQL特性的时候我们使用No SQL数据库,各得其所。

下面举个典型的例子加以说明:

在Web2.0网站中比较典型就是用户评论的存储,评论表大致可分为评论表主键ID、被评论用户ID、评论用户ID、评论时间、评论内容等字段。结合关系型数据库与No SQL数据库的特点,我们可将需要查询的字段,比如评论表主键ID、被评论用户ID、评论用户ID、评论时间等数据、时间类型的小字段存储于关系型数据库中,根据查询建立相应的索引,而评论内容是个大文本字段,我们肯定不会通过文本内容进行查询,所以我们把评论内容存储在No SQL数据库中。这种让关系型数据库专门负责处理擅长的关系存储,No SQL数据库作为数据的存储的结合使用方式,首先节省了关系型数据库的IO开销,提高了数据库的数据备份与恢复速度;其次由于No SQL数据库的Cache往往都是行级别的,所以对评论内容字段也更容易做Cache,最后由于No SQL数据库天生就容易扩展,经过这种结合优化,关系型数据库的性能也能得到提高。这种结合方式实现起来比较容易,却能取得不错的效果。关系型数据库与No SQL数据库结合并不局限于这种方式,应该根据具体的应用场景灵活组合使用。

4 结束语

关系数据库已经流行了几十年了,No SQL数据库想在短期内取而代之显然是不可能的,但是No SQL数据库的发展势头也不容小觑。在当前阶段的某些场景下,可以将No SQL数据库与关系型数据库结合使用,相互弥补各自的缺陷,这种数据库组合对解决目前Web2.0网站所遇到的性能、扩展性等问题具有指导意义。

参考文献

[1]李莉莎.关于NOSQL的思考[J].中国传媒科技,2010(4):40-41.