关系数据库汇总十篇

序论：好文章的创作是一个不断探索和完善的过程，我们为您推荐十篇关系数据库范例，希望它们能助您一臂之力，提升您的阅读品质，带来更深刻的阅读感受。

篇（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）

0 引言

关系数据库是20世纪70年代初提出来，经过数据库专家几十年的努力，理论和实践都取得了显著成果，标志着数据库技术的日益成熟。但它仍然难以实现对关系数据库中数据的分析，不能很好地支持决策，因此在80年代，产生了数据仓库的思想，90年代，数据仓库的基本原理、架构形式和使用原则都已确定。主要技术包括对数据库中数据访问、网络、C / S结构和图形界面，一些大公司已经开始构建数据仓库。针对数据仓库中迅速增长的海量数据的收集、存放，用人力已经不能解决，那么数据仓库中有用的知识的提取就需要数据挖掘来实现。数据挖掘与统计学子领域“试探性数据分析”及人工智能子领域“知识发现”和机器学有关，是一门综合性的技术学科。了解关系数据库、数据仓库与数据挖掘三者之间的区别与联系，使之更好的使用这3种技术，处理各种信息需求是非常必要和重要的。

1 关系数据库、数据仓库和数据挖掘之间的关系

1.1 关系数据库和数据仓库之间的联系与区别

关系数据库是面向事务的设计，数据仓库是一个面向主题的设计；关系数据库存储在线事务数据，数据仓库通常存储历史数据，关系数据库的设计将尽量避免冗余，但数据仓库是倾向于引入冗余；关系数据库设计用于捕获数据，数据仓库设计用于分析数据。传统的关系数据库面向以事务处理为主的系统应用，所以它无法满足决策支持系统的分析要求。事务处理和分析处理有非常不同的性质，他们有不同的需求数据。

1.2 数据仓库与数据挖掘之间的联系与区别

数据挖掘是基于数据仓库和多维数据库中的数据，找到数据的潜在模式进行预测，它可以对数据进行复杂处理。大多数情况下，数据挖掘是让数据从数据仓库到数据挖掘数据库中。从数据仓库中直接得到进行数据挖掘的数据有许多优点，因为数据仓库中数据的清理和数据挖掘中几乎是相同的，如果数据在数据仓库中已被清除，数据挖掘中不再被清除，并且数据不一致也得到了解决。数据仓库是数据挖掘的先期步骤，通过数据仓库的构建，提高了数据挖掘的效率和能力，保证了数据挖掘中的数据的宽广性和完整性。

1.3 关系数据库与数据挖掘之间的联系与区别

数据挖掘的数据源不一定是数据仓库。也可以是一个关系数据库中的数据，但要事先进行数据预处理，才能用于数据挖掘。数据预处理是数据挖掘的关键步骤，并且是数据挖掘过程中的主要工作部分。因此，数据仓库和数据挖掘没有必然的联系，有些人简单地认为，数据仓库是数据挖掘的准备，这种理解是不全面的，也可以使用关系数据库中的数据作为数据挖掘的数据源。

2 三种技术的应用

2.1 应用价值

2.1.1 关系数据库

关系数据库的主要价值体现在事务处理。关系数据库已经渗透到各行各业的日常事务，该事务管理离不开关系数据库的应用系统，这是对传统事务管理的一个重大突破，是社会甚至家庭不可或缺的工具，它对社会的应用价值是100%。

2.1.2 数据仓库

数据仓库的主要价值体现在为决策分析提供数据源。一方面，在一个事务中，用户要求高效的访问系统和数据库，操作时间应该短。在一个决策分析中，决策问题的一些请求可能会导致系统的操作，解决这一问题的决策分析需要遍历大多数数据库中的数据，这对一般日常事务处理系统是困难的，所以操作数据和决策分析数据应该分开。另一方面，决策数据需求问题。在决策分析时，由于不同的应用系统中，实体、字段存在数据类型、名称和格式的不符，需要在集成时进行转换，这个转换必须在决策之前完成；一些决策数据需要动态更新，需要经常进行汇总和总结，这些需求用事务处理系统解决比较繁琐。三是数据的操作模式问题。决策分析人员要以专业用户身份，使用各种工具以各种形式来操作数据，对数据操作的结果以商业智能的方式表达出来。事务处理系统不能满足这一要求，只有数据仓库系统能够满足数据挖掘技术对数据环境的要求，所以使用数据仓库中的数据省去了对数据预处理的步骤。

2.1.3 数据挖掘

面对日益激烈的市场竞争，客户对迅速应答各种业务问题的能力要求越来越高，对过量数据的及时处理要求越来越高，带来的挑战一方面大规模、复杂数据系统让用户感觉漫无头绪，无法开始；另一方面，这些大量数据背后隐藏很多有意义的有价值的决策信息。如计算机界都熟知的“啤酒与尿布”的故事，就是零售业巨头“沃尔玛”从大量销售数据中分析出来的规律：美国的男士在下班要去超市买婴儿尿布，同时他们还会买啤酒。“沃尔玛”就把这两种“毫不相干”的商品摆放在靠近的货架上，并且还摆放一些下洒小菜，使这些商品销量大增。所以应用数据挖掘从大量数据中发现规律，具有具体的指导意义。

2.2 应用领域

2.2.1 关系数据库

关系数据库应用领域非常广泛，如：证券行业、医院、银行、销售部门、公司或企业，以及政府、国防工业，科学和技术发展领域等等，这些领域都需要使用数据库来存储数据。例如：人事管理系统、工资管理系统，xxx部门信息管理系统，手机话费管理系统等，都需要关系数据库作为后台提供数据源。

2.2.2 数据仓库

数据仓库应用领域主要有两个方面：一是全局应用。因为数据仓库获得来自多方面的数据，所以在把数据向数据仓库输入时，要进行转换、计算和综合等集成处理。通过处理把来自不同地方的数据源转换成统一的格式，以促进全局应用。二是复杂系统。信息处理的要求越来越复杂，除了数据处理操作，如添加、删除、修改、和统计汇总，高级管理层也希望对历史的和现在的数据进行各种复杂性分析，以支持决策。数据仓库中就是存储了旧的历史数据，方便复杂分析、应用，为高层决策服务。

