Report data tracing method and device, computer equipment, readable storage medium and program product

By constructing and visualizing the lineage map of report data, the data flow path can be automatically traced, solving the problems of low efficiency and insufficient accuracy of report data tracing in existing technologies, and realizing efficient and accurate data tracing and visualization.

CN121705348APending Publication Date: 2026-03-20KINGDEE SOFTWARE(CHINA) CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202511915706.5
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-12-18
Publication Date
2026-03-20

AI Technical Summary

Technical Problem

In existing technologies, data traceability in reports relies on manual methods, which are inefficient, lack accuracy, and have high technical barriers, making it difficult to meet the needs for efficient and accurate data traceability.

Method used

By constructing a target data lineage graph, the data flow path from report cells to database table fields is traced in reverse. The nodes and edges in the graph represent data entities and flow relationships, enabling automated data tracing and visualizing the path as a hierarchical relationship graph.

Benefits of technology

It achieves a second-level response from report cells to source database fields, improving traceability efficiency and accuracy, lowering the technical threshold, enabling business personnel to intuitively understand the data generation process, and enhancing data trust.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121705348A_ABST
    Figure CN121705348A_ABST
Patent Text Reader

Abstract

The invention relates to a report data tracing method and device, computer equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: responding to a data traceability request for a target cell in a currently displayed target report; obtaining a target data blood relationship map corresponding to the target report; nodes in the data consanguinity map represent data entities, and edges among the nodes represent a data flow relationship; the data entity comprises at least one of a table cell, a data query statement and a database table field; traversing an upstream node quoted by a target node corresponding to the target cell according to the reverse direction of the edge in the target data consanguinity map by taking the target cell as a starting point until a node corresponding to the database table field is searched, and obtaining a target data flow path corresponding to the target cell; and displaying the target data flow path. By adopting the method, the report data tracing efficiency and accuracy can be improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of computer data processing technology, and in particular to a method, apparatus, computer equipment, computer-readable storage medium, and computer program product for tracing report data. Background Technology

[0002] With the deepening development of enterprise informatization and data-driven decision-making technologies, the field of business intelligence and data analysis increasingly relies on various dynamic reports to present complex business indicators. These report data typically originate from multiple heterogeneous data sources and undergo processing such as calculation, transformation, and aggregation, ultimately serving management decisions in a visualized form.

[0003] In traditional technologies and most existing reporting systems, when users have questions about the accuracy, consistency, or business meaning of specific data in a report, they usually rely on a manual traceability method.

[0004] Specifically, business personnel or data analysts need to consult with technical developers, who then manually review static report definition scripts, database query statements, ETL processing logic, and even application source code to attempt to infer and interpret the source and calculation process of the data. However, this manual tracing method suffers from low efficiency, insufficient accuracy, and a high technical barrier.

[0005] Therefore, there is a need for a report data traceability solution that can lower the threshold for data traceability and improve the efficiency and accuracy of data traceability. Summary of the Invention

[0006] Therefore, it is necessary to provide a report data traceability method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can improve the efficiency and accuracy of data traceability in response to the above-mentioned technical problems.

[0007] Firstly, this application provides a method for tracing the source of report data, the method comprising:

[0008] Responding to a data tracing request for a target cell in the currently displayed target report;

[0009] Obtain the target data lineage graph corresponding to the target report; the nodes in the data lineage graph represent data entities, and the edges between the nodes represent data flow relationships; the data entity includes at least one of a cell, a data query statement, and a database table field;

[0010] Starting from the target cell, in the target data lineage graph, the upstream nodes referenced by the target node corresponding to the target cell are traversed in reverse order of the edge direction until the node corresponding to the database table field is found, thus obtaining the target data flow path corresponding to the target cell;

[0011] The target data flow path is displayed.

[0012] In some embodiments, the edges between the nodes include dependency edges representing computational dependencies and data edges representing data source relationships; obtaining the target data lineage graph corresponding to the target report includes:

[0013] Obtain the generation process record of the target report and the report definition file;

[0014] The generation process record is parsed to obtain the data query statements executed during the rendering of the target report and the source data information accessed by the query statements;

[0015] The report definition file is parsed to obtain the data processing logic corresponding to each candidate cell in the target report; the data processing logic includes calculating the values ​​of other cells based on the calculation dependency relationship or binding the query results to the query statement based on the data source relationship;

[0016] The target data lineage map is constructed based on the query statement, source data information, and data processing logic.

[0017] In some embodiments, constructing the target data lineage map based on the query statement, source data information, and the data processing logic includes:

[0018] For the candidate cell configured with the computational dependency, perform syntax parsing on the computational dependency corresponding to the candidate cell to obtain the abstract syntax tree corresponding to the computational dependency;

[0019] Analyze the abstract syntax tree to obtain the identifier of at least one source cell of the input parameters that constitute the computational dependency;

