文档数据

文档数据（共9篇）

文档数据 篇1

随着计算机技术的发展和计算机的普及使用,各种信息管理系统被应用,数据处理自动化极大地提高了工作效率。虽然多数信息管理系统都是基于数据库保存组织数据的形式开发的,但涉及普通文档形式保存数据的情况时,难免要利用文档编程技术实现数据处理的自动化。OFFICE文档对象编程在许多针对OFFICE文档的应用中被广泛使用,本文将介绍OFFICE对象编程的一般原理,并给出对EXCEL文档进行数据比对,EXCEL文档与WORD文档结合进行数据合成等实例的实现过程。各种信息管理系统多是针对前期需求分析开发的,当用户在系统使用中产生新的文档数据处理需要时,利用OFFICE文档对象编程进行简便的二次开发可快速满足需求。

1 文档数据自动处理的原理

一般不同类型的文档都有各自的文档格式。在程序员角度,如果要编程实现程序读、写或处理文档中的数据,必须要了解文档格式。对记事本文件、C语言源码文件等一些格式简单的字符流文档,无论用何种编程语言,一般函数库中的普通文件处理函数就可实现文件读写操控,但OFFICE文件却不同,其文档格式较复杂,不是简单的字符流,其商业版权也使得其文档格式并不对外公开。幸而微软公司提供了OFFICE编程接口。

伴随着微软技术发展,OFFICE文档对象编程技术形式不断变化。早期为了让应用程序之间自动获取彼此的最新数据,微软推出对象的链接与嵌入技术(Object Linking and Embedded,OLE),应用程序的数据交换提高到“对象交换”,程序间可获得彼此的应用程序对象,从而可直接使用彼此的数据内容。但OLE1.0对象使用上还有许多限制,到OLE2.0阶段,OLE自动化、OLE控件、OLE文档使应用程序间能更好的相互协调工作。

OLE自动化允许一个应用程序自身暴露一些可编程对象给其它程序的应用程序,被使用对象的一方是自动化服务器,利用并操纵自动化服务器提供功能的一方叫自动化控制器。微软还为其桌面应用程序(尤其是Microsoft Office)推出了通用自动化语言——VBA(Visual Basic for Application),利用VBA或其他编程语言都可以针对OFFICE文档进行编程,实现文档数据的自动化处理。

在EXCEL中利用VBA语言操纵单元格中的内容,进行计算或数据处理时,EXCEL本身既是OLE控制器又是OLE服务器,若进行创建WORD文档等工作,则WORD是OLE服务器,EXCEL是自动化控制器。如用VC或VB等编程语言在程序中创建并编辑一个Excel工作表,则开发的程序是自动化控制器,EXCEL则是自动化服务器。从实现上讲OLE自动化是利用面向对象编程思想的深化,以com组件技术实现。

无论以何种形式针对OFFICE文档进行面向对象编程,一般都是通过创建或获得OFFICE文档对象,通过对对象属性、方法等的编程,实现程序对OFFICE文档数据的自动处理[1-5]。虽然随着各种新技术和新名词的出现,VBA、OLE自动化等技术看似已陈旧,但实际上在很多场合下,其数据处理的自动性及开发快速的特性使得其仍有较大的应用价值。

2 利用VBA进行EXCEL中的数据对比

VBA不能独立使用,需要一个宿主应用程序,微软的OFFICE软件套装中均支持VBA,并提供VBA编辑器方便开发。一般为了开发方便,用户可以先录制符合条件的宏,然后调整修改VBA代码,编写适合自己需求的自动化程序,实现对OFFICE文档数据的自动处理[1]。

虽然Office应用程序随着时间的推移已经发生了演变,不可避免地提供不同的对象模型,但仍保存了一些一致性,VBA对象模型从上到下有着一般性的层次结构:

1)顶层为Application对象。Word、EXCEL、PPT等都有自己的Application对象。Application对象代表了整个应用。

2)不同的Application对象下有不同的子对象。如EXCEL中是Workbooks集合对象,而WORD则主要是Documents集合对象。

3)再向下,EXCEL有Workbook对象代表Microsoft Excel工作簿,Worksheets集合对象代表指定的或活动工作簿中所有工作表对象,再到Worksheet对象代表一张工作表,再通过Range和Cells到单元格。类似地,WORD中深化各个Document对象,然后深化各个Range对象。通过各种细节属性及方法的使用完成对文档的细节操控。

以银行工作为例,业务数据一致性比对经常发生,每次抽检的数据字段可能不同,现有的信息系统可能无法提供这种临时性的功能。此时就可以利用VBA在文档中快速完成比对。如比较EXCEL文档中两列账户信息,筛选出B列中没有出现在A列中的账户有哪些。此时EXCEL没有合适的公式可用,但通过VBA中编程实现循环对比即可快速完成,示例代码如下:

3 VB编程实现WORD文档数据自动整合到EXCEL

下面讨论的实例基于这样的应用:员工招聘时每个员工都有一个单独的Word文档,但现有的办公系统不提供该格式WORD文件的处理,为了方便统一汇总和管理所有新员工信息,需要自动批量处理这些WORD文档,将文档中需要的数据统一提取到EXCEL文件中。

File System Object对象模型,是微软提供的专门用来访问计算机文件系统的,结合FSO和VBA对象编程可以批量处理OFFICE数据文档。FSO模型并不是VBA的一部分,它以COM组件的形式提供,包含在脚本类型库中。在VBA编辑器中使用时,可选择"Tools"菜单下"References...",在出现的对话框中选择"Browser..."选中COM对象文件C:WindowsSystem32Scrrun.dll。在其他开发平台中需通过相关的库引用设置菜单引入相应的项(如VB开发平台需在工程|引用中添加microsoft scripting runtime)。

将多个WORD文档数据批量提取到EXCEL的实现过程主要是通过VBA对象操控EXCEL文件,利用FSO循环处理文件夹下的批量WORD文件,这些WORD文件有相同的格式和数据表,利用VBA的WORD文档对象获取每个文件中的详细信息,然后写入到EXCEL文件中。如果没有复杂的界面要求,完全可以直接在EXCEL文件中实现。本例利用VB开发平台设计了一些简单的用户交互界面,但本质上仍然是FSO和VBA技术的结合使用,关键代码如下:

设置要提取的WORD文档表格中的单元格的行列值:

循环提取所有招聘文档中表格里的数据:

为了从汇总的EXCEL文件中再次方便地查看原始数据,可再通过对象编程,给EXCEL单元格建立超链接链接到源WORD文件。

4 结束语

对OFFICE文档数据进行处理,可以通过嵌入VBA的OFFICE文档实现;微软还提供了VSTO(Visual Studio Tools for OFFICE),基于Visual studio平台将应用程序编程和VBA的OFFICE对象编程结合起来,实现更丰富的OFFICE文档应用的二次开发;或者对现有的信息系统进行二次开发。各种方式开发代价不同,都能实现文档数据自动处理,其本质原理都是利用各种OFFICE对象模型实现的自动化数据处理。在工作中可以根据不同的应用环境和情况选择最合适的方式提高数据处理自动化程度,提高我们的工作效率。

参考文献

[1]王贵,石仙.利用VBA在Excel和Word中完成复杂的数据引用[J].电脑知识与技术,2011,24(7):5908-5010.

[2]刘永平.基于VBA的毕业设计文档自动生成系统[J].西安邮电学院学报,2011,2(16):46-48.

[3]余艳艳,周明刚.VC++实现Excel操作自动化的方法研究与应用[J].企业技术开发:学术版,2010,29(2):7-9.

[4]周静,袁方,袁江鹭,等.基于VSTO的Office二次开发[J].福建电脑,2011(9):22-23,36.

[5]桑银邦,王成良.XML数据交换在Office二次开发中的应用[J].计算机工程,2010,22(36):78-80.

文档数据 篇2

一、加密Microsoft Office文件

1、加密Word、Excel、PowerPoint文件

加密这三种类型的文件，方法相似，可以通过下面两种途径不定期实现。

