关系型数据库范文第1篇

【关键词】关系型数据库 异构数据 数据同步

1 引言

数据同步就是借助数据复制技术将一组数据从一个数据源拷贝到不同物理地点的另一个数据源。中国石油集团搭建数据同步系统主要用于解决以下两个问题：

（1）实现中国石油集团各机构业务系统之间数据的交换与共享，这些系统由于开发时间与环境不一致，因此，所采用的数据库工具与所设计的数据库表一般差异较大。

（2）中国石油集团各机构业务系统在更新换代过程中，为了让用户拥有一段时间的适应期，出现的新旧系统同时运行的过渡阶段，这种情况下，新旧系统的数据库可能出现重构，并且旧系统中发生的数据变化需要实用同步更新到新系统中。

2 数据同步问题分析

在搭建中国石油集团的数据同步系统过程中，相关的调查现状如下：

（1）从整体上看，作为待同步数据的多个业务系统由于分别由各个机构在不同时期独立开发，缺少关联，因此，所采用的数据库系统和数据表结构差异很大。

从数据库系统上分析，位于地方县市的部门开发的系统多采用MYSQL数据库或者SQLSERVER数据库，极少数采用了ACCESS数据库；位于省级部门开发的系统多采用ORACLE数据库或者DB2数据库。

从数据表结构分析，基本上待同步的两个数据表之间不存在一致性，并且出现很多数据字段同名不同义或者同义不同名的现象。

（2）从业务逻辑上看，数据同步过程中，数据传播方向分为两类：一类是数据在同级系统间进行复制，这类业务虽然要求数据复制周期较短，但是允许存在时间延迟。一类是数据由下级系统向上级系统进行复制，这类业务主要用于分析，可接受的数据复制周期较长。

所以，系统并不像金融系统那样需要实时保证数据的紧密一致性。为了提高系统的可用性，在实际应用中，各节点之间的数据采用异步复制。

可见，数据同步的难点主要在于对数据异构性的处理和对数据复制时效性的控制。

3 数据同步方案设计

完成一次数据同步任务的过程由数据捕获，数据转换和数据传输三个标准步骤来执行。

图1展现了数据同步的标准数据复制流程。

经过调研，在现有技术中，本文发现利用这三个标准步骤来执行同步的方案仅限于数据库表字段之间彼此一对一的复制，不能支持涉及跨库跨表的多字段映射关系的复制需求，其问题就在于数据转换模块只能处理两表之间互相关联的两个数据字段之间的一对一类型转换关系，而难以处理多表之间互相关联的多个数据字段之间的复杂转换关系。

而在中国石油集团的同步应用场景中，为了在不改动当前各类应用系统的数据资源结构的基础上实现分布式数据库系统的数据同步目标，就必然涉及在同步过程中需要完成对数据字段之间复杂转换关系的处理，这就意味着数据转换模块必须能够承担足够复杂的数据分析处理任务。

为此，本文在三个标准步骤的基础上特别设计了一个智能数据转换中心，并基于该数据转换中心，将同步的源数据库和目标数据库区分为同步源区和同步目标区，每个同步源区和同步目标区都可以拥有不止一个数据库，它们之间的复杂数据转换关系依靠智能数据转换中心进行处理以便满足中国石油集团的数据同步应用场景。

3.1 数据捕获

本文通过对目前常用的七种数据捕获技术的优缺点进行对比分析发现，控制表法能够获取各种方式操纵数据库所引起的变化数据，具有普遍适用性，且不需要修改表结构，不会影响原业务系统的性能，在时效性上十分灵活，其设计思想最适用于中国石油集团各机构业务系统的数据同步应用场景。

但是，控制表法要为每个进行同步的源表T创建一个控制表C，这对拥有大量需要同步的源数据表的同步应用来说是十分占用数据库空间的。因此，本文在控制表法设计思想的基础上，做了一种改进的用于异构数据库同步的变化数据捕获方法――同步变化表法。

该方法在每个要同步的源数据库中只创建一个同步变化表，同步变化表里面包含发生变化的源数据表的表名，数据项所在源数据表的主键值，数据变化的类型（插入、删除、更新），数据变化时间和数据同步的状态（已同步、未同步）。当源数据表中的数据发生变化的时候，通过在其上建立的删除、增加和修改触发器向同步变化表里面添加相应的记录信息。这些记录信息被用于在同步过程中查找变化数据的完整信息，并且在数据被同步成功后删除，有效的减少了数据库空间的占有量。

3.2 数据转换

为解决中国石油集团异构数据之间复杂的转换关系，本文设计了一个智能数据转换中心，该转换中心利用数据整合、数据计算和一个可以自由灵活扩充的计算公式库用于处理对应复杂数据关系的转换。

智能数据转换中心会将提取的变化数据按照系统规则整合为约定格式的XML文档，该XML文档详细描述了每个数据的来源数据库、数据表名称、数据字段与数据类型。之后由数据计算中心按照配置的数据转换关系从XML文档中提取相关数据并调用计算公式库中的算子进行分析得到目标数据表要求的数据格式，并将这些数据转换为对应目标数据库的SQL脚本进行输出，从而完成复杂数据关系的转换。

3.3 数据传输

为保证传输周期的灵活性，本文采用定时器技术以自由指定周期的轮询方式进行数据传输。图2展现了本文设计的数据传输模块的处理流程。

4 数据同步方案实现

4.1 同步实例

以中国石油集团某机构下级业务系统向上级系统汇总油井数据同步应用为例。

在这一同步应用场景中，一个地区存在多个并行的下级业务系统负责管理其所分配的若干口油井。上级业务系统每天会获取一次这些下级业务系统的当日采油量数据进行汇总，从而得到某一地区每日采油量数据。

4.2 系统实现

