关系数据库篇（1）

中图分类号：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数据库的地方就使用关系型数据库，通过相应的转换办法，就可以实现它们之间的数据共享。

参考文献：

关系数据库篇（2）

中图分类号：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网站所遇到的性能、扩展性等问题具有指导意义。

参考文献：

关系数据库篇（3）

中图分类号P28 文献标识码A 文章编号 1674-6708（2014）111-0112-02

地理信息系统也就是我们简称的GIS，他具有管理、采集、描述、贮存以及分析等各个方面的地理分布与地球之间所有相关的数据信息。当前，信息社会随着不断的进步与发展，我们应用的GIS是作为集合了所有的地理空间以及和所有的信息统计相结合的系统，它也是作为信息传送的重要基础设施，并且得到了广泛的关注，是我国当前最为热门的一类课题研究。在其它国家，这种技术从上个世纪就已经得到了大力的发展，所以技术也相对成熟，成功率也相对较高。在我国这种技术发展的较晚，但势头却很猛烈，现阶段已经取得了一定的进展，也具有一定的突破，并且应用在相关的单位当中。然而与国外相比较仍然会存在一定的差距，在技术方面还需要不断的学习和研究，我们很多技术人员在近些年以来都在开发GIS的数据库系统，并且也取得了一定的成效，这也为以后的发展奠定了基石。

1 GIS数据库概念分析

1）在当前形势下，由于科学技术在不断的发展，尤其在计算机技术领域方面以及在系统信息，数据库等方面的实践研究都已经得到了很大程度的提升，并且也取得了一定的成功，这也就促使人们在应用地理信息时不会仅限在单一的产品中了，而会把计算机的有效管理应用在更为繁琐的地理信息当中，同时便将经济与社会当中的所有信息等方面进行有效的叠加，从而取得更大的价值，并且把效益放大化，获得良好的成绩，所以，这就产生了GIS的产业发展与相应的理论研究。然而，在这其中我们要清楚，GIS所应用的基础必须基于系统信息，而它的基础则是建立在相关联的数据库上。我们要清楚，GIS是和其他的系统相同的，都具有同样的特性，所以在设计上应该遵守相应的设计。由于GIS的技术服务不仅仅是地图产品，他还具有更多的实用功能，他可以对地理信息以及对其全面的整合都具有很大的帮助，比如在统计信息、检索、管理以及在分析方面等都比较突出；

2）我们在认识地理信息以及依赖和利用这方面的知识已经具有很长的历史了，而最为有效的应用就是相关的地图信息，因此，在进行研究时我们发现，地图历史要早于文字，并且他应用了地图的语言以及相关的数学法则的综合应用，把世界客观的一面通过地图加以呈现，但是从实质上我们看出，他是通过应用符号、公式化以及更为抽象的表现出客观世界，因此，通过地图表现，我们才可以更为真切的对生存环境做进一步的认识，同时也借助于了有效又其简单的工具，看到了客观世界，这种信息的传递以及认知能力是无法替代的，所以，不管我们未来会发展成怎样，都离不开地图的应用，依赖于他；

3）在GIS数据库当中，他所存储的一般都是地理信息，其中包括有属性图形数据等，并且具有不同的特征，比如有分辨率和数据的精准度，一种是描述尺度的，另外一种是描述数据的精准度的，对此，我们可以看出，在GIS数据库当中已经不再显示比例尺了，所以，他不具有这方面的意义的，也就是说，如果指地名时，只代表一种社会信息，并不代表其它意义，所以，也可以说是地理信息。而所谓的比例尺也只不过指的是地图数据库的一种特征。在一般情况下我们所说的比例尺，也就是地图数据库，并不是所说的GIS。通常GIS我们是把他当成一个信息仓库，所反映出的信息是更为真实和直接的，并不是在特定要求下所反映出来的。

2地图数据库

