Financial insurance field-oriented cloud report automatic generation method and system

Abstract

The invention provides a cloud report automatic generation method and system oriented to the financial insurance field, and relates to the technical field of financial insurance data process.The method comprises the steps that abstract processing is conducted on original business data, and a data desensitization structure is established; based on a data desensitization structure, dividing a database table into a basic table, a parameter table, a dictionary table, an intermediate table and a result table; setting uniform prefix identifiers for fields in the basic table and the parameter table, and establishing a mapping relationship between the desensitization fields and actual service meanings through the dictionary table; receiving business requirements submitted by business personnel based on the data desensitization structure; the business requirements comprise data screening conditions, index fields needing to be displayed and computational logic expressions of all indexes; and analyzing the service demand, and extracting core information in the service demand to obtain a security prompt word only containing the desensitization field and the logic instruction. According to the method, the report generation efficiency and accuracy are improved while the security of the sensitive data is guaranteed.

Description

Technical Field

[0001] This invention relates to the field of financial and insurance data processing technology, and in particular to a cloud-based automated report generation method and system for the financial and insurance sector. Background Technology

[0002] In the financial and insurance sector, financial statements serve as the core vehicle for regulatory reporting, risk management, and business decision-making, and their quality directly impacts an institution's compliance and decision-making efficiency.

[0003] Currently, cloud report generation mainly relies on the traditional model of business requirements + IT development. However, this model has significant bottlenecks: First, data anonymization is disconnected from business needs. Existing static anonymization technologies often render the data unusable immediately after anonymization. For example, after simply masking sensitive fields in an insurance policy, business personnel cannot accurately associate the requirements with the anonymized data. Dynamic anonymization, on the other hand, lacks a unified field mapping mechanism, and cross-department reports often experience data conflicts due to differences in anonymization rules. Second, requirement parsing is inefficient. Business personnel often submit requirements through unstructured documents, requiring IT personnel to manually identify filtering conditions, indicator fields, and calculation logic. In cross-system data retrieval scenarios, field consistency verification alone consumes more than half of the time and is prone to errors. Third, the generation of SQL is highly dependent on manual processes. Insurance actuarial reports often contain complex formulas with multiple nested factors (such as loss ratios which need to integrate parameters such as mortality rate and surrender rate). The logical error rate of manually written scripts is high, and the lack of automated syntax validation mechanisms leads to the report generation cycle generally exceeding the expected time, making it difficult to meet the timeliness requirements of regulatory reporting. Fourth, the restoration of anonymized data lacks systematic support. For example, existing methods mostly rely on manual reverse replacement, which is prone to restoration deviations when dealing with high-dimensional business data. This affects the readability of reports and poses a risk of sensitive data leakage.

[0004] In industry practice, although some organizations have tried to optimize processes through data platforms, they still face core contradictions such as a lack of systematic design for de-identification structures, an unstructured mechanism for demand parsing, reliance on manual intervention for SQL generation, and a failure to balance de-identification and readability. Summary of the Invention

[0005] The technical problem to be solved by this invention is to provide a cloud-based automated report generation method and system for the financial and insurance field, which can realize full-process automation from the submission of business requirements to the final presentation of reports, while ensuring the security of sensitive data and improving the efficiency and accuracy of report generation.

[0006] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows: Firstly, a method for automatically generating cloud-based reports for the financial and insurance sector, the method comprising: The original business data is abstracted and processed to establish a data anonymization structure. Based on the data anonymization structure, the database tables are divided into basic tables, parameter tables, dictionary tables, intermediate tables, and result tables. A unified prefix identifier is set for the fields in the basic tables and parameter tables, and a mapping relationship between the anonymized fields and their actual business meanings is established through the dictionary table. Based on the data anonymization structure, we receive business requirements submitted by business personnel; business requirements include data filtering conditions, indicator fields to be displayed, and the calculation logic of each indicator. The business requirements are analyzed, and the core information in the business requirements is extracted to obtain security prompt words that contain only de-identified fields and logical instructions; Semantic association analysis is performed on security prompt words to identify the business data types and operation rules corresponding to logical instructions for each de-identified field, and semantic analysis values ​​are obtained. The discrete business requirement elements in the security prompt words are established according to the preset spatial association rules to establish a correspondence. The element matching value is obtained by effectively matching the business requirement elements with the SQL syntax elements. Based on the semantic analysis value and the element matching value, the SQL statement fragment is obtained. The SQL statement fragment is then subjected to syntax verification and business logic integration to obtain an executable SQL script. By executing an executable SQL script, the data in the base table and parameter table are called and calculated to obtain a structured result table; the structured result table is then transformed and visualized to obtain the final generated and presented report.

[0007] Furthermore, the original business data is abstracted and a data anonymization structure is established. Based on this structure, the database tables are divided into base tables, parameter tables, dictionary tables, intermediate tables, and result tables. A unified prefix identifier is set for all fields in the base and parameter tables. A mapping relationship between the anonymized fields and their actual business meanings is established through the dictionary table, including: Feature extraction is performed on the original business data, and high-dimensional business data is mapped to a low-dimensional space through geometric projection to achieve dimensionality reduction processing of data abstraction; based on the dimensionality reduction processing of data abstraction, the main component features are obtained; The main component features are mapped to the de-identified fields. By maintaining the geometric relationship between the fields, a set of fields named with the "col" prefix is ​​obtained. The base table is defined based on the set of fields. Define the table that stores data processing rules and configuration parameters as a parameter table, where each field in the parameter table is named with the prefix "para"; Define the table that stores the mapping relationship between the masked fields and their actual business meanings as a dictionary table; Define the table that stores temporary data generated during SQL processing as an intermediate table; Define the table that stores the final report data as the result table; Based on the mapping relationship established by the dictionary table, the anonymized fields are restored to their actual business meaning during the report generation stage. Based on the restored actual business meaning, the readability and data security of the report are obtained by adopting the inverse process of geometric projection.

[0008] Furthermore, based on the data anonymization structure, it receives business requirements submitted by business personnel; these requirements include data filtering conditions, the indicator fields to be displayed, and the calculation logic for each indicator, including: Based on the field naming conventions provided by the data anonymization structure, we receive business requirements submitted by business personnel through structured spreadsheets. Spatial indexes are constructed for business requirements. By using R-tree index calculation, discrete business requirement elements are organized into spatial objects with a hierarchical structure. Based on the hierarchical structure of spatial objects, identify the spatial relationships between data filtering conditions, display indicator fields, and calculation logic expressions in business requirements; By verifying the spatial relationships, the consistency between the field names referenced in the business requirements and the de-identified fields defined in the data de-identification structure is verified, so as to ensure that all business logic is expressed based on the de-identified fields.

[0009] Furthermore, the business requirements are analyzed, and by extracting the core information from the business requirements, security prompt words containing only de-identified fields and logical instructions are obtained, including: In a local secure environment, the received business requirements are structured and parsed to identify the computational logic expressions and field reference relationships. Based on field reference relationships, by mapping the actual business fields referenced in business requirements to the corresponding de-identified fields, the association between de-identified fields and calculation logic can be established, that is, the de-identified field association relationship; By standardizing the computational logic expression, an instruction sequence consisting of de-identified fields and logical operators is obtained; Based on the relationship between the instruction sequence and the de-identified fields, a security prompt word containing only the de-identified identifier and logical operations is obtained to ensure that it does not contain any sensitive business information.

