关系数据库例1

通俗地说，关系型数据库就是采用了关系模型来组织数据的数据库。简单来说，关系模型就是一个类似于二维表格的模型，而关系型数据库就是由二维表格及其中含有的数据所组成的一个数据组织。在关系数据库中，有些名词需要我们了解：

关系：通俗地说，在一张二维表格中，每个关系都具有一个关系名，就是通常说的表名table。

属性：在二维表格中也就是类似于excel表格中的一列，在数据库中被称为字段。

域：属性的取值范围，也就是数据库中某一字段的属性限制条件。

关键字：一组可以唯一标识元组的属性。数据库中常称为主键，由一个或多个列组成。

关系模式：指对关系的描述，其格式椋汗叵得（属性1，属性2，…，属性N）。也就是数据库中的表结构。

随着数据库应用领域的扩展以及数据对象的多样化，传统的关系数据模型暴露出了许多问题，如对复杂对象的表述能力差，表达能力较弱。为此，人们提出了许多新的数据模型，下面笔者向大家介绍一下以前的数据库的主要特点：数据不保存、系统没有专用的软件对数据进行管理、数据不共享、数据不具有独立性。

在文件系统层面上，数据可以以文件的形式进行长期保存，数据交由文件系统管理数，独立的机制使得程序与数据之间具有一定的独立性但在这个结构中，数据的独立性、共享性差，冗余度大、易造成数据传输之间的不一致性。

在数据库系统层面上，数据可以结构化，数据之间的共享性提高，冗余度小，一个用户可以拥有多个数据库，因此数据独立性高，数据控制功能也变得统一起来。其中大可分为4类：

第一类，数据安全性控制；第二类，数据完整性控制；第三类，数据的并发控制；第四类，数据管理与恢复。

数据结构化，在数据库系统中，将数据按照一定的数据模型插入到一个结构化的数据库中，需要考虑此数据库的数据结构，还需要考虑连接数据后的数据结构，而在以前的数据库中，这些，是我们看不到的。下面，笔者将就几个方面对其进行分析：

非关系型数据库的实质：非关系型数据库产品是传统关系型数据库的缩略版本，通过减少功能，来大幅度提升产品性能，类似于我们平时游戏中的资料篇。

目前市场上流通的大部分主流的非关系型数据库基本上都是免费的。而大公司中，名气大的关系型数据库开发软件，比如Oracle、DB2是收费的。这在很大程度上限制了一些平民用户的使用。但是在实际开发中，有很多小型的业务需求，并不需要完整的关系型数据库进行组建，非关系型数据库的功能就足够了。这种情况下，使用性能高、成本低的非关系型数据库当然是我们的首选。在性能上NOSQL是基于键值对的，可以理解成类似于Java中和HashMap中的键值对，数据表中的主键和值也具有相同对应关系，但在使用过程中是不需要经过SQL层的解析，所以性能非常高是它的主要优点。同样，它也具有良好的可扩展性，这也是基于键值对，数据之间存在相当低的耦合度，所以在使用的时候非常容易扩展。

在SQL语言中，关系型数据库对其也具有独特的解读优势：在复杂查询语句中，可以用SQL语句根据表连接、嵌套、子句等方法方便地在一个表或多个表之间做复杂的数据查询，且代码的冗余性很低，这也使得数据库对于安全性能要求很高的数据得以访问，对于非关系型数据库，就没有这些优点。

但是近年来的发展中，两种数据库类型都在不同的需求市场中发展着，虽然有所交集，但是这并不影响数据库的进化方向。比如，NOSQL数据库自从2008年的更新版本以后，慢慢开始具备SQL数据库的一些复杂查询功能，并随着服务端的更新，这方面的功能日益完善，而SQL数据库也在慢慢地进化着，在数据库平台上HandlerSocker技术的出现，可以在MYSQL上实现对于数据库SQL层的穿透，在非NOSQL数据库上使用NOSQL的方式访问数据库，可以实现无中心化的集群等特点，更是向我们说明了数据库在这些年间的变化。