地图数据库是大不相同于GIS数据库的，他是带有一定的比例尺概念，并且建立了一个具有特定比例尺的仓库，如果需要应用更多的比例尺地图时，就要进行建立更多的数据库，如果条件允许，也可以建立几个分支数据库，方便管理。一般情况下，GIS可以管理地图数据库，我们也可以建立专门系统对其进行管理。在管理过程当中，对地图数据库的管理模式需要应用简单模式，也就是一幅图可以配备一个文件。此外，在地图数据库当中，会带有一定的图形属性表现，这主要包括有大小、文字、符号、图层、线型以及粗细等方面。而一般在GIS数据库当中是不会体现出这些属性的，他只是针对一些规范要求和图式来改变的，并不代表专一性，也没有体现出更多的属性。在地图数据库当中，产品的管理都是具有相应的标准模式的，都是电子产品，所以就会保留他们的各种本质特点，但是，怎样对其进行分层管理，对其进行有效的编辑，并且显示出必备的图层以及印刷颜色的要求以及对大小进行无限修改，拼接或裁切和量测等方面进行有效的调整。在其它方面，如果需要更新地图数据库时，也可以针对部分进行有调整的更新变化，从而减少电子地图的调整时间。在一般的情况下，地图数据库在更新方面会很慢，属下游产品，在更新方面还取决于GIS数据库，并不是取决它的上游数据源，他们之间的关系属于单向。由于在地图当中会存储大量的信息，而这些信息都是通过过人为进行修改和编辑的，所以我们所看到的这些信息都不是现实世界当中所反映出来的真实特点，更不是在GIS数据库当中的真实内容了。

3 结论

当前，信息社会随着不断的进步与发展，我们应用的GIS是作为集合了所有的地理空间以及和所有的信息统计相结合的系统，它也是作为信息传送的重要基础设施。在我国，由于建设GIS技术已经发展了多年，并且很多专家在这种技术方面也已经更为深入的进行了研究，并且已经取得了一定的进展，也具有一定的突破，并且应用在相关的单位当中。虽然与国外相比较仍然会存在一定的差距，还需要不断的学习和研究，我们很多科技人员在近些年以来都在开发GIS的数据库系统，并且也取得了一定的成效，这也为以后的成功发展奠定了很大的基础。

参考文献

[1]施一军.基于GIS技术建立地图数据库的构想和实现[J].测绘通报，2011(1).

关系数据库篇（4）

中图分类号：TP311文献标识码：A文章编号：1009-3044(2011)09-1971-02

1 绪论

随着计算机技术的不断发展，数据库作为计算机发展的一个重要方向也得到了长足的进步。数据库技术近五十年的发展过程中形成了独立的理论基础，在服务于金融、信息管理等各个方面形成了多种多样的数据库产品，广泛的应用于社会各个领域。数据库根据服务对象的不同，已经开发建设了成千上万个数据库，为政府、企业、部门提供了强大的数据处理能力。

一般数据库作为程序开发的后台数据处理系统，在各种开发工具和环境下，往往会让数据库的“兼容性”大大降低。这种情况是怎样产生的呢？这就要从数据库的特性来分析和解决这个问题。

2 数据库里数据导入理论基础

简单地说，数据库就是按照数据结构来组织、存储和管理数据的仓库。而数据库里存放的数据是结构化的为多种应用服务的；数据存储独立于使用它的程序。对数据库插入新数据，修改和检索原有数据均能按一种可控制的方式进行。这也就为数据库里数据“兼容性”提供了理论依据。首先是数据整体性，数据库是一个单位或是一个应用领域的通用数据处理系统，它存储的是属于企业和事业部门、团体的有关数据的集合。数据库中的数据是从全局观点出发建立的，是按照一定的数据模型进行组织、描述和存储。其结构基于数据间的自然联系，从而可提供一切必要的存取路径，且数据不再针对某一应用，而是面向全组织，具有整体的结构化特征。其次是数据共享性，数据库中的数据是为众多用户所共享其信息而建立的，已经摆脱了具体程序的限制和制约。不同的用户可以按各自的用法使用数据库中的数据；多个用户可以同时共享数据库中的数据资源，即不同的用户可以同时存取数据库中的同一个数据。数据共享性不仅满足了各用户对信息内容的要求，同时也满足了各用户之间信息通信的要求。基于这两点数据库里数据相互导入就有了充足的理论依据了。

3 数据导入的“瓶颈”

在数据库开发现实环境中，由于开发公司的不同因而产品也多种多样，和数据库模型及数据接口等因素造成了数据导入难以实现。而数据往往是需要移植和共享的，所以各个公司都在积极探索数据导入方法。

