关键词：数据库；关系模型；关系数据库
通俗地说，关系型数据库就是采用了关系模型来组织数据的数据库。简单来说，关系模型就是一个类似于二维表格的模型，而关系型数据库就是由二维表格及其中含有的数据所组成的一个数据组织。在关系数据库中，有些名词需要我们了解：
关系：通俗地说，在一张二维表格中，每个关系都具有一个关系名，就是通常说的表名table。
属性：在二维表格中也就是类似于excel表格中的一列，在数据库中被称为字段。
域：属性的取值范围，也就是数据库中某一字段的属性限制条件。
关键字：一组可以唯一标识元组的属性。数据库中常称为主键，由一个或多个列组成。
关系模式：指对关系的描述，其格式椋汗叵得（属性1，属性2，…，属性N）。也就是数据库中的表结构。
随着数据库应用领域的扩展以及数据对象的多样化，传统的关系数据模型暴露出了许多问题，如对复杂对象的表述能力差，表达能力较弱。为此，人们提出了许多新的数据模型，下面笔者向大家介绍一下以前的数据库的主要特点：数据不保存、系统没有专用的软件对数据进行管理、数据不共享、数据不具有独立性。
在文件系统层面上，数据可以以文件的形式进行长期保存，数据交由文件系统管理数，独立的机制使得程序与数据之间具有一定的独立性但在这个结构中，数据的独立性、共享性差，冗余度大、易造成数据传输之间的不一致性。
在数据库系统层面上，数据可以结构化，数据之间的共享性提高，冗余度小，一个用户可以拥有多个数据库，因此数据独立性高，数据控制功能也变得统一起来。其中大可分为4类：
第一类，数据安全性控制；第二类，数据完整性控制；第三类，数据的并发控制；第四类，数据管理与恢复。
数据结构化，在数据库系统中，将数据按照一定的数据模型插入到一个结构化的数据库中，需要考虑此数据库的数据结构，还需要考虑连接数据后的数据结构，而在以前的数据库中，这些，是我们看不到的。下面，笔者将就几个方面对其进行分析：
非关系型数据库的实质：非关系型数据库产品是传统关系型数据库的缩略版本，通过减少功能，来大幅度提升产品性能，类似于我们平时游戏中的资料篇。
目前市场上流通的大部分主流的非关系型数据库基本上都是免费的。而大公司中，名气大的关系型数据库开发软件，比如Oracle、DB2是收费的。这在很大程度上限制了一些平民用户的使用。但是在实际开发中，有很多小型的业务需求，并不需要完整的关系型数据库进行组建，非关系型数据库的功能就足够了。这种情况下，使用性能高、成本低的非关系型数据库当然是我们的首选。在性能上NOSQL是基于键值对的，可以理解成类似于Java中和HashMap中的键值对，数据表中的主键和值也具有相同对应关系，但在使用过程中是不需要经过SQL层的解析，所以性能非常高是它的主要优点。同样，它也具有良好的可扩展性，这也是基于键值对，数据之间存在相当低的耦合度，所以在使用的时候非常容易扩展。
在SQL语言中，关系型数据库对其也具有独特的解读优势：在复杂查询语句中，可以用SQL语句根据表连接、嵌套、子句等方法方便地在一个表或多个表之间做复杂的数据查询，且代码的冗余性很低，这也使得数据库对于安全性能要求很高的数据得以访问，对于非关系型数据库，就没有这些优点。
但是近年来的发展中，两种数据库类型都在不同的需求市场中发展着，虽然有所交集，但是这并不影响数据库的进化方向。比如，NOSQL数据库自从2008年的更新版本以后，慢慢开始具备SQL数据库的一些复杂查询功能，并随着服务端的更新，这方面的功能日益完善，而SQL数据库也在慢慢地进化着，在数据库平台上HandlerSocker技术的出现，可以在MYSQL上实现对于数据库SQL层的穿透，在非NOSQL数据库上使用NOSQL的方式访问数据库，可以实现无中心化的集群等特点，更是向我们说明了数据库在这些年间的变化。
对于研究数据库的人来说，或许关系型数据库只是数据库众多实现中的一个特例模型，在数据库中，类型的划分具有严格的限制。科学家们用严格的数学公式和逻辑形式定义了数据关系以及其中的各种运算，虽然这两极都因为各自的弱势而开始进化出另一极的一些特性，但是这些特性的增加也会导致数据库失去一些原本具备的优势，所以怎样构建和使用数据库的系统模型，是数据结构的框架构造工程师需要考虑的问题。
参考文献：
[1] 王珊.数据库与信息系统[M].北京：高等教育出版社，2005.
关键词：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.
关系数据库系统作为软件企业核心的数据处理系统，不仅在我国取得了十分广泛的应用，而且对我国信息化建设发展具有重要的作用与意义。而数据字典系统作为保证关系数据库系统正常运行的最基础软件，在很大程度上影响着关系数据库系统的运行状况具有重要影响。而本文笔者将对关系数据库系统的数据字典系统进行深入的分析与研究。
【关键词】关系数据库 管理系统 数据字典 研究
作为关系数据库系统功能实现的最核心软件，数据字典系统的设计与实现是十分重要的。只有做好数据字典系统的设计，才能有效的保障关系数据库系统的正常、稳定运行。本文将对关系数据库系统中的数据字典系统进行分析与研究。
1 数据字典物理存储
1.1 数据字典的定义
数据字典的一个重要作用就是提供最终用户数据库所有的信息，在物理存储上就采用跟其他用户表一样的实现，提供统一的接口。而数据字典的主要作用还是提供给DBMS自身使用，在实现上还跟整个数据库的结构功能相关。
1.2 数据字典的逻辑功能
具体来说，关系数据库中的所有数据信息与关联都与数据字典有着十分紧密的联系。数据字典具有着对关系数据库中的所有对象进行定义的逻辑功能，除此之外，数据字典还可以对关系数据库中的序列值进行默认、对数据库中的各种信息进行约束、对数据库中的用户信息进行存储和统计、对数据库中的用户权限进行分辨，并且还可以对数据库中的各种信息的定义以及它们之间的关联进行操作与辨别。
由于关系数据库之中的各个对象之间存在着较强的关联性，当用户对某一对象进行删除操作时，往往会由于该对象与其它对象之间的关联程度与类型不同而产生一定的影响。例如数据库用户在PRLMARY KEY上建立起一个unique index文件，而这个unique index文件的主要功能就是帮助PRLMARY KEY实现其自身的功能任务。而由于PRLMARY KEY是依附在一个数据表中的，当删除表或是表中的相关信息有所变动时，依附于这个表存在的PRLMARY KEY中的unique index里的信息也会相应的被删除或有所变动。而数据字典负责的功能就是将关系数据库中发生的这些关联信息与操作完整的记录和保存下来。通常来说，关系数据库中的所有这些关联对数据库的用户都是公开透明的，而另一种情况就是数据库用户为了方便自己的操作或是其它因素，在对数据库中的对象进行删除操作时需要加上由用户自己设定的关系语句才能实现删除操作，当此删除操作实现时，与该对象有着密切关联的其它信息也会一并被删除。
1.3 物理记录的存储格式
关系数据库中的数据字典与用户数据都是以表的形式被记录保存在关系数据库的物理文件中的，并且关系数据库管理系统中有着多种物理存储格式，每一种物理存储格式都有着各自不同的特点，相互之间具有较大的差别，而这都是由于关系数据库管理系统中并发模式类型的不同造成的。现阶段，我国的数据库管理系统将加锁模型与多版本模型作为最为主要的两种并发模型。其中加锁式并发模型的特点是记录格式简单、无需版本信息就能实现，如SQL Server并发模型。而多版本并发模型主要有Oracle数据块并发模型。该种并发模型不仅需要用到物理记录来对数据库中的版本信息进行记录，而且还需要物理格式的帮助来实现对数据库系统的并发控制及相关的事务处理，比较复杂。
2 数据字典内存表示
2.1 CACHE作用
关系数据库管理系统能够通过对数据字典中的信息数据进行读取来获得数据用户以及数据库中的对象与存储信息，当数据库用户需要对某些数据进行查询和相关的操作时都需要利用其所发出的SQL语句来对数据字典中的信息进行查询，查询频率非常高。现阶段，我国的数据库管理系统主要由两部分组成，即CACHE与RELCACHE。其中CACHE主要负责的是对数据库管理系统中的表进行存放。在该部分中，一个系统表能够利用ID查询、NAME查询与主键查询中的任意一种方式进行查询，除此之外，用户也可以通过部分键对该系统表进行查询。当查询操作完成后，关系数据库系统会根据数据字典的分析最终弹出用户需要寻找的表格。
而RELCACHE部分的每一项都是一个RELATION结构，该结构对此结构中的所有数据信息与关联进行了记录与保存。并且此结构能够将关系数据库系统中的所有与需要查询事件相关联的描述信息进行联合构造，以更好的满足数据库用户的需求，提高关系数据库管理的质量与水平。
2.2 数据库的启动与CACHE的初始化
使关系数据库能够启动并发挥其应有的作用，操作人员至少要做好以下三个步骤，即将一个实例启动，之后对数据库系统进行装配操作，第三，将数据库系统打开。使数据库的CACHE系统得以初始化的方式有两种：第一种，在数据库系统建立时进行CACHE的初始化，主要负责对数据库系统的内存进行分配；第二种，数据库系统已经建立完成后在启动时进行初始化操作，此时，内存已经分配完毕，用户只要正常进行启动操作就可以完成CACHE的初始化。
3 结束语
本文主要对关系数据库管理系统的数据字典程序进行了分析介绍与研究，希望能够进一步推动我国关系数据库系统的管理质量，促进关系数据库系统的进步。
参考文献
[1] 程阳.关系数据库管理系统的一种简易的数据存储与查询模块的设计与实现[D].华中科技大学（硕士学位论文），2012.
[2] 冯玉才，李东，王元珍，曹忠升.一种移动数据库管理系统的体系结构[J].计算机研究与发展，2011，38（5）： 620-625.
[3]何新贵，唐常杰，李霖.特种数据库技术――数据库技术丛书之一[M].北京：科学出版社，2010.
1、用图形表示主从关系，直接设置外键；
2、方便数据库程序员较快的掌握数据库表之间的关系和数据库表的结构；
3、表达数据表间的依赖关系，对于数据库可靠稳定地工作具有重要意义。
关键词:关系数据库;云端数据库;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:
Abstract： From the system structure， internal function， external interface and indexing algorithm， this article discusses the improvement and optimization of SQLite. It also talks about redesigning the RT-database storage way according to the characteristics of Internet appliances， improving the RT-system performance by the active rule library， and the CGI program design for home gateway based on SQLite.
关键词： SQLite；家庭网关；嵌入式Linux；内存数据库
Key words： SQLite；home gateway；embedded Linux；memory database
中图分类号：TP311.1 文献标识码：A 文章编号：1006-4311（2015）26-0069-03
0 引言
在信息家电系统中，要用遥控器对各类信息家电主动控制，并随家庭环境的变化对信息家电进行自动控制，整个系统中存在着大量实时数据的采集和处理需求。目前对数据的处理通常采用基于数据库的方式，所以构建具有实时性能的嵌入式数据库系统是家庭网关设计环节必须要解决的问题。
结合国内外家庭网关研究的现状和进展，如何改进嵌入式实时数据库对信息家电状态信息的采集处理效率；如何优化数据库系统的资源占用，成为家庭网关系统设计的重要环节。
1 家庭网关的发展与演进
作为智能家居的大脑，家庭网关的作用至关重要。本文主要针对家庭网关数据库平台进行研究，选择合适的数据库架构，改进、移植相关软件，搭建网关的软件系统，设计网关系统中心主模块和web服务程序，实现嵌入式web 服务器的基本功能。
2 嵌入式开发环境的选择
要想保证系统能够真正地发挥自身功能，选择合适的操作系统至关重要。现阶段比较成熟的嵌入式系统主要有：Windows CE、Unix、Linux、QNX等。从家庭网关平台日后的系统升级、维护和功能扩展这些角度出发，本文中的家庭网关平台采用Linux2.6版本作为软件开发平台。
Linux2.6内核拥有更多的新特性：性能方面，采用了新的内核抢占式算法和新的I/O调度算法；稳定性方面，改进了内核加载和导出机制，提高了平台的稳定性和可靠性。设备支持方面，系统内核取消了对大型系统的限制，支持更多的控制器和设备；文件系统方面，扩展了文件的属性，保证了系统的信息安全，增强了PCI总线支持，对USB、蓝牙等外设总线进行功能扩展，满足多种短距离无线传输，方便家庭网关的内部组网。[1]
3 嵌入式网关系统的模块化设计
家庭网关软件系统采用模块化设计，包括系统定制、系统服务、设备模块、控制模块、显示模块、软件开发控制等。其中系统定制模块包括系统移植、内核定制、驱动开发等部分；系统服务模块由系统中心、可移植层、设备管理器、维护管理器、存储系统组成，如图1所示；设备模块主要包括视频模块、Zigbee模块、网络模块等；控制模块主要由web 服务器和各种应用服务器组成[2]。
4 SQLite数据库的改进与移植
4.1 数据库的选型
家庭网关中的嵌入式实时数据库是为了完成家电状态信息的管理而设计的小型数据库。应具备如下功能：支持多种数据类型；支持创建和删除多个表；支持对记录进行插入删除修改和查询操作；支持表的索引操作；支持触发操作，以满足信息家电之间的统一协作。
基于嵌入式linux系统的数据库非常多，常用的有以下几种：
Oracle Database Lite；DB2 Everyplace；Berkeley DB；Firebird；MySQL；SQLite。本文选取的SQLite数据库系统是一个简单易用、开放源码的轻量级嵌入式数据库管理系统。它具有以下优势：支持ACID事务；不需要安装配置、支持大部分SQL92；数据存储在单一的磁盘文件中；最大支持数据库到2TB；内核精小；数据操作速度快等。
4.2 SQLite的应用系统设计
SQLite系统的体系结构包括8个主要模块，如图2所示。
应用程序接口是SQLite的公共接口，通过main.c，table.c，legaey.c，vdbeapi.c程序来实现。词法分析器负责将原始的SQL语句按顺序传送到语法分析器里。语法分析器是一个基于上下文环境的输入语法解释器，采用非终结符析构器的概念，大大降低了出错的几率。通过调用代码生成器，可生成SQL查询所需的虚拟机代码。虚拟机是使用堆栈存储指令来实现处理代码生成器产生代码的虚拟引擎。B-树驱动器通过表和索引中的B-tree创建相应的数据库实例。B-tree模块在磁盘建立1024字节大小的页面缓存，进行读写缓冲，管理数据库文件的读/写锁定的权限。SQLite通过Linux系统的操作系统接口来打开和关闭、删除和创建文件，释放磁盘的缓冲。[3]
SQLite系统与Linux的外部接口的具体应用集成在一起，由程序调用相应的核心API函数去实现对数据的存取操作。Sqlite3_open（）可以打开数据库文件，建立SQLite引擎；sqlite3_exec（）对查询结果进行处理；sqlite3_close（）用来关闭数据库文件，释放SQLite引擎。
4.3 对SQLite存储结构及索引机制的改进
由于SQLite所有数据都保存在设备的Flash中，为了减少FO操作，延长Flash的寿命，对数据的操作都设计为在内存中完成，只在设备启动和修改保存数据时才进行FO操作。将SQLite改进为基于内存的嵌入式关系型数据库，提高数据操作效率，增强实时性能。
4.4 优化SQL数据在内存中的存储结构
在内存中采用区段式结构进行内存数据的组织管理，将存储空间逻辑地划分为多个分区。每个分区存储一个关系。区段式数据组织管理机制如图3所示。
为保证数据结构的紧凑性，内存数据库中的关系表按编号登记在分区表中。当有新数据段插入时，在分区表或段表中找到插入点，插入点后的所有表项都往后移动一项；而删除一个表项时，则删除点之后的所有表项都往前移动一项。
为节省内存占用，分区表和段表均采用动态数组结构，具体操作是：创建时都先申请适当大小的表项空间，数据的增加使得区段表不断增长，当表项空间不够时，再申请一定数量的空间。相反，数据的删除操作使得区段表不断缩短，当其尾部出现大量的空表项时，回收空表项占用的内存。[4]
4.5 优化内存数据库的索引机制
为适应智能家居中对实时数据频繁的查找和更新需求，进一步改进高效的索引机制加速操作的执行速度，需优化内存数据库的索引机制。SQLite系统采用是基于改进的Hybrid-HT的H-T索引机制，本文通过优化H-T机制中的哈希函数，通过对哈希表长的控制，分散了键值对记录指针和哈希地址的操作范围，从而高效率利用内存空间，提高查询、修改的操作速度。[5]
5 家庭网关数据库系统的设计
本文构造的嵌入式家庭网关，是以S3C440系列嵌入式微处理器为中心，uCLinux嵌入式操作系统作为家庭网关的底层，移植部分功能模块作为家庭网关硬件平台。信息家电通过IAIDL接口向家庭网关注册，每个家电的注册信息、参数和状态信息都存放在SQLite数据库中，如图4所示。
信息家电接口定义语言（IAIDL）是一种用来定义智能家居网络中信息家电的说明性语言，是对设备资源信息的描述。
以某公司生产的某信息空调为例，其IAIDL描述如下：
IAIDL定义了家庭网络中设备之间的互操作，详细描述信息家电的属性和功能。家庭网关利用编译器提取设备所发送的IAIDL描述内容进行解析，利用API函数将相关信息存储在SQLite数据表中。SQLite库中的信息表包含设备类型表、设备列表、设备属性表、设备接口表、事件通道表五种表格。由系统将设备类型号作为关键字，作为每类设备的唯一标识，如图5所示。[6]
编译器对设备IAIDL完成分析扫描后，通过API函数接口生成数据库文件。信息家电启动时，系统会在内存区域生成设备状态表的副本作为设备运行状态表。这些文件不会随着时间的变化而发生改变，真正实时变化是处于运行状态的设备状态信息。
实时监控系统按一定的扫描频率对内存中的设备运行状态表进行扫描，数据采集模块按照设定的频率对外部信号进行采集，经数据处理模块将数据存入内存中的设备运行状态表，获取最新的状态数据，完成对设备状态的实时更新和控制。
信息家电中的黑色家电是供人们娱乐休闲用的，如电视机、VCD、音响等。黑色家电的状态绝大多数情况下不会发生改变，所以设定所有的黑色家电都没有实时状态信息，在内存中不生成设备运行状态表，需要查询时可以从flash中读取。
而白色家电的状态会随着时间的变化而不断变化，数据的实时性要求很高，如空调、电冰箱等，是改善生活环境提高物质生活水平的。白色家电启动后在内存中生成设备运行状态表，可以随时监视到设备状态。
在系统中构建主动规则库对设备的实时状态进行监控，当设备状态变化时对家电进行自动控制，或设备状态异常进行报警，由ECA规则来实现。一旦信息家电出现异常情况，就要进行报警操作。信息家电在满足这些设定的事件时，系统能自动执行规定好的动作。[7]
在设备运行过程中，数据随着各种设备的运行不断产生，系统将新的状态数据写入内存，实时数据会转储为历史数据。为保证系统的稳定性，系统中的实时数据备份模块负责周期性将内存中设备状态表数据保存到Flash中。当设备运行故障时，可以从历史数据库中进行恢复。
6 家庭网关WEB服务器的设计
家庭网关中各种动态信息需要服务器实时创建，服务器程序与客户端浏览器有较强的交互能力。本文采用BOA+CGI应用程序构建WEB服务器。CGI是外部扩展应用程序与Web服务器交互的一个标准接口。Web服务器通过调用CGI程序实现和Web浏览器的交互，处理来自客户端浏览器输入的数据，从而完成客户端与服务器的交互，实现动态Web技术。[8]
WEB服务器从SQL查询结果中读取信息，同时把这些信息返回给客户端。CGI应用程序可以使用printf（）函数将查询结果以HTML的形式输出到客户端，向客户端返回动态页面，实现用户WEB服务器与数据库SQLite的交互。
总之，整个家庭网关程序设计都以嵌入式数据库实时SQLite为核心，可有效满足家庭网关对信息家电实时数据管理要求。
7 结论
本文针对嵌入式设备的实时性特点，结合家庭网关的实际应用需求，对SQLite数据库系统的体系结构、内部函数、外部接口、索引算法等方面进行了改进与优化。提高了系统整体实时性能；完善了数据库的安全性；降低了系统资源占用，良好的匹配了现有ARM架构的家庭网关硬件体系，完全能满足家庭网关对信息家电实时数据管理的要求。
由于自身水平、设备条件有限，本文还有很多需进一步改进的地方，如事务处理的调度和执行策略方面；身份验证、数据加密等安全性研究方面，对报警库，CA库，ECA库的详细设计方面还有待于进一步的充实和完善。
参考文献：
[1]宋安，习勇，魏急波.基于μCLinux的NAT设备的设计与开发[J].电子工程师，2005-05-15.
[2]徐叶，袁敏，李国军.嵌入式Web服务器远程监控系统的设计与实现[J].计算机与现代化，2013-02-27.
[3]王俊，郭书军.嵌入式Web服务器的实现及其CGI应用[J]. 电子设计工程，2011-11-05.
[4]高建国，崔业勤.ARTs-EDB的内存数据存储管理[J].微计算机信息，2010-01-25.
[5]陈嘉.嵌入式主存数据库索引机制的研究与改进[D].湖南师范大学，2006：278-282.
[6]刘志东.基于嵌入式Web技术的远程射频识别系统的设计与实现[D].西北民族大学硕士论文，2012-04-01.
关键词：关系型数据库管理系统 Visual FoxPro；Access SQL Server
目前的商用数据库市场，近90%是采用关系数据模型。例如，小型数据库系统 Visual FoxPro, Access, MySQL等，大型数据库系统 DB2, Ingers, Oracle, Informix, Sybase, SQL Server 等．
目前，计算机数据库课接触比较多的有 Visual FoxPro, Access 和 SQL Server，前两种列为了全国计算机二级考试科目．下面对这三种关系型数据库管理系统进行比较．
1、数据库的区别及安全性
Access 的数据库文件格式是 MDB，一个数据库就是一个文件，所有的数据库对象都存储在这一个文件中．Visual FoxPro 的数据库文件格式是 DBC，一个数据库也是一个文件，但所有的数据库对象都分别以不同的格式存储，即是不同的文件．SQL_Server 的数据库物理上也是一个 MDF 数据文件，但 MDF 数据文件可以说是一个数据库的集合，里面包括了很多个数据库．
SQL_Server 提供相同的企业级安全性机制，可以完全控制用户访问数据库的情况，并提供完备的数据安全性方案．在 Visual FoxPro、Access 中也有一些安全方面的配置，但其性能根本没有 SQL Server 完善．
2、DBMS 和数据库的物理位置
Visual FoxPro, Access 的 DBMS 系统和数据库是不能分离的，必须物理上在同一台计算机．SQL Server的 DBMS 可以和数据库分离，即单独安装在物理上不同的计算机上．SQL Server 是支持客户机/服务器结构的数据库管理系统，数据库系统管理工具、前端开发工具和后台数据库是可以分离的，通常我们所说的网络数据库管理系统指的是管理工具和后台数据库的总和．
3、数据库规模和开发运行环境
Visual FoxPro 的规模属于一个中小型数据库开发软件，Access 也适用于中小型企业数据管理的需求．SQL Server 可以帮助各种规模的企业管理数据，是真正的中大型数据库．
Visual FoxPro和Access提供的是较弱的数据库管理和较强的前端开发工具，开发工具与数据库集成为一体，既是数据库管理工具，又是数据库应用开发的前端工具，在Visual FoxPro 6.0 里就集成了应用开发工具，直接使用VisualFoxPro 就可以进行数据库应用系统开发．在Access 2000 和 2003 里集成了脚本语言．
Visual FoxPro 可以编译成独立程序，脱离开发环境运行，可以生成独立的 EXE 文件作为商业软件产品；Access 应用只能在 Access 软件环境中运行，想要脱离 Access 只能用 VB 等来编程调用 Access数据库，现在小型 Web 开发中 ASP+Access 或JSP+Access 的方式比较常用．
SQL_Server 仅仅是一个数据库引擎，没有集成接口开发工具．任何前台应用程序的开发都需要开发程序来处理．
4、支持的操作系统
Visual FoxPro、Access 的计算机操作系统为桌面型操作系统，如 Windows 98/XP 系统等，不提供或仅仅提供有限的网络应用功能．SQL Server可以运行于 Windows NT/2000/XP 等多种操作系统之上．需要网络操作系统支持，包括 WindowsNT Server，Windows Server 2000，Windows Server2003，Linux Server，UNIX，Solaris 等．
5、学习和使用的难度
Access 被集成到 Office 中，具有 Office 系列软件的一般特点，如菜单、工具栏等．简单易学，一个普通的计算机用户，没有程序语言基础，也能快速地掌握和使用它．Visual FoxPro 除了掌握数据库的操作外，还涉及到程序设计，需要一定的程序语言基础，学习比 Access 稍难．
SQL Server 不但要掌握 SQL Server 的操作，而且还要能熟练掌握 Windows NT/2000 Server 的运行机制，以及 SQL 语言，所以对非专业人员的学习和使用有一定的难度．
总之，如果数据库系统并发的用户数较少，对安全性的要求也不高，那么 Visual FoxPro、Access 的性价比比较高．SQL Server 是基于服务器端的中大型的数据库，适合大容量数据的企业单位应用，在功能和管理上比 Access 和 Visual FoxPro 强得多．
参考文献：
[1]傅荣会.三种关系型数据库管理系统的比较研究[J].重庆三峡学院学报,No.3.2011.
中图分类号： 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
关键词：数据仓库；数据挖掘；客户关系管理；客户流失
中图分类号：TP311文献标识码：A文章编号：1009-3044(2012)26-6200-03
Application of Customer Relationship Management Based on Data Warehouse and Data Mining
XIAO Yan-qun
(Yangzhou polytechnic college,Yangzhou 225009,China)
Abstract: Data Warehouse and Data Mining are important tools in storage, analysis and extracting data. According to Customer Relationship’s characteristics, Data Warehouse and Data Mining are added to its management,which mainly focuses on introduc? ing the application in the prevention and reduction of customer loss.
Key words: data warehouse; data mining; customer relationship management; customer loss
随着市场经济的发展，产品种类日益丰富，企业之间的竞争越来越激烈，卖方市场已过渡到了买方市场，对现代企业而言，当下最主要提升的不仅仅是产品本身，更为重要的是客户的争夺。因此，企业要想立于不败之地，必须能够对市场上发生的变化做出迅速的反应，而导致市场变化的根源就是客户行为的变化。企业已经逐渐认识到保有客户的重要性，只有不断提升服务意识，有针对性地满足客户的需求，企业才能长期发展。因此，企业当下的重要课题就是要加强客户关系管理，提高核心竞争能力。
客户数据的收集与存储是实施客户关系管理的根基。随着办公自动化的推广，数据库和网络技术的应用，各企业拥有的客户信息越来越多，增长迅速。在这海量的、异构的信息资源中，蕴含着具有巨大潜在价值的信息资源，比如客户的基本资料、产品交易信息及客户反馈信息等[1]。企业要想不陷入信息的沼泽中，必须拥有强有力的数据分析工具，用以实现客户关系管理的目标。而数据仓库和数据挖掘技术的发展可以很好地解决这个问题。
1数据仓库与数据挖掘技术
1.1数据仓库
数据仓库是一个在企业管理和决策中面向主题的(Subject- Oriented)、集成的(Integrated)、反映历史变化的(TimeVariant)、相对稳定(Non-Volatile)的数据集合[2]。
数据仓库要求数据量大，数据正确全面，所以数据在进入数据仓库前必须经过提取、转换与集成，把数据按主题分类，形成多维数据模型。它以多维数据模型为基础，实现数据的分析处理，主要用于支持管理决策。数据进入数据仓库后，一般会被长期保存，基本不会进行修改和删除操作，主要实现数据的查询。
数据仓库与传统关系型数据库不同，主要区别在于数据仓库打破了关系数据库中数据的规范性，实现了数据的重组，增加了数据冗余度；其次传统关系型数据库为了实现数据处理的及时性，要求数据尽量少，而数据仓库为了更有效的实现数据查询，要求存储的数据尽量多，实现海量存储。
1.2数据挖掘技术
数据挖掘技术，是近几年国内外迅速发展起来的一门交叉学科，涉及到数据库、统计学、人工智能与机器学习等多个领域，并在金融、商业零售、电信以及生物医学和基因分析等领域得到广泛应用。
1.2.1数据挖掘的概念
数据挖掘(Data Ming)，是指从大量的、不完全的、有噪声的、模糊的、随机的数据中，提取隐含在其中的、人们事先不知道的、但又是潜在有用的信息和知识的过程，提取的知识一般可表示为概念(ConcePts)、规则(Rules)、规律(Regularities)、模式(Patterns)等形式[3]。
数据挖掘是知识发现的过程，是将未加工的数据转换为有用信息的整个过程。该过程包含一系列的步骤：确定业务对象、数据准备、数据挖掘、模式评估和知识表示[4]。
1.2.2数据挖掘的技术与方法
数据挖掘方法是以数据库为对象，基于机器学习、科学计算、统计分析等技术，形成了数据挖掘方法和技术。一般，数据挖掘常用的技术与方法可以分为以下几个方面：
1）决策树方法
决策树方法是利用信息论的原理建立决策树，主要用于分类和预测。决策树是一种简单的知识表示方法，它将事例逐步分类成代表不同的类别。由于分类规则比较直观，易于理解，实用效果好，影响较大，因而得到广泛应用。决策树最早的算法是Quinlan提出的ID3算法，最流行的是其改进版的C4.5算法。
2）聚类方法
聚类分析是直接分析样本，按照各样本数据间的距离远近将样本数据分成若干个不同的类。一般，同一类中的对象相似度很高，不同类中的对象相似度很差。聚类分析属于无监督的分类方法。
3）统计分析方法
统计分析方法是通过统计学中的技术方法实现数据库的数据分析，发现数据间的关系和规律。常用的方法有：回归分析、相关分析、主成分分析等。
4）关联规则
关联规则通过对给定数据集中的数据进行关联分析，描述一个事物中某些属性频繁同时出现的条件，发现隐藏在其中的有趣的联系或规律。一旦建立起数据项间的关联规则，则其中某一项的属性值就可以依据其他属性值进行预测。
5）可视化技术
可视化数据分析技术在传统图表功能基础上进行了拓展，为用户提供交互式的数据浏览，帮助用户更清楚地剖析数据。当所要识别的不规则事物是一系列图形而不是数字表格时，人的识别速度是最快的。
2数据仓库与数据挖掘技术在客户关系管理中的应用
2.1客户关系管理
客户关系管理（CRM）关注的是企业与客户之间实时、方便的信息交互，通过与客户多渠道的接触、交流和沟通，实现从“接触管理”到“客户关怀”的角色转变，企业的经营中心也从产品或市场转变为客户。客户关系管理最核心的任务是对企业运营过程中所得到的各种数据进行分析，进而为企业经营决策提供支持和依据。
从功能上来看，CRM系统可分为三种类型[5]：
1）操作型CRM
操作型CRM也称为流程型CRM，主要用于客户信息的自动集成过程，实现企业各部门对客户信息的协同合作。
2）分析型CRM
分析型CRM用于分析操作型CRM中产生的各种数据，使用数据仓库和数据挖掘技术产生商务智能，为企业决策提供支持。3）合作型CRM
合作型CRM用于企业与客户的合作服务系统，包括电话、呼叫系统、电子邮件等，它能实现客户信息的全面收集。
2.2数据仓库的形成
数据仓库是CRM的中央存储系统。在这个信息爆炸的时代，各个企业经过长期经营，收集了大量的客户数据。而这些海量、异构的数据被分散在不同部门，没有得到充分合理的利用。因此，首先要做的是对这些海量分散的数据进行清洗、集成和转换,建立一个整合的、标准化、结构化的数据模型,形成全面、一致和面向决策的数据，即数据仓库。对已形成的数据仓库，按照不同的主题，产生多个对应的数据处理模块，如普通客户数据模块，Vip客户数据模块，团体客户数据模块等，这种多数据模块的建设有利于分析不同客户的行为特点。
2.3数据挖掘技术的应用
使用数据挖掘技术对企业客户信息进行分析，从而挖掘出对企业发展有价值的信息，如：新客户开发、交叉销售及预测、客户信用分析、客户细分、客户类别分析等客户关系管理功能，为企业决策者提供更有效的的决策支持，最大程度地发挥企业CRM的作用。
近年来，随着市场竞争的加剧，企业要想获得一个新客户，所花费的开销往往是争取留住老客户的几倍。有统计数据表明：1）公司一般每年平均流失10%的老客户；
2）企业留住5%的老客户，利润提升100%；
3）开发新客户的成本是留住老客户成本的5-8倍；
4）一个公司如果将其客户流失率降低5%，其利润就可能增加25-85%。
因此保持老客户就显得更有价值。那么，如何才能预防、减少客户的流失呢？一个非常重要的工作就是要找出顾客流失的原因。我们可以通过数据挖掘技术实现这一目标。
现以电信公司判断用户离网的可能性来做分析,首先进行数据准备,抽取一定量的用户信息，提取的信息主要包括:用户号码、用户类型、用户状态、话费性质(长话/市话)、欠费情况、投诉次数等,利用这些数据，我们来建立判断用户离网可能性的模型。
在数据准备和适当的预处理之后，我们采用决策树中的C4.5算法建立决策树模型。这里，我们引入了信息论中的信息增益率的概念并以此作为属性选择的标准，其核心是在决策树的各级节点上选择属性时用信息增益率作为属性选择标准。通过计算这些属性的信息增益率，找出“投诉次数”属性作为决策树的根节点。扩展决策树节点，进行分枝，其他中间节点也是选择各节点检测属性增益最大的属性，同级的预选属性的增益相同时，规定选择属性值个数较少的属性作为当前节点的分枝，最后，我们可以生成一棵决策树。
生成的决策树还需要进行进一步验证，才能最终得到可用的分类模型。选择一些具有共同特征的已离网用户作为测试数据,输入属性值进行离网判断,检验模型的正确性，生成最终的决策树模型。
使用生成的决策树模型，对比用户的信息是否贴近离网用户的特征属性值，能大致预测出该用户的离网可能性，对离网可能性高的用户，根据其特征属性进行挽留工作，从而预防、减少客户的流失。
3结束语
在当前的技术形式下，将数据仓库和数据挖掘技术有效运用在CRM中，对企业收集的大量客户数据信息进行分析，挖掘出对企业发展有价值的客户信息，从而更有效地提升企业的竞争能力，树立企业的品牌形象，帮助企业实现有效的市场营销和客户服务，达到成功挽留客户的目的。相信未来会有更多的行业加入使用客户关系管理的行列中，通过数据仓库和数据挖掘技术挖掘出对自身发展有用的信息，也必使CRM的目标得到更好的实现。
参考文献：
[1]白雪.数据挖掘技术在客户关系管理中的应用研究[J] .大众科技,2012 (2).
[2] Han Jianwei,Micheline Kamber.Data Mining Concepts and Techniques[M].Morgan Kanfmann Publishing,2000.
[3]陈安.数据挖掘技术及应用[M].北京:科学出版社,2006.