途径一：选项设置。在上述应用软件的窗口(如Word)中，执行“工具选项”命令，打开“选项”对话框，切换到“安全性”标签下(如图1)，设置好“打开权限密码”和“修改权限密码”后，确定退出，然后保存当前文档即可。

图2

途径二：保存加密。在对上述文档(如“演示文稿”)进行“保存”或“另存为”操作时，打开“另存为”对话框，按工具栏上的“工具”按钮右侧的下拉按钮，在随后弹出的下拉列表中，选“安全选项”，打开“安全选项”对话框(如图2)，设置好“打开权限密码”和“修改权限密码”后，确定退出，然后再保存文档即可。

图2

[特别提醒]①根据你保密的具体情况“打开权限密码”和“修改权限密码”可以只设置其中一个，也可以设置全部设置(两种密码可以相同，也可以不相同)，

②对于PowerPoint，只有2002及以后的版本中才增加了加密功能。③在用途径二加密文件时，在Word中，选择的是“安全措施选项”，在Excel中，选择的是“常规选项”。

2、加密Access数据库文件

启动Access2002，执行“文件打开”命令，打开“打开”对话框，选中需要加密的数据库文件，然后按右下角“打开”按钮右侧的下拉按钮，在随后弹出的下拉列表中(参见图3)，选择“以独占方式打开”选项，打开相应的数据库文件。

图3

执行“工具→安全→设置数据库密码”命令，打开“密码”对话框(如图4)，设置好密码后，确定返回，即可对打开的数据库文件进行加密。

图4

二、加密WPS Office文件

加密用WPS Office中金山文字、金山表格、金山演示组件制作的文件，其方法是完全一样的，操作起来也非常简单。

在相应的组件(如“金山表格2002”)窗口中，执行“文件文档加密密码”命令，打开“密码”对话框(如图5)，确定返回后，再保存(或另存)当前文件就行了。

文档数据 篇3

基于WEB的信息管理系统的发展, 使得网络中的分布式异构数据库的数据集成和互访成为研究热点之一。传统的关系数据库的安全性、完整性、多用户并发访问、数据恢复等突出优点成为绝大多数用户构建数据库的首选模式, 然而, 在实际的企业应用中, 由于各种历史和客观情况, 不同的企业构建应用平台所采取的数据库系统存储格式不一定相同, 这样导致大量的异构数据库的存在。当企业应用平台进行数据交换和集成时就会出现各种问题。

XML语言, 作为SGML语言的子集之一, 由于其定义严格、独立性、结构清晰、兼容性、灵活易懂等特点, 成为描述WEB应用中各种复杂数据的最适合的格式之一, 作为数据交换标准, 在各种应用平台, 尤其是基于WEB平台的EDI中发挥着重要的作用。因此, 研究传统数据库和XML数据库的结合, 实现两个数据库中的数据交换, 显得尤为迫切和重要。

2 XML文档向关系数据库的转换

XML文档转换为关系数据库, 一般采取模型和结构为中心的转化方法[1,2,3]。结构转化方法根据XML文档中固有的模式信息生成对应的关系模式, 然后对XML文档进行解析分解并存储于对应的关系 (即表) 中。例如利用Schema思想直接映射为关系模式, 采用混合内联法根据XML文档的语义信息, 实现从DTD映射为关系模式[4,5]。模型转化方法是指将所有的XML数据根据XML文档结构的方式存储于固定关系模式的数据库中, 然后提取对应的元素, 实现到关系模式的转化。例如利用四个固定格式的表来存储XML文档, 利用群模式的XML树方法来存储XML文档[6,7], 都是标识和提取XML文档中的元素, 然后以关系记录 (表) 的方式进行存储。

目前研究的大多数XML文档向关系数据库的转化都是基于Edge的映射算法[8], 其主要思路是把XML文档扫描成一棵带标记的树, 根据节点、边把树中所有的边都存储在关系表中。本着减少关系表连接数目, 提高查询效率的原则, 对Edge算法进行了改进。根据Edge的映射算法, 将XML文档进行抽象, 转化成一棵有向、有序的带标记的树。然后做如下定义:

定义1对任意节点m, 按照有向图的原则, 统计关于该节点m的度、入度、出度, 则节点m的度的总数应为以m为开始节点的出度和以m为终止节点的入度和之和。

定义2如果节点m的入度为0, 并且通过节点m可以浏览树中的所有节点, 则节点m必为根节点;如果节点m的入度为1, 并且节点m的出度为非0, 则节点m为元素节点;如果节点m的入度为1, 并且节点m的出度为0, 则节点m为值节点。

定义3关系数据表rel, 包含编号、父节点编号、节点名称三个字段。

算法描述:

(1) 对XML文档采用SAX的方式进行文档解析, 这种解析方法提供顺序访问机制, 把XML文档的元素作为对象处理, 占用内存少, 检测速度快。

(2) 根据Edge算法, 对要映射的XML文档进行深度优先扫描, 根据定义1的方式, 记录XML文档中任意两个节点之间的结构关系, 并对结构图中出现次数大于1的所有元素加上指定的特殊符号标记, 用于对元素进行检测重复元素的时候进行区分。根据定义2, 当一个任意节点第一次被遍历时, 加上已经访问标记, 当该节点下面的所有节点遍历完成时, 取消该节点的已经访问标记, 如果检测结束, 该节点仍然有已经访问标志, 则说明该元素必然有特殊符号标记, 存在重复访问的问题。

(3) 对于步骤2的检测结果分两种情况处理, 把所有带特殊符号标记的节点映射为单独的关系数据表;对于其它剩余的普通节点, 如果节点m为初始节点, 则关于该节点所能访问的下属节点作为属性, 存入一个关系数据表中。

(4) 根据定义3建立的节点之间的关系数据表, 保存处理过的XML文档中节点之间的关系, 然后重构XML文档数据库。

最后, 根据上述算法及处理结果, 采用Microsoft Visual Studio2003和C#语言在Windows内部组件之一的.NET Framework代码库中进行XML文档到SQL Server 2003关系数据库的转化。具体转换实例由于篇幅原因省略, 转换结果发现, 该算法生成的关系数据表比较简单, 表间关系相对比较清晰, 表内元素独立性相对较好。

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

关系数据库向XML文档的转换一般采用XML文档向关系数据库转化的逆过程的原理或者采用JDBC API的方式完成。逆过程一般流程是, 根据XML文档的要求对将要转化成的XML文档进行描述, 包括关系数据库中的每个表, 表中的字段名称, 表间的关系等都定义成元素或者子元素的形式, 然后设置XML文档格式中根元素的开始标记和结束标记, 接着从开始标记起对关系数据库中的表的所有记录以及表间关系进行扫描。这种逆向转化方式的缺点在于将XML文档转化成关系数据库后, 再将关系数据库转化为新的XML文档, 会导致新旧两个XML文档的数据不会完全相同, 这与映射算法存在关系, 从XML文档到关系数据库的映射过程中, 属性和子元素都映射到关系数据库表中的一个字段, 而且在映射的过程会遗弃本身既是属性又是子元素的信息。不过这对最终的结果影响不是太大, 不会影响Internet网中的数据传输和处理。

在实际的数据转化和处理过程中, JDBC API的方式简单且易操作, 所以采用其实现关系数据库到XML文档的转化。基本流程是, 利用Java API for XML Processing、SQL Server 2003、XML的文本编辑器等工具, 通过JDBC实现和即将转换的关系数据库建立连接, 定义并执行SQL语句中基本查询语句SELECT语句即将转换的数据库中的信息, 记录查询结果;然后利用API建立JDOM树, 将查询结果的记录添加到JDOM树中, 其中字段名和字段值分别对应于XML文档的子元素名称和子元素内容;然后根据XML文档的格式, 将JDOM树输出为XML格式的文档。

简要介绍一下具体操作实现过程。

(1) 建立JDBC和数据库的连接。在计算机上安装Java应用程序、创建好SQL Sever关系数据库及相关数据表、安装JDBC驱动程序, 然后装入数据库驱动程序, 设置Connection对象, 创建Statement和Result Set对象, 分别用于执行SQL语句和对查询结果进行检索。