2.2.3 数据挖掘

数据挖掘的应用领域主要表现在特定应用问题和应用背景。数据挖掘技术已经应用于各行各业，如电信，保险，交通，学校、银行、超级市场等。例如：数据挖掘技术应用在大学。高校扩招，学生增加到几万人，但是学生的学习积极性不高，成绩不好，因此引入数据挖掘技术找出影响学生学习积极性和学习成绩的原因，制定措施，提高教育和教学质量。分析的数据源是考试成绩和成绩之外的影响因素，分析的方法是采用关联规则、模型库、去“噪”处理、粗糙集等进行数据挖掘，得出的结论是：传统的学习方法不能完全满足需要，改进教学方法和教学模式，从而调动学生学习的积极性，提高教学质量。

3 关系数据库、数据仓库与数据挖掘的融合

日常事务处理需要关系数据库，构建分析处理环境需要数据仓库，帮助决策者寻找数据之间的潜在的关联需要数据挖掘。他们之间是相互联系又有区别的，不能互相取代的，又需要相互融合。数据仓库中的数据并不是最新的，专有的，而是来源于其他关系数据库，它是建立在一个更全面和完善的信息应用的基础上，用于支持高层决策分析的数据基地。数据仓库是数据库新技术，到目前为止，数据仓库仍用关系数据库管理系统管理数据。数据挖掘是从大量存储在数据库、数据仓库或其他信息库中发现有趣知识的过程。只有这三个数据库技术互相融合，取长补短，各尽其责，才能更好的为广大用户所使用，为社会各个领域所应用。

【参考文献】

篇（3）

中图分类号：TP311　文献标识码：A　文章编号：1009-2374(2011)07-0088-02

在信息技术与网络技术高速发展的今天，网络已经成为新一代操作平台。信息正全面地以互联网方式展开，互联网的信息传播，极大地加速了人类发展的进程。随着WEB技术的日益发展，WEB已经成为信息制造、、加工和处理的主要平台。XML技术已日益受到更为广泛的关注，已经在电子商务、电子数据交换、科学数据表示、数据建模与分析和搜索引擎等领域有着广泛的应用。随着XML应用技术的深入，将会有大量的XML文档出现，并且现在在网络上已经积累了大量的XML文档。本文主要就基于关系数据库的XML存储技术相关问题进行探讨。

一、XML与关系数据库结构上的差异

XML文档是半结构化的数据，是一个树模型，如果考虑到XML元素次序，则是一棵有序树模型，其数据结构是非结构化的，而关系数据库管理系统是采用二维表格作为存储数据的模型，表格由行和列组成，列被称作“字段”用于表示组成数据有效信息的属性，行则用于储存一条完整的数据记录。XML数据与关系表之间数据结构有很大的差异，具体来说，XML数据是有序的，而关系数据则是无序的，另外XML数据的模式往往经常变化，可是关系数据库的数据结构是固定不变的，XML数据可以无限层次嵌套，而关系数据则不能。虽然XML放松的类型限制和自描述性有利于数据之间的交换，但是却不利于数据存储。因此，XML的数据模型的半结构化、有序性与平坦、无序的关系模型之间存在固有的不匹配。另外遵循文档类型定义(DTD)或文档模式定义(XML SCHEMA)的XML文档也与遵循关系存储模式的关系数据在语法、结构以及约束等很多方面存在着固有的异构性，因此很难直接由XML数据产生关系模式。甚至即使多个XML文档实例都遵循同一个文档模式定义，它们也可能有不同的结构。可以看出，XML映射到关系数据库中存在固有的困难。映射时主要存在以下需要解决的问题：(1)如何利用可能有的XML文档模式(或类型)信息来采取各种不同的存储策略；(2)如何将XML文档无损地存入关系数据库；(3)如何从关系数据库中查询并重构XML信息。

二、基于关系数据库的存储策略

(一)　基于结构映射的策略

具体来说，基于结构的映射方法可以分为两个步骤来实现：

第一步：简化DTD并生成DTD图。因为XML DTD的元素是相当复杂的，需要对复杂的DTD进行简化。DTD的简化变换主要有以下三种方式：(1)平面化变换：将DTD内的层次嵌套关系打平，把嵌套的定义转换为非嵌套的定义；(2)简化变换：将连续的多个一元操作转换为一个一元操作；(3)聚集变换：将多个具有相同名称的子元素聚在一起，形成一个子元素。一个DTD图表示的是一个DTD的结构，图的结点表示DTD中的元素、属性或操作符，DTD中的元素在DTD图中只出现一次，属性和操作符在DTD图中出现的次数则与它们在DTD中出现的次数相同。

第二步：DTD图到关系模式的映射。从DTD图到关系模式的映射方法主要有：基本内联法、共享内联法和综合内联法。

首先，基本内联法。基本内联法的原则是在存储一个结点的时候，尽可能多地将这个元素的后代结点存储在一个表中。其次，共享内联法。共享内联法为以下三种DTD结点生成独立的关系：(1)DTD图中入度大于l或者等于0(根结点)的元素结点生成独立的关系；(2)DTD图中结点“幸”的孩子结点(将值集元素作为单独的关系保存)；(3)互为递归的入度均为1的元素结点，其中之一生成独立的关系。而其余的结点都生成关系属性。共享内联法相对减少了XML查询转换为SOL语句的数目，但增加了每个SOL查询中的连接运算。再次，综合内联法。综合内联方法在处理入度大于1的结点上与共享内联方法不同，综合内联法将所有入度大于1的元素结点也内联进入父结点所生成的关系表中，但是带回路的结点以及结点“}”或“+”的直接后继结点除外，该方法减少了子结点与父结点的连接运算。

(二)　基于模型映射的策略

模型映射的方法是用一个固有的模式来存储XML文档。它用固定的关系模式来存放任何格式的XML数据，而不考虑XML文档的模式(DTD或SCHEMA)，其实质是存储XML文档本身的结构信息。