[0020] In the data lineage graph, a dependency edge is created from the node corresponding to the identifier of the source cell to the node corresponding to the current candidate cell.

[0021] In some embodiments, constructing the data lineage map corresponding to the target report based on the query statement, source data information, and the data processing logic includes:

[0022] For the candidate cell configured with the data source relationship, the target data field bound to the current candidate cell is determined according to the data source relationship;

[0023] In the data lineage graph, a data edge is created between the target data query statement node and the node corresponding to the current candidate cell; the target data query statement node is the node corresponding to the data query statement that returns the target data field after execution.

[0024] In some embodiments, the target data flow path is displayed as follows:

[0025] The data flow path is visualized as a hierarchical relationship diagram; wherein, the hierarchical relationship diagram presents the path from the source data table field node to the target cell node, through the query statement node and the intermediate cell node; the hierarchical relationship diagram distinguishes and displays the dependency edge and the data edge;

[0026] In response to a location command for any cell node in the hierarchical relationship diagram, the actual cell corresponding to the cell node is highlighted in the interface of the target report.

[0027] In some embodiments, displaying the data flow path includes:

[0028] In response to the user's selection of a target node on the hierarchical relationship graph, the node parameters of the target node are displayed; wherein, if the selected node is a cell node, the node parameters include the calculation dependency relationship or the data source relationship corresponding to the cell; if the selected node is a data query statement node, the node parameters include the query statement and the execution conditions of the query statement.

[0029] Secondly, this application also provides a report data traceability device, the device comprising:

[0030] The response module is used to respond to data tracing requests for target cells in the currently displayed target report;

[0031] The acquisition module is used to acquire the target data lineage graph corresponding to the target report; the nodes in the data lineage graph represent data entities, and the edges between the nodes represent data flow relationships; the data entities include at least one of cells, data query statements, and database table fields.

[0032] The search module is used to traverse the upstream nodes referenced by the target node corresponding to the target cell in the target data lineage graph in reverse order of the edge direction, starting from the target cell, until the node corresponding to the database table field is found, so as to obtain the target data flow path corresponding to the target cell.

[0033] The display module is used to display the target data flow path.

[0034] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps included in any of the aforementioned report data traceability method embodiments.

[0035] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps included in any of the aforementioned report data traceability method embodiments.

[0036] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps included in any of the aforementioned report data traceability method embodiments.

[0037] The aforementioned report data tracing method, apparatus, computer equipment, computer-readable storage medium, and computer program product, in response to a data tracing request for a target cell in a currently displayed target report, obtain a target data lineage graph corresponding to the target report; the nodes in the data lineage graph represent data entities, and the edges between the nodes represent data flow relationships; the data entity includes at least one of a cell, a data query statement, and a database table field; starting from the target cell, traverse the upstream nodes referenced by the target node corresponding to the target cell in the target data lineage graph in reverse order of the edge direction until the node corresponding to the database table field is found, thereby obtaining the target data flow path corresponding to the target cell; and display the target data flow path. This invention, through the introduction and querying of refined data lineage maps, can automatically complete the full path tracing from report cells to source database fields. This transforms the traditional, inefficient, manual investigation process relying on technical personnel into automated tracing with millisecond-level response and cell-level accuracy. This greatly improves the efficiency and accuracy of tracing. Furthermore, by visualizing the data flow path, it transforms the technical details originally hidden in scripts and databases into business language that business personnel can intuitively understand, thereby improving the efficiency and accuracy of data tracing and lowering the technical threshold for data tracing. Attached Figure Description

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

[0039] Figure 1 This is a diagram illustrating the application environment of a report data tracing method in one embodiment.

[0040] Figure 2 This is a flowchart illustrating a report data tracing method in one embodiment;

[0041] Figure 3 This is a flowchart illustrating the report data tracing method in another embodiment;

[0042] Figure 4 This is a schematic diagram of the interface in a report data tracing method in one embodiment, illustrating the user triggering a tracing request.

[0043] Figure 5 This is a schematic diagram of the calculation process logic display interface in the report data tracing method of one embodiment;

[0044] Figure 6 This is a schematic diagram of the data source details display interface in the report data tracing method of one embodiment;

[0045] Figure 7 This is a schematic diagram of the cell location operation entry interface in a report data tracing method in one embodiment;

[0046] Figure 8 This is a schematic diagram illustrating the highlighted display effect of a report cell in a report data tracing method in one embodiment;

[0047] Figure 9 This is a schematic diagram illustrating query statement parsing and business semantic mapping in a report data tracing method of one embodiment.

[0048] Figure 10 This is a flowchart of the internal processing of the formula parsing engine in a report data tracing method in one embodiment.

[0049] Figure 11 This is a structural block diagram of a report data traceability device in one embodiment;