(2) 在SQL Server中使用Select语句对关系数据库进行查询, 由Statement对象发起, 并由Result Set对象进行查询结果的存储。为第四步的XML文档转化做好合适的数据准备。

(3) 设置转换规则。这是关系数据库到XML文档转化的核心环节。利用Select语句的查询结果, 创建一个临时的类似XML结构的文档, 然后修改数据结构的形式符合XML文档的结构, 主要是对Date、Element、Root三种元素的形式、名称、内容的定义。

(4) 将前两步存储的数据转化成XML文档格式。对前面建立的临时文档进行检索, 主要检索Data元素中存储的Result Set中的Select中的查询结果内容, 根据XML文档的结构形式抽取数据, 然后利用API建立JDOM树, 设置JDOM树的根节点, 利用Document对象把检索到的元素内容依次存储, 多次循环处理初始数据, 根据需要向临时文档加入元素及其相关属性, 直到把所有的数据都分析完。最后将得到的JDOM树按照指定的格式输出为XML文档。当然格式不指定也可以, 指定格式的输出文档可读性比较好。

4 结论

WEB的飞速发展和广泛应用, 尤其是物联网技术的带动, 使得XML语言在Internet数据传输中牢牢占据了主动地位, 在关系数据库模式中迅速有效的存储和转化XML文档也成为很多专家学者的研究热点, 但由于XML文档非结构化和结构化的关系数据库存在结构不匹配的原因, 二者的数据互换或者交换问题一直没有完美的解决方案。本文中提出的XML文档向关系数据库转化的改进的Edge算法以及利用JDOM树进行关系数据库向XML文档的转化, 在上机实现上相对比较简单, 基本上实现了结构化和非结构化数据之间的互换。但没有考虑到表的数据完整性和表间的关系的约束、参照完整性问题, 需要在以后的研究中进行补充完善。

摘要：简要介绍了XML文档和关系数据库进行数据交换的必要性, 并讨论了XML文档数据库和关系数据库之间进行数据相互转换的算法, 并对计算机上机操作的实验流程进行了简要的描述。

关键词：XML,关系数据库,交换,映射

参考文献

[1]Kei Fujimoto, Dao Dinh Kha, Masatoshi Yoshikawa, ToshiyukiAmagasa, “A Mapping Scheme of XML Documents into RelationalDatabases using Schema-based Path Identi.ers, ”wiri, pp.82-90, International Workshop on Challenges in Web Information Retrievaland Integration, 2005[1]Kei Fujimoto, Dao Dinh Kha, Masatoshi Yoshikawa, ToshiyukiAmagasa, “A Mapping Scheme of XML Documents into RelationalDatabases using Schema-based Path Identi.ers, ”wiri, pp.82-90, International Workshop on Challenges in Web Information Retrievaland Integration, 2005

[2]Dweib I, Aeadi A, Elrhman S E F, et al.Schemaless Approachof Mapping XML Document into Relational Database[C]//Proc.ofthe 8th IEEE International Conference on Computer and Informa-tion Technology.Sydney, Australia:[s.n.], 2008:167-172.[2]Dweib I, Aeadi A, Elrhman S E F, et al.Schemaless Approachof Mapping XML Document into Relational Database[C]//Proc.ofthe 8th IEEE International Conference on Computer and Informa-tion Technology.Sydney, Australia:[s.n.], 2008:167-172.

[3][6]SOLTAN S, RAHGOZAR M.A.A clustering-based scheme forlabeling XML trees[J].International Journal of Computer Scienceand Network Security, 2006, 6 (9A) , 84-89.[3][6]SOLTAN S, RAHGOZAR M.A.A clustering-based scheme forlabeling XML trees[J].International Journal of Computer Scienceand Network Security, 2006, 6 (9A) , 84-89.

[4]LEE D, CHU W.CPI:constraint preserving inlining algorithm formapping XML to relational schema[J].Data and Knowledge Engi-neering, 2001, 39 (1) :3 25.[4]LEE D, CHU W.CPI:constraint preserving inlining algorithm formapping XML to relational schema[J].Data and Knowledge Engi-neering, 2001, 39 (1) :3 25.

[5]Bohannon.From XML schema to relations:a cost based ap-proach to XML storage[C]//Proc of the18th International Conferenceon Data Engineering.2002:64 75.[5]Bohannon.From XML schema to relations:a cost based ap-proach to XML storage[C]//Proc of the18th International Conferenceon Data Engineering.2002:64 75.

[6]M Yoshikawa, T Amagasa, T Uemura, Shimura.A path-basedapproach to storage and retrieval of XML documents usingRDBMS.[J].ACMTOIT, 2001, 1 (1) :110 141.[6]M Yoshikawa, T Amagasa, T Uemura, Shimura.A path-basedapproach to storage and retrieval of XML documents usingRDBMS.[J].ACMTOIT, 2001, 1 (1) :110 141.

文档数据 篇4

一、磁盘数据组织结构

在INFORMIX-OnLine的磁盘数据组织结构中的最上层为逻辑概念上的数据库空间dbspace,每一个数据库空间都有一个或若干个物理单位数据存储块chunk组成，镜像数据存储块mirror保证当根数据存储块故障时，OnLine能够继续工作。每一个数据存储块都有若干个数据页page组成，为了提高输入和输出效率，若干个连续的数据页组成数据连续页extent。用户的数据库database和数据表table存储在缺省的或者指定的数据库空间中，数据表的逻辑概念上的存储空间数据表空间tblspace有一个或若个安数据连续页extent组成，数据记录row存放在数据页page中。

为更好的的支持多媒体应用，多媒体数据可以存放在二进制大对象数据页Blobpage中，若干个二进制大对象数据页在此二进制大对象空间Blobspace。 OnLine使用逻辑日志Logicallog、物理日志Physicallog来管理数据库日志操作。

1.数据存储块chunk

INFORMIX-OnLine的数据存放在物理上连续的数据存储块chunk中，数据存储块是OnLine数据存储的最大的物理单位。数据存储块可以有两种构造方法，其一是直接构造在系统的物理磁盘上，其二是构造在操作系统的文件或者卷上。

在第一种情况下，在操作系统上仅仅定义了这个(块)磁盘但没有格式化这个(块)磁盘，因此在这上面的所有数据操作都有OnLine来完成，操作系统对它不存在任何管理，数据空间在物理磁盘上连续，这种数据的存储空间称为原始空间rawspace。

而在第二种情况下，操作系统不仅定义了这个数据存储空间(文件)，还管理这个数据存储空间(文件)，数据文件操作时的内存缓冲、输入与输出。数据空间的建立受操作系统的制约，在物理存储上不连续。我们称这种数据存储空间为非原始空间cookedspace。

比较这两种数据的存储空间，原始空间在磁盘上连续，没有操作系统的缓存和制约，非原始空间在磁盘上不连续，存在着操作系统的缓存和操作系统的输入/输出的制约，因此在实际应用中，采用原始空间效率高于非原始空间，由于原始空间与系统设备有关，同时不同操作系统对设备的定义的不一致性，定义非原始空间比定义原始空间来得简单。我们将原始空间所对应的磁盘称原始设备rawdevice，而将非原始空间所对应的操作系统文件称操作系统文件cookedfile。

为了进一步提高数据库运行的效率，我们通常选用字符设备作为存放实际的原始设备，这样在我们输入/输出数据时，可以充分发挥系统的DMA能力。当我们使用原始设备时，可以在同一个原始设备上建立多个数据存储块。通过对数据存储块的参数OFFSET和SIZE的定义，其单位为KB，我们可以定义多个数据存储块在同一个磁盘或磁盘块上，参数OFFSET定义数据存储块的起始位置，参数SIZE定义数据存储块的大小，用户在设置参数OFFSET和SIZE时必须保证在物理磁盘上没有相互覆盖。

