SQL 脚本解析方法、 装置及系统 【技术领域】
本发明涉及一种元数据管理技术， 尤其涉及一种 SQL 脚本解析方法、 装置及系统。背景技术 目前很多大型企业如通信、 金融等行业的企业都已经建立了元数据管理系统， 以 加强对日益膨胀的数据仓库系统的有效管理。在这些元数据管理系统中， 其中有大部分仍 然采用手工整理方式管理 SQL 脚本元数据。而有些企业则在最近几年开始尝试一种 SQL 脚 本元数据自动获取方案。这种方案基于编译技术， 设法提取 ETL 和数据处理过程的 SQL 脚 本， 然后对这些 SQL 脚本进行词法、 语法和语义分析， 并将获得的 SQL 脚本数据流信息翻译 成 SQL 脚本元数据。
整个方案划分 3 个环节， 在第一个环节中， 目前获取 SQL 脚本的方式主要有三种， 包括直接从 ETL 和数据处理过程的程序代码中提取、 从数据库日志中提取或者从 ETL 和数 据处理过程的运行日志中提取。在第二个环节中， 利用编译技术对提取出来的 SQL 脚本进
行词法和语法分析， 形成语法树， 以此作为语义分析的基础。在第三个环节中， 对 SQL 脚本 的语法树进行语义分析。如果在语义分析过程中发现该 SQL 脚本包含完整的数据流语义信 息， 则将这些数据流语义翻译成元数据， 否则不做翻译处理。
如图 1 所示， 将每个 SQL 脚本看出是一个数据流语义信息的独立载体， 对每个 SQL 脚本单独进行获取和处理， 并生成该 SQL 脚本的元数据， 而不需要考虑 SQL 脚本的上下文环 境。
现有方案是基于每条 SQL 脚本的数据流语义信息与上下文环境无关这样一个假 设进行处理的。当这个假设成立时， 可以自动生成质量很好的 SQL 脚本元数据。但是， 当部 分 SQL 脚本不满足这个假设时， ETL 和数据处理过程中所包含的部分数据流信息就会被丢 失， 最终没有生成相应的元数据。
造成信息丢失的原因主要有两个 ：
1、 环节一的 SQL 脚本获取方式不合理
在环节一中， 现有方案有三种 SQL 脚本的获取方式。 包括从数据库日志中提取 SQL 脚本的方式、 直接从程序块源代码中提取 SQL 脚本的方式和从程序块的运行日志中提取 SQL 脚本的方式。
如果采取从数据库日志中提取 SQL 脚本的方式， 则无法判断所提取的 SQL 脚本属 于哪个程序块， 这些 SQL 脚本中程序块中的先后执行关系和上下文环境信息也无法获知。 因此采用这种方式获取 SQL 脚本， 在后续环节生成元数据时， 就没有足够信息来建立 SQL 脚 本与程序块的关系、 结合上下文环境来分析 SQL 脚本的数据流语义。
如果采取直接从程序块的源代码中提取 SQL 脚本的方式， 对于以静态 SQL 为主的 存储过程脚本， 这种方式是比较有效的。 但是在很多情况下， 程序块的源代码中编写了大量 的动态拼装 SQL 脚本的代码。现有技术方案无法从源代码提取这种动态 SQL 脚本。因此采 取这种方式获取 SQL 脚本， 会丢失所有的动态 SQL 脚本， 这些 SQL 脚本所包含的数据流语义也就无法翻译成元数据。
如果采用从程序块的运行日志中提取 SQL 脚本的方式， 目前的方案只考虑将运行 日志作为 SQL 脚本传递的媒介， 并没有建立一种运行日志输出机制， 可以将 SQL 脚本按上下 文环境进行有效组织。缺乏了这些上下文环境信息， 后续处理环节遇到上下文相关的 SQL 脚本时， 就很难保证元数据的生成质量。
2、 环节三的元数据生成缺乏上下文环境的分析处理方法
在环节三中， 现有方案一方面受到环节一的限制， 另一方面在本环节也没有综合 上下文环境来解析 SQL 脚本的数据流语义， 将每条 SQL 脚本孤立起来处理。当 SQL 脚本存 在上下文相关特性时， 往往无法正确生成元数据。
综上所述， 现有方案虽然可以一定程度上解决 SQL 脚本元数据的管理问题， 但是 现有方案没有通过提供一种机制将 SQL 脚本和相关的上下文环境辅助信息有机组织起来， 从而有可能丢失一些数据流语义信息， 影响了 SQL 脚本元数据的自动获取质量。 发明内容 本发明的目的在于， 提供一种 SQL 脚本解析方法、 装置及系统， 避免数据流语义信 息的丢失， 提高获取 SQL 脚本的元数据的完整性和准确性。
为实现上述目的， 根据本发明的一个方面， 提供一种 SQL 脚本解析方法， 包括 ：
A、 按照运行日志中的 SQL 脚本执行顺序， 从运行日志中提取 SQL 脚本 ；
B、 对每条 SQL 脚本依次进行词法、 语法和语义进行分析， 生成 SQL 脚本的语义结果 集；
C、 根据所述语义结果集分析所述 SQL 脚本的上下文类型， 生成所述运行日志中各 个 SQL 脚本之间的上下文相关信息， 根据所述语义结果集和所述上下文相关信息获得所述 运行日志的数据流信息。
为实现上述目的， 根据本发明的另一个方面， 提供一种 SQL 脚本解析装置， 包括 ：
提取模块， 用于按照运行日志中的 SQL 脚本执行顺序从运行日志中提取 SQL 脚 本；
词法、 语法和语义分析模块， 对每条 SQL 脚本依次进行词法、 语法和语义进行分 析， 生成 SQL 脚本的语义结果集 ；
上下文相关性分析模块， 用于根据所述语义结果集分析所述 SQL 脚本的上下文类 型， 生成所述运行日志中各个 SQL 脚本之间的上下文相关信息， 根据所述语义结果集和所 述上下文相关信息获得所述运行日志的数据流信息。
为实现上述目的， 根据本发明的另一个方面， 提供一种 SQL 脚本解析系统， 包括 ：
运行日志存储装置， 用于存储脚本程序运行时生成的运行日志 ；
SQL 脚本解析装置， 用于按照运行日志中的 SQL 脚本执行顺序， 从运行日志中提取 SQL 脚本 ； 对每条 SQL 脚本依次进行词法、 语法和语义进行分析， 生成 SQL 脚本的语义结果 集； 根据所述语义结果集分析所述 SQL 脚本的上下文类型， 生成所述运行日志中各个 SQL 脚 本之间的上下文相关信息， 根据所述语义结果集和所述上下文相关信息获得所述运行日志 的数据流信息。
本发明的 SQL 脚本解析方法、 装置及系统， 通过对 SQL 脚本进行词法、 语法、 语义以
及上下文相关性分析， 避免在生成 SQL 脚本的元数据时， 数据流语义信息的丢失， 从而提高 获取 SQL 脚本的元数据的完整性和准确性， 保证 SQL 脚本元数据的获取质量。 附图说明 图 1 是现有技术中对 SQL 脚本分析的过程示意图 ；
图 2 是本发明日志文件的格式的示意图 ；
图 3 是本发明 SQL 脚本解析方法实施例的流程图 ；
图 4 是本发明语法树的示意图 ；
图 5a 是本发明 SQL 脚本解析方法实施例中有无缺省数据库连接信息后 SQL 脚本 分析结果对比示意图 ；
图 5b 是本发明 SQL 脚本解析方法实施例中创建和使用临时表的 SQL 脚本之间存 在上下文相关的关系的示意图 ；
图 5c 是本发明 SQL 脚本解析方法实施例中不预先处理临时表创建脚本所引起的 错误的示意图 ；
图 5d 是本发明 SQL 脚本解析方法实施例中 RENAME 句型 SQL 脚本对命名空间的影 响和解析处理方式示意图 ；
图 6 是本发明 SQL 脚本解析装置实施例的结构图 ； 图 7 是本发明 SQL 脚本解析系统实施例的结构图。具体实施方式
本发明中， 数据仓库系统的 ETL 和数据处理过程中， 每次脚本程序的运行， 都将相 关内容写入运行日志， 并将运行日志输出到运行日志区。
运行日志区是一个运行日志存储装置， 在物理实现上可以采用如下两种方式 ：
1、 文件目录， 运行日志以日志文件的方式提交到这些文件目录中 ；
2、 数据库表， 运行日志以库表记录的方式写入这些数据库表中。
如果采用文件目录方式， 运行日志区可以分布在多台主机上。每台主机根据本机 的脚本程序部署情况确定运行日志区的目录结构。 脚本程序的运行日志输出到指定的目录 中。SQL 脚本解析装置的通过 FTP 方式访问运行日志存储装置。
如果采用数据库表方式， 运行日志区可以分布在多个不同的 schema 或者数据库 服务器中。SQL 脚本解析装置的通过 JDBC 连接数据库， 访问运行日志区。
每个脚本程序一次运行所输出的日志， 必须完整输出到运行日志存储装置， 并标 记运行日志的起始和结束位置， 以便 SQL 脚本解析装置根据这些标记确认运行日志的完整 性。
SQL 脚本解析装置定时检查运行日志区， 提取其中未经处理运行日志进行 SQL 脚 本解析处理。 SQL 脚本解析装置每次处理一个完整的运行日志， 将生成这个运行日志所对应 脚本程序的元数据。
运行日志的内容主要包括 ：
1、 提交到数据库执行的 SQL 脚本， 脚本程序中所有提交到数据库执行的 SQL 脚本 都要完整写入运行日志中， 这些 SQL 脚本应该是数据库服务器可以直接执行的， 不能包含脚本程序变量等非数据库语法单元 ( 存储过程除外 ) ；
2、 上下文辅助信息， 如缺省数据库连接信息、 临时表信息、 命名空间信息或 SQL 脚 本循环信息 ；
其中， 缺省数据库连接信息， 是脚本程序存在多次创建数据库链接， 分别向不同 schema 提交 SQL 脚本的情况下， 将创建链接的信息 ( 包括数据库服务器、 用户名等 ) 按规 定格式写入运行日志中的， 以便 SQL 脚本解析装置据此确定后续执行的 SQL 脚本的缺省 schema 是什么
运行日志可以采用日志文件或者日志表两种存储方式。 其中日志文件方式采用文 本文件记录日志内容， 而日志表方式采用数据库表记录日志内容。下面分别说明日志文件 和日志表的格式要求 ：
1、 日志文件格式
每个脚本程序在中运行日志区中都有一个固定的日志文件输出目录。 不同脚本程 序可以共用一个日志文件输出目录。
脚本程序每次运行时， 都需要在该目录下输出一个独立的日志文件。这些日志文 件应具有明确的文件命名规则， 以便 SQL 脚本解析装置确定运行日志与脚本程序的对应关 系。 写入日志文件中的文本所采用的字符集应该与 UTF-8 和 GBK 兼容。
如图 2 所示， 日志文件的内容划分文件头、 文件体和文件结束标志 3 个部分。这三 个部分必须按先后顺序依次写入日志文件。
1) 文件头的格式要求
文件头必须依次写入如下内容 ：
a) 脚本程序名
格式 ： [PROC] 脚本程序名 [/PROC]。
其中的脚本程序名是指脚本程序的文件名， 为避免在不同路径下出现重名脚本程 序名的情况， 这里的文件名应包括文件路径。
b) 脚本程序版本号
格式 ： [VERSION] 脚本程序版本号 [/VERSION]
其中的脚本程序版本号是一个字符串， 格式不限。
c) 脚本程序最近修改时间
格式 ： [MODIFY DATE] 脚本程序最近修改时间 [/MODIFY DATE]
其中的脚本程序最近修改时间是指脚本程序文件最后一次更新的时间， 可以采用 操作系统中记录的文件修改时间。
时间格式 ： yyyy-mm-dd hh24:mi:ss
d) 脚本程序本次运行的输入参数
格式 ： [PARA] 参数描述串 [/PARA]
其中的参数描述串用于记录脚本程序本次运行时， 从外部传进来的参数值， 参数 描述串的格式 ： “参数名 1 ＝参数值 1 ； 参数名 2 ＝参数值 2 ； ......” 。
e) 脚本程序本次运行的启动时间
格式 ： [BEGIN TIME] 脚本程序本次运行的启动时间 [/BEGIN TIME]
时间格式 ： yyyy-mm-dd hh24:mi:ss
2) 文件体的格式要求
文件体记录脚本程序运行时提交到数据库执行的所有 SQL 脚本、 创建数据库连接 的相关参数以及文件导入导出操作命令。
以下内容必须按脚本程序运行的先后顺序写入文件体中。
a) 提交到数据库执行的 SQL 脚本
格式 ：
[SQL]
SQL 脚本
[/SQL]
其中的 SQL 脚本是指一条可执行的 SQL 语句。SQL 脚本的起止标志 [SQL] 和 [/ SQL] 必须分别独占一行。而 SQL 脚本可以占一行或者多行。
b) 创建数据库链接的相关参数
如果在脚本程序中存在建立数据库连接的操作， 则相关的数据库连接参数 ( 密码 除外 ) 需要以连接串的方式写入日志文件。 格式 ： [CONN] 数据库连接串 [/CONN]
其中的数据库连接串应采用如下格式的字符串进行记录 ： “参数名 1 ＝参数值 1 ； 参数名 2 ＝参数值 2 ； ...” 。这些参数应包括 ： 数据库类型、 数据库所在主机、 数据库实例名 和连接用户等内容。
c) 文件导入导出操作 (import/export/load/unload)
格式 ： [SQL] 文件导入导出操作命令 [/SQL]
其中的文件导入导出操作命令是指一条 import/export/load/unload 命令的完 整文本。
3) 文件结束标志
文件结束标志用于 SQL 脚本解析装置确认一个日志文件的完整性， 避免日志文件 在输出过程还没完全结束时就被 SQL 脚本解析装置提取出来处理 ；
文件结束标志格式 ： [END TIME] 脚本程序本次运行的结束时间 [/ENDTIME] ；
时间格式 ： yyyy-mm-dd hh24:mi:ss。
2、 日志表格式
如果在运行日志区中采用数据库表来存储运行日志的内容， 则这组日志表的表结 构和数据格式必须遵守日志表的格式要求。日志表由如下两张数据库表组成 ：
运行日志总体表 ： sqlparser_log_general
运行日志明细表 ： sqlparser_log_detail
每个脚本程序的每次运行输出一个运行日志。 运行日志总体表中的每条记录对应 一个运行日志， 而运行日志的详细信息写入运行日志明细表中。
运行日志总体表的填写要求如下表 1 所示 ：
表1
运行日志明细表填写要求如下表 2 所示。 表2以下结合附图对本发明进行详细说明。
方法实施例
数据仓库系统的 ETL 和数据处理过程中， 有很多脚本程序的组合 SQL 脚本， 属于上 下文相关的组合 SQL 脚本。在解析处理这些组合 SQL 脚本时， 需要识别 SQL 脚本之间的上 下文关系， 否则很可能导致解析结果出错。
如图 3 所示， 本发明 SQL 脚本解析方法实施例主要包括以下步骤 ：
步骤 302， 按照运行日志中的 SQL 脚本执行顺序， 从运行日志中提取 SQL 脚本 ； 每 个运行日志对应 ETL 和数据处理过程中的一个程序块 ；
步骤 304， 读取所述 SQL 脚本的字符串， 对字符串的字符序列进行单词提取， 生成 满足 SQL 脚本的保留字、 常量、 变量等的单词序列 ；
例如， 对字符串 “rename A01 to B01” 进行 SQL 脚本词法分析后， 形成如下单词序 列： “rename” 、 “A01” 、 “to” 、 “B01” ；
步骤 306， 对上述词法分析环节输出的单词序列进行语法分析， 获取其语法结构， 生成语法树 ； 如图 4 所示， 语法树是以树形结构描述一条 SQL 脚本的语法结构 ；
步骤 308， 遍历步骤 306 中获得的语法树， 根据语法树中每个结点的语义和语法结 构， 生成 SQL 脚本的语义结果集 ；
例如， 如图 4 所示， 对 Rename 语句进行语义分析， 遇到 Rename 结点， 即可知道这是 一个数据库表的改名操作， 遍历后续结点 OldTableName， 即可知道这是改名之前的库表名， 再往下遍历， 可以找到改名前的库表名是 A01， 遍历整个语法树后， 就可以获得如下语义信 息： 将库表 A01 改名为 B01 ； 获得的语义结果集包括 ： 3 个对象 ： 库表 A01、 库表 B01 和改名操 作； 以及两个关系 ： 库表 A01 与改名操作的关系， 库表 B01 与改名操作的关系 ； 步骤 310， 根据所述语义结果集分析所述 SQL 脚本的上下文类型， 生成所述运行日 志中各个 SQL 脚本之间的上下文相关信息， 根据所述语义结果集和上下文相关信息获得运 行日志的数据流信息，
上下文类型主要包括 ： 缺省数据库连接信息、 临时表、 命名空间及 SQL 脚本循环等 等。
另外， 运行日志中除了 SQL 脚本外， 可能还包括上下文辅助信息， 因此， 在步骤 310 中， 还需要根据根据所述上下文辅助信息分析所述 SQL 脚本的上下文类型， 生成上下文相 关信息。
上下文辅助信息包括 ： 缺省数据库连接信息。 上述步骤 310 具体包括 ： 根据所述缺 省数据库连接信息确定每条 SQL 脚本的缺省 schema ； 根据所述缺省 schema 获得数据库实 体在原数据库中的定位。
本实施例中， 上下文相关的 SQL 脚本主要有以下几种关系 ： 缺省数据库连接信息、 临时表、 命名空间或 SQL 脚本循环等。以下对这几种情况 SQL 脚本的上下文相关性解析分 别举例说明。
(1) 当多条 SQL 脚本之间存在创建数据库连接和关闭数据库连接的操作， 根据上 下文辅助信息中的缺省数据库连接信息确定每条 SQL 脚本的缺省 schema。
数据库连接决定了 SQL 脚本运行的缺省 schema， 而数据库实体在元数据库中的定 位需要依赖于该数据库实体所属 schema。因此， 除非 SQL 脚本的每个数据库表 / 视图都标 明所属 schema， 否则必须预先知道 SQL 脚本执行时的缺省 schema。
如果在一个脚本程序的多条 SQL 脚本之间， 存在创建数据库连接和关闭数据库连 接的操作， 则这些 SQL 脚本执行的缺省 schema 可能不一样。这时需要根据创建数据库连接 的信息来确定每条 SQL 脚本的缺省 schema。
如图 5a 所示， 有如下的 SQL 脚本 ：
CONNECT TO S02
INSERTINTO A02 SELECT...FROM S01.A01
CONNECT TO S03
INSERTINTO A02 SELECT...FROM S01.A01
如果不能识别数据库连接信息及其与 SQL 脚本的先后顺序， 则有可能生成错误结 果， 错误的解析结果如图 5a 中的 501 所示为 A02 ； 而正确的解析结果应当如 5a 中的 502 所 示的分别为 S02.A02 和 S03.A03。
(2) 当 SQL 脚本中存在对临时表的操作时， 根据查询子句确定临时表的结构， 根据 所述临时表结构对所述 SQL 脚本进行上下文相关性分析。
如果在一条 SQL 脚本中存在对临时表的操作， 而且这个临时表是在该 SQL 脚本执 行前创建的， 那么这条 SQL 脚本的解析过程很可能需要依赖与创建临时表的 SQL 脚本所包 含的信息。在经营分析系统中， 有很多脚本程序通过一个查询子句创建临时表。这种情况 需要根据该查询子句来确定临时表的结构， 并将这些结构信息应用于后续 SQL 脚本的解析 处理过程中。
如图 5b 所示， 有如下的 SQL 脚本 ：
SQL01 ： CREATE TABLE TA(fa1， fa2) ；
SQL02 ： INSERT INTO TA SELECT fb1， fb2 FROM TB ；
如果不首先解析第一条 SQL 脚本， 获取 TA 的库表结构， 则 Transformer 对象的目 标关系无法建立， 错误的解析结果如图 5b 中的 503 所示 ； 而正确的解析结果应当如 5b 中的 504 所示。
如图 5c 所示， 不预先处理临时表创建脚本也会引起的解析错误。
有如下的 SQL 脚本 ：
SQL01 ： CREATE TABLE TA(fa1， fa2， fa3) ；
SQL02 ： INSERT INTO TA(fa1， fa2)SELECT fb1， fb2 FROM TB ；
错误的解析结果如图 5c 中的 505 所示， 缺少 fa3 字段 ； 而正确的解析结果应当如 5b 中的 506 所示。
(3) 对于命名空间信息的处理， 识别 SQL 脚本中同一标识的数据库表的不同命名 空间信息， 对所述数据库表的标识增加相应的命名前缀， 根据所述命名前缀对所述 SQL 脚 本进行上下文相关性分析 ；
在脚本程序中， 一个数据库表的命名只能在一定范围内标识该数据库表， 当这个 命名超出该范围时， 所标识的是其他数据库表， 这个范围就称为命名空间。
一般情况下， 数据库表的命名空间会覆盖脚本程序的所有 SQL 脚本。但是， 如果在 脚本程序中存在 RENAME 句型的 SQL 脚本， 或者 DROP 表操作的 SQL 脚本， 则这些 SQL 脚本的 上下文会影响数据库表的命名空间， 甚至出现同一个命名有多个命名空间， 分别标识多个 不同的数据库表的情况。
这种情况下， SQL 脚本解析时需要识别同一标识的不同命名空间， 通过对这个命名 标识增加命名前缀来加以区分。
数据库表命名空间与 SQL 脚本的关系如下 ：
1、 CREATE 句型是指在执行期间创建数据库表的 SQL 脚本。所创建的数据库表的命名对应一个新 的命名空间。
2、 RENAME 句型
SQL 脚本 RENAME TABLE A01 TO A02 影响两个数据库表的命名空间。其中 A01 的 命名标识范围结束， A02 创建一个新的命名空间。
3、 DROP 句型
SQL 脚本 DROP TABLE A01 令 A01 的命名标识范围结束。
如图 5d 所示， 有如下的 SQL 脚本 ：
SQL01 ： CREATE TABLE TA AS SELECT...FROM TB0... ； //TA 的 NameSpace01 开始
SQL02 ： RENAME TABLE TA TO TA0 ； //TA 的 NameSpace01 结束
//TA0 的 NameSpace01 开始
SQL03 ： CREATE TABLE TA AS SELECT...FROM TB1... ； //TA 的 NameSpace02 开始
SQL04 ： RENAME TABLE TA TO TA1 ； //TA 的 NameSpace02 结束
//TA1 的 NameSpace01 开始
不区分命名空间的情况下， 将 SQL01 和 SQL03 所创建的 TA 视为同一张表， 解析出 错误的结果， 如图 5d 中的 507 所示， 事实上这两张表很可能具有不同的表结构 ； 正确的解析 结果如图 5d 中的 508 所示。
(4) 当 SQL 脚本为循环时， 将多个结构类似的 SQL 脚本识别为一个 SQL 脚本， 并对 该循环的 SQL 脚本进行上下文相关性分析。
如果脚本程序中存在一个循环体内的 SQL 脚本， 那么这个 SQL 脚本输出到运行日 志后， 可能会是多个结构类似的 SQL 脚本。对这批本来不是组合 SQL 脚本的组合 SQL 脚本 进行处理时， 需要将其识别为一个 SQL 脚本， 解析生成的结果应该是一个 SQL 脚本的结构化 描述结果。
以下对上述步骤 310 进行具体举例说明， 运行日志如下表 3 所示，
表3
当解析处理该运行日志时， 首先创建一个空的上下文相关信息， 如下表 4 所示， 表4
依次解析运行日志中的每一条信息。 1、 解析第一条 ：[CONN]″ schema ＝ S01″ [/CONN]，
这并不是一条 SQL 语句， 而是一条上下文辅助信息， 因此不生成语义结果集， 其上 下文类型属于改变数据库连接类型， 针对这种上下文类型的处理， 是将上下文环境中的缺 省 schema 修改为新的 schema， 修改后的上下文相关信息如下表 5 所示。
表5
2、 解析第二条 ：
[SQL]
Create table TB(b1 int， b2 int)
[/SQL]
对这条 SQL 语句进行词法语法和语义分析后， 其语义结果集是 TB 的表结构。结合 当前的上下文相关信息， TB 所属 schema 是 S01， 同时该 SQL 句型涉及临时表和命名空间的 处理， 需要将 S01.TB 的表结构和命名空间登记到上下文相关信息中， 如下表 6 所示。
表6
3、 解析第三条 ：
[SQL]
Insert into TB select...from S02.TA...
[/SQL]
对这条 SQL 语句进行词法语法和语义分析后， 其语义结果集是读取表 S02.TA 的数 据， 写入 TB 中， 这时要访问上下文相关信息， 才能知道 TB 是属于命名空间 01 中的 S01.TB， 其表结构是 (b1 int， b2 int)。综合这些信息， 可生成该 SQL 语句的元数据信息。
这条 SQL 语句不需要更新上下文相关信息。
4、 解析第四条 ：
[CONN]″ schema ＝ S02″ [/CONN]
修改上下文相关信息中的缺省 schema， 如下表 7 所示 ：
表7
5、 解析第五条 ：
[SQL]
Rename S01.TB to S01.TB01
[/SQL]
该 SQL 语句的语义结构集， 是将 S01 下的库表 TB 改名为 TB01， 生成改名的元数据 信息。同时， 这里涉及上下文相关信息中命名空间的变化， 而 TB01 继承了 TB 的表结构， 这 个表结构需要从上下文相关信息中获得， 此外， 还要登记 TB01 的命名空间， 为此要修改上 下文相关信息， 如下表 8 所示。
表8
6、 解析第六条 ：
[SQL]
Create table S01.TB(b1 string， b2 string， b3 string)
[/SQL]
在 S01 下面创建库表 TB， 检查上下文相关信息得知， 由于之前的 S01.TB 的命名空 间 01 已经结束， 现在的 TB 要登记一个新的命名空间 02， 同时要将 TB 的表结构记录到上下 文相关信息中， 如下表 9 所示。
表9
本实施例的 SQL 脚本解析方法， 通过对 SQL 脚本进行词法、 语法、 语义以及上下文 相关性分析， 避免在生成 SQL 脚本的元数据时， 数据流语义信息的丢失， 从而提高获取 SQL 脚本的元数据的完整性和准确性， 保证 SQL 脚本元数据的获取质量。另外， 通过在运行日志 中加入上下文辅助信息， 在上下文相关性分析 SQL 脚本时， 同时考虑该上下文辅助信息， 能 够更精确的判断 SQL 脚本与上下文的关系， 进一步提高获取 SQL 脚本的元数据的完整性和 准确性， 保证 SQL 脚本元数据的获取质量。
装置实施例
如图 6 所示， 本发明 SQL 脚本解析装置实施例包括 ：
提取模块 602， 用于按照运行日志中的 SQL 脚本执行顺序从运行日志中提取 SQL 脚 本；
词法、 语法和语义分析模块， 对每条 SQL 脚本依次进行词法、 语法和语义进行分 析， 生成 SQL 脚本的语义结果集 ；
上下文相关性分析模块 610， 用于根据所述语义结果集分析所述 SQL 脚本的上下 文类型， 生成所述运行日志中各个 SQL 脚本之间的上下文相关信息， 根据所述语义结果集 和所述上下文相关信息获得所述运行日志的数据流信息。
其中， 词法分析模块 604， 用于读取所述 SQL 脚本的字符串， 对字符串的字符序列 进行单词提取， 生成单词序列 ；
语法分析模块 606， 用于分析所述单词序列的语法结构， 生成语法树 ；
语义分析模块 608， 用于遍历所述语法树， 根据语法树中每个结点的语义和语法结 构， 生成所述 SQL 脚本的语义结果集。
本实施例 SQL 脚本解析装置中， 各模块的工作方式在上述方法实施例中已经详细 说明， 在此不再赘述。
本实施例的 SQL 脚本解析装置， 通过对 SQL 脚本进行词法、 语法、 语义以及上下文 相关性分析， 避免在生成 SQL 脚本的元数据时， 数据流语义信息的丢失， 从而提高获取 SQL 脚本的元数据的完整性和准确性， 保证 SQL 脚本元数据的获取质量。
系统实施例
如图 7 所示， 本发明 SQL 脚本解析系统实施例包括 ：
运行日志存储装置 72， 用于存储脚本程序运行时生成的运行日志 ；
SQL 脚本解析装置 74， 用于按照运行日志中的 SQL 脚本执行顺序， 从运行日志中提 取 SQL 脚本 ； 对每条 SQL 脚本依次进行词法、 语法和语义进行分析， 生成 SQL 脚本的语义结 果集 ； 根据所述语义结果集分析所述 SQL 脚本的上下文类型， 生成所述运行日志中各个 SQL 脚本之间的上下文相关信息， 根据所述语义结果集和所述上下文相关信息获得所述运行日 志的数据流信息。
其中， 运行日志存储装置 72， 采用日志文件或日志表的方式存储所述运行日志。
所述日志文件采用文本文件记录日志内容， 对于所述脚本程序的每次运行， 都在 相应的目录下存储一个独立的日志文件， 所述日志文件的文件名与所述脚本程序相对应。
所述日志表采用数据库表记录日志内容， 对于日志表的存储方式， 存储运行日志 总体表和运行日志明细表 ； 都在所述运行日志总体表的每条记录， 对应所述脚本程序的每 次运行生成的一个运行日志 ； 所述运行日志明细表对应所述运行日志的详细信息。
优选地， 运行日志中包括 ： 脚本程序中所有提交到数据库执行的 SQL 脚本及上下 文辅助信息。 SQL 脚本解析装置 74 则进一步根据所述上下文辅助信息分析所述 SQL 脚本的 上下文类型， 生成上下文相关信息。
如果采用文件目录方式， 运行日志区可以分布在多台主机上。每台主机根据本机 的脚本程序部署情况确定运行日志区的目录结构。 脚本程序的运行日志输出到指定的目录 中。SQL 脚本解析装置的通过 FTP 方式访问运行日志存储装置。
如果采用数据库表方式， 运行日志区可以分布在多个不同的 schema 或者数据库 服务器中。SQL 脚本解析装置的通过 JDBC 连接数据库， 访问运行日志区。
本实施例的 SQL 脚本解析系统， 通过对 SQL 脚本进行词法、 语法、 语义以及上下文 相关性分析， 避免在生成 SQL 脚本的元数据时， 数据流语义信息的丢失， 从而提高获取 SQL 脚本的元数据的完整性和准确性， 保证 SQL 脚本元数据的获取质量。另外， 通过在运行日志 中加入上下文辅助信息， 在上下文相关性分析 SQL 脚本时， 同时考虑该上下文辅助信息， 能 够更精确的判断 SQL 脚本与上下文的关系， 进一步提高获取 SQL 脚本的元数据的完整性和 准确性， 保证 SQL 脚本元数据的获取质量。
应说明的是 ： 以上实施例仅用以说明本发明而非限制， 本发明也并不仅限于上述 举例， 一切不脱离本发明的精神和范围的技术方案及其改进， 其均应涵盖在本发明的权利 要求范围中。