A tax data blood analysis method, device, equipment and storage medium

Abstract

The application discloses a tax data blood relation analysis method and device, equipment and a storage medium, and relates to the technical field of data asset management, which comprises the following steps: performing lexical analysis and syntax analysis on a current data query statement input by a user to obtain a word list object; identifying CTE objects in each word list object, and constructing a CTE name set based on CTE names in all CTE objects; performing depth-first recursive analysis on CTE definition bodies in the CTE objects based on the CTE name set to extract internal association structures of the CTE definition bodies; constructing a dependency relationship between each CTE object and other CTE objects or physical tables referenced in the query statement based on the CTE name set and the internal association structures, obtaining a dependency relationship graph, and outputting the dependency relationship graph by using a topological sorting algorithm to obtain a blood relation analysis result. The application can improve the accuracy of data blood relation analysis and is helpful for the smooth completion of data auditing work.

Description

Technical Field

[0001] This application relates to the field of data asset management technology, and in particular to a method, apparatus, equipment and storage medium for tax data lineage analysis. Background Technology

[0002] Because tax-related data (such as taxpayer identity information, invoice issuance details, audit files, fund transfers, etc.) are highly sensitive administrative management data, the tax information platform needs to conduct compliance audits and risk control on user-defined SQL (Structured Query Language) query statements before submitting them to the tax database for execution. This is to support downstream applications, such as permission and compliance verification, sensitive field access auditing, query risk prediction, and data change impact assessment.

[0003] Currently, when tax information platforms conduct compliance audits of tax data, they typically perform lineage analysis on the SQL queries entered by platform users to retrieve tax-related data from the tax database and trace the data flow path and dependencies from the source physical tables to the final output. This allows them to reconstruct the user's true query intent, such as the actual set of physical tables (the real database tables) read by the SQL query, the JOIN keys and JOIN types between table references, the WHERE filtering conditions applied to table references, and the dependencies and execution order between table references.

[0004] The current mainstream approach to SQL query lineage analysis is through SQL parsing tools (such as sqllineage, sqlfluff, ANTLR, etc.). These tools are based on static lexical scanning or regular expressions. When performing lineage analysis on SQL queries, they typically treat the CTE object defined in the WITH clause (consisting of the CTE name and CTE definition body) as an opaque token list object (i.e., a TokenList object). This approach has at least the following technical problems: 1. The system determines a table as a source table solely based on whether its identifier appears after the FROM / JOIN clause, without distinguishing between CTE (Common Table Expression) objects and physical tables. This results in the CTE name being incorrectly identified as the name of the physical table, and permission verification and access auditing cannot be completed based on the incorrect physical table record. 2. Treating the CTE definition body as an indivisible list of terms object, and not recursively entering the CTE definition body to extract table references and parse JOIN relationships for the SELECT clauses it contains, results in the physical tables actually accessed within the CTE definition body, the JOIN keys between tables, and the WHERE filter conditions being invisible. This makes the audit results inconsistent with the user's actual audit requirements. Furthermore, platform users with SQL writing capabilities (such as operations engineers and third-party vendor technicians) can circumvent auditing by encapsulating unauthorized access logic within the CTE definition body. 3. Only a single-level table reference relationship is constructed, and the internal table references of other CTE objects referenced in the CTE definition body are not recursively tracked, which makes it impossible to trace the sensitivity of the lowest physical table back to the top level along the nested reference chain, resulting in incomplete coverage of compliance judgment results; 4. Current SQL parsing tools lack topology sorting analysis capabilities and cannot output the linear execution order of each physical table and each CTE object. As a result, the risk prediction of queries executed in the order of dependency (such as estimating the physical table scan volume in sequence) and the assessment of the impact of data changes (such as locating the affected downstream CTE objects and main queries in sequence) cannot be automated. Summary of the Invention

[0005] In view of this, the purpose of this application is to provide a method, apparatus, device, and storage medium for tax data lineage analysis, which can improve the accuracy of tax data lineage analysis and help users better understand the flow of tax data, thus facilitating the smooth completion of tax data audits. The specific solution is as follows: Firstly, this application discloses a method for analyzing the lineage of tax data, applied to a data lineage analysis system deployed in a tax information platform, comprising: Obtain the structured query statement for the target tax data input by the current user, and get the current data query statement; Lexical and syntactic analysis are performed on the current data query statement to obtain multiple word list objects; Each CTE object in the lexical list object is identified, and a CTE name set is constructed based on the CTE names in all the CTE objects; each CTE object consists of a CTE name and a CTE definition body. Based on the CTE name set, a depth-first recursive parsing is performed on the CTE definition body in each CTE object to extract the internal association structure of the CTE definition body and obtain the definition body association structure information; Based on the CTE name set and the definition body association structure information, the dependency relationship between each CTE object in the current data query statement and other CTE objects or physical tables referenced is constructed to obtain a dependency graph. The dependency graph is then output using a topological sorting algorithm to obtain the lineage analysis results of the target tax data.

[0006] Optionally, the lexical and syntactic analysis of the current data query statement to obtain multiple word list objects includes: The current data query statement is divided by an SQL parsing engine according to preset lexical rules to obtain a word sequence; the word elements in the word sequence carry two attributes: type and value. The lexical units in the lexical sequence are combined according to the bracket hierarchy and preset grammar rules to obtain nested list objects of multiple lexical units.

[0007] Optionally, identifying the CTE objects in each of the lexical list objects includes: Identify the WITH keyword in the term list object, and scan each term list object sequentially along the WITH keyword to extract the CTE name before the AS keyword and the CTE definition body after the AS keyword in the term list object; The CTE name and the CTE definition are used as CTE objects for the corresponding lexical list objects.

[0008] Optionally, extracting the internal association structure of the CTE definition body to obtain the definition body association structure information includes: Extract the table references, JOIN conditions, and WHERE filtering conditions from the CTE definition body to obtain the definition body's associated structure information; the JOIN conditions include JOIN type and ON condition.

