關系數據庫向文檔數據庫的模式轉換算法

王海林，張雅君（山西財經大學信息管理學院，太原　030006）

關系數據庫向文檔數據庫的模式轉換算法

王海林，張雅君
（山西財經大學信息管理學院，太原030006）

0　引言

從數據庫的角度來講，大數據是指不可以被通常的數據處理工具如傳統的數據庫管理系統所捕獲、存儲、管理和分析的數據［1］。為了滿足大數據存儲及處理分析的需求，NoSQL（Not Only SQL）數據庫應運而生。

不同于關系數據庫，NoSQL數據庫用來存儲大量的非結構化數據，因此它的特征是非關系的、分布的、開源的、可水平擴展的。按照存儲結構的不同，常見的NoSQL數據庫可以分為文檔式存儲、列式存儲、鍵值對存儲、對象式存儲和圖形式存儲。其中，MongoDB是一種輕量級文檔式存儲數據庫，在不涉及到聚合函數的情況下，MongoDB在性能方面甚至要優于關系數據庫［2］。

NoSQL數據庫在性能上滿足了對海量數據的高效存儲和訪問的需求，文獻［3-5］在性能這方面做了詳細的敘述。與關系數據庫相比，NoSQL數據庫靈活性更大，擴展性更高，可用性更強［6］。

為了將關系數據庫中的數據遷移到NoSQL數據庫中，實現從SQL到NoSQL的轉換，并維持良好的查詢性能，甚至是提高查詢效率，許多學者都做了相關的研究。一些學者提出四種表模式變換方法，實現了從關系數據庫向HBase遷移的半自動化遷移［7］。對于轉換到HBase數據庫的方法，也有學者提出使用嵌套和多重嵌套描述SQL數據庫中的參照關系，設計了HBase的數據模式，并支持從關系數據庫到HBase數據庫的遷移［8］。因為一個表中任何數據的獲得都只需執行一次查詢，因此在這種模式下會提高查詢性能。由于HBase是列存儲數據庫，與MongoDB存儲結構不同，這種轉換并不能實現到文檔數據庫的轉換。

本文從ER圖入手，提出一種轉換算法，將SQL數據庫中表間的參照關系轉換為層次結構，將參照關系中外鍵所在的表作為子表嵌入到主鍵所在的表也就是父表中，從而存儲到MongoDB數據庫中。最后，實驗結果表明這種算法不僅可以實現數據模式從SQL數據庫到MongoDB數據庫的轉換，還可以提高數據查詢的性能，更加符合大數據時代對數據分析的要求。

1　相關研究

從結構化到半結構化再到非結構化，數據的形式越來越自由，越來越向無模式的方向發展。基于關系數據庫存儲半結構化或非結構化數據，可以利用已經完善的SQL數據庫，降低開發者的學習曲線。Sinew是一個基于關系數據庫的系統，它在關系數據庫中定義了虛擬列，從而對鍵值對文檔進行存儲，實現了對半結構化數據的存儲［9］。可正是由于以關系數據庫為基礎，這個系統在對數據的拓展性和進行分布式處理時都有很大的障礙。因此，NoSQL數據庫呈現出了巨大的優勢。

圖數據庫是NoSQL中的一種，有學者提出使用圖數據庫存儲醫療數據，通過圖中的節點實現了更高的擴展性［10］。也有學者提出基于文本構造圖數據庫的方法［11］。但是圖數據庫中存儲的數據有一定的特征，如社交網絡中的數據。因為它更適合處理數據間的關系，對于節點本身屬性的處理沒有優勢。所以將沒有具體特征的數據轉存于圖數據庫中并不合適。

為了很好的利用NoSQL數據庫無固定結構的優勢，轉換后的數據模式不僅要符合所使用數據庫的特點，還可以有針對性的提高數據庫性能。一些學者探索了在NoSQL中，如何在最小存儲開銷中優化查詢性能［12］。他們提出的方法是在已知的模式中，用執行已定負載的成本引導從數據模型到物理模式的映射。可由于缺少目標NoSQL數據庫的成本模型和搜索可能查詢模式的方法，性能的比較是通過人工實現的，所以對于大量的數據，并不能說明這種映射可以更好的提高查詢效率。QODM［13］是一個面向查詢的工具，在工具中輸入NoSQL數據庫中數據存儲結構和應用程序對數據查詢的需要，就可以生成相應的數據模型和數據模式。可NoSQL并沒有固定的數據結構，這就需要使用第三方工具實現數據的轉換或遷移。