第一，Edge方法。Edge方法圆的存储策略是把要存入的XML文档看做图形结构，每个图的边界都表示为图中的元组，把XML文档图中的所有边都存入到关系表Edge中，用表Edge(source，ordinal，target，label，flag，value)存储XML文档图中的边，其中的source字段和target字段分别用来存储边的源结点和目标结点的标识符；label域为目标结点的类型；flag用来区分目标结点；target是一个元素结点还是一个文本结点，如果该目标结点是文本结点，则文本值存储于value域中；ordinal字段指出target结点在source结点的所有孩子中的位置。由于Edge方法将所有XML数据都用Edge表存放，操作方法简单。但缺点是在Edge方法中每条边都是单独管理的，所以在用户进行查询操作时就需在大量的表上进行连接操作以形成路径。如果要判断祖先/后代关系就需要从祖先到后代(或与之相反)遍历所有的边，造成代价非常昂贵。

第二，XRel方法。XRel方法为了存储XML文档的所有信息，将XML文档树分解为一个个路径表达式，对于树中每一个结点，都将从根结点到其自身的路径存储。而在树中有可能有多个结点的路径是一样的，所以单个的简单路径表达式并不能够存储整棵XML文档树的信息。XRel模式是通过区间编码[start，end]来反映XML文档的模型结构，并根据结点类型来划分，分为元素结点表、属性结点表和文本结点表，同时将所有路径进行存储。因此，XRel模式由四个关系表组成如图1所示：

在Path表中，存储所有的不重复的路径，其中，PathID为标记路径的标识，pathexp域存储标记路径。为了实现路径表达式的字符串匹配操作，防止意外的结果出现，将标记路径中的“/”替换为“#/”进行存储。对于Element表、Attribute表和Text表，Attribute表和Text表中的value字段存储的分别是属性结点的值和文本结点的值。对于每一个路径表达式，查询过程都可以分为两部：第一步，利用字符串的匹配操作，能够快速的查找出与路径表达式相匹配的所有标记路径的标识；第二步，利用这些路径标识，能够快速的查找出隶属于这些路径终端的值。

XRel存储模式的特点可以总结如下：(1)用简单路径表达式和结点的区间编码(start，end)存储XML文档的所有信息；(2)分别为每一种结点类型创建一个对应的关系表；(3)用一个Path表把文档中所有不重复的路径都提取出来，有效地降低了数据库的存储容量。

第三，XParent方法。XParent模式和XRel模式一样，将文本数据路径独立出来，共包含四个关系表，如图2所示：

其中，表LabelPath中的pathexp字段用来存储所有不重复的标签路径，即模式路径。每一个标签路径被赋予一个标识符pathlD，length为标记路径的长度。Parent表存储的是双亲/孩子关系，pid和cid分别表示一个边的起始结点与结尾结点。did为XML文档中元素结点的标识，它也可以作为以该结点为终端点的数据路径的标识。

篇（4）

中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2016）26-0008-02

1 引言

关系数据库是当今应用最广泛的数据库系统。关系数据库支持关系数据模型。关系数据结构非常单一，现实世界中的实体及实体之间的联系都是用关系来表示，在用户看来，关系数据结构就是二维表。常用的关系操作包括查询操作和插入、删除、修改操作两大部分，其中查询操作的表达能力最重要。数据查询是数据库应用中非常重要的组成部分，数据查询是否具备较高的执行效率和反应速度受到数据库设计者和用户的极大关注。

2 不同查询方案代价对比

关系模型中的查询语言早期通常是用代数方法或逻辑方法来表示，分别称为关系代数和关系演算，随后出现一种介于关系代数和关系演算的语言称为结构化查询语言，简称SQL。SQL语言作为关系数据库的标准语言向用户提供了易于掌握、高度非过程化得查询语言。大多数商用数据库都支持SQL语言，用户只需指明“干什么？”不需指出“怎么干。”对同一个查询要求有不同的查询解决方案，查询优化就是尽量在不同的解决方案中找到效率高、代价小的方案。

为了提升数据库系统性能对数据查询进行优化成了必须解决的问题，查询优化技术的发展与应用，也助推了数据库技术的推广与普及。

下面我们通过一个实例对比不同查询方案所花费的代价。

商品销售管理数据库

销售点信息表（销售点编号，城市、地址，联系电话，开设时间）

产品信息表（产品编号，产品名，类型，规格，生产厂家，进货价格）

销售情况表（销售点编号，产品编号，销售量，销售单价）

求销售产品编号为’JD051’这种产品的销售点信息？

用SQL语言表达该查询：

Select 销售点信息表.*

From 销售点信息表 ， 销售情况表

Where 销售点信息表.销售点编号=销售情况表.销售点编号 and 产品编号=’JD051’

SQL语言是高度的非过程化语言，同一个查询要求可以有不同的执行方式。下面针对上述查询要求运用关系代数表达式来表示不同的执行方式。

方案1

Π销售点信息表.*（σ销售点信息表.销售点编号=销售情况表.销售点编号∧销售情况表.产品编号=’JD051’（销售点信息表×销售情况表））

第一种方式需要占用内存空间保留广义笛卡尔积的中间结果，读取数据量过多及耗时较长；

方案2

Π销售点信息表.*（σ产品编号=’JD051’（销售点信息表∞销售情况表））

第二种方案相比第一种方式减少了中间结果，使用自然连接相比笛卡尔积大大减少了中间结果；

方案3

Π销售点编号（σ产品编号=’JD051’ （销售情况表））∞销售点信息表

第三种方式减少了数据读取量，中间结果相比第二种情况更少。总的查询时间最短、查询代价最少。

以上三种表达式虽然等价，但其执行的查询策略不同，数据规模越大，查询所花费的代价差别就越大。通过三种不同查询方式的对比，说明查询优化的必要性，选择合适的查询策略将大大减少查询时间、降低查询代价，因此查询优化问题一直是数据库研究的重点。

3 关系数据库查询处理过程

当用户发出查询请求，要采用不同的处理步骤对原始查询进行转换，这些转换工作必须在系统处理查询请求和返回查询结果前完成。关系数据库查询处理过程如图1所示。

图1

主要步骤：语法分析与翻译处理，查询优化处理，执行。

4 查询优化技术分类

查询优化技术一般分为代数优化和非代数优化（物理结构优化）。