在原始设备/dev/rdsk/c0t1d1s0上建立三个数据存储块chunk1、chunk2和chunk3，它们的大小分别为50MB、30MB和50MB，由于chunk的SIZE单位为KB，因此chunk1、chunk2和chunk3的SIZE分别为50000、30000和50000。在通常情况下,第一个数据存储块chunk1的OFFSET为0，这样第二个数据存储块chunk2的OFFSET应为第一个数据存储块chunk1的SIZE，而第三个数据存储块chunk3的OFFSET则为第二个数据存储块chunk2的OFFSET加上第二个数据存储块chunk2的SIZE。为保证在两个数据存储块的相邻边界处不发生重叠，可以将后一个数据存储块的起始位置稍微挪后一点。如果采用操作系统文件作为数据存储空间时，一般不在一个文件中建立多个数据存储块。一个文件中建立多个数据存储块，操作系统对文件中数据的定位时间将更长。

不管是原始设备还是非原始设备，OnLine的概念是一致的。在实际应用中，可以一部分数据存储块用原始设备而另一部分用非原始设备，只是原始设备采用OnLine的管理的I/O机制，而非原始设备采用操作系统unix的I/O机制。

2.数据页page

INFORMIX-OnLine在数据存储块中以数据页page为单位来组织存放数据，并以数据页为单位来输入输出数据，它的大小与数据在共享内存中数据缓冲区相一致，所以OnLine的数据页的大小是不可以改变的。数据页是OnLine组织存放数据的最小的物理单位。

根据不同从操作系统，OnLine的数据页的大小是不同的。例如在SCO、AT&T、UNISYS和HP等操作系统平台上，每一个数据页的大小为2KB，而在IBM和SEQUENT等操作系统平台上，每一个数据页的大小则为4KB。同时数据在共享内存中的缓冲区的大小也是根据操作系统的不同而不同，其值与数据页的大小一致。

3.数据连续页extent

为提高数据操作的效率，OnLine将若干个在物理磁盘上连续的数据页组成一个数据连续页extent。当用户创建一个数据表时，OnLine以数据连续页为单位在数据存储块中分配一块连续的空间，当用户的数据写满了这个数据连续页后，OnLine将以数据连续页为单位在数据存储块中申请一块连续空间，以存放更多的用户数据。在缺省情况下，初始化时第一个数据连续页为8个数据页。

数据连续页不能跨越数据存储块，当OnLine需要申请较多的数据页构成数据连续页时，如果OnLine找不到如数的在物理设备上连续的数据页时，OnLine将放弃这些不够构成一个数据连续页的数据页，OnLine将去下一个数据存储块去申请如数的在物理设备上连续的数据页。因此在实际系统中，过小的数据存储块将不利于数据操作性能和数据存取效率。

4.数据库空间dbspace

在INFORMIX-OnLine的磁盘数据组织中，数据库空间dbspace处于一个比较上层的位置。数据库空间是数据库在逻辑概念上的存储空间，一个或若干个数据库空间组成OnLine数据实体。在物理磁盘上，每一个数据库空间总对应于一个或几个数据存储块，在这些与数据库空间对应的数据存储块中，一定有一个数据存储块是根数据存储块，而其它的则是后继数据存储块。从功能上来看，根数据存储块除了具有后继数据存储块能够存储用户数据外，它还具有管理本数据库空间的功能;从数据存储块的保留页来看，根数据存储块具有56个保留页，而后继数据存储块仅有3个保留页。当然不同版本的OnLine在主、后继数据存储块的保留页的数量可能不同，但是根数据存储块需要更多的保留页来保存本数据库空间的定义。

在OnLine初始化后有一个称为根数据库空间rootdbs的数据库空间，它是OnLine系统的第一个数据库空间。当建立根数据库空间时，它的根数据存储块将被建立，所有数据库的日志和所有的定义信息都必须存放在该数据存储块中，它比所有其它根数据存储块的保留页更多。由于数据库日志定义的需要，因此对根数据库空间的根数据存储块的定义尤其重要，关于如何正确地定义根数据库空间的根数据存储块将在后面详细介绍，

为了提高数据库系统运行的效率，INFORMIX新的动态服务器OnLineDynamicServer7.1中引入了临时数据库空间的概念。在没有临时数据库空间的系统中，临时数据将建立的缺省的根数据库空间中，由于临时数据操作需要频繁的增加、删除，会给根数据库空间的数据存储块中造成很多碎片，将导致数据库操作效率的降低;另外当数据库备份时，那些临时数据也一起作备份，从而增加了数据备份量，降低了数据备份的效率。引入临时数据库空间后，用户的临时数据或者数据操作的中间结果将被存放在临时数据库空间中，同时当数据备份时临时数据库空间将不再被备份。

5.数据存储块镜像mirror

为提高OnLine运行时的数据高可靠性，OnLine在数据存储上引入了数据存储块镜像的机制。OnLine数据存储的镜像是对数据存储块而言的，但是其定义是对数据库空间的。当一个数据库空间被定义为镜像时，它下面的所有数据存储块全部镜像;当一个数据库空间被定义成没有镜像的时候，它下面的所有数据存储块全部没有镜像。

当OnLine在运行时，一旦数据存储块所在的物理磁盘发生读写故障，对于没有数据库空间没有镜像的系统，OnLine将自动关闭，并等待恢复。而对于具有镜像的数据库空间，OnLine将把存在读写故障的数据存储块标识为Down，同时OnLine将继续运行，用户完全可以根据需要，在适当的时候，恢复存在读写故障的数据存储块所在的磁盘，然后重构继续。因此一个具有镜像的数据库空间，其运行时的可靠性将大大高于不具有镜像的数据库空间。

6.数据表空间tblspace

在逻辑上，数据库存放在数据库空间dbspace中，数据表存放在数据表空间tblspace中。数据库空间是由数据存储块组成，数据表存在于这些数据存储块中，数据表空间是由连续存放该数据表记录的数据连续页组成。

二、共享内存数据组织结构

OnLine能高效地执行联机事务处理的第二个机制是数据库服务器系统的共享内存。在一些不使用共享内存的数据管理系统中，管理进程只能在需要数据的时候，将该记录和索引的最新值读入该进程所占有的私用数据缓存中进行操作，由于频繁的磁盘I/O，使系统的运行效率降低，同时由于那些管理进程都各占一份数据缓存，使得系统内存的有效使用率降低。因此使用共享内存会有以下三方面的好处：

(1)数据缓存不再属于某个进程，所有的数据库进程均共享这块内存，降低了磁盘的I/O;

(2)所有数据库进程访问相同的访问，它们的值和索引在内存中只有一份拷贝，提高了内存的有效使用率;

(3)操作的相关记录被预读进共享内存中，由于内存的I/O效率极高，因而系统并发除了数据的能力得到提高。

随着OnLine功能和性能的不断提高，OnLine的共享内存也有所不同。尤其是INFORMIX的动态服务器OnLineDynamicServer(ODS)在其共享内存的结构上增加了两个功能模块。在OnLine5中，其共享内存仅有一个区域，驻留区Residentportion;动态服务器ODS7.1除了驻留区Residentportion外还增加了虚拟区Virtualportion和通讯区Communicationportion。

1、操作系统参数对数据库服务器共享内存的影响

操作系统的共享内存参数对数据库服务器的共享内存的定义和建立会产生极大的影响。对INFORMIX来说，数据库服务器的共享内存绝对不能超过操作系统共享内存定义的允许范围。一个OnLine动态服务器7.1的共享内存不能超过操作系统所定义的一个UNIX进程所允许访问共享内存的极大值，由于操作系统对共享内存的定义往往不能满足OnLine动态服务器7.1的需要，因此，数据库管理员通常需要在建立其数据库应用系统以前，首先调谐操作系统的共享内存参数。

对于OnLine动态服务器7.1来说，操作系统的参数对它们的影响，在共享内存锁资源管理方面和虚拟处理器对共享内存访问操作方面是不全部相同的。它们对操作系统参数的要求也是不一样的，因此需要数据库管理员根据产品来决定操作系统的参数，在决定这些操作系统的参数前，请先阅读产品说明文件。例如OnLine动态服务器7.1的$INFORMIXDIR/release/ONLINE_7.1，在这个文件中它向数据库管理员阐述该INFORMIX产品在该机器平台上对操作系统参数的要求。同一种产品在不同的平台上，对该平台操作系统参数的要求非常有可能是不一样的;在同一平台上，同一产品的不同版本对操作系统参数也很有可能是不同的。