现在数据库开发的公司并不多，甲骨文公司（Oracle）是世界最大的数据库软件公司，它的开发工具有Oracle Jdeveloper和Oracle Designer等一系列产品。Oracle数据库一般比较适合超大型的行业领域，如电信、移动、联通、医疗保险、邮政部门等。微软（Microsoft)公司是全球最大的电脑软件提供商，在Windows操作系统中，Microsoft Access和Microsoft SQL Server是最常见的数据库，以及Visual Fox Pro 6.0数据库管理系统，它们同时都可以应用于网络程序应用系统。一般情况下，Microsoft Access数据库和Visual Fox Pro 6.0数据库管理系统比较适合小型或家庭型的应用程序，而Microsoft SQL Server一般比较适合大型的应用程序。还有其它如IBM等公司也有自己的数据开发平台和产品。这些公司的数据库产品都有着自己鲜明的公司属性。

在数据库开发过程中，数据库的应用一般都是关系数据库，而关系数据库能把现实世界中的各种实体以及实体之间的各种联系均用关系模型来表示。关系模型由关系数据结构、关系操作集合、关系完整性约束三部分组成。关系式数据结构把一些复杂的数据结构归结为简单的二元关系。在关系数据库中，对数据的操作几乎全部建立在一个或多个关系表格上，通过对这些关系表格的分类、合并、连接或选取等运算来实现数据的管理。关系数据库的应用领域非常广泛，主要在证券行业、银行、公司或企业单位，以及政府部门、国防军工领域、科技发展等领域。

4 数据导入的途径和方法

关系数据库不但应用领域广泛而且对数据库里数据都做了严格的定义，数据自然是最理想的数据模型。因为关系数据库里的数据在数据类型、域（值）、属性等方面都有较系统的定义和规范，所以关系数据库数据就成为处理数据最实用的方式和存取方式了。再加上，现在程序编写由原来的面向过程结构化程序设计理念转向面向对象编程（OOP）编程架构的转变，都为数据库数据的调入和导入提供了强有力的保证。

由于在实际工作中，有些数据、报表并不是用关系数据库个模型存放的，可能有的还是用文本的形式记录的。这些数据多且繁杂，往往需要导入到数据库中进行管理和储存。而这种数据的移库是一项艰巨的任务，费时费力且容易出错。在这里一个重要的问题就是要将非关系型数据转换成关系型数据。

在日常的数据处理中一般都使用办公软件中Microsoft Excel软件。这套软件确实给日常数据处理工作带来了极大的方便，但是Microsoft Excel却只是对数字的运算和逻辑判断而不能进行关系运算。美国微软公司推出了Visual Fox Pro 6.0数据库软件，却是一款关系型数据库管理系统。由于这两种软件同属于微软公司开发，所以有着很好的兼容性，可以Excel电子表格导入成VFP6.0数据库表文件，如图1所示。

当然，Excel数据表也可以导入到Microsoft Access成为Access数据库表。因为两者同属于Microsoft Office办公软件，所以导入也比较简单，如图2所示。

如果数据还只是文本，可以通过Microsoft Word转换成Microsoft Excel表格再进行上述操作就可以了。

5 结论

导入后生成的数据库表文件就是关系数据库数据了。关系型数据库功能非常强大，使用起了非常方便。这是由于数据库采用了结构化查询语言（SQL），在对关系数据库里的数据进行存取、查询、更新和管理时，都采用一组标准的语言结构来书写，SQL语言结构简洁功能强大且简单易学，从而得到了广泛的应用。这对我们利用不同的计算机高级语言编写的程序和开发软件时，在对数据库处理时就太方便了。因为它作为软件系统一个独立的部分使用SQL就可以很方便的调用了。SQL又是非过程化编程语言，允许用户在高层数据结构上工作同时不需要用户了解具体的数据存放方式，具有完全不同底层结构的不同数据库系统，都可以使用相同的SQL语句来管理数据库数据。

参考文献：

关系数据库篇（5）

中图分类号: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.

关系数据库篇（6）

摘要： 本文从体系结构，内部函数，外部接口，索引算法等方面对SQLite进行了改进与优化；针对信息家电特点重新设计了实时数据库的存储方式，利用主动规则库来提高系统的实时性能，并基于SQLite对家庭网关进行了CGI程序设计。