1）代数优化，通过对查询语句进行变换，改变基本操作的次序，使查询语句执行起来更有效，这种查询优化仅涉及查询语句本身，而不涉及实际存取路径，称为独立于存取路径的优化，或代数优化。

查询是由高级查询语言表示的对数据库的一个或一组操作的集合，通常由投影、选择、连接、笛卡尔积等操作符组成。通过语法分析功能分析查询语句的正确性、完整性、有效性，并将其转换为等价关系代数查询树，如图2。

根据关系代数等价变换规则，查询树可以按以下方法进行变换：

方法1：下移选择和投影运算，以减少中间结果的元组数和参与运算的关系的规模；

方法2：将某些选择运算与笛卡尔积运算相结合；

方法3：同时执行同一个关系上的选择、投影运算，减少对关系的扫描次数；

方法4：将连接运算与投影运算结合起来执行。

图2可变换为图3。

对比图2和图3选择运算和投影运算优先执行，减少了查询中间结果的元组数，大大降低了参与连接运算的关系规模。

在制定具体的查询策略时应尽量减少对数据表的访问，减少对磁盘的访问次数，访问磁盘所需的时间大大长于对内存的访问时间，减少对磁盘的访问次数将大大降低系统的响应时间。选择运算尽可能提前做，往往可以使执行时间降低几个数量级，通过选择运算减少中间结果。在执行连接操作前，对关系进行适当的预处理，在连接的字段上建立索引以及对关系进行排序，加快查询速度。

关系代数优化的一般步骤：[3]

（a）把查询转换成语法树；（b）优化语法树；（c）选择低层次的存取路径；（d）选择代价较小的查询方案。

2）非代数优化，也称物理结构优化。数据库物理结构是整个数据库存储的基础，物理结构设计是在逻辑结构设计的基础上完成的，应确保数据库存储和访问或操作数据表具有较高的执行效率。物理结构优化是指为数据库系统的数据推荐合适的物理存储位置或存储结构，以及为查询推荐合适的存取路径，进而提升系统的整体性能。

5 小结

查询优化技术是数据库中一项重要的技术。对于的查询要求，我们应该根据数据规模大小，具体的物理存储结构等因素进行分析，选择合适的查询策略。具体的SQL查询语句应根据代数优化的相关原则进行变换，提高查询效率。查询优化目的是为了提升系统的性能，如果进行优化本身需要花费的代价过大，反而会降低系统的性能。所以只有兼顾了查询效率、控制系统开销、保障数据库安全等诸多方面才能真正地优化系统的性能。

参考文献：

[1] 冯卫兵.关系数据库的查询优化[J].现代计算机，2010（1）.

[2] 王能斌.数据库系统原理[M].北京：电子工业出版社，2001.

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

[4] 谷震离.关系数据库查询方法研究[J].微计算机信息，2006.

篇（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）

中图分类号：TP311文献标识码：A 文章编号：1009-3044(2008)16-21188-02

On Optimization Method for Query in Relational Database

YIN Mei-gui

(Heyuan Polytechnic, Heyuan 517000, China)

Abstract: In the database application MIS, query process is the most frequent. Whether query process is good or bad will directly affect the performance of database application system. Therefore, query in database should be optimized. This article suggests some methods of how to realize the optimization by making use of the technology of query in relational database.

Key words: RDBMS; query optimization; methods

1 引言

数据库系统是管理信息系统的核心，基于数据库的联机事务处理（OLTP）以及联机分析处理（OLAP）是企业、银行、政府部分最为重要的计算机应用之一。从大多数数据库系统的应用实例来看，查询操作是所有数据库操作中所占据比重最大的操作。当数据库系统积累到一定程度（如税务系统的账户达到上百万甚至上千万条记录），全表扫描一次往往需要数十分钟，甚至数小时。如果采用比全表扫描更好的查询策略，往往能降低查询时间。如何设计数据库，采取什么样的查询方法，提高查询效率，这就是查询优化要解决的问题。

2 合理使用索引

索引是数据库一个常用的数据库对象，优化查询的重要方法是建立索引，也是数据库同时预先将数据分类导入到多表格的方式。在关系数据库的表上建立合适的索引，可以提高数据库数据查询的速度，改善数据库的性能。除了集簇索引，每一索引的使用都以磁盘容量作为代价，当使用一个索引，数据库引擎必须执行两个数据读取，这两个数据读取是数据库记录所必需的，第一个数据被读取到实际数据指针的索引，第二个数据被读入到指针指定的位置。因此创建索引时必须要与实际应用系统的查询需求密切结合，才能达到优化查询的目的。

2.1 建索引的必要性

判断索引必要性的最终标准是判断这些索引是否对数据库的工作效率有所帮助。在实际的应用过程中，应该为优化工作做以下几点准备：

首先观察数据库应用程序中所有的SQL语句，并从中统计出常用且可能对性能有影响的部分语句，然后分析、归纳出作为Where条件子句的字段及其各种组合方式；在这一基础上可以初步判断出哪些表的哪些字段应该建立索引。其次，必须了解应用程序，要了解哪些表是数据操作频繁的表；哪些表经常与其他表进行连接；哪些表中的数据量可能很大；数据量大的表中各个字段的数据分布情况如何等等。对于满足上述条件的这些表，必须重点关注。因为建立在这些表上的索引，将对SQL语句的性能产生举足轻重的影响。

2.2 使用索引的规则

索引的使用要恰到好处，其使用原则如下：

（1）在经常进行连接，但是没有指定为外键的列上建立索引，而不经常连接的字段则由优化器自动生成索引。

（2）在主键索引方面，不应有超过25%列成为主键，而普通列很少，这会浪费索引空间。

（3）在条件表达式中经常用到的不同值较多的列上建立检索，在不同值少的列上不要建立索引。

（4）在频繁进行排序或分组（即进行group by 或 order by 操作）的属性上建立索引。

（5）在作为最小值等聚集函数的属性上考虑建立索引。

索引的建立、维护和使用都需要付出代价，应合理使用索引。错误的索引不会使数据库性能得到预期的提高，往往还会产生一些负面影响。

3 SQL语句优化

