Banking data processing method, system, terminal device and computer storage medium

Abstract

The application discloses a kind of banking data processing method, system, terminal equipment and readable storage medium, it is related to banking data processing field, the banking data processing method of the present application includes: by uniform syntax specification, generate the database modeling requirement information of multiple different databases;According to the database modeling requirement information of each database, and in combination with uniform logic modeling structure, establish banking professional knowledge base;Acquire the banking data to be processed, by banking professional knowledge base, the data logic model corresponding to banking data is translated into the data physical model corresponding to banking data;According to data physical model, generate the modeling statement adapted to each database;Modeling statement is input to the database environment corresponding to each database and is executed, obtains the result of analyzing and processing banking data.Processing analysis efficiency of banking data can be improved and cost is reduced by using the present application.

Description

Technical Field

[0001] This application relates to the field of banking data processing, and in particular to a method, system, terminal equipment, and readable storage medium for processing banking data. Background Technology

[0002] As data is widely recognized and deeply applied as a new factor of production, business innovation forces, represented by the banking industry, are seeing an increasing proportion of data-driven business, more diverse business needs, and an explosive growth in data scale. Therefore, it is necessary to build an intelligent modeling system based on banking business, with a professional banking knowledge base, business tags, and rule suggestions. This system would reduce the learning threshold and development cost of bank data model design, and provide security and compliance suggestions and supporting rule controls in model design from the perspective of banking business.

[0003] However, traditional data modeling and development systems primarily provide visual and logical design of database and table structures, as well as code writing. This is a general-purpose database development solution that cannot address the issue of repetitive development across multiple database types and clusters, resulting in low efficiency and high costs for data processing and analysis in the banking industry. For example, in the banking industry, various databases and data engines generally still use SQL (Structured Query Language) as the development language. However, due to differences in underlying storage and computing architectures, computing models, and data formats, various big data open-source software programs have different requirements and syntax for SQL, such as Hive, Apache Spark SQL, and GaussDB. Furthermore, based on scenario considerations, application systems may employ different component deployment strategies to address differences in storage and computing efficiency and cost. They may use different database tools simultaneously, but store the same data on them. This necessitates modeling a single business process across different databases. Achieving this requires data developers to master multiple database modeling languages ​​and understand their best design practices, leading to significant usage costs and efficiency bottlenecks. Summary of the Invention

[0004] The main objective of this application is to provide a method, system, terminal device, and readable storage medium for processing banking data, aiming to solve the technical problems of low efficiency and high cost in processing and analyzing banking data.

[0005] To achieve the above objectives, this application provides a method for processing banking data, the method comprising:

[0006] By using a unified syntax standard, database modeling requirements information for multiple different databases can be generated;

[0007] Based on the database modeling requirements of each database and combined with a unified logical modeling structure, a banking professional knowledge base is established. The banking professional knowledge base includes a dictionary, data items, and code value definitions corresponding to the data items. The dictionary includes a root word dictionary and a terminology dictionary.

[0008] The process involves acquiring banking data to be processed and translating the data logic model corresponding to the banking data into a data physical model corresponding to the banking data using the banking professional knowledge base.

[0009] Based on the data physical model, generate modeling statements adapted to each of the databases;

[0010] The modeling statement is input into the database environment corresponding to each of the databases and executed to obtain a comprehensive execution result, which is then used as the result of the analysis and processing of banking data.

[0011] Optionally, the step of translating the data logic model corresponding to the banking data into the data physical model corresponding to the banking data through the banking professional knowledge base includes:

[0012] Using the banking professional knowledge base, the data logic model corresponding to the banking data is initialized and marked, and a preset label-guided confirmation interface is output.

[0013] Upon receiving a confirmation instruction input in response to the label-guided confirmation interface, multiple preset target attributes corresponding to the banking data are generated based on the initialized data logic model. The preset target attributes include business labels and data distribution patterns.

[0014] Based on the preset target attributes corresponding to the banking data, the data physical model corresponding to the banking data is determined.

[0015] Optionally, the step of determining the data physical model corresponding to the banking data based on each of the preset target attributes includes:

[0016] Based on the preset target attributes corresponding to the banking data, business compliance indicators matching the banking data are retrieved from the banking professional knowledge base. The business compliance indicators include the value range information, security compliance information, and regulatory requirement information corresponding to the preset target attributes.

[0017] Based on the aforementioned business compliance indicators, the banking data is deployed in a multi-cluster model to obtain the corresponding data physical model.

[0018] Optionally, the step of generating modeling statements adapted to each of the databases based on the data physical model includes:

[0019] Obtain the database characteristics corresponding to each of the databases, and optimize and supplement the data physical model according to the database characteristics corresponding to each of the databases to obtain the target physical model that is adapted to each of the databases.

[0020] Based on the target physical model adapted to each of the databases, modeling statements adapted to each of the databases are generated;

[0021] The model optimization includes optimizing the field information, primary key and distribution key information of the data physical model, and the configuration supplement includes supplementing the lifecycle, storage type and sharding rules of the data physical model.

[0022] Optionally, the step of inputting the modeling statement into the database environment corresponding to each of the databases for execution to obtain a comprehensive execution result includes:

[0023] The modeling statement is input into the database environment corresponding to each database, and the model execution instruction information corresponding to each database environment is output. The database environment includes database type information, and the model execution instruction information is to create a new model or modify a model.

[0024] The statement strategy adapted to the instruction information of each model is executed to obtain the comprehensive execution result.

[0025] Optionally, before the step of translating the data logic model corresponding to the banking data into the data physical model corresponding to the banking data, the method further includes:

[0026] A standardization check was performed on the data logic model corresponding to the aforementioned banking data;

[0027] The non-standard information identified during the standardization check is corrected and updated in the data logic model corresponding to the banking data.

[0028] Optionally, the step of acquiring the banking data to be processed includes:

[0029] Obtain the mapping source banking business data of the end-to-end input;

[0030] By using the mapped source banking business data, combined with fact model design and dimensional model design, core data of the banking industry's data warehouse is obtained through screening and analysis.

[0031] The core data of the data warehouse is used as banking data to be processed.

[0032] Furthermore, to achieve the above objectives, this application also provides a banking data processing system, the system comprising:

[0033] The semantic definition module is used to generate database modeling requirements information for multiple different databases through a unified syntax specification;

[0034] The logic design module is used to establish a banking professional knowledge base based on the database modeling requirements of each database and in combination with a unified logic modeling structure. The banking professional knowledge base includes a dictionary, data items, and code value definitions corresponding to the data items. The dictionary includes a root word dictionary and a terminology dictionary.

[0035] The physical conversion module is used to acquire banking data to be processed and, through the banking professional knowledge base, translate the data logic model corresponding to the banking data into the data physical model corresponding to the banking data.

[0036] The statement generation module is used to generate modeling statements adapted to each of the databases based on the data physical model;

[0037] The statement execution module is used to input the modeling statement into the database environment corresponding to each of the databases for execution, obtain a comprehensive execution result, and use the comprehensive execution result as the result of analysis and processing of banking data.

[0038] In addition, to achieve the above objectives, this application also provides a terminal device, the terminal device comprising: a memory, a processor, and a banking data processing program stored in the memory and executable on the processor, wherein when the banking data processing program is executed by the processor, it implements the steps of the banking data processing method described above.

[0039] In addition, to achieve the above objectives, this application also provides a computer-readable storage medium storing a banking data processing program, which, when executed by a processor, implements the steps of the banking data processing method described above.

[0040] This application generates database modeling requirement information for multiple different databases through a unified syntax specification, thereby defining a unified modeling syntax specification and logical modeling structure. Based on the database modeling requirement information of each database and combined with the unified logical modeling structure, a banking professional knowledge base is established. This banking professional knowledge base includes a dictionary, data items, and code value definitions corresponding to the data items. The dictionary includes a root word dictionary and a terminology dictionary. Then, the banking data to be processed is obtained. Through the banking professional knowledge base, the data logical model corresponding to the banking data is translated into a data physical model corresponding to the banking data. A unified semantic model is then used to establish the logical model. Based on the database to be modeled, the... The logical model is translated into a physical model corresponding to the database. Then, based on the physical model, modeling statements adapted to each database are generated. This enables the system to automatically generate modeling statements for different databases based on the physical model. The modeling statements are then input into the database environment corresponding to each database for execution, resulting in a comprehensive execution result. This comprehensive execution result is used as the result of analyzing and processing banking data, thus providing a unified semantic logical modeling method. The data development of this application only requires defining the business model once. The system automatically converts and generates multi-engine, multi-cluster models and tasks, achieving one-time development and multi-cluster deployment, significantly improving modeling efficiency and model portability, and reducing the learning cost of data development.

[0041] In other words, the banking data processing method in this application enables unified semantic data logic modeling. Through a unified standard of modeling semantics, it meets the modeling needs of various databases. Users do not need to worry about the syntax differences between databases and can use unified semantics to complete modeling for different databases. Furthermore, modeling with unified semantic syntax allows for one-time definition and simultaneous modeling for multiple databases, significantly improving modeling efficiency and demonstrating the replicability and portability of logical modeling. Simultaneously, the unified semantics supports extension, achieving compatibility with different databases, reducing the cost and efficiency of modeling banking data on different databases, and thus effectively solving the technical problems of low efficiency and high cost in processing and analyzing banking data. Attached Figure Description

[0042] Figure 1 This is a schematic diagram of the structure of the terminal device in the hardware operating environment involved in the embodiments of this application;

[0043] Figure 2 This is a flowchart illustrating the first embodiment of the banking data processing method of this application;

[0044] Figure 3 This is a flowchart illustrating the second embodiment of the banking data processing method of this application;

[0045] Figure 4This is a flowchart illustrating the third embodiment of the banking data processing method of this application;

[0046] Figure 5 This is a flowchart illustrating the fourth embodiment of the banking data processing method of this application;

[0047] Figure 6 This is a schematic diagram of the functional modules involved in an embodiment of the banking data processing system of this application.

[0048] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0049] It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0050] Reference Figure 1 , Figure 1 This is a schematic diagram of the terminal device structure of the hardware operating environment involved in the embodiments of this application.

[0051] It should be noted that the terminal device in this application embodiment can be a device that executes the banking data processing method of this application, and the terminal device can specifically be a terminal device that internally includes a banking data processing system.

[0052] like Figure 1 As shown, the terminal device may include: a processor 1001, such as a central processing unit (CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen and an input unit such as a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be a high-speed random access memory (RAM) or a stable non-volatile memory (NVM), such as a disk drive. The memory 1005 may also optionally be a storage device independent of the aforementioned processor 1001.

[0053] Those skilled in the art will understand that Figure 1The structure shown does not constitute a limitation on the terminal device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0054] like Figure 1 As shown, the memory 1005, which serves as a storage medium, may include an operating system, a data storage module, a network communication module, a user interface module, and a banking data processing program.

[0055] exist Figure 1 In the terminal device shown, the network interface 1004 is mainly used for data communication with other devices; the user interface 1003 is mainly used for data interaction with the user; the processor 1001 and memory 1005 in the terminal device of this application can be set in the terminal device, and the terminal device calls the processing program of banking data stored in the memory 1005 through the processor 1001 and performs the following operations:

[0056] By using a unified syntax standard, database modeling requirements information for multiple different databases can be generated;

[0057] Based on the database modeling requirements of each database and combined with a unified logical modeling structure, a banking professional knowledge base is established, which includes a dictionary, data items, and the code value definition corresponding to the data items.

[0058] The process involves acquiring banking data to be processed and translating the data logic model corresponding to the banking data into a data physical model corresponding to the banking data using the banking professional knowledge base.

[0059] Based on the data physical model, generate modeling statements adapted to each of the databases;

[0060] The modeling statement is input into the database environment corresponding to each of the databases and executed to obtain a comprehensive execution result, which is then used as the result of the analysis and processing of banking data.

[0061] Furthermore, the processor 1001 calls the processing program for banking data stored in memory 1005 and performs the following operations:

[0062] Using the banking professional knowledge base, the data logic model corresponding to the banking data is initialized and marked, and a preset label-guided confirmation interface is output.

[0063] Upon receiving a confirmation instruction input in response to the label-guided confirmation interface, multiple preset target attributes corresponding to the banking data are generated based on the initialized data logic model. The preset target attributes include business labels and data distribution patterns.

[0064] Based on the preset target attributes corresponding to the banking data, the data physical model corresponding to the banking data is determined.

[0065] Furthermore, the processor 1001 calls the processing program for banking data stored in memory 1005 and performs the following operations:

[0066] Based on the preset target attributes corresponding to the banking data, business compliance indicators matching the banking data are retrieved from the banking professional knowledge base. The business compliance indicators include the value range information, security compliance information, and regulatory requirement information corresponding to the preset target attributes.

[0067] Based on the aforementioned business compliance indicators, the banking data is deployed in a multi-cluster model to obtain the corresponding data physical model.

[0068] Furthermore, the processor 1001 calls the processing program for banking data stored in memory 1005 and performs the following operations:

[0069] Obtain the database characteristics corresponding to each of the databases, and optimize and supplement the data physical model according to the database characteristics corresponding to each of the databases to obtain the target physical model that is adapted to each of the databases.

[0070] Based on the target physical model adapted to each of the databases, modeling statements adapted to each of the databases are generated;

[0071] The model optimization includes optimizing the field information, primary key and distribution key information of the data physical model, and the configuration supplement includes supplementing the lifecycle, storage type and sharding rules of the data physical model.

[0072] Furthermore, the processor 1001 calls the processing program for banking data stored in memory 1005 and performs the following operations:

[0073] The modeling statement is input into the database environment corresponding to each database, and the model execution instruction information corresponding to each database environment is output. The database environment includes database type information, and the model execution instruction information is to create a new model or modify a model.

[0074] The statement strategy adapted to the instruction information of each model is executed to obtain the comprehensive execution result.

[0075] Furthermore, the processor 1001 calls the processing program for banking data stored in memory 1005 and performs the following operations:

[0076] A standardization check was performed on the data logic model corresponding to the aforementioned banking data;

[0077] The non-standard information identified during the standardization check is corrected and updated in the data logic model corresponding to the banking data.

[0078] Furthermore, the processor 1001 calls the processing program for banking data stored in memory 1005 and performs the following operations:

[0079] Obtain the mapping source banking business data of the end-to-end input;

[0080] By using the mapped source banking business data, combined with fact model design and dimensional model design, core data of the banking industry's data warehouse is obtained through screening and analysis.

[0081] The core data of the data warehouse is used as banking data to be processed.

[0082] Based on the aforementioned terminal equipment, this application provides an overall concept for the method of processing banking data.

[0083] Currently, traditional data modeling and development systems primarily provide visual and logical design of database and table structures, as well as code writing. This is a general-purpose database-like development solution, but it cannot solve the problem of repetitive development across multiple database types and clusters, resulting in low efficiency and high costs for data processing and analysis in the banking industry. For example, in the banking industry, various databases and data engines generally still use SQL (Structured Query Language) as the development language. However, due to differences in underlying storage and computing architectures, computing models, and data formats, various big data open-source software have different requirements and syntax for SQL, such as Hive, Apache Spark SQL, and GaussDB. Furthermore, based on scenario considerations, application systems may adopt different component deployment strategies to address differences in storage and computing efficiency and cost, potentially using different database tools that store the same data. This necessitates modeling a single business process on different databases. Achieving this requires data developers to master multiple database modeling languages ​​and understand their best design practices, leading to significant usage costs and efficiency bottlenecks.

[0084] Specifically, for applications or data warehouses that simultaneously use multiple computing and storage engines such as Gauss and Hadoop, with each engine potentially having multiple clusters, user business requirements necessitate the separate development of a single business model across different engines and clusters. This results in low development efficiency and difficulty in ensuring consistency. Furthermore, different databases and engines have different syntax and specification requirements, leading to high learning costs and steep learning curves.

[0085] To address the aforementioned issues, this application proposes a method for processing banking data. The method includes: generating database modeling requirements for multiple different databases using a unified syntax standard; establishing a banking professional knowledge base based on the database modeling requirements of each database and a unified logical modeling structure, wherein the banking professional knowledge base includes a dictionary, data items, and code value definitions corresponding to the data items; acquiring the banking data to be processed; translating the data logic model corresponding to the banking data into a data physical model corresponding to the banking data using the banking professional knowledge base; generating modeling statements adapted to each database based on the data physical model; inputting the modeling statements into the database environment corresponding to each database for execution, obtaining a comprehensive execution result, and using the comprehensive execution result as the result of analyzing and processing the banking data.

[0086] Thus, the banking data processing method in this embodiment can achieve unified semantic data logic modeling. Through unified standard modeling semantics, it meets the modeling needs of various databases. Users do not need to worry about the syntax differences between databases and can use unified semantics to complete modeling for different databases. Furthermore, through unified semantic syntax modeling, it is possible to define once and model multiple databases simultaneously, significantly improving modeling efficiency and demonstrating the replicability and portability of logical modeling. At the same time, unified semantics supports extension, achieving compatibility with different databases, reducing the cost and efficiency of modeling banking data on different databases, and effectively solving the technical problems of low efficiency and high cost in processing and analyzing banking data.

[0087] Based on the overall concept of the terminal equipment and the banking data processing method of this application described above, various embodiments of the banking data processing method of this application are further proposed.

[0088] Please refer to Figure 2 , Figure 2 This is a flowchart illustrating the first embodiment of the banking data processing method of this application.

[0089] It should be understood that although the logical order is shown in the flowchart, in some cases, the method of processing banking data in this application may of course be performed in a different order than that shown or described here.

[0090] like Figure 2 As shown, in this embodiment, the method for processing banking data may include the following steps:

[0091] Step S10: Generate database modeling requirements information for multiple different databases using a unified syntax specification;

[0092] In this embodiment, a unified modeling syntax specification is first defined, for example, based on SQL92, to ensure compatibility with standard syntax, keywords, and data types of GaussDB, Hadoop, etc., providing users with a unified modeling language. Thus, based on the characteristics of multiple different databases, and combined with the defined unified syntax specification, database modeling requirement information for multiple different databases can be generated.

[0093] Step S20: Based on the database modeling requirements of each database and combined with a unified logical modeling structure, establish a banking professional knowledge base;

[0094] The banking professional knowledge base includes a dictionary, data items, and code value definitions corresponding to the data items. The dictionary includes a root word dictionary and a terminology dictionary.

[0095] In this embodiment, a banking professional knowledge base needs to be constructed based on the database modeling requirements of each database and in conjunction with a unified logical modeling structure. This banking professional knowledge base includes dictionaries, data items, and corresponding code value definitions for the data items. The dictionaries include a root word dictionary and a terminology dictionary. Of course, this banking professional knowledge base may also include design specifications for the data items, their respective theme and business domain tags, as well as classification and grading quality and management specifications, and logical and physical model conversion specifications, etc.

[0096] This embodiment adopts a unified semantics approach to establish the design principles of the logical model, thereby achieving a unified semantics logical model design that facilitates users in completing the logical model design.

[0097] Specifically, to aid understanding, the following description is provided:

[0098] In this embodiment, the root word dictionary includes root words for the main business and their Chinese and English definitions, such as account, institution, transaction, discount, corporate, etc. Table (I) below shows an example of root words:

[0099]

[0100] (one)

[0102] The terminology dictionary is based on national banking industry standards, extracting the Chinese and English full pinyin or abbreviations of commonly used terms. Compared to word roots, it has a more universal meaning in the banking industry. Table (II) below is an example of a terminology dictionary:

[0103]

[0104] (two)

[0106] In this embodiment, some data items of terminology and bank owner data (data items can be translated based on word root combinations) may have a specific case where their content has agreed-upon alternative values, requiring the definition of their code values ​​in the knowledge base. Simultaneously, each type of data item can define its associated topic, which is a type of business tag. Table (III) below provides an example of code values:

[0107] (three)

[0109] A topic can define its business domain and be used for rule processing related to that business domain. Table (IV) below provides an example of a topic:

[0110] theme Field of study Bill of exchange business Business Operations (Four)

[0112] It should be noted that the rules and specifications for data items (i.e., the design specifications corresponding to data items) are divided into business specifications and system specifications:

[0113] 1. Business specifications refer to data items subject to specific controls or requirements within the banking industry. Examples include standardized PII (Personal Identifiable Information) data, security levels for sensitive information, encryption strategies, and access and dissemination control policies. Additionally, there are inspection rules and definitions for data items submitted to regulatory authorities. These specifications, once defined, are used for data control to ensure the compliant use and management of data.

[0114] 2. System specifications should consider the following when converting the logical model into a physical model: Based on common banking data distribution patterns, the system should generate different partitioning strategies and timestamps; manage data validity and expiration according to banking standards; and establish multiple physical models that meet the requirements of the logical model, automatically configuring their storage strategies and data partitioning, etc. Table (V) below provides examples of data distribution patterns, validity periods, and agreed-upon physical fields:

[0115] (five)

[0117] After step S20, step S30 is executed: obtain the banking data to be processed, and translate the data logic model corresponding to the banking data into the data physical model corresponding to the banking data through the banking professional knowledge base;

[0118] This embodiment translates the logical model into a physical model of the corresponding database based on the database to be modeled. Specifically, for example, it translates according to GaussDB syntax, mapping model attributes, field attributes, constraint information, etc., to GaussDB table or view elements. Using this method, the logical model is mapped to the physical model, and it can also be extended to support other database types.

[0119] For example, the step of acquiring banking data to be processed includes:

[0120] Step A10: Obtain the end-to-end input mapping source banking business data;

[0121] Step A20: Using the mapped source banking business data, combined with fact model design and dimensional model design, core data of the banking industry's data warehouse is obtained through screening and analysis;

[0122] Step A30: The core data of the data warehouse is used as banking data to be processed.

[0123] This embodiment acquires end-to-end input mapping source banking business data, and then, through this mapping source banking business data, combined with fact model design and dimensional model design, filters and analyzes to obtain the core data of the banking industry's data warehouse. This core data of the data warehouse is then used as the banking industry data to be processed. Thus, when the banking industry data to be processed needs to be acquired, this embodiment can quickly establish core data such as data warehouse master data through end-to-end mapping source data and fact model / dimensional model, thereby completing the process of acquiring source data (i.e., mapping source banking business data) to obtain the banking industry data to be processed. This facilitates the subsequent use of the banking industry data to be processed as seeds, quickly initializing and marking it through a knowledge base, guiding manual confirmation, and finally completing the marking of business tags and data distribution patterns.

[0124] Furthermore, prior to the step of translating the data logic model corresponding to the banking data into the data physical model corresponding to the banking data, the method further includes:

[0125] Step B10: Perform a standardization check on the data logic model corresponding to the banking data;

[0126] Step B20: Correct and update the non-standard information identified during the standardization check in the data logic model corresponding to the banking data.

[0127] This embodiment performs a standardization check on the data logic model corresponding to banking data, and corrects and updates the non-standard information found in the standardization check within the data logic model corresponding to banking data. This allows the embodiment of this application to check the standardization of the logical model after establishing the logical model and before translating the physical model. For example, it checks for non-standard situations such as inappropriate naming, non-standard data types, excessively large field lengths, and missing necessary attributes.

[0128] After step S30, step S40 is executed: based on the data physical model, modeling statements adapted to each of the databases are generated;

[0129] In this embodiment, the system has obtained the physical models of all databases to be modeled. Based on the syntax of the databases and the elements of the physical models, it can assemble and generate the final modeling statement to be executed. Each database will generate its own independent modeling statement.

[0130] Step S50: Input the modeling statement into the database environment corresponding to each of the databases for execution, and obtain the comprehensive execution result. Use the comprehensive execution result as the result of analyzing and processing banking data.

[0131] In this embodiment, the modeling statement is submitted to the corresponding database environment for execution according to the environment configuration of the database to be modeled, and the execution result is returned. The returned execution result is the result of the analysis and processing of banking data.

[0132] For applications or data warehouses that use multiple computing and storage engines such as Gauss and Hadoop, and each computing engine may have multiple clusters, the user's business scenario requirements mean that a business model needs to be developed separately on different engines and different clusters, resulting in low development efficiency and difficulty in ensuring consistency. Different databases and engines have different syntax and specification requirements, which leads to high learning costs and high barriers to entry.

[0133] This embodiment generates database modeling requirement information for multiple different databases through a unified syntax specification, thereby defining a unified modeling syntax specification and logical modeling structure. Based on the database modeling requirement information of each database and combined with the unified logical modeling structure, a banking professional knowledge base is established. This banking professional knowledge base includes a dictionary, data items, and code value definitions corresponding to the data items. The dictionary includes a root word dictionary and a terminology dictionary. Then, the banking data to be processed is obtained. Through the banking professional knowledge base, the data logic model corresponding to the banking data is translated into a data physical model corresponding to the banking data. A unified semantic model is then used to establish the logical model. Based on the database to be modeled, the logical model is... The logical model is translated into a physical model of the corresponding database. Then, based on the physical model, modeling statements adapted to each database are generated. This enables the system to automatically generate modeling statements for different databases based on the physical model. The modeling statements are then input into the database environment corresponding to each database for execution, resulting in a comprehensive execution result. This comprehensive execution result is used as the result of analyzing and processing banking data, thus providing a unified semantic logical modeling method. In this embodiment, data development only requires defining the business model once. The system automatically converts and generates multi-engine, multi-cluster models and tasks, achieving one-time development and multi-cluster deployment, significantly improving modeling efficiency and model portability, and reducing the learning cost of data development.

[0134] In other words, the banking data processing method in this application embodiment can achieve unified semantic data logic modeling. Through unified standard modeling semantics, it meets the modeling needs of various databases. Users do not need to worry about the syntax differences between databases and can use unified semantics to complete modeling for different databases. Furthermore, through unified semantic syntax modeling, it is possible to define once and model multiple databases simultaneously, significantly improving modeling efficiency and demonstrating the replicability and portability of logical modeling. At the same time, unified semantics supports extension, achieving compatibility with different databases, reducing the cost and efficiency of modeling banking data on different databases, and thus effectively solving the technical problems of low efficiency and high cost in processing and analyzing banking data.

[0135] Furthermore, based on the first embodiment of the banking data processing method of this application described above, a second embodiment of the banking data processing method of this application is proposed herein.

[0136] Please refer to Figure 3 , Figure 3 This is a flowchart illustrating the second embodiment of the banking data processing method of this application. Figure 3 As shown, in step S30 above, the step of translating the data logic model corresponding to the banking data into the data physical model corresponding to the banking data through the banking professional knowledge base includes:

[0137] Step S31: Initialize and mark the data logic model corresponding to the banking data through the banking professional knowledge base, and output a preset label guidance confirmation interface;

[0138] Step S32: After receiving the confirmation instruction input in response to the tag-guided confirmation interface, generate multiple preset target attributes corresponding to the banking data according to the data logic model after initialization of the tag, wherein the preset target attributes include business tags and data distribution patterns;

[0139] Step S33: Determine the data physical model corresponding to the banking data based on the preset target attributes corresponding to the banking data.

[0140] This embodiment uses a banking professional knowledge base to initialize and mark the data logic model corresponding to banking data, and outputs a preset tag-guided confirmation interface. After receiving a confirmation command input in response to the tag-guided confirmation interface, multiple preset target attributes corresponding to the banking data are generated according to the initialized and marked data logic model. Among them, the preset target attributes include business tags and data distribution patterns. Then, based on each preset target attribute corresponding to the banking data, the data physical model corresponding to the banking data is determined. Thus, using the data logic model corresponding to the banking data as a seed, the knowledge base is used to quickly initialize and mark the data, guide manual confirmation, and finally complete the marking of preset target attributes such as business tags and data distribution patterns.

[0141] To aid understanding, a specific embodiment is provided for further description:

[0142] This embodiment requires source data standard management. Specifically, during source data collection, in addition to field mapping, end-to-end configuration and hiding underlying details, recommending terminology, business tagging, and marking data distribution patterns, it is also necessary to define the source of business data in accordance with banking industry standards, including the banking industry sector to which it belongs and the reporting items that are affected.

[0143] This embodiment requires establishing a source data collection and labeling strategy. By mapping source data to fact models / dimensional models end-to-end, core data assets such as data warehouse master data can be quickly established. This type of data is then used as seeds for rapid initial labeling through a knowledge base, guiding manual confirmation. Finally, the labeling of business tags, data distribution patterns, etc., is completed.

[0144] Specifically, the end-to-end mapping of source data to the fact model / dimensional model is a highly automated solution based on the characteristics of the banking data architecture:

[0145] (1) After the user quickly configures the data mapping, the system automatically establishes the source data layer through the source data model and then maps and generates the fact model and dimensional model without the need for manual development. During the mapping generation process, the data distribution pattern of the source data is manually marked. After the system checks and confirms the data distribution pattern through knowledge base keywords, it will automatically generate incremental and full process models and data based on the data distribution pattern.

[0146] (2) After generating fact and dimension models through rapid mapping, the system automatically matches keywords based on the knowledge base, generates field definitions in English and Chinese that conform to data specifications, and marks the identified business tags. At the same time, it guides manual marking of the domain to which the business belongs, as well as the regulatory and reporting items that may be affected. Meanwhile, the system automatically transmits the business tags defined at the source to the fact and dimension models according to the mapping relationship, including business domains, code value definitions, and classification and hierarchical security tags, etc.

[0147] (3) The facts / dimensional models collected above have relevant features that conform to the terminology definitions of banking standards, and also have multi-dimensional markings such as business, security, and regulation.

[0148] Furthermore, the collected data can be further processed according to business needs, i.e., data processing modeling. Data processing modeling includes two parts: model design and data processing logic. At this stage, the model name, fields, and data distribution format should be defined according to business requirements, and labels such as banking business, quality and timeliness levels, security levels, and regulatory requirements should be added. Then, the data processing logic should be written. Among these:

[0149] Step 1: Processing and Modeling. First, a logical model needs to be created according to business requirements, including names, fields, and data distribution patterns. During development, the system automatically searches the knowledge base, automatically checks the consistency of banking terminology and the matching degree between Chinese and English, and automatically supplements attribute information such as code value configurations for banking-specific data items. Users can also tag items at this stage with labels such as banking business, quality and timeliness levels, security levels, and regulatory requirements.

[0150] Step Two: After the user completes the logical model setup using the system's low-code visual interface, the system automatically retrieves the banking model format from the knowledge base, automatically completes physical fields and other information, and then generates multi-engine physical model code through the unified semantic code module. This module is compatible with the syntax specifications of various databases such as GaussDB, Hadoop, Oracle, etc. Based on the structured physical model definition, it generates executable modeling code (i.e., modeling statements) that are compatible with each database. During generation, depending on different scenarios such as creation and modification, different code implementations for each database are selected. Based on the physical model definition and combined with the needs of business and data architecture (i.e., database characteristics), the code is distributed to multiple engines and clusters for creation.

[0151] Step 3: After completing the physical model creation, users can write the model's data processing logic using the system's low-code visual interface, according to their business needs. The system's low-code visual configuration supports entering processing logic by statement and operator structure. Upon completion, it automatically parses and identifies the data source of the current model and analyzes the calculation relationships of the fields.

[0152] Step 4: After identifying the data source, extract the business tags of the source model and fields, analyze the types of field calculation relationships, and determine the transitivity of the tags: If the calculation relationship is a reference or simple processing, it means that the business meaning has not changed, and the relevant tags can be passed; if the calculation relationship is a complex processing, the business meaning may have changed, and it is necessary to assist the user in making a judgment: if the judgment result is that the business meaning has not changed, then the relevant tags are passed; if the judgment result is that the business meaning has changed, then the relevant tags are not passed.

[0153] The transferable business tags include: the banking business area, quality and timeliness level, security level, regulatory requirements, etc. The system determines which business tags to transfer by comparing them with those marked in the user's logical model design. Missing tags are automatically filled in, and conflicting tags are flagged to assist the user in making a judgment.

[0154] Step 5: After the model structure, processing logic, and model labels are determined, the system automatically completes the deployment of models across multiple clusters.

[0155] This embodiment constructs a professional knowledge base for the banking industry. In model design, it provides multi-layered model design, including terminology translation, business tag generation, and business rule generation. Through a low-code, visual logical modeling method, data development starts from business needs, allowing users to focus solely on logical model design. The system automatically generates physical models that conform to banking data standards based on the logical model. Users only need to define the business model once to automatically generate multi-engine, multi-cluster models and tasks, achieving one-time development and multi-cluster deployment. This significantly improves modeling efficiency and model portability, and greatly reduces the learning cost of data development.

[0156] It should be noted that although the above specific embodiment one illustrates many technical details, it is only used to assist in understanding the technical concept of this application and does not constitute a limitation on the processing method of banking data in this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0157] In one possible implementation, step S33: determining the data physical model corresponding to the banking data based on each of the preset target attributes includes:

[0158] Step C10: Based on the preset target attributes corresponding to the banking data, retrieve the business compliance indicators matching the banking data from the banking professional knowledge base, wherein the business compliance indicators include the value range information, security compliance information and regulatory requirement information corresponding to the preset target attributes;

[0159] Step C20: Based on the business compliance indicators, perform multi-cluster model control on the banking data to obtain the data physical model corresponding to the banking data.

[0160] As data is widely recognized and deeply applied as a new factor of production, business innovation forces, represented by the banking industry, are seeing an increasing proportion of data-driven business, more diverse business needs, and an explosive growth in data scale. Therefore, it is necessary to build an intelligent modeling system based on banking business, with a professional banking knowledge base, business tags, and rule suggestions. This system would reduce the learning threshold and development cost of bank data model design, and provide security and compliance suggestions and supporting rule controls in model design from the perspective of banking business.

[0161] Based on this, this application embodiment retrieves business compliance indicators matching the banking data from a banking professional knowledge base according to the preset target attributes corresponding to the banking data. These business compliance indicators include the value range information, security compliance information, and regulatory requirement information corresponding to the preset target attributes. Based on these business compliance indicators, multi-cluster model control is implemented on the banking data to obtain the corresponding data physical model. This provides a method for constructing a banking data model with business tags. By establishing a banking professional knowledge base, starting from business needs, users can focus on model structure design, business tagging, and business rule generation. This enables one-time definition and generation of multi-level models, significantly improving the efficiency of constructing banking data models while enhancing compliance control of the banking models.

[0162] To aid understanding, a second specific embodiment is provided for further description:

[0163] This embodiment requires processing and modeling banking data. Specifically, the name, fields, and data distribution format of the logical model are defined according to business needs, and attribute information is automatically completed using a knowledge base. The system automatically generates multi-engine physical model code based on the logical model. Then, according to business requirements, the user completes the data processing logic of the new model. The system automatically identifies the data source, analyzes the transitivity of field business tags, reviews the model design, and recommends tags such as banking business domain, quality and timeliness level, security level, and regulatory requirements to the user. After user confirmation, the system automatically completes the multi-cluster model deployment.

[0164] This embodiment requires recommending business rules for banking data. Specifically, based on the business tags of the model, the system searches the banking knowledge base to find matching value ranges, security compliance, regulatory requirements, and other business rules, and automatically suggests the business rules to be generated. After user confirmation, the system automatically generates physical rules for multiple engines and completes the model deployment across multiple clusters.

[0165] Specifically, after completing the model structure and business tag processing, the system retrieves the banking knowledge base based on the model's business tags and recommends the model's business control rules, including:

[0166] (1) For each model's fields, based on terms and data items, multiple business rules need to be generated, such as value range verification, encryption and access policy checks, and regulatory rule verification.

[0167] (2) Each model generates high-level testing and control rules, reporting timeliness control rules and other business rules based on the banking industry’s unique compliance requirements such as quality and timeliness levels and regulatory relevance, to ensure timely and compliant data output.

[0168] The generation of business rules is handled by a business rule generation engine. This engine defines clear, standard rules, which are uniformly adopted during the recommended rule generation process. Users are encouraged to confirm and edit the rules using a visual, low-code approach. Once confirmed, the engine executes the physical rule generation. This engine integrates with various execution systems through a standard interactive interface and provides extensible configuration. When generating physical rules, it can adapt to various systems to configure specific business rules, as well as the runtime triggering and result collection interaction configurations for each system.

[0169] Furthermore, this embodiment performs model processing and analysis on banking data. Specifically, during the model processing and modeling process, the model needs to be reviewed. This requires the system to provide the ability to analyze the model processing logic, identify the data source of the current model, construct field calculation relationships, and then analyze the business tags of the data source model. The transitivity of the field business tags is analyzed for comparison with the automatically recommended and manually assigned business tags during modeling.

[0170] In addition, the generation of the physical model requires processing data structures, business tags, and business rules. The system supports a low-code, visual configuration approach, automatically checks physical specifications, generates multi-engine code, and deploys it to multiple clusters.

[0171] The generation of physical code for the model data structure consists of two steps:

[0172] (1) Completing Information to Generate Physical Model and Code: After the user completes the logical model design in the system, the system retrieves the banking model form from the knowledge base and automatically completes the physical fields and other information to generate the physical model. Then, the physical model code is generated through the unified semantic code module. This module is compatible with the type systems and semantic specifications of multiple database engines and can automatically convert the physical data structure into physical model code for multiple types of engines, including generating matching modeling code and adjusting the code according to different scenarios such as creation and modification.

[0173] (2) Business Rule Generation: In business rule recommendation, business rules need to be automatically suggested based on model-based business tags. Business rules involve code value checking, high-level testing and control, sensitive field encryption, sensitive field access control and anti-proliferation strategies, and data rule verification and timeliness control for regulatory reporting. Since the configuration and execution systems involved are generally different, a business rule generation engine needs to be built. This engine will define standard rules, and these definitions will be used uniformly during rule recommendation to ensure a consistent user experience. After configuration, in the physical rule generation stage, the engine will adapt to different systems, configure specific business rules, and configure the interaction between system operation triggers and result collection.

[0174] It should be noted that although the above-described specific embodiment two illustrates many technical details, it is only used to assist in understanding the technical concept of this application and does not constitute a limitation on the processing method of banking data in this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0175] In one feasible embodiment, step S40 above: generating modeling statements adapted to each of the databases based on the data physical model includes:

[0176] Step D10: Obtain the database characteristics corresponding to each database; based on the database characteristics corresponding to each database, optimize and supplement the data physical model respectively to obtain the target physical model that is adapted to each database.

[0177] Step D20: Based on the target physical model adapted to each of the databases, generate modeling statements adapted to each of the databases.

[0178] Step D30, wherein the model optimization includes optimizing the field information, primary key and distribution key information of the data physical model, and the configuration supplement includes supplementing the lifecycle, storage type and sharding rules of the data physical model.

[0179] In this embodiment, after converting the physical model, the system automatically optimizes and supplements the physical model configuration based on the characteristics of different databases. The optimization process considers the field information, primary key and distribution key information of the physical model, combined with the database type, to supplement the optimal storage configuration of the physical model, such as the model's lifecycle, storage type, and sharding rules. Figure 4 As shown.

[0180] Furthermore, in a feasible embodiment, step S50, which involves inputting the modeling statement into the database environment corresponding to each of the databases for execution to obtain a comprehensive execution result, includes:

[0181] Step E10: Input the modeling statement into the database environment corresponding to each database, and output the model execution instruction information corresponding to each database environment. The database environment includes database type information, and the model execution instruction information is to create a new model or modify a model.

[0182] Step E20: Execute the statement strategy adapted to the instruction information of each model to obtain the comprehensive execution result.

[0183] This embodiment, after converting the physical model, selects an appropriate statement strategy based on the database type for which the model is to be built, and whether it is a new or modified model, for the next step of generating modeling statements.

[0184] To aid understanding, a specific embodiment three is provided to further describe the modeling statement strategy of this application's embodiments, such as... Figure 5 As shown:

[0185] 1. After obtaining the physical model, first select different statement strategies based on whether it is a new creation or a modification;

[0186] 2. If it is a new model, the statement for creating a new model can be directly generated according to the syntax of the database corresponding to the physical model;

[0187] 3. If it is a model change, it is necessary to further determine whether the corresponding database can use the alter syntax and meet the reliability requirements;

[0188] 4. If the `alter` syntax can be used, and the `alter` syntax changes meet reliability requirements such as reversibility, accessibility, and data consistency, then model change statements based on `alter` will be generated directly. Note that different attributes may not be changed at once, or other commands similar to `alter` may be required, therefore multiple change statements may be generated.

[0189] 5. If the `alter` syntax cannot be used, the statement should employ a strategy of first creating a temporary model and then renaming / replacing it. The temporary model can be generated directly using the `create new model` statement, and the model name should be replaced with the system's default model name. After the `create temporary model` statement, add statements to rename the old model to the old model name and the temporary model to the official model name. Different databases may choose different generation strategies; therefore, after determining the modeling statement strategy, reserve separate statements for each database for final execution.

[0190] It should be noted that although the above-described specific embodiment three illustrates many technical details, it is only used to assist in understanding the technical concept of this application and does not constitute a limitation on the processing method of banking data in this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0191] In addition, to achieve the above objectives, this application also provides a banking data processing system, please refer to... Figure 6 , Figure 6 This is a schematic diagram of the functional modules involved in an embodiment of the banking data processing system of this application, as shown below. Figure 6 As shown, the system includes:

[0192] Semantic definition module 10 is used to generate database modeling requirement information for multiple different databases through a unified syntax specification;

[0193] The logic design module 20 is used to establish a banking professional knowledge base based on the database modeling requirements of each database and in combination with a unified logic modeling structure. The banking professional knowledge base includes a dictionary, data items, and code value definitions corresponding to the data items. The dictionary includes a root word dictionary and a terminology dictionary.

[0194] The physical conversion module 30 is used to acquire banking data to be processed and, through the banking professional knowledge base, translate the data logic model corresponding to the banking data into the data physical model corresponding to the banking data.

[0195] The statement generation module 40 is used to generate modeling statements adapted to each of the databases based on the data physical model.

[0196] The statement execution module 50 is used to input the modeling statement into the database environment corresponding to each of the databases for execution, obtain a comprehensive execution result, and use the comprehensive execution result as the result of analysis and processing of banking data.

[0197] Optionally, the physical conversion module 30 is also used for:

[0198] Using the banking professional knowledge base, the data logic model corresponding to the banking data is initialized and marked, and a preset label-guided confirmation interface is output.

[0199] Upon receiving a confirmation instruction input in response to the label-guided confirmation interface, multiple preset target attributes corresponding to the banking data are generated based on the initialized data logic model. The preset target attributes include business labels and data distribution patterns.

[0200] Based on the preset target attributes corresponding to the banking data, the data physical model corresponding to the banking data is determined.

[0201] Optionally, the physical conversion module 30 is also used for:

[0202] Based on the preset target attributes corresponding to the banking data, business compliance indicators matching the banking data are retrieved from the banking professional knowledge base. The business compliance indicators include the value range information, security compliance information, and regulatory requirement information corresponding to the preset target attributes.

[0203] Based on the aforementioned business compliance indicators, the banking data is deployed in a multi-cluster model to obtain the corresponding data physical model.

[0204] Optionally, the statement generation module 40 is also used for:

[0205] Obtain the database characteristics corresponding to each of the databases, and optimize and supplement the data physical model according to the database characteristics corresponding to each of the databases to obtain the target physical model that is adapted to each of the databases.

[0206] Based on the target physical model adapted to each of the databases, modeling statements adapted to each of the databases are generated;

[0207] The model optimization includes optimizing the field information, primary key and distribution key information of the data physical model, and the configuration supplement includes supplementing the lifecycle, storage type and sharding rules of the data physical model.

[0208] Optionally, the statement execution module 50 is also used for:

[0209] The modeling statement is input into the database environment corresponding to each database, and the model execution instruction information corresponding to each database environment is output. The database environment includes database type information, and the model execution instruction information is to create a new model or modify a model.

[0210] The statement strategy adapted to the instruction information of each model is executed to obtain the comprehensive execution result.

[0211] Optionally, the banking data processing system also includes a semantic specification checking module (not shown), which is used for:

[0212] A standardization check was performed on the data logic model corresponding to the aforementioned banking data;

[0213] The non-standard information identified during the standardization check is corrected and updated in the data logic model corresponding to the banking data.

[0214] Optionally, the physical conversion module 30 is also used for:

[0215] Obtain the mapping source banking business data of the end-to-end input;

[0216] By using the mapped source banking business data, combined with fact model design and dimensional model design, core data of the banking industry's data warehouse is obtained through screening and analysis.

[0217] The core data of the data warehouse is used as banking data to be processed.

[0218] In addition, this application also provides a terminal device, the terminal device including: a memory, a processor, and a banking data processing program stored in the memory and executable on the processor, wherein when the banking data processing program is executed by the processor, it implements the steps of the banking data processing method described above.

[0219] The specific embodiments of the terminal equipment in this application are basically the same as the embodiments of the above-mentioned banking data processing methods, and will not be described in detail here.

[0220] In addition, this application also provides a computer-readable storage medium storing a banking data processing program, which, when executed by a processor, implements the steps of the banking data processing method as described in any of the above embodiments.

[0221] The specific embodiments of the computer-readable storage medium in this application are basically the same as the embodiments of the above-described banking data processing methods, and will not be described in detail here.

[0222] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0223] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0224] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0225] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for processing banking data, characterized in that, The methods for processing the banking data include: By using a unified syntax standard, database modeling requirements information for multiple different databases can be generated; Based on the database modeling requirements of each database and combined with a unified logical modeling structure, a banking professional knowledge base is established. The banking professional knowledge base includes a dictionary, data items, and code value definitions corresponding to the data items. The dictionary includes a root word dictionary and a terminology dictionary. The process involves acquiring banking data to be processed and translating the data logic model corresponding to the banking data into a data physical model corresponding to the banking data using the banking professional knowledge base. Based on the data physical model, generate modeling statements adapted to each of the databases; The modeling statement is input into the database environment corresponding to each of the databases and executed to obtain a comprehensive execution result. The comprehensive execution result is used as the result of analysis and processing of banking data. The step of translating the data logic model corresponding to the banking data into the data physical model corresponding to the banking data through the banking professional knowledge base includes: Using the banking professional knowledge base, the data logic model corresponding to the banking data is initialized and marked, and a preset label-guided confirmation interface is output. Upon receiving a confirmation instruction input in response to the label-guided confirmation interface, multiple preset target attributes corresponding to the banking data are generated based on the initialized data logic model. The preset target attributes include business labels and data distribution patterns. Based on the preset target attributes corresponding to the banking data, the data physical model corresponding to the banking data is determined.

2. The method for processing banking data as described in claim 1, characterized in that, The step of determining the data physical model corresponding to the banking data based on each of the preset target attributes includes: Based on the preset target attributes corresponding to the banking data, business compliance indicators matching the banking data are retrieved from the banking professional knowledge base. The business compliance indicators include the value range information, security compliance information, and regulatory requirement information corresponding to the preset target attributes. Based on the aforementioned business compliance indicators, the banking data is deployed in a multi-cluster model to obtain the corresponding data physical model.

3. The method for processing banking data as described in claim 1, characterized in that, The step of generating modeling statements adapted to each of the databases based on the data physical model includes: Obtain the database characteristics corresponding to each of the databases, and optimize and supplement the data physical model according to the database characteristics corresponding to each of the databases to obtain the target physical model that is adapted to each of the databases. Based on the target physical model adapted to each of the databases, modeling statements adapted to each of the databases are generated; The model optimization includes optimizing the field information, primary key and distribution key information of the data physical model, and the configuration supplement includes supplementing the lifecycle, storage type and sharding rules of the data physical model.

4. The method for processing banking data as described in claim 3, characterized in that, The step of inputting the modeling statement into the database environment corresponding to each of the databases for execution and obtaining the comprehensive execution result includes: The modeling statement is input into the database environment corresponding to each database, and the model execution instruction information corresponding to each database environment is output. The database environment includes database type information, and the model execution instruction information is to create a new model or modify a model. The statement strategy adapted to the instruction information of each model is executed to obtain the comprehensive execution result.

5. The method for processing banking data as described in any one of claims 1 to 4, characterized in that, Before the step of translating the data logic model corresponding to the banking data into the data physical model corresponding to the banking data, the method further includes: A standardization check was performed on the data logic model corresponding to the aforementioned banking data; The non-standard information identified during the standardization check is corrected and updated in the data logic model corresponding to the banking data.

6. The method for processing banking data as described in any one of claims 1 to 4, characterized in that, The steps for obtaining banking data to be processed include: Obtain the mapping source banking business data of the end-to-end input; By using the mapped source banking business data, combined with fact model design and dimensional model design, core data of the banking industry's data warehouse is obtained through screening and analysis. The core data of the data warehouse is used as banking data to be processed.

7. A banking data processing system, characterized in that, The system includes: The semantic definition module is used to generate database modeling requirements information for multiple different databases through a unified syntax specification; The logic design module is used to establish a banking professional knowledge base based on the database modeling requirements of each database and in combination with a unified logic modeling structure. The banking professional knowledge base includes a dictionary, data items, and code value definitions corresponding to the data items. The dictionary includes a root word dictionary and a terminology dictionary. The physical conversion module is used to acquire banking data to be processed and, through the banking professional knowledge base, translate the data logic model corresponding to the banking data into the data physical model corresponding to the banking data. The statement generation module is used to generate modeling statements adapted to each of the databases based on the data physical model; The statement execution module is used to input the modeling statement into the database environment corresponding to each of the databases for execution, obtain a comprehensive execution result, and use the comprehensive execution result as the result of analysis and processing of banking data; The physical conversion module is also used for: Using the banking professional knowledge base, the data logic model corresponding to the banking data is initialized and marked, and a preset label-guided confirmation interface is output. Upon receiving a confirmation instruction input in response to the label-guided confirmation interface, multiple preset target attributes corresponding to the banking data are generated based on the initialized data logic model. The preset target attributes include business labels and data distribution patterns. Based on the preset target attributes corresponding to the banking data, the data physical model corresponding to the banking data is determined.

8. A terminal device, characterized in that, The terminal device includes: a memory, a processor, and a banking data processing program stored in the memory and executable on the processor. When the banking data processing program is executed by the processor, it implements the steps of the banking data processing method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a processing program for banking data, which, when executed by a processor, implements the steps of the banking data processing method as described in any one of claims 1 to 6.

Images