[0050] Figure 12 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0051] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0052] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0053] The report data tracing method provided in this application embodiment can be applied to, for example... Figure 1 In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104 or placed on a cloud or other network server. Server 104 responds to a data tracing request for a target cell in the target report currently displayed on terminal 102; it obtains the target data lineage graph corresponding to the target report; the nodes in the data lineage graph represent data entities, and the edges between the nodes represent data flow relationships; the data entity includes at least one of a cell, a data query statement, and a database table field; starting from the target cell, it traverses the upstream nodes referenced by the target node corresponding to the target cell in the target data lineage graph in reverse order of the edge direction until the node corresponding to the database table field is found, thus obtaining the target data flow path corresponding to the target cell; and displays the target data flow path through terminal 102. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, and projection equipment. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted displays. Head-mounted displays can be virtual reality (VR) devices, augmented reality (AR) devices, and smart glasses. Server 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0054] In one exemplary embodiment, such as Figure 2 As shown, a method for tracing report data is provided, which can be applied to... Figure 1 Taking server 104 as an example, the following steps are included:

[0055] Step 202: Respond to the data tracing request for the target cell in the currently displayed target report.

[0056] The target report can be a specific business report displayed on a terminal (such as a computer browser or a mobile app). It is dynamically generated and rendered by the reporting system based on a pre-designed template (i.e., a "report definition file"), after executing a series of data queries and processing logic. For example, an online report titled "Sales Profit Statement for Each Department in the First Quarter of 2024" is a "target report." This report contains multiple cells, each containing specific data such as text or numbers.

[0057] A data tracing request can be a user-initiated instruction to investigate the complete source path of specific data in a report. For example, when a user has doubts about the accuracy or meaning of data in a report (e.g., questioning the value in the "Net Profit" cell), they can select the cell (the "target cell") by clicking or long-pressing and triggering a "View Source" or similar button. This interaction generates a "data tracing request," the core message of which is: "Please tell me, where did the data in this cell come from?"

[0058] Data tracing refers to tracing and revealing the complete data processing and flow chain from the earliest database record to the final report cell display value. For example, starting from a specific data cell in the final target report, one can trace back layer by layer according to the data lineage diagram until the earliest original data record and all the calculation steps are found.

[0059] Step 204: Obtain the target data lineage graph corresponding to the target report; the nodes in the data lineage graph represent data entities, and the edges between the nodes represent data flow relationships; the data entity includes at least one of a cell, a data query statement, and a database table field.

[0060] The target data lineage graph can be a graph structure model built in advance or in real-time for the target report to describe its internal data dependencies. Nodes in the target data lineage graph represent the different forms of data at different stages. Specifically, database table field nodes represent the final source of the data (i.e., the data source), which can serve as the starting point of the data lineage. For example, the node [DB_Field: sales_data.amount] represents the amount field in the sales_data database table. Source data can be specifically represented by specific tables and fields in the database. Data query statement nodes represent operations that extract data from the data source. For example, the node [Query: SELECT amount FROM sales_data WHEREdept='Sales'] represents an SQL statement that queries the sales department's sales revenue. Correspondingly, cell nodes represent the interface elements on the report that ultimately display the data. For example, the node [Cell: B2] corresponds to the display value of cell B2 on the report.

[0061] Edges in a target data lineage graph can be directed. An edge connecting two nodes represents the transfer or transformation of data between those two points, i.e., the flow of data. For example, an edge from [DB_Field: sales_data.amount] to [Query: SELECT ...] indicates that the query read data from that field. An edge from [Query: SELECT ...] to [Cell: C5] indicates that the value of cell C5 comes directly from the execution result of the query. An edge from [Cell: C5] to [Cell: D10] indicates that the value of cell D10 is obtained by referencing the value of cell C5 through a calculation formula (e.g., D10 = C5 * 0.1).

[0062] Step 206: Starting from the target cell, in the target data lineage graph, traverse the upstream nodes referenced by the target node corresponding to the target cell in reverse order of the edge direction until the node corresponding to the database table field is found, and obtain the target data flow path corresponding to the target cell.

[0063] After loading the target data lineage graph, starting from the node corresponding to the "target cell" clicked by the user (i.e., the target node), the process searches for all upstream nodes directly or indirectly referenced by the target node, following the opposite direction of the data flow (reverse, i.e., from the final result to the original source). Specifically, starting from the target node, the process searches backward along the "edge" leading to that node to find its parent node; then, using these parent nodes as new starting points, the reverse search continues recursively. When the traversed node type is a database table field, it indicates that the data source has been reached, and the traversal stops. All nodes and edges traversed during the entire traversal process are output. These nodes and edges together constitute the complete target data flow path from the target cell to the source data. This target data flow path clearly shows which calculation steps and query statements the data in the target cell underwent, and ultimately, which database and which field it originated from.