要对查询进行优化，一个简单直接有效的方法是对SQL语句进行调整，减少计算量，提高查询的效率。以下是一些书写SQL的一些经验。

3.1 避免相关子查询

查询嵌套层数每增加一层，查询的效率成几何级的降低。要想提高嵌套语句的执行效率，则应减少嵌套语句的嵌套的层次。所以在实际应用中，若可以用连接查询代替的子查询，则用连接查询实现。

例：查询选修了“3-105”号课程的学生基本信息

用子查询的方法如下所示：

SELECT * FROM student WHERE SNO IN (SELECT sno FROM sc WHERE cno=’3-105’)

改写成连接查询如下：

SELECT student.* FROM student,sc WHERE stuent.sno=sc.sno AND cno=’3-105’

3.2 用UNION替换OR

合理建立索引有助于提高查询效率。有时尽管在所有的检索列上都有索引，但有些形式SELECT查询语句可能不会促使查询优化器使用索引，从而降低查询效率。如果对查询语句进行改写，用UNION替换OR，可以强迫优化器按索引路径处理。如：假定分别在“职工”关系中的“年龄”和“月工资”字段上创建了索引，对以下SQL语句

SELECT 姓名，年龄，月工资 FROM 职工 WHERE 年龄>45 OR 月工资

可替换为：

SELECT 姓名，年龄，月工资 FROM 职工 WHERE 年龄>45

UNION

SELECT 姓名，年龄，月工资 FROM 职工 WHERE月工资

3.3 使用临时表优化查询

在涉及相关查询的某些情形中，构造临时关系可以提高查询效率。如：查询每个部门中月工资最高的“职工号”

SELECT 职工号 FROM 职工 AS e1 WHERE 月工资=(SELECT MAX(月工资)FROM 职工 AS e2 WHERE e1.部门号=e2.部门号)

以上的查询对于外层的职工关系e1中的每一个元组，都要对内层的整个职工关系e2进行检索，因此查询效率不高。可以构建临时关系提高查询效率。

SELECT MAX（月工资） AS 最高工资，部门号 INTO temp FROM职工 GROUP BY 部门号

SELECT 职工号 FROM 职工，temp WHERE 月工资=最高工资 AND 职工.部门号=temp.部门号

3.4 避免在索引列上使用计算

WHERE子句中，如果索引列是函数的一部分。优化器不使用索引而使用全表扫描。如

SELECT * FROM职工 WHERE 月工资*12>20000

可改为：

SELECT * FROM 职工 WHERE 月工资>20000/12

3.5 谓词的等价变换

由于执行引擎对各种谓词的处理方法不同，把逻辑表达式重写成等价的且效率较高的表达式是提高效率的有效方法，同时也是切实可行的。针对执行引擎对各种谓词执行效率的不同，总结如下谓词转换规则：

1）将BETWEEN转化为AND 连接的谓词

把BETWEEN．．．AND．．．形式改写为用AND连接的两个谓词，效率往往

有一定的提高。

例如：月工资 BETWEEN 1000 AND 2000 改为： 月工资>=1000 AND 月工资

2）避免使用In语句

当查询语句中有In关键词时，优化器采用OR并列条件。

如：职工号IN (‘1001’,’2001’) 改为：职工号=’1001’ OR 职工号=’2001’

4 结束语

查询处理是数据管理系统的核心，而查询优化技术是查询处理的关键技术。查询优化就要抓住关键问题。在数据库的开发和维护过程中，查询优化设计可以提高系统的性能，尤其对于数据量大的数据库系统最为重要。本文提到一些优化方法是根据自己的经验，并查阅了大量的资料。在具体的使用时候要根据实际情况，才能合理制定出良好的优化方法，实现快速、高效的数据查询。

参考文献：

篇（7）

一、关系数据库关键词查询概述

关系数据库通常通过结构化查询语言SQL来访问。SQL访问方式不但要求用户知道并理解关系数据库模式,也要懂得书写复杂的SQL查询语言,因此,它一般适合于专业用户使用。普通用户一般通过定制的关系数据库查询接口程序RQI(Relational databases Query Interface)或者关系数据库应用程序RAP(Relational databases Application Program)来访问关系数据库。RQI访问方式虽然不要求用户书写复杂SQL查询语言,但是要求用户知道并理解关系数据库模式,对于不同的关系数据库需要使用不同的RQI,而且定制的RQI也往往不能满足灵活多变的用户查询需求,当RQI不能满足用户查询需求时,就需要应用开发人员来修改RQI,由此,使用RQI访问方式则需要较高的开发费用和维护费用。

随着Internet和Web技术的快速发展和应用,一方面用户越来越习惯于使用简单的查询关键词通过Web搜索引擎如Google,Baidu等来搜索信息;另一方面,越来越多的关系数据库到Web上面向广大普通用户,形成所谓的“Deep Web”问题,使得普通用户也期望能够使用简单的关键词来查询关系数据库数据。

二、相关定义

定义1:关系数据库模式Sdb(Relational Database Schema)假设关系数据库的模式,Sdb=(R,FK),R={R1,R2,…,Rk}是一组关系模式,FK是R中关系模式间引用关系的映射,FK:RR,如果FK(Ri)=Rj,记为RiRj(1≤i,j≤n),它表示Rj一个外键引用了Ri主键。

定义2:关系数据库模式图Gs(Relational Database Schema Graph)假设Gs=(V,E)表示模式Sdb=(R,FK)的关系数据库对应的模式图。Gs是一个有向图,将关系数据库中的每一个关系模式Rk(1≤k≤n)看作是Gs的一个节点,当且仅当关系模式Ri∈Gs,关系模式Rj∈Gs,(RiRj)∈FK时,(Ri,Rj)∈E。

定义3:连接元组树Jt(Joning Tree of Tuples)给定一个关系数据库的模式图Gs=(V,E),Jt是以数据库中的元组tl为结点的一棵树,其中tl(1≤l≤m)是关系rk(1≤k≤m)中元组,关系rk(1≤k≤m)是关系模式Rk(1≤k≤n)上的实例,如果(Ri,Rj)∈E且(ti tj)∈(ri rj),那么,(ti,tj)是Jt的一条边,其中ti∈ri,tj∈rj,(1≤i, j≤n),称Jt为一棵连接元组树。