[0009] Optionally, the step of extracting table references, JOIN join conditions, and WHERE filter conditions from the CTE definition body to obtain the definition body association structure information includes: The first table reference is obtained by identifying the table references located after the FROM and JOIN clauses in the CTE definition body based on the state machine mechanism; Identify the aliases in the first table reference and the table names of the physical tables corresponding to the aliases to obtain the first alias and the first table name; A local alias mapping table is created based on the first alias and the first table name for the corresponding CTE definition body; Identify the ON condition in the first table reference, and use a preset regular expression to identify the alias in the ON condition to obtain the second alias. Then replace the second alias with the corresponding first table name in the local alias mapping table to obtain the JOIN connection condition. Scan the conditional expression following the WHERE keyword in the CTE definition body to obtain the WHERE conditional expression; Identify the alias in the WHERE condition expression to obtain the third alias, and replace the third alias with the corresponding first table name in the local alias mapping table to obtain the replaced WHERE expression; The replaced WHERE expressions are grouped according to their respective tables to obtain WHERE filtering conditions, and the table references, JOIN connection conditions, and WHERE filtering conditions are used as the definition body association structure information of the corresponding CTE definition body.

[0010] Optionally, replacing the second alias with the corresponding first table name in the local alias mapping table to obtain the JOIN join condition includes: Determine whether the second alias belongs to the CTE name set; If the second alias does not belong to the CTE name set, then the second alias is replaced with the first table name that has a mapping relationship in the local alias mapping table to obtain the JOIN join condition; Accordingly, replacing the third alias with the corresponding first table name in the local alias mapping table to obtain the replaced WHERE expression includes: Determine whether the third alias belongs to the CTE name set; If the third alias does not belong to the CTE name set, then the third alias is replaced with the first table name that has a mapping relationship in the local alias mapping table, resulting in the replaced WHERE expression; The tax data lineage analysis method also includes: If the second alias or the third alias belongs to the CTE name set, then the second alias or the third alias is marked as the CTE name of the corresponding CTE object.

[0011] Optionally, based on the CTE name set and the definition body association structure information, the dependency relationships between each CTE object in the current data query statement and other referenced CTE objects or physical tables are constructed to obtain a dependency graph. The dependency graph is then output using a topological sorting algorithm to obtain the lineage analysis results of the target tax data, including: Extract the table references from the definition body association structure information to obtain the second table reference, and determine whether the second table reference matches a CTE name in the CTE name set; If the second table reference hits a CTE name in the set of CTE names, then the CTE object corresponding to the second table reference is determined to be a recursive object; If the second table reference does not match any CTE name in the CTE name set, then the CTE object corresponding to the second table reference is determined to be a non-recursive object, and the dependency relationship between the CTE object and other referenced CTE objects or physical tables is constructed to obtain a dependency graph. The linear execution order of each node in the dependency graph is determined using the Kahn algorithm, and the dependency graph is output according to a preset text format and the linear execution order to obtain the lineage analysis results of the target tax data.

[0012] Secondly, this application discloses a tax data lineage analysis device, applied to a data lineage analysis system deployed in a tax information platform, comprising: The acquisition module is used to acquire the structured query statement of the current user for the target tax data and obtain the current data query statement; The analysis module is used to perform lexical and syntactic analysis on the current data query statement to obtain multiple word list objects; The identification module is used to identify the CTE objects in each of the lexical list objects respectively; The first construction module is used to construct a set of CTE names based on the CTE names in all the CTE objects; the CTE object consists of a CTE name and a CTE definition body. The parsing module is used to perform depth-first recursive parsing of the CTE definition body in each CTE object based on the CTE name set, so as to extract the internal association structure of the CTE definition body and obtain the definition body association structure information. The second construction module is used to construct the dependency relationship between each CTE object in the current data query statement and other CTE objects or physical tables referenced, based on the CTE name set and the definition body association structure information, to obtain a dependency relationship graph; The output module is used to output the dependency graph using a topological sorting algorithm to obtain the lineage analysis results of the target tax data.

[0013] Thirdly, this application discloses an electronic device, including a processor and a memory; wherein, when the processor executes a computer program stored in the memory, it implements the aforementioned tax data lineage analysis method.

[0014] Fourthly, this application discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned tax data lineage analysis method.

[0015] As can be seen, this application is applied to a data lineage analysis system deployed in a tax information platform. First, it obtains the structured query statement for the target tax data input by the current user, resulting in the current data query statement. Then, it performs lexical and syntactic analysis on the current data query statement to obtain multiple token list objects. Next, it identifies the CTE objects in each token list object and constructs a CTE name set based on the CTE names in all the CTE objects (composed of CTE names and CTE definitions). Then, based on the CTE name set, it performs depth-first recursive parsing on the CTE definitions in each CTE object to extract the internal association structure of the CTE definitions, obtaining definition association structure information. Finally, based on the CTE name set and the definition association structure information, it constructs the dependency relationships between each CTE object in the current data query statement and other referenced CTE objects or physical tables, obtaining a dependency graph. Finally, it uses a topological sorting algorithm to output the dependency graph, obtaining the lineage analysis results of the target tax data.

[0016] This application first performs lexical and syntactic analysis on the structured query statement input by the user, obtaining multiple token list objects (i.e., TokenList objects). Then, it constructs a set of CTE names based on the CTE names in all token list objects, and performs depth-first recursive parsing on the CTE definitions based on this set to extract the internal association structure of the definitions. Next, it constructs the dependency relationships between different CTE objects in the query statement and the referenced physical tables based on the set and the internal association structure of the definitions. Finally, it uses a topological sorting algorithm to output the constructed dependency graph, thus realizing the lineage analysis of tax data. It is evident that this application performs depth-first recursive parsing on the internal association structure of the CTE definitions, making the internal structure of the CTE definitions visible. Furthermore, by constructing the dependency relationships between different CTE objects and the referenced physical tables (i.e., the actual referenced database tables) based on the internal association structure of the definitions, this application avoids misidentifying CTE names as physical table names, thereby ensuring the accuracy of the dependency graph and improving the accuracy of lineage analysis. In addition, the use of a topological sorting algorithm to output the dependency graph helps users better understand the flow of tax data, contributing to the smooth completion of tax data auditing. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0018] Figure 1 This application discloses a flowchart of a tax data lineage analysis method. Figure 2 This is a schematic diagram of the process for obtaining the associated structural information of the definition body as disclosed in this application; Figure 3 This is a schematic diagram of the structure of a tax data lineage analysis device disclosed in this application; Figure 4 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0019] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0020] This application discloses a method for tax data lineage analysis, applied to a data lineage analysis system deployed on a tax information platform. See [link to relevant documentation]. Figure 1 As shown, the method includes: Step S11: Obtain the structured query statement for the target tax data input by the current user, and obtain the current data query statement.

