面向多信息系统互操作性的本体数据库混合模型开发外文翻译资料

 2022-07-31 18:00:00

英语原文共 6 页,剩余内容已隐藏,支付完成后下载完整资料


面向多信息系统互操作性的本体数据库混合模型开发

摘要

公司将要面对的问题是应用程序在信息系统(IS)中的集成以及系统本身与其他信息系统的互连。IS的互操作性使用一种有利于共享信息以获得更好的性能和盈利能力的共同语言构成了他们根据给定模型进行沟通和互操作的能力。[1]

在本文中,我们重申了我们为IS的互操作性提出的模型,它是互连的模型,目的是将IS互联的业务流程同步化。这种同步主要是基于业务流程BPMN(业务流程模型表示法)不同的IS在可执行语言——业务流程执行语言(BPEL)中的转变,这种转变得益于ATL(ATLAS转换语言)语言,将所有BPEL整合到一个全球BPEL中,以作为适应规则和本体数据库的基础。然后使用逆向工程,对不同IS的流程BPMN进行更新使其适应性更强。

这个架构的关键是使用本体数据库。我们在这篇文章中提出了一个新的本体数据库混合模型,基于本体存储架构的两种方法,我们可以从数据库系统到本体论(BDBO)的比较研究的分析结果中创造出不同的方法。这种分析已经帮助我们采用了拥有自己的架构和存储模型的BDBO的混合模型。我们正在采用这种混合模型来实现几个信息系统的互操作性模型。

关键词:互操作性,信息系统,BPMN,BPEL,逆向工程,ATL,本体论,BDD,本体存储,数据库,方法,形式主义,混合模式

介绍

在信息学中,数据的利用不再是在机器中对信息盲目处理,而是让系统和用户之间进行对话。那么,一般而言,系统不仅能够访问人类使用的术语,还必须访问与他们相关联的语义,以确保有效和可能的沟通。本体论是各社区的热门搜索问题。[2]

数据存储系统(数据库和数据仓库)及其行业在当今表现非常丰富。因为它们允许管理任何公司最昂贵的资本:数据。[2]

在工业和学术界本体出现的地方,什么是管理本体论的需要。IS的互操作性基本上是基于数据交换,用于共享数据是不够的,但也必须知道其语义。通过本文,我们向您介绍已经用于开发互操作性模型的方法,该模型中的流程利益相关者和最重要的部分是在实现我们的互操作性模型期间将要使用的BDBO混合模型的呈现。[3]

本部分分析了BDBO的比较研究结果,导致采用这种混合动力模型具有巨大的优势。

I.在互操作性模型中使用的方法

2.1.由MDA模型管理的方法

大多数公司遇到的问题是从旧技术迁移到新技术,这需要大量的开发工作,并涉及高昂的迁移成本。解决方案是最大限度地降低这两个参数的成本和开发重复工作,特别是与业务逻辑相关的成本,因为它独立于平台。在这一方面需要MDA方法[4](模型驱动架构)(由模型管理的架构),因为它允许您引入稳定的企业业务逻辑和较不稳定的实现逻辑的分离方法。这种方法是由IDM模型[5]领导的工程的一般背景的一部分,它促进了模型并将其作为开发和IS的中心。[6]

采用这种方法背后的动机是满足减少重新设计已经成为必要的应用程序的任务的需要,特别是计算机技术的发展,因为模型比代码更耐用。使用MDA方法可以保持需求交易,重用建筑和编码的选择,并确保项目阶段之间的完整性和一致性。开发模式,是MDA的主要原理和核心。

首先分析,然后设计并经过转换实现的代码,会显得连贯和丰富。[7]

2.2 中介人或调解人的方法

通过使用提供通用调解模式的调解员,可以促进信息系统之间的沟通。这使用接口在内部与两个系统进行通信,以及用于对所交换的信息进行建模的中间表示。[8]

调解员是可执行实体形式的组件,其执行调解任务,包括数据的接收和格式化,处理的应用和结果的创建的过程中进行总结,以便将它们路由到其他调解员或其他应用程序进行集成。[9]

在将业务流程BPMN转换为互连的不同信息系统的可执行语言BPEL时,我们使用MDA方法。然后,我们建立一个由BPEL语言组成的可执行语言的通用BPEL,同时考虑到在本体数据库的帮助下处理差异。为了创建最后一个,我们使用中间人的方法来找到可通过逆向工程(逆向工程)转换为业务流程BPMN的可执行语言BPEL Global。[9]