[0064] For example, suppose a user clicks on cell D10 in a report (with a value of 1050), triggering the following data tracing process: First, locate the node [Cell: D10] corresponding to D10 in the graph. Perform the first level of backtracking and find that [Cell: D10] has an incoming edge (i.e., a reference relationship) from node [Cell: C5], with the relationship being "computation dependency" (i.e., D10 = C5 * 0.1). At this point, the path record is D10 <- C5. Then, perform the second level of backtracking, tracing back to [Cell: C5], and find that it has an incoming edge from node [Query: SELECT amount FROM sales_data WHERE dept='Sales'], with the relationship being "data source". Update the current target data flow path to D10 <- C5 <- Query(Sales). Then, perform the third level of backtracking, tracing back to the query statement node, and find that it has an incoming edge from node [DB_Field: sales_data.amount]. It should be noted that in this embodiment of the invention, the database table field node is used as the traversal endpoint because it represents the original source of the data and is the final anchor point for data credibility. This completes the full tracing from the "displayed value" to the "system record." The final "target data flow path" is an ordered sequence of nodes: [Cell: D10] <- [Cell: C5] <- [Query: SELECT ...] <- [DB_Field: sales_data.amount]. This path fully describes that "the 1050 yuan in cell D10 is calculated by multiplying the 10500 yuan in cell C5 by 10%, and the 10500 yuan in cell C5 is obtained by querying the amount field of all records in the sales_data table with dept='Sales' and summing them."

[0065] Step 208: Display the target data flow path.

[0066] To present the calculated tracing results in a more user-friendly way, the aforementioned target data flow path can be rendered into a hierarchical diagram or flowchart through a graphical interface (such as a sidebar or pop-up). This visualization clearly shows the complete link from the source data field to the target cell, and uses different colors or line styles to distinguish different types of flow relationships such as "data source" and "calculation dependency," enabling users to intuitively and quickly understand the data generation process.

[0067] This invention refines the granularity of data tracing from the report or table level down to the individual cell level, achieving unprecedented precision in data localization. It transforms the previously cumbersome process of manual, cross-system troubleshooting by technical personnel into a system-automated process completed in seconds, significantly improving the efficiency of data problem investigation and understanding. Through a visualized data path, business personnel can independently complete data tracing without understanding underlying technical details (such as SQL or database schemas), breaking down communication barriers between technology and business and enhancing data trust. By tracing back to the database table field as the data source, it provides a complete and reliable chain of evidence for every number in the report, strongly supporting data-driven decision-making.

[0068] In some embodiments, the edges between the nodes include dependency edges representing computational dependencies and data edges representing data source relationships; obtaining the target data lineage graph corresponding to the target report includes:

[0069] Obtain the generation process record of the target report and the report definition file;

[0070] The generation process record is parsed to obtain the data query statements executed during the rendering of the target report and the source data information accessed by the query statements;

[0071] The report definition file is parsed to obtain the data processing logic corresponding to each candidate cell in the target report; the data processing logic includes calculating the values ​​of other cells based on the calculation dependency relationship or binding the query results to the query statement based on the data source relationship;

[0072] The target data lineage map is constructed based on the query statement, source data information, and data processing logic.

[0073] The report definition file can be viewed as the design blueprint for the report. It can be a structured file (such as XML or JSON format) generated by a report designer (such as FineReport or Tableau Desktop). The report definition file statically defines the report's layout, style, and the data processing logic for each cell. For example, it specifies whether a cell is directly bound to a data field or configured with the formula =A1+B1.

[0074] The generation process log can be the report's runtime log, dynamically recording the actual operations performed during the report rendering process. Specifically, the generation process log can be obtained by intercepting database query traffic, analyzing database audit logs, or through reporting tool plugins. The generation process log contains all the data query statements actually initiated by the report to retrieve data from the database.

[0075] Each original query statement (such as an SQL statement) in the record undergoes lexical and syntactic analysis, for example, using an SQL parser (such as one generated by ANTLR), to extract the source data information accessed by the query. The source data information can include at least: source table name (e.g., sales_data); source field names (e.g., amount, order_date); and query conditions (e.g., WHERE department = 'Sales'). The source data information identifies specifically which tables and fields in the database the data in the currently displayed target cell was retrieved from.

[0076] The report definition file is parsed, each cell (i.e., "candidate cell") is traversed, and the source method of its data, i.e., the data processing logic, is determined. This data processing logic can include calculation-based dependencies and data source-based relationships. If a cell has a configured formula (e.g., =B2*C2), its data processing logic uses calculation dependencies to reference the values ​​of one or more other cells for calculation. Conversely, if a cell does not have a configured formula but is directly dragged and bound to a data field, its data processing logic uses data source relationships to directly present the specific field value from the result set returned by a data query.

[0077] This completes the process of creating corresponding nodes in the graph for each source table field, each data query statement, and each candidate cell parsed in the preceding steps. Then, based on the data source relationships, data edges are established between the data query statement node and the cell nodes filled by its result set; simultaneously, data edges are also established between the data query statement node and the source table field node it queries. Finally, based on computational dependencies, dependency edges are established between the source cell node referenced by the calculation formula and the target cell node used in the calculation.