对于研究数据库的人来说，或许关系型数据库只是数据库众多实现中的一个特例模型，在数据库中，类型的划分具有严格的限制。科学家们用严格的数学公式和逻辑形式定义了数据关系以及其中的各种运算，虽然这两极都因为各自的弱势而开始进化出另一极的一些特性，但是这些特性的增加也会导致数据库失去一些原本具备的优势，所以怎样构建和使用数据库的系统模型，是数据结构的框架构造工程师需要考虑的问题。

参考文献：

关系数据库例2

2传统关系数据库面临的挑战

基于二维关系模型的数据库在数据管理的发展历程中是一个标志性的时期，数据结构化存储，冗余较低、程序和数据具有一定的独立性、易扩充等特点。随着Internet技术的发展，涌现出半结构化、非结构化数据，对这些结构复杂的大数据的高效实时多维分析的需求越来越多。传统的关系数据库从70年展至今，虽然应用范围较广技术较成熟，但在处理海量数据方面还存在许多不足。（1）关系模型结构制约了快速访问大数据的能力。在二维关系表中，依据属性的值来检索相应的元组，受这种方式的束缚，在检索数据过程中，将耗费一定的时间，从而使访问数据的时间较慢。在存储对象设计上虽然可以使用分区的方法，提高数据访问冲突，但在大量数据的前提下，分区技术改善的性能较微弱。（2）处理大数据的灵活性不足。在应用系统中，用户的各种查询需求经常发生变化，不受时间和操作对象的约束，用户希望随时随地都能快速得到反馈结果。关系型数据库需要专门的数据库维护人员对用户的查询要求进行优化处理，不能及时的反馈给用户查询结果，这使得使用关系数据库存储数据的企业不具备对大数据的快速响应能力。（3）处理复杂结构数据能力较弱。关系型数据库对现实数据的处理常见类型为字符、数值等，对于半结构化和非结构化数据的处理只限于二进制代码文件的存储，而现今用户对复杂结构数据的要求上升为识别、检索和多维分析，如何处理占总数据量85%的非结构化数据，是许多关系数据库产品需要解决的问题。（4）存储维护管理PB级数据导致成本不断增加。数据量递增使得企业在硬件存储上投资不断增加，虽然存储设备的投入成本在逐步降低，但总成本却在逐步提高。此外，大量复杂结构的数据维护工作也给数据库管理员增加了很多负担。

3大数据库技术

随着大数据技术的日趋完善，各大公司及开源社区都陆续了一系列新型数据库来解决海量数据的组织、存储及管理问题。目前，工业界主流的处理海量数据的数据库有四种，分别是列式数据库、内存数据库、键值数据库及流式数据库。

3.1列式数据库

采用列族存储数据，将经常被使用的数据放到一个列族中，例如，经常会查询学生的学号和姓名，而不是专业，这样把学号和姓名放到一个列族中，专业放到另一个列族中，该数据库通常用来存储分布式大数据，HBase是列式数据库的典型代表。

3.2内存数据库

对数据库中所有数据的操作都在内存中完成，一般数据库也有一定的缓存机制，对大部分数据的操作都包含从外存到内存的读取，这一过程在很大程度上降低了系统的性能。由于在内存中的读/写是以纳秒为单位的，所以内存数据库的性能极高，Spark是内存数据库的典型代表。

3.3键值数据库

该数据库主要借助哈希表的结构，使用一个特定的键和一个指向特定数据的指针，利用键来完成对数据库中数据的添加、删除和查询操作，这种结构具有很好的扩展性，使系统具有较高的性能，Memcached、Redis、MemcacheDB都是键值数据库的典型代表。

3.4流式数据库