很显然，在汇总采油量数据的同步应用中，是一个多对一的复杂数据转换关系。同步源区包含多个下级业务系统对应的源数据库，同步目标区只包含一个上级业务系统对应的目标数据库，在同步过程中，对应一个地区的采油量数据需要对地区包含的每一个下级业务系统对应数据库中的每日油井信息表数据做汇总计算得到，为此，按照本文所设计的同步方案，同步系统实现如下：

（1）需要在下级业务系统数据库中增加同步变化表如表1。

（2）为每日油井信息表dailyOil添加增删改触发器，用于捕获每日变化数据到同步变化表中。

（3）在智能数据转换中心中将这一种复杂数据转换关系配置在映射文件中如下：

可见，在数据转换关系映射文件中记录了上级业务系统每日采油量信息表AreaOil所需要的数据对应的每个地区的源数据库链接地址，数据转换的计算方式，各个字段与源数据表字段的关联关系，源数据表名称和轮询周期。在执行过程中，智能数据转换中心将根据这些信息定时提取源变化数据集合做相应计算完成复杂数据转换。最后，本文采用JAVA语言对系统做了实现。

5 结语

本文设计的多级异构数据库智能同步分析系统可以在不改变原有系统业务逻辑和数据资源结构的基础上来完成不同异构数据的同步处理任务，有效满足了中国石油集团的分布式系统数据同步应用场景。该系统采用类似插件开发的问题解决思路，具备很广的通用性，可普遍适用于不需要保持数据副本紧密一致性的各类数据同步应用场景。

参考文献

[1]杨淼淇，叶国权，孙纳新.异构数据库的变化捕捉和动态同步策略的研究与比较[J].办公自动化：综合月刊，2010（03）：35-37.

[2]杨鹏，杨海涛，王正华.异构数据库变化捕捉及同步策略[J].计算机工程，2008（16）：53-55.

[3]张雪洁，王志坚，许峰，李静燕.基于XML的领域异构数据库间的数据转换[J].计算机与现代化，2004（05）：71-74.

作者简介

唐孝宇（1984-），男。大学本科学历。现为中国石油集团工程设计有限责任公司北京分公司工程师，从事公司网络管理及信息化建设策划、研究和实施工作。

关系型数据库范文第2篇

关键词：关系数据库；数字水印；hash函数

1.引言

数据库水印就是在数据库数据中嵌入水印达到保护数据库所有权的一种技术，是近年来数据库安全领域快速发展的一个重要分支。它可以借鉴多媒体数字水印技术的原理和思想，但与多媒体数据相比较，关系数据库数字水印技术要困难很多，因为关系数据库中的数据还有许多特点：

1） 关系数据库中的数据由若干独立元组组成，每个元组的各个字段的值是确定的，冗余很小；

2） 关系数据库中的数据行和列的顺序是无序的；

3） 关系数据库中的数据经常要进行增加、删除、修改。

由于关系数据库数据有其自己的特殊性，这些都使数字水印的嵌入和提取成为难题。因此，数据库水印的算法考虑如下：

( 1) 鲁棒性，数据库水印能够经受住数据更新和攻击；

( 2) 透明性，数字水印不能被用户察觉，不会因为加了水印而影响关系数据的使用。

2.数据库数字水印模型

一般数据库数字水印模型主要包括3个算法：数字水印生成算法、数字水印嵌入算法和数字水印提取算法。

2.1数字水印生成模型

数字水印可以是文本、图像等，想把水印嵌入到数据库中，必须要对水印进行预处理，把它转换成二进制流。水印生成模型如图1所示：

图1 数字水印生成模型

2.2数字水印嵌入模型

数字水印的嵌入通常是把处理好的二进制水印通过数字水印嵌入算法隐藏到数据库的某些数据中，而不影响数据库的使用。水印嵌入模型如图2所示：

图2 数字水印嵌入模型

2.3数字水印提取模型

数字水印的提取通常是利用密钥，通过水印提取算法从数据库中提取出水印信号，解预处理后，再恢复为原有的数字水印信号。

图3 数字水印提取模型

3.关系数据库数字水印算法

关系数据库的行被称为“元组”，列被称为“字段”。元组是字段的集合，字段有不同的类型和取值，考虑到关系数据库的特点和不破坏数据库的使用价值，针对数值型字段值进行数字水印。在一个数据库里，数值型字段有1个或多个，他们的有效位数是不同的，有的有效位数多，有的有效位数少，本文采取了对数值型字段的最低有效位进行数字水印的嵌入算法。

3.1算法描述

（1）水印预处理：将文本水印转换为二进制并进行纠错编码处理；

（2）水印的嵌入：通过单向哈希函数HASH确定数字水印的嵌入位置，然后把二进制水印按顺序嵌入到选定元组的数值型数据的最低有效位上；

（3）水印的提取：对水印数据库库中的数值型字段计算函数HASH值，然后顺序提取各嵌入位0、1序列，最后再恢复成水印信息。

3.2数字水印预处理

本文采用的是文本水印W，可以由各种字符组成，按照ASCII码表将每个字符用一个字节表示，然后顺序排列，得到了二进制比特流，然后分成4组，不足的添0补齐。最后用海明码对水印信息进行纠错编码。

有效的纠错编码方法有很多种，最简单也是最早的方法之一是海明码，它保证了任意两个编码信息至少有3个比特不同，并可以对单个比特错误进行修正。复杂一点的编码有BCH和网格码，可以纠正更多错误。这些编码经常根据符号纠错的方法来描述，不同编码适合不同的错误类型。例如，海明编码处理随机错误效果较好，而BCH编码处理突发错误（连续符号群发错误）效果较好。

3.3数字水印嵌入位置

