面向多源异构数据库的SQL_解析与转换方法研究

第 22卷第 12期2023年 12月
Vol.22 No.12
Dec.2023软件导刊
Software Guide
面向多源异构数据库的SQL解析与转换方法研究
练金栋1，陈志1，岳文静2，赵培1，3，吕伟初1，3
（1.南京邮电大学计算机学院； 2.南京邮电大学通信与信息工程学院，江苏南京 210003；
3.金篆信科有限责任公司，江苏南京 210012）
摘要：传统的单一数据库模式难以适应如今多样化的数据管理需求。

如何将多个异构独立的数据库进行集成，对
数据库系统进行整体控制和协同操作成为研究热点。

针对此问题进行面向多源异构数据库的SQL解析与转换方法
研究，通过建立通用的中间表示模型，对异构数据库请求进行语法树解析、语义分析与模型转换，实现了不同数据库
之间的互操作。

在基于TPC-H基准测试数据集的功能测试中，测试系统对数据类型和语法操作的支持度达到
100%。

在性能测试中，测试系统在跨平台的增删改查操作时间上，较官方工具分别快了13.1 ms、8.8 ms、22.5 ms与
2.3ms。

实验验证了该方法的正确性与可行性。

关键词：异构数据库；中间表示；语法解析；语法转换
DOI：10.11907/rjdk.232028开放科学（资源服务）标识码（OSID）：
中图分类号：TP391 文献标识码：A 文章编号：1672-7800（2023）012-0124-08
Research on SQL Parsing and Transformation Method for Multi-Source
Heterogeneous Database
LIAN Jindong1， CHEN Zhi1， YUE Wenjing2， ZHAO Pei1，3， LYU Weichu1，3
（1.School of Computer Science， Nanjing University of Posts and Telecommunications；
2.School of Communications and Information Engineering， Nanjing University of Posts and Telecommunications， Nanjing 210003， China；
3.JINZHUAN Information Technology Co.， Ltd.， Nanjing 210012， China）
Abstract：Nowadays， the traditional mode with single database has difficulty meeting with the demand of in diversified data management. The integration of multi-mode heterogeneous databases has become a research hotspot for overall control and collaborative operation of the global database system. Aiming at this problem， this paper studies the SQL parsing and transformation methods for heterogeneous databases. And in‐teroperability between different database has been achieved through universal intermediate-representation-model establishing，syntax tree parsing， semantic analysis and model transformation. In the functional test based on the TPC-H benchmark dataset， the frame-based test sys‐tem has 100% support for data types and syntax operations， while the framework has advantages over official tools in terms of operation speed for cross platform addition， deletion， modification， and query， with 13.1 ms， 8.8 ms， 22.5 ms， and 2.3 ms， respectively. The experiment ver‐ifies the correctness and feasibility of the proposed method.
Key Words：heterogeneous database； intermediate representation； syntax parsing； grammar transformation
0 引言
随着数据量的爆发式增长，传统的单一数据库模式愈发难以满足存储和查询的实时性要求。

数据结构呈现多样化趋势，多种存储类型的数据库并行交互［1-2］，各行业内部出现不同部门存在数据壁垒、数据共享消耗大量资源、数据流转和融合处理成本上升、数据一致性难以保证等问题［3］。

为了满足各行各业对数据应用的需求，企业开始根据自身业务特点，采用多种数据库产品管理业务数据，形
收稿日期：2023-10-06
基金项目：江苏省重点研发计划（社会发展）项目（BE2019739）；中兴通讯产学研合作基金项目（2021H2ZTE05-01）
作者简介：练金栋（1998-），男，南京邮电大学计算机学院硕士研究生，研究方向为数据库技术；陈志（1978-），男，CCF会员，南京邮电大学计算机学院教授，研究方向为软件工程、无线传感网、计算机视觉；岳文静（1982-），女，南京邮电大学通信与信息工程学院副教授，研究方向为信号处理、边缘计算、计算机视觉；赵培（1973-），男，南京邮电大学计算机学院兼职“江苏省产业教授”，金篆信科有限责任公司高级工程师，研究方向为软件工程、分布式数据库；吕伟初（1978-），男，南京邮电大学计算机学院兼职“江苏省产业教授”，金篆信科有限责任公司高级工程师，研究方向为软件工程、分布式数据库。

本文通讯作者：陈志。