定义4:关键词查询Kq(Keyword Query)把关键词查询定义为查询函数f:KqT,其中Kq是一个集合,其元素ki(1≤i≤m)为关键词,T是一个集合,其元素Jti(1≤i≤n)为一个关键词查询结果。

定义5:关键词查询结果T(Keywords Qeury Results)关键词查询结果是OR语义,Kq是一个集合,其元素为ki(1≤i≤m)为关键词,一个查询结果是至少含有Kq中一个ki(1≤i≤m)且每个叶结点都至少含有Kq中一个ki(1≤i≤m) 的连接元组树。

关键词查询结果是AND语义,Kq是一个集合,其元素为ki(1≤i≤m)为关键词,一个查询结果是Kq中的每一个的关键词ki(1≤i≤m)都必须出现在结果中,并且每个叶子节点都至少含有一个Kq中的关键词ki(1≤i≤m)的连接元组树。

三、体系结构

(1)系统设置系统启动模块,做一些系统初始化工作,如系统的参数配置

(2)模式图生成器从系统配置文件读入数据库模式图的模式配置信息,生成数据库模式图。

(3)用户查询该模块为用户查询接口,接受用户输入的查询关键词,

提交后续模块处理。

(4)元组集生成器该模块利用由关系数据库的全文检索功能建立的IR引擎,将关系数据库中具有文本属性的每个关系生成元组集,只有那些与某个查询关键词或者查询关键词组合相关的非空的元组集保留下来,称为非自由元组集,每个非自由元组集都是其源表(即生成该元组集的表)的一个子集,每个非自由元组集实际上也是一个临时表,继承其源表的主外键关系。

(5)候选网络生成器候选网络生成器利用元组集生成器生成的非自由元组集扩展模式图,形成元组集图,然后对该元组集图进行扩展,生成结点不超过预定最大允许结点数的候选网络。所谓候选网络,也称元组集连接树,也是可以看做是要用来产生关键词查询潜在结果的JOIN表达式。

(6)候选网络执行器候选网络执行器完全执行所有候选网络得到全部结果,或者采用某种top-k算法执行候选网络,以得到top-k查询结果。

四、查询处理

系统启动时,首先会生成数据库模式图,这个过程非常短,然后系统接收到用户提交的查询关键词。当用户提交查询关键词时,元组集生成器利用IR引擎生成元组集,然后,候选网络产生器利用非自由元组集扩展Gs生成元组集图,广度优先遍历元组集图生成候选网络,最后,候选网络执行器执行全部候选网络。或者采用某种top-k查询算法执行候选网络,生成最终查询结果返回给用户。通过介绍SDSG系统,可以发现SDSG系统存在的优点:数据库模式图占用内存少;缺点:候选网络产生器执行效率低、候选网络执行效率低、缺少语义查询。

参考文献

[1] 施伯乐,丁宝康,汪卫.数据库系统教程.第二版.高等教育出版社,2003:1-359

篇（8）

2）德克萨斯大学的Sunitha Ramanujam提出了“Bi-directional Translation of Relational Data into Virtual RDF Stores”[5]，即关系数据和RDF间的双向转换，并在D2R的基础上开发了工具D2RQ++。

3）中科院国家科学图书馆成都分馆的Shihan Yang等人提出“半自动化地从关系数据库中构建本体”，文中提出了利用中间件来实现关系数据库到本体转化的方法，并且提出了W-graph的中间件语言，W-graph映射语义使用与关系数据库和本体都无关的双向模拟等价图表示。中间件模式是动态的，当数据库模式或本体频繁变化时，该方法因此有很好的适应性。此方法不仅可以处理数据库模式而且也可以处理数据库中存储的实例。图形语义编辑工具的开发，提高了方法的可用性。

4）许卓明提出 “一种从关系数据库学习OWL本体的方法”，开发出了关系数据库模式到OWL本体转换原型工具DB2WO，并给出了实例验证。该研究首先给出了关系数据库模式和OWL本体的定义，其次定义了关系数据库模式到OWL本体的一组映射规则，然后开发了转换工具DB2WO。关系数据库模式信息通过读取关系数据库字典来提取。

5）陈和平等人提出“基于关系数据库的本体生成器的设计与实现”[6] 。该研究中首先指出需要解决的2个关键问题：（1）如何提取关系数据库的ER模式（2）如何定义由ER模式到OWL本体的映射规则。然后给出ER模式的提取一般可以通过查询该关系数据库的数据字典或应用数据库的逆向工程工具，接着给出了ER模式到OWL本体的10多条转化规则。最后，给出了本体生成器OWLFROMDB的功能模块结构图，并给出了实例验证。

6）中国人民理工大学的Peng Liu等人在2010第九届国际网格和云计算会议提出“基于关系数据库的本体自动构建”[7]。其思想跟前述许卓明、陈和平等一致：通过分析关系数据库模式，建立一系列的从关系数据模式到OWL的转换规则，然后给出了算法和流程图，最后给出了生成的本体的层次图。

7）W3C成立了 RDB2RDF研究组，致力于提供一个从关系数据库RDB到本体描述语言RDF的规范性的映射标准，到目前为止，该研究小组提出了几个关于RDB到RDF映射语言的内部草稿，还未成为标准。

3 研究瓶颈及建议

现在，基于关系数据库生成本体的研究已经引起越来越多研究者的兴趣。基本思路无非是从关系数据库中提取出数据模式，然后设定数据模式转化为本体的规则，然后编程实现。每个研究人员都提出了自己的转化规则，而并没有人对规则的可行性给出评价结果。至今，尚未有研究者或机构给出权威的转换规则。转换规则的可行性和合理性应该是未来研究的重点。

4 结束语

利用关系数据库中结构化的数据作为数据源来构建本体的方法，已经引起了众多研究人员的重视，而随着W3C的介入， 必将使这种转换规范化。

参考文献：

[1] /RDF[EB/OL].

[2] /TR/owl-features[EB/OL].

[3] Du Xiaoyong, Li Man, Wang Shan. A Survey on Ontology Learning Research[J] .Journal of Software, 2006,17(9): 1837-1847.