II. IS的互操作性模型中的利益相关者流程

将BPMN模型转换为BPEL模型

业务流程BPMN是一种图形符号,用于对工作流中企业的过程和工作流程进行建模。这种商业模式代表了系统在环境中的远景,而无需考虑系统结构的细节。它阐述了系统应该做什么。 它允许系统的用户了解问题,并有一个词汇的来源,将与其他模型共享。BPMN由业务流程管理计划(BPMNI)开发,现在由对象管理组(OMG)维护。[10]

BPEL模型是一种编程语言,旨在管理在BPMN整个活动中代表BPMN的两个或多个服务之间进行协作的流程编排。正是由于这个原因,它与BPMN最相关联,因为它将占据编排并使其可执行的工作流程。[10]

将BPMN模型转换为语言BPEL的过程需要由模型(MDA)管理的体系结构实现,以便从概念模型转换到源代码可执行文件。要做到这一点,直接从一个模型转移到另一个模型是不能够的,但可以去经历他们的模型。一般来说,转换将输入模型(来源),并提供模型(目标)的输出。这种转变将使我们能够生成一个自动化代码,这将是企业应用程序开发水平所需的相当大的时间。事实上,通过使用MDA方法是预期的目标,其中大多数方法都不被认可。该转换将使用语言ATL进行,该语言允许通过写作通信规则从模型1向基于不同元模型的模型2移动。[10]

图1:根据IDM在可执行代码BPEL中转换模型

有两种类型的转换,模型到模型和模型到文本。在本文中,我们感兴趣的是将模型转换为文本(即将BPMN流程转换为源代码BPEL可执行文件),目的是汇集所有代码BPEL以生成源代码BPEL Global。ATL转换的语言基于元模型的定义,以确保其与其他建模工具的独立性。这种语言的原理是通过使用元模型,特别是构成它的元素从一个模型转移到另一个模型。[10]

B. 全局BPEL

不同信息系统互联的业务流程BPMN的转型使我们走向可执行语言BPEL。这些语言可能同时包含相同的或不同的信息。我们的贡献是将BPEL语言中包含共同元素和差异的全局BPEL语言汇集在一起,通过应用变换规则和特定表达式的帮助来适应数据库本体论。[11]

图2:通过调用本体数据库来开发一个通用的全局BPEL的过程

C.本体数据

我们可以将本体定义为一个概念化的概念,它有助于明确地表示一个域的语义,通过自愿对象的模型,每个概念与通用标识符相关联,以引用与他对应的语义。[12]

我们的方法要求有一个能看到它非常多的优势的本体论数据库。它允许您管理和调整语言BPEL在语言BPEL Global之间的差异。本体还允许通过其概念的定义和管理它们的规则来对区域进行建模。本体的主要原理是确保其重用,确保不同数据源的互操作性。当以本体形式对领域进行建模时,这样可以在同一模型中为这些不同的术语提供一个位置,将每个概念与指定的不同术语相结合。[13]

D.逆向工程

我们的互操作性模型的最后一层要求我们应用校正,对所获得的共同语言进行适应。当流程BPMN到BPEL的转换完成之后,在BPMN信息系统源之前先进行更新,以和流程同步BPMN进行交易。复古工程允许我们借助于技术和转型规则,从其源代码BPEL获取粗体模型。管理知识资本,寻找技术规格,然后查找初始模型的功能和起源,然后进行结构化,形式化和更新。[14]

III.本体概念:概念和形式化

可以将本体设置为概念和属性方面的域的概念化。 本体定义了概念(原理,想法,对象类别,概念,潜在抽象和关系)。[12]

它通常包括这些概念之间存在的相关概念和关系的层次组织,以及强制他们的规则和公理。本体通常是一个术语,它允许你唤起一个图形表示的世界,它允许在程序结构上达成一致。 其应用基本上位于知识基础和语义网的基础之上。[12]

换句话说,本体定义了共享词汇,以达成对给定区域的共同理解。实际上,它包含域中概念的定义和它们之间的关系。它也可能包含我们允许推断新知识的公理和规则。[15]

区分本体中的两种概念,原始概念和定义的概念很重要。原始概念是不能通过定义完全公理定义或表示的概念。定义的概念可以在原始概念的基础上定义。 本体设计的主题已经广泛约束;这就是为什么根据设计目标设计本体的几种形式主义。[12]