[0078] Through the above steps, a complete and accurate target data lineage map that can support cell-level reverse tracing is constructed. This embodiment of the invention automatically constructs the core data lineage map from the design and operation information of the report, providing technical support for achieving efficient and accurate data traceability.

[0079] In some embodiments, constructing the target data lineage map based on the query statement, source data information, and the data processing logic includes:

[0080] For the candidate cell configured with the computational dependency, perform syntax parsing on the computational dependency corresponding to the candidate cell to obtain the abstract syntax tree corresponding to the computational dependency;

[0081] Analyze the abstract syntax tree to obtain the identifier of at least one source cell of the input parameters that constitute the computational dependency;

[0082] In the data lineage graph, a dependency edge is created from the node corresponding to the identifier of the source cell to the node corresponding to the current candidate cell.

[0083] The computational dependencies can be represented by calculation formulas or expressions configured in the report cells. For example, the formula configured in cell D2 is =B2 * (1 + C2). Syntax parsing can process the above text formulas using a preset parser (e.g., a parser developed for Excel formula syntax or custom formula syntax for specific reporting tools).

[0084] Transform a linear textual formula into a structured abstract syntax tree (AST). This tree precisely reflects the computational logic and structure of the formula, rather than its textual form. For example, the formula =B2 * (1 + C2) might be parsed into an AST with the following structure:

[0085] [operator: *]

[0086] / \

[0087] [Operand: B2] [Operator: +]

[0088] / \

[0089] [Constant: 1] [Operand: C2];

[0090] The above AST is traversed to identify all leaf nodes in the tree. Among the identified leaf nodes, those representing cell references (excluding constants such as 1) are the input parameters for this formula. The source cell identifiers are extracted, and the identifiers of the referenced cells are collected. For example, by analyzing the above AST, the system can accurately extract two input parameters: B2 and C2. This means that the calculation result of cell D2 directly depends on the values ​​of cells B2 and C2.

[0091] The analyzed dependencies are then solidified into the data lineage graph. Specifically, this involves finding the nodes corresponding to the extracted source cell identifiers (e.g., B2, C2) and the nodes corresponding to the currently processed candidate cells (e.g., D2) in the initially constructed data lineage graph. A directed edge is created from the [Cell: B2] node to the [Cell: D2] node, and another directed edge is created from the [Cell: C2] node to the [Cell: D2] node. These edges are labeled as dependency edges, meaning that the value of D2 is generated by a calculation formula that depends on the values ​​of B2 and C2.

[0092] This embodiment can automatically and comprehensively parse out all cell-level dependencies implied in complex calculation formulas within reports, and accurately transform these relationships into the topological structure of a data lineage graph. This provides the technical foundation for reliable, layer-by-layer backtracking from the target cell, ensuring the integrity and accuracy of the tracing path.

[0093] In some embodiments, constructing the data lineage map corresponding to the target report based on the query statement, source data information, and the data processing logic includes:

[0094] For the candidate cell configured with the data source relationship, the target data field bound to the current candidate cell is determined according to the data source relationship;

[0095] In the data lineage graph, a data edge is created between the target data query statement node and the node corresponding to the current candidate cell; the target data query statement node is the node corresponding to the data query statement that returns the target data field after execution.

[0096] In this context, the data source relationship represents the direct correspondence between a cell and the original data. Specifically, the data source relationship can refer to the relationship established during the report design phase, through drag-and-drop operations or attribute configuration, that binds a cell in the report to a specific field in a data query result set. For example, in the report designer, if a developer drags and drops the employee_name field from the dataset to cell A3 of the report, this establishes a data source relationship between cell A3 and the employee_name field.

[0097] By parsing the report definition file, the binding information of such cells can be accurately obtained. For example, for the currently processed candidate cell (e.g., [Cell:A3]), the target data field it is bound to can be parsed from its attributes. For instance, if the target data field is employee_name, then the display value of cell A3 will be directly filled by the query result returning the employee_name field.

[0098] In the graph, connections are established from data acquisition operations to data display elements. Matching searches are performed on the query statements obtained from the pre-parsed generation process records to find the query statement whose result set, after execution, contains the `employee_name` field. For example, the node `[Query:SELECTemployee_id,employee_nameFROMemployee_tableWHEREstatus='Active']` is found. This node is the target data query statement node.

[0099] After the search, create a directed edge in the target data lineage graph, pointing from the [Query:SELECT...] node located above to the current candidate cell [Cell:A3]. This edge is labeled as a "data edge," meaning that the data in cell A3 comes directly from the employee_name field in the result set of the query statement.

[0100] The embodiments of the present invention can automatically establish a precise connection between the cells in the report used to display basic data and the backend data query, thereby extending the "flow" of data from the query operation inside the database to the report interface visible to the end user, providing an accurate and traceable intermediate link for the complete data flow path.

[0101] In some embodiments, the target data flow path is displayed as follows:

[0102] The data flow path is visualized as a hierarchical relationship diagram; wherein, the hierarchical relationship diagram presents the path from the source data table field node to the target cell node, through the query statement node and the intermediate cell node; the hierarchical relationship diagram distinguishes and displays the dependency edge and the data edge;

[0103] In response to a location command for any cell node in the hierarchical relationship diagram, the actual cell corresponding to the cell node is highlighted in the interface of the target report.

[0104] In order to transform the calculated abstract path into an intuitive graph, the target data flow path can be rendered as a hierarchical relationship diagram from top to bottom or from left to right in a separate area of ​​the preset user interface (such as a sidebar, pop-up window or floating panel), so that the complex dependencies can be seen at a glance.

[0105] Specifically, a typical path might be displayed as a chain of: [DB_Field: sales.amount] → [Query:SELECT ...] → [Cell: B2] → [Cell: C5] → [Cell: D10]. This chain can intuitively show that the data in cell D10 comes from the calculation in C5, the data in C5 comes from B2, and the data in B2 is obtained from the amount field of the sales table by a specific query statement.

[0106] Optionally, to more clearly express the nature of data flow, dependency edges and data edges can be visually distinguished in the hierarchy diagram. Data edges can be represented by solid arrows, symbolizing direct data transfer (from a query to a cell, or from a database field to a query). Dependency edges can be represented by dashed arrows or arrows of different colors, symbolizing computational references between cells, allowing users to quickly understand which steps involve simple data transfer and which involve business logic calculations.

[0107] When viewing the hierarchical relationship diagram, users can trigger a query operation on any cell node (e.g., [Cell:C5]). This can be triggered by hovering the mouse, clicking, or selecting "Locate" from the right-click menu. In response to this query command, the actual cell corresponding to that node is located and highlighted on the original target report interface. For example, when a user clicks the [Cell:C5] node in the diagram, the actual cell C5 on the report will be visually emphasized with a prominent background color (e.g., yellow), a thicker border, or a blinking animation.

[0108] This embodiment transforms complex and technical data links into clear graphics through the aforementioned interactive visualization scheme, greatly reducing the understanding threshold for business personnel and achieving a seamless mapping from "logical path" to "physical location." When a user sees a key node in the graph (such as [Cell: C5] as an intermediate calculation result), they can immediately locate it on the report using the "locate" function, realizing the linkage between the graph and the report, which facilitates on-site verification and comparative analysis for users.

[0109] For example, suppose a user initiates a data tracing exercise on the "Tax Payable" cell (value 924.21) in a report. The system displays a hierarchical relationship diagram showing the following path: [DB_Field: ...] → [Query: ...] → [Cell: B10] → [Cell: C10] → [Tax Payable Cell], with the annotation [Tax Payable Cell] = [Cell: B10] - [Cell: C10]. At this point, the user may wonder about the specific meaning and value of [Cell: B10] and [Cell: C10]. The user simply clicks on the [Cell: B10] node in the hierarchical relationship diagram and selects "Locate," immediately highlighting cell B10 in yellow. Similarly, clicking on the [Cell: C10] node highlights cell C10. Through this interaction, the user can quickly understand which cells next to "Tax Payable" are its direct calculation source, achieving a WYSIWYG report data tracing experience and breaking down the barriers between business data and technical support.

[0110] In some embodiments, displaying the data flow path includes:

[0111] In response to the user's selection of a target node on the hierarchical relationship graph, the node parameters of the target node are displayed; wherein, if the selected node is a cell node, the node parameters include the calculation dependency relationship or the data source relationship corresponding to the cell; if the selected node is a data query statement node, the node parameters include the query statement and the execution conditions of the query statement.

[0112] In order to provide the ability to drill down from macroscopic paths to microscopic details and achieve in-depth tracing of report data, in this embodiment, when users view the hierarchical relationship diagram, they can select any node in the path as the target node by clicking, touching, etc., to explore its specific details. In response to this operation, a node parameter corresponding to the node type is dynamically loaded and displayed in an information panel (such as tooltips or side details bar), thereby giving users the ability to investigate in depth layer by layer along the tracing path and achieve a layer-by-layer tracing experience.

[0113] For example: Suppose a user traces the source of the "Tax Payable" cell (value 924.21) in the report, and the resulting hierarchical path is: [DB_Field: profit_data.tax_base] → [Query_A] → [Cell: Taxable Base] → [Cell: Tax Reduction] → [Cell: Tax Payable].

[0114] When a user clicks on a cell node, such as the [Cell: Tax Payable] node, its calculation dependencies are displayed, i.e., the calculation formula: = [Taxable Base] - [Deductions]. This directly answers the question, "How is 924.21 calculated?" Subsequently, when the user clicks on its upstream node [Cell: Taxable Base], the node parameters show its data source relationships, such as data binding: Profit and Loss Statement.Taxable Income. This answers the question, "Where does the 'Taxable Base' figure used in the calculation come from?"

