CN106126543A - 一种关系型数据库到MongoDB的模型转换和数据迁移方法 - Google Patents

一种关系型数据库到MongoDB的模型转换和数据迁移方法 Download PDF

Info

Publication number
CN106126543A
CN106126543A CN201610424619.4A CN201610424619A CN106126543A CN 106126543 A CN106126543 A CN 106126543A CN 201610424619 A CN201610424619 A CN 201610424619A CN 106126543 A CN106126543 A CN 106126543A
Authority
CN
China
Prior art keywords
label
model
mongodb
relevant database
frequently
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.)
Granted
Application number
CN201610424619.4A
Other languages
English (en)
Other versions
CN106126543B (zh
Inventor
贾天宇
丁贵广
李长青
孙鹏
董艳华
李志文
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing August melon Technology Co., Ltd
Tsinghua University
Original Assignee
Beijing Hengguan Network Data Treatment Co Ltd
Tsinghua University
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Beijing Hengguan Network Data Treatment Co Ltd, Tsinghua University filed Critical Beijing Hengguan Network Data Treatment Co Ltd
Priority to CN201610424619.4A priority Critical patent/CN106126543B/zh
Publication of CN106126543A publication Critical patent/CN106126543A/zh
Application granted granted Critical
Publication of CN106126543B publication Critical patent/CN106126543B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21Design, administration or maintenance of databases
    • G06F16/214Database migration support
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25Integrating or interfacing systems involving database management systems
    • G06F16/254Extract, transform and load [ETL] procedures, e.g. ETL data flows in data warehouses
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25Integrating or interfacing systems involving database management systems
    • G06F16/258Data format conversion from or to a database
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28Databases characterised by their database models, e.g. relational or object models
    • G06F16/284Relational databases

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明公开了一种关系型数据库到MongoDB的模型转换和数据迁移方法,包括以下步骤:提取关系型数据库的概念模型;对关系型数据库的日志信息进行分析,获得关系型数据库的描述特征;根据描述特征进行模型转换获得MongoDB的物理模型;根据MongoDB的物理模型进行数据迁移。本发明通过对关系型数据库的日志信息进行了挖掘,以此为基础进行更加科学的模型转换,形成完整、有效的数据模型,并将模型转换和数据迁移相结合,以模型转换的结果为基础进行数据迁移,使数据迁移更加简单高效,且提高了应用的性能。

Description

一种关系型数据库到MongoDB的模型转换和数据迁移方法
技术领域
本发明涉及计算机数据库技术领域,具体涉及一种关系型数据库到MongoDB的模型转换和数据迁移方法。
背景技术
随着数据量的增长和数据结构越来越灵活多变,分布式文档存储数据库(MongoDB)已经在很多领域取代了关系型数据库。虽然关系型数据库依旧是目前使用最为广泛的数据库,但是随着大数据时代的到来很多应用在使用关系型数据库的过程中普遍出现了性能上的瓶颈。人们希望使用MongoDB等非关系型数据库来代替原有的关系型数据库,将保存在关系型数据库中的数据迁移到MongoDB等非关系型数据库中以获得更好的性能,但现有技术存在以下缺点:
1)常见的迁移方法都是直接把关系型数据库中的表(table)转换至MongoDB中的集合(Collection),并未运用MongoDB的嵌套关系于在数据结构上的灵活多变的特点。
2)一些研究和MongoDB的数据模型相关,这些研究通过关系代数证明了可以用关系型数据库的数据模型来指导MongoDB数据模型的建立,但这些研究仅仅完成了数据模型的转换,并未根据数据模型转换的结果来指导数据迁移,最终还需手动地完成迁移数据,一旦关系型数据库的数据模型出现变化,所有的工作将要从头开始,导致效率很低。
有鉴于此,急需提供一种有效的关系型数据库到MongoDB的模型转换和高效、简单的数据迁移方法,提高应用的性能。
发明内容
本发明所要解决的技术问题是目前的相关研究都侧重在数据迁移或者模型转换的某一方面,并没有一套完整的、科学的、高效的通过模型转换和数据迁移将关系型数据库的数据迁移到MongoDB中的问题。
为了解决上述技术问题,本发明所采用的技术方案是提供了一种关系型数据库到MongoDB的模型转换和数据迁移方法,包括以下步骤:
提取关系型数据库的概念模型;
对关系型数据库的日志信息进行分析,获得关系型数据库的描述特征;
根据描述特征进行模型转换获得MongoDB的物理模型;
根据MongoDB的物理模型进行数据迁移。
在上述方法中,所述根据描述特征进行模型转换获得MongoDB的物理模型具体包括以下步骤:
将描述特征转换成描述标签添加至概念模型上;
通过描述标签和概念模型中的关系生成操作标签并添加至概念模型上;
通过模型转换算法将概念模型向MongoDB的物理模型进行转换。
在上述方法中,所述描述标签包括:
频繁连接标签:如果关系型数据库中两个表或者多个表之间执行连接操作的比例大于设定的阈值,则在概念模型的关系上添加上频繁连接标签;
大数据量标签:如果关系型数据库中某个表的平均一条记录需要占用的空间大于定的阈值,则在概念模型的实体上添加上大数据量标签;
频繁修改标签:如果关系型数据库中某个表执行修改或者删除操作的比例大于设定的阈值,则在概念模型的实体上添加上频繁修改标签;
频繁插入标签:如果关系型数据库中某个表执行插入操作的比例大于设定的阈值,则在概念模型的实体上添加上频繁插入标签。
在上述方法中,所述操作标签包括:
嵌入儿子实体标签:一个包含一组主外键关系的关系型数据库中,在进行模型转换时包含外键的表需要被嵌入到包含主键的表中;
嵌入父亲实体标签:一个包含一组主外键关系的关系型数据库中,在进行模型转换时包含主键的表需要被嵌入到包含外键的表中;
引用标签:一个包含一组主外键关系的关系型数据库中,在进行模型转换时需要使用引用关系。
在上述方法中,所述根据描述标签和概念模型的关系生成操作标签并添加至对应的关系上,具体包括以下步骤:
A1、遍历所述包含描述标签的概念模型中的每一组关系;
A2、对每一组关系进行判断,若是一对一关系,则转至A3;若是一对多关系,则转至A6;若是多对多关系,则转至A9;
A3:判断这组关系的包含外键的表是否包含大数据量标签、频繁修改标签或频繁插入标签,如果包含则转A4;否则转A8;
A4:判断这组关系的包含主键的表是否包含大数据量标签、频繁修改标签或频繁插入标签,如果不包含则转A5;否则转A9;
A5、给这组关系加上嵌入父亲实体标签并转A1;
A6、判断这组关系上是否包含有频繁连接标签,若包含则转A7;否则转A9;
A7、判断这组关系的儿子实体是否包含大数据量标签、频繁修改标签或频繁插入标签,若不包含则转A8;否则转A9;
A8、给这组关系加上嵌入儿子实体标签并转A1;
A9、给这组关系加上引用标签并转A1。
在上述方法中,所述通过模型转换算法将概念模型进行向MongoDB的物理模型具体包括以下步骤:
B1、将包含操作标签的概念模型转换为有向图;其中每个实体为有向图上的点,嵌入儿子实体标签和嵌入父亲实体标签会转换为边;对于嵌入儿子实体标签,边的方向由包含外键的表指向包含主键的表;对于嵌入父亲实体标签,边的方向向包含主键的表指向包含外键的表;对于引用标签不做任何操作;
B2、利用heustic algorithm算法检测生成的有向图并解环,获取有向无环图;
B3、对有向无环图进行拓扑排序,确定各个实体的嵌套顺序;
B4、对有向无环图的实体进行嵌套得到MongoDB的物理模型。
在上述方法中,所述根据MongoDB的物理模型进行自动的数据迁移具体包括以下步骤:
S41、使用MetaModel的调用接口将关系型数据库中的每一张表导入到MongoDB中对应的集合;
S42、在MongoDB的物理模型中,对于有嵌套结构的集合,根据关系型数据库的概念模型中的主外键关系进行数据的替换和嵌套;
S43、删除MongoDB的物理模型中无用的集合;
S44、检查嵌套之后MongoDB的数据模型和模型转换的结果是否一致。
在上述方法中,所述关系型数据库的概念模型为ER模型。
本发明通过对关系型数据库的日志信息进行了挖掘,以此为基础进行更加科学的模型转换,形成完整、有效的数据模型,并将模型转换和数据迁移相结合,以模型转换的结果为基础进行自动的数据迁移,使数据迁移更加简单高效,且提高了应用的性能。
附图说明
图1为本发明提供的流程图;
图2为为本发明提供的关系数据库的概念模型示意图;
图3为本发明提供的概念模型生成操作标签的流程图;
图4为本发明提供的实施例1的示意图;
图5为本发明提供的通过模型转换算法将概念模型转换为MongoDB的物理模型流程图;
图6为本发明提供的实施例2的示意图;
图7为本发明提供的概念模型转换为MongoDB的物理模型时数据的嵌套示意图;
图8为本发明提供的在TPC-H数集上进行实验的概念模型示意图;
图9为本发明提供的在TPC-H数集上进行实验的结果示意图。
具体实施方式
本发明通过运用关系型数据库中的描述特征与模型转换的算法,将关系型数据库的数据模型生成相应的MongoDB的数据模型;再根据模型转换的结果自动的进行数据迁移,把关系型数据库中的数据自动的转移到MongoDB中,实现使用MongoDB来代替现有的关系型数据库的目标,提高应用的性能。下面结合具体实施例和说明书附图对本发明予以详细说明。
本发明提供了一种关系型数据库到MongoDB的模型转换和数据迁移方法。如图1所示,包括以下步骤:
S1、提取关系型数据的概念模型。
本发明中提取关系型数据库的概念模型选用的是ER模型,且使用JDBC(即JavaDataBase Connectivity,称为Java数据库连接)接口直接连接目标关系型数据库并得到ER模型;如图2所示,为关系型数据库的概念模型的示意图。因为大多数关系型数据库都提供了提取ER模型的接口,因此ER模型容易获得。
S2、对关系型数据库的日志信息进行分析,得到现有关系型数据库的描述特征,并将描述特征转换为描述标签添加至概念模型上。
一般情况下,从关系型数据库向MongoDB进行数据迁移的目的是为了使应用性能更好。因此,需要研究现有的关系型数据库的局限性,再利用存储在MongoDB中的数据具有结构灵活的特点,虽然MongoDB不支持join操作,但MongoDB可以通过嵌套的形式大大提高数据的读取操作速度,避免join操作。
为了确定关系型数据库中哪些表需要在MongoDB中被嵌套成一个整体,则需要对关系型数据库的日志信息进行分析,分析的内容包括数据库的描述特征,本发明中,将数据特征和查询特征统称为关系型数据库的描述特征。具体意义如下:
数据特征:反应在数据表中的特征;比如每个表的大小、每一条记录的平均大小等。
查询特征:用户对数据库的操作特征;比如增加数据、修改数据、查询数据、删除数据等。
本发明中运用到的描述特征主要有“频繁连接”、“大数据量”、“频繁修改”和“频繁插入”四种,如表1所示。
表1、描述特征及其含义。
几乎所有的关系型数据库都有对应的日志信息系统,在分析关系型数据库中的日志信息之前首先要确定一系列类默认的阈值或用户根据需求自行设定阈值,再根据分析得到的结果,把表1中的四个描述特征转换成为如下所述的描述标签并对应的添加至S1中的概念模型上,四个描述标签的具体含义如下:
“频繁连接”标签("Frequent join"tag):如果关系型数据库中两个表或者多个表之间执行join操作的比例大于设定的阈值,则在概念模型的关系上添加上“频繁连接”标签。
“大数据量”标签("Big size"tag):如果关系型数据库中某个表的平均一条记录需要占用的空间大于定的阈值,则在概念模型的实体上添加上“大数据量”标签。一条记录的平均大小为整个表的大小除以表包含的记录总数。
“频繁修改”标签("Frequent modify"tag):如果关系型数据库中某个表执行alter或者delet操作的比例大于设定的阈值,则在概念模型的实体上添加上“频繁修改”标签。
“频繁插入”标签("Frequent insert"tag):如果关系型数据库中某个表执行insert操作的比例大于设定的阈值,则在概念模型的实体上添加上“频繁插入”标签。
S3、通过数据特征和查询特征将关系型数据的概念模型转换成MongoDB的物理模型。
模型转换的基础是通过步骤S1和S2获得概念模型和描述特征。在步骤S2中,已经描述特征生成描述标签并添加到了概念模型中,因此已经得到了一个包含描述标签的概念模型(ER Model)。如表2所示,为关系型数据库和MongoDB间各个概念的对应关系,除了关系型数据库的关系之外,关系型数据库中其他的概念也可以在MongoDB中找到一个对应的概念且直接进行转换。需要说明的是,本发明的模型转换主要是针对关系型数据库中的关系设计转换的方法,确定在MongoDB中应该用引用(Reference)或嵌套(Embedding)来表示关系型数据库中的表;本质上就是确定关系型数据库转换成MongoDB的物理模型时哪些表需要嵌套在一起,哪些表是独立,对于需要嵌套的表嵌套的方向。
表2、关系型数据库和MongoDB间各个概念的对应关系。
关系型数据库 MongoDB
表(Table) 集合(Collection)
行(Row) 文档(Document)
列(Column) 域(Field)
数据类型(Data type) 数据类型(Data type)
关系(Relationship) 引用(Reference)或嵌套(Embedding)
本发明中模型转换主要包括以下两个步骤,首先是结合描述标签和概念模型中的关系生成操作标签并添加至概念模型上,再通过模型转换算法将概念模型向MongoDB的物理模型进行转换,具体如下:
S31、根据描述标签和概念模型中的关系生成操作标签
在关系型数据库中一共有三种方式来表达实体和实体之间的关系,分别为一对一关系(One-to-One relationship),一对多关系(One-to-Many relationship)和多对多关系(Many-to-Many relationship)。在MongoDB中用引用(Reference)和嵌套(Embedding)两种表达集合(Collection)之间的关系。生成操作标签的目的就是为了确定关系型数据库中的哪些表在MongoDB需要使用嵌套以及嵌套的方向,并使用嵌套表达。哪些表不需要嵌套,而需要形成独立的集合(Collection),并使用引用(Reference)表达。
需要说明的是,在关系型数据库的每一组主外键关系中,包含主键的表是父亲实体(father entity),包含外键的表是儿子实体(child entity),且所有的操作标签都只会被添加到概念模型(ER Model)的关系(relationship)上。如表3所示,为各操作标签及其含义。
表3、操作标签及其含义。
如图3所示,生成操作标签具体包括以下步骤:
A1、遍历通过S2获得的概念模型(ER Model)的每一组关系(relationship)。
A2、对每一组关系(relationship)进行判断,若是一对一关系,则转至A3;若是一对多关系,则转至A6;若是多对多关系,则转至A9。
A3:判断这组关系的儿子实体是否包含“大数据量”、“频繁修改”或“频繁插入”标签,如果包含则转A4;否则转A8。
A4:判断这组关系的父亲实体是否包含“大数据量”、“频繁修改”或“频繁插入”标签,如果不包含则转A5;否则转A9。
A5、给这组关系加上“嵌入父亲实体”标签并转A1。
A6、判断这组关系上是否包含有“频繁连接”标签,若包含则转A7;否则转A9。
A7、判断这组关系的儿子实体是否包含“大数据量”、“频繁修改”或“频繁插入”标签,若不包含则转A8;否则转A9。
A8、给这组关系加上“嵌入儿子实体”标签并返回A1。
A9、给这组关系加上“引用”标签并返回A1。
下面通过具体实施例来说明。
实施例1。
如图4所示,其中country表和city表与city表和address表都是一对多关系,且两表之间都包含了“频繁连接”标签,说明经常执行join操作;且address表上未包含“大数据量”、“频繁修改”或“频繁插入”标签,所以在city表和address表的关系上加上了“嵌入儿子实体”标签。city表上有“大数据量”标签,所以country表和city表的关上加上了“引用”标签。
S32、通过模型转换算法将概念模型进行向MongoDB的物理模型转换;如图5所示,具体包括以下步骤:
B1、将包含操作标签的概念模型转换为有向图;其中每个实体为有向图上的点,“嵌入儿子实体”标签和“嵌入父亲实体”标签会转换为边。对于“嵌入儿子实体”标签,边的方向由儿子实体指向父亲实体,代表以后要把儿子实体嵌入到父亲实体中;对于“嵌入父亲实体”标签,边的方向由父亲实体指向儿子实体,代表以后要把父亲实体嵌入到儿子实体中。对于“引用”标签不做任何操作,不添加边。
B2、利用heustic algorithm(高效软硬件划分)算法检测生成的有向图并解环,获取有向无环图。通过heustic algorithm算法可直接检测生成的有向图中是否有环,如果有环则将自动解环,如果无环则不操作。
B3、对有向无环图进行拓扑排序,确定各个实体的嵌套顺序。
B4、对有向无环图的实体进行嵌套并得到MongoDB的物理模型。
下面通过具体实施例来说明。
实施例2。
如图6所示,以MySQL数据库的样板数据库sakila的一部分为例。首先从现有的关系型数据库中提取概念模型,并根据关系型数据库的日志信息为概念模型加上描述标签。需要说明的是,本实施例只使用了“频繁连接”标签;如图(A)所示,staff表和store表与address表和store表经常执行join操作,根据步骤S31生成操作标签,并转换为如(B)所示的有向图,因有向图中包含环,则通过heustic algorithm算法进行解环形成如图(C)所示的有向无环图,再对此有向无环图进行拓扑排序,确定各个实体之间的嵌套顺序,最后根据拓扑排序的结果和概念模型我们得到了如(D)所示的MongoDB的物理模型。如图(D)中所示,应该被嵌套在一起的实体按照先后顺序已嵌套成了一个集合(Collection),而不需要被嵌套的实体每一个都独立成为一个集合(Collection)。可见只需优化关系型数据库中将要被嵌套的表,可以较大的提升性能。我们没有优化整个关系型数据库中的所有集合,这样可以避免数据的冗余。
S4、根据MongoDB的物理模型进行数据迁移。
具体包括以下步骤:
S41、使用MetaModel(元模型)的调用接口(API)将关系型数据库中的每一张表导入到MongoDB的对应的集合(Collection)中。此时每一张表都对应的一个独立集合。
S42、在MongoDB的物理模型中,对于有嵌套结构的集合,根据关系型数据库的概念模型中的主外键关系进行数据的替换和嵌套。嵌套顺序是由叶子节点到根节点的形式。如图7所示,把Product集合中的一条记录根据productID这个主外键信息就可以嵌入到Sales集合中的一条记录中去,得到一套新的记录,保存到New Sales集合中。
S43、删除MongoDB的物理模型中无用的集合。如图7所示,把Sales集合和Product集合嵌套到一起之后,切以后再也不会用到Sales集合和Product集合,就可以将这两个集合删除。
S44、检查嵌套之后MongoDB的数据模型和模型转换的结果是否一致。
如图8所示,为本发明提供的在TPC-H数据集上进行实验的概念模型。
实验机器为:Windows 8.1 X64,i5-4590CPU@3.30GHz,8G RAM,7200 1TB SATA。
MySQL 5.6.24 X64。
MongoDB 3.2.0 X64。
首先在MySQL数据库中生成了1G的TPC-H数据,并测试以下3种查询语句:
1)select SQL_NO_CACHE o_totalprice from orders,lineitem where o_orderkey=l_orderkey and l_extendedprice=901.00
2)select SQL_NO_CACHE c_nationkey from customer,orders,lineitem wherec_custkey=o_custkey and o_orderkey=l_orderkey and l_extendedprice=901.00
3)select SQL_NO_CACHE n_regionkey from nation,customer,orders,lineitem where n_nationkey=c_nationkey and c_custkey=o_custkey and o_orderkey=l_orderkey and l_extendedprice=901.00
假定上述三条查询语句都是频繁执行的,且三条查询分别涉及1张表、2张表和3张表,通过本发明提供的方法将MySQL中的TPC-H数据迁移到MongDB中,并执行上述三条查询语句操作,本实验是在有索引和无索引的情况下都进行了测试,测试的结果如图9所示,可以看出通过本发明提供的方法进行模型转换和数据迁移之后,所有的查询花费的时间都减少,且涉及的表越多,性能提升就越大;另外,为了保持实验条件的一致性,实验中未使用MongoDB分布式部署方式,也没有使用Map Reduce编程模型。如果使用上述两种编程模型,查询速度会更快,同时相比于MySQL可以存储更加海量的数据。
本发明的有益效果如下:
(1)本发明提供了一种从关系型数据库到MongoDB的模型转换和数据迁移方法,可以方便的将关系型数据库中的数据迁移到MongoDB中,提供更好的应用性能。
(2)本发明对关系型数据库的日志信息进行了挖掘,以此为基础进行科学的模型转换,形成有效的数据模型。
(3)本发明将模型转换和数据迁移相结合,以模型转换的结果为基础进行自动的数据迁移。
本发明不局限于上述最佳实施方式,任何人应该得知在本发明的启示下作出的结构变化,凡是与本发明具有相同或相近的技术方案,均落入本发明的保护范围之内。