基本理念是数据的价值会随着时间的流逝而不断减少，因此，需要使式数据库来实现流式计算。流式计算处理模式是将源源不断的数据视为数据流，它总是尽可能快速地分析最新的数据，并给出分析结果，也就是尽可能实现实时计算。典型流式数据库：SparkStreaming、Storm。

4大数据SQL

关系数据库例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

2、方便数据库程序员较快的掌握数据库表之间的关系和数据库表的结构；

关系数据库例5

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

一、数据模型及其建立

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

参考文献：

关系数据库例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

目前的商用数据库市场，近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 强得多．

参考文献：

关系数据库例8

中图分类号：TP311.132.3文献标识码：A文章编号：1009-3044(2011)25-6079-03

Optimize the Data Structures in Relational Database by Normal Form

QIAN Zong-bin1，WANG Yan-bing2

(1.Anhui Technical College of Industry and Economy，Hefei 230001, China; 2.Huishang Technical College，Hefei 230001, China)

Abstract: In the database design phase,construct a well-structured relational schema and a compliant database is very important.A well-structured database can avoid anomalies when insert or delete in data manipulation and reduce redundant data in the database .In a relational database,we can raise the grade of nomal form table by standard the table and make the date's structure more reasonable in the datebase.Normal form have 1NF 2NF 3NF BCNF 4NF and 5NF.This article starting from the concept of functional dependency,for the purpose of design a well-structured table,introduce the important applications of normal form in database design by several examples.

Key words：datebase; relationship; functional dependency; normal form; code

数据库设计在软件的设计和开发中占有着重要的地位，数据库结构设计的好与坏直接关系着软件系统的成败。一般来说，数据库设计包括需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施以及数据库运行及维护等六个阶段。其中逻辑结构的设计占据着重要的地位，在此阶段，设计人员应该充分考虑如何构造合理的数据结构。比如数据库中应该有几个关系表，关系表中应该有哪几组属性，表之间以及属性间的联系和依赖等。

设计结构不好的数据库很容易存在数据冗余过多，插入、删除异常，更新复杂等情况。比如要设计一个教师信息表，有如下关系R（Tno，Tname，Tclass，Sdept，Mname，Wage），其中Tno表示教师工号，Tname表示姓名，Tclass表示课时量，Sdept表示所在系部，Mname表示系主任，Wage表示教师工资，候选码为（Tno，Tclass）。教师工号和所带课时量确定教师的工资，单课时量并不能确定工资。见表1。

可以看到，该关系模式的结构设计并不良好，其存在下列问题：

1）数据冗余过多：表中“所在系部”和“系主任”列中多次重复出现相同的值，造成大量冗余数据的产生，浪费系统的存储空间。

2）插入、删除异常：若新进一名教师，但该教师还未选课，由于码值不能为空，导致该教师其他信息也不能录入数据库，产生插入异常，类似的情况在删除时也会出现。

3）更新繁琐：若某教师从A系转入B系，本来只需要修改教师所在系部信息即可，但此时还需修改系主任信息，加大数据更新的复杂度。

以上类似的问题在关系数据库的逻辑结构设计阶段很容易出现，解决上述问题的一个重要方法就是关系规范化，即将一个符合低级别范式的关系通过模式分解转换为若干个高一级范式的关系模式集合，用范式规范化理论将一个表格拆分成若干个表格，表格与表格之间通过特定属性关联起来，从而达到消除对数据操作产生异常的问题。

1 函数依赖

函数依赖的关系规范化的理论根据，它表达是的关系模式中一个属性对于另外一个属性的约束关系，其定义为：设有关系R（U）是属性集U上的关系模式，X，Y是U的子集，若对于R（U）上的任意一个可能的关系r， r中不可能存在两个元组在X上的属性值相等，而在Y上的属性值不等，则称Y函数依赖于X，记作XY[1]。关系中函数依赖成立与否依靠的是现实生活语意判断或数据库管理员（DBA）对数据的定义。