[4] Sunitha Ramanujam ,VaibhavKhadilkar.Bi-directional Translation of Relational Data into Virtual RDF Stores[C].2010 IEEE Fourth International Conference on Semantic Computing,2010,61:268-276.

篇（9）

关键词：关系数据库 关键词查询 数据库索引

1 系统总体设计

人们在求解一个复杂问题时，通常采用的是逐步分解、分而治之的方法。也就是把一个大问题分解成若干个比较容易求解的小问题，然后分别求解。设计一个复杂的系统时，往往也是把整个系统划分为若干个功能较为单一的功能模块，然后分别予以设计、实现，这就是模块化设计。本系统也采用这种模块化设计方式。

■

图1 面向关系数据库关键字查询系统框图

2 数据库设计

本系统为面向关系数据库的关键字查询系统，在实验中本文选取了IMDB 数据集，为了进行实验，将数据集整理为以下七个表数据结构。

实验数据集（电影信息数据库）：

create table Actor（ //演员表

actorname varchar（50） Primary Key ; //演员姓名key

sex varchar（2）; //性别

mvname varchar（50）; //出演电影或电视剧名

mvyear varchar（10）; //电影上映时间

mvactorname varchar（10）; //电影中人物姓名

position varchar（20）; //电影中人物排名

made varchar（10）; //TV 或是Video

setname varchar（50）; //出演电视剧集名

episode varchar（10）; //出演电视剧集

date varchar（10）; //电视剧播出日期

classification varchar（30）; //（achieve football）

）

creat table Consume（ //设计师

consumename varchar（20） Primary Key; //设计师姓名key

mvname varchar（20）; //电影名或电视剧名

mvyear varchar（10）; //上映日期

setname varchar（20）; //电视剧集名

episode varchar（10）; //电视剧集

productiondate varchar（10）; //电视剧播放日期

classification varchar（30）; //（as M...）

made varchar（10）; ///（V/TV/uncredited）

）

creat table Director（ //导演信息

directorname varchar（20） Primary Key; //导演姓名key

mvname varchar（20）; //电影或电视剧名

mvyear varchar（10）; //上映日期

setname varchar（20）; //电视剧集名

episode varchar（20）; //电视剧集

made varchar（10）; //（V/TV/VG）

explantaion varchar（30）; //（as M...）

）

creat table Business（ //投资

mvname varchar（20） Primary Key; //电影名key

productiondate varchar（20）; //拍摄日期

company varchar（50）; //出品公司

studiodate varchar（50）; //上映日期

masterpiece varchar（1000）;///OW

budget varchar（20）; //预算

ad varchar（50）; ///AD

general_revenue varchar（20）; //收入

wg varchar（50）; //WG

）

editorname varchar（20） Primary Key; //编辑名

mvname varchar（20）; //电影或电视剧名key

mvyear varchar（10）; //上映日期

made varchar（10）; //（V/TV/video）

setname varchar（20）; //电视剧集名key

episode varchar（20）; //电视剧集key

explantaion varchar（30）; //（as M...）

）

creat table Color { //颜色信息

mvname varchar（20）; //电影或电视剧名key

mvyear varchar（10）; //上映日期

setname varchar（20）; //电视剧集名key

episode varchar（20）; //电视剧集key

color varchar（20）; //颜色分类color或black and white

explantaion varchar（10）; //颜色分类之后的（）中有（HD）等，（HD）是高清

Primary Key（mvname，setname，episode）;

}

creat table Keyword（ //关键词

mvname varchar（20）; //电影或电视剧名key

mvyear varchar（10）; //上映日期

setname varchar（20）; //电视剧集名key

episode varchar（10）; //电视剧集key

keyword varchar（50）; //关键词

Primary Key（mvname，setname，episode）;

）

3 数据库索引设计

由于关系型数据库对于文本属性上全文索引的支持，所以在文本属性可以直接利用数据库中的全文索引。对于给定的关键字k，全文索引能检索出查询关键字所在位置。

对于数据库中的表属性，构建索引的方式比较简单，依赖于DBMS的IR索引。对于数据库中具有文本属性的列，在该列上建立全文索引。在进行关键字查询时，对于给定的关键字，通过数据库的全文索引，会返回包含该关键字的元组集合。

在进行关键字查询的时候，对于用户给定查询关键字，系统首先要对给定的关键字进行定位，确定关键字所匹配的信息是模式项还是数值项。

例如，关键字{“Color”“Director”}的索引结构如表1所示。

表1 关键字{“Color”“Director”}的索引结构

■

4 关键字检索设计

在搜索引擎行业，所谓关键字，就是用户在使用搜索引擎时输入的、能够最大程度概括用户所要查找的信息内容的字或者词，是信息的概括化和集中化。关键字检索作为一种易于使用的检索方式，为大量普通用户所喜爱。本文从关键字个数角度介绍现有的关键字检索技术中最常见的单关键字查询和多关键字查询这两种关键字检索形式。

5 结果生成设计

在本文中，将查询结果定义为元组连接树。

元组连接树（Joined Tuple Tree）是给定一个数据库模式图GS，一个元组连接树T是一棵元组树。其中，T中的每一条边（ti，tj）（ti∈Ri，tj∈Rj）满足以下两个要求：

①（Ri，Rj）∈RS，

②ti∞tj∈Ri∞Rj。

同时这些元组连接树满足以下条件：

①完整性：用户提交的所有关键字均出现在元组连接树上;

②最小性：从元组连接树中移除任何元组后的元组连接树都不具有完整性。

6 结束语

通过分析相关检索系统的实现策略，设计了支持关键字检索的系统架构和核心构成组件，主要包括数据库索引、数据库模式图、关键字检索和结果生成。

参考文献：

篇（10）

中图分类号：TP391

文献标识码：A 文章编号：16727800（2014）002012703

0引言

工作流是公文流转系统的重要组成部分，不同于一般概念上的工作流，公文流转中的工作流具有自身特点和要求。本文提出的公文工作流模型基于关系数据库，降低了业务系统与公文流转系统集成的复杂度，减轻了复杂工作流引擎带来的系统负担，使公文流转系统能够适应不同的公文业务需求。