关键词 ： SQLite；家庭网关；嵌入式Linux；内存数据库

中图分类号：TP311.1 文献标识码：A 文章编号：1006-4311（2015）26-0069-03

作者简介：李宏升（1973-），男，河南新蔡人，讲师，工学硕士，主要从事互联网与嵌入式应用研究方向。

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描述如下：

美的空调 is <空调>

{

enum type=(slow，normal，quick);

enum switch=(on，off);

attribute厂家=美的电器公司;

attribute功率=1.5P;

state温度状态Temp int(29:<20:the_min_value>，<40:the_max_value>);

state风速状态fan type(normal，normal);

function设置温度void ST Temp(in int st(20，40)):

function设置风速void ST Fan(in type ff);

function开关void On Off(in switch 00);

}

SQLite中家电信息表的生成

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.

关系数据库篇（7）

中图分类号：TP393 文献标识码：A文章编号：1007-9599 (2011) 11-0000-01

Relational Database Network Office System Study

Chen Jinping

(Dalian Fishe Ries University Vocational&Technical College,Dalian116300,China)

Abstract:The database is the data of scientific management,advanced technology,is an important part of computer science,relational database applications are becoming increasingly widespread.This paper describes the enterprise network in the office of information technology systems relational database design and application,the application method has a certain universality and representation.

Keywords:Relational databases;Office system;Enterprises;Server

一、企业网络办公系统信息化建设中关系型数据库的设计

（一）系统结构的选择

在整个系统开发过程中系统结构的设计是最重要的一环。对于网络办公系统来说，尤其是一些结构关系较为复杂的系统，如果没有一个科学合理的系统结构而要有一个完善的办公系统是不可能的。不同类型的应用系统需要定制不同的系统结构，系统的设计在很大程度上取决于系统结构的规划。按照系统业务情况的不同，可把企业网络办公系统的开发结构分为B／S（browser／service）和C／S（client／service）两种结构模式。它们特色鲜明，是当前常见的系统开发模式。

B／S结构的系统以服务器环节为核心，除了部分脚本，大部分程序解析和数据处理都在服务器端完成的，用户不需要安装特殊的客户端程序，只要能够连接服务器，使用浏览器就可以访问系统。C／S结构的系统以服务器作为数据处理和存储平台，在终端要求安装有专门的软件来处理事务，数据被传递到服务器端，用户必须使用客户端应用软件才能访问系统。

（二）关系型数据库的设计

1.设计规则。综合考虑到企业办公系统基础数据量大，访问频繁，设计时尤其要注意系统的处理效率。同时从全局的层面出发，数据构成关系型数据库系统，保证全局数据的完整性和一致性。

2.系统结构。该企业办公系统是由数据库服务器和web程序服务器构成。数据库存放所有的管理数据，发展整个系统正常运行所需的数据，程序服务器存放应用程序，并且处理用户的访问请求。采用这种有冗余的相对集中的关系型结构可以对系统中的主要数据进行集中式管理。当WEB程序服务器收到用户的请求后，服务器应用程序和WEB服务器将请求转换为数据库访问命令，并发送到数据库服务器，数据库服务器执行命令并返回结果。

二、PHP语言在办公系统中的应用

该系统采用PHP（Hypertext Preprocessor）语言编写，它是服务器端的编译执行环境，我们可用它来创建动态Web页或生成功能强大的网络应用程序。对关系型数据表中的记录进行增加、编辑、删除可以用命令insert、update、delete来实现。现在以增加通知信息为例来说明PHP语言在办公系统中的应用：

$ddd=time（）；

if（empty（$timu））

echo"题目不能为空"；

elseif（empty（$_POST['neirong']））

echo"内容不能为空"；

elseif（empty（$lanmu））

echo"你没有选择栏目"；

$sortid=（float）$usec+（float）$sec；

$quer=mysql_query（"insert into$tongzhi set timu='$ timu'，neirong='$neirong'，lanmu='$lanmu'，ReleaseTime='$ddd'，AmendTime='$ddd'"）；

if（$quer）

echo"通知记录添加成功"；

else

echo"调整记录添加失败"；

?>

对记录的修改和删除方法与此类似。

三、关系型数据库在办公自动化管理系统中的实际应用