[0021] It should be noted that the tax data lineage analysis solution proposed in this application can be applied to data governance and data asset management scenarios in the field of tax informatization. Lineage analysis can be achieved through a data lineage analysis system (such as an SQL lineage analysis system) deployed in a tax informatization platform. This system comprises five layers from top to bottom: a user interface layer, an SQL parsing engine layer, a CTE processing layer, a lineage analysis layer, and a sorting output layer. Data is exchanged between these layers through pre-defined interaction interfaces, achieving modularity and scalability. The tax informatization platform can be deployed on a server.

[0022] In this embodiment, when performing tax data lineage analysis, the SQL lineage analysis system first receives the structured query statement (i.e., SQL statement, which can be the SQL dialect of mainstream databases and big data computing engines such as MySQL, Oracle, PostgreSQL, Hive, SparkSQL, etc.) entered by the user on the current interface through a preset interactive interface in the user interface layer, such as a Web form or REST API (Application Programming Interface), and obtains the current data query statement.

[0023] Users may include, but are not limited to, tax personnel (such as those in positions of inspection, risk control, tax administration, and data analysis), operations and maintenance engineers (engineers responsible for the daily operation and maintenance of the platform and database), and technical personnel from third-party vendors (such as external vendors' development / implementation personnel who undertake specific business module development, report preparation, and data migration for tax authorities).

[0024] In one specific implementation, the current data query statement (i.e., the SQL statement, described in string form) can be: WITH t_month AS ( SELECT nsrsbh, SUM(je) AS je FROM sjck_ywzc.fpkj_mx WHERE skssq BETWEEN '202601' AND '202612' GROUP BY nsrsbh ), t_risk AS ( SELECT m.nsrsbh, m.je, n.hy_dm FROM t_month m JOIN sjck_ggmx.nsrxx n ON m.nsrsbh = n.nsrsbh JOIN sjck_ggmx.hydm h ON n.hy_dm = h.hy_dm WHERE n.nsr_zt = '01' ) SELECT FROM t_risk WHERE je > 1000000.

[0025] Step S12: Perform lexical and syntactic analysis on the current data query statement to obtain multiple word list objects.

[0026] In this embodiment, after receiving the structured query statement (i.e., SQL statement) input by the current user through the user interface layer, the SQL parsing engine layer further performs lexical analysis on the current data query statement (i.e., SQL statement) according to preset lexical rules to identify each word in the SQL statement, and performs syntactic analysis on the identified multiple words to obtain a list of multiple words corresponding to the SQL statement (i.e., TokenList object, which refers to an ordered set of words).

[0027] Specifically, the step of performing lexical and syntactic analysis on the current data query statement to obtain multiple word list objects may include: dividing the current data query statement into word sequences using an SQL parsing engine and according to preset lexical rules; word sequences carrying two attributes, type and value; and combining word sequences according to bracket hierarchy and preset syntactic rules to obtain nested multiple word list objects. Specifically, by using an SQL parsing engine (such as the sqlparse library, JsqlParser (implemented in Java), or Calcite (an Apache open-source framework), and dividing the various tokens in the above SQL statement according to preset lexical rules, a token sequence can be obtained. It should be noted that each token in the token sequence carries two attributes: type and value. For example, the header WITH t_month AS of the above SQL statement can be divided into multiple tokens, such as `type=CTE object, value="WITH"`, `type=space, value=" "`, `type=CTE name, value="t_month"`, `type=keyword, value="AS"`, `type=punctuation mark, value="("`, `type=keyword, value="SELECT"`, etc.

[0028] Furthermore, the aforementioned tokens are organized into nested token list objects (i.e., TokenList objects) according to the bracket hierarchy. The outermost token list object corresponds to the entire SQL statement, each CTE definition body corresponds to a sub-token list object, and when a subquery exists within the main query of the SQL statement, the subquery also corresponds to a token list object (i.e., a sub-token list object), thus forming an Abstract Syntax Tree (AST), a tree structure of SQL syntax represented by nested token list objects as nodes.

[0029] The main query refers to the outermost SELECT statement located after all WITH clauses, representing the final output of the SQL statement.

[0030] A subquery is a complete SELECT statement enclosed in parentheses, nested within another SQL statement. Its execution result serves as the data source or decision criterion for the outer statement. Subqueries can be categorized based on their dependency on the outer query: non-correlated subqueries and correlated subqueries. Non-correlated subqueries are those that can execute independently and do not reference any columns from the outer query; correlated subqueries reference columns from the outer query and require re-evaluation for each row of the outer query.

[0031] Step S13: Identify the CTE objects in each of the lexical list objects, and construct a CTE name set based on the CTE names in all the CTE objects; the CTE object consists of a CTE name and a CTE definition body.

[0032] In this embodiment, after performing lexical and syntactic analysis on the current data query statement to obtain multiple nested word list objects, the CTE processing layer identifies the CTE objects (including CTE names and CTE definitions) in each word list object, and constructs a CTE name set based on the CTE names in all identified CTE objects.

[0033] Specifically, identifying the CTE objects in each of the token list objects may include: identifying the WITH keyword in the token list object, and sequentially scanning each token list object along the WITH keyword to extract the CTE name before the AS keyword and the CTE definition body after the AS keyword in the token list object; and using the CTE name and the CTE definition body as the CTE object of the corresponding token list object. In this embodiment, firstly, the token with type = CTE object is located in the token list object (i.e., the TokenList object), i.e., the WITH keyword. Then, each token list object is sequentially scanned along the WITH keyword to extract the value of the token with type CTE name before the AS keyword in each token list object, and this value is used as the CTE name. The tokens between the punctuation marks after the AS keyword are extracted as the CTE definition body. Finally, the extracted CTE name and CTE definition body are used as the CTE object of the corresponding token list object (i.e., the TokenList object).

[0034] For example, the CTE definition body for a user-inputted SQL statement to be analyzed is: SELECT nsrsbh, SUM(je) AS je FROM sjck_ywzc.fpkj_mx WHERE skssq BETWEEN '202601' AND '202612' GROUP BY nsrsbh` and `SELECT m.nsrsbh, m.je, n.hy_dm FROM t_month m JOIN sjck_ggmx.nsrxx n ON m.nsrsbh = n.nsrsbh JOIN sjck_ggmx.hydm h ON n.hy_dm = h.hy_dm WHERE n.nsr_zt = '01'` Furthermore, all extracted CTE names are integrated to obtain a CTE name set. For example, for the above SQL statement, its CTE name set is: `{"t_month", "t_risk"}`.

[0035] It should be noted that the CTE processing layer needs to scan all CTE objects defined in the WITH clause at once and complete the construction of the complete set of CTE names before entering the subsequent lineage analysis layer to perform depth-first recursive parsing on each CTE definition.

[0036] Step S14: Based on the CTE name set, perform depth-first recursive parsing on the CTE definition body in each CTE object to extract the internal association structure of the CTE definition body and obtain the definition body association structure information.

[0037] In this embodiment, after constructing a set of CTE names based on the CTE names in all CTE objects, a lineage analysis layer is used to perform a depth-first recursive parsing of the CTE definition body in each CTE object based on the CTE name set, in order to extract the table references, JOIN connection conditions, and WHERE filtering conditions inside the CTE definition body, and obtain complete definition body association structure information; wherein, the JOIN connection conditions specifically include JOIN type and ON condition.

[0038] Depth-first recursive parsing refers to the following: when encountering a sublexical list object in the Abstract Syntax Tree (AST), the entire contents of the sublexical list object (including its deeper sublexical list objects) are completely parsed before returning to the previous level to continue parsing.

[0039] By generating an abstract syntax tree that nests multiple TokenLists, a depth-first recursive traversal is performed on the CTE definition body and subqueries, and context information such as CTE name and table alias is maintained during the traversal, which enables automatic extraction from the syntax tree to the lineage relationship.

[0040] By performing deep-first recursive parsing on the statements within each CTE definition body, such as SELECT statements, the internal table references, JOIN joins, and WHERE filter conditions can be fully extracted. This transforms the internal relationship structure of the CTE from a black box to a white box, fully revealing the previously invisible internal relationship structure of the CTE. Users can clearly understand which tables each CTE references and what conditions connect the tables, which is very helpful for understanding the data flow of complex business SQL.

[0041] See Figure 2 As shown, the table references, JOIN join conditions, and WHERE filter conditions within the CTE definition body are extracted to obtain the definition body association structure information, which may specifically include: Step S21: Based on the state machine mechanism, identify the table references located after the FROM clause and JOIN clause in the CTE definition body to obtain the first table reference.

[0042] In this embodiment, the first table reference is obtained by first identifying the table references after the FROM clause and JOIN clause in the CTE definition body through the state machine mechanism (a computational model that performs state transitions between finite sets of states based on input).

[0043] The FROM clause refers to a statement segment enclosed in the reserved word FROM, used to specify the data source table, which can be followed by a single data source table, multiple data source tables, or a common table expression.

[0044] The JOIN clause refers to a statement segment introduced by the reserved word JOIN (including variants such as INNER JOIN, LEFT JOIN, RIGHT JOIN, FULL JOIN, CROSS JOIN, etc.) used to connect two tables according to specified conditions.

[0045] Table references are identifiers in SQL statements that appear as table names or aliases to refer to a specific data source. They typically appear at the beginning of the FROM clause, JOIN clause, or subquery. For example, in FROM t_month m JOIN t_user u ON..., t_month and t_user both constitute table references. Based on the nature of the object they refer to, they can be divided into two categories: first, table references that point to the actual physical tables stored in the database; second, table references that point to CTE objects defined in the WITH clause.

[0046] For example, the current state of the initialized state machine is INIT (initialization), and a temporary storage area for pending JOIN operations is maintained. The state set of the state machine is {INIT, FROM_SEEN, JOIN_SEEN, ON_SEEN, WHERE_SEEN, END}, and the state transition rules of the state machine are as follows: INIT→FROM_SEEN: Triggered when a term with the value "FROM" is encountered, the list of terms immediately following the term is identified as the current left table and written to the left table field of the above-mentioned pending JOIN temporary storage area.

[0047] FROM_SEEN→JOIN_SEEN: Triggered when encountering a keyword terminology whose value belongs to {JOIN, INNER JOIN, LEFT JOIN, RIGHTJOIN, FULL JOIN, CROSS JOIN}, the list of terms immediately following the keyword terminology is identified as the right table to be joined and written into the right table field of the above-mentioned pending JOIN temporary storage area.

[0048] JOIN_SEEN→ON_SEEN: Triggered when a keyword token with the value ON is encountered, and then the collection of ON conditional expressions begins.

[0049] ON_SEEN→JOIN_SEEN: Triggered when the next JOIN keyword term is encountered during the collection of ON conditions; at this time, the "left table-right table-JOIN type-ON condition" quadruples accumulated in the above-mentioned pending JOIN temporary storage area are first written into the JOIN relationship list and the ON condition field in the above-mentioned pending JOIN temporary storage area is cleared, and then the new right table is written into the above-mentioned pending JOIN temporary storage area according to this rule.

[0050] ON_SEEN→WHERE_SEEN: Triggered when a keyword token with the value WHERE is encountered; first clear the last JOIN relationship in the above pending JOIN temporary storage area, and then extract the WHERE condition.

[0051] Any state → END: Triggered when encountering a semicolon, a right parenthesis (matching the closing parenthesis of the CTE definition body), or one of GROUP BY / ORDER BY / HAVING / LIMIT / UNION / INTERSECT / EXCEPT; when triggered, the uncommitted JOIN relationships in the above pending JOIN staging area are also cleared.

[0052] It should be noted that each time the transition loop FROM_SEEN→JOIN_SEEN→ON_SEEN→(JOIN_SEEN |WHERE_SEEN | END) is completed, a complete JOIN relationship record will be generated.

[0053] Step S22: Identify the alias in the first table reference and the table name of the physical table corresponding to the alias to obtain the first alias and the first table name.

[0054] In this embodiment, the aliases in the first table reference and the table names of the physical tables corresponding to the aliases are identified to obtain the first alias and the first table name. For example, when the first table reference is FROM sjck_ywzc.fpkj_mx m, the alias is m.

[0055] In this context, a physical table refers to a data table that actually exists in the database, has physical storage space, and can be uniquely located using the format "Schema.table_name". For example, `sjck_ywzc.fpkj_mx` is a physical table, where `sjck_ywzc` is the Schema (database schema, a logical namespace used to organize data tables, views, sequences, and other objects), and `fpkj_mx` is the table name.

[0056] Step S23: Create a local alias mapping table for the corresponding CTE definition based on the first alias and the first table name.

[0057] For example, "alias m → physical table sjck_ywzc.fpkj_mx" is written into the initial mapping table maintained independently by the current CTE definition, thereby creating the local alias mapping table of the current CTE definition.

[0058] Step S24: Identify the ON condition in the first table reference, and use a preset regular expression to identify the alias in the ON condition to obtain the second alias. Then, replace the second alias with the corresponding first table name in the local alias mapping table to obtain the JOIN connection condition.

[0059] In this embodiment, after creating the local alias mapping table, the table attribution within the ON condition in the first table reference is parsed. Specifically, when the ON condition is `m.nsrsbh=n.nsrsbh`, a regular expression (a formal syntax for describing string matching patterns) can be used, such as `(\w+)\.(\w+)`, to match the "alias.column name" format from the string of the ON condition, thus obtaining the tuples `("m","nsrsbh")` and `("n","nsrsbh")`. Then, by querying the local alias mapping table, the second alias in the tuple is replaced. For example, `m` in the tuple is replaced with `sjck_ywzc.fpkj_mx`, and `n` is replaced with `sjck_ggmx.nsrxx`, thus obtaining the JOIN join condition with explicit table attribution.

[0060] It should be noted that if the alias itself (such as the alias in the ON condition or WHERE condition) belongs to the above set of CTE names, it will not be replaced with the table name of the physical table, but will be marked as a reference to the CTE object (e.g., marked as a CTE name).

[0061] Furthermore, when multiple consecutive JOINs (such as `A JOIN B ON ... JOIN C ON ...`) appear in the CTE definition, i.e., chained JOINs exist within the CTE definition, a state machine processing mechanism is used to handle the chained JOINs. For example, after completing the first `A JOIN B`, the JOIN buffer continues to retain records with the left table as A and the right table as B. When entering the second JOIN, the alias of the left column is parsed from the second ON condition: if the alias is equal to the left table alias (i.e., A) recorded in the JOIN buffer, it is determined to be a chained JOIN, and the left table remains A, while establishing the `A JOIN C` relationship; if the alias is equal to the right table alias (i.e., B) recorded in the JOIN buffer, it is determined to be a sequential JOIN, the left table is B, and the `B JOIN C` relationship is established. Through this method, it can be ensured that multiple consecutive JOINs are correctly associated with their respective ON conditions.

[0062] In another specific real-time approach, the parsing of chained JOINs can also employ a two-pass scanning method (the first pass collects the positions of the JOIN and ON keywords, and the second pass performs the pairing).

[0063] Step S25: Scan the conditional expression after the WHERE keyword in the CTE definition body to obtain the WHERE conditional expression.

[0064] Step S26: Identify the alias in the WHERE condition expression, obtain the third alias, and replace the third alias with the corresponding first table name in the local alias mapping table to obtain the replaced WHERE expression.

[0065] In this embodiment, after scanning and extracting the WHERE conditional expression located after the WHERE keyword in the CTE definition body, the alias in the conditional expression is identified, and then the identified alias is replaced with the corresponding first table name in the aforementioned local alias mapping table to obtain the replaced WHERE expression.

[0066] Step S27: Group the replaced WHERE expressions according to their respective tables to obtain WHERE filtering conditions, and use the table references, JOIN connection conditions, and WHERE filtering conditions as the definition body association structure information of the corresponding CTE definition body.

[0067] In this embodiment, after obtaining the replaced WHERE expression, the WHERE conditions in the replaced WHERE expression can be grouped according to the table to which they belong.

[0068] For example, for simple expressions of type `column operator value`, the table to which it belongs can be located by the column prefix alias; for compound operators spanning multiple terms (e.g., `BETWEEN value1 AND value2`, `IS NULL`, `IS NOT NULL`, `IN (...)`), when the starting term of the above compound operator is scanned, several adjacent terms can be pre-read and included in the current conditional expression: when reading BETWEEN, the three terms "value1, AND, value2" can be merged to form a complete WHERE filter condition; when reading IS, 1 to 2 terms can be merged and it can be determined whether it is NULL (empty value) or NOT NULL (not empty).

[0069] In this embodiment, replacing the second alias with the corresponding first table name in the local alias mapping table to obtain the JOIN condition can specifically include: determining whether the second alias belongs to the CTE name set; if the second alias does not belong to the CTE name set, then replacing the second alias with the first table name that has a mapping relationship in the local alias mapping table to obtain the JOIN condition. In this embodiment, it is first determined whether the second alias (such as an alias in the ON condition, WHERE condition, etc.) belongs to the CTE name set. If it does not belong, then the second alias is replaced with the first table name (i.e., the name of the physical table) that has a mapping relationship in the local alias mapping table to obtain the JOIN condition.

[0070] Accordingly, replacing the third alias with the corresponding first table name in the local alias mapping table to obtain the replaced WHERE expression may specifically include: determining whether the third alias belongs to the CTE name set; if the third alias does not belong to the CTE name set, then replacing the third alias with the first table name that has a mapping relationship in the local alias mapping table to obtain the replaced WHERE expression. That is, if the alias in the WHERE condition expression does not belong to the CTE name set, then the corresponding alias is replaced with the first table name (i.e., the physical table name) that has a mapping relationship in the local alias mapping table.

[0071] Additionally, it may include: if the second alias or the third alias belongs to the CTE name set, then the second alias or the third alias is labeled as the CTE name of the corresponding CTE object. That is, if the alias in the ON condition and WHERE expression belongs to the CTE name set, then the corresponding alias is labeled as the corresponding CTE name in the CTE name set.

[0072] This application establishes a set of CTE names and compares them with the set of CTE names when resolving table references. This allows for the accurate differentiation between CTE objects and physical tables, avoiding the problem of misidentifying CTE names as source tables and accurately recognizing them as CTE objects, thereby improving the accuracy of data lineage analysis.

[0073] Step S15: Based on the CTE name set and the definition body association structure information, construct the dependency relationship between each CTE object in the current data query statement and other CTE objects or physical tables referenced, obtain the dependency relationship graph, and use the topological sorting algorithm to output the dependency relationship graph to obtain the lineage analysis result of the target tax data.

[0074] In this embodiment, after completing the internal parsing of all CTE definitions, a dependency graph is constructed between different CTE objects. For each CTE object, all table names referenced in its CTE definition are analyzed, and a CTE name set is queried to determine if it is a CTE object. If so, a directed edge from the current CTE object to the referenced CTE object is added to the dependency graph. Additionally, a sink node representing the main query needs to be added to the dependency graph. For each table reference appearing in the FROM / JOIN clauses of the main query, the CTE name set is compared, and a directed edge from the main query node to the referenced CTE object or physical table is added based on the comparison result.

[0075] Furthermore, the dependency graph described above is output using a topological sorting algorithm to obtain the lineage analysis results of the target tax data to be queried. The topological sorting algorithm includes, but is not limited to, Kahn's algorithm and Depth-First Search (DFS) algorithm.

[0076] It should be noted that the final lineage analysis results can be directly used in downstream application scenarios such as permission and compliance verification, sensitive field access auditing, query risk prediction, and data change impact assessment.

[0077] In one specific implementation, the process of constructing the dependency relationships between each CTE object in the current data query statement and other referenced CTE objects or physical tables based on the CTE name set and the definition body association structure information, obtaining a dependency graph, and outputting the dependency graph using a topological sorting algorithm to obtain the lineage analysis results of the target tax data, may specifically include: extracting table references from the definition body association structure information to obtain a second table reference, and determining whether the second table reference hits a CTE name in the CTE name set; if the second table reference hits a CTE name in the CTE name set, then the CTE object corresponding to the second table reference is determined to be a recursive object; if the second table reference does not hit a CTE name in the CTE name set, then the CTE object corresponding to the second table reference is determined to be a non-recursive object, and the dependency relationships between the CTE objects and other referenced CTE objects or physical tables are constructed to obtain a dependency graph; the linear execution order of each node in the dependency graph is determined using the Kahn algorithm, and the dependency graph is output according to a preset text format and the linear execution order to obtain the lineage analysis results of the target tax data. In this embodiment, the table references in the parsed definition body association structure information are first extracted to obtain the second table reference. Then, it is determined whether the second table reference matches a CTE name recorded in the CTE name set. If it matches and the matched CTE name is equal to the name of the CTE object currently being parsed, the CTE object corresponding to the second table reference is determined to be a recursive object. For recursive objects, no directed edges from the current CTE object to itself are added to the dependency graph to ensure the directed acyclic property of the dependency graph, thereby ensuring that the subsequent Kahn algorithm can terminate normally. If it does not match, the CTE object corresponding to the second table reference is determined to be a non-recursive object, and the dependency relationship between the CTE object and other referenced CTE objects or physical tables is constructed, thereby generating a complete dependency graph covering CTE objects with arbitrary depth of nested references and between CTE objects and physical tables.

[0078] Furthermore, Kahn's algorithm is used to calculate the in-degree of each node in the dependency graph, and the linear execution order of each node in the dependency graph is determined based on the in-degree. The physical table node has an in-degree of 0, and nodes with an in-degree of 0 are first added to a First In First Out (FIFO) queue. It should be noted that the initial in-degree of the main query node is determined by the number of CTEs referenced by the FROM / JOIN clauses in the main query and the number of physical tables; it is dequeued last in the sorting process, thus ensuring a linear execution order of "physical table → CTE → main query".

[0079] Specifically, the process of generating a linear execution order can be as follows: Loop through the first-in-first-out (FIFO) queue, adding the head node to the linear execution order list. Decrement the in-degree of all downstream nodes that depend on the head node by 1. If the in-degree of a downstream node reaches 0, add it to the FIFO queue. Repeat this process until the FIFO queue is empty, and then output the linear execution order list. For example, for the SQL statement above, the linear execution order is: `sjck_ywzc.fpkj_mx[physical table]→sjck_ggmx.hydm[physical table]→sjck_ggmx.nsrxx[physical table]→t_month[CTE]→t_risk[CTE]→main query[SELECT]`, that is, the linear execution order is: 1. sjck_ywzc.fpkj_mx [Physics Table] 2. sjck_ggmx.hydm [Physics Table] 3. sjck_ggmx.nsrxx [Physics Table] 4. t_month [CTE] 5. t_risk [CTE] 6. Main query [SELECT].

[0080] It should be noted that when there are no direct dependencies between multiple nodes, a linear execution order can result in multiple equivalent outcomes. For example, the order of the hydm and nsrxx tables in the linear execution order described above can be interchanged. Furthermore, CTE objects not included in the linear execution order list in the SQL statement can be treated as unaccessed CTE objects.

[0081] By using the Kahn topology sorting algorithm to output the linear execution order of each physical table and each CTE object, input data can be provided in a dependency order for query risk prediction and data change impact assessment.

[0082] Finally, the dependency graph is output according to the preset text format and the above linear execution order, thereby obtaining the lineage analysis results for the target tax data.

[0083] The preset text formats include, but are not limited to, structured text, JSON (JavaScript Object Notation, a lightweight data exchange format), or HTML (Hypertext Markup Language, a markup language used to build web pages), tables, and other forms.

[0084] In one specific implementation, the lineage analysis result includes at least the following six parts: The first part is a list of physical tables and CTE objects, one per row, labeled [Physical Table] or [CTE]; the second part is the grouping information of physical tables by schema; the third part is the internal association details of CTE objects, including the name of each CTE object, the set of other CTE objects it depends on, the set of physical tables it references, the internal JOIN relationships and complete ON conditions, and the internal WHERE conditions; the fourth part is the JOIN relationship table of the main query; the fifth part is the WHERE conditions grouped by table; and the sixth part is the linear execution order output by applying the Kahn algorithm. For example, the final lineage analysis result output as structured text is: [Table List] [Physical Table] sjck_ywzc.fpkj_mx [Physical Table] sjck_ggmx.nsrxx [Physics Table] sjck_ggmx.hydm [CTE] t_month [CTE] t_risk [Schema Grouping] sjck_ywzc: fpkj_mx sjck_ggmx: nsrxx, hydm [CTE Object Details] t_month: CTE dependency: (None) Referenced physics table: sjck_ywzc.fpkj_mx INTERNAL WHERE: skssq BETWEEN '202601' AND '202612' Internal Join: (None) t_risk: Depends on CTE: t_month Referenced physics tables: sjck_ggmx.nsrxx, sjck_ggmx.hydm Internal JOIN: t_month m JOIN sjck_ggmx.nsrxx n ON m.nsrsbh = n.nsrsbh sjck_ggmx.nsrxx n JOIN sjck_ggmx.hydm h ON n.hy_dm = h.hy_dm Internal WHERE: n.nsr_zt = '01' [Main Query WHERE] t_risk: je > 1000000 As can be seen, this application first performs lexical and syntactic analysis on the structured query statement input by the user, obtaining multiple token list objects (i.e., TokenList objects). Then, a CTE name set is constructed based on the CTE names in all token list objects, and a depth-first recursive parsing is performed on the CTE definition body based on this set to extract the internal association structure of the definition body. Then, based on the set and the internal association structure of the definition body, the dependency relationship between different CTE objects in the query statement and the referenced physical table is constructed. Finally, the topological sorting algorithm is used to output the constructed dependency graph, thereby realizing the lineage analysis of tax data. For example, the internal relationship structure of the CTE definition is analyzed using a depth-first recursive parsing method. This makes the internal structure of the CTE definition visible. Furthermore, this application constructs the dependency relationship between different CTE objects and the referenced physical tables (i.e., the actual referenced database tables) based on the internal relationship structure of the definition. This avoids misidentifying CTE names as physical table names, thereby ensuring the accuracy of the dependency graph and improving the accuracy of lineage analysis. In addition, the embodiments of this application use a topological sorting algorithm to output the dependency graph, which can help users better understand the flow of tax data and facilitate the smooth completion of tax data auditing.

[0085] Accordingly, this application also discloses a tax data lineage analysis device, applied to a data lineage analysis system deployed in a tax information platform, see [link to relevant documentation]. Figure 3 As shown, the device includes: The acquisition module 11 is used to acquire the structured query statement for the target tax data input by the current user, and obtain the current data query statement; Analysis module 12 is used to perform lexical and syntactic analysis on the current data query statement to obtain multiple word list objects; The identification module 13 is used to identify the CTE objects in each of the lexical list objects respectively; The first construction module 14 is used to construct a set of CTE names based on the CTE names in all the CTE objects; the CTE object consists of a CTE name and a CTE definition body; The parsing module 15 is used to perform depth-first recursive parsing of the CTE definition body in each CTE object based on the CTE name set, so as to extract the internal association structure of the CTE definition body and obtain the definition body association structure information. The second construction module 16 is used to construct the dependency relationship between each CTE object in the current data query statement and other CTE objects or physical tables referenced, based on the CTE name set and the definition body association structure information, to obtain a dependency relationship graph; Output module 17 is used to output the dependency graph using a topological sorting algorithm to obtain the lineage analysis results of the target tax data.

[0086] The specific workflow of each of the above modules can be found in the relevant content disclosed in the foregoing embodiments, and will not be repeated here.

[0087] Furthermore, embodiments of this application also disclose an electronic device, Figure 4 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.

[0088] Figure 4 This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the tax data lineage analysis method disclosed in any of the foregoing embodiments. Alternatively, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0089] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0090] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0091] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the tax data lineage analysis method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include computer programs capable of performing other specific tasks.

[0092] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned disclosed method for tax data lineage analysis. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0093] Furthermore, embodiments of this application also disclose a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the tax data lineage analysis method disclosed above.

[0094] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0095] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0096] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0097] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0098] The foregoing has provided a detailed description of a tax data lineage analysis method, apparatus, device, and storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for analyzing the lineage of tax data, characterized in that, Data lineage analysis systems deployed in tax information platforms include: Obtain the structured query statement for the target tax data input by the current user, and get the current data query statement; Lexical and syntactic analysis are performed on the current data query statement to obtain multiple word list objects; Each CTE object in the lexical list object is identified, and a CTE name set is constructed based on the CTE names in all the CTE objects; each CTE object consists of a CTE name and a CTE definition body. Based on the CTE name set, a depth-first recursive parsing is performed on the CTE definition body in each CTE object to extract the internal association structure of the CTE definition body and obtain the definition body association structure information; Based on the CTE name set and the definition body association structure information, the dependency relationship between each CTE object in the current data query statement and other CTE objects or physical tables referenced is constructed to obtain a dependency graph. The dependency graph is then output using a topological sorting algorithm to obtain the lineage analysis results of the target tax data.

2. The tax data lineage analysis method according to claim 1, characterized in that, The lexical and syntactic analysis of the current data query statement yields multiple word list objects, including: The current data query statement is divided by an SQL parsing engine according to preset lexical rules to obtain a word sequence; the word elements in the word sequence carry two attributes: type and value. The lexical units in the lexical sequence are combined according to the bracket hierarchy and preset grammar rules to obtain nested list objects of multiple lexical units.

3. The tax data lineage analysis method according to claim 1, characterized in that, The step of identifying CTE objects in each of the lexical list objects includes: Identify the WITH keyword in the term list object, and scan each term list object sequentially along the WITH keyword to extract the CTE name before the AS keyword and the CTE definition body after the AS keyword in the term list object; The CTE name and the CTE definition are used as CTE objects for the corresponding lexical list objects.

4. The tax data lineage analysis method according to claim 3, characterized in that, The step of extracting the internal association structure of the CTE definition body to obtain the definition body association structure information includes: Extract the table references, JOIN conditions, and WHERE filtering conditions from the CTE definition body to obtain the definition body's associated structure information; the JOIN conditions include JOIN type and ON condition.

5. The tax data lineage analysis method according to claim 4, characterized in that, The step of extracting table references, JOIN join conditions, and WHERE filter conditions from the CTE definition body yields the definition body's associated structure information, including: The first table reference is obtained by identifying the table references located after the FROM and JOIN clauses in the CTE definition body based on the state machine mechanism; Identify the aliases in the first table reference and the table names of the physical tables corresponding to the aliases to obtain the first alias and the first table name; A local alias mapping table is created based on the first alias and the first table name for the corresponding CTE definition body; Identify the ON condition in the first table reference, and use a preset regular expression to identify the alias in the ON condition to obtain the second alias. Then replace the second alias with the corresponding first table name in the local alias mapping table to obtain the JOIN connection condition. Scan the conditional expression following the WHERE keyword in the CTE definition body to obtain the WHERE conditional expression; Identify the alias in the WHERE condition expression to obtain the third alias, and replace the third alias with the corresponding first table name in the local alias mapping table to obtain the replaced WHERE expression; The replaced WHERE expressions are grouped according to their respective tables to obtain WHERE filtering conditions, and the table references, JOIN connection conditions, and WHERE filtering conditions are used as the definition body association structure information of the corresponding CTE definition body.

6. The tax data lineage analysis method according to claim 5, characterized in that, The step of replacing the second alias with the corresponding first table name in the local alias mapping table to obtain the JOIN join condition includes: Determine whether the second alias belongs to the CTE name set; If the second alias does not belong to the CTE name set, then the second alias is replaced with the first table name that has a mapping relationship in the local alias mapping table to obtain the JOIN join condition; Accordingly, replacing the third alias with the corresponding first table name in the local alias mapping table to obtain the replaced WHERE expression includes: Determine whether the third alias belongs to the CTE name set; If the third alias does not belong to the CTE name set, then the third alias is replaced with the first table name that has a mapping relationship in the local alias mapping table, resulting in the replaced WHERE expression; The tax data lineage analysis method also includes: If the second alias or the third alias belongs to the CTE name set, then the second alias or the third alias is marked as the CTE name of the corresponding CTE object.

7. The tax data lineage analysis method according to claim 6, characterized in that, Based on the CTE name set and the definition body association structure information, the dependency relationships between each CTE object in the current data query statement and other referenced CTE objects or physical tables are constructed to obtain a dependency graph. The dependency graph is then output using a topological sorting algorithm to obtain the lineage analysis results of the target tax data, including: Extract the table references from the definition body association structure information to obtain the second table reference, and determine whether the second table reference matches a CTE name in the CTE name set; If the second table reference hits a CTE name in the set of CTE names, then the CTE object corresponding to the second table reference is determined to be a recursive object; If the second table reference does not match any CTE name in the CTE name set, then the CTE object corresponding to the second table reference is determined to be a non-recursive object, and the dependency relationship between the CTE object and other referenced CTE objects or physical tables is constructed to obtain a dependency graph. The linear execution order of each node in the dependency graph is determined using the Kahn algorithm, and the dependency graph is output according to a preset text format and the linear execution order to obtain the lineage analysis results of the target tax data.

8. A tax data lineage analysis device, characterized in that, Data lineage analysis systems deployed in tax information platforms include: The acquisition module is used to acquire the structured query statement of the current user for the target tax data and obtain the current data query statement; The analysis module is used to perform lexical and syntactic analysis on the current data query statement to obtain multiple word list objects; The identification module is used to identify the CTE objects in each of the lexical list objects respectively; The first construction module is used to construct a set of CTE names based on the CTE names in all the CTE objects; the CTE object consists of a CTE name and a CTE definition body. The parsing module is used to perform depth-first recursive parsing of the CTE definition body in each CTE object based on the CTE name set, so as to extract the internal association structure of the CTE definition body and obtain the definition body association structure information. The second construction module is used to construct the dependency relationship between each CTE object in the current data query statement and other CTE objects or physical tables referenced, based on the CTE name set and the definition body association structure information, to obtain a dependency relationship graph; The output module is used to output the dependency graph using a topological sorting algorithm to obtain the lineage analysis results of the target tax data.

9. An electronic device, characterized in that, It includes a processor and a memory; wherein, when the processor executes a computer program stored in the memory, it implements the tax data lineage analysis method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Used to store computer programs; wherein, when the computer programs are executed by a processor, they implement the tax data lineage analysis method as described in any one of claims 1 to 7.

Images