第 12 期练金栋，陈志，岳文静，等：面向多源异构数据库的SQL解析与转换方法研究
成了不同技术解决不同场景应用问题的局面［4］：企业会以Oracle、MySQL、PostgreSQL等多个主流数据库管理数据；各部门的数据会以CSV、XML、JSON等不同文件类型分别进行存储；各类实时业务会采用HBase、MongoDB、Neo4J等数据库进行数据处理与分析。

研究表明［5］，每个企业应用程序至少都涉及两到三种不同类型的查询系统，许多现实的分析业务也提出了便捷、高效地执行跨平台查询的需求。

针对这一情形，研究人员开展了大量针对多源异构数据库的跨平台、统一操作技术的研究［6-7］。

然而，与数据库系统的快速发展相对的，已有的异构数据库集成操作在易用性、统一性与高效性方面都存在一定的不足［8-10］。

首先，现有工作尚未提供一个适用于跨平台查询的统一的SQL查询语言，易用性不高；其次，由于异构数据库不同的特性和各异的语法规则，数据库之间的相互访问需要通过编写数据转换接口来实现，学习成本高且工作量大，扩展性不足。

此外，现有工作大多只能针对单一的跨平台SQL査询进行优化，可能严重影响跨平台查询性能。

为了解决以上问题，本文开发了一套高效、灵活且具有跨平台特性的多源SQL解析转换方案。

该方案设计了一种能描述异构数据库执行逻辑的中间表示模型，通过该模型来隐藏底层库的差异性，从而实现对异构数据库的统一解析建模和映射转换，满足多种数据集中存储、查询和修改的业务需求，提高数据处理效率和灵活性。

1 相关工作
SQL和NoSQL数据库都有着各自的适用场景，并能满足特定的数据需求与应用目标，因此将多种SQL与NoSQL 数据库进行集成，实现异构数据库的统一管理和互操作，可以让不同数据库系统在功能方面进行有机结合，发挥各自的优势，从而利于提升数据处理效率，灵活应对各种类型数据的查询需求［11］。

目前的研究成果主要集中在SQL与NoSQL的集成融合系统以及支持数据相互访问的标准化API上。

文献［12］通过将key-value数据转换合并到关系模型，实现利用PostgreSQL对MongoDB进行操作，证明了在关系型和NoSQL数据存储上集成统一操作的可能性；文献［13］提出基于SQL模型的映射算法，通过SQL查询扩充来实现每个SPARQL代数运算符，并生成高效的SQL查询；文献［14-16］通过设计模式映射和查询映射方法，实现了关系型数据库与RDF平台的互操作。

但此类研究只简单堆积了少数SQL和NoSQL数据库，仅适用于涉及两三类不同数据库的小型业务，不具备通用性。

另一些研究进一步尝试设计统一适配器的方式，通过向统一数据中间模型动态提供适配数据，实现异构数据库的SQL统一查询。

文献［17］提出一种为每种SQL语句定制正则表达式的方法解析SQL，并
通过扩展XQuery实现对MongoDB数据库的操作；文献［18-20］通过将关系表、键值对、CSV文件、JSON文件等结构化与半结构化数据转换为临时关系表结构，以单一数据库语法操作实现多数据源的统一查询。

此类方法的局限性在于要求在异构数据库之间设计数据转换接口，以实现相互访问，工作量大，扩展性很差。

本文对上述方案的设计思想和方法进行参考与总结，设计了一套通用的异构数据库解析转换方案，通过设计统一中间表示模型来隐藏异构数据库在查询语言和数据格式上的差异，实现多种关系型和NoSQL数据库的统一解析与转换，生成统一的逻辑查询计划实现底层库的操作请求，同时保证了较好的可扩展性。

2 基于SQL语法的中间表示模型
由于Oracle、MySQL、DB2等基于ANSI-SQL标准开发的关系型数据库仍被广泛应用。

本文采用以SQL语法为基础、引入多种NoSQL语法模型的模式设计异构数据库的中间表示模型。

该模式降低了数据模型之间的开发和维护成本，并为满足特定业务需求提供了更强的灵活性。

2.1　异构语法转换模式
由于不同数据库系统的数据存储模型不同，在数据命名、数据类型、数据结构方面存在差异［21-22］，需要设计不同语法模型之间的转换策略。

如图1（a）所示的传统多对多转换模式，两个异构数据库之间直接进行数据转换，转换效率高，但n个异构数据库节点的双向操作必须编写n*（n-1）个数据转换器。

如果新增一个异构数据库类型，则需要开发2n个转换器，导致开发维护成本高、可扩展性差。