2　模型轉換設計

2.1基本轉換思維

MongoDB的邏輯結構是一種層次結構，它由數據庫（Database）、集合（Collection）和文檔（Document）組成［14］。在關系數據庫中，當查詢涉及多個表時，通常需要使用連接查詢。而由于MongoDB自身的特點，它不支持連接查詢。為了彌補這一缺陷，MongoDB提供DBRef方式關聯數據表，可這種關聯方式并不是性能最優的查詢方式。當把需要連接的內容放在一個集合中，也就是使用嵌套存儲方式時，會消除表間的連接，提高查詢效率。由于從關系數據庫遷移到MongoDB的數據多為用于數據分析的歷史數據，在MongoDB中對這些數據只做查詢操作，因此這種嵌套存儲方式不會影響MongoDB數據庫的完整性和一致性。

2.2FR圖元建模

使用元建模工具MetaEdit+對ER圖進行建模，建立ER圖的元模型，元模型建好后，使用逆向工程的方法從設計好的關系數據庫生成ER圖，然后使用“角色”對其進行遍歷。

2.3數據模式基本轉換

由于MongoDB是文檔類型的數據庫，所以在模型轉換時，ER圖中的實體型最終轉換為文檔集合，相關定義如下：

①E表示ER圖的實體型，表示E的值，即E的實體。Ei表示ER圖中第i個實體型；

②TE表示E最終生成的文檔集合；

③E.A表示實體型E中的屬性A。E.U表示E的屬性全集，即由E的全部屬性組成的集合。E.Apk表示E的主鍵，E.Afk表示E的外鍵，E.Aot表示E的其他屬性集合，即E.Aot=E.U-E.Apk-E.Afk；

④E.pk表示E在聯系中承擔的主鍵角色；

⑤E.fk表示E在聯系中承擔的外鍵角色；

⑥E.Tfk表示模式轉換后實體型E的E.Afk。

（1）單表模式轉換

當實體型E不參照任何其它實體型時，模型轉換前和轉換后沒有本質的區別。轉換圖如圖1所示。

圖1　單表模式轉換

（2）參照模式轉換

①簡單轉換

如圖2所示，實體型E1的主鍵為E1.Apk，外鍵為E1. Afk=E1.A2，其他屬性集合為E1.Aot=E1.B1。實體型E2的主鍵為E1.Apk=E2.A2，其他屬性集合為E2.Aot=E2.B2。可以看出，E2的主鍵E2.A2為E1的外鍵。

圖2　簡單轉換

在進行模式轉換時，實體型E2的所有屬性作為以E2.A2為節點的屬性集合存儲在E1中。也就是E1的外鍵不再是轉換前的E2.A2，而是包含E2的主鍵和其他屬性集合的集合。這樣數據結構就不再是轉換前的結構，而是將實體型連同其屬性作為一個文檔數據集合，內嵌于另一個實體型的屬性中，即：

（2）縱向擴展

在1:n聯系中，縱向擴展是指實體型E1參照E2，E2參照E3，依此類推，直至En-1參照En，而En不參照任何實體型。在模式轉換后，En的屬性集合En.U會作為En-1的外鍵存儲在En-1.Tfk中，此時En-1的屬性集合為En-1. U=En-1.Tfk∪En-1.Apk∪En-1.Aot；然后En-1的屬性集合En-1.U會作為En-2的外鍵存儲在En-2.Tfk中，En-2的屬性集合變為En-2.U=En-2.Tfk∪En-2.Apk∪En-2.Aot；依次遞推，就可得出如下結果：

綜上所述，在小兒支氣管哮喘急性發作治療中，采用布地奈德混懸液聯合吸入用異丙托溴銨治療效果更為顯著，有利于加速患兒臨床癥狀消失，提高其整體治療效果。

使用圖來表示轉換過程，如圖3。

（3）橫向擴展

橫向擴展是指實體型E1既參照E2，也參照E3、E4…，En，如圖4。此時有：

2.4ER模型轉換算法