办公自动化管理系统安装在企业的服务器上，形成一个可供企业上至管理层、下至普通员工，根据不同的权限而使用相应功能的公共系统。

（一）系统实现的主要功能

（1）企业内通知的接收与发送。（2）企业公文的接收与发送。（3）企业业务部门电子公告。（4）内部员工电子邮件。（5）相应辅助功能：如日程安排，通讯录等。

（二）数据库设计

该办公自动化管理系统的数据库由HFYH（合法用户表），TZ（通知表），GW（公文表），NBYJ（内部邮件表）几个主表组成。

（三）系统特点

本系统与传统的办公管理系统相比，具有如下的优点：

1.占用主机空间小。对于传统的办公管理软件，用户如果希望实现数据管理，则必须在每台计算机上安装办公管理软件，占用主机空间。而本系统属于B/S系统，只要安装在服务器上，同时用户拥有使用权限，便可使用本系统。

2.安装简便。只需一次安装便可服务于多个用户。

四、结束语

网络技术日新月异，但是如果没有关系型数据库结合其中，办公系统将无法工作。本文介绍的关系型数据库网络办公系统中的应用方法，具有一定的普遍性和代表性。

关系数据库篇（8）

第一章绪论

当今社会，传统的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

关系数据库篇（9）

中图分类号：TP311文献标识码：A文章编号：1009-3044(2011)13-2988-03

The Data Transformation Methods for XML Documents to Relational Databases Based on DOM

ZHU Xing-tong

(School of Computer and Electronics Information, Guangdong University of Petrochemical Technology, Maoming 525000, China)

Abstract: With the popularity of Internet and the rapid development of Web technology, XML is quickly becoming the standards for data representation and exchange, the emergence of a large number of XML data in order to achieve fast query and efficient exchange of data, you need to transform from XML document to a relational database. This article describes the data transformation methods for XML documents to relational databases based on DOM.

Key words: XML; DOM; relational database; transform

1 XML技术

XML[1]是eXtensible Markup Language的缩写，称为可扩展标记语言。1998年2月W3C正式推出了XML（XML1.0）。XML的前身是SGML（Standard Generalized Markup Language，标准通用标记语言）。XML是一种简单的数据存储语言，使用一系列简单的标记描述数据，它可以标记任何一种事物。XML的跨平台型，它提供了一种不同的应用程序之间进行数据库交换的公共标准，是一种公共的交互平台。XML文件是由标记以及它所包含的内容构成的文本文件，这些标记可自由定义，其目的是使得XML文件能够很好地体现数据的结构和含义。W3C推出XML的主要目的是使得Internet网络上的数据相互交流更方便，让文件的内容更加显而易懂。

W3C XML1.0规范给出一种XML通用数据模型。XML文档定义为具有一个名字和根元素。一个XML文档有一棵树组成。一棵XML文档树是一个节点的集合，其中每个节点至少有一个父节点，并可以有多个有序的孩子节点。一个XML文档存在六种类型的节点：

1）声名节点。包括XML声明信息和DTD声明信息。

2）元素节点。每个元素节点有一个名字、一个父节点、一个属性节点集、一个有序的由元素节点、字符数据节点和注释节点组成的孩子集。其中根元素节点没有父元素，而且每个文档只有一个根元素节点，它引用整个XML文档资源。

3）字符数据节点。文档中的字符数据字符串，包括CDAT段。

4）属性节点。每个属性节点有一个元素父节点、一个属性名和一个属性值。多值属性例如IDREFS，分成多个节点。

5）注释节点。由一个该文注释组成。

6）处理指令节点。由一个目标和数据组成。

下面给出一个XML文档例子。

XML实用教程

范立锋

24

人民邮电出版社

智能计算

曾黄麟

28

重庆大学出版社

2 文档对象模型（DOM）

XML解析器是XML和应用程序之间的一个软件组织，为应用程序从XML文件中解析出所需要的数据，XML解析模型如图1所示。