在表1中，“教师工号”确定“姓名”、“课时量”、“所在系部”，“教师工号”和“课时量”决定“工资”，“所在系部”确定“系主任”，这就构成了属性于属性间的函数依赖关系：TnoTname，TnoTclass，TnoSdept，SdeptMname，(Tno，Tclass) Wage。

函数依赖分为完全函数依赖和部分函数依赖。在关系R（U）中，若XY，但是Y不依赖于X的任何真子集，那么称Y完全函数依赖于X，记作：。反之，若XY，但是Y不完全依赖于X，则Y对X部分函数依赖，记作：。在表1中（Tno，Tclass）Wage是完全函数依赖，而(Tno，Tclass) Tname是部分函数依赖。此外，还存在某属性间接决定其他属性情况，比如，Sdept函数依赖Tno，Mname函数依赖Sdept，那么由Tno可以间接决定Mname，此种情况称为传递依赖。

2 基于范式的数据库设计

范式由E.F.Codd于1971-1972年提出，后经过Boyce等人扩充。现在范式分为第一范式（1NF），第二范式（2NF），第三范式（3NF），修正第三范式（BCNF），第四范式（4NF）和第五范式（5NF）。关系能达到的范式等级越高，其结构也就越好。低级的范式可以通过模式分解达到高一级的范式标准。通过关系规范化可以解决关系模式中存在的数据冗余、插入和删除异常、更新繁琐等问题。一般来说，在函数依赖的情况下，关系模式能够达到BCNF就可以完全的消除插入和删除异常。

2.1 第一范式（1NF）

若某关系属于第一范式，则该关系中任何一个属性都是不可分割的数据项。其确定了关系表中属性的“原子性”，比如某关系有属性“工资”，包括基本工资和绩效工资，见表2。此关系就不满足第一范式。

实际上，在关系数据库中，所有的关系均满足第一范式的要求，不满足第一范式的数据库不能称之为关系数据库。满足第一范式只能做为数据库设计的一个基本要求，还不足以称为结构良好的关系，其仍然存在问题，需要通过模式分解以达到更高范式的要求才可以解决问题。

2.2 第二范式（2NF）

在表1中，该关系已经满足第一范式的要求，但其中仍然存在数据冗余，插入、删除异常，修改复杂等问题。仔细观察该表可以发现，其候选码为（Tno，Tclass），只有属性Wage完全函数依赖候选码，而Tname和Sdept属性只是部分函数依赖，该关系模式中部分函数依赖的存在，会导致在更新教师个人信息时必然要与其所带课时量联系起来，这显然是不合理的，因此若要解决问题，就需要消除表中存在的部分依赖关系，从而达到第二范式的要求。第二范式的概念为：若R∈1NF，且每一个非主属性完全依赖于码，则关系R∈2NF。第二范式消除了关系中的部分依赖，这可以大大减少数据插入、删除异常等问题。

在表1的关系R（Tno，Tname，Tclass，Sdept，Mname，Wage）中，函数间依赖关系如下：

根据第二范式的要求，对其规范化，将该关系分解成教师表Teacher（Tno，Tname， Sdept，Mname）和工资表Wage（Tno，Tclass，Wage）。经过分解后得到两个独立的表，每个表中表达实体更加简单，已经不存在部分依赖。这样在增加或删除教师信息的时候，只需要修改教师表就可以了，而无需考虑其课时量等情况，提高了数据库的科学性、合理性。其实关系规范化强调的就是一个关系应该反映一个实体或一个联系的准则，而不应把几样关系混合放在一起。

2.3 第三范式（3NF）

关系模式R中，若不存在这样的码X，属性组Y及非属性组Z（Z ?埸Y），使得XY，YZ成立，X不依赖于Y，则称R∈3NF[1]。第三范式消除了关系中非主属性对码传递函数依赖。