本文采取图1（b）所示的中介转换模式，即通过设计一种中间模型，为所有的数据库指令提供统一的元数据描述格式，并通过转换器实现从源库数据转换为中间模型、再由中间模型转换为目标库数据的间接转换模式。

该方案仅需编写2n种转换器，当增加、修改一个数据库存储模型时，只需编写新数据库模型与通用模型的语法转换器，其它同步节点的数据转换模块保持不变。

该模式屏蔽了底层数据库之间的差异，极大地降低了开发难度，并考虑了一定的扩展性。

2.2　中间表示模型设计
中间表示模型在解析SQL语句对数据集合的计算操作后，以结构化形式描述SQL各个子句语法块。

模型参考文献［23-25］的设计框架，以实体（Entity）作为对所有SQL 语法块的统一描述，并将部分实体进一步划分为语句（St‐
mt）和表达式（Expr）。

即：
stmt⊆entity，expr⊆entity，stmt∪expr⊆entity（1）Stmt实体存储SQL语句执行计划的基本步骤，Expr实体存储执行计划的具体数据，其他实体负责对Stmt和Expr
·
·125
2023 年
软件导刊作进一步描述。

统一的中间表示模型的形式化表示如下：
entity =Type ， Field ， Attribute ， Relation ， Map
（2）
其中，Type 表示实体类型，Stmt 实体类型包括IN‐
SERT 、SELECT 、CREATE_TABLE ，Expr 实体类型包括Nu‐meric 、Literal 、Logical 等；Field 表示一系列实体集合，即当前实体的所有子句类；Attribute 表示实体内部属性，即SQL 请求的元数据信息；实体关系Relation∈（Entity×Entity ）用于描述实体间的语义关联，包括字符常量与数据表（Ta‐ble ）、数值与数据结构（Datatype ）；Map 表示此实体的映射转换方法。

以查询语句的From 子句为例，在标准 SQL 语句中，
From 子句既可以由单个引用表实体组成，又可以由多个引
用表实体通过各种形式的连接（Join ）构成：
fromClause ={<tableSource L ，joinType ，tableSource R ，condition >
|tableSource S ，tableSource D ∈entity ⋀ conditon ∈expr ⋀ joinType ∈{SQL 连接类型集合} }
（3）
其中，tableSource 实体用于描述引用表，即参与数据查
询的关系表结构，按连接关系分为tableSource L 和
tableSource R 。

joinType 是一个枚举
（Enum ）属性，代表Join 连接操作类型，包括INNER_JOIN 、LEFT_JOIN 、
RIGHT_JOIN 等。

condition 是Expr 实体的子类，用于描述SQL 语句的可嵌套逻辑关系式，在fromClause 实体中用于指定tableSource L 和tableSource R 的连接条件。

其形式化表示为：
condition ∈{logicalExpr ，comparisonExpr }
（4）
其中，logicalExpr 和comparisonExpr 分别表示可嵌套的
逻辑表达式与关系表达式，在SELECT 、UPDATE 、DELETE
等操作中指定数据筛选条件，通过运算符优先级进行划分。

一个logicalExpr 可以由一个comparisonExpr 组成，也可以由若干可嵌套逻辑表达式（nestedLogicalExpr ）和逻辑运算符号（AND 、OR 和NOT ）组合构成，以筛选出符合指定逻辑规则的数据行。