Claims (8)

1.一种关系型数据库到MongoDB的模型转换和数据迁移方法,其特征在于,包括以下步骤:
提取关系型数据库的概念模型;
对关系型数据库的日志信息进行分析,获得关系型数据库的描述特征;
根据描述特征进行模型转换获得MongoDB的物理模型;
根据MongoDB的物理模型进行数据迁移。
2.如权利要求1所述的方法,其特征在于,所述根据描述特征进行模型转换获得MongoDB的物理模型具体包括以下步骤:
将描述特征转换成描述标签添加至概念模型上;
通过描述标签和概念模型中的关系生成操作标签并添加至概念模型上;
通过模型转换算法将概念模型向MongoDB的物理模型进行转换。
3.如权利要求2所述的方法,其特征在于,所述描述标签包括:
频繁连接标签:如果关系型数据库中多个表之间执行连接操作的比例大于设定的阈值,则在概念模型的关系上添加上频繁连接标签;
大数据量标签:如果关系型数据库中某个表的平均一条记录需要占用的空间大于设定的阈值,则在概念模型的实体上添加上大数据量标签;
频繁修改标签:如果关系型数据库中某个表执行修改或者删除操作的比例大于设定的阈值,则在概念模型的实体上添加上频繁修改标签;
频繁插入标签:如果关系型数据库中某个表执行插入操作的比例大于设定的阈值,则在概念模型的实体上添加上频繁插入标签。
4.如权利要求3所述的方法,其特征在于,所述操作标签包括:
嵌入儿子实体标签:一个包含一组主外键关系的关系型数据库中,在进行模型转换时包含外键的表需要被嵌入到包含主键的表中;
嵌入父亲实体标签:一个包含一组主外键关系的关系型数据库中,在进行模型转换时包含主键的表需要被嵌入到包含外键的表中;
引用标签:一个包含一组主外键关系的关系型数据库中,在进行模型转换时需要使用引用关系。
5.如权利要求4所述的方法,其特征在于,所述根据描述标签和概念模型的关系生成操作标签并添加至对应的关系上,具体包括以下步骤:
A1、遍历所述包含描述标签的概念模型中的每一组关系;
A2、对每一组关系进行判断,若是一对一关系,则转至A3;若是一对多关系,则转至A6;若是多对多关系,则转至A9;
A3:判断这组关系的包含外键的表是否包含大数据量标签、频繁修改标签或频繁插入标签,如果包含则转A4;否则转A8;
A4:判断这组关系的包含主键的表是否包含大数据量标签、频繁修改标签或频繁插入标签,如果不包含则转A5;否则转A9;
A5、给这组关系加上嵌入父亲实体标签并转A1;
A6、判断这组关系上是否包含有频繁连接标签,若包含则转A7;否则转A9;
A7、判断这组关系的儿子实体是否包含大数据量标签、频繁修改标签或频繁插入标签,若不包含则转A8;否则转A9;
A8、给这组关系加上嵌入儿子实体标签并转A1;
A9、给这组关系加上引用标签并转A1。
6.如权利要求4所述的方法,其特征在于,所述通过模型转换算法将概念模型进行向MongoDB的物理模型具体包括以下步骤:
B1、将包含操作标签的概念模型转换为有向图;其中每个实体为有向图上的点,嵌入儿子实体标签和嵌入父亲实体标签会转换为边;对于嵌入儿子实体标签,边的方向由包含外键的表指向包含主键的表;对于嵌入父亲实体标签,边的方向向包含主键的表指向包含外键的表;对于引用标签不做任何操作;
B2、利用heustic algorithm算法检测生成的有向图并解环,获取有向无环图;
B3、对有向无环图进行拓扑排序,确定各个实体的嵌套顺序;
B4、对有向无环图的实体进行嵌套得到MongoDB的物理模型。
7.如权利要求6所述的方法,其特征在于,所述根据MongoDB的物理模型进行自动的数据迁移具体包括以下步骤:
S41、使用MetaModel的调用接口将关系型数据库中的每一张表导入到MongoDB中对应的集合;
S42、在MongoDB的物理模型中,对于有嵌套结构的集合,根据关系型数据库的概念模型中的主外键关系进行数据的替换和嵌套;
S43、删除MongoDB的物理模型中无用的集合;
S44、检查嵌套之后MongoDB的数据模型和模型转换的结果是否一致。
8.如权利要求1所述的方法,其特征在于,所述关系型数据库的概念模型为ER模型。
CN201610424619.4A 2016-06-15 2016-06-15 一种关系型数据库到MongoDB的模型转换和数据迁移方法 Active CN106126543B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610424619.4A CN106126543B (zh) 2016-06-15 2016-06-15 一种关系型数据库到MongoDB的模型转换和数据迁移方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610424619.4A CN106126543B (zh) 2016-06-15 2016-06-15 一种关系型数据库到MongoDB的模型转换和数据迁移方法

