CN106844693A - 一种openEHR Template到关系数据库的转换方法 - Google Patents
一种openEHR Template到关系数据库的转换方法 Download PDFInfo
- Publication number
- CN106844693A CN106844693A CN201710059819.9A CN201710059819A CN106844693A CN 106844693 A CN106844693 A CN 106844693A CN 201710059819 A CN201710059819 A CN 201710059819A CN 106844693 A CN106844693 A CN 106844693A
- Authority
- CN
- China
- Prior art keywords
- attribute
- template
- field
- name
- openehr
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/284—Relational databases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
- G06F16/2282—Tablespace storage structures; Management thereof
Abstract
本发明公开了一种openEHR Template到关系数据库的转换方法,包括以下步骤:解析openEHR原型并建立原型对象模型;对原型对象模型进行约束,建立模板对象模型;生成符合JPA规范的实体对象;将实体对象映射成具体的数据库表;解析输入的AQL语句,生成数据库表操作语句;运行数据库表操作AQL语句得到相应的数据操作结果;生成新的数据结果dADL文件并返回给调用方。本发明通过openEHR模板构建出对应数据库表存储数据,使每个openEHR模板实例的数据存储于对应的数据库表中,实现了数据分散存储,使数据访问可以针对特定的数据库表进行,从而提高了数据访问的性能,能够满足实际医疗业务的需求。
Description
技术领域
本发明涉及数据库信息技术领域,特别涉及医疗信息的数据库存储技术,具体为一种openEHR Template到关系数据库的转换方法。
背景技术
医学信息领域具有高度的复杂性和动态性。复杂性表现在医学信息概念繁多,人体是最复杂的系统之一,有关人体和人体健康的概念及概念之间的相互关系构成了一类最复杂的概念网。现代医学高度发达,已经获取了大量关于健康、疾病、诊疗、研究的信息,构成了一个超大的概念集合,精细的临床专科分工和多样的诊疗技术以及信息技术的应用在医疗过程中产生了大量多种多样的医疗信息需要记录、存储、分析和利用。动态性表现在现代医学的迅速发展,导致医学知识动态更新,信息广度不断扩张,如新的诊断方法不断出现,导致新的信息类别持续增加,信息深度不断加深,如医疗研究进步和信息获取能力增强,导致各类信息的细节特征持续增加,信息复杂度不断升高,如信息交叉研究的分析挖掘的进展,各种信息之间的关系持续增加。面对医疗信息的复杂性和动态性,传统信息建模和系统构建方法已经不能适应,将医疗信息中动态更新的部分和稳定不变的部分分离表达的分层建模方法逐渐成为主流的方法。
openEHR规范进一步明确了分层建模的概念。openEHR规范是由欧洲openEHR机构提出的一套开放的电子病历体系结构规范,其目标是实现电子病历系统内部以及电子病历系统之间的健康信息共享。欧洲标准化委员会(CEN)已经将openEHR规范的一个子集作为标准通过(CEN 13606)。在国外,openEHR规范已经被积极应用于各种研究和商业活动,澳大利亚、瑞典、英国、美国等国家相继开展各种openEHR规范研究和实施项目,并开发了多种用于支持openEHR实施的工具。例如,澳大利亚Ocean Informatics公司开发了一系列基于openEHR规范的产品;瑞典大学Rong Chen等人组织开展了openEHR Java参考实施项目,目标是实现完整的参考模型和原型对象模型,并支持基于原型的对象生成和验证;日本Akimihci Tatsukawa等人开展了openEHR Ruby实施项目。
openEHR采用分层方法对医学知识和概念进行描述,包括参考模型(RM),和原型模型(AM),原型模型由原型(Archetype)和模板(Template)组成。参考模型定义了一组表达医学知识和概念的通用基础数据类型和数据结构,原型通过对参考模型添加约束来描述每个具体的医学知识和概念,模板根据实际应用需求对原型进一步添加约束来描述具体的数据需求。
openEHR规范主要解决医学知识和数据需求不断变化导致的信息系统维护和更新的问题。通过分层方法,信息系统基于稳定不变的参考模型建立,医学知识和数据需求通过原型和模板表达。当医学知识和数据需求发生变化的时候,通过修改和制定新的原型和模板来表达变化的部分,信息系统通过解析原型和模板实现功能的变化,而不用进行修改。
目前,对基于openEHR规范进行信息存储的方法研究众多。openEHR官方机构公布了一种属性+路径(Node+Path)方法。openEHR原型具有与XML格式相似的结构,每个原型属性(Node)具有唯一的路径(Path)标识。根据这一特性,可构建一张包含有限字段的数据库表,其中包括原型属性路径字段,原型属性取值字段,原型名字段,以及原型实例标识字段。这样一张数据库表可以存储所有openEHR原型实例的数据。
属性+路径方法的数据访问可以通过特定的原型实例进行。利用原型名、原型实例标识和原型属性路径构造SQL语句,可以逐个针对一个原型实例在数据库中存储的所有属性值进行操作。
当医学知识变化时,对应会产生新原型,新原型与原有原型一样,实例数据按照属性+路径的方式存储到数据库中,数据访问通过原型实例进行。这种数据存储方法可以实现适应知识动态变化的效果,不会对数据访问者产生影响。
2010年CAIS JAIIO会议上发表的一篇论文《Traumagen:historia clínicaelectrónica con acceso a estudios radiológicos digitales especializada en laatención de pacientes gravemente traumatizados》提出了一种参考模型对象关系映射(ORM)方法。参考模型是一组表达医学知识和概念的通用基础数据类型和数据结构,原型是通过对参考模型添加约束的方式进行定义,大部分的原型都是从少数固定的几个参考模型类派生,如表示临床观察结果的Observation类,临床评估结果的Evaluation类,临床计划的Instruction类,临床执行过程的Action类。将参考模型通过对象关系映射方法构建出一组对应的数据库表,能够达到存储所有openEHR原型实例数据的目的。
数据访问可以通过操作原型对应的参考模型类生成的数据库表进行。通过解析原型可以获得原型派生的参考模型类,利用原型派生的参考模型类,通过ORM方法可以对这个原型派生的参考模型类对应的数据库表进行数据操作。
当医学知识变化时,对应会产生新原型,新原型也是从少数固定的参考模型类派生,新原型的实例数据可以存储到参考模型类对应的数据库表中,数据访问通过ORM方法操作原型实例派生的参考模型类对应的数据库表进行。这种数据存储方法可以实现适应知识动态变化的效果,不会对数据访问者产生影响。
在上述两种方法中,通过有限的数据库表存储全部openEHR原型实例所表达的电子病历数据,将导致数据集中于少量数据库表,数据访问性能大大降低,无法满足实际医疗业务的需求。
《 Electronic Articles on Academic Policies and Trends》杂志2012年卷070发表了一篇名为《Performance of XML Databases for EpidemiologicalQueries in Archetype-Based EHRs》的论文,提出了使用XML数据库存储openEHR规范信息的方法,并进行了详细的评估。论文结论指出,XML数据库在效率方面远远不及关系型数据库,无法满足实际医疗业务的需求。
发明内容
本发明提供了一种openEHR Template到关系数据库的转换方法,解决了现有openEHR标准数据存储实现方法效率低,性能无法满足实际医疗环境业务需求的问题。
一种openEHR Template到关系数据库的转换方法,所述openEHR Template包括openEHR原型、openEHR模板,所述openEHR Template对应有原型查询语言AQL的语法规范,所述转换方法包括以下步骤:
(1)解析openEHR原型并建立原型对象模型;
(2)解析openEHR模板,并利用该解析结果对步骤(1)建立的原型对象模型进行约束以生成模板对象模型;
(3)通过步骤(2)所述模板对象模型结合预设的映射配置文件生成符合JPA规范的实体对象;
(4)通过对象关系映射框架将步骤(3)生成的实体对象映射为关系数据库表,并提取模板对象模型与数据库表的映射关系;
(5)根据所述语法规范编写语法树文件,通过所述语法树文件解析输入的AQL语句以提取表达式,所述的操作信息包括操作数和操作数之间的关系,结合步骤(2)生成的模板对象模型和步骤(4)映射得到的关系数据库表生成数据库表操作语句;
(6)针对步骤(4)生成的关系数据库表,根据调用方需求运行步骤(5)生成的数据库表操作语句得到相应的数据操作结果;
(7)将所述数据操作结果生成数据结果dADL文件;
(8)将所述数据结果dADL文件返回给调用方。
本发明的openEHR Template到关系数据库的转换方法对每个openEHR模板进行单独解析,并构建相应的数据库表,每个openEHR模板的数据存储在独立的数据库表中,实现了数据的分散存储,数据访问性能大大提高,且当医学知识变化时,生成新的对应的数据库表,可实现系统动态适应知识变化。
所述步骤(1)解析openEHR原型并建立原型对象模型包括:
解析原型名;
解析基本类型属性的属性名、数据类型、数据长度;
解析集合类型属性的属性名、集合容纳的数据类型;
解析archetype slot类型属性的属性名、目标原型名。
基本类型、集合类型以及archetype slot类型均为Archetype中的基础数据类型。
所述步骤(2)对原型对象模型进行约束生成模板对象模型包括:
解析openEHR模板中的根原型及根原型中的Items元素下的Rule节点;
如果openEHR模板中根原型包括子原型,则继续解析子原型及子原型包括的Items元素下的Rule节点;
通过解析Rule节点中的path属性来唯一确定原型对象模型中的属性,并通过max属性来决定该属性是否映射成关系数据库表中的字段;
每个openEHR模板转换为一族数据库表,数据库表名为模板名称;针对确定的原型对象模型中的属性进行如下操作:
如果是基本类型属性,每个属性转换为一个数据库表字段,字段名为属性名,字段类型为属性数据类型,字段长度为属性数据长度;
如果是集合类型属性,每个属性转换为一个单独的集合类型属性数据库表,数据库表名为“模板名_集合类型属性名”,集合类型属性数据库表包括主键字段,字段名为“模板名_集合类型属性名”,字段类型为整型自增,关联到模板对应的数据库表的外键字段,字段名为模板名,字段类型与模板对应的数据库表主键字段类型相同,集合类型属性对应的字段,字段名为集合类型属性名,字段类型为集合类型属性数据类型,字段长度为集合类型属性数据长度;
如果是archetype slot类型属性,每个属性转换为单独的archetype slot类型属性数据库表,数据库表名为“模板名_archetype slot属性名”,archetype slot数据库表包括主键字段,字段名为“模板名_集合类型属性名”,字段类型为整型自增,关联到模板对应的数据库表的外键字段,字段名为模板名,字段类型与模板对应的数据库表主键字段类型相同,archetype slot类型属性对应的字段,字段名为“archetype slot类型属性名”,并关联到目标模板对应的数据库表。
所述步骤(3)将模板对象模型结合映射配置文件生成符合JPA规范的实体对象包括:
确定实体对象中字段的命名规则,并按照命名规则对实体对象进行命名并从中确定主实体对象;
根据原型对象模型中的属性分别将各个属性映射为相应的实体对象,具体如下:
集合类型属性或者Archetype Slot类型属性映射为一个新的实体对象,且若属性的occurrence上限为*,则映射为一对多关系两个实体对象中的多端对象,该属性所在的实体对象为一端对象,该属性下的所有属性映射为多端对象的字段,多端对象存储一端对象的主键作为外键;如果属性的occurrence上限为1,则映射为一个可嵌入的实体对象,同时该属性所在的实体对象增加一个类型为该可嵌入实体对象的字段;
为各个实体对象生成一个GUID字段作为主键,用来唯一标识各个实体对象的实例;
映射配置文件主要对映射生成的实体对象的字段属性进行额外配置,所述额外配置包括是否为主键、是否添加索引、是否唯一、是否允许为空、是否可传递、字段类型及长度。
作为优选,所述实体对象的字段的命名规则如下:将属性的路径值转换为实体对象的字段的字段名,将路径值中所有属性ID对应的Ontology值按照先后顺序用“_”连接作为字段名。
例如:将路径值中所有属性ID对应的Ontology值按照先后顺序用“_”连接作为字段名,如将上述路径中的at0001对应的Order、at0002对应的Tree、at0003对应的Medicine用“_”连接得到Order_Tree_Medicine。通过该方法生成的字段名简单易懂,同时又可以保证字段名的唯一性,不会出现重复。
一个模板对象模型最终会映射成一个或多个实体对象,且每个模板对象模型都对应一个主实体对象,名称为“模板的Entity类型名_模板概念名”。即按照上述映射规则,一个模板将映射成具有树状结构(根据一对多关系)的多个实体对象。
映射配置文件主要对映射生成的数据库字段属性进行一些额外的配置,包括是否为主键、是否添加索引、是否唯一、是否允许为空、是否可传递、字段类型及长度。
所述步骤(4)通过成熟的对象关系映射框架将步骤(3)生成的实体对象映射为具体的关系数据库表:通过应用成熟的对象关系映射框架,例如Hibernate将实体对象映射成数据库表,由于实体对象是完全符合JPA规范的,所以对于所有实现JPA规范的框架都可以用来生成数据库表,将模板对象映射和对象关系映射完全解耦。
所述步骤(5)中结合步骤(2)生成的模板对象模型和步骤(4)映射得到的关系数据库表生成数据库表操作语句具体包括:
判断模板对象模型中是否包含所提取的表达式:
如果存在:则根据模板对象模型与数据库表的映射关系确定与提取出的表达式相对应的关系数据库表以及相应的关系数据库表字段,并根据相应表达式中各操作数之间的关系拼接即得到数据库表操作语句;
如果不存在,则不操作。
本发明中,步骤(5)通过语法解析将AQL语句分解成带有语义的不同部分(即表达式),供后续使用。通过开源的语法分析器——ANTLR(Another Tool for LanguageRecognition)针对openEHR Template对应有原型查询语言AQL的语法规范设计出AQL的语法文件,用AQL语法文件生成具体的解析代码对输入的AQL语句(即用户输入的AQL语句)进行解析,以提取用户输入的AQL语句中的表达式,该表达式实际上也可以理解为一颗描述用户输入的AQL语句的抽象语法树。
本发明中通过所述语法树文件解析输入的AQL语句具体包括:
1)模板名称(指AQL中携带的)是否存在于映射关系中;
2)变量(代表模板名称的别名)使用是否正确;
3)模板中节点的路径是否存在;
4)模板中节点的路径的值类型是否匹配。
同SQL类似,该AQL语句实现了select、insert、update和delete操作,每个模板中的AQL命令转换为一个对应的数据库表操作SQL语句。
SELECT语句由SELECT、FROM和WHERE三部分组成,SELECT部分通过路径指定返回的具体属性,FROM部分指定查询的模板名,不再包含CONTAINS部分,WHERE部分指定筛选的条件。
INSERT语句由INSERT INTO和VALUES两部分组成,INSERT INTO部分指定需要创建实例的模板名,VALUES部分对新建的模板实例的属性赋值,格式为“路径=值”。
UPDATE语句由UPDATE、SET和WHERE三部分组成,UPDATE部分指定需要更新实例的模板名,SET部分对指定的属性进行更新,格式为“路径=值”,WHERE部分指定筛选的条件。
DELETE语句由DELETE、FROM和WHERE三部分组成,DELETE部分指定删除的属性,如果没有指定属性则表示删除整个实例,FROM部分指定查询的模板名,不再包含CONTAINS部分,WHERE部分指定筛选的条件,与AQL的WHERE部分一致。当DELETE关键字后面有路径值,表示从数据库中筛选出符合条件的模板实例,并删除其中指定的属性;DELETE关键字后面无路径值,表示从数据库中筛选出符合条件的模板实例并删除整个实例。
所述步骤(7)将数据操作结果生成数据结果dADL文件包括:
将每个关系数据库表转换为一类模板实例,每个关系数据库表记录转换为一个模板实例,根据关系数据库表名查找对应模板名,根据字段名找到对应属性名。
所述openEHR Template到关系数据库的转换方法中原型名的构造方法为模板namespace.原型对应参考模型类.原型领域概念.版本号;
所述openEHR Template到关系数据库的转换方法中属性名的构造方法为/根父属性编码/…/父属性编码/属性编码,属性编码格式为“at”+四位数字,如果属性编码不存在,用属性名替代。
与现有技术相比,本发明的有益技术效果为:
(1)通过openEHR模板构建出对应数据库表存储数据,从而使每个openEHR模板的数据存储于对应的数据库表中,实现了数据分散存储,使数据访问可以针对特定的数据库表进行,从而提高了数据访问的性能,能够满足实际医疗业务的需求;
(2)当医学知识变化时,导致新的原型产生,或者临床需求发生变化时,导致模板对原型的约束条件发生改变,而不必要修改原型本身。本方法可自动针对新原型或者新的模板生成对应数据库表存储新的实例数据,针对新原型制作的模板可以访问新原型对应的数据库表,新的模板也可以访问原来的原型对应的数据库表,可实现系统动态适应知识变化。
附图说明
图1为本发明提供的一种openEHR Template到关系数据库的转换方法流程图;
图2为本发明解析openEHR原型并建立原型对象模型详细流程图;
图3为本发明通过对openEHR原型对象模型进行约束并建立模板对象模型的详细流程图;
图4为本发明生成符合JPA规范的实体对象的详细流程图;
图5为本发明将实体对象映射为具体的关系数据库表的详细流程图;
图6为本发明解析语法树生成原型查询语言AQL,进而生成数据库表操作语句的详细流程图;
图7为本发明根据数据操作结果生成数据结果dADL文件详细流程图。
具体实施方式
图1为本发明中openEHR Template到关系数据库的转换方法的流程图,下面结合图与具体实施例进一步阐释本发明。
其中,步骤S101为解析openEHR原型并建立原型对象模型。
图2示出了本发明步骤S101中解析openEHR原型并建立原型对象模型的详细流程为:S201读取openEHR原型文件;S202解析原型名;S203判断是否是基本类型属性:如果是基本类型属性,则进行如下操作:S204解析基本类型属性的属性名,S205解析基本类型属性的数据类型,S206解析基本类型属性的数据长度;如果不是基本类型属性,则继续执行S207,判断是否为集合类型属性;如果是集合类型属性,则执行S208解析集合类型属性的属性名,S209解析集合容纳的数据类型;如果是集合类型属性则执行S210,判断是否是archetypeslot类型属性,如果是archetype slot类型属性,则执行S211解析archetype slot类型属性的属性名,S212解析archetype slot类型属性的目标原型名。
表1给出了一病人的openEHR原型;
表2给出了一病人就诊记录的openEHR原型。
分别对表1和表2给出的openEHR原型进行解析并建立原型对象模型,结果见表3和表4。
表1
表2
表3
表4
图1中的步骤S102解析openEHR模板,并利用该解析结果对步骤(1)建立的原型对象模型进行约束以生成模板对象模型。
图3示出了本发明通过对原型对象模型进行约束并建立模板对象模型的详细流程包括:S301,读取openEHR模板文件;S302验证模板文件,具体指验证读取的openEHR模板文件和原型文件是否一致;S303:解析definition元素:验证该模板文件(指openEHR模板文件)中的definition元素,从其中获取模板文件要约束的原型名称;S304读取Rule元素,用来约束原型对象模型中的属性,S305获得Rule元素中的path属性来唯一确定原型对象模型中的属性,而max属性则用来确定该属性根据实际需求是否出现和最多出现多少次;S306判断是否definition元素中是否有Items元素,该元素是对archetype slot类型的属性的支持,代表slot的子原型;S307则是根据S306的执行结果解析子原型的原型名称之后按照处理根原型的方式获取Rule元素和Items元素,即递归的检索所有的子原型。
表5给出了一病人入院记录的解析openEHR模板并建立模板对象模型的实例。
表5
图1中,步骤S103通过模板对象模型结合预设的映射配置文件生成符合JPA规范的实体对象。
图4示出了本发明结合映射配置文件生成符合JPA规范的实体对象详细流程包括:
S401建立参考模型与实体对象字段类型的映射;
参考模型的定义出于完整性考虑包含了数据的全部信息,但这些信息在存储或者交换过程中往往不是必须的。因此为了避免在生成的实体对象中存在过多无用的字段,只对参考模型的部分属性进行了映射,例如DV_BOO‘’LEAN、DV_DATE、DV_IDENTIFIER、DV_TEXT、DV_COxDED_TEXT等;
S402确定实体对象字段命名规则;
模板对象映射将模板的属性映射为实体对象的字段。在模板中,属性通过路径值来唯一标识该属性。在实体对象中,字段则通过字段名来唯一标识该字段。因此,在模板对象映射过程中,需要将属性的路径值转换为字段的字段名,将路径值中包含的所有属性ID对应的Ontology值组合作为字段名,把路径值中所有属性ID对应的Ontology值按照先后顺序用“_”连接作为字段名,如将路径值/activities[at0001]/description[at0002]/items[at0003]/value/value中的at0001对应的Order、at0002对应的Tree、at0003对应的Medicine用“_”连接得到Order_Tree_Medicine。通过该方法生成的字段名简单易懂,同时又可以保证字段名的唯一性,不会出现重复;
S403确定模板的主实体类,每个模板只生成一个主实体类;
S404判断集合类型属性是否存在:
若存在集合类型属性,则进行如下操作:
S405确定模板的主实体类,确定模板中的集合类型属性,该属性映射成一个新的实体对象;
S406解析Occurrence,确定实体对象的类型,指定该生成的实体对象的名称,命名规则为“该属性所在的实体对象名_属性Ontology值”;
S407生成GUID唯一表示该实体对象;
S408根据映射配置文件而配置集合类型属性的映射信息,然后执行S409,判断archetype slot类型属性是否存在;
若不存在集合类型属性,则执行S409,判断archetype slot类型属性是否存在:
若archetype slot类型属性不存在,则直接完成;
若archetype slot类型属性存在,则进行如下操作:
S410,确定模板中的archetype slot类型的属性类名,该属性也映射成一个新的实体对象;
S411解析Occurrence,确定实体对象的类型,
S412,生成GUID唯一表示该实体对象;
S413,根据映射配置文件而配置集合类型属性的映射信息。
S406和S410指定该生成的实体对象的名称,命名规则是“该属性所在的实体对象名_属性Ontology值”,并在末尾增加“$Slotted Archetype概念名”。
S406和S419解析集合类型或者archetype slot属性中的occurrence,如果该属性的occurrence上限为*,则映射为一对多关系两个实体对象中的多端对象,该属性所在的实体对象为一端对象,该属性下的所有属性映射为多端对象的字段,多端对象存储一端对象的主键作为外键。
如果该属性的occurrence上限为1,则映射为一个可嵌入的实体对象,同时该属性所在的实体对象增加一个类型为该可嵌入实体对象的字段;S404、S408和S413为主实体对象和每个多端实体对象均自动生成一个GUID字段作为主键,用来唯一标识实体对象的实例。
S409和S414根据映射配置文件配置集合类型和archetype slot类型属性的映射信息,由于原型和模板无法精确控制生成的数据库结构到具体的数据库字段属性,模板关系配置文件(即映射配置文件)主要对映射生成的数据库字段属性进行一些额外的配置,包括是否为主键、是否添加索引、是否唯一、是否允许为空、是否可传递、字段类型及长度、模板中Link属性指定被连接的模板和属性路径等。
表6
图1中,步骤S104通过对象关系映射框架将步骤(3)生成的实体对象映射为关系数据库表,并提取模板对象模型与数据库表的映射关系。
图5示出了本发明将实体对象映射成具体的数据库表详细流程包括:
S501序列化实体类生成源代码文件;
实体类的信息存储在JavaClass类中,通过解析该类的实例来生成模板对应的实体类源代码信息,该信息保存在内存中。
S502动态编译实体类生成字节码文件;
通过编译器在内存中编译实体类信息生成字节码文件,该文件存储了模板的全部映射信息。
S503使用成熟的对象关系映射框架来完成实体类到关系型数据库中的映射;
由于该实体类符合JPA规范,所以只要实现该规范的任何ORM框架都可以完成此工作。
图1中,步骤S105根据所述语法规范编写语法树文件,通过所述语法树文件解析输入的AQL语句以提取表达式,所述的操作信息包括操作数和操作数之间的关系,结合步骤(2)生成的模板对象模型和步骤(4)映射得到的关系数据库表生成数据库表操作语句。
图6示出了本发明通过解析语法树,根据模板对象模型和关系数据库表生成数据库表操作语句的详细流程包括:
设计AQL语法,实现数据库表操作,包括select(即select类型语句)、insert(即insert类型语句)、update(即update类型语句)和delete(即delete类型语句)。
对于select类型语句,S604说明select部分通过路径来唯一确定具体的属性,S605说明from部分指定要进行查询的模板名,S606说明where部分指定筛选的条件,该部分目前支持and、or和类似SQL中的in的match操作;
对于delete类型语句,S608说明DELETE部分指定删除的属性,DELETE关键字后面有路径值,表示从数据库中筛选出符合条件的模板实例,并删除其中指定的属性,DELETE关键字后面无路径值,表示从数据库中筛选出符合条件的模板实例并删除整个实例,S609说明from部分指定要进行删除操作的模板,S610部分指定where部分中的筛选条件;
对于insert类型语句,S612说明INSERT INTO部分指定需要创建实例的模板名,S613说明from部分指定的要插入数据的模板;
对于update类型语句,S615说明UPDATE部分指定需要更新实例的模板名,S616SET部分对指定的属性进行更新,S617WHERE部分指定筛选的条件。
表7为通过病人号查询病人的基本信息的数据库表操作AQL语句生成实例。
表7
图1中,步骤S106针对步骤(4)生成的关系数据库表,根据调用方需求运行步骤(5)生成的数据库表操作语句得到相应的数据操作结果。
图1中,步骤S107为根据数据操作结果生成数据结果dADL文件。
图7示出了本发明根据数据操作结果生成数据结果dADL文件详细流程包括:
S701,读取数据操作结果;
对于SELECT查询操作,返回的结果数据为具体的模板实例数据。openEHR规范定义了dADL的语法用于表达模板实例数据,可以分为ADL和XML两种形式。ADL形式的模板实例数据在使用时需要进行解析和数据的绑定,速度较慢,而XML形式的模板实例数据解析相对较快,并且可以通过转换模板路径为XPath路径来直接访问数据。
S702,转换数据操作语句中的路径值;
将操作数据库提供的路径值转换成xpath路径,用于唯一的标识该数据,如o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value
可以转换为以下的XPath路径:
o/data[@archetype_node_id=’at0001’]/events[@archetype_node_id=’at0006’]/data
[@archetype_node_id=’at0003]/items[@archetype_node_id=’at0004]/value。
S703输出为dADL文件。
图1中,步骤S108为返回数据结果dADL文件给调用方。
综上所述,本发明通过openEHR模板构建出对应数据库表存储数据,从而使每个openEHR模板实例的数据存储于对应的数据库表中,实现了数据分散存储,使数据访问可以针对特定的数据库表进行,从而提高了数据访问的性能,能够满足实际医疗业务的需求。
Claims (8)
1.一种openEHR Template到关系数据库的转换方法,所述openEHR Template包括openEHR原型、openEHR模板,所述openEHR Template对应有原型查询语言AQL的语法规范,其特征在于,所述转换方法包括以下步骤:
(1)解析openEHR原型并建立原型对象模型;
(2)解析openEHR模板,并利用该解析结果对步骤(1)建立的原型对象模型进行约束以生成模板对象模型;
(3)通过步骤(2)所述模板对象模型结合预设的映射配置文件生成符合JPA规范的实体对象;
(4)通过对象关系映射框架将步骤(3)生成的实体对象映射为关系数据库表,并提取模板对象模型与数据库表的映射关系;
(5)根据所述语法规范编写语法树文件,通过所述语法树文件解析输入的AQL语句以提取表达式,所述的操作信息包括操作数和操作数之间的关系,结合步骤(2)生成的模板对象模型和步骤(4)映射得到的关系数据库表生成数据库表操作语句;
(6)针对步骤(4)生成的关系数据库表,根据调用方需求运行步骤(5)生成的数据库表操作语句得到相应的数据操作结果;
(7)将所述数据操作结果生成数据结果dADL文件;
(8)将所述数据结果dADL文件返回给调用方。
2.如权利要求1所述的openEHR Template到关系数据库的转换方法,其特征在于,所述步骤(1)解析openEHR原型并建立原型对象模型包括:
解析原型名;
解析基本类型属性的属性名、数据类型、数据长度;
解析集合类型属性的属性名、集合容纳的数据类型;
解析archetype slot类型属性的属性名、目标原型名。
3.如权利要求1所述的openEHR Template到关系数据库的转换方法,其特征在于,所述步骤(2)对原型对象模型进行约束生成模板对象模型包括:
解析openEHR模板中的根原型及根原型中的Items元素下的Rule节点;
如果openEHR模板中根原型包括子原型,则继续解析子原型及子原型包括的Items元素下的Rule节点;
通过解析Rule节点中的path属性来唯一确定原型对象模型中的属性,并通过max属性来决定该属性是否映射成关系数据库表中的字段;
每个openEHR模板转换为一族数据库表,数据库表名为模板名称;针对确定的原型对象模型中的属性进行如下操作:
如果是基本类型属性,每个属性转换为一个数据库表字段,字段名为属性名,字段类型为属性数据类型,字段长度为属性数据长度;
如果是集合类型属性,每个属性转换为一个单独的集合类型属性数据库表,数据库表名为“模板名_集合类型属性名”,集合类型属性数据库表包括主键字段,字段名为“模板名_集合类型属性名”,字段类型为整型自增,关联到模板对应的数据库表的外键字段,字段名为模板名,字段类型与模板对应的数据库表主键字段类型相同,集合类型属性对应的字段,字段名为集合类型属性名,字段类型为集合类型属性数据类型,字段长度为集合类型属性数据长度;
如果是archetype slot类型属性,每个属性转换为单独的archetype slot类型属性数据库表,数据库表名为“模板名_archetype slot属性名”,archetype slot数据库表包括主键字段,字段名为“模板名_集合类型属性名”,字段类型为整型自增,关联到模板对应的数据库表的外键字段,字段名为模板名,字段类型与模板对应的数据库表主键字段类型相同,archetype slot类型属性对应的字段,字段名为“archetype slot类型属性名”,并关联到目标模板对应的数据库表。
4.如权利要求1所述的openEHR Template到关系数据库的转换方法,其特征在于,所述步骤(3)将模板对象模型结合映射配置文件生成符合JPA规范的实体对象包括:
确定实体对象中字段的命名规则,并按照命名规则对实体对象进行命名并从中确定主实体对象;
根据原型对象模型中的属性分别将各个属性映射为相应的实体对象,具体如下:
集合类型属性或者Archetype Slot类型属性映射为一个新的实体对象,且若属性的occurrence上限为*,则映射为一对多关系两个实体对象中的多端对象,该属性所在的实体对象为一端对象,该属性下的所有属性映射为多端对象的字段,多端对象存储一端对象的主键作为外键;如果属性的occurrence上限为1,则映射为一个可嵌入的实体对象,同时该属性所在的实体对象增加一个类型为该可嵌入实体对象的字段;
为各个实体对象生成一个GUID字段作为主键,用来唯一标识各个实体对象的实例;
映射配置文件主要对映射生成的实体对象的字段属性进行额外配置,所述额外配置包括是否为主键、是否添加索引、是否唯一、是否允许为空、是否可传递、字段类型及长度。
5.如权利要求4所述的openEHR Template到关系数据库的转换方法,其特征在于,所述实体对象的字段的命名规则如下:将属性的路径值转换为实体对象的字段的字段名,将路径值中所有属性ID对应的Ontology值按照先后顺序用“_”连接作为字段名。
6.如权利要求1所述的openEHR Template到关系数据库的转换方法,其特征在于,所述步骤(5)中结合步骤(2)生成的模板对象模型和步骤(4)映射得到的关系数据库表生成数据库表操作语句具体包括:
判断模板对象模型中是否包含所提取的表达式:
如果存在:则根据模板对象模型与数据库表的映射关系确定与提取出的表达式相对应的关系数据库表以及相应的关系数据库表字段,并根据相应表达式中各操作数之间的关系拼接即得到数据库表操作语句;
如果不存在,则不操作。
7.如权利要求1所述的openEHR Template到关系数据库的转换方法,其特征在于,所述步骤(7)将数据操作结果生成数据结果dADL文件包括:
将每个关系数据库表转换为一类模板实例,每个关系数据库表记录转换为一个模板实例,根据关系数据库表名查找对应模板名,根据字段名找到对应属性名。
8.如权利要求1~7任一所述的openEHR Template到关系数据库的转换方法,其特征在于:
所述openEHR Template到关系数据库的转换方法中原型名的构造方法为模板namespace.原型对应参考模型类.原型领域概念.版本号;
所述openEHR Template到关系数据库的转换方法中属性名的构造方法为/根父属性编码/…/父属性编码/属性编码,属性编码格式为“at”+四位数字,如果属性编码不存在,用属性名替代。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710059819.9A CN106844693A (zh) | 2017-01-24 | 2017-01-24 | 一种openEHR Template到关系数据库的转换方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710059819.9A CN106844693A (zh) | 2017-01-24 | 2017-01-24 | 一种openEHR Template到关系数据库的转换方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN106844693A true CN106844693A (zh) | 2017-06-13 |
Family
ID=59121382
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201710059819.9A Pending CN106844693A (zh) | 2017-01-24 | 2017-01-24 | 一种openEHR Template到关系数据库的转换方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN106844693A (zh) |
Cited By (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107291880A (zh) * | 2017-06-19 | 2017-10-24 | 郑州云海信息技术有限公司 | 一种资源图形化的创建方法和装置 |
CN107480115A (zh) * | 2017-08-31 | 2017-12-15 | 郑州云海信息技术有限公司 | 一种caffe框架残差网络配置文件格式转换方法及系统 |
CN107577812A (zh) * | 2017-09-29 | 2018-01-12 | 北京酷我科技有限公司 | 一种实体数据库的快速读取方法 |
CN108038175A (zh) * | 2017-09-30 | 2018-05-15 | 用友金融信息技术股份有限公司 | 多维数据动态关联查询方法、装置、计算机设备和介质 |
CN108520032A (zh) * | 2018-03-27 | 2018-09-11 | 深圳中兴网信科技有限公司 | 数据接口建立方法、系统、计算机设备及存储介质 |
CN108564988A (zh) * | 2018-03-20 | 2018-09-21 | 深圳中兴网信科技有限公司 | 基于OpenEHR的档案存储方法、档案存储系统 |
CN108766507A (zh) * | 2018-04-11 | 2018-11-06 | 浙江大学 | 一种基于CQL与标准信息模型openEHR的临床质量指标计算方法 |
CN108829746A (zh) * | 2018-05-24 | 2018-11-16 | 青岛海信网络科技股份有限公司 | 一种基于内存数据库的主数据管理系统及装置 |
CN109669951A (zh) * | 2018-11-09 | 2019-04-23 | 金蝶软件(中国)有限公司 | 对象查询方法、装置、计算机设备和存储介质 |
CN110209699A (zh) * | 2019-05-22 | 2019-09-06 | 浙江大学 | 一种基于openEHR Composition模板的数据接口动态生成与执行方法 |
CN111180089A (zh) * | 2019-12-31 | 2020-05-19 | 创业慧康科技股份有限公司 | 一种多学科远程医疗云平台配置系统和方法 |
CN112306463A (zh) * | 2020-10-14 | 2021-02-02 | 深圳市中农网有限公司 | 基于POJO的mybatis生成方法、系统、存储介质及设备 |
CN112486990A (zh) * | 2020-11-27 | 2021-03-12 | 山东浪潮通软信息科技有限公司 | 一种根据模型描述同步数据库表结构的方法及设备 |
CN112800149A (zh) * | 2021-02-18 | 2021-05-14 | 浪潮云信息技术股份公司 | 基于数据血缘分析的数据治理方法及系统 |
CN113205881A (zh) * | 2021-06-02 | 2021-08-03 | 中国人民解放军军事科学院军事医学研究院 | 基于思维导图的OpenEHR原型与模板自动生成方法 |
CN114116674A (zh) * | 2021-11-30 | 2022-03-01 | 浩云科技股份有限公司 | 基于综合业务平台的业务建模方法、装置、介质及设备 |
CN117390055A (zh) * | 2023-12-13 | 2024-01-12 | 火石创造科技有限公司 | Jooq连表语句生成方法、设备以及介质 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101980213A (zh) * | 2010-11-23 | 2011-02-23 | 中国科学院软件研究所 | 一种基于j2ee的数据持久化方法及系统 |
CN103136445A (zh) * | 2013-01-29 | 2013-06-05 | 浙江大学 | 一种openEHR信息到关系数据库的转换方法 |
CN105512985A (zh) * | 2015-12-29 | 2016-04-20 | 杭州邦泰科技有限公司 | 基于openEHR标准的糖尿病电子病历数据存储方法 |
-
2017
- 2017-01-24 CN CN201710059819.9A patent/CN106844693A/zh active Pending
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101980213A (zh) * | 2010-11-23 | 2011-02-23 | 中国科学院软件研究所 | 一种基于j2ee的数据持久化方法及系统 |
CN103136445A (zh) * | 2013-01-29 | 2013-06-05 | 浙江大学 | 一种openEHR信息到关系数据库的转换方法 |
CN105512985A (zh) * | 2015-12-29 | 2016-04-20 | 杭州邦泰科技有限公司 | 基于openEHR标准的糖尿病电子病历数据存储方法 |
Non-Patent Citations (1)
Title |
---|
刘骏健: "基于openEHR的临床数据中心设计与实现", 《中国优秀硕士学位论文全文数据库信息科技辑》 * |
Cited By (24)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107291880A (zh) * | 2017-06-19 | 2017-10-24 | 郑州云海信息技术有限公司 | 一种资源图形化的创建方法和装置 |
CN107480115A (zh) * | 2017-08-31 | 2017-12-15 | 郑州云海信息技术有限公司 | 一种caffe框架残差网络配置文件格式转换方法及系统 |
CN107577812A (zh) * | 2017-09-29 | 2018-01-12 | 北京酷我科技有限公司 | 一种实体数据库的快速读取方法 |
CN108038175A (zh) * | 2017-09-30 | 2018-05-15 | 用友金融信息技术股份有限公司 | 多维数据动态关联查询方法、装置、计算机设备和介质 |
CN108564988A (zh) * | 2018-03-20 | 2018-09-21 | 深圳中兴网信科技有限公司 | 基于OpenEHR的档案存储方法、档案存储系统 |
CN108520032A (zh) * | 2018-03-27 | 2018-09-11 | 深圳中兴网信科技有限公司 | 数据接口建立方法、系统、计算机设备及存储介质 |
CN108520032B (zh) * | 2018-03-27 | 2021-08-31 | 深圳中兴网信科技有限公司 | 数据接口建立方法、系统、计算机设备及存储介质 |
CN108766507A (zh) * | 2018-04-11 | 2018-11-06 | 浙江大学 | 一种基于CQL与标准信息模型openEHR的临床质量指标计算方法 |
CN108766507B (zh) * | 2018-04-11 | 2021-08-17 | 浙江大学 | 一种基于CQL与标准信息模型openEHR的临床质量指标计算方法 |
CN108829746A (zh) * | 2018-05-24 | 2018-11-16 | 青岛海信网络科技股份有限公司 | 一种基于内存数据库的主数据管理系统及装置 |
CN109669951A (zh) * | 2018-11-09 | 2019-04-23 | 金蝶软件(中国)有限公司 | 对象查询方法、装置、计算机设备和存储介质 |
CN110209699A (zh) * | 2019-05-22 | 2019-09-06 | 浙江大学 | 一种基于openEHR Composition模板的数据接口动态生成与执行方法 |
CN111180089A (zh) * | 2019-12-31 | 2020-05-19 | 创业慧康科技股份有限公司 | 一种多学科远程医疗云平台配置系统和方法 |
CN112306463A (zh) * | 2020-10-14 | 2021-02-02 | 深圳市中农网有限公司 | 基于POJO的mybatis生成方法、系统、存储介质及设备 |
CN112306463B (zh) * | 2020-10-14 | 2024-02-20 | 深圳市中农网有限公司 | 基于POJO的mybatis生成方法、系统、存储介质及设备 |
CN112486990A (zh) * | 2020-11-27 | 2021-03-12 | 山东浪潮通软信息科技有限公司 | 一种根据模型描述同步数据库表结构的方法及设备 |
CN112486990B (zh) * | 2020-11-27 | 2023-05-02 | 浪潮通用软件有限公司 | 一种根据模型描述同步数据库表结构的方法及设备 |
CN112800149B (zh) * | 2021-02-18 | 2023-08-08 | 浪潮云信息技术股份公司 | 基于数据血缘分析的数据治理方法及系统 |
CN112800149A (zh) * | 2021-02-18 | 2021-05-14 | 浪潮云信息技术股份公司 | 基于数据血缘分析的数据治理方法及系统 |
CN113205881A (zh) * | 2021-06-02 | 2021-08-03 | 中国人民解放军军事科学院军事医学研究院 | 基于思维导图的OpenEHR原型与模板自动生成方法 |
CN113205881B (zh) * | 2021-06-02 | 2023-07-21 | 中国人民解放军军事科学院军事医学研究院 | 基于思维导图的OpenEHR原型与模板自动生成方法 |
CN114116674A (zh) * | 2021-11-30 | 2022-03-01 | 浩云科技股份有限公司 | 基于综合业务平台的业务建模方法、装置、介质及设备 |
CN117390055A (zh) * | 2023-12-13 | 2024-01-12 | 火石创造科技有限公司 | Jooq连表语句生成方法、设备以及介质 |
CN117390055B (zh) * | 2023-12-13 | 2024-03-01 | 火石创造科技有限公司 | Jooq连表语句生成方法、设备以及介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN106844693A (zh) | 一种openEHR Template到关系数据库的转换方法 | |
CN103136445B (zh) | 一种openEHR信息到关系数据库的转换方法 | |
US5560012A (en) | Object-oriented data processing system | |
KR101835345B1 (ko) | 지식베이스 기반의 개념그래프 확장 시스템 | |
CN106663101A (zh) | 本体映射方法和设备 | |
CN106991276B (zh) | 一种基于openEHR模板的数据接口动态生成方法 | |
Flouris et al. | A Classification of Ontology Change. | |
US5572733A (en) | Data processing system which executes composite objects by combining existing objects | |
JP2018067278A (ja) | データプロパティ認識のための装置、方法及びプログラム | |
Le et al. | Domain-driven design using meta-attributes: A DSL-based approach | |
CN108766507A (zh) | 一种基于CQL与标准信息模型openEHR的临床质量指标计算方法 | |
Maldonado et al. | Framework for clinical data standardization based on archetypes | |
Bachmann et al. | OBSE–an approach to Ontology-based Software Engineering in the practice | |
CN107368302A (zh) | 一种基于本体的设计模式识别方法 | |
Cerans et al. | Relational Database Semantic Re-Engineering Technology and Tools | |
Paterson et al. | A universal character model and ontology of defined terms for taxonomic description | |
KR100704285B1 (ko) | 자원 디스크립션 프레임워크를 사용하여 제품 데이터온톨로지를 구성하는 장치 및 방법 | |
Buchmann et al. | Evaluation criteria for logical database design methodologies | |
Chaves-Fraga et al. | Enhancing OBDA query translation over tabular data with Morph-CSV | |
CN113205881B (zh) | 基于思维导图的OpenEHR原型与模板自动生成方法 | |
Van Belle | Evaluation of selected enterprise reference models | |
Bernardello et al. | Information ontologies for historical analysis: survey and BIM model of the San Trovaso Church in Venice | |
JP2005202612A (ja) | データベース生成プログラム作成装置 | |
Dayani-Fard et al. | Reverse engineering by mining dynamic repositories | |
Zhang et al. | Ontology-Based Adaptive Object Model for Simulation Physical Parameter Management |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20170613 |