数据库的容量是巨大的，而水印信号是有限的，要嵌入水印信号的元组数量远远小于数据库包含的元组，因此要选择一定数量的元组进行水印的嵌入，以减少工作量和避免对数据库的大量修改。数据库中的数据经常变动，所以要在不同情况下找到嵌入水印的元组就要对数据库中元组进行标记．同时在提取水印时，使用一样的标记可以找到这个元组．

3.4数字水印嵌入算法

1 )将文本水印信息转换为二进制形式；

2 )利用海明码对二进制水印进行纠错编码；

3 )计算HASH值ID和控制因子C，确定数字水印的嵌入位置T； 

4 )根据T的值，按照水印二进制流的顺序，将0、1代码依次嵌入各数值型字段的最低比特位。

3.5数字水印提取算法

1 )针对数据库中的数值型字段，计算HASH函数的值，再通过控制因子C找到嵌入水印的位置；

2 )根据水印嵌入的位置， 顺序提取各嵌入位的0、1序列；

3 )根据0、1序列恢复成水印信息。 

4.总结

数据库水印技术是数据库安全领域的新生事物，虽然数据库水印技术困难很大，研究进展缓慢，但数据库数字水印技术的研究具有很重要的理论意义和广阔的应用前景。本文阐述了数据库数字水印的基本原理和通用模型，并具体介绍了一种基于数值型字段的数字水印算法，该算法经实验证明具有较强的鲁棒性和健壮性。

参考文献：

[1 ] 彭沛夫，林亚平，张桂芳，等．基于有效位数的数据库数字水印[ J ] ．计算机工程与应用， 2 0 0 6．4 ， 4 2 ( 1 1 ) ： 1 6 6 -1 6 8 ． 

[2] 王树梅， 赵卫东， 王志成． 数字水印嵌入强度最优化分析 [ J ] ．计算机安全，2007．

[3] 傅瑜．关系数据库的数字水印模型 [ D ] ．华中师范大学硕士学位论文，2007．

[4] 王忠，叶雄 飞．遗传算法在数字水印技术中的应用[ J ] ．武汉工程大学学报，2 0 0 8 ，1 ： 9 5 —9 7 ．    

关系型数据库范文第3篇

关键词：树型结构；Treeview控件

中图分类号：TP311.52 文献标识码：A 文章编号：1007-9599 （2012） 17-0000-02

1 引言

在树型结构中，根节点没有前驱节点，其他节点均有一个前驱节点，叶子节点没有后续节点，其他节点均有一个或多个后续节点，其核心就是数据元素之间一对多的关系，比如设备管理、组织结构等。然而在关系型数据库中，表是以行和列的形式组织起来的数据集合，表的每一行是一个数据元素，数据元素之间呈线性排列，彼此间没有关系，在各种基于关系型数据库开发的应用系统中，我们往往要存储像组织结构这样的树型结构的数据，数据元素之间存在着一对多的关系，将具有树型结构的数据元素简单的呈线性排列是无法体现数据元素之间的关系，如何在关系型数据库中设计树型数据结构并有效应用，是我们要解决的问题。

2 数据结构设计

2.1 路径表示法

路径表示法是将从根节点到节点的路径记录下来，每条记录中的路径字段表明了节点在树中的层次关系，如表一。equipmentType列记录设备类型，path列记录设备类型路径。路径表示法优点在于查询方便，不受树深度的影响，缺点在于要修改某一节点在树中的隶属关系时需要维护路径，这样做非常麻烦。

2.2 双亲表示法

双亲表示法用两个字段来表示一个节点在树中的隶属关系，如表二。equipmentType列记录设备类型，equipmentTypeParent列父记录设备类型。双亲表示法的优点在于修改某一节点在树的隶属关系比较方便，只需要修改父节点信息既可，缺点在于查询单一节点信息方便，但是查询某一父节点下的所有子节点信息需要递归查询。

2.省略平台下利用Treeview控件对树型结构数据进行展示和数据维护的方法。图一为数据维护界面。

界面左侧为设备类型树，图二为Treeview控件的示例代码。程序初始化时，可以将已经设计好的数据表中的设备信息集合作为Treeview控件的数据源，当在树中点击任意设备类型时，右侧将显示此设备的详细信息，这一点在选择改变事件中可以用简单代码实现。数据初始化与选择改变事件关键代码如下：

using System.Windows.Controls；

public partial class mobileEquipmentTypeTreeManage ： UserControl

{

dataformService ser = new dataformService（）；

public mobileEquipmentTypeTreeManage（）

{

InitializeComponent（）；

elementTypeTree elementTypeTree；

ser.getMobileEquipmentTypeTree（out elementTypeTree）；

mobileEquipmentTypeTreeView.ItemsSource = new List（） { elementTypeTree }；

……

}

private void mobileEquipmentTypeTreeView_SelectedItemChanged（object sender， RoutedPropertyChangedEventArgs e）

{

elementTypeTree elementTypeTree = mobileEquipmentTypeTreeView.SelectedItem as elementTypeTree；

if （elementTypeTree ！= null）

{

this.mobileEquipmentTypeTextBox.Text = elementTypeTree.current.type；

……

}

}

……

}

4 数据维护

基于数据结构设计采用路径表示法与双亲表示法相结合的方式，在这里只对数据维护要注意的事项进行说明。

4.1 增加节点

（1）父节点必须存在，可以在树中选择任意节点作为父节点。（2）新增节点路径 = 父节点路径 + 新增节点名称。（3）新增节点在树中不能已经存在。

4.2删除节点

（1）要删除的节点是否有子节点，如果有需先删除子节点。

4.3修改节点

（1）修改后的父节点必须是存在于树中。（2）要修改的节点不能为父节点。（3）修改后的节点路径 = 修改后的父节点路径 + 修改后的节点名称