2、处理器资源组织结构

OnLine动态服务器7.1采用多进程Multi-processes多线索Multi-treads的数据库服务器机制，将每一个服务器进程根据用户定义分解成若干个线索，每一个线索响应一个用户的设计访问的请求。INFORMIX将每一个进程称作一个虚拟处理器Virtualprocess。

在以前的多处理器系统中，往往将用户的应用程序和系统的处理器CPU对应起来，每一个处理器都分别处理一个用户的应用程序;当应用程序数量多于处理器数目时，应用程序为争夺处理器资源CPU，而引起应用程序在运行时间上的不平衡;同时当应用程序的数量少于处理器数目时，由于一些处理器资源得不到运用而空闲，导致处理器资源运用上的不平衡。一种比较好的方法是将处理器与应用所需要的处理器分离开来，然后由数据库系统来平衡这种需求。在INFORMIX动态服务器中，用户应用程序发出的数据操作请求被称作虚拟处理器的服务器进程所接收，然后OnLine均匀地将这些服务器进程分配到系统实际的处理器CPU上。这样就较好地解决了上面所提到的两种不平衡状态。

在ODS7.1中每一个数据库服务器进程都称作一个虚拟处理器Virtualprocess，简称VP。若干个相同功能的虚拟处理器组成一个虚拟处理器类VirtualprocessClass，简称VPClass，每一个VPClass都表示一种功能的虚拟处理器。OnLine一共有七种虚拟处理器，它们是：

处理器虚拟处理器CPUVP，响应所有用户和OnLine系统对CPU资源的操作和协调。

磁盘输入输出虚拟处理器DiskI/OVP，响应用户和OnLine系统的磁盘输入输出请求，磁盘输入输出处理器分三种，异步输入输出AsynchronousI/O、物理日志输入输出Physical-logI/O和逻辑日志输入输出Logical-logI/O。

网络通讯虚拟处理器NetworkVP，响应用户的网络联接的请求。ODS的网络虚拟处理器有三种，它们分别用于管理tli、soc和ipc三种网络通讯接口。

系统管理虚拟处理器AdminstrationVP，运行OnLine系统管理程序和一些专职程序。

光盘虚拟处理器OpticalVP，当用户运行OnLine/Optical时管理光盘系统的运转。

审计虚拟处理器AuditVP，当用户系统需要一定的运行时数据安全性的时候，审计虚拟处理器在后台帮助检查每一个用户操作的合法性。

杂项管理虚拟处理器MiscellaneousVP，用于管理所有以上虚拟处理器不作的工作。

共5页: 1 [2] [3] [4] [5] 下一页

文档数据 篇5

关系型数据库是一种“纵向扩展”的技术，想要扩展容量（无论数据存储还是I/O），都需要更换更大的服务器。现代应用结构的解决却是使用“横向扩展”----无需新购买更大的服务器，只需要在负载均衡器下增加一般的服务器、虚拟机或是云服务器就可以实现扩展。此外，容量在不再需要的时候还可以轻易的缩减。事实上，“横向扩展”在应用逻辑层的使用已经很广泛了，只是数据库技术上刚刚赶上而已。

NoSQL“横向扩展”部署方案的优点已经受到了业界的注意，但是同时很多人忽略的是NoSQL数据管理的简洁，不需要很复杂的操作模式构建，这一点对于数据库的提升也和扩展模型一样重要。在使用传统关系数据库时，添加数据前，需要定义操作模式。之后每一条记录的加入都需要严格的按照定义的操作模式进行，比如固定的列数和数据类型。因此，改变那些分区关系型数据库的操作模式，会非常的麻烦。如果数据获取和数据管理需求经常变化，那这种严格的模式限制将会成为制约表现的屏障。NoSQL无论文档型、列式、K-V都是水平扩展的，它们都不需要预先定义操作模式、所以也不需要在需求改变时改变操作模式。使用SequoiaDB来介绍文档型NoSQL数据库技术。

SequoiaDB的数据模型就是以JSON格式存储的文档型模型，所以SequoiaDB具备了文档型和NoSQL数据库的数据灵活性和高可扩展性。SequoiaDB的文档型数据模型不仅简化了数据存取的过程，也大大的提升了数据的灵活性。在应用中不仅免去了设计模式这个麻烦的环节，还能很好的适应大数据时代高并发、实时性和分布式的要求。

文档数据 篇6

关键词：关系数据库,文档数据库,异构数据,Web service,DotNet

0、引言

目前, 关系型数据库具有数据结构化、最低冗余度、较高的程序与数据独立性、易于扩充、易于编制应用程序等优点, 是计算机数据管理的基础, 也是信息系统的根本。著名的关系数据库管理系统有Oracle、Sql server、DB2等。SQL Server是目前最流行的关系型数据库系统之一, 它适合作为网络数据库等大型应用, 提供了强大的并行处理机制, 具有强大的网络数据库支持功能, 因此在被广泛使用。

随着网络技术和软件技术的快速发展, 非结构化数据的应用日趋扩大。关系数据库的局限性也越来越明显, 文档数据库应运而生, 区别于传统的其它数据库, 它是用来管理文档。在传统的数据库中, 信息被分割成离散的数据段, 而在文档数据库中, 文档是处理信息的基本单位。文档可以很长、很复杂、可以无结构, 与字处理文档类似。典型的代表是Lotus Notes/Domino, 它被广泛地应用于办公自动化的建设。随着计算机网络的广泛应用, 异构系统间的数据交互日益频繁, 其中异构数据库间的数据的共享和透明访问显得尤为重要, 本文提出了相应的解决方案。

2、数据库操作

2.1 Domino数据库的访问技术与实现方法

Lotus Domino/Notes作为群件系统是一个为群体/工作组提供通过计算机网络达到数据共享与协同工作的分布式C/S系统平台。它包含一整套基于通信机制的文档数据库, 同时具备分布式存储和通信的特点。

Notes的中心是它独特的对象仓库, NSF (Notes Storage Facility, Notes存储工具) 文件。Notes数据库也被称为"对象仓库", 它们存储数据的方式与大多数数据库体系结构存储数据的方式不一样。Notes数据库记录不储存在表单中, 每条记录 (称为"note"或"document") 可以只包含那些真正有数据的字段[1]。

2.1.1 Domino类库中接口技术

程序中要用到的接口类型有:NotesSession Domino数据库全局性对象, 其中包括全局性的特征、关系以及信息。NotesDatabase代表一个Domino数据库;NotesView作为Domino数据库的视图, 通过它可访问数据库中的文档;NotesDocument表示Domino数据库中的文档;NotesViewEntry表示Domino数据库视图中的一行;NotesViewNavigator通过它能够访问视图中的所有行或及其子行, 与SQL语言中的游标的作用类似[1]。

2.1.2 实现方法

Dotnet中ADO.net组件只能进行对关系数据库的操作, 并不提供对Domino数据库的支持。如果在Dotnet中读取、操作Domino数据库中的数据, 必须通过对Domino的引用 (domobj.tlb) 而实现。在Domino数据库 (nsf) 中, 用视图 (View) 来进行数据库管理, 所以要得到其中我们关心的数据, 先要得到各种所需要的视图。再从视图的ColumnValues中得到所需数据。具体方法如下所示: (假设已建有数据库mylotus.nsf (数据库模板为Lotus SmartSuite Library) 。

主要代码如下:

2.2 Sql server数据库的访问方法

利用Dotnet中的ADO.Net组件功能强大, 可以方便快捷地访问SQL Server 2000等关系数据库中的数据, 主要步骤为1) 建立并打开数据连接;2) 使用ADO Net对象 (SqlCommand、SqlDataAdapter等) 操作数据表、视图、存储过程等;3) 绑定显示控件;4) 更新数据;5) 关闭连接。