Publications (2)

Publication Number Publication Date
CN106126543A true CN106126543A (zh) 2016-11-16
CN106126543B CN106126543B (zh) 2019-09-03

Family

ID=57469586

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610424619.4A Active CN106126543B (zh) 2016-06-15 2016-06-15 一种关系型数据库到MongoDB的模型转换和数据迁移方法

Country Status (1)

Country Link
CN (1) CN106126543B (zh)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106951442A (zh) * 2017-02-15 2017-07-14 中国保险信息技术管理有限责任公司 一种异构数据库间的数据交互方法及装置
CN107145601A (zh) * 2017-06-02 2017-09-08 北京蓝图明册科技有限公司 一种高效的引用关系发现算法
CN108153911A (zh) * 2018-01-24 2018-06-12 广西师范学院 数据的分布式云存储方法
CN108681240A (zh) * 2018-03-09 2018-10-19 南京航空航天大学 一类基于未知输入观测器的小型无人机分布式编队的故障诊断方法
CN108763432A (zh) * 2018-05-24 2018-11-06 思派(北京)网络科技有限公司 一种应用于互联网医疗的跨平台数据整合方法
CN110851425A (zh) * 2019-11-18 2020-02-28 上海新炬网络技术有限公司 基于Mongify迁移Oracle数据至Mongo DB数据库的方法
CN111352918A (zh) * 2018-12-21 2020-06-30 卓望数码技术(深圳)有限公司 一种终端数据库数据迁移方法及系统
WO2020215799A1 (zh) * 2019-04-24 2020-10-29 深圳先进技术研究院 基于日志分析的MongoDB数据迁移监控方法及装置
CN112035566A (zh) * 2020-11-04 2020-12-04 长沙树根互联技术有限公司 数据调用方法、装置、电子设备和存储介质
CN112487196A (zh) * 2020-06-29 2021-03-12 孙炜 一种训练关系抽取模型并抽取嵌套命名实体关系的方法
CN112765197A (zh) * 2020-12-30 2021-05-07 金蝶软件(中国)有限公司 数据查询方法、装置、计算机设备和存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101093493A (zh) * 2006-06-23 2007-12-26 国际商业机器公司 数据库查询语言转换方法、转换装置、数据库查询系统
CN103246749A (zh) * 2013-05-24 2013-08-14 北京立新盈企信息技术有限公司 面向分布式计算的矩阵数据库系统及其查询方法
CN103810275A (zh) * 2014-02-13 2014-05-21 清华大学 用于非关系与关系型数据库间数据交互的方法和装置
CN104794244A (zh) * 2015-05-13 2015-07-22 南京大学 一种基于MongoDB实现图转换的方法和装置
US9348880B1 (en) * 2015-04-01 2016-05-24 Palantir Technologies, Inc. Federated search of multiple sources with conflict resolution

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101093493A (zh) * 2006-06-23 2007-12-26 国际商业机器公司 数据库查询语言转换方法、转换装置、数据库查询系统
CN103246749A (zh) * 2013-05-24 2013-08-14 北京立新盈企信息技术有限公司 面向分布式计算的矩阵数据库系统及其查询方法
CN103810275A (zh) * 2014-02-13 2014-05-21 清华大学 用于非关系与关系型数据库间数据交互的方法和装置
US9348880B1 (en) * 2015-04-01 2016-05-24 Palantir Technologies, Inc. Federated search of multiple sources with conflict resolution
CN104794244A (zh) * 2015-05-13 2015-07-22 南京大学 一种基于MongoDB实现图转换的方法和装置

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106951442A (zh) * 2017-02-15 2017-07-14 中国保险信息技术管理有限责任公司 一种异构数据库间的数据交互方法及装置
CN107145601B (zh) * 2017-06-02 2020-08-14 北京数语科技有限公司 一种高效的引用关系发现方法
CN107145601A (zh) * 2017-06-02 2017-09-08 北京蓝图明册科技有限公司 一种高效的引用关系发现算法
CN108153911A (zh) * 2018-01-24 2018-06-12 广西师范学院 数据的分布式云存储方法
CN108153911B (zh) * 2018-01-24 2022-07-19 广西师范学院 数据的分布式云存储方法
CN108681240A (zh) * 2018-03-09 2018-10-19 南京航空航天大学 一类基于未知输入观测器的小型无人机分布式编队的故障诊断方法
CN108681240B (zh) * 2018-03-09 2021-04-02 南京航空航天大学 基于未知输入观测器的无人机分布式编队的故障诊断方法
CN108763432A (zh) * 2018-05-24 2018-11-06 思派(北京)网络科技有限公司 一种应用于互联网医疗的跨平台数据整合方法
CN108763432B (zh) * 2018-05-24 2021-05-25 思派(北京)网络科技有限公司 一种应用于互联网医疗的跨平台数据整合方法
CN111352918A (zh) * 2018-12-21 2020-06-30 卓望数码技术(深圳)有限公司 一种终端数据库数据迁移方法及系统
CN111352918B (zh) * 2018-12-21 2023-05-23 卓望数码技术(深圳)有限公司 一种终端数据库数据迁移方法及系统
WO2020215799A1 (zh) * 2019-04-24 2020-10-29 深圳先进技术研究院 基于日志分析的MongoDB数据迁移监控方法及装置
CN110851425A (zh) * 2019-11-18 2020-02-28 上海新炬网络技术有限公司 基于Mongify迁移Oracle数据至Mongo DB数据库的方法
CN110851425B (zh) * 2019-11-18 2023-05-26 上海新炬网络技术有限公司 基于Mongify迁移Oracle数据至Mongo DB数据库的方法
CN112487196A (zh) * 2020-06-29 2021-03-12 孙炜 一种训练关系抽取模型并抽取嵌套命名实体关系的方法
CN112035566A (zh) * 2020-11-04 2020-12-04 长沙树根互联技术有限公司 数据调用方法、装置、电子设备和存储介质
CN112035566B (zh) * 2020-11-04 2021-02-23 长沙树根互联技术有限公司 数据调用方法、装置、电子设备和存储介质
CN112765197A (zh) * 2020-12-30 2021-05-07 金蝶软件(中国)有限公司 数据查询方法、装置、计算机设备和存储介质
CN112765197B (zh) * 2020-12-30 2024-04-30 金蝶软件(中国)有限公司 数据查询方法、装置、计算机设备和存储介质