5 结束语

本文讨论的树型结构设计方法，利用了数据冗余减少了数据表的数量，相对的增加了数据结构的稳定性，树的深度不受限制。对单条数据维护不会破坏树结构，与以往在数据库中使用SQL语句维护数据相比，操作相对简便易懂。此方案已经成功应用于本单位的生产系统和车辆调度系统。

参考文献：

关系型数据库范文第4篇

【关键词】关系数据库；非关系数据库；NoSql

前言

从上个世纪60年代至今的半个世纪，数据库技术伴随着信息技术的发展不断发展，到目前共经历了人工管理阶段、文件系统阶段和数据库系统阶段，在数据库系统阶段又经历了网状数据库、层次数据库和关系数据库阶段，进二十来年，关系数据被广泛使用，发展成主流，但随着互联网技术的蓬勃发展，关系数据库使用遇到了一些新的问题，为应对这些新的问题，近两年来非关系数据库NOSql越来越引起人们的注视，得到了快速发展。

1 关系数据库

1.1 关系数据库的简介

支持关系模型的数据库系成之为关系数据库，是目前各类数据库中使用最为广泛的数据库系统。关系数据库在经过二十几年的发展，已经变的功能强大，使用广泛，产品成熟的数据库系统，现在使用主流的数据库都为关系型数据库，比较熟悉的如SQL Server、Mysql、Oracle、Sybase、Informix、DB2等。在网络上使用比较广泛的是Sql Server、Mysql和Oracle。

1.2 关系数据库的特点

关系数据库是支持关系模型的数据库系统。而关系模型是由二维表来表示实体和实体间联系的模型。使用二维表存储数据，对使用者来说很直观，更容易理解。使用关系数据库的优势主要表现在以下几个特性：

（1）操作方便性。通过开发应用程序和数据库连接，用户能方便的对数据库中数据进行操作，特别对没有数据库基础的人，也可以通过数据库管理系统，直接在数据库中操作。

（2）易于维护性。关系数据库在完整性约束中提供了实体完整性、参照完整性和用户定义的完整性，通过完整性约束可以大大降低了数据存储的冗余及数据不一致的概率。

（3）访问数据的灵活性。关系数据库中提供了诸如视图，存储过程，触发器，索引等对象，是访问数据更加灵活。

1.3 目前关系数据库面临的问题

随着互联网技术的发展，尤其是web2.0 技术使用，更注重用户和服务器以及用户和用户之间的交互作用，用户成为既是网站内容的浏览者，也是网站内容的制造者。例如：博客（BLOG）、社会网络（SNS）、以及现在比较热的微博等。对于在使用web2.0技术并且访问量比较大网站，使用传统关系数据库就会遇到一些问题，主要表现在以下几点：

（1）对数据库高并发读写的需求

Web 2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，无法使用动态页面静态化技术，因此数据库的并发负载非常高，往往要达到每秒上万次的的读写请求，此时服务器上的磁盘根本无法承受如此之多的读写请求。

（2）对海量数据的高效率存储和访问的需求

对于大型的社交网站网站，每天用户产生海量的用户动态，随着用户的不断增减，一个数据表中的记录可能有几亿条，对于关系型数据库来说，在一个有上亿条记录的表里面进行SQL询，效率是极其低下的。一些大型Web 网站的用户登录系统也是如此，如腾讯、163邮箱都有数亿的帐号。

（3）对数据库的高扩展性和高可用性的需求

在基于Web的架构中，数据库是最难进行横向扩展的，当用户量和访问量增加时， 数据库没有办法像Web Server 那样简单的通过添加更多的硬件和服务结点来扩展性能和负载能力，对于很多需要24 小时不间断服务的网站来说，对数据库系统的升级和扩展往往需要停机维护。

2 非关系数据库NoSql

2.1 NoSql概述

NoSql是应对关系数据库出现的问题而发展起来的，近几年随着web2.0技术的广泛应用，NoSQL 得到了快速的发展，NoSQL数据库指的是非关系性的、定义不是很明确的数据存储仓库。NoSQL数据库不再使用关系模型的概念，放弃了使用SQL语句对数据库进行操作。

NoSQL 数据库根据数据的存储模型和特点又分为很多种类。主要有

（1）面向列的存储系统。按列存储，区别于关系数据库中按行存储，容易扩展，适用与存储海量数据，对一个或几个字段进行查询的效率很高，但在复杂查询功能比较弱，如多表联合查询。此类数据库产品有BigTable、Hbase、assandra和Hypertable。

（2）面向文档存储系统。保证海量数据存储的同时，具有良好的查询性能。用JSON或类JSON格式进行存储，存储的内容是文档型的，文档中的格式是自由的。此类数据库产品有MongoDB和CouchDB。

（3）键-值（key/value）存储系统。是最简单的Nosql系统，具有极高的并发读写性能。通过key能够快速查询到value，并且不考虑value 的格式。此类数据库产品有Tokyo Cabinet/Tyrant、BerkeleyDB、MemcacheDB和Redis。

（4）图存储系统。图形关系的最佳存储模式。如Neo4J、FlockDB。

（5）对象存储。类似面向对象语言的语法操作数据库，通过对象的方式存取数据。此类数据库产品有db4o、Versant。

（6）xml 数据库。高效存储XML 数据，并支持XML的内部查询语法。此类数据库产品有Berkeley DBXML、BaseX。

2.2 NoSql数据库的优势

相对于关系数据库，Nosql数据库的优点主要表现在：

（1）容易扩展和高性能。NoSQL 数据库种类很多，但是都有一个共同的特点就是去掉关系型数据库的关系型特性。数据之间彼此无关系，这样就非常容易扩展。可以存储海量数据。同样由于数据之间无关系，数据库的结构简单，在处理大数据量时，NoSQL 数据库会有出色的读写性能。