1工作流技术

通常把工作中具有固定程序的活动集合叫做工作流。它把工作活动细分成定义良好的角色、任务、过程和规则来完成工作的监控和执行，从而提高了工作效率和生产组织水平。国际工作流管理联盟（Workflow Management Coalition，WFMC）对工作流的概念进行了定义[1]：工作流是指在计算机支持下的整个或部分经营过程的全自动或半自动化。通常，工作流由计算机软件系统控制其执行。它包括一组活动以及活动之间的顺序关系、一系列过程和对每个活动的具体描述以及活动的启动和终止条件。通过分离应用逻辑和过程逻辑，可以在只修改过程模型而不修改具体功能的前提下改变系统功能，实现对生产经营过程部分或全部的自动化管理，合理、有效地把人、应用和信息组织在一起，实现了“在合理的时间把适当的信息传递给正确的人”的要求。

2公文流转工作流

2.1公文流转工作流定义

WMFC 给工作流做出了如下定义： 按照事先定义好的规则，文档、任务或者信息在参与者之间进行传递，从而完成整个业务过程的自动化处理。依据公文流转的特点，公文流转中的工作流包括如下4 个要素： 多人参与、同一个业务目标、每个参与者通过动作来完成自己的任务、按照一定的顺序和规则传递。公文流转通过多个参与者完成的一系列任务达到业务目标。由工作流的要素可知，在定义公文流转中的工作流时应考虑以下5方面定义：传递的公文文档定义、角色定义、活动定义、路线定义和事件定义。下面用一个公文流转过程来描述和定义公文流转中的工作流 [2]，如图1 所示。

（1）活动节点：实际上代表了组成一个实际过程所需要的任务，包括不可分割的原子级任务和套嵌的公文工作流过程。公文工作流主要依靠流转过程中各个节点的实现来达到公文流转的目的。

（2）事件节点：主要是用于确认流程是否推动，如果满足条件则流程继续，否则继续等待。

（3）控制节点：用于控制相邻活动节点的先序关系。控制条件一般在活动中定义，由继续流转条件、停止流转条件、退改条件组成。继续流转条件表示进入这个活动，是这个活动被激活的前提或准备条件；退改条件表示如果活动没有满足某个特定条件，则重复执行，一直到满足继续流转条件为止。

2.2公文流转工作流分析

2.2.1公文流转工作流程

按照公文流转中节点处理的时间先后顺序，可以把工作流程分为串行和并行两类。串行流程中所有节点呈“一”字型排列，后一个节点的启动时间为前一个节点的完成时间；并行流程中两个或者两个以上节点并排排列，节点可在同一时刻工作。典型的串行流程和并行流程如图2（a）和图2（b）所示。

一般情况下，并行流程和串行流程的各种不同组合构成一个复杂的公文流程，如图2（c）所示。

2.2.2公文流转并行工作流程

传统意义上的纸制公文只有一份，在同一时间只能交给一个人来处理，因此不会有流程分支的情况。公文电子化后，突破了纸制公文只有一份的限制，使流程分支成为可能。但是，公文系统业务要求保留每个处理过程的修改痕迹，如果将同一份电子文档交给多人同时修改，不仅会造成文档修改时的逻辑混乱，也会带来文档的存取问题。同一时间一份文档只能交给一个人处理和修改，某一用户处理和修改文档时，文档是被锁的，其它用户要使用此文档，必须等到该用户处理完毕。针对以上问题，本文提出了文档版本的思想来实现公文流转中的并行工作。

用户A对公文拟稿后，点击提交按钮，进入公文流转流程，流程流转到步骤2。此时，系统自动在工作流表中插入一条记录，FLOW_STATE状态为1，表示流程正在流转，公文电子文档被保存到公文文档表中。同时在工作流步骤表中插入步骤1和步骤2两条记录：步骤1为文件起草，FLOWSTEPS_STATE为2，表示公文已处理；步骤2为B处理过程，FLOWSTEPS_STATE为1，表示公文待处理。在工作流人员表中插入对应步骤1和步骤2的两条记录：步骤1的执行者为A，FLOWPERSON_OPTION字段为提交；步骤2的执行者为B， FLOWPERSON_OPTION字段为未知，表示还未处理。在工作流事件表中插入步骤1的执行事件，事件为提交。流程流转到步骤2后，B用户可选择的事件有同意、退还、否决。如果B用户同意，则流程进入步骤3，在工作流步骤表中插入步骤3的记录，同时把步骤2的状态改为2，步骤3的状态标为1。在工作流人员表中插入步骤3的执行者记录为C，同时更改B的FLOWPERSON_OOPTION为提交。如果用户B退还，则流程回到步骤1，同时删除步骤1后的所有记录，把步骤1的状态改为1，表示公文待处理。如果用户B否决，则流程终止流转，并把公文流转表中的FLOW_STATE改为终止。

4.2同一任务多人处理策略

在同一任务多人处理流程中，一个任务可能需要多个执行者参与，没有明确的先后顺序（即并行流程）。某任务的多人处理流程如图6所示。

用户A对公文拟稿后，点击提交按钮，进入公文流转流程，流程流转到步骤2。此时判断出步骤2的任务为两个人处理，在工作流人员表中对应于步骤2插入两条记录，执行者分别为B和C，同时生成文档版本b和文档版本c，存入公文文档表，分别由FLOW_ID、FLOWSTEPD_ID和FLOWPERSONS_ID三个字段进行约束。待用户B和C都提交后，流程流转到步骤3。 D用户综合B和C的修改意见，生成版本d。

4.3系统实现

本文采用以上技术，研制开发了一套以公文流转为核心的办公自动化系统。该系统基于B/S结构，以IIS 为Web服务器。系统的开发平台为ASP. NET，关系数据库为Oracle9i，通过数据模型实现对数据库的访问。系统界面如图7 所示。

5结语

本文提出了一种基于关系数据库的公文流转系统实现方法，采用与其它业务系统相一致的主流数据库将工作流及公文数据存储在结构开放的关系数据库中，大大降低了公文流转系统与其它业务系统集成的复杂度，同时减轻了复杂工作流引擎带给系统的负担。

参考文献：