Also Published As

Publication number Publication date
CN106126543B (zh) 2019-09-03

Similar Documents

Publication Publication Date Title
CN106126543A (zh) 一种关系型数据库到MongoDB的模型转换和数据迁移方法
CN103823823B (zh) 基于频繁项集挖掘算法的反规范化策略选择方法
US6944619B2 (en) System and method for organizing data
CN102867066B (zh) 数据汇总装置和数据汇总方法
CN107111617A (zh) 数据库中的图处理
CN104462351B (zh) 一种面向MapReduce范型的数据查询模型与方法
CN104281652A (zh) 度量空间中逐个支撑点数据划分方法
CN102609490B (zh) 一种面向列存储dwms的b+树索引方法
CN104778236A (zh) 一种基于元数据的etl实现方法及系统
CN102270232A (zh) 一种存储优化的语义数据查询系统
CN107291895A (zh) 一种快速的层次化文档查询方法
CN102456055A (zh) 兴趣点检索的方法及装置
CN106599052A (zh) 一种基于ApacheKylin的数据查询系统及其方法
CN109325062A (zh) 一种基于分布式计算的数据依赖挖掘方法及系统
CN110275966A (zh) 一种知识抽取方法及装置
CN104573405B (zh) 一种基于大树构建子树的系统进化树重建方法
CN108228787A (zh) 按照多级类目处理信息的方法和装置
CN106095852A (zh) 一种针对活动轨迹的高效查询方法
Jena et al. High performance frequent subgraph mining on transaction datasets: A survey and performance comparison
CN109086381A (zh) 模糊概念格的一种更新生成方法
CN108984711A (zh) 一种基于分层嵌入的个性化app推荐方法
Scriney et al. Efficient cube construction for smart city data
CN106933844A (zh) 面向大规模rdf数据的可达性查询索引的构建方法
CN102955860B (zh) 基于模式图的关键字查询改进方法
CN105354243B (zh) 基于归并聚类的并行化频繁概率子图搜索方法

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
CP03 Change of name, title or address
CP03 Change of name, title or address

