PDM数据向MongoDB迁移的设计实现

夏秀峰，曾喆（1.沈阳航空航天大学辽宁省通用航空重点实验室，沈阳　110136; .沈阳航空航天大学计算机学院，沈阳　110136）

PDM数据向MongoDB迁移的设计实现

夏秀峰1，2，曾喆2
（1.沈阳航空航天大学辽宁省通用航空重点实验室，沈阳110136; 2.沈阳航空航天大学计算机学院，沈阳110136）

0　引言

目前，制造业中针对PDM的数据存储主要基于传统的关系数据库[1-2]。由于关系数据库的数据存储结构是以二维表的形式存在，当涉及到PDM数据中诸如文献[1]提到的产品结构树，装配关系与批架次关系等一些列复杂的网状结构数据时，往往呈现多对多的关系，零件E、F组成部件B，部件B又被其他的部件、产品所使用，如下图所示（其中箭头指向为父件指向子件），这种情况下，必须进行相应的数据存储关系转化(例如由网状结构到单父-单子存储模式的转换），表1所示，来适应二维表的存储模式。这种以二维表形式存储复杂网状结构数据的方式严重制约了PDM数据的存储及查询效率。

表1　单子—单父表法

图1　PDM中零部件复杂的网状关系

并且，由于当今MBD[3-4]技术在制造业的推广，基于关系数据库存储的PDM数据在高扩展性、高并发访问和高可用性等方面将会面临新的挑战。文献[5]指出，MBD技术通过将三维尺寸标注信息、各种制造信息和产品结构信息一起附着在三维实体模型上的方式，完整地表达了产品的各种有效信息。文献[3]指出，在这样的设计模式下，企业将具有详细标注的三维模型作为数据唯一来源，并围绕其进行需求、分析、设计、实施等一系列操作，在这些环节当中必然会产生大量的数据，再加上随着时间推移、产品型号增加等因素的影响，使得这些数据逐步呈现大数据的态势。

新近出现的非关系数据库NoSQL[6-8]相对于传统的关系数据库在处理PDM复杂网状结构数据以及大数据等方面表现出优越的性能，其中具有代表性的非关系数据库MongoDB是目前较好的面向文档的免费开源NoSQL数据库。它以简洁熟悉的类JSON形式，即BSON[9]形式来展现数据库的存储形式,且不必遵循关系数据库ACID（原子性、一致性、隔离性、持久性）特性。MongoDB使用键值存储作为最基本的存储形式，依靠嵌套、引用来组织关联关系，允许数据重复存储而不太多关注存储代价。所以，当MongoDB来处理PDM中产品结构树复杂的网状数据结构时，可以通过重复存储各个零部件的方式更加形象高效地存储产品结构树，不用去过多考虑关系数据库需要考虑的数据关系模式转换，数据冗余等问题。MongoDB在应对大数据态势时也具有强大优势，它可以依靠廉价的集群克服服务器硬件瓶颈问题，依靠分片[10-11]方式达到负载均衡，有效解决了高并发读写，海量访问等难题。

针对上述PDM数据存储在关系数据库中遇到的一系列问题以及非关系数据库在存储PDM数据方面所具有的优良特性，本文主要研究将存储在关系数据库中的PDM数据迁移到MongoDB非关系数据库中。

1　主流的数据库迁移技术

1.1关系数据库之间数据迁移

关系数据库之间的数据迁移技术如今已经相当成熟，正如文献[12]指出的，现行的迁移工具不仅有In鄄formix的InforMover、Microsoft SQL Server 7的DTS和Oracle的Oracle Warehouse Builder等这类数据库厂商专门提供的为自己产品服务的数据迁移工具，还有一些是面向大多数数据库开发的迁移工具，这类产品一般都有较完善的体系结构,其功能相对比较全面，但是由于其并不是针对某一种数据库，所以其功能相对全面的同时也伴随着高复杂性，典型的产品有Ascential DataStage和Informatica。

1.2关系数据库到MongoDB数据库迁移技术

（1）MongoDB自带工具的迁移实现

MongoDB在初始设计时已经考虑到数据的迁移问题，其自带的导入工具mongoimport可以实现将JSON以及CSV格式的数据导入到MongoDB数据库中[12]。文献[13]实现的将Excel数据迁移到MongoDB中就是充分利用了MongoDB自带的导入工具，由关系数据库向MongoDB迁入时，只需从关系数据库中导出大多数主流数据库都支持的CSV格式的数据，然后导入到MongoDB中，最后分别设定好各个表转换成的集合之间的关系即可。但是使用MongoDB自带的工具进行数据迁移时，只是机械的将关系数据库中的表数据直接“复制”到MongoDB数据库中，并且需要人工的指明各个表（集合）之间的关系，并不能体现出MongoDB结构自由，不局限于ACID模式等一系列优势。

（2）现有的其他人士的迁移工具的实现

文献[13]重点研究了关系数据库中表迁移到Mon鄄goDB时表与表之间的关系：嵌套还是引用，其方法不仅需要人工判定，并且该研究定位在以表为研究的基本对象，进而处理各对象之间的相应关系。虽然该方法相对于MongoDB自带的工具有了较大改进（并不是简单的依靠原有的外键进行简单的引用，融合了嵌套引用具有MongoDB特色的元素），但是仍然没有从Mon鄄goDB更小的结构单位（文档、数组）来处理问题，使得MongoDB的优势不能充分体现，在应用到PDM数据时依然存在与关系数据库类似的问题。

2　基于PDM数据的迁移实现

2.1主要设计思想

将PDM数据从关系数据库迁移到非关系数据库MongoDB的设计思想主要是根据PDM数据的特征，由于制造业中普遍存在一个零部件可能是其他多个零部件的组成部分这样的情况，PDM数据存储到关系数据库中，为了遵循ACID特性，每个零部件只能存储一个，当其他零部件涉及到该零部件时，需要建立大量的关联关系，从而导致对产品的查询效率大大降低。本文设计的迁移工具主要是从降低联接查询，提高查询效率出发，利用MongoDB灵活的文档嵌套结构，将零部件数据直接嵌入到相应零部件当中。这样在牺牲存储空间的情况下，避免了大量的联接查询，极大地提高了查询效率。

2.2独立表的迁移

（1）变换情景

当关系数据库中表独立存在，不与其他表存在外键关联时，可将表直接进行迁移变换。如表2所示，该表与其他表没有存在外键关联关系，只需进行直接迁移变换，并且为了下面多表的迁移做好准备，需要将关系数据库中所有表先进行表到文档的转换。

表2　Unit

（2）变换策略

基本的表变换方法是将原来表的名字作为Mon鄄goDB中集合的名字，表中的每一个元组转换成Mon鄄goDB集合中的各个文档，每个文档中的键-值对分别对应关系表中的字段名-属性值。在MongoDB中每一项文档生成的时候，系统都会自动给其生成一个唯一“_id”键,作为该文档在集合中的唯一标识，其值为Ob鄄jectId（）对象。我们也可以自己插入“_id”，但是其值在每个集合内部必须唯一。

（3）性能分析

由于关系数据库中独立表到MongoDB集合的迁移只是简单的存储形式的变化，因此其在数据库存储空间，查询效率等方面与MongoDB自带的工具差别不大。

2.3连接表的多表迁移

（1）变换场景

表3是以单父-单子模式存储的设计BOM详细信息表，即产品结构树，主键为复合主键Materialid+Par鄄entid，其中Materialid为外键，关联着表4（BOM基本信息表）。

表4是零部件基本信息表，主键为Materialid，存储了所有零部件的基本信息。

表3　bomdetail（设计BOM详细信息表）

在关系数据库中我们查看产品结构树中产品或者零部件的基本信息时，必须进行一次关联表的查询才能获取信息，为了避免关联表查询，在MongoDB中将由表4转换的集合以文档为基本单位嵌入表3转换的集合中。

（2）变换方法

将表3，表4进行独立表形式的变换，将表4变换的集合名称作为表3键-值对中的键，表4中与表3以关系表中外键相关联的文档作为值，进而将表4分解存储到表3的文档中，这种变换模式体现了MongoDB中支持内嵌文档作为值的特性。如果关系数据库中对表4的查询只是通过表3来完成，则可以将表4转换的集合删除，但是当该表还需要其他方面的查询，则保留该表转换的集合。例如表4中产品NW034/5-0是不需要表3查询的，所有表4转换的集合必须保留。下面是变换后的bomdetail集合。

（3）性能分析

通过将bomheader（BOM基本信息表）进行以关系数据库中的外键为纽带的分解，使得bomdetails转换成的集合能减少一步联接查询过程），但是对于bomhead鄄er转换成的集合不能删除，这必然导致存储代价的提高，但是能够使查询效率得到很到提升，并且实际生产中主要是对产品结构树进行频繁的查询而不是修改。

2.4涉及到中间表的多表迁移

（1）适用情景说明

①适用情景

对于关系数据库中多对多关系的处理，通常使用中间表的模式。以PDM图文档中的user表、sjwj表、sjwj_user表三表的迁移为例，表5（user表）跟表6（siwj表）相互独立，但是都与表7（sjwj_user表）关联，即为传统关系数据库中的多对多表关系。为了减少联接查询次数，可以通过将表5的转换文档依据表7的转换文档嵌入到表6的文档中，最后根据情况对表5、表7进行取舍。

表5是设计人员表，主键为User_num（设计人员编号），存储了设计人员的个人信息。

表5　user（设计人员表）

表6是设计文件表，主键为Pronduct_id（产品编号），该表存储了产品的所有信息。

表6　sjwj（设计文件表）

表7是为了存储设计人员与设计文件的对应关系而专门设计的中间表，这里没有特别设定主键，以设计人员编号和产品编号作为联合主键。

②迁移策略

多对多关系的迁移转换建立在前面两步基础之上，将表5、表6、表7首先进行独立变换形成各自的三个集合，user集合、sjwj集合、user_sjwj集合。将集合user名字作为sjwj集合中的键，将user集合中通过us鄄er_sjwj集合建立联系的user文档作为值，由于是多对多的关系，每个sjwj集合中涉及到的user集合中的文档数量常常多于一个，即每个设计文件通常有多个设计者。在处理上述情况时，可以使用MongoDB中的数组类型，将文档作为数组元素，来实现多个文档的嵌入。由于可能要进行对所有用户的查询，并不是只通过sjwj集合对user进行查询，所有user集合保留，但是user_sjwj集合要删除。实现迁移后的sjwj集合如下面文档所示。

表7　user_sjwj（设计人员、文件关联表）

③效果评价

将user集合进行分解并将其文档嵌入到sjwj集合当中，sjwj集合在进行user查询时可以减少关系数据库中两次联接查询，大大提高了查询效率。尽管嵌入式文档存储的方式因为冗余存储增加了空间存储代价，提高了写入更改的难度，但是实际生产中主要进行查询操作，并且MongoDB之类的非关系数据库在空间存储方面有先天优势，所以这样的迁移转换很符合实际需要。

3　性能比较分析

为了对比分析传统关系数据库，MongoDB自带工具以及本文提出的迁移工具三者的性能，以最复杂的多对多关系模式的设计人员与设计文件为例，分别从存储以及查询两方面进行对比，本文设定了500名设计人员，设计文件分别为5000,1万，5万，10万，50万

3.1空间存储比较分析

如图2所示。

3.2查询效率比较分析

在关系数据库中，以查询sjwj中的设计者user为例进行具有中间表sjwj_user的对主轴的设计者进行查询，查询语句如下。

本实验的查询语句如下。

说明：以上实验都是在没有建立索引情况下进行的实验对比。

图2　数据不同存储形式的空间存储量

3.3实验总结分析

通过图2可以看出当数据规模较小时三者差别不大，但是当数据规模逐渐增大时，本实验工具的空间存储代价远远高于另外两者，从图3可以看出当数据规模较小时，三者查询效率差别不大，但是随着数据规模的不断增大，本实验的查询效率明显高于其他两者。说明通过嵌入式的重复存储数据，尽管付出了巨大的存储代价，但是却大大减少了联接查询，提高了查询效率，这种消耗存储代价换取查询效率的方式对于非关系数据是容易接受的。

4　结语

关系数据库存储的PDM数据迁移到MongoDB等非关系数据库中，有效地解决了PDM大数据特征下关系数据库的不足之处，并且对比MongoDB自带的迁移工具，本文设计的迁移工具从更小的单位——文档的角度进行了存储的有效改进，在牺牲了一定的存储代价的情况下，大大提高了查询效率。在后期工作中，可以与MongoDB索引相结合，对查询效率进行进一步优化。

图3　不同工具的查询效率

[1]苟凌怡，魏生民.基于关系型数据库的产品动态BOM的数据库设计与优化[J].组合机床与自动化加工技术，1999,5:6-9.

[2]苟凌怡，魏生民.在Oracle中产品结构树的生成与查询优化[J].计算机工程与应用，1999,7:63-76.

[3]夏秀峰,赵小磊,孔庆云.MBE与大数据给PDM带来的思考[J].制造业自动化,2013,35（10）:70-72.

[4]姜红明，张丰华.MBD技术实施研究[J].制造业自动化，2012,34（12）：1-12.

[5]冯潼能.MBD技术下的协同与管理“进化”[J].中国制造业信息化，2011,7：24-26.

[6]申德荣，于戈，王习特，聂铁铮，寇月.支持大数据管理的NoSQL系统研究综述.软件学报,2013,24（8）:1786-1803.

[7]Strauch.C.NoSQL Databases.Selected Topics on Software-Technology,Stuttgart Media University.

[8]NoSQL.http://nosql-database.org/

[9]BSON.http://bsonspec.org/

[10]（美）Kyle Banker著.MongoDB实战.丁雪丰译.北京：人民邮电出版社，2012.

[11]（美）Kristina Chodorow著.MongoDB权威指南.邓强，王明辉译.北京：人民邮电出版社，2014.

[12]宋鹏.基于Oracclgi的数据迁移方案设计及性能优化[D].陕西：西安电子科技大学，2007.

[13]毛应爽.Excel到MongoDB数据迁移解决方案[J].信息通信，2013,7:87-88.

[14]黄伟权.MongoDB的形式化模型和研究[D].广东：中山大学软件工程学院，2013.

[15]钟自强.南方公司机动分公司[D].湖南：国防科学技术大学机械工程学院，2002.

MBD;PDM;NoSQL;Data Migration;MongoDB;Query Efficiency

Design and Implementation of PDM Data Migrating to MongoDB

XIA Xiu-feng1，2，ZENG Zhe2
（1.Liaoning General Aviation Laboratory,Shenyang Aerospace University,Shenyang 110136；2.School of Computer Science,Shenyang Aerospace University,Shenyang 110136）

1007-1423（2016）04-0087-06

10.3969/j.issn.1007-1423.2016.04.021

夏秀峰（1964-），男，山东青岛人，博士，教授，研究方向为数据库理论与技术

曾喆（1987-），男，山东省菏泽人，硕士研究生，研究方向为管理信息系统与数据库

2015-12-15

2016-01-10

随着MBD技术在制造业的广泛实施，使得产品整个生命周期中产生的数据规模急剧增大，伴随而来的对数据高并发读写、高访问量等问题日益突出，现行的基于RDB的数据存储方式不能很好地应对这些问题而非关系数据库具有先天优势。针对上述问题，设计迁移工具实现数据由RDB向非关系数据库MongoDB迁移。通过提出的三种变换方法，并且以文档为最小变化单位，实现数据迁移。实验结果表明，在随着文档规模不断增大的情况下，经过设计的迁移工具和MongoDB自带的迁移工具迁移之后，前者比后者查询效率明显提高。

MBD；PDM；非关系数据库；数据迁移；MongoDB；空间存储；查询效率

航空科技基金（No.2013ZG54032）

With widely implemented in manufacturing industry,MBD technology makes the product whole life cycle of data size increases sharply, the data associated with high concurrency,speaking,reading and writing,such as high traffic problem increasingly prominent,the current way of data storage based on RDB cannot deal with these issues effectively rather than a NoSQL has the congenital advantage.Aiming at these problems,designs the tool to migrate data from RDB to directing a non-relational database MongoDB.Through the proposed three kinds of transformation methods,and according to the document as the smallest unit of change,realizes the data migration.The experi鄄mental results show that along with the continuously increasing scale of documents,comparing the design of the migration tool to Mon鄄goDB own migration,the former obviously improves the query efficiency than the latter.