充當外鍵角色的實體型其自身所包含的屬性信息是不完整的，因此，它的數據集合應該包含著它所參照的實體型。換句話說就是要將主鍵角色實體型的屬性內嵌于參照關系中外鍵角色實體型的屬性中，從而減少數據表與表之間的連接，提高查詢效率。

由于MetaEdit+是隨機確定遍歷實體型順序的，所以使用其對ER圖進行遍歷時，每一次的搜索順序都是不同的。如果從只含有主鍵角色的實體型開始遍歷，可以簡化遍歷算法。

圖3　縱向擴展

首先，從任意實體型開始，通過“角色”遍歷ER圖，找到某一個只充當主鍵角色而不充當外鍵角色的實體型，然后從該實體型開始查找其上層是否有外鍵角色實體型。如果沒有，則將該實體型轉換為一個單獨的文檔集合存儲在MongoDB中。若有則根據上層外鍵角色實體型找到其參照的所有實體型，將這些實體型分別轉換為一個單獨的文檔集合存儲在MongoDB中，再將它們連同自己的屬性存入上一層外鍵角色的實體型中。此時，這個上層外鍵角色實體型參照的所有實體型都轉換結束，就可以去除其外鍵角色將其看作只充當主鍵角色而不充當外鍵角色的實體型，繼續循環。

圖4　橫向擴展

3　實驗分析

為了驗證轉換后的內嵌文檔存儲模式對查詢性能的提高，需要在文檔數據庫中分別以內嵌文檔模式和單文檔模式存儲同一數據集并對比執行相同查詢時所需的時間。

3.1實驗數據

實驗使用了兩個數據集，分別來自關系數據庫SQL Server 2014的示例數據庫Business和文檔數據庫MongoDB的示例數據庫Northwind。根據前面所述的要求，我們將Business數據庫的數據分別以單文檔集合模式和內嵌文檔集合模式存儲在MongoDB中，并將Northwind數據庫的數據轉換為數據表的形式存儲在SQL Server 2014中。Northwind中實體型間參照關系最大為3層，Business中實體型間參照關系最大為4層。

3.2性能比較

根據數據結構，設計單表查詢語句和多重表連接查詢語句。圖5反映了隨著表連接數的增加，MongoDB中使用內嵌和非內嵌模式時查詢語句得出結果所需的時間。該結果證明了算法中內嵌數據的模式在某種程

度上提高了查詢性能，縮短了查詢所需要的時間。

圖5　內嵌模式和非內嵌模式查詢性能比較

從上圖中可以看出兩個數據集中內嵌模式比非內嵌模式的查詢性能要高，所需時間要短，并且隨著查詢所涉及數據表數量的增多，使用內嵌模式的優勢越明顯。在MongoDB中，不支持數據表的連接操作，所以在非內嵌模式下的查詢，需要在主鍵角色的文檔集合中篩選滿足條件的數據并把其查詢出的結果賦予一個變量，再將變量中的相關屬性作為條件在外鍵角色的文檔集合中進行查詢，最后返回查詢結果。由于需要對不同文檔集合的數據進行篩選和對中間變量的賦值和提取，會大大延長查詢時間，降低數據庫性能。而將關系數據庫中表間的連接關系轉換為內嵌結構只需要在一個文檔集合中進行操作，從而節省了操作所需的時間。

4　結語

本文提出了一種數據模式的轉換算法，這種算法利用MetaEdit+中的“角色”遍歷ER圖，實現了數據模式從關系數據庫到文檔數據庫的轉換，解決了數據從傳統的關系數據庫遷移到大數據環境下NoSQL類型數據庫中模式不同的問題，并通過實驗說明了轉換算法的正確性，驗證了在轉換后的內嵌模式下查詢性能的提高。

［1］Jaroslav Pokorny.Database Technologies in the World of Big Data［C］.Proceedings of the 16th International Conference on Computer Systems and Technologies.New York:ACM，2015:1-12.

［2］Zachary Parker，Scott Poe，Susan V.Vrbsky.Comparing NoSQL MongoDB to an SQL DB［C］.Proceedings of the 51st ACM Southeast Conference.New York:ACM，2013.

［3］申德榮，于戈，王習特等.支持大數據管理的NoSQL系統研究綜述［J］.軟件學報，2013，24（8）:1786-1803.