（2）灵活的数据模型。NoSQL 数据库不使用传统的关系数据库模型，而是使用如key-value 存储、文档型的、列存储、图型数据库、xml 等方式存储数据模型，使用这些模型都无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。同时根据需求可以选择合适的模型。

（3）经济性

在数据量和访问量比较大的情况下，传统的关系数据库对服务器的要求比较高，甚至使用专用硬件设备，这样造价就比较高。而NoSQL数据库的易扩展的特点使配置较低服务器上运行，也可以使用低配服务器组成集群来使用，并且有研究证实使用NoSql数据库基于低配硬件的分布式存储解决方案比现在的高端关系数据库更加可靠。这样就极大的降低了投资成本。

2.3 NoSql的不足

（1）成熟度方面。NoSQL数据库的实际应用，近几年才逐渐开始使用，并且大部分NoSQL的产品都还处于实验和不断完善的阶段。在产品成熟度和稳定性方面，NoSq数据库远不及发展了二十多年且已被广泛使用的关系数据库。

（2）商业支持方面。大部分NoSQL数据库都是开源项目，没有专门的数据库厂商提供完善的服务，一旦出现故障，只能自己的能力解决，对于一般使用者来说风险比较大。

（3）使用习惯方面。软件开发人员已经习惯了关系数据库的模式，解决问题的思路已经被固定在关系模型上，而NoSQL数据库的开发以放弃了关系模型，要软件开发人员放弃原来的思路，而掌握和使用NoSql数据库是很困难的，导致使用NoSQL数据库的开发人员不可能在短时间内快速增加，这也成为NoSql数据库发展的一个障碍。

3 关系数据库与NoSQL 数据库结合使用

Web2.0时代，关系数据库不能满足对数据库高并发读写、海量数据的高效率存储和访问、高扩展性和高可用性方面的需求，而NoSql数据库可以解决这些问题，从而推动了NoSql数据库应用和发展，那是不是说NoSql数据库就能取代关系数据可了呢？从目前来看，基于NoSql数据库的不足，NoSql数据库还不能完全取代关系数据库，对NoSql数据库的使用，单独使用的情况很少，大多数情况下都是关系数据库和NoSql数据库结合使用。

关系数据库和NoSql数据库结合使用又分为两种模式：

（1）NoSql数据库作为辅助存储。在这种模式下，把所有的数据都存放在关系数据库中，可能被经常频繁读取的数据再存放在NoSql数据库中一份，其目的是提高数据的查询速度，减少关系数据库的并发访问负载。

（2）NoSql数据库作为主存储。在这种模式下，把所有的数据存储在NOSQL数据库中，为了一些特殊业务或功能的需要，在将数据存入NOSQL 的时候，同时存储到关系数据库一份。在数据存储和查询主要是由Nosql数据库完成，少量的数据是从关系数据库读取。

4 结语

目前关系数据库仍是主流数据库，仍被广泛使用，NoSQL数据库还不能完全取代关系数据库，虽然NoSql数据库打破了关系数据库存储的观念，采用创新的存储方式，在快速读写、海量存储，高扩展性上很好满足web2.0时代数据存储的要求，但NoSql数据库也有自己的缺陷。在现阶段的某些情况下，可以将关系型数据库和NoSQL数据库结合使用，相互弥补各自的不足。随着NoSql数据库的不断发展和完善，将来也有可能取代关系数据库成为主流数据库。

参考文献：

[1]卢冬海，何先波.浅析NoSQL数据库 中国西部科技 2011年02期

关系型数据库范文第5篇

摘要:

医疗信息的复杂性和动态性给医疗信息系统带来巨大的挑战，openEHR规范的两层建模思想提高医疗信息系统的灵活性，适应医疗信息需求的变化。但面临查询数据量巨大、查询条件复杂多变的个性化操作需求时，基于openEHR两层建模方法实现医疗信息系统查询性能较低，这主要与底层数据存储模型有关。数据仓库多维数据模型具有高性能查询的优点，通过建立满足个性化需求的数据集市，可以加快数据查询速度。由于基于openEHR规范两层建模方法实现的医疗信息系统的特殊性，传统的数据仓库构建方法使得用户的参与性较低并且费时费力。针对这一问题，以openEHR规范的两层建模思想为基础，提出模板到动态数据仓库多维数据模型的映射方法，实现多维数据模型的用户可配置，利用映射路径加快ETL的实施，为医疗行业提供一种可操控、可扩展并真实反映用户需求的数据仓库构建方法。对该方法进行性能上的验证，结果表明，在10861522条数据中查询329条数据时，基于该方法构建的数据集市是基于openEHR两层建模方法生成的数据库的5.6倍，是基于传统方法构建的数据集市的0.97倍。

关键词:

openEHR;模板;数据仓库;多维数据模型

医疗领域的医学知识和医疗业务需求复杂多变，采取传统的医疗信息系统开发方法，工程技术人员不仅要在医疗信息系统开发之时即与医疗领域专家反复讨论确认，而且在系统的使用过程中还要不断对系统进行维护和更新，这使得医疗信息系统很难及时响应医疗人员对医疗信息的需求。openEHR规范作为一套开放的EHR(electronichealthrecord)体系结构，其核心在于将医疗领域知识从具体的临床信息中分离出来，并建立两层模型———参考模型和原型模型［1－2］。按照openEHR规范的设计，系统底层结构的开发主要基于参考模型，而系统中所涉及的领域概念全部由原型定义，这就有效降低了系统底层结构对领域知识的依赖性，从而使系统对领域知识变化的适应能力大大增强。领域知识层由原型和模板组成，允许领域专家直接定义，从而“把临床医生放回了驾驶员的座位上”［3］。