[0115] Correspondingly, when a user clicks on a data query statement node, if the user continues upwards and clicks the [Query_A] node, the complete query statement is displayed, such as SELECT tax_base FROM profit_data WHERE company_id ='C001' AND quarter = '2023Q4', with the execution conditions explicitly listed: company_id = 'C001' (corresponding to "Huanyu International"), quarter = '2023Q4'. This achieves a clear display of the business context, unlike simply displaying field names. In this embodiment, it indicates that this "taxable base" is the data for "Huanyu International" in the "fourth quarter of 2023". By displaying the query statement and its execution conditions, technical SQL is transformed into business filtering conditions that business personnel can understand (such as targeting specific companies or specific time ranges), greatly enhancing the interpretability and trustworthiness of the data. Furthermore, if there are errors in the data, users can quickly locate the problem by checking the node parameters layer by layer. Is the calculation formula wrong? Is the data bound to the wrong field? Or are the query conditions in the source data set incorrectly? The troubleshooting process becomes clearer and more efficient than ever before.

[0116] In one exemplary embodiment, the data tracing process can be as follows: Figure 3 As shown, Figure 3 As shown, the process can begin with a tracing request sent by a user to a target cell in a report. Upon receiving the request, the system first determines whether the relevant data lineage graph exists (i.e., whether it's an existing or incremental scenario). If the graph already exists (existing), it is directly queried; if it doesn't exist (incremental), a construction process is initiated. This process includes querying calculation rules, expressions, and formulas, which are then parsed by the parsing engine, and subsequently the lineage analysis engine generates the graph. Regardless of the path, a tracing path is ultimately generated and rendered and displayed to the user by the visualization module.

[0117] When a user interacts with the front-end report interface, the starting point of their interaction can be as follows: Figure 4As shown, users can trigger a data tracing request by clicking on a specific target cell (such as the "Tax Payable" cell with a value of "924.21") in the currently displayed report.

[0118] The initial visual representation of the response to a user request is as follows: Figure 5 As shown. After the user clicks, a traceability panel will pop up, which clearly shows the calculation logic of the target cell. For example, it explicitly states that "tax payable of 924.21" is derived from the formula "924.21 - 0 - 0".

[0119] To further reveal the business implications of the data, this embodiment of the invention also provides a detailed drill-down function, the interface of which can be as follows: Figure 6 As shown. When the user... Figure 5 If you have any questions about specific data items in the calculation formula (such as "924.21", "0"), you can click [here]. Figure 5 The "Details" button will display the data source details for that data item. For example, it will clearly indicate that the first "924.21" comes from the "Operating Revenue" field in the "Profit Recognition Working Paper" table, thus clearly revealing the data consistency between the internal and external reports.

[0120] To achieve linkage between the traceability path and the report interface, a location function was designed, and its operation entry point can be found as follows: Figure 7 As shown in the diagram. In the traceability panel, each data item has a "Locate" button next to it; clicking it triggers a location command. The effect of the location command is indicated by a highlight in the front-end report, as shown below. Figure 8 As shown. When the user clicks on the location, the actual cell corresponding to the data item will be highlighted in the original report interface in a prominent way (e.g., yellow background, bold border, or underline), thus establishing an intuitive mapping between the visual path and the physical report location. When building the data lineage graph in the backend, the steps for handling external data sources can be as follows: Figure 9 As shown. Figure 9 This demonstrates how to parse query statements from a database. The parsing engine performs syntax analysis on SQL statements (such as `SELECT yysr FROM tccit_dg_a100000_1 WHERE ...`), accurately extracting the source table (`tccit_dg_a100000_1`), source field (`yysr`), and query conditions (such as `org = 1000`). This technical information is then transformed into semantics understandable to business users, such as "organization is Huanyu International" and "period from 2025-01-01 to 2025-03-31", thus bridging the gap between the database and business reports.

[0121] at last, Figure 10This illustrates the internal processing logic of the core parsing engine in an embodiment of the present invention, such as... Figure 8 As shown, the parsing parameters are first initialized and a cell mapping object is constructed. Then, the calculation formula is recursively parsed, and an abstract syntax tree is generated using a parser. Through a series of steps such as matching terms and assembling objects, a structured result object set containing type, calculation formula, adjustment value, cell information, formula information, and numerical value is finally generated, providing a precise data foundation for front-end display and the construction of the lineage graph. As can be seen from the above description, this embodiment of the invention implements a complete data traceability solution from user interaction and back-end calculation to multi-layered visualization display through an interconnected, front-end and back-end collaborative process.

[0122] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0123] Based on the same inventive concept, this application also provides a report data tracing device for implementing the report data tracing method described above. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations in the report data tracing device embodiments provided below can be found in the limitations of the report data tracing method described above, and will not be repeated here.

[0124] In one exemplary embodiment, such as Figure 11 As shown, a report data tracing device is provided, including: a response module, used to respond to a data tracing request for a target cell in the currently displayed target report;

[0125] The acquisition module is used to acquire the target data lineage graph corresponding to the target report; the nodes in the data lineage graph represent data entities, and the edges between the nodes represent data flow relationships; the data entities include at least one of cells, data query statements, and database table fields.

[0126] The search module is used to traverse the upstream nodes referenced by the target node corresponding to the target cell in the target data lineage graph in reverse order of the edge direction, starting from the target cell, until the node corresponding to the database table field is found, so as to obtain the target data flow path corresponding to the target cell.

[0127] The display module is used to display the target data flow path.

[0128] Each module in the aforementioned report data traceability device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0129] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 12 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a report data traceability method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0130] Those skilled in the art will understand that Figure 12The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0131] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in any of the foregoing embodiments of the report data tracing method.

[0132] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps in any of the aforementioned report data tracing method embodiments.

[0133] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in any of the foregoing report data tracing method embodiments.

[0134] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0135] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, distributed databases based on blockchain. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, data processing logic devices based on quantum computing, artificial intelligence (AI) processors, etc., and are not limited to these.

[0136] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0137] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for tracing the source of report data, characterized in that, The method includes: Responding to a data tracing request for a target cell in the currently displayed target report; Obtain the target data lineage graph corresponding to the target report; the nodes in the data lineage graph represent data entities, and the edges between the nodes represent data flow relationships; the data entity includes at least one of a cell, a data query statement, and a database table field; Starting from the target cell, in the target data lineage graph, the upstream nodes referenced by the target node corresponding to the target cell are traversed in reverse order of the edge direction until the node corresponding to the database table field is found, thus obtaining the target data flow path corresponding to the target cell; The target data flow path is displayed.

2. The method according to claim 1, characterized in that, The edges between the nodes include dependency edges representing computational dependencies and data edges representing data source dependencies; The step of obtaining the target data lineage map corresponding to the target report includes: Obtain the generation process record of the target report and the report definition file; The generation process record is parsed to obtain the data query statements executed during the rendering of the target report and the source data information accessed by the query statements; The report definition file is parsed to obtain the data processing logic corresponding to each candidate cell in the target report; the data processing logic includes calculating the values ​​of other cells based on the calculation dependency relationship or binding the query results to the query statement based on the data source relationship; The target data lineage map is constructed based on the query statement, source data information, and data processing logic.

3. The method according to claim 2, characterized in that, The step of constructing the target data lineage map based on the query statement, source data information, and the data processing logic includes: For the candidate cell configured with the computational dependency, perform syntax parsing on the computational dependency corresponding to the candidate cell to obtain the abstract syntax tree corresponding to the computational dependency; Analyze the abstract syntax tree to obtain the identifier of at least one source cell of the input parameters that constitute the computational dependency; In the data lineage graph, a dependency edge is created from the node corresponding to the identifier of the source cell to the node corresponding to the current candidate cell.

4. The method according to claim 2, characterized in that, The step of constructing the data lineage map corresponding to the target report based on the query statement, source data information, and the data processing logic includes: For the candidate cell configured with the data source relationship, the target data field bound to the current candidate cell is determined according to the data source relationship; In the data lineage graph, a data edge is created between the target data query statement node and the node corresponding to the current candidate cell; the target data query statement node is the node corresponding to the data query statement that returns the target data field after execution.

5. The method according to claim 2, characterized in that, The target data flow path is then displayed: The data flow path is visualized as a hierarchical relationship diagram; wherein, the hierarchical relationship diagram presents the path from the source data table field node to the target cell node, through the query statement node and the intermediate cell node; the hierarchical relationship diagram distinguishes and displays the dependency edge and the data edge; In response to a location command for any cell node in the hierarchical relationship diagram, the actual cell corresponding to the cell node is highlighted in the interface of the target report.

6. The method according to claim 5, characterized in that, The display of the data flow path includes: In response to the user's selection of a target node on the hierarchical relationship graph, the node parameters of the target node are displayed; wherein, if the selected node is a cell node, the node parameters include the calculation dependency relationship or the data source relationship corresponding to the cell; if the selected node is a data query statement node, the node parameters include the query statement and the execution conditions of the query statement.

7. A report data traceability device, characterized in that, The device includes: The response module is used to respond to data tracing requests for target cells in the currently displayed target report; The acquisition module is used to acquire the target data lineage graph corresponding to the target report; the nodes in the data lineage graph represent data entities, and the edges between the nodes represent data flow relationships; the data entities include at least one of cells, data query statements, and database table fields. The search module is used to traverse the upstream nodes referenced by the target node corresponding to the target cell in the target data lineage graph in reverse order of the edge direction, starting from the target cell, until the node corresponding to the database table field is found, so as to obtain the target data flow path corresponding to the target cell. The display module is used to display the target data flow path.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.