Address after: 100084 Tsinghua University, Beijing, Haidian District

Co-patentee after: Beijing August melon Intellectual Property Agency Co., Ltd.

Patentee after: Tsinghua University

Address before: 100083 Tsinghua University, Beijing, Haidian District

Co-patentee before: BEIJING HENGGUAN NETWORK DATA TREATMENT CO., LTD.

Patentee before: Tsinghua University

CI03 Correction of invention patent
CI03 Correction of invention patent

Correction item: Patentee|Address|Patentee

Correct: Tsinghua University|100083 Tsinghua University, Beijing, Haidian District|BEIJING HENGGUAN NETWORK DATA TREATMENT CO., LTD.

False: Tsinghua University|100084 Tsinghua University, Beijing, Haidian District|Beijing August melon Intellectual Property Agency Co., Ltd.

Number: 47-02

Volume: 35

CP01 Change in the name or title of a patent holder
CP01 Change in the name or title of a patent holder

Address after: 100084 Tsinghua University, Beijing, Haidian District

Co-patentee after: Beijing August melon Technology Co., Ltd

Patentee after: Tsinghua University

Address before: 100084 Tsinghua University, Beijing, Haidian District

Co-patentee before: BEIJING HENGGUAN NETWORK DATA TREATMENT CO., LTD.

Patentee before: Tsinghua University