目前，国际上开展了很多基于openEHR规范的医疗信息系统的研究［4－5］，对openEHR两层建模思想进行了验证。在基于openEHR规范构建的医疗信息系统数据持久化层方面，国内外已研究出基于openEHR两层模型方法建立的医疗数据存储平台。该平台通过读取由领域专家定义的openEHR领域模型来满足相应的数据存储需求，实现医疗数据存储结构的高度可适应性和可扩展性。其中，开源的基于openEHR体系结构的Opereffa原型系统底层使用关系数据库存储医疗数据［6］，瑞典林雪平大学的SergioMirandaFreire等实现了使用XML数据库存储基于openEHR规范的医疗数据文档［7］，日本会津大学的AasthaMadaan等实现了由原型驱动的基于NoSQL数据库的医疗数据存储平台［8］。除此之外，浙江大学的王利等为了管理复杂和不断发展的医疗信息，利用openEHR两层模型和原型驱动方法的高度可适应性和可扩展性，设计并实现了一个由原型驱动的基于关系型数据库的医疗数据存储平台，由原型映射到关系型数据库表来实现灵活的数据存储。在ARM的基础上，该研究将AQL扩展为具有完整数据操作功能的数据操作语言，并在数据存储平台上进行了技术实现，从而使该数据存储平台通过一组网络服务对外提供灵活的数据访问［9］。基于openEHR两层建模实现的医疗信息系统提高了系统的灵活性，适应了医疗信息的变化和更新，但面临数据查询量巨大、查询条件复杂多变的个性化操作需求(报表、集成视图等)时，基于openEHR两层建模实现的医疗信息系统查询性能较低。这主要与底层数据存储模型有关，数据仓库多维数据模型拥有高性能查询的优点，通过改变基于openEHR两层建模实现的医疗信息系统底层数据存储结构，可以解决个性化操作需求中存在的性能问题。对于此类问题，目前采用数据驱动和应用驱动相结合的数据仓库开发方法，即根据数据源和具体的需求来设计多维数据模型，再进行相应的ETL设计实现，建立数据仓库［10］。由于基于openEHR规范两层建模方法实现的医疗系统的特殊性，系统持久化层会伴随领域知识的改变而发生变化，相应的数据仓库多维数据模型以及ETL设计都需随之发生改变;采用传统的数据仓库构建方法，在数据仓库的开发与维护过程中，技术开发人员需要不断地与用户进行沟通交流来明确用户的需求，费时费力且容易出错，用户的参与性较低，不能很好地适应领域知识的变化。针对这一问题，为了提高数据仓库构建时用户的参与性，加快数据仓库的构建速度，更好地满足用户的个性化需求，本研究以国际标准openEHR为基础，采用两层建模的方法，提高用户的可操控性，利用数据仓库多维数据模型高性能查询的优点，提出模板到动态数据仓库多维数据模型的映射方法。与传统的数据仓库构建方法相比，该方法实现了数据仓库多维数据模型的用户配置，提高了建立数据仓库时用户的参与性;在多维数据模型与数据源之间建立了映射关系，根据自动生成的映射路径可以快速地访问数据源中的数据结构、数据类型等信息，加快了ETL工作的进行，降低了构建数据仓库的周期。

1多维数据模型映射方法

openEHR原型通常是对临床知识完整定义，而在实际的医疗环境中，往往不需要记录如此完整详尽的信息。openEHR模板是根据实际临床需求，对若干原型合理组合并做进一步的语义约束，不会对原型施加任何新的语义。模板与原型的不同之处主要在于:原型通常需要在国家甚至国际层面上进行统一制定，以保证得到的原型具有通用性，可以被广泛共享。而模板的制作通常是相对局部化、本地化的事情，每个软件系统都可以根据自己的本地化需求，定义出一系列特定的模板。研究模板到动态数据仓库数据存储模型映射方法，更能切实地满足医疗工作者的个性化需求［11－12］。基于openEHR原型关系映射方法构建医疗信息系统，在显著提高数据持久化性能的同时，使医疗信息系统能够适应医疗信息需求快速发展变化的形势，促进医疗信息系统的应用［9］。目前，该构建方法被广泛采用，本研究选取基于openEHR原型关系映射方法生成的关系型数据库，作为构建数据仓库的数据源。数据仓库技术采用多维数据模型，多维数据模型把数据看作是多维空间中的点集，把集合的属性分为维和度量两类:维属性用来描述度量属性，是多维空间的维度;度量属性的值用来进行分析处理，是多维空间中的点。根据事实表和维表的关系，又可将常见的模型分为星型模型和雪花模型。两者在数据冗余度和查询性能上有所区别:雪花模型冗余度低，查询性能较低;星型模型虽然冗余度高，但查询性能好。因此，在冗余可以接受的前提下，实际中运用星型模型更多，也更有效率［13－14］。采用基于openEHR的临床医疗数据仓库构建方法，其主要技术路线如图1所示。模板真实反映了基于openEHR规范两层建模方法实现的医疗信息系统底层数据存储结构。该技术路线从模板出发，通过映射模块在模板与多维数据模型之间建立关联，在此基础上进行基于模板的元数据处理和ETL过程，实现数据集市建立。映射模块实现模板到动态数据仓库多维数据模型的映射，具体实现方法为:映射模块对传入的模板进行解析，生成反应模板内部数据结构信息的树形结构，根据原型关系映射规则对树形结构中的可选项进行筛选。用户通过对树形结构中节点的挑选，组合成满足需求的多维数据模型，并自动收集模板到多维数据模型的映射关系以及必要的元数据。ASP．NET是建立、部署以及执行Web应用程序的平台，它为构建新一代动态网站和基于网络的分布式应用提供了有力的支持。ASP．NET下MVC设计模式将程序分成相对独立而又能协同工作的3个部分———模型、视图、控制器，可以清楚地分离用户界面与业务逻辑，能够为系统开发提供基本的分析方法和清晰的设计框架［15］。本研究基于ASP．NET下MVC设计模式开发来实现。