［4］John Klein，Ian Gorton，Neil Ernst，et al.Performance Evaluation of NoSQL Databases:A Case Study［C］.Proceedings of the 1st Workshop on Performance Analysis of Big Data Systems.New York:ACM，2015:5-10.

［5］王林彬，黎建輝，沈志宏.基于NoSQL的rdf數據存儲與查詢技術綜述［J］.計算機應用研究，2015，5（32）:1281-1286.

［6］孟曉峰，慈祥.大數據管理：概念、技術與挑戰［J］.計算機研究與發展，2013，50（1）:146-169.

［7］楊寒冰，趙龍，賈金原.HBase數據庫遷移工具的設計與實現［J］.計算機科學與探索，2013，7（3）:236-246.

［8］Gansen Zhao，Libo Li，Zijing Li，et al.Multiple Nested Schema of HBase for Migration from SQL［C］.Proceedings of Ninth International Conference on P2P，Parallel，Grid，Cloud and Internet Computing.2014:338-343.

［9］Daniel Tahara，Thaddeus Diamond，Daniel J.Abadi.Sinew:A SQL System for Multi-Structured Data［C］.Proceedings of the SIGMOD 2014.New York:ACM，2014:815-826.

［10］Manpreet Singh，Karamjit Kaur.SQL2Neo:Moving Health-care Data From Relational To Graph Database［C］.Proceedings of IACC.Piscataway，NJ:IEEE，2015:721-725.

［11］S.Jeon，Y.Khosiawan，B.Hong.Making a Graph Database from Unstructured Text［C］.Proceedings of Computational Science and Engineering.Piscataway，NJ:IEEE，2013:981-988.

［12］Michael J.Mior.Automated Schema Design for NoSQL Databases［C］.Proceedings of SIGMOD 2014.New York:ACM，2014:41-45.

［13］Xiang Li，Zhiyi Ma，Hongjie Chen.QODM:A Query-Oriented Data Modeling Approach for NoSQL Databases［C］.Proceedings of WARTIA.Piscataway，NJ:IEEE，2014:338-345.

［14］Veronika Abramova，Jorge Bernardino.NoSQL Databases:MongoDB VS Cassandra［C］.Proc of the International C*Conference on Computer Science and Software Engineering.New York，2013:14-22.

Schema Conversion；Document Database；MongoDB；NoSQL

An Algorithm for Schema Conversion from Relational Databases to Document-Oriented Databases

WANG Hai-lin，ZHANG Ya-jun
（College of Information Management，Shanxi University of Finance and Economics，Taiyuan 030006）

山西省回國留學人員科研資助項目（No.2013076）

1007-1423（2016）18-0018-06

10.3969/j.issn.1007-1423.2016.18.004

王海林（1962-），男，副教授，碩士，研究方向為數據建模、大數據、分布式系統、數據可視化張雅君（1992-），女，碩士研究生，研究方向為數據挖掘、數據建模

2016-06-07

2016-06-20

文檔數據庫是NoSQL數據庫的一種，它與關系數據庫在數據結構上存在較大差異。為了解決關系數據庫與非關系數據庫模式不同的問題，實現數據從關系數據庫向非關系數據庫的轉換，以文檔數據庫MongoDB為例，利用元建模工具MetaEdit+中的“角色”遍歷ER圖，提出從關系數據庫到文檔數據庫的模式轉換算法。這種算法不僅解決傳統關系數據庫與文檔數據庫模式不同的問題，而且使得轉換后的模式對數據庫查詢性能有顯著的提高。實驗結果說明這種轉換的正確性以及模式對于查詢的高效性。

數據模式轉換；文檔數據庫；MongoDB；NoSQL

The document-oriented database is one of NoSQL databases；its schema is different from relational databases.In order to implement the conversion from relational databases to NoSQL databases，based on MongoDB，proposes an algorithm which achieves schema conversion of relational databases to document-oriented databases by traversing ER-Diagram in MetaEdit+which is one of tools for metamodeling. The algorithm not only solves the different schema problems between traditional relational databases and document-oriented databases，and the transformed model improves the performance of the database query.Finally，the experiment has shown the correctness of the algorithm and the high performance of join operation.