文档对象模型（Document Object Model，DOM）提供了一种从其他的应用程序中调用或管理XML数据的方法。处理方法是将一个XML文档看作一个对象，通过固定的方法和属性对XML文档的不同标记进行读写。DOM规范的核心就是树模型，对于要解析的XML文档，解析器会把XML文档加载到内存中，在内存中为XML文件建立逻辑形式的树，上面XML文档例子对于的DOM树图2所示。DOM就是XML文档的一个结构化的视图，它将一个XML文档看作是一棵节点树，而其中的每一个节点代表一个可以与其进行交互的对象。树的节点是一个个的对象，通过操作这棵树和这些对象就可以完成对XML文档的操作，为处理文档的所有方面提供了一个完美的概念性框架。通过DOM解析器处理XML文件效率高，但是，十分消耗系统的资源，比较适合复杂但相对较小的文件。DOM解析器解析XML文件需要下列几个步骤：

1）建立一个DOM解析工厂；

2）通过解析工厂创建DOM解析器；

3）解析指定的XML文件；

4）根据标记名称获得node标记列表；

5）遍历每一个node节点；

6）获得标记内容。

3 XML文档到关系数据库的数据转换

XML文件和关系数据库有很多相似之处，关系数据库采用二维表方式存储数据，XML文件通过标记之间的关系来描述数据。关系数据库提供了对于大批量数据的有效存储管理和快速信息检索、查询的功能。XML文件是基于标记的文本文件，兼容性好，便于组织、解析和交换数据。某个系统获得一个XML文件后，可能需要将XML中的某些标记包含的文本内容转化为数据库中表的一条记录，以便发挥关系数据库在管理数据方面的优势；另一方面，一个应用系统可能需要将关系数据库表中的某些记录转化为一个XML文件，以便与其他系统交互数据，发挥XML文件在数据交换上的优势。

要把XML文件中数据写入关系数据库中，首先需要利用解析器解析出XML文件中的数据，再利用某种技术获得数据库的连接，把数据写进数据库。Sun 公司制定了 JAXP(Java API for XML Processing) 规范，用于在 Java 程序中以一种标准的方式对 XML 文档进行处理。将XML中的某些标记中的内容转化为数据库中表的一条记录，主要步骤如下[5-6]：

1）使用DOM解析器获取标记中的数据；

2）连接数据库,将获取的文本数据作为一条记录添加到数据库。

下面给出使用Java语言开发的基于DOM的XML文档到SQL Server2000数据库的数据转换的实例，实现把上面XML文档例子的数据写入SQL Server2000数据库中books表中，主要代码如下。

public class XMLToDatabase{

public static void main(String args[]){

Connection con=null;

Statement sql=null;

ResultSet rs=null;

try { Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");

}catch(Exception e){

System.out.println(""+e);

}try { con=DriverManager.getConnection("jdbc:odbc:books","","");

sql=con.createStatement();

DocumentBuilderFactory factory=

DocumentBuilderFactory.newInstance();

factory.setIgnoringElementContentWhitespace(true); //忽略缩进空白

DocumentBuilder domPaser=factory.newDocumentBuilder();

Document document=domPaser.parse(new File("books.xml")) ;

Element root=document.getDocumentElement();

NodeList list1=root.getElementsByTagName("title");

NodeList list2=root.getElementsByTagName("author");

NodeList list3=root.getElementsByTagName("price");

NodeList list4=root.getElementsByTagName("publisher");

int size=list1.getLength();

String [] title=new String[30];

String [] author=new String[20];

double [] price=new double[4];

String [] publisher=new String[30];

for(int k=0;k

Node titleNode=list1.item(k);

Node authorNode=list2.item(k);

Node priceNode=list3.item(k);

Node publisherNode=list4.item(k);

title[k]= titleNode.getTextContent().trim();

author[k]=authorNode.getTextContent().trim();

String str=priceNode.getTextContent().trim();

price[k]=Double.parseDouble(str);

publisher[k]=publisherNode.getTextContent().trim();

String insertData="INSERT INTO books VALUES('"

+ title[k]+"','"+ author[k]+"','"+ price[k]+"',"+publisher[k]+")";

sql.executeUpdate(insertData);

}con.close();

}catch(Exception e){ System.out.println(e); }

}}

运行上面的程序将前面的XML文档例子中的数据转换到SQL Server2000数据库中，books表中的数据如图3所示。

4 结束语