一般本体论是一种表示:[12]

正式:以语法和语义形式表达

同意:由社区成员承认

可引用:任何实体或关系由符号(ID)引用

还有其他形式主义允许您定义词汇之间的映射,并提供扣除和推断的机会。他们使用包括概念和非规范概念。对于语义Web,它们将模型存在为DAML,OIl,DAML OIL和Owl,这是推理语言,它们扩展了RDF模式。在Web中表示本体的标准被更多地认可为OWL.OWL的模型是OWL-lite,OWL-DL和OWL-Full的3个版本,它们是填充表达式与其可判定性之间妥协的子模型的推理。[12]

IV.本体存储在数据库中

我们将数据库称为数据库本体(BDBO),该数据源包含本体(本地),本地本体对外部本体的引用,实例的数据集以及每个数据与本体定义意义的概念之间的关系。[16]

由企业解释的本体数据的数量变得越来越重要,需要在数据库中存储本体及其实例。目前有几个本体论的数据库,但它们必须允许根据给定格式存储本体及其实例。 然而,本体论模型和本体论实例可以使用相同的存储格式存储在一起,或者单独使用不同的格式存储在一起。[16]

V.本体存储模式:

方法:它允许您通过一个具有三列的表来表示本体,每个类都有一个表。 这些列分别表示:资源本体的ID,资源的名称和该资源的值。 这种表示的优点在于它有助于插入新的三元组,尽管他的询问是复杂的,因为它可能需要多次自联接的操作,这可能变得非常昂贵。Oracle的BDBO使用这种表示来表示本体的实例。[12]

图3:垂直方法的表示[16]

水平方法:它呈现由关系DBMS使用的相同的传统表示。BDBO OntoDB使用这种方法来表示其本体论模型以及这些实例。[16]

二进制方法:根据代表采用的方法有三种变体:本体中所有类的单个表,每个表的表与表的遗产和不具有表的遗产的类的表。有BDBO组合这些方法,所谓的混合方法,我们将采用接口模型和适应互操作性的几个IS。[12]

VI.选择混合存储架构的标准(性能)

根据基于三个特定DBMS Oracle,SOR和OntoDB上建立的数据库系统到本体论基础的比较研究的分析,根据两个标准:本体实例的加载时间和查询的执行时间。该性能研究是基于BDBO中本体及其实例的加载;它是通过一系列实验进行的,以评估研究的DBMS。它是基于这项研究,得出结论,两个Oracle DBMS OntoDB是最符合两个标准的表现评估。[15]

在本节中,我们向您介绍性能研究的结果:

5.1在数据加载(本体和实例)方面的性能:

为了在BDBO中测量本体及其实例的载入性能,该测量的操作员模式总结为4点:数据的生成,文件中这些数据的转换和连接,每个BDBO中的加载时间(秒)实例的计算和结果的解释。[12]

在加载方面,Oracle提供了非常好的结果,其次是SOR,OntoDB显示缓慢。 对于Oracle,可以通过对插入数据执行少量操作来解释这一点。SOR翻译所需的时间是必须的。 OntoDB发现的缓慢是由大多数实例插入请求中存在的多个Sub查询来解释的。[12]

图4:查询执行时间[12]

5.2在查询响应时间方面的表现:

根据我们受到启发的研究,请求的执行时间在三个本体中被测量了几秒钟。关于响应请求方面的表现,OntoDB比Oracle和SOR做出的反应更好。甲骨文排在第二位,其次是SOR,这是慢的,因为他为所有查询实现了几个连接。相比之下,SOR实现了一个很好的扣除工作。

VII.基于混合方法的数据库选择:

近年来,本体论在几个方面发生了重大变化,因此产生对这些本体的存储的强烈需求。学者和实业家提出了依赖于现有数据库管理系统的持久性解决方案,从而在确保大量的数据的同时有效地管理和轮询数据。在这个事实上,出现了几种对实例和本体论类和架构的专用存储的形式和模型。[17]

根据本研究的分析结果,我们发现,为了发展我们的几种信息系统互操作性的接口和适应性模型,我

全文共6680字,剩余内容已隐藏,支付完成后下载完整资料


资料编号:[142687],资料为PDF文档或Word文档,PDF文档可免费转换为Word

原文和译文剩余内容已隐藏,您需要先支付 30元 才能查看原文和译文全部内容!立即支付

以上是毕业论文外文翻译,课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。