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.