logicalExpr 的形式化表示如下：
logicalExpr ∈{comparisonExpr ，nestedLogicalExpr }（5）
nestedLogicalExpr ={<left ，logicalOp ，right ，isNot >| left ，right
∈logicalExpr ⋀logicalOp∈｛AND ，OR ｝⋀isNot∈｛true ，false ｝｝
（6）
其中，comparisonExpr 用于根据特定条件比较两个值或列之间的大小关系以筛选数据。

形式表达式如下： comparisonExpr ={ <value1，compOp ，value2>
|value1，value2∈unaryExpr ⋀ compOp ∈{关系运算符集合} }
（7）
其中，compOp 是关系运算符（如=、<、>、<=、！=等）的
集合，表示值或列的比较方式；unaryExpr 实体用于表示计算表达式以及对象名、变量、常量等，是SQL 标准语句中的基本参数。

其形式化表示如下： unaryExpr ={<value ，unaryOp ，dataType >|unaryOp
∈{一元操作符集合} ⋀ dataType ∈{Integer ，Char ，Varchar ，Float }}
（8）
以上实体构成了Expr 的形式化表示，其中一元表达式
的value 代表整数、浮点数、字符串、标识符等，用Java 包装类型进行存储；unaryOp 是正负号、引号等常规符号的集合；dataType 表示literal 存储数据的数据类型。

3 面向多源异构语法的统一SQL 解析转换器
面向多源异构语法的统一SQL 解析转换器参照传统数据库的编译流程，将解析与转换功能划分为语法解析器、语义分析器、语法重构器、查询优化器等组件，执行流程如图2所示。

首先根据语法文件生成SQL 语法的词法和语法分析器，组成语法解析器；然后将SQL 语句输入对应的语法解析器，生成抽象语法树（Abstract Syntax Tree ，AST ）；接下来使用语义分析器遍历访问抽象语法树，提取特征信息，封装为中间表示模型并进行语义分析；语法重
写器根据前台指定的目标库类型，选取相应转化策略对中间模型进行映射，使其转换为能在目标平台执行的逻辑执行计划；最后，执行优化器可以对逻辑执行计划作进一步优化处理，以提高可执行性。

3.1　语法解析器
语法解析器（Syntax Parser ）由ANTLR 工具生成的词法分析器（Lexer ）和语法分析器（Parser ）组成，负责在语法规则的支持下，经过词法解析和语法解析将查询语句编译成AST 结构。

以SQL 语法为例［26］：词法分析器负责分析词法结果，即通过拆解SQL
语句将输入的字符序列分解成词法
（a ）　M-N conversion mode （a ）　多对多转换模式
（b ）　Mediation conversion mode
（b ）　中介转换模式
Fig. 1　Grammar conversion mode
图1　语法转换模式
··126
第 12 期练金栋，陈志，岳文静，等：面向多源异构数据库的SQL解析与转换方法研究
符号（token）序列。

其中，token 是语法的基本词汇符号，可分为5种类型：①保留字（keyword）。

由固定字符序列组成，如select、table、case等；②标识符（identifier）。

如常量名、表名、属性名；③文字常量（literal）。

包括25、4.14、4e3等数字常量，以及“abc”“cid”字符串；④运算符（operator）。

常用的包括算术运算符（+-*/）、关系运算符（<，>，<=，！=）和逻辑运算符（NOT、AND、OR）；⑤分隔符（separator）。

如小括号、中括号、逗号等，负责对标识符进行规范。

语法分析器则通过检查token的序列结构是否符合语法规则，判断语句是否合法，并把token按照语法规则进行模式匹配，组装成AST结构。

3.2　语义分析器
语义分析是编译过程中的一个逻辑阶段，负责收集抽象语法树标识符的属性信息并与节点绑定，审查SQL查询请求有无语义错误，例如库表、列名是否存在，列的数据类型是否正确，为逻辑计划树生成收集类型信息。

语义分析器（Semantic Analyzer）通过ANTLR提供Visi‐tor访问模式按深度优先顺序遍历语法分析树，通过显式的方法调用来获取子节点信息，生成逻辑执行树结构。

具体算法如下：
算法1 语义分析算法
输入：抽象语法树节点TreeNode
输出：中间表示IR
1. function visitTreeNode
2. IF TreeNode IS StmtContextNode THEN
3. stmtModel←buildStatement（TreeNode）
4. FOR node IN TreeNode.getChildren（） DO
5. clauseModel←visitTreeNode（node）
6. stmtModel.setProperty（clauseModel）
7. END FOR
8. RETURN stmtModel
9. ELSE IF TreeNode IS clasueContextNode THEN
10. clauseModel←buildClause（TreeNode）
11. FOR node IN TreeNode.getChildren（） DO
12. exprModel←visitTreeNode（node）
13. clauseModel.setExpr（exprModel）
14. END FOR
15. RETURN clauseModel
16. ELSE IF TreeNode IS exprContextNode THEN
17. exprModel←parseExpr（TreeNode）
18. RETURN exprModel
19. ELSE IF TreeNode IS TerminalNode THEN
20. RETURN parseUnaryExpr（TreeNode.getText（））
21.END function
算法1以深度优先、自底向上的顺序对AST进行遍历，将语法树节点与元数据绑定，引入2.2节建立的中间表示模型，同时结合上下文进行语义分析。

对于整数、字符串及复合表达式等Expr实体，算法按类型判断参数类型是否匹配、逻辑是否有歧义、是否超出变量范围等，接着按照具体值域类型生成继承表达式类；对于增删改查等Stmt实体及其内部元素，算法先判断是否存在重复声明属性、形参与实参不匹配、属性不存在等语义错误，再根据具体SQL 语句类型和子句类型封装语法块的语义。

最终逻辑执行树能完整描述SQL的逻辑执行步骤。

以查询请求“SELECT * FROM people WHERE status = "A" ORDER BY user_id DESC”为例，划分SQL各语法块并通过分析可知：查询实体为people表，以status = "A"为筛选条件获取实体所有属性，并将结果集根据user_id列递减排序。

算法1生成的中间表示对应的JSON格式化描述如下：
｛
"type"： "statement"， "attribute"： "simpleSelect"，"result"：［｛"type"："selectItem"，"attribute"："column"，"value"： "*" ｝］，
"from"：｛"type"："tableSources"，"attribute"："table"，"val‐ue"： "people" ｝，
"where"：［｛
"type"： "condition"， "format"： "binary"， "operator"： "="，"left"：｛"type"："expression"，"attribute"："column"，"value"："sta‐tus"，"link"："from"."value"
｝，
"right"：｛"type"："expression"，"attribute"："literal"，"value"："A"，"link"： "left"."value"
｝
｝］，
"order"：［｛
"type"： "orderBy"， "attribute"： "order"，
Fig. 2　SQL parsing and conversion process 图2　SQL解析转换流程
··127
2023 年软件导刊
"expression"：｛"type"："identifier"，"attribute"："column"，"value"： "user_id" ｝，
"mode"： "desc"
｝］
｝
在语义分析与实体封装过程中，模块判断people表是否存在，以及是否存在status、user_id等表属性、status属性是否为varchar类型数据等。

此外还会检查user_id是否为people表索引，若是，则在Query语义树中标记其索引名为“user_id”以及对应的索引类型。

3.3　语法重写器
语法重写器（Syntax Rewriter）负责接收语义分析器生成的逻辑执行树，若目标数据库为关系型数据库，则可通过transform转换策略将中间表示内部属性、变量进行修改，实现源实体entity src到目标实体entity target的转换。

以Oracle到MySQL的转换为例，部分转换策略如表1所示。

若目标数据库是NoSQL类型，则将中间表示转换为对应的NoSQL语法。

SQL与NoSQL的部分对象映射关系如表2所示。

关系型数据库的表、列、属性和数据对象分别与NoSQL数据库MongoDB的集合、文档、字段、值等数据结构对应。

在分析器生成SQL的逻辑查询树后，通过此映射关系将SQL数据一一转换为NoSQL形式，以实现SQL逻辑执行树的重构。

以MongoDB为目标对象，其转换算法如下：
算法2 模型转换算法
输入： SQL语句对应的语法模型stmtModel
输出： MongoDB逻辑执行计划targetPlan
1. function convertBson
2. targetPlan←createPlanner（）
3. targetPlan.appendCollectionName（stmtModel.getTable⁃Name（））
4. SWITCH stmtModel.getType（） THEN
5. targetPlan.setCurdOperator（type）
6. END
7. FOR entity IN stmtModel.getProperties（） THEN
8. operation←toNosqlMap（entity）
9. field←parseField（stmtModel.getReference（））
10. value←parseValues（stmtModel.getExprList（））
11. pair←createPair（field，value）
12. targetPlan.appendOperation（field，value）
13. END FOR
14. RETURN targetPlan
15. END function
3.4　查询优化器
若目标数据库是关系型，则调用查询优化器（Query Optimizer）对目标SQL请求进行优化。

查询优化器采用基于规则的优化（RBO）方式定义一系列优化规则，包括列剪裁、最大最小消除、投影消除、谓词下推、Join消除等，优化规则与表1原理一致。

优化器搜索过程可视为根据指定的优先顺序循环判断SQL各语块是否匹配优化格式（Pat‐tern），若符合则按照优化规则（Rule）对SQL语句进行优化，并重新进入循环，直到没有可以匹配的语块，从而完成优化。

以“获得满分成绩的学生查询”为例，常用的SQL写法为：SELECT * FROM Student t ， Grade g WHERE t.S_id = g. S_id AND g.score = 100。

该Select语句对应的关系代数为：σt.sid=g.sid^g.socre= 100(Student⊳⊲Grade)（9）根据代数式可知，语句在执行时数据库会先全表扫描全部的Student学生信息表和Grade学生成绩表，然后才根据where条件进行筛选，因而提高了查询计算量。

这种情况可以通过谓词下推，将过滤条件表达式（如=、！=、like、in、between等）尽量靠近待过滤的数据源（Student表和Grade表），即先将通过过滤条件“grade=100”筛选Grade表中的数据，再进行连接操作，以达到优先过滤无用数据、提升SQL执行效率的目的。

对应关系代数为：
Student⊳⊲
t.sid=g.sid(σscore=100(Grade)
)（10）
转换成对应语句为：SELECT * FROM Student t1 RIGHT JOIN（SELECT * FROM Grade WHERE grade = 100 ） t2 ON t1.S_id = t2.S_id。

转换前和转换后的关系表达树如图3所示。

如图3所示，在数据库执行查询操作时，逻辑执行计划根据关系表达树中的操作符逐步向上计算，直到根节点（整个表达式）的计算完成。

因此，通过谓词下推，数据库在内查询时就先过滤了Grade表中的大部分无用数据，极大地减少了临时表的空间开销，提高了查询效率。

4 实验与结果分析
为验证面向多源异构数据库的SQL解析转换器在实际开发环境中的应用，本文基于方案实现了一个多源异构数据库的统一操作系统，旨在检验解析转换器在异构数据库间跨平台访问的可靠性、正确性和高效性。

功能测试主要验证查询系统在多源异构、跨平台环境下数据库对基本
Table 1　Transformation strategies
表1　转换策略
序号S1
S2 S3 S4 S5
策略
operatorStrategy
dataTypeStrategy
functionStrategy
rownumStrategy
groupStrategy
实体
Operators
Data types
Functions
Query blocks
Group extensions
转换实例
转换前
strA||strB
Number（p，s）
Length（string）
Rownum <= n
Rollup（A，B）
转换后
Concat（strA，strB）
Decimal（p，s）
Char_length（String）
Limit n
A，B With Rollup
Table 2　Relational mapping between SQL and NoSQL objects 表2　SQL与NoSQL对象关系映射
中间模型关系模型文档模型图模型
实体
表（Table）
集合（Collection）
节点标签（Label）
属性
列（Col）
字段（Field）
节点属性（Property）
基本单元
行（Row）
文档（Document）
节点（Node）
排序结构
索引（Index）
索引（Index）
索引（Index）·
·128
第 12 期练金栋，陈志，岳文静，等：面向多源异构数据库的SQL 解析与转换方法研究操作的支持度，以及核心查询业务的可靠性，性能测试主要验证解析转换器基本增删改查操作的性能。

4.1　环境配置
操作系统以Java 编程平台作为运行平台，分别使用
Oracle 、MySQL 和MongoDB 存储关系型和非关系型数据，并基于TPC-H 基准测试数据集进行功能测试和性能测试，实验中针对不同测试单元对数据集进行相应处理。

具体实验环境参数如表3所示。

4.2　功能测试
4.2.1　数据类型支持度
为测试本系统对各结构化、半结构化数据的支持度，
先导入完整的包含各种类型的测试数据集（所有数据均不包含NULL 和NAN 值）。

为维护执行效率，各底层库随机导入数据集数据1万条，再使用简单的query 操作语句对数值型、字符型和时间日期型数据进行查询与解析，检验最终的返回结果是否与映射表相符，以及是否存在非法值或
缺失。

其中，数据类型映射基于SQLines 技术文档（Oracle 映射至MySQL 类型映射表：http ：///oracle-to-mysql ）进行整合，部分映射如表4所示。

经自定义函数对查询结果进行数据统计和异常值检验，最终的实验结果表明，系统支持对所有已集成数据库
的数据类型进行解析、存储和映射转换。

4.2.2　操作类型支持度
本系统已集成的数据库有Oracle 、MySQL 和Mon‐
goDB ，本节测试其对于SQL 各种操作类型的支持度。

实验涉及的SQL 语句主要面向与具体数据操作相关的环境，所以在实验论证中只对关系型数据库的部分DDL 语句和
DML 语句，以及NoSQL 的标准CURD 语句进行实验验证。

实验分别在Oracle 、MySQL 及MongoDB 数据库创建相应的数据集，并对多源异构数据执行增删改查操作。

实验结果如表5所示。

其中，NoSQL 的CURD 操作对应关系型数据库的DML 语句。

MongoDB 的数据存储类型是BSON 文档，可以通过insert （）、update （）、delete （）方法动态指定集合（Collec‐tion ）、文档（Document ）内部field 的数据类型。

因此，Mon‐goDB 对数据存储对象的DDL 操作不纳入测试。

由表5可知，解析转换器支持所有常见关系型数据库之间的DDL 与
DML 互操作，以及关系型与NoSQL 的CURD 互操作。

4.3　性能测试
性能测试通过将系统与官方的mongo-jdbc 插入、删除、更新和选择操作的时间开销进行对比，以评估多源异构解析转换器的SQL 覆盖率和各项访问操作的性能。

为有效评估解析转换器的跨平台访问性能，本节引入Mon‐goDB 官方推出的mongo-jdbc 驱动插件，使用SQL 对Mon‐
student
grade
σt.sid=g.sid
^ g.score=100
（a ）　Original relationship expression tree
（a ）　原关系表达树
student
grade
t.sid=g.sid
σscore=100
（b ）　Optimized relationship expression tree
（b ）　优化后的关系表达树
Fig. 3　Query optimization - predicate pushdown
图3　查询优化—谓词下推
Table 3　Environmental configuration table
表3　环境配置表
环境硬件环境
软件环境
配置CPU
内存磁盘操作系统
编程语言数据库配置参数
Intel （R ） Core （TM ） i7-7700HQ
8GB 512G SSD Windows 10Java MySQL 8.0、Oracle 12c MongoDB 5.0.15-rc0
Table 5　Support for SQL statement 表5　对SQL 语句类型支持情况
语句DDL
DML/CURD
语句类型
CREATE （TABLE/VIEW/INDEX ）ALTER （TABLE/VIEW/INDEX ）DROP （TABLE/VIEW/INDEX ）
TRUNCATE TABLE
SELECT INSERT UPDATE DELETE 支持情况支持支持支持支持支持支持支持支持
Table 4　Data types mapping
表4　数据类型映射
Oracle 数据类型
INTEGER
FLOAT （p ）REAL
CHAR （n ）VARCHAR （n ）DATE TIMESTAMP MySQL 数据类型
INT
DOUBLE CHAR （n ）
VARCHAR2（n ）DATETIME DATETIME
PostgreSQL 数据类型DECIMAL （38）
DOUBLE PRECISION CHAR （n ）VARCHAR （n ）TIMESTAMP （0）
TIMESTAMP MongoDB 数据类型integer double string date
timestamp ·
·129
2023 年软件导刊
goDB进行异构访问，分别让MongoDB数据库、mongo-jdbc 和测试系统执行1 000次INSERT、UPDATE、DELETE与SELECT操作，测试结果如表6所示。

其中，每个操作对应的执行时间为执行的平均时间，单位为毫秒（ms）。

实验数据表明，查询系统在CURD操作方面的总体性能优于mongo-jdbc。

在同等条件下，测试系统执行CURD 操作的响应时间较官方工具分别快了13.1 ms、8.8 ms、22.5 ms与2.3 ms。

其中，由于INSERT操作的平均单次响应时间较短，因此延迟率高，但平均响应时间仅为mongo-jdbc的49%。

在SELECT查询操作上，系统较官方驱动程序平均仅快2.3 ms，没有明显优势，主要由于相较于增删改操作，查询样例涉及嵌套查询、连接表、过滤条件式等复杂的query业务，在解析优化和底层执行方面开销更多，因此平均执行和响应时间更长。

以上结果表明，面向多源异构数据库的SQL解析转换器相较于mongo-jdbc有着更优异的性能，且其运算成本始终保持在一个固定范围内，与操作类型无关。

实验结果证明，面向多源异构数据库的SQL解析转换器在功能和性能方面可满足预期需求，有效实现了对多个异构数据库的集成操作，且能保证一定的正确性。

5 结语
本文提出一种满足跨平台统一查询需求的SQL解析和转换方法，详细设计了一系列查询语言的适配存储结构和语义一致性转换及性能优化策略，允许用户在异构关系数据库和NoSQL数据库上进行准确、可靠的SQL操作，屏蔽了不同执行平台间在语法逻辑、底层机制方面的差异，将多个异构数据库转换为一个统一的模式，并通过设计测试系统进行功能和性能验证，证明了解析转换器的可行性。

实验结果表明，面向多源异构数据库的SQL解析和转换方法在满足多源异构数据库跨平台访问功能需求的同时，还具有较好性能，且在集成系统的多对多数据访问环境下具有良好的可扩展性和准确性。

由于条件和时间限制，本文仍有诸多不足，有待进一步研究和改进，主要改进方向有：①增加对更多异构数据库的适配访问和操作业务支持。

目前跨平台解析转换方案仅实现了对Oracle、MySQL和MongoDB等若干数据库的支持，对数据和事务的一致性支持尚不够全面，难以支持复杂的业务操作；②提升跨平台解析转换方案面对真实海量数据处理业务的性能。

实验的测试数据在数据规模和复杂度上与真实业务差距较大，需要将方案置于接近真实海量数据环境中进行测试与改进；③进一步完善跨平台执行优化模块。

目前优化器主要基于传统经验编写一系列静态策略以实现查询优化，在开发和使用效率上具有局限性，可以引入基于代价的优化（CBO）算法，获得所有等价的重构变换方案，进一步提升查询性能。

参考文献：
［1］ XIA Z X， LUO S M， SUN Y H， et al. Design， implementation and prac‐tice of parallel processing system for large-scale heterogeneous data［J］.
Big Data Research， 2020， 6（4）： 18-29.
夏正勋，罗圣美，孙元浩，等.大规模异构数据并行处理系统的设计，实现与实践［J］.大数据， 2020， 6（4）： 18-29.
［2］ CORBELLINI A，MATEOS C，ZUNINO A，et al.Persisting big-data：the NoSQL landscape［J］. Information Systems， 2017， 63（1）： 1-23.［3］ QIAO W. A method for integrating heterogeneous databases based on XML ［P］.China，112100457A， 2020-12-18.
乔玮.一种基于XML的异构数据库集成方法［P］.中国，112100457A， 2020-12-18.
［4］ HUANG Y H，ZHU G H，YIN L L. A unified cross-platform big data SQL query method［P］.China， 110059103A， 2019-07-26.
黄宜华，朱光辉，尹良良.一种跨平台统一的大数据SQL查询方法［P］.中国， 110059103A， 2019-07-26.
［5］ DENG C Z. A unified SQL query system supporting multi-source heteroge‐neous data［P］. China， 115129735A， 2022-09-30.
邓昌智.一种支持多源异构数据的统一SQL查询系统［P］.中国，115129735A， 2022-09-30.
［6］ AICHA A， MOHAMED N S. P3 Process for object-relational data migra‐tion to NoSQL document-oriented datastore［J］.International Journal of
Software Science and Computational Intelligence， 2022， 14（1）： 1-20.［7］ LIU P Y， WANG H T， ZHENG D Y， et al. Design of a multi-source het‐erogeneous cultural big data fusion platform［J］. Journal of Huazhong Uni‐
versity of Science and Technology （Natural Science Edition），2021，49 （2）： 95-101.
刘盼雨，王昊天，郑栋毅，等.多源异构文化大数据融合平台设计［J］.华中科技大学学报（自然科学版）， 2021， 49（2）： 95-101
［8］ LI L M.Application scenarios of relational and NOSQL databases［J］.
Electronic Technology and Software Engineering， 2022（16）： 184-187.
李立猛.关系型数据库与NOSQL数据库的应用场景［J］.电子技术与
软件工程， 2022（16）： 184-187.
［9］ CHANG M L， CHUA N H. SQL & NoSQL database comparison： from per‐formance perspective in supporting semi-structured data［C］// Future of In‐
formation and Communication Conference， 2018：294-310.
［10］ STONEBRAKER M. SQL databases v. NoSQL databases ［J］. Communi‐cations of the ACM， 2010， 53（4）： 10-11.
［11］ WEI J H， XIA Y F， GONG X Q. Survey on multi-query sharing technol‐ogy［J］. Journal of Software， 2021， 32（10）： 3176-3202.
危剑豪，夏烨峰，宫学庆.多查询共享技术研究综述［J］.软件学报，
2021， 32（10）： 3176-3202.
Table 6　Comparison of CURD performance testing 表6　CURD性能测试结果对比
操作SELECT INSERT UPDATE DELETE 数据库响应
时间/ms
258.9
128.7
303.4
275.9
mongo-jdbc
执行时
间/ms
272.3
154.6
339.2
296.3
△T /
ms
13.4
25.9
35.8
20.4
延迟
/%
5.2
20.1
11.8
7.4
测试系统
执行时
间/ms
267.6
136.5
310.7
282.7
△T /
ms
15.7
12.8
13.3
11.6
延迟
/%
6.1
9.4
4.4
4.2
··130。