1.1模板解析模板遵循TOM(templateobjectmodel)定义，原型由ADL(archetypedefinitionlanguage)定义。openEHR模板是根据实际需求对若干原型的合理组合，在模板解析中需要访问模板引用的原型。openEHR参考模型和原型定义了大量的类和属性，以及类之间的关系，尤其是参考模型，它不仅定义了openEHR的上层组织结构，而且对openEHR中各类信息的组织结构以及数据类型、数据结构等都进行了详细定义。因此，直接访问完整的参考模型和原型的实施将会是一项非常庞大的工程。目前，国际上已经出现了多个openEHR规范实施项目，其中比较有代表性的是瑞典Linkping大学RongChen等人组织开展的openEHRJAVA开源参考实施项目。该项目已经对RM和AM进行了比较完整的实现，因此，本研究RM和AM的实现直接基于此JAVA参考实施项目。根据实际需要，采用了openEHRJAVA的模块adl-parser和模块xml-serializer。模块adl-parser实现了ADL文件到AOM、AP对象的解析，模块xml-serializer实现了AOM、AP对象到XML文件的序列化。通过以上两个模块，可以将ADL文件转化为既方便计算机处理又具有一定可读性的XML数据文件。JAVA类文件并不能直接在ASP．NET下运行，IKVM．NET是开源的基于．NETCLR的JAVA虚拟机，该项目虽然在安全性上有待改进，但实现了JAVA程序在．NET下的运行。本研究通过引用以上两个模块和IKVM．NET，将ADL文件转化为方便计算机处理并且具有一定可读性的XML数据文件。JSON作为一种轻量级的数据传输格式，可以在多种语言之间进行数据交换。JSON易于阅读和编码，并且是JavaScript规范的子集，能够被支持JavaScript的浏览器所解析;相比XML，它减少了解析时带来的性能和兼容性问题，使其成为了理想的数据交换语言［16］。因此，本研究将JSON作为数据交换语言。在实现中，主要是XML文件到JSON对象的转换，这一过程借助XML2JSON插件完成。

模板解析技术的实现路线如图2所示。将模板转化为JSON对象后，传入后台解析模块，后台解析模块依次调用需要的原型，原型经过一系列的转化后转变为JSON对象，返回后台解析模块，后台解析模块解析模板，并生成一个真实反映模板内部结构的JSON对象，传入前台解析模块，前台解析模块遍历该JSON对象，生成模板对应的树形结构。在本研究中，将基于openEHR原型关系映射方法生成的关系型数据库作为构建数据仓库的数据源。为了真实地反映数据源中的数据结构信息，根据原型关系映射规则，对树形结构中的可选项进行了筛选，原型关系映射规则［9］如下:1)每个原型映射为一个关系数据库表，数据库表名为原型名。2)每个基本类型的原型属性映射为一个关系数据库表字段，字段名为属性名，字段类型为属性数据类型，字段长度为属性数据长度。3)每个集合类型的原型属性映射为一个单独的数据库表，数据库表名为“原型名_集合类型属性名”，包括主键字段，字段名为“原型名_集合类型属性名”;关联到原型对应的数据库表的外键字段，字段名为原型名，字段类型与原型对应的数据库表的主键字段类型相同;集合类型属性对应的字段，字段名为集合类型属性名，字段类型为集合类型属性数据类型，字段长度为集合类型属性数据长度。4)每一个archetypeslot类型的原型属性映射为一个单独的数据库表，数据库表名为“原型名_archetypeslot属性名”，包括主键字段，字段名为“原型名_集合类型属性名”;关联到原型对应的数据库表的外键字段，字段名为原型名，字段类型与原型对应的数据库表主键字段类型相同;archetypeslot类型属性对应的字段，字段名为“archetypeslot类型属性名”，并关联到目标原型对应的数据库表。根据以上规则，树形结构中能够映射到关系型数据库表字段名的节点为可选项，其他节点为不可选项。树形结构各节点name按照是否可选进行了不同的命名方式。不可选项name为对应模板层次结构中节点的属性名，可选项name由对应模板层次结构中节点的属性名、属性数据类型、该属性节点在模板中的完整路径三者拼接而成，以方便信息的传递。

1.2可操控配置个性化需求复杂多变，而模板包含了满足实际应用的信息，用户通过对解析模板生成的树形结构中有价值节点的选择，组合成满足个性化需求的事实表和维表，构建数据集市的多维数据模型。具体实现方法如下:根据数据仓库多维数据模型的相关定义，允许用户在建立数据集市时创建一张事实表和多张维表。在创建表的过程中，表名由用户手动输入，并进行唯一性检验，避免表名重复。用户通过对树形结构中有价值节点的选择，将该选中项的name信息传送到对应表，生成对应表的行信息，用户可以指定已创建表中的某一行为主键或某些行组合成复合主键，并可以对已创建的事实表和维表进行主/外键关联操作，组合成多维数据模型。数据集市是聚焦的、面向特定主题的，它通常致力于单一的某个领域，且为特定用户服务。为了方便对数据集市的使用与管理，在用户建立多维数据模型时，需用户输入数据集市的唯一性命名以及面向对象等元数据信息。