关系数据库系统相当成熟，把XML文档数据转换到关系数据库中，可以发挥关系数据库在管理数据方面的优势.本文介绍的利用Java语言实现基于DOM的XML文档到SQL Server2000数据库的数据转换方法，经实例验证是正确可行的。利用Java语言与DOM相结合来解析XML文档，需要把XML文档全部加载到内存中。如果XML文档非常庞大，以及解析器耗尽内存，就会造成内存溢出异常。

参考文献：

[1] W3C.Extensible Markup Language (XML) 1.0 (Fifth Edition)[EB/OL]./TR/2008/REC-xml-20081126/.

[2] 朱珊娜,李书琴,安福定.XML文档到关系数据库的转换研究[J].计算机工程与设计,2008,29(21):5507-5509.

[3] 林耀进.基于实现XML文档与关系数据库转换的方法[J].计算机与现代化,2007(6):43-45.

[4] 蔚晓娟,冉静,李爱华,等.基于DOM的XML解析与应用[J].计算机技术与发展,2207,17(4):86-88.

关系数据库篇（10）

中图法分类号：TP311文献标识码：A 文章编号：1009-3044(2007)03-10617-01

1 引言

在数据库中，数据冗余、数据不一致等问题会引起各种数据操作异常，为了尽可能的避免此类问题，能过模式规范化将关系模式分解为若干比较小的关系模式以消除冗余等现象。

2 关系模式

关系模式级别有1NF、2NF、3NF、BCNF等多种，1NF是关系模式的基础，关系模式中每个属性值都不可再分就为1NF，称不上1NF的关系模式，就不能算是关系模式，1NF是关系模式应具备的最起码的条件。

例如：库存（仓库号，设备号，数量，地点）每个属性均不可再分，所以该关系模式首先就是1NF级别的。

1NF关系模式很可能具有不受欢迎的冗余和异常现象，我们现在需要把关系模式做进一步规范化，对它进行分解让它达到2NF。2NF就是在1NF的基础上消除非主属性对键的局函数信赖，那么我们分析上例，库存（仓库号，设备号，数量，地点）为1NF，但非2NF。

非主属性“数量”完全依赖于关键字。非主属性“地点”局部依赖于关键字。即有仓库号地点。（仓库号，设备号）地点。那么将它分解为2NF的方法，将局部函数依赖关系的决定方和非主属性从关系模式中提出，单独构成一个关系模式，再将余下属性加上码构成另一关系模式。

那么我们按此方法最后将库存（仓库号，设备号，数量，地点）分解为：

库存（仓库号，设备号，数量）仓库（仓库号，地点）。现在分解出来的关系模式就不会出现数据插入、数据操作等异常了。

3NF是在2NF的基础上消除了所有非主属性对键的传递依赖，如关系模式：仓库（仓库号，所在省，仓库面积，所在城市）是2NF而非3NF，因为仓库号所在城市，所在城市所在省，所以仓库号所在省，不是3NF，其中会出现数据插入异常的问题。假如在广东深圳要设一个仓库，想先存入有关所在城市信息，但还暂时无仓库号，现在则不能插入数据。

为避免此类问题需将它分解为3NF，分解方法就是将传递依赖的属性分解出来。例关系模式：仓库（仓库号，所在省，仓库面积，所在城市）就可分解为仓库（仓库号，仓库面积，所在城市） 城市（省，城市），那么就不会再出现数据插入异常现象了。

虽然3NF在数据库设计中常常出现但有的情况下3NF也存在操作异常，我们就需要对它进行一步分解为更高范式BCNF。BCNF是在3NF的基础上消除了主属性对非主属性的函数依赖。如学生（学号，姓名，专业，宿舍）假定无重名，则码为学号或姓名，非主属性对这两个码不存在部分函数依赖和传递函数依赖，所以是3NF。而同时除{学号}和{姓名}以外没有其他决定因素，所以也是BCNF。

范式是衡量模式优劣的标准，范式表达了模式中数据依赖之间应满足的联系。关系模式在分解时应保持“等价”，数据等价和语义等价两种，分别用无损分解和保持依赖两个特征来衡量。

3 结束语

关系模式的规范化过程是一个分解的过程，把逻辑上独立的信息放在独立的关系模式中，是解决数据冗余的主要方法，也是规范化的原则。

参考文献：

[1]龚小勇.关系数据库与SQL Server2000[M].机械工业出版社,2004.