3、异构数据库的数据集成

异构数据库的各个组成部分具有自身的自治性, 实现数据共享的同时, 每个数据库系统仍保有自己的应用特性、完整性控制和安全性控制。异构数据库的数据集成是将相关的多个数据库系统的集合起来, 实现数据的共享和透明访问[3]。Webservice是DCOM/COR-BA等分布式计算体系的发展, 其使用基于XML的SOAP协议作为平台无关的通讯机制, 通过UDDI进行定位。它具有通用性更强、结果信息处理能力更强、强大的二次开发能力、完善的信息源标识功能等特点, 成为异构数据库数据集成的常用技术[4]。Dotnet中提供了强大的Webservice支持, 所以本文中选用Webservice处理Domino数据库和Sqlserver数据中的数据集成问题, 流程示意图如下图1:

上述方法通过VS2005编程实现, 编程语言是C#, 在测试计算机中安装Windows Server2003操作系统并安装IIS 6.0Web服务器, Lotus Domino Server 6、和SQL Server2000在C#下编译通过。通过Web service方法实现了不现数据库中数据的共享和透明访问。

4、结束语

异构数据集成和访问是当今的热点技术, 特点是在关系型数据库和非关系型数据库系统中应用, 本文针对目录主流的关系型数据库和使用日益增多的文档型数据库中数据的集成问题, 本文提出了相应的解决方案, 用.net编程语言实现了有效的进行如Domino数据库这种非关系数据库系统的数据读取和转化, 具有一定的实用性。

参考文献

[1]陈山.Lotus Domino Designer 6企业级应用程序高级开发[M].中国水利水电出版社, 2004.

[2]王程辉.基于LotusDomino_Notes的OA系统设计与应用研究[J].中国科技信息, 2010.1:121-124.

[3]王彦新, 杨奎河.基于XML的异构数据库集成方法研究与实现[J].福建电脑, 2006.4:90-91.

文档数据 篇7

关键词：RDF,存储,NoSQL,MongoDB,语义,Web

1 引言

随着计算机网络的快速发展, 语义Web也得到大量的使用和发展, 产生了大量的RDF数据。对于快速有效的存储和查询如此海量的RDF数据, 提出了更高的要求。非关系 (No SQL) 数据库技术是最近几年研究和学习热点, 它们多数不支持事务的处理, 更加关注数据的读取和查询的效率问题。同时它们的出现是迎合那些对数据的一致性不高但是对读取和查询性能要求高的应用。基于此, 本文设计并实现了一种大规模RDF数据的存储方案, 并在基于面向对象文档No SQL数据库Mongo DB上实现包括存储和查询的一系列实验。实验结果表明, 该方案对于大规模RDF数据的存储和查询具有性能的优势。尤其在性能上优于传统的关系数据库。

2 相关工作

RDF数据是以形如 (S, P, O) 的三元组形式来描述和组织数据的, 其中S表示主语, P表示谓语, 宾语用O表示。主语表示Web的某一资源, 谓语表示主语的某一属性或与其他资源的关系, 宾语表示谓语的属性值或与之有关系的另一资源。 (S, P, O) 三元组中有以下三种形式的数据:统一资源标识符 (URI) 、字面值 (Literal) 、空节点 (Blank Node) 。

Mongo DB是面向文档的数据库, 是一种非关系型数据库 (No SQL) , 是一种强大、灵活、可扩展的数据存储方式。

论文中将RDF三元组存储在六张HBase表中, 他们分别是S_PO、P_SO、O_SP、PS_O、SO_P和PO_S表。它通过冗余数据来实现数据的快速查询效率。论文[8]实现的是基于Big Table存储模型的分布式结构化数据存储系统。

3 RDF存储方案设计

3.1 存储模式设计

为了保持RDF原有数据的语义, 在本文的设计模式中将RDF数据和RDFS信息分开存储, 建立相应的存储集合。本文采用S、P、O分开存储的方案, 其它的集合使用_id来进行映射。从而避免了数据的大量重复冗余。

3.1.1 建立RDF数据存储模式

因为空节点是没有名称既URI的资源, 既空节点也是一种特殊的资源。所以我们设计资源, 字面值和三元组声明三张表 (见RDF_RESOURCE、RDF_LITERA、RDF_TRIPLE集合) 。在XML描述语言中有命名空间的概念, 为了节省存储空间, 建立命名空间集合 (见RDF_NAMESPACE集合) 。在RDF_TRIPLE集合中的is Resource标记object是资源还是字面值。

3.1.2 建立RDFS存储模式

RDFS建立了RDF的一些基本的模型限制, 说明了类的属性、类与类之间的关系、值域和定义域在属性上的约束。RDFS主要通过以下资源来描述类及其之间的关系:rdfs:Class, rdf:Property, rdfs:Domain, r d f s:R a n g e, r d f s:S u b P r o p e r t y O f, rdfs:Sub Class Of。所以分别建立了RDFS集合。其中, Class、Property集合声明了属于类和属性的资源。Domain、Range集合描述了属性与类之间或属性与数据类型之间的定义域和值域。Sub Property Of、Sub Class Of集合表示属性的子属性和类的子类的语义。

按照上面所述, 我们设计的Mongo DB存储模式的集合和字段内容如下:RDF_RESOURCE{_id、namespace Id、local Name}, RDF_NAMESPACE{_id、prefi x、space Name}, RDF_TRIPLE{_id、subject Id、predicate Id、objectId、is Resource}, RDF_LITERA{_id、literal}, RDFS_CLASS{resource Id}, RDFS_PROPERTY{resource Id}, RDFS_DOMAIN{property Id、class Id}, RDFS_R A N G E{propertyId、classId}, R D F S_SUBPROPERTYOF{sub Id、super Id}, RDFS_SUBCLASSOF{sub Id、super Id}。

3.2 面向文档的Mongo DB的实现

3.2.1 Mongo DB集合存储

Mongo DB存储上面每组数据时通过文档的形式来存储的。如果说Mongo DB中的文档类似于关系数据库中的行, 那么集合就相当于表。Mongo DB的集合是无模式的, 但是因为RDF/RDFS的数据格式都是规范的, 而且这种无模式的特性可行带来效率上下降。所以本文中不涉及到Mongo DB集合的无模式操作。所有的数据格式都按照上面所设计的集合来创建和存储。

3.2.2 实现

根据上面所设计的模式来创建Mongo DB集合。

第一步:我们创建一个名叫rdf的数据库:

use rdf;

第二步:创建RDF和RDFS集合:

d b.c r e a t e C o l l e c t i o n (“R D F_NAMESPACE”) ;db.create Collection (“RDF_RESOURCE”) ;

…

并使用Sesame通过分解规则将RDF三元组的信息分别存入相应的集合中。对于RDFS数据, 可以参考文献中的分解规则来对RDFS信息分解存入相应的集合中。为了提高查询的效率, 我们将对一些主要的集合建立索引。

索引字段的顺序是很重要的, 不能随便的排序或打乱, 否则会影响查找的效率。

在集合RDF_TRIPLE中的SP, SO, PO索引实际上实现了论文中通过冗余数据来实现查询性能的提升。

4 实验结果及性能分析

实验所用环境:惠普笔记本电脑, CPU为Intel Core 2 Duo T6570, 2.1GHz, 内存2G, windows7 32位操作系统, Mongo DB版本为2.4.3。

4.1 数据集

本次实验使用dblp数据集。它提供了主要的计算机科学期刊和会议的文献书目信息, 但只存储文献的相关元数据, 如标题, 作者, 发表时间等。截止2013年已包括超过230万计算机文献。

4.2 查询性能

查询性能作为评价系统整体性能优劣的一个重要因素。本实验查询设计采用文献的方案, 分别对Q1, Q2, Q3, Q4查询进行实验。其中Q1针对单一属性的查询;Q2做一次subject-subject连接;Q3做两次subjectsubject连接;Q4需要做subject-subject和subject-object连接。我们将在上面数据集对Sesame进行性能的对比。本文实验采用Mysq的Sesame数据库方式。