1.3数据库生成该模块的主要功能是根据用户已经建立好的多维数据模型，生成数据库，并收集部分元数据信息。用户输入命名的事实表名和维表名通常不符合实际数据库表名的命名规则，需经过解析转化符合命名标准的表名。解析用户配置生成的事实表和维表的各个行信息，得到该行的属性名、属性数据类型、属性节点的完整路径。解析后的属性名和属性数据类型主要为生成数据库表字段服务，而属性节点的完整路径提供AQL查询，可以查询到生成表字段的对应节点在原型中的信息，并可与通过原型关系映射生成的关系数据库中的表字段关联起来，方便数据的集成处理。解析后的属性名并不能直接作为生成数据库表的字段名，需经过解析和唯一性处理生成对应表的字段名，字段类型为对应属性数据类型。然后，收集主/外键关联信息，生成对应的创建关系型数据库表的SQL语句，在数据库中创建事实表和维表，并记录下生成的数据集市名、数据集市面向对象、表名、表字段、表字段对应的属性节点的完整路径等元数据信息，便于对数据集市的管理。

2结果

为了验证该方法是否可行，笔者针对查询检验信息的相关报表中存在的性能问题，根据模板到动态数据仓库多维数据模型映射方法，构建了满足需求的多维数据模型，通过专业的ETL工具SSIS，对数据进行了集成处理，建立数据集市，希望通过改变底层数据存储结构，提升查询性能，实现数据仓库的快速构建。选取了与检验信息相关的模板中有价值的节点，配置基于openEHR模板的多维数据模型，生成的数据库表结构如图3所示。该模型为包含一张事实表和三张维表的星型模型，涵盖了满足个性化需求的所需数据。其中，事实表FactLaboratoryTest存放了检验结果的相关数据，复合主键为TestReport_ID、ItemOrder。维表DimPatient存放了病人基本信息的相关数据，主键为PatientIdentifier_Identifier;维表DimAdmin_PatientAdmission存放了病人就诊的相关数据，主键为EncounterIdentifier;维表DimInst_LaboratoryTestRequest存放了检验申请的相关数据，主键为RequestorIdentifier。3个维表通过主键与事实表FactLaboratoryTest建立关联。在ETL过程中，基于openEHR原型关系映射生成的关系型数据库为数据源，利用构建多维数据模型时收集的表字段的完整路径与基于openEHR原型关系映射生成的关系型数据库中的表字段进行关联，快速地查找到其在数据源中对应数据的数据结构、数据类型等相关信息，在此基础上进行数据的集成处理。数据抽取频率设定为每天一次，抽取策略采用全量抽取，在ETL引擎中完成数据转换，然后对数据进行装载。

为了检验查询性能是否得到了提升，在基于模板到动态数据仓库多维数据模型映射方法建立的数据集市和基于传统方法建立的数据集市、基于原型关系映射生成的关系型数据库间进行查询性能对比，挑选了三者中的部分数据作为测试数据集，数据包括57465位病人基本信息、1210798条检验申请记录、840746条检验报告记录、10861522条检验结果记录。分别在三者中对某病人的相关信息、26条检验申请记录、24条检验报告记录、329条检验结果记录进行了查询。测试电脑配置CPU为Intel(R)Core(TM)2DuoCPU，内存为4GB，操作系统为Windows7.1Enterprise32位，数据库为SQLServer2012Enterprise32位。在三者中，分别进行了3次查询，所花费的时间以及各自平均查询时间的结果如表1所示。查询结果表明，在基于模板到动态数据仓库多维数据模型映射方法建立的数据集市中，对某病人的检验相关信息进行3次查询所花费的时间均值为274ms。在基于传统方法建立的数据集市中，花费的时间均值为265ms;在基于openEHR原型关系映射生成的关系型数据库中，花费的时间均值为1520ms。在查询性能上，基于模板到动态数据仓库多维数据模型映射方法是基于传统方法建立的数据集市的0.97倍，基本持平。与基于openEHR原型关系映射生成的关系型数据库相比，基于模板到动态数据仓库多维数据模型映射方法构建的数据集市在性能上提升了约5.6倍。总体表明，根据模板到动态数据仓库多维数据模型映射方法，可以配置满足个性化需求的多维数据模型，利用多维数据模型与数据源中数据建立的映射关系，方便了ETL过程的进行，实现了数据集市的快速建立。查询时间对比表明，该方法切实可行，大幅提升了个性化需求的查询性能。

3讨论

在本研究中，基于openEHR规范，提出了模板到动态数据仓库多维数据模型的映射方法。与传统的数据仓库构建方法相比，该方法充分利用了openEHR两层建模思想的模板领域知识驱动、易扩展、反映本地化需求等优点，使用户在无需了解数据源底层数据存储结构的基础上，实现了数据仓库多维数据模型的用户可配置，提高了在数据仓库构建过程中用户的参与性，避免了数据仓库开发前期的需求分析工作，满足了用户的个性化需求。在数据仓库多维数据模型的构建过程中，自动收集了数据源与多维数据模型间的映射关系，利用映射路径，方便ETL过程的处理，提高了数据仓库的构建效率。用户参与数据仓库中多维数据模型的设计有利也有弊。用户临床医疗知识和计算机操作水平的差异，会影响到多维数据模型的质量，并直接关系到数据集市的服务水平。在这一点上，本研究提出的模板到动态数据仓库多维数据模型的映射方法做了妥协。用户需要在技术人员的指导下进行模型的设计，借助专业的ETL工具实现数据集成。提高用户在临床医疗数据仓库系统开发过程中的参与性，让用户成为数据仓库构建的主角，是缩短系统开发周期、满足用户个性化需求的重要手段。但是，让用户独立配置数据仓库还是具有一定的风险，所以领域专家的指导和培训非常重要。通过培训，让用户了解临床医疗数据仓库的相关知识，以及将医疗数据仓库的领域概念与医疗领域知识相结合，对于数据仓库配置过程中以用户为主体具有一定的可操作性。

4结论