第二范式消除了关系中存在的部分函数依赖，从而优化了数据库的表结构，但是其并不能完全消除数据插入、删除异常，更新繁琐等问题，因为其可能存在传递依赖。表1教师表中，通过模式分解将其分为Teacher（Tno，Tname， Sdept，Mname）和Wage（Tno，Tclass，Wage）两个关系表，拆分后的表已经不存在部分依赖，虽然数据库结构的合理性提高了，但在Teacher表中，属性Mname传递函数依赖于属性Tno。这样依然会出现数据操作上的问题。比如某教师从A系转入B系，本来只需修改其所在系部即可以，但存在传递依赖，就必须要修改系主任，增加了操作的复杂度。同样比如有一关系：R（学号，所在系部，系主任），此关系不存在部分依赖，但存在传递依赖，那么当某系学生全部毕业之后，该系的系主任信息也要一并删除，这是不合理的。

对于存在传递依赖的关系，需要对其进一步优化，使其符合3NF标准以消除了关系中存在的传递依赖，进一步提高关系结构的合理性。以“教师表”为例，对其进一步优化，可将其拆分成T-S（Tno，Tname，Sdept）和S-M（Sdept，Mname）两个表，它们之间通过属性Sdept连接，这样就可以解决删除、删除异常，更新繁琐等问题。

2.4 BCNF

BCNF由Boyce和Codd共同提出，它被称为修正的第三范式，它要求在关系中，每一个决定因素都包含码。BCNF消除了主属性对主码的部分依赖和传递依赖，进一步提高了数据结构的合理性。

比如现有如下关系G-S-M（Goods，Saler，Market），Goods表示商品名，Saler表示售货员，Market表示商场。其中，一名售货员只能在一个商场工作，一个商品可以在多个商场售卖，一个商场可以销售多种商品，一名售货员可以销售多种商品，且商场中并无重名的售货员，那么可以得出该表的依赖关系为：

（Goods，Saler）Market

SalerMarket

（Goods，Market）Saler

其中（商品名，售货员）、（商品名，商场）都是候选码。且没有部分依赖或传递依赖，所以其满足3NF，但是“售货员”是决定因素，且“售货员”并不包含码。因此，其不满足BCNF。在该关系中，会出现当某种商品售完而进货未到达时，该商品销售员信息和商场信息也一并删除的情况。问题的原因是存在主属性对码的部分依赖。第三范式消除了关系中非主属性对码的传递依赖，但并未解决主属性对码的部分依赖或传递依赖，因此一旦存在此类问题也可能会导致问题产生。改进的方法是将上述关系进一步拆分成商品表G-M（Goods，Market）和销售员表S-M（Saler，Market）。拆分后的表都符合BCNF，从而消除数据操作中产生的插入、删除异常等问题。

在实际应用中，达到BCNF标准的情况并不多，因为随着范式级别的提高，数据的存储结构与基于问题域的结构间的匹配程度也随之下降，在需求变化时导致数据的稳定性较差，同时范式级别的提高意味着需要访问的表增多，使系统性能下降[2]。在设计数据库系统时，应该根据实际情况设计出合适的数据结构。大多数情况下达到3NF标准即可。

3 结论

关系规范化在数据库的设计中尤为重要，对于存在部分依赖和传递依赖的关系，需要通过模式分解拆分成若干个关系，从而降低关系的复杂度，改善结构的合理性。在拆分过程中要考虑无损连接和保持函数依赖的问题。达到BCNF要求的关系模式已经可以在函数依赖范围内消除插入、删除异常等问题。在实际的数据库设计中还要注意以下2点：

1）关系模式达到BCNF标准并不能完全消除数据冗余。

2）在实际数据库设计以及应用中，并非规范化等级越高，效果越好，应该将实际应用环境和范式理论结合起来，选择最优的结构。比如在设计网络数据库时，不仅要满足一定的范式，而且要满足一定网络要求：数据的并发性访问非常频繁，网络数据流量要大，数据查询时要求简单、快速等[4]。

参考文献：

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

关系数据库例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

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

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

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