表2是两种方案的查询时间对比。使用面向文档数据库Mongo DB的存储方案比Sesam关系数据库的查询速度上有优势。

5 结束语

文中给出了面向文档的No SQL数据库在RDF存储的基本方案。在与Sesame的关系型数据库存储方式的对比中在性能上更优, 尤其是在对Q2, Q4的查询场合。

面向文档的No SQL数据库Mongo DB是支持分布式的非关系型数据库, 既支持集群。下一步的工作将对Mongo DB在本方案的基础上实现多个节点的集群下性能实验。并与其它No SQL数据库在集群的情况下的性能比较。最后能将自己的方案整合扩展到Sesame的存储后端, 为开源多出自己的一点贡献。

参考文献

[1]易雅鑫, 宋自林, 尹康银.RDF数据存储模式研究及实现[J].情报科学, 2007.

[2]王星, 宋金玉, 陈爽, 陈萍.基于列数据库的RDF数据管理实现[J].计算机技术与发展.2012.

[3]鲍文, 李冠宇.本体存储技术研究[J].计算机技术与发展, 2008.

[4]MongoDB权威指南[M].程显峰译.北京:人民邮电出版社, 2011.

文档数据 篇8

XML语言具有跨平台、自描述、可扩展、简单易于处理等优点,多用于异构系统集成之间数据交换。近些年来国内外研究者对XML文档与关系数据库之间的转换方法做了大量研究,发表了很多成果。但常用的数据交换方法有两种,一是没有使用XML模式的结构映射方法[1]和使用XML模式的模型映射方法[2]。XML模式中的DTD方法主要依据DTD来生成对应的关系模式[3]。从DTD到关系数据库模式的映射中的CPI方法还可以完整规定XML文档的语义信息[4]。但这类的结构映射方法对XML文档的格式要求十分严格,造成数据空间的大量耗费,并且降低了数据库存储与查询的效率。XParent方法中的dataPath表在查找和进行数据连接时会消耗巨大的存储物理空间[5]。文献[6]中用来存储XML文档结构的是编码字符串的大文本字段,这种方法降低了维持XML文档结构的代价,但却提高了查询XML文档的难度。不过总体来说模型映射方法与结构映射方法相比,具有保持数据完整性,不丢失数据,支持静态和动态的XML数据存储等优点。因此,本文结合前人的研究针对模型映射这一方法提出了一种以节点生成树作为XML文档与关系数据转换的中间桥梁的双向映射方法。

1 相关概念

XML Schema是以XML语言为基础的,它用于可替代DTD,用于定义和描述XML文档,XML Schema的作用就是定义一份合法的XML文档的组件群,就像DTD的作用一样,一份XML Schema定义出现在文档里的元素、属性,定义哪些元素是子元素,定义子元素的顺序、数量 ,定义一个元素是否可以包含文本,或是否可以为空,定义元素和属性的数据类型、默认值和固定值。其中数据类型可以分成简单数据类型和复杂数据类型两类:只包含字符数据内容不包含子元素和属性的是简单数据类型。可以包含字符数据内容,且要包含子元素或属性中的一种,并用minOccurs和maxOccurs表示子元素出现的次数的为复杂数据类型[7]。

2 XML文档和关系数据库的相互映射方法

2.1 中间节点树的定义

在将关系数据库与XML文档进行数据转换时,可以依据关系数据库结构或xml Schema模式事先定义出一个中间节点树。定义节点树的表达式如下:TNode=。表达式中节点的集合是V, 边的集合是E⊆V×V,根的节点是r∈V。

(1)V代表节点树中的节点的集合,在此节点树中只包含父节点和子节点,不细分每个节点的属性。

(2)r代表此节点树的根节点。

(3)E代表节点树中边的集合, 它表示父节点和子节点之间的关系。用符号来表示若v1∈V,v2∈V,v1→v2表示由v1到v2的边,表示v1节点是v2节点的父节点[8]。

(4)*代表一种操作符,表示一个节点和其子节点出现的次数,若此节点v1代表叶子节点,则v*1表示v1节点出现了任意次;若v1并非叶子节点,即存在v1∈V,v2∈V,…,vm∈V使得v1→v2,v1→v3,…,v1→vm则v*1就是(v2,v3,…,vm)*,并且v2,v3,…,vm是以一种固定不变的顺序出现的。

(5)+代表一种操作符,表示一个节点和其子节点出现的次数大于一次,若此节点v1代表叶子节点,则v+1表示v1节点至少出现了一次;若v1并非叶子节点,即存在v1∈V,v2∈V,…,vm∈V使得v1→v2,v1→v3,…,v1→vm则v+1就是(v2,v3,…,vm)+,并且v2,v3,…,vm是以一种固定不变的顺序出现的。

2.2 关系数据库到XML文档的映射

2.2.1 将关系数据库结构转换为节点树的规范

(1)关系数据表的处理规则

若此关系数据表在数据库中没有引用其他的关系数据表,既原表中没有外键FK,则可以将此关系数据表名称Table直接转化为树中的节点名称,关系数据表中的字段名Column作为其子节点。若存在外键则将此表定义为其引用关系数据表的子节点Table1_to_Table2_FK。依据数据表的性质,此处应该执行+操作。

(2)数据表中字段的处理规则

数据表中的字段名Column直接转化为节点树中关系表Table节点下的子节点,每个字段的属性转化为此Column节点下的子节点,若此字段是此表的主键则定义此节点名称为Column_PK,若此字段是此表的外键则定义此节点名称为Column_FK,每个字段下的内容也直接转化为此节点的子节点,依据数据表中字段的性质,此处应该执行+操作。

(3)字段中属性的处理规则

字段中的属性直接转化为此字段Column节点下的叶子节点,一般有类型Column_base、大小Column_size、默认值Column_type等节点。此处执行*操作。

2.2.2 节点树到XML Schema的映射规则

(1)根节点在XML Schema中映射为XML文档中与其同名的根元素。

(2)Table节点映射为一个与其同名的复杂类型元素。

(3)Column节点映射为XML Schema中一简单类型元素,嵌套于对应Table节点的复杂类型元素之下,元素的取值类型由“type”属性指定。

(4)利用XML Schema中的key元素来表达节点树中Column_PK的节点信息。例如节点树Class中节点“ClasslD”映射为XML Schema则为:

XML是一个树形结构,其中“selector”元素指名了主键所在的路径,“.”表示取当前路径,“field”指名了所选路径下的某个节点[9]。

(5)利用XML Schema中的keyref元素来表达节点树中Column_FK的节点信息。利用XML Schema中的minOccurs以及maxOccurs属性描述外键的取值是否唯一。例如节点树Students中的节点Students_to_Class_FK映射为XML Schema如下:

⑥利用XML Schema中的“base”、“restriction”、 “nullable”元素来分别表达节点树中Column节点下“Column_base”、“Column_size”、“Column_type”节点信息。例如节点树Students中的节点studentsID映射为XML Schema如下:

2.3 XML文档到关系数据库映射方法

2.3.1 将XML Schema转换为中间节点树的规范[8]

(1)元素的处理规则

文档中的元素声明,可以直接转化为树中的节点,元素的属性转化为节点的相应属性。声明中的name属性变成节点的名字,default转变为节点的默认值,maxOccurs,minOccurs属性是元素出现的次数,若maxOccurs的值为unbounded, minOccurs的值为0,则执行“*”操作, 若minOccurs的值为1,则执行“+”,此处默认为“*”操作,ref表示引用其它类型的元素, 将被引用的元素作为树中节点。若type属性表示的是简单类型则将该简单类型直接作为该节点的属性,若type为复杂类型,则将复杂类型展开,使其中声明的元素作为其子节点。

(2)属性元素的处理规则

由… 声明的属性,直接作为树中的子节点以属性名name的值作为节点的名字,属性use的值表示该节点是否必须,若是在关系数据库中则表示该属性列不能为空。

(3)简单类型的处理规则

对于…声明的简单类型只是作为节点的属性。

(4)复杂类型的处理规则

对于…则是将其中定义的元素(element)和属性(attribute)转化为引用该复杂类型元素的子节点。

2.3.2 节点树到关系数据库的映射规则

(1)根节点在关系数据库中映射为数据库的名字。

(2)根节点以外的节点如果v*1≥1,则将此节点映射为数据库中的表,并且不存在没有属性列的表。

(3)根节点以外的节点如果v+1≥0,则将此节点映射为数据表中的字段,如果v1是叶子节点或v+1=0表示此字段无属性定义。

(4)节点树中名字为“Column_PK”、“Column_FK”的节点映射为数据库中表的主键与外键,以及相应的表间关系。

(5)节点树中名字为 “Column_base” “Column_size”、“Column_type”的节点映射为数据表中的字段属性约束。

3 XML文档和关系数据映射模型设计及实现

3.1 关系数据库到XML文档映射模型及实现

3.1.1 关系数据库到XML文档的映射模型

关系数据库到XML文档的实现如图1所示。

3.1.2 关系数据库到XML文档的转换方法

(1)配置开发环境,选择想要进行数据转换操作的异构数据库,使用JDBC等技术配置数据库连接。

(2)运用JDBC技术以及相应开发语言配合相关的SQL语句获取需要转换数据的数据库中的相关信息(数据表名、字段名、表间的关系,字段的类型等)生成JavaBean对象。

(3)利用反射机制与DOM4j技术对JavaBean对象进行具体处理,按照节点树的定义规则生成一棵Nod节点树。

(4)根据映射规则与算法简化与修剪Nod节点树生成标准的XML Schema。

(5)重复(2)-(3)步操作从数据库表中获取具体数据生成符合XML Schema文档规则的XML文件。

3.2 XML文档到关系数据库的映射模型及实现

3.2.1 XML文档到关系数据库的映射模型

XML文档到关系数据库的实现如图2所示。

3.2.2 XML文档到关系数据库的转换方法

(1)利用反射机制与DOM4j技术读取XML Schema文档得到相应的JavaBean对象。

(2)依照定义的节点树规则对JavaBean对象进行处理,使之转化为一棵Nod节点树。

(3)根据节点处理规则判断树中的节点并依照映射规则动态生成一个Table表类,完成XML Schema到数据库结构的转换。

(4)使用DOM4j解析与读取XML数据,并参照步骤(3)生成的Table表类生成实例化的table对象。

(5)使用相应的SQL语句将table对象写入到目标数据库中,完成XML文档到关系数据库的转换。

4 结束语

随着信息技术的不断发展,企业应用的异构系统数据库之间的数据如何共享与交流这一问题不断凸显,XML技术可以很好地解决不同系统之间的数据共享问题。本文研究了XML文档和关系数据库之间的双向映射模型和算法,给出了一种实用的可以不丢失数据信息的XML文档和关系型数据库之间数据交换的方法。

摘要：在数据集成中为了有效保证数据信息的完整性,基于XML Schema在数据集成中的优势,提出一种以节点生成树作为中间桥梁的XML Schema和关系数据库模式相互映射的算法,建立了XML文档和关系型数据库之间双向转换的映射模型,并给出了这一模型的具体实现方法。

关键词：数据集成,映射模型,节点树,XML文档,关系型数据库

参考文献

[1]BOHANNON P,FREIRE J,ROY P,et al.From XML schema to rela-tions:a cost-based approach to XML storage[C]//Proc of the 18thInternational Conference on Data Engineering Washington DC:IEEEComputer Society,2002:64-75.

[2]SONTAN S,RAHGOZAR M.A clustering-based schema for labelingXML trees[J].International Journal of Computer Science and Net-work Security,2006,6(9A):84-89.

[3]SHANMUGASUNDARAM J,TUFTE K,ZHANG Chun,et al.Rela-tional database for querying XML documents:limitations and oppor-tunities[C]//Proc of the 25th International Conference on VeryLarge Data Bases,1999:302-314.

[4]LEE D,CHU W W.CPI:constraint-preserving inlining algorithm formapping XML to relational schema[J].Data and Knowledge Engi-neering,2001,39(1):3-25.

[5]JIANG Hai-feng,LU Hong-jun,WAGN Wei,et al.Path materializa-tion revisited:an efficient storage model for XML data[C]//Proc ofthe 13th Australasian Database Conference on Database Technologise.Melbourne:Australian Computer Society,2002:85-94.

[6]耿飚,宋余庆,梁成全,等.XML文档到关系数据库映射方法的研究[J].计算机应用研究,2010,27(3):951-954.

[7]WALMSLEY P.XML模式权威教程[M].陈维安,乔安平,英宇,译.北京:清华大学出版社,2003.

[8]黄根平,郭绍忠,陈海勇,等.数据集成中XML模式和关系模式映射模型研究[J].信息工程大学学报,2009,10(4):527-531.

从关系数据库到XML文档的转换 篇9

关键词：数据库,XML文档,JDBC,SQL

(一) 引言

XML (e Xtensible Markup Language, 可扩展标记语言) 因其具有支持信息系统交互和数据整合、生命周期长等方面的独特优势, 得到了信息技术界的普遍重视。另一方面, 传统的关系数据库依然是存储数据的主要手段, 是Internet信息的主要来源, XML为这些存储在不同关系数据库中的信息之间的交换提供了一条捷径。而与其他数据库编程环境相比, Java和JDBC有一个显著优点:使用Java和JDBC开发的程序可以跨平台运行, 且不受数据库供应商的限制, 具有很好的通用性。因此文中介绍如何利用JDBC从数据库中抽取数据, 并用Java实现数据到XML文档的转换。

(二) 从关系数据库到XML文档转换的系统结构

实现从关系数据库到XML文档转换的核心思想是, 利用JDBC从关系数据库中抽取数据, 通过java程序将抽取的数据转换为XML文档, 整个系统中数据的流程图如下所示:

(三) 通过JDBC访问数据库

JDBC是一种可用于执行SQL语句的Java API, 它由一些Java语言编写的类、界面组成。JDBC给数据库应用开发人员、数据库前台工具开发人员提供了一种标准的应用程序设计接口, 使开发人员可以用纯Java语言编写完整的数据库应用程序。通过使用JDBC, 开发人员可以很方便地将SQL语句传送给几乎任何一种数据库, 因此用JDBC来解析数据库, 具体的解析步骤如下:

(四) 生成XML文档

Java是一种广泛使用的网络编程语言, 它简单、面向对象、不依赖于机器的结构, 具有可移植性、安全性, 并且提供了并发的机制、具有很高的性能。其次, Java还提供了丰富的类库, 使程序设计者可以很方便地建立自己的系统, 因此使用Java来解析生成XML文档是一种很好的方式。

1. 从关系数据库结构到XML文档的映射

本文采用的方法是将命令语句嵌入模板的方法, 例如, 在元素中内嵌了SQL语句:

这种映射方法相当灵活, 在最后的结果中替换想要的内容, 包括在SELECT中使用的参数, 另外它还支持使用编程结构, 例如循环和条件判断结构。根据用户的需要生成相应的SQL查询语句, 把这些查询语句嵌入到模板的程序模块中, 最后生成文档。

2. 从关系数据库到XML文档转换基于模板映射的实现方法

(1) 生成DOM数代码实现

(2) 输出XML文档实现方法

(五) 结束语

XML是一个数据表示的开放标准, 其特点使得其在信息管理、数据交换, 应用集成等方面有着重要的用途, 基于XML的信息也将普遍存在, 它和现在很多信息数据库之间存在着大量的数据转换, 因此文中讨论了从关系数据库到XML文档的转换。基于JDBC和Java具有很好的跨平台性, 因此使用这两种工具语言来实现整个转换过程, 以做到整个转换系统具有很好的通用性。

参考文献

[1]Cay S.Horstmann, Gary Cornell.JAVA2核心技术[M].北京:机械工业出版社, 2006.

[2]Brett D.McLaughlin, Justin Edelson.Java与XML[M].南京:东南大学出版社, 2007.