[0010] Furthermore, semantic association analysis is performed on the security prompt words to identify the business data types corresponding to each de-identified field and the operation rules corresponding to the logical instructions, obtaining semantic analysis values, including: Semantic features are extracted from the de-identified fields and logical instructions in the security prompts, and the semantic feature representation relationship between the fields and instructions is established. Based on semantic feature representation, the semantic correlation between each de-identified field is analyzed to identify a set of fields with similar business meanings; Semantically group the field set, determine the business data type corresponding to each field based on the degree of semantic relevance, and obtain the semantic grouping results; Based on the semantic grouping results, the operational characteristics of logical instructions are analyzed to identify the operation rule type corresponding to each instruction; By combining the data types of business data and the types of operation rules, semantic analysis values ​​representing the semantic features of prompt words are obtained.

[0011] Furthermore, the discrete business requirement elements in the security prompt words are established with corresponding relationships according to preset spatial association rules. Element matching values ​​are obtained through effective matching of business requirement elements and SQL syntax elements. Based on semantic analysis values ​​and element matching values, SQL statement fragments are obtained. Syntax validation and business logic integration are performed on the SQL statement fragments to obtain an executable SQL script, including: Based on semantic analysis values, the business requirement elements in the security prompt words are arranged according to the data processing logic order, and the execution dependencies between the elements are established. Based on execution dependencies, the sorted business requirement elements are matched with SQL syntax elements to establish conversion rules from business logic to SQL statements; Based on the transformation rules, each business requirement element is converted into a corresponding SQL statement fragment, and the logical connection relationship between each fragment is recorded; Perform syntax correctness verification on the SQL statement fragments to ensure that each fragment conforms to the SQL syntax specification, and obtain the SQL statement fragments that pass the verification; Based on the logical connections, the validated SQL statement fragments are combined in the order of execution to obtain a complete executable SQL script.

[0012] Furthermore, by executing executable SQL scripts, data from the base table and parameter table is called and processed to obtain a structured result table. This structured result table is then transformed and visualized to obtain the final generated and presented report, including: Execute the executable SQL script in the local database environment, call the data in the base table and parameter table, and process the data according to the calculation logic defined in the script; Based on the execution of the aforementioned operational logic, a structured result table containing the final data result is obtained by writing the processed data into the result table. The de-identified fields in the structured result table are restored. Based on the mapping relationship stored in the dictionary table, the de-identified fields are converted into actual business field names, resulting in a restored data table with business readability. The restored data table is input into the report generation engine, which then fills in the data and renders the format according to the preset report template to obtain the final visual report.

[0013] Secondly, a cloud-based automated report generation system for the financial and insurance sector includes: The configuration module is used to abstract and process the original business data and establish a data anonymization structure. Based on the data anonymization structure, the database tables are divided into basic tables, parameter tables, dictionary tables, intermediate tables, and result tables. A unified prefix identifier is set for the fields in the basic tables and parameter tables, and a mapping relationship between the anonymized fields and their actual business meanings is established through the dictionary table. The receiving module is used to receive business requirements submitted by business personnel based on the data anonymization structure. The business requirements include data filtering conditions, indicator fields to be displayed, and the calculation logic of each indicator. The parsing module is used to parse business requirements. By extracting the core information from the business requirements, it obtains security prompt words that contain only de-identified fields and logical instructions. Semantic association analysis is performed on the security prompt words to identify the business data type corresponding to each de-identified field and the operation rules corresponding to the logical instructions, and obtain semantic analysis values. The processing module is used to establish a correspondence between discrete business requirement elements in the security prompt words according to preset spatial association rules, obtain element matching values ​​through effective matching of business requirement elements and SQL syntax elements, obtain SQL statement fragments based on semantic analysis values ​​and element matching values, and perform syntax verification and business logic integration on the SQL statement fragments to obtain an executable SQL script. The summary module is used to call and perform calculations on the data in the base table and parameter table by executing executable SQL scripts to obtain a structured result table; the structured result table is then transformed and visualized to obtain the final report generation and presentation.

[0014] The above-described solution of the present invention has at least the following beneficial effects: This approach categorizes database tables into basic tables, parameter tables, and dictionary tables. It also sets unified prefixes for fields in basic and parameter tables and establishes a mapping between anonymized fields and their actual business meanings through the dictionary table. This overcomes the problem of existing data anonymization methods being disconnected from business needs, avoids the situation where anonymized data becomes unusable, and resolves data conflicts in cross-departmental reports due to differences in anonymization rules, thus achieving end-to-end security protection for sensitive data processing. Furthermore, it employs a method of receiving business personnel's submitted requirements based on a data anonymization structure. It organizes discrete requirement elements into hierarchical spatial objects using an R-tree index and verifies field consistency. This overcomes the low parsing efficiency caused by unstructured business requirements and avoids requirement distortion due to ambiguous terminology. This improves the efficiency of business requirement parsing and reduces information bias during requirement transmission. By parsing business requirements in a local secure environment, security prompts containing only anonymized fields and logical instructions are generated. Semantic association analysis is performed on these prompts to identify the data types of the anonymized fields and the operational rules of the logical instructions. Then, SQL syntax elements are matched according to preset spatial association rules, generating SQL statement fragments. These fragments are then subjected to syntax validation and business logic integration to obtain an executable SQL script. This overcomes the problem of SQL generation being highly dependent on manual intervention, reduces the high error rate of logic, and solves the problem of time-consuming syntax validation. Consequently, it significantly reduces manual intervention, lowers the error rate of SQL scripts, and shortens the script generation cycle. The method of executing SQL scripts to obtain structured result tables is used. Based on the mapping relationship of dictionary tables, anonymized fields are restored to actual business fields. Then, a reporting engine performs data filling and format rendering. This overcomes the problem of errors easily arising from manual restoration of anonymized data, solves the problem of poor report readability, and improves the problem of failing to meet regulatory timeliness requirements. This ensures the business readability and data security of the final visual report, significantly shortens the report generation cycle, and meets the timeliness requirements of regulatory reporting and business decision-making. Attached Figure Description

[0015] Figure 1 This is a flowchart illustrating a cloud-based automated report generation method for the financial and insurance sector, provided by an embodiment of the present invention.

[0016] Figure 2 This is a schematic diagram of a cloud-based automated report generation system for the financial and insurance sector, provided by an embodiment of the present invention. Detailed Implementation

[0017] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0018] like Figure 1 As shown, an embodiment of the present invention proposes a method for automatically generating cloud reports in the financial and insurance field, the method comprising the following steps: Step 1: Abstract the original business data and establish a data anonymization structure; based on the data anonymization structure, divide the database tables into basic tables, parameter tables, dictionary tables, intermediate tables, and result tables; set a unified prefix identifier for the fields in the basic tables and parameter tables, and establish a mapping relationship between the anonymized fields and their actual business meanings through the dictionary table; Step 2: Based on the data anonymization structure, receive business requirements submitted by business personnel; business requirements include data filtering conditions, indicator fields to be displayed, and the calculation logic expression of each indicator; Step 3: Analyze the business requirements and extract the core information from them to obtain security prompt words that contain only de-identified fields and logical instructions; Step 4: Perform semantic association analysis on the security prompt words to identify the business data type and the operation rules corresponding to the logical instructions of each de-identified field, and obtain the semantic analysis value; Step 5: Establish correspondences between discrete business requirement elements in the security prompt words according to preset spatial association rules; obtain element matching values ​​by effectively matching business requirement elements with SQL syntax elements; obtain SQL statement fragments based on semantic analysis values ​​and element matching values; perform syntax verification and business logic integration on the SQL statement fragments to obtain an executable SQL script. Step 6: By executing the executable SQL script, the data in the base table and parameter table are called and calculated to obtain a structured result table; the structured result table is then transformed and visualized to obtain the final generated and presented report.

[0019] In this embodiment of the invention, a data anonymization structure is built for the original business data. Database tables are categorized, field prefixes are set, and a dictionary table maps the anonymized fields to their business meanings. This avoids a disconnect between data anonymization and business requirements, reduces cross-departmental report data conflicts, and ensures the security of sensitive data. Business requirements are received based on the anonymized structure, clearly defining the filtering conditions, indicator fields, and calculation logic included in the requirements. This makes requirement submission more standardized, reduces parsing deviations caused by ambiguous requirements, and improves requirement parsing efficiency. The core information of the business requirements is extracted, generating security prompts containing only anonymized fields and logical instructions. This prevents the leakage of sensitive business information and further strengthens data security protection. Semantic association analysis is performed on the security prompts to identify the data types of the anonymized fields and the operation rules of the logical instructions. This accurately grasps the semantics of the prompts, providing a precise basis for SQL statement conversion. Business requirement elements and SQL syntax elements are matched according to rules to generate and validate integrated SQL scripts. This reduces reliance on manually written SQL, lowers the script logic error rate, and shortens SQL script generation time. The SQL script is executed to obtain the result table, which is then converted and rendered into a report. This quickly restores the business meaning of the anonymized fields, ensures report readability, and accelerates report generation.

[0020] In a preferred embodiment of the present invention, step 1 above may include: Step 1.1 involves feature extraction from the raw business data. High-dimensional business data is mapped to a low-dimensional space via geometric projection to achieve dimensionality reduction through data abstraction. Based on this dimensionality reduction, key component features are obtained, specifically including: a comprehensive review of raw business data in the financial and insurance sector, encompassing various types such as policy signing data, claims processing data, and premium payment data; then, for each type of raw business data, features reflecting core business attributes are extracted, such as policyholder gender, insured vehicle type, insurance period, and premium amount from policy signing data. If multiple data samples are compiled, each containing several of the aforementioned core features, based on characteristics such as premium amount and underwriting institution, a high-dimensional data matrix is ​​formed, structured as sample number × feature dimension. By locating the projection direction that minimizes information loss, the high-dimensional data is transformed into low-dimensional data. The first step is to standardize the high-dimensional data matrix, eliminating dimensional differences between features, such as measuring premium amount in monetary units and insurance period in time units. The second step is to calculate the covariance matrix of the standardized data matrix, which quantifies the degree of linear correlation between any two features, such as the relationship between insurance period and premium amount. If a strong linear correlation exists, the corresponding value in the covariance matrix will be significantly higher, thus identifying information redundancy in the data. The third step is to solve for the eigenvalues ​​and eigenvectors of the covariance matrix. The magnitude of the eigenvalue represents the data information density along the direction of the corresponding eigenvector, and the eigenvector corresponds to the specific projection direction. The top N eigenvectors whose total eigenvalue ratio meets a preset threshold (this threshold is set based on retaining key information from financial and insurance business) are selected first to ensure that the projected data still carries core business value. The fourth step is to combine the selected N eigenvectors into a projection matrix. The fifth step is to... The standardized high-dimensional data matrix is ​​subjected to matrix operations with the projection matrix to obtain a low-dimensional data matrix with the sample size × N, thus completing the high-dimensional to low-dimensional mapping. Throughout the projection process, the core principle is to avoid losing key information related to financial insurance business decisions. The information retention rate is strictly controlled by the feature value ratio threshold to avoid the loss of key business features due to dimensionality reduction, such as the insured vehicle type affecting risk assessment and the insurance period related to premium calculation. Through this processing, the dimensionality reduction of data abstraction is completed, and finally, the low-dimensional feature corresponding to each column in the low-dimensional data matrix is ​​defined as the principal component feature.

[0021] Step 1.2 maps the principal component features to de-identified fields. By maintaining the geometric relationship between fields, a set of fields named with the prefix "col" is obtained. A base table is defined based on this field set. Specifically, this includes: analyzing the specific attributes of the financial insurance business corresponding to each principal component feature; for example, one principal component feature corresponds to the premium payment amount, and another principal component feature corresponds to the claims processing time. Then, a unique de-identified field identifier is assigned to each principal component feature, and all de-identified fields use "col" as a unified prefix; for example, the principal component feature corresponding to the premium payment amount is named "col-001", and the principal component feature corresponding to the claims processing time is named "col-002". During the naming process, the geometric relationship between each de-identified field is strictly maintained. This relationship is reflected in the field arrangement order and coding rules, ensuring that the business logic relationship between different de-identified fields is consistent with the relationship between the original principal component features. Finally, all de-identified fields named with the prefix "col" are integrated to form a field set, and a base table is defined based on this field set.

[0022] Step 1.3 defines the table storing data processing rules and configuration parameters as a parameter table. Each field in the parameter table is named with the prefix "para". Specifically, this includes: first, identifying the data processing rules and configuration parameters needed for report generation in the financial and insurance field; data processing rules include claims ratio calculation rules, premium growth rate statistics rules, etc., and configuration parameters include the time range threshold for report generation, the accuracy requirements for indicator calculation, etc.; then, designing the field structure of the parameter table based on the types of these data processing rules and configuration parameters; each field corresponds specifically to a data processing rule or a configuration parameter, and to clearly distinguish them from the "col" prefix fields in the base table, all fields in the parameter table use "para" as a unified prefix; for example, naming the field corresponding to the claims ratio calculation threshold "para-001" and the field corresponding to the report generation period "para-002"; finally, filling the identified data processing rules and configuration parameters into the corresponding fields to complete the definition of the parameter table.

[0023] Step 1.4 defines the table storing the mapping relationship between masked fields and their actual business meanings as a dictionary table. This includes: first, clarifying the core content the dictionary table needs to store, namely, the correspondence between each defined "col" prefix masked field and its actual financial insurance business meaning; specifically, recording the corresponding actual business name for each "col" prefix masked field, such as "col-001" corresponding to premium payment amount and "col-002" corresponding to claims processing time; also recording the data type of the field, such as numeric or character type, and the business segment to which the field belongs, such as premium management segment or claims management segment; then designing the dictionary table structure to ensure complete storage of this information, and setting up indexes for easy querying to quickly retrieve the actual business meaning corresponding to the masked fields; finally, entering the relevant information for each "col" prefix masked field into the dictionary table one by one, completing the dictionary table's creation.

[0024] Step 1.5 defines the table storing temporary data generated during SQL processing as an intermediate table. This includes analyzing the temporary data types that may be generated during SQL execution in the report generation process. These temporary data types include intermediate data obtained after preliminary filtering of base table data, temporary indicator data obtained after preliminary calculation based on parameter table rules, and transitional data generated during join queries between different data tables. Then, the table structure of the intermediate table is designed to ensure it can adapt to the storage requirements of these different types of temporary data. Furthermore, the field naming of the intermediate table will refer to the `col` prefix of the base table and the `para` prefix of the parameter table to avoid confusion with fields in other tables. During SQL execution, whenever temporary data is generated, it is immediately written into the intermediate table for storage.

[0025] Step 1.6 defines the table storing the final report data as the result table. This includes: First, determining the content of the final report data. This content is based on temporary data from intermediate tables, combined with core business data from the base table and configuration rules from the parameter table, obtained after complete calculation and integration. For example, a monthly auto insurance business report needs to include final indicator data such as the number of policies in each region and the loss ratio for each type of insurance. Then, designing the result table structure, ensuring that the fields in the result table correspond to the desensitized fields with the "col" prefix in the base table, guarantees that the final report data can be traced back to the original desensitized business data. Simultaneously, standardizing the field arrangement and data format according to the report's display requirements. Finally, filling the calculated and integrated final report data into the corresponding fields one by one according to the result table structure completes the generation of the result table.

[0026] Step 1.7: Based on the mapping relationship established by the dictionary table, the masked fields are restored to their actual business meaning during the report generation stage. Based on the restored actual business meaning, the readability and data security of the report are improved by adopting the inverse process of geometric projection. Specifically, this includes: First, during the report generation stage, extracting all masked fields with the prefix "col" from the result table. These masked fields are the core content that needs to be restored. Then, according to the dictionary table, query the actual business meaning corresponding to each masked field with the prefix "col" and replace the masked field name with the corresponding actual business name; for example, replacing "col-001" with the premium payment amount, and replacing "col-001" with the actual business name. l-002 is replaced with the claims processing time to make the report data more business-readable. At the same time, to ensure the logical consistency between the restored data and the original high-dimensional business data, the reverse process of geometric projection is initiated to map the anonymized data in the low-dimensional space back to the original high-dimensional business data dimension. In this process, the business relationships between the data are strictly preserved to avoid data restoration deviations. Through this processing, it is possible to ensure that the report data conforms to the business reading habits of the financial and insurance field, and to ensure that sensitive information is not leaked during the entire data processing process, ultimately achieving a dual guarantee of report readability and data security.

[0027] In this embodiment of the invention, high-dimensional original business data is reduced in dimensionality through geometric projection to extract key component features, simplifying the data while retaining crucial information. Key component features are mapped to desensitized fields with the prefix "col," maintaining geometric correlation between fields. The defined basic table fields are standardized and remain associative after desensitization. The table storing data processing rules and configuration parameters is set as a parameter table with the prefix "para," facilitating rapid identification and retrieval. A dictionary table stores the mapping between desensitized fields and their actual business meanings, preparing for subsequent field restoration. An intermediate table stores temporary data during SQL processing, avoiding interference with the original data and final results. A result table specifically stores the final report data, clearly defining data storage ownership. Finally, desensitized fields are restored based on the dictionary table mapping relationship and the reverse process of geometric projection, ensuring both report readability and data security. Overall, the data desensitization structure is more systematic, and the functions of each table are clear, laying a solid foundation for subsequent automated cloud report generation.

[0028] In a preferred embodiment of the present invention, step 2 above may include: Step 2.1: Based on the field naming conventions provided by the data anonymization structure, receive business requirements submitted by business personnel through a structured spreadsheet. Specifically, this includes: first, clarifying the field naming conventions provided by the data anonymization structure. These conventions are consistent with the defined table structure, i.e., basic table fields use "col" as a unified prefix, parameter table fields use "para" as a unified prefix, and each prefix field has a corresponding business meaning record in the dictionary table; next, providing business personnel with a pre-formatted structured spreadsheet, which will be divided into fixed columns, including the requirement name, data filtering condition column, indicator field column to be displayed, and calculation logic expression column for each indicator. The indicator field column will indicate that anonymized fields conforming to the "col" / "para" prefix must be filled in; business personnel fill in their requirements according to the table columns, for example, filling in "col-008" in the indicator field column and the monthly average of "col-008" in the calculation logic column; finally, receiving the completed structured spreadsheet.

[0029] Step 2.2 involves constructing a spatial index for business requirements. This is done using an R-tree index to organize discrete business requirement elements into hierarchical spatial objects. Specifically, this includes: first, extracting discrete business requirement elements from a structured spreadsheet. These elements include each data filtering condition, each indicator field, and each piece of calculation logic. For example, extracting independent elements such as filtering Q3 2024 insurance data, col-008, and the monthly average of col-008; then, starting the R-tree index calculation, treating each requirement element as a spatial data object in an R-tree, and assigning a spatial index to each object. The corresponding spatial coordinates are set according to the element type. For example, the coordinate prefix for filter condition elements is 1, for indicator field elements it is 2, and for calculation logic elements it is 3. Subsequent values ​​increase sequentially according to the order in which the elements are filled in the table. Then, according to the hierarchical construction rules of the R tree, elements with similar coordinates are grouped into the same child node. For example, the three highly related elements of filtering Q3 2024 insurance data, col-008, and the monthly average of col-008 are grouped into the same child node. Then, multiple child nodes are integrated into a parent node, finally forming a spatial object with a hierarchical structure of root node, parent node, and child nodes.

[0030] Step 2.3, based on the hierarchical structure of spatial objects, identifies the spatial relationships between data filtering conditions, display indicator fields, and calculation logic expressions in business requirements. Specifically, this includes: first, traversing the hierarchical structure of the R-tree, analyzing the types of requirement elements contained in each spatial object layer by layer from the root node to the child nodes; for elements under the same child node, focusing on analyzing their logical relationships. For example, a child node may contain filtering data for Q3 2024 insurance policies (filtering condition), col-008 (indicator field), and the monthly average of col-008 (calculation logic). The spatial coordinate relationships of the child nodes (same prefix) are analyzed. (And subsequent values ​​are continuous), it was identified that the screening of insurance data in Q3 2024 was based on the screening condition of the col-008 indicator field, and the monthly average value of col-008 is the calculation logic corresponding to this indicator field; for elements with different child nodes but the same parent node, their indirect relationship was analyzed. For example, two child nodes respectively contain screening of passenger car insurance policies + col-015 (corresponding to the anonymized claim amount field) and screening of commercial truck insurance policies + col-015. Through the unified affiliation of the parent node, it was identified that the screening conditions of these two child nodes are both based on different dimensions of the col-015 indicator field.

[0031] Step 2.4 verifies the consistency between the field names referenced in the business requirements and the desensitized fields defined in the data anonymization structure through spatial relationships, ensuring that all business logic is expressed based on the desensitized fields. Specifically, this includes: extracting all field names referenced in the business requirements based on the identified relationships, such as extracting col-008 and col-015 from the monthly average of col-008 and the loss ratio calculated based on col-015; then calling the constructed data anonymization structure information, including the list of all desensitized fields in the base table and parameter table, as well as the field correspondences recorded in the dictionary table; then comparing the extracted field names with the desensitized field list one by one to check for any fields not in the list; if a business user mistakenly enters bf-008 (a field without the col / para prefix), immediately indicating that the field is not standardized; if the entered col-008 is in the list and matches the mapping of the premium amount in the dictionary table, then the field is considered consistent; finally, a field consistency verification report is obtained. If all referenced fields meet the requirements, it is confirmed that all business logic in the business requirements is expressed based on the desensitized fields; if there are inconsistent fields, the report is returned to the business user for correction.

[0032] In this embodiment of the invention, the field naming convention based on the data anonymization structure, along with the receipt of business requirements through structured spreadsheets, makes the submission of business requirements more standardized and avoids the confusion caused by unstructured documents. The use of R-tree indexing to construct a spatial index for business requirements organizes discrete requirement elements into hierarchical spatial objects, clearly outlining the logical hierarchy of requirement elements and breaking down the scattered state of elements. Based on the hierarchical structure of the spatial objects, the spatial relationships between data filtering conditions, display indicator fields, and calculation logic are identified, clarifying the logical connections between various elements within the requirement and reducing misunderstandings caused by ambiguous terminology. Furthermore, the consistency between the fields referenced in the business requirements and the anonymized fields is verified through spatial relationships, ensuring that all business logic is expressed based on the anonymized fields. This avoids the risk of sensitive data exposure and provides a standardized foundation for subsequent business requirement parsing and security warning word generation.

[0033] In a preferred embodiment of the present invention, step 3 above may include: Step 3.1 involves performing structured parsing of the received business requirements in a local secure environment to identify the calculation logic expressions and field reference relationships. Specifically, this includes: first, importing the verified business requirements into the local secure environment, which is isolated from the external network to prevent data leakage during parsing; then, scanning each line of the business requirements to extract the calculation logic expressions from the calculation logic expression columns of the structured spreadsheet, such as the ratio of the monthly average of col-008 to the sum of col-015; simultaneously identifying field reference relationships from the indicator field columns and calculation logic expressions to determine which anonymized fields are referenced and their positions in the logic, for example, identifying that both col-008 and col-015 are referenced, with col-008 used to calculate the average and col-015 used to calculate the sum.

[0034] Step 3.2, based on field reference relationships, establishes the association between the masked fields and the calculation logic by mapping the actual business fields referenced in the business requirements to their corresponding masked fields. This involves: first, organizing the identified field reference relationships and listing all referenced fields, including a small number of actual business fields that may be mistakenly filled in by business personnel, such as premium amount instead of col-008; then, calling the dictionary table and converting these actual business fields into their corresponding masked fields through the mapping relationship between actual business fields and masked fields stored in the dictionary table, for example, mapping premium amount to col-008; finally, unifying all referenced fields into masked fields and recording the role of each masked field in the calculation logic, such as col-008 corresponding to calculating the monthly average and col-015 corresponding to summation, thereby establishing the association between the masked fields and the calculation logic.

[0035] Step 3.3 involves standardizing the computational logic expression to obtain an instruction sequence consisting of desensitized fields and logical operators. Specifically, this includes: first, transforming the computational logic expression according to preset standardization rules; these rules include unifying the expression of logical operators, such as unifying different expressions like "average" and "average down" into "average calculation"; clarifying the order of operations, such as replacing vague natural language descriptions with "do what first, then do what"; and combining desensitized fields and operators into fixed structures, for example, converting the monthly average of col-008 into the monthly average of col-008, and converting the ratio of the monthly average of col-008 to the sum of col-015 into the ratio of the monthly average of col-008 to the sum of col-015. Through this standardization process, an instruction sequence consisting of desensitized fields and unified logical operators is obtained, with consistent format and clear meaning.

[0036] Step 3.4: Based on the relationship between the instruction sequence and the de-identified fields, obtain security prompt words containing only de-identified identifiers and logical operations to ensure that no sensitive business information is included. Specifically, this includes: first, integrating the relationship between the instruction sequence and the de-identified fields to ensure that the de-identified fields in each instruction correspond to the correct logical function; then, combining this information into prompt words according to the structure of filter conditions + indicator fields + calculation logic; during the combination process, strictly filtering any content that may involve sensitive business information, such as removing the actual business name corresponding to the field and only retaining the de-identified identifier with the prefix "col" or "para"; removing specific descriptions related to business scenarios and only retaining standardized logical operation instructions; for example, generating prompt words such as filter conditions (time range 2024Q3); indicator fields (col-008, col-015); calculation logic (the ratio of the monthly average of col-008 to the sum of col-015); the final security prompt words contain only de-identified identifiers and logical operations.

[0037] In this embodiment of the invention, business requirements are parsed in a local secure environment, and computational logic expressions and field reference relationships are identified. This ensures data security while accurately extracting core elements of the requirements and preventing the leakage of sensitive information. Based on field reference relationships, actual business fields are mapped to de-identified fields, establishing a connection between de-identified fields and computational logic. This solves the problem of de-identification being disconnected from business logic, ensuring that the logic is developed based on the de-identified fields. Standardizing the computational logic expressions to obtain instruction sequences unifies logical expression forms, reduces ambiguity, and provides a standardized basis for subsequent processing. Based on the instruction sequence and the association relationship between de-identified fields, security prompts containing only de-identification identifiers and logical operations are generated. This completely avoids the exposure of sensitive business information, ensuring data security and providing reliable and standardized input for subsequent semantic analysis and SQL generation.

[0038] In a preferred embodiment of the present invention, step 4 above may include: Step 4.1 involves extracting semantic features from the anonymized fields and logical instructions in the security prompt, establishing a semantic feature representation relationship between fields and instructions. Specifically, this includes: first, obtaining the security prompt, which contains only anonymized fields and logical operation instructions; then, extracting semantic features from the anonymized fields and logical instructions in the prompt: for anonymized fields, extracting features such as prefix type and business segment based on field association information recorded in the dictionary table, for example, the features of col-008 are the prefix "col" and the premium management segment; for logical instructions, extracting features such as operation type and operation dimension, for example, the feature of calculating monthly averages is numerical statistics and the time dimension is monthly; then, establishing a semantic feature representation relationship between fields and instructions, i.e., recording the anonymized fields and their features corresponding to each logical instruction, for example, associating the monthly average instruction with col-008, obtaining the feature correspondence between col-008-monthly average-premium management-numerical statistics-monthly.

[0039] Step 4.2, based on semantic feature representation relationships, analyze the semantic correlation between each de-identified field, and identify a set of fields with similar business meanings. Specifically, this includes: calling the feature representation relationships to extract the semantic feature information of all de-identified fields, and compiling a list of fields to be analyzed (e.g., col-008, col-009, col-015); calculating the correlation degree based on the business segment, data usage, and other characteristics of the fields: if two fields belong to the same business segment and have similar data usage, for example, col-008... If col-008 (premium management, premium amount) and col-009 (premium management, premium growth rate) are considered to have high semantic relevance, then col-008 (premium management) and col-015 (claims management, claims amount) are considered to have low semantic relevance. Then, based on the relevance results, the fields with high semantic relevance are grouped into the same set. For example, col-008 and col-009 are grouped into the premium-related field set, and col-015 and col-016 are grouped into the claims-related field set.

[0040] Step 4.3 involves semantically grouping the field sets. Based on the degree of semantic relevance, the business data type corresponding to each field is determined, resulting in semantic grouping results. This includes further analyzing the characteristics of each field set, combining business data type standards in the financial and insurance field (such as amount, time, and quantity) to determine the core characteristics of the set. For example, in the premium-related field set, col-008 (premium amount) and col-009 (premium growth rate) both represent fund-related data in numerical form, with the core characteristics being numerical type and fund attribute. In the time-related field set, col-020 and col-021 both represent the time of business occurrence, with the core characteristics being date type and time attribute. Then, the set division is adjusted according to the degree of semantic relevance. If a field has a slightly lower relevance to other fields in the set but the core characteristics are the same, it is retained in the set. If the relevance is extremely low and the core characteristics are different, it is reclassified. Finally, each set is labeled with the corresponding business data type, for example, the premium-related set is labeled as amount type, and the time-related set is labeled as time type, thus obtaining the semantic grouping results.

[0041] Step 4.4: Based on the semantic grouping results, analyze the operational characteristics of the logical instructions and identify the corresponding operation rule types for each instruction. Specifically, this includes: extracting logical instructions associated with each field set; for example, instructions associated with the monetary set (col-008, col-009) include monthly averaging and summing, and instructions associated with the time set (col-020, col-021) include quarterly grouping and yearly filtering. Then, analyze the operational characteristics of these logical instructions and, in conjunction with the business data types in the semantic grouping results, match the corresponding operation rule types: if the instruction performs numerical statistics on the monetary field, such as monthly averaging and summing, it is identified as a numerical statistics operation rule; if the instruction performs dimensional division on the time field, such as quarterly grouping and yearly filtering, it is identified as a time dimension aggregation operation rule; if the instruction involves the ratio calculation of two different set fields, such as the ratio of the monetary field to the quantity field, it is identified as a cross-type ratio operation rule. Then, record the operation rule type corresponding to each instruction to obtain the correspondence between instruction-rule type-data type.

[0042] Step 4.5: Integrate the business data type and operation rule type to obtain the semantic analysis value representing the semantic features of the prompt word. Specifically, this includes: integrating the business data type and operation rule type corresponding to each logical instruction to form basic semantic units, such as col-008 (amount type) + monthly average (numerical statistics type), col-015 (amount type) + summation (numerical statistics type), and the ratio of col-008 to col-015 (cross-type ratio operation type); then, perform feature encoding on the basic semantic units, converting the business data type and operation rule type into quantifiable feature values, such as value 1 for the amount type, value 2 for the time type, value A for the numerical statistics type, and value B for the time aggregation type; then, integrate the feature values ​​of all basic semantic units in the same security prompt word to obtain a complete feature combination, which is the semantic analysis value representing the semantic features of the prompt word.

[0043] In this embodiment of the invention, semantic features are extracted from the anonymized fields and logical instructions in the security prompt, and a semantic feature representation relationship between the two is established. This clarifies the semantic association between fields and instructions, avoiding misunderstandings caused by semantic ambiguity. Based on this semantic feature representation relationship, the semantic correlation between each anonymized field is analyzed, and a set of fields with similar business meanings is identified, which solves the problem of confused field classification and makes field attribution clearer. The field set is semantically grouped, and the business data type corresponding to each field is determined according to the degree of correlation, which can accurately match data attributes for subsequent processing and reduce data type adaptation errors. Based on the semantic grouping results, the operational features of the logical instructions are analyzed, and the operation rule type corresponding to each instruction is identified, which clarifies the operation logic behind the instruction and avoids confusion of operation rules. Finally, the semantic analysis value representing the semantic features of the prompt is obtained by combining the business data type and the operation rule type, which can provide accurate semantic basis for SQL statement generation, reduce logical deviations in the SQL conversion process, and improve the overall accuracy of semantic analysis and the efficiency of subsequent processing.

[0044] In a preferred embodiment of the present invention, step 5 above may include: Step 5.1: Based on the semantic analysis value, arrange the business requirement elements in the security prompt word according to the data processing logic order, and establish the execution dependency relationship between the elements. Specifically, this includes: obtaining the semantic analysis value, which contains the feature combination of business data type and operation rule type; then, according to the data processing logic reflected in the semantic analysis value, arranging the business requirement elements in the security prompt word in the execution order, for example, processing data filtering conditions first, then processing the extraction of indicator fields, and finally processing the calculation logic; at the same time, analyzing the dependency relationship between elements, if a certain calculation logic needs to be based on the filtered fields, then mark the calculation logic as dependent on the filtering conditions; if the extraction of a certain indicator field needs to refer to the configuration in the parameter table, then mark the field as dependent on the parameter table call; through such arrangement and marking, a clear execution dependency relationship is established.

[0045] Step 5.2: Based on execution dependencies, match the sorted business requirement elements with SQL syntax elements to establish conversion rules from business logic to SQL statements. This includes: first, identifying the types of sorted business requirement elements, including filtering condition elements, field extraction elements, and calculation logic elements; then, corresponding them to core elements in the SQL syntax, such as the WHERE clause for filtering conditions, the SELECT clause for field extraction, the operation expression for calculation logic, and the JOIN clause for parameter table calls; finally, formulating conversion rules based on execution dependencies, for example, filtering condition elements must be converted to WHERE clauses and placed before field extraction, and field extraction involving multi-table joins must be converted to JOIN clauses before performing SELECT operations. These rules ensure that the conversion from business logic to SQL syntax conforms to the execution order. Specifically, the WHERE clause is used to set data filtering conditions, retaining only records that meet the conditions; the SELECT clause is used to specify the fields or data columns to be extracted from the database tables; and the JOIN clause is used to connect multiple database tables.

[0046] Step 5.3: Based on the transformation rules, each business requirement element is converted into a corresponding SQL statement fragment, and the logical connection between each fragment is recorded. Specifically, this includes: processing the arranged business requirement elements one by one, generating corresponding SQL statement fragments according to the transformation rules, such as converting time range filtering conditions into fragments of WHERE (time field), BETWEEN (start time), and AND (end time), converting the average calculation logic into fragments of AVG field names, and converting the requirement to extract multiple indicator fields into fragments of SELECT field1 field2; at the same time, the logical connection between each fragment is recorded. If the filtering condition fragment needs to be combined with the field extraction fragment, it is marked as the WHERE clause following the SELECT clause. If the calculation logic fragment needs to be based on the field extraction result, it is marked as the calculation method nested in the SELECT clause. Through such transformation and recording, complex business requirements are broken down into ordered SQL fragments.

[0047] Step 5.4 verifies the syntax correctness of the SQL statement fragments to ensure that each fragment conforms to the SQL syntax specification, obtaining the verified SQL statement fragments. Specifically, this includes: calling a preset SQL syntax specification library, which contains the syntax format of various clauses, keyword usage rules, function call specifications, etc.; then verifying each SQL statement fragment one by one to check for problems such as misspelled keywords, missing parameters, and incomplete clause structures, such as verifying whether the WHERE clause contains a valid conditional expression; if a fragment is found to have a syntax error, such as AVG being misspelled as AGV, the error location is marked and automatically corrected according to the conversion rules, or a prompt is given that it needs to be converted again. After verification, all fragments that conform to the SQL syntax specification are obtained.

[0048] Step 5.5: Based on the logical connection relationships, combine the verified SQL statement fragments in the execution order to obtain a complete executable SQL script. This includes: first, retrieving the logical connection relationships and execution dependencies to determine the combination order of the fragments. For example, first combine the JOIN clause fragment to associate the base table and the parameter table, then combine the SELECT clause fragment to extract the required fields, then combine the WHERE clause fragment to add filter conditions, and finally combine the aggregate function fragment to complete the calculation logic. Then, according to the standard structure of SQL statements, concatenate each fragment in sequence to ensure that the syntax at the connection points is grammatically correct. For example, correctly add the FROM table name after the SELECT fragment and correctly connect the JOIN result before the WHERE fragment. Finally, a complete executable SQL script is obtained.

[0049] In this embodiment of the invention, by arranging business requirement elements according to data processing logic and establishing execution dependencies based on semantic analysis values, execution deviations caused by disordered element order can be avoided, making requirement processing more organized. Matching business requirement elements with SQL syntax elements and establishing conversion rules based on execution dependencies can solve the problem of disconnect between business logic and SQL syntax, providing a clear basis for the conversion of requirements to SQL. Converting requirement elements into SQL statement fragments based on conversion rules and recording logical connections can break down complex requirements into clear fragments, reducing the difficulty of subsequent processing. Performing syntax correctness verification on SQL fragments can avoid syntax errors in advance and prevent script execution failure. Combining verified fragments according to logical connections to obtain a complete executable SQL script can ensure that the script logic is coherent and can be directly executed, reducing the workload and error rate of manual integration, and improving the overall efficiency and accuracy of SQL script generation.

[0050] In a preferred embodiment of the present invention, step 6 above may include: Step 6.1: Execute the executable SQL script in the local database environment, calling data from the base table and parameter table, and processing the data according to the calculation logic defined in the script. Specifically, this includes: First, importing the executable SQL script into the local database environment, which is physically isolated from the external network and only allows access to the base table and parameter table to prevent data leakage during processing; then, starting the script execution program, calling data from the base table and parameter table according to the instructions in the script, such as extracting the raw data of col-008 (premium amount) and col-015 (claim amount) from the base table, and extracting configuration parameters such as para-003 (loss rate calculation threshold) from the parameter table; then, processing the data according to the calculation logic defined in the script, including filtering the data for Q3 2024 by time range, calculating the monthly average of col-008, calculating the sum of col-015, and then calculating the ratio of the two in conjunction with para-003. The entire processing strictly follows the logical order in the script to ensure the accuracy of the data calculation results.

[0051] Step 6.2: Based on the execution of the aforementioned operational logic, a structured result table containing the final data results is obtained by writing the processed data into the result table. Specifically, this includes: first, determining the storage path and table structure of the result table; the fields of the result table retain the desensitized identifier with the "col" prefix, corresponding to the field structure of the basic table, such as fields like "col-008-avg" (monthly average premium), "col-015-sum" (total claims amount), and "ratio-result" (ratio result); then, writing each processed data item into the result table one by one according to the field correspondence, for example, filling the calculated monthly average premium for Q3 2024 into the "col-008-avg" field, filling the total claims amount for the same period into the "col-015-sum" field, and filling the ratio result of the two into the "ratio-result" field; after writing, performing an integrity check on the result table to ensure that all processing results have been correctly stored, ultimately obtaining a structured result table containing the final data results.

[0052] Step 6.3 involves restoring the anonymized fields in the structured result table. Based on the mapping relationships stored in the dictionary table, the anonymized fields are converted to actual business field names, resulting in a restored data table with business readability. Specifically, this includes: first, extracting all anonymized fields from the structured result table, such as col-008-avg, col-015-sum, and ratio-result. These fields still use "col" as a prefix and cannot directly reflect their business meaning. Next, the dictionary table is called, and the mapping relationships between the anonymized fields and actual business field names stored in the dictionary table are used for querying and conversion. For example, based on the dictionary table records, col-008-avg is converted to the monthly average premium, col-015-sum is converted to the total claim amount, and ratio-result, being a calculated result field, corresponds to the loss ratio in the dictionary table. After the conversion, a new data table is obtained, where all fields are replaced with actual business names, resulting in a restored data table with business readability.

[0053] Step 6.4 involves inputting the restored data table into the report generation engine, filling in the data and rendering the format according to the preset report template to obtain the final visual report. Specifically, this includes: first, importing the restored data table into the preset report generation engine, which stores commonly used report templates in the financial and insurance field, including fixed-format templates required for regulatory reporting (such as monthly premium statistics reports) and dynamic analysis templates for business decision-making (such as loss ratio trend charts); then, selecting the corresponding template based on the business requirement type; next, automatically matching the fields in the restored data table with the data items in the template, and filling in the corresponding data content, for example, filling the monthly average premium into the premium indicator column of the template, and filling the loss ratio into the data source of the trend chart; after filling, rendering according to the format set in the template, including adjusting table borders, setting chart colors, and labeling data units, ultimately obtaining a visual report containing tables, charts, and text descriptions.

[0054] In this embodiment of the invention, executing an executable SQL script in a local database environment, calling data from the base table and parameter table, and processing it according to the script logic avoids interference from the external environment, ensuring the security of the data processing process, while ensuring that the calculation strictly conforms to the business requirement logic. The processed data is written into a result table to obtain a structured result table, allowing the final data to be stored in a standardized format, providing a clear and orderly data foundation for the restoration of anonymized fields. The anonymized fields in the structured result table are restored based on the dictionary table mapping relationship, solving the problem of anonymized data being difficult to understand, making the data table present the actual field names that business personnel can recognize, and improving data readability. The restored data table is input into the report engine, and data is filled and rendered according to the preset template, which can quickly generate visual reports, meeting the timeliness requirements of regulatory reporting and the need for intuitive reports in business decision-making. Overall, the report generation process from data processing to presentation is secure, efficient, and practical.

[0055] like Figure 2 As shown, embodiments of the present invention also provide a cloud-based automated report generation system for the financial and insurance sector, comprising: The configuration module is used to abstract and process the original business data and establish a data anonymization structure. Based on the data anonymization structure, the database tables are divided into basic tables, parameter tables, dictionary tables, intermediate tables, and result tables. A unified prefix identifier is set for the fields in the basic tables and parameter tables, and a mapping relationship between the anonymized fields and their actual business meanings is established through the dictionary table. The receiving module is used to receive business requirements submitted by business personnel based on the data anonymization structure. The business requirements include data filtering conditions, indicator fields to be displayed, and the calculation logic of each indicator. The parsing module is used to parse business requirements. By extracting the core information from the business requirements, it obtains security prompt words that contain only de-identified fields and logical instructions. Semantic association analysis is performed on the security prompt words to identify the business data type corresponding to each de-identified field and the operation rules corresponding to the logical instructions, and obtain semantic analysis values. The processing module is used to establish a correspondence between discrete business requirement elements in the security prompt words according to preset spatial association rules, obtain element matching values ​​through effective matching of business requirement elements and SQL syntax elements, obtain SQL statement fragments based on semantic analysis values ​​and element matching values, and perform syntax verification and business logic integration on the SQL statement fragments to obtain an executable SQL script. The summary module is used to call and perform calculations on the data in the base table and parameter table by executing executable SQL scripts to obtain a structured result table; the structured result table is then transformed and visualized to obtain the final report generation and presentation.

[0056] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for automatically generating cloud reports for the financial and insurance sector, characterized in that, The method includes: The original business data is abstracted and processed to establish a data anonymization structure. Based on the data anonymization structure, the database tables are divided into basic tables, parameter tables, dictionary tables, intermediate tables, and result tables. A unified prefix identifier is set for the fields in the basic tables and parameter tables, and a mapping relationship between the anonymized fields and their actual business meanings is established through the dictionary table. Based on the data anonymization structure, we receive business requirements submitted by business personnel; business requirements include data filtering conditions, indicator fields to be displayed, and the calculation logic of each indicator. The business requirements are analyzed, and the core information in the business requirements is extracted to obtain security prompt words that contain only de-identified fields and logical instructions; Semantic association analysis is performed on security prompt words to identify the business data types and operation rules corresponding to logical instructions for each de-identified field, and semantic analysis values ​​are obtained. The discrete business requirement elements in the security prompt words are established according to the preset spatial association rules to establish a correspondence. The element matching value is obtained by effectively matching the business requirement elements with the SQL syntax elements. Based on the semantic analysis value and the element matching value, the SQL statement fragment is obtained. The SQL statement fragment is then subjected to syntax verification and business logic integration to obtain an executable SQL script. By executing an executable SQL script, the data in the base table and parameter table are called and calculated to obtain a structured result table; the structured result table is then transformed and visualized to obtain the final generated and presented report.

2. The cloud-based automated report generation method for the financial and insurance sector according to claim 1, characterized in that, Abstract the original business data and establish a data anonymization structure; Based on the data anonymization structure, the database tables are divided into basic tables, parameter tables, dictionary tables, intermediate tables, and result tables; A unified prefix identifier is set for all fields in the base table and parameter table. A mapping relationship between the masked fields and their actual business meanings is established through a dictionary table, including: Feature extraction is performed on the original business data, and high-dimensional business data is mapped to a low-dimensional space through geometric projection to achieve dimensionality reduction processing of data abstraction; based on the dimensionality reduction processing of data abstraction, the main component features are obtained; The main component features are mapped to the de-identified fields. By maintaining the geometric relationship between the fields, a set of fields named with the "col" prefix is ​​obtained. The base table is defined based on the set of fields. Define the table that stores data processing rules and configuration parameters as a parameter table, where each field in the parameter table is named with the prefix "para"; Define the table that stores the mapping relationship between the masked fields and their actual business meanings as a dictionary table; Define the table that stores temporary data generated during SQL processing as an intermediate table; Define the table that stores the final report data as the result table; Based on the mapping relationship established by the dictionary table, the anonymized fields are restored to their actual business meaning during the report generation stage. Based on the restored actual business meaning, the readability and data security of the report are obtained by adopting the inverse process of geometric projection.

3. The cloud-based automated report generation method for the financial and insurance sector according to claim 2, characterized in that, Based on a data anonymization structure, business requirements are received from business personnel. Business requirements include data filtering criteria, the indicator fields to be displayed, and the calculation logic for each indicator, including: Based on the field naming conventions provided by the data anonymization structure, we receive business requirements submitted by business personnel through structured spreadsheets. Spatial indexes are constructed for business requirements. By using R-tree index calculation, discrete business requirement elements are organized into spatial objects with a hierarchical structure. Based on the hierarchical structure of spatial objects, identify the spatial relationships between data filtering conditions, display indicator fields, and calculation logic expressions in business requirements; By verifying the spatial relationships, the consistency between the field names referenced in the business requirements and the de-identified fields defined in the data de-identification structure is verified, so as to ensure that all business logic is expressed based on the de-identified fields.

4. The cloud-based automated report generation method for the financial and insurance sector according to claim 3, characterized in that, By analyzing the business requirements and extracting the core information, we obtained security prompts containing only anonymized fields and logical instructions, including: In a local secure environment, the received business requirements are structured and parsed to identify the computational logic expressions and field reference relationships. Based on field reference relationships, by mapping the actual business fields referenced in business requirements to the corresponding de-identified fields, the association between de-identified fields and calculation logic can be established, that is, the de-identified field association relationship; By standardizing the computational logic expression, an instruction sequence consisting of de-identified fields and logical operators is obtained; Based on the relationship between the instruction sequence and the de-identified fields, a security prompt word containing only the de-identified identifier and logical operations is obtained to ensure that it does not contain any sensitive business information.

5. The cloud-based automated report generation method for the financial and insurance sector according to claim 4, characterized in that, Semantic association analysis is performed on security prompt words to identify the business data types corresponding to each de-identified field and the operation rules corresponding to the logical instructions, resulting in semantic analysis values, including: Semantic features are extracted from the de-identified fields and logical instructions in the security prompts, and the semantic feature representation relationship between the fields and instructions is established. Based on semantic feature representation, the semantic correlation between each de-identified field is analyzed to identify a set of fields with similar business meanings; Semantically group the field set, determine the business data type corresponding to each field based on the degree of semantic relevance, and obtain the semantic grouping results; Based on the semantic grouping results, the operational characteristics of logical instructions are analyzed to identify the operation rule type corresponding to each instruction; By combining the data types of business data and the types of operation rules, semantic analysis values ​​representing the semantic features of prompt words are obtained.

6. The cloud-based automated report generation method for the financial and insurance sector according to claim 5, characterized in that, Establish a correspondence between discrete business requirement elements in the security prompt words according to the preset spatial association rules, and obtain the element matching value through effective matching of business requirement elements and SQL syntax elements; Based on semantic analysis values ​​and element matching values, SQL statement fragments are obtained; The SQL statement fragments are syntax-checked and integrated with business logic to obtain an executable SQL script, including: Based on semantic analysis values, the business requirement elements in the security prompt words are arranged according to the data processing logic order, and the execution dependencies between the elements are established. Based on execution dependencies, the sorted business requirement elements are matched with SQL syntax elements to establish conversion rules from business logic to SQL statements; Based on the transformation rules, each business requirement element is converted into a corresponding SQL statement fragment, and the logical connection relationship between each fragment is recorded; Perform syntax correctness verification on the SQL statement fragments to ensure that each fragment conforms to the SQL syntax specification, and obtain the SQL statement fragments that pass the verification; Based on the logical connections, the validated SQL statement fragments are combined in the order of execution to obtain a complete executable SQL script.

7. The cloud-based automated report generation method for the financial and insurance sector according to claim 6, characterized in that, By executing an executable SQL script, data from the base table and parameter table can be called and processed to obtain a structured result table. The structured result tables are transformed and visualized to obtain the final generated and presented report, including: Execute the executable SQL script in the local database environment, call the data in the base table and parameter table, and process the data according to the calculation logic defined in the script; Based on the execution of the aforementioned operational logic, a structured result table containing the final data result is obtained by writing the processed data into the result table. The de-identified fields in the structured result table are restored. Based on the mapping relationship stored in the dictionary table, the de-identified fields are converted into actual business field names, resulting in a restored data table with business readability. The restored data table is input into the report generation engine, which then fills in the data and renders the format according to the preset report template to obtain the final visual report.

8. A cloud-based automated report generation system for the financial and insurance sector, wherein the system implements the method as described in any one of claims 1 to 7, characterized in that, include: The configuration module is used to abstract and process raw business data and establish a data anonymization structure; Based on the data anonymization structure, the database tables are divided into basic tables, parameter tables, dictionary tables, intermediate tables, and result tables; Set a uniform prefix identifier for all fields in the base table and parameter table, and establish a mapping relationship between the de-identified fields and their actual business meanings through a dictionary table; The receiving module is used to receive business requirements submitted by business personnel based on a data anonymization structure. Business requirements include data filtering conditions, indicator fields to be displayed, and the calculation logic for each indicator; The parsing module is used to parse business requirements and extract core information from them to obtain security prompt words that contain only de-identified fields and logical instructions. Semantic association analysis is performed on security prompt words to identify the business data types and operation rules corresponding to logical instructions for each de-identified field, and semantic analysis values ​​are obtained. The processing module is used to establish a correspondence between discrete business requirement elements in the security prompt words according to preset spatial association rules, and obtain element matching values ​​through effective matching of business requirement elements and SQL syntax elements; Based on semantic analysis values ​​and element matching values, SQL statement fragments are obtained; Perform syntax validation and business logic integration on SQL statement fragments to obtain an executable SQL script; The summary module is used to call and perform operations on the data in the base table and parameter table by executing executable SQL scripts to obtain a structured result table; The structured result table is transformed and visualized to obtain the final generated and presented report.

Images