A data standard automatic governance method and platform for a credit card system

Abstract

The application relates to the technical field of financial technology, and particularly discloses a data standard automatic management method and platform for a credit card system, wherein the method comprises the following steps: in response to a DDL script in a table building request submitted by a user, generating a table structure record in a to-be-reviewed state after analyzing and standard checking the DDL script; in response to a review rejection operation, extracting a historical snapshot record in a passed state for the last time; when the historical snapshot record in the passed state exists, performing coverage recovery on the table structure record in the to-be-reviewed state; when the historical snapshot record in the passed state does not exist, updating the state to a rejection state without a historical version; in response to a review passing operation, updating the state to a to-be-executed state; and in response to an execution confirmation operation, changing the table structure record in the to-be-executed state into an incremental ALTER DDL script and issuing the script for execution, and updating the state to a passed state after successful execution.

Description

Technical Field

[0001] This invention relates to the field of financial technology, specifically to an automatic data standard governance method and platform for credit card systems. Background Technology

[0002] Credit card systems typically feature long business chains, numerous data objects, multiple historical systems, frequent data field reuse, and high regulatory compliance requirements. A complete credit card business platform may simultaneously include multiple subsystems such as application processing, customer information, card management, account management, credit limit management, billing, transaction authorization, clearing and settlement, repayment, installment payments, collection, risk control, marketing, and points. Over long-term evolution, different subsystems are prone to issues such as inconsistent naming of fields with the same business meaning, inconsistent lengths of the same field type, inconsistent meanings of enumeration values, lack of version records for table structure changes, and reliance on manually written change scripts.

[0003] For example, the "customer number" might be named customer_id, cust_id, or client_no in different systems; the "currency" might be CNY / USD in one system and 156 / 840 in another; and the "transaction status" field might have duplicate definitions or semantic discrepancies in the enumeration values ​​across the authorization, billing, and clearing systems. If these differences are not addressed uniformly, they will pose significant risks to data warehouse construction, regulatory reporting, data quality checks, cross-system reconciliation, interface integration, and production changes.

[0004] To address the above issues, existing solutions mainly include: (1) Manual registration data dictionary: The development or data management personnel register field information in tables, documents or ordinary databases, and the reviewers manually compare the field standards.

[0005] (2) General metadata management system: collects metadata through database connection or script, and displays information such as tables, fields, lineage, and tags, but usually does not focus on the approval and execution closed loop of credit card business data standards.

[0006] (3) Database DDL Difference Tool: Generates change scripts by comparing two table creation scripts or two database instances. It focuses on structural differences and does not have field standard validation, Chinese semantic matching, or business approval process.

[0007] (4) Role-based workflow approval system: It can realize the processes of submission, approval, rejection, etc., but usually does not understand DDL structure, field identity and standard field rules.

[0008] (5) Enumeration value management table: The enumeration values ​​are manually entered and maintained in groups, but there is no mechanism to automatically generate hierarchical codes based on the English names of fields, reuse the first-level codes, and automatically increment the second-level serial numbers.

[0009] However, existing technical solutions still have the following problems: (1) Field standard validation relies on human experience. The existing manual method can only check the field name, type, length and comments one by one. It is difficult to find fields with similar but not completely consistent names in a large number of credit card table structures, which easily leads to omissions and errors in validation.

[0010] (2) Comparing structural differences solely by field name cannot accurately identify renaming. Traditional DDL difference tools or simple text comparison methods usually treat field names as field identities. Once the English name of a field changes, the same field may be mistakenly identified as the deletion of an old field and the addition of a new field, leading to the risk of data loss in production change scripts.

[0011] (3) It is difficult to balance the performance and consistency of standard field queries. If the database is accessed for each validation, the database pressure will be high during batch import and validation of a large number of fields; if only simple caching is used, the database may not be refreshed in time after the standard fields are added or modified.

[0012] (4) Disconnect between approval and technical changes. Many platforms still require manual writing of ALTER SQL after approval, and the approval object and the final execution script are inconsistent, making it impossible to guarantee that the review results are consistent with the actual changes.

[0013] (5) Lack of versioned snapshots and rejection recovery. Existing systems often only save the current state and lack table-level and field-level snapshots after each review; when a modification is rejected, it cannot be automatically restored to the last valid version.

[0014] (6) The enumeration standard lacks a unified coding rule. Multiple enumeration values ​​for the same field may be managed separately, and there is a lack of interpretable relationship between the first-level code, the second-level sequence number and the standard number.

[0015] (7) Incomplete audit evidence. Traditional operation logs only record "who did what" and do not fully save the JSON before and after the change, operator IP, system code, business object, module type and operation time, which makes it difficult to meet the internal control tracking requirements of the financial system. Summary of the Invention

[0016] To address the aforementioned issues, the purpose of this invention is to provide an automated data standard governance method and platform for credit card systems. This platform can be used to uniformly register, parse, verify, approve, version-store, generate incremental changes, and audit trace data table structures such as customers, cards, accounts, credit limits, bills, transactions, installments, authorizations, repayments, collections, points, and risk control within the credit card system.

[0017] This invention provides an automatic data standard governance method for credit card systems, comprising: Pending review status construction: In response to the DDL script in the table creation request submitted by the user, after parsing and standardizing the DDL script, a table structure record for the pending review status is generated; the table structure record includes a list of fields; Review rejection branch: In response to the review rejection operation, extract the most recent historical snapshot record that was in the "passed" state; When a historical snapshot record of a passed status exists, the table structure record of the pending review status is overwritten and restored using the ID field and metadata in the historical snapshot record, and the status of the table structure record of the pending review status is reset to the status before the review rejection. If there is no historical snapshot record of the passed state, then the status of the table structure record of the state to be reviewed is updated to the rejection state with no historical version. Review passed branch: In response to the review passed operation, the status of the table structure record is updated to the pending execution status, and a table structure snapshot and field snapshot of the current version are generated simultaneously; the field snapshot contains the field ID; In response to the confirmation operation, the table structure record change in the pending execution state is converted into an incremental ALTERDDL script and sent for execution. After successful execution, the status of the table structure record in the pending execution state is updated to the passed status.

[0018] In one possible implementation, the deletion branch: in response to a user's request to delete a table structure record in the pending review state, the status of the table structure record in the pending review state is updated to a pending deletion state, and the table structure record in the pending deletion state is saved as a recovery base point. In response to the deletion confirmation operation, delete the table structure records in the pending deletion state; In response to a deletion rejection operation, the state of the table structure record to be deleted is reset to the state before the deletion rejection.

[0019] In one possible implementation, the step of generating a table structure record for the pending review status after parsing and standardizing the DDL script includes: DDL script parsing: Remove redundant newline characters and spaces from the DDL script to obtain the normalized DDL text; Locate the field definitions of the table creation statements in the standardized DDL text, split the field definitions, and maintain a bracket level counter during splitting to ignore commas inside the data type definitions; extract the field ID and metadata of each field; the metadata includes at least the database field name, English field name, Chinese field name, field type, field length, and decimal precision; For each field, perform the following steps: Standard field three-index construction: Load the corresponding English field name, database field name, and Chinese field name into the memory cache; Standardization verification: Based on the standard field library, perform database field name or English field name exact match, Chinese field name exact match, English field name fuzzy match, and Chinese field name fuzzy match in sequence; If any standard field in the standard field library is matched, the consistency of the field type, field length and decimal precision is further verified, and the standardization verification result is generated. The parsed metadata of the fields is associated with the standardization verification results to generate a table structure record for the pending review status. If the current table creation request is determined to be a new request, a globally unique field ID is assigned to each field. If the current table creation request is determined to be a modification request, the original field ID is associated with the fields based on the historical snapshot record.

[0020] In one possible implementation, prior to the DDL script in response to the user-submitted table creation request, the following is also included: Verify the user's permissions; When the user does not have the necessary permissions, the DDL script will not be received and an insufficient permissions message will be returned. When the user has the necessary permissions, extract the English table names from the DDL script and query whether a table structure record with the same name exists in the system: If no record with the same table structure name is found, the submission is determined to be a new request; If a table structure record with the same name and a status of "passed" is found, then this submission is determined to be a modification request. If a record with the same name is found and its status is either pending review or pending execution, the submission will be rejected and a record conflict warning will be returned.

[0021] In one possible implementation, the step of converting the table structure record changes in the pending execution state into an incremental ALTER DDL script in response to the confirmation operation includes: Retrieve the field snapshots of the current version associated with the table structure records of the pending execution state, as well as the field snapshots of the historical versions associated with the modification baseline; Based on the field ID, establish a mapping relationship between the current version's field snapshot and the historical version's field snapshot associated with the modification baseline. Compare the metadata of the corresponding fields in the two snapshots and generate an incremental ALTER DDL script. Rename recognition: If the database field name or English field name corresponding to the same field ID is inconsistent in the two snapshots, a RENAME COLUMN statement will be generated; Attribute modification identification: If the field type, field length, decimal precision, non-null constraint, default value or comment information corresponding to the same field ID are inconsistent in the two snapshots, a MODIFY COLUMN statement will be generated. Added identification: If a field ID only exists in the current version's field snapshot, then an ADD COLUMN statement will be generated; Deletion identification: If a field ID only exists in the field snapshot of a historical version, then a DROP COLUMN statement is generated; The incremental ALTER DDL script is associated with the table structure record of the pending execution state for storage, so that it can be called for execution confirmation operation.

[0022] In one possible implementation, after generating the incremental ALTER DDL script, the process further includes: High-risk interception: Scan the incremental ALTER DDL script to identify any DROP COLUMN statements or MODIFY COLUMN statements that may cause data truncation. When a DROP COLUMN statement or a MODIFY COLUMN statement that may cause data truncation is detected, a high-risk warning message is generated and the issuance of the incremental ALTER DDL script is suspended until a secondary confirmation instruction for the warning is received. In response to the secondary confirmation command, the pause state is lifted, allowing the incremental ALTER DDL script to be issued and executed.

[0023] In one possible implementation, the step of using the ID and metadata fields in the historical snapshot record to perform overwrite recovery of the table structure record in the state to be reviewed includes: Extract the ID field and its corresponding metadata from the historical snapshot record; Iterate through the list of fields in the pending review status. For each field in the list, if its field ID exists in the historical snapshot record, then use the metadata in the historical snapshot record to overwrite and update the current attribute of the field; if its field ID does not exist in the historical snapshot record, then remove the field from the list of fields in the pending review status. Clear the ALTER DDL scripts associated with the table structure records in the pending review state to ensure that the restored data is completely consistent with the historical snapshot records.

[0024] In one possible implementation, the standard hierarchical encoding of the enumeration is as follows: in response to the registration request of the enumeration field, the English field name of the enumeration field is extracted, the English field name is split according to a preset separator, and the first letter of the first few words is extracted to form a prefix code. Based on the prefix code, query the largest existing first-level code that starts with the prefix code; If a maximum level code exists, extract the numeric part of the maximum level code that is located after the prefix code, add 1 to the numeric part and concatenate it back to the prefix code to generate the current level code; If the maximum first-level code is not found, the prefix code is concatenated with the initial number sequence to generate the initial first-level code; Based on the current first-level code, query the existing largest second-level sequence number that starts with the current first-level code; If a maximum second-level sequence number exists, extract the numerical part of the maximum second-level sequence number that is located after the current first-level code, add 1 to the numerical part, and generate the current second-level sequence number; If the maximum second-level sequence number is not found, an initial second-level sequence number is generated based on the current first-level code and the preset initial number sequence. The current first-level code and the current second-level sequence number are concatenated to generate the standard hierarchical code of the enumeration field, and the standard hierarchical code is associated with and stored with the field ID of the enumeration field.

[0025] In one possible implementation, the audit trail involves recording an operation log when a state transition occurs in a table structure record. The operation log includes the module type, operation type, business object ID, business object name, JSON data before the change, JSON data after the change, operator, operator IP address, system code, and operation time. The acquisition of the operator's IP address follows a preset priority. The X-Forwarded-For, X-Real-IP, Proxy-Client-IP, WL-Proxy-Client-IP, HTTP_CLIENT_IP, and HTTP_X_FORWARDED_FOR header information are parsed sequentially, and the first valid address is taken from the multi-level proxy IP.

[0026] This invention also provides an automatic data standard governance platform for credit card systems, which executes any of the above-described automatic data standard governance methods, including: The metadata access module is used to respond to the DDL script in the table creation request submitted by the user. The DDL structure semantic parsing module is used to parse the DDL script; The similarity verification module is used to verify the parsed DDL script and generate a table structure record in the pending review status; the table structure record includes a list of fields. The Field Identity Snapshot module is used to extract historical snapshot records that were last approved in response to review rejection operations; When a historical snapshot record of a passed status exists, the table structure record of the pending review status is overwritten and restored using the ID field and metadata in the historical snapshot record, and the status of the table structure record of the pending review status is reset to the status before the review rejection. If there is no historical snapshot record of the passed state, then the status of the table structure record of the state to be reviewed is updated to the rejection state with no historical version. In response to the approval operation, the status of the table structure record is updated to the pending execution status, and a snapshot of the table structure and field snapshots of the current version are generated simultaneously; the field snapshots contain field IDs; The incremental ALTER DDL generation module is used to respond to the execution confirmation operation by converting the table structure record changes in the pending execution state into an incremental ALTER DDL script and sending it for execution. After successful execution, the status of the table structure record in the pending execution state is updated to the passed status.

[0027] The present invention provides an automatic data standard governance method and platform for credit card systems, which enables the platform to automatically parse table structure DDL, automatically match standard fields, automatically verify field standards, generate incremental change statements based on field identity, realize version tracking and rejection recovery based on approval snapshots, and form an auditable, traceable and batch-processable data standard governance closed loop throughout the entire process. Attached Figure Description

[0028] Figure 1 A flowchart illustrating the automatic data standard governance method provided for embodiments of the present invention; Figure 2 The overall architecture diagram of the automatic data standard governance platform provided in the embodiments of the present invention; Figure 3 A flowchart illustrating the closed-loop process of table structure governance and approval execution provided in this embodiment of the invention; Figure 4 A flowchart of incremental ALTER DDL generation for field identity awareness provided in this embodiment of the invention; Figure 5 A flowchart for standard field matching and standardization verification provided for embodiments of the present invention; Figure 6 This is a schematic diagram illustrating the generation of the standard hierarchical encoding for credit card enumeration provided in an embodiment of the present invention. Detailed Implementation

[0029] The embodiments of the present invention will be further described in detail below with reference to the accompanying drawings and examples. The following detailed description of the embodiments and the accompanying drawings are used to illustrate the principles of the present invention by way of example, but should not be used to limit the scope of the present invention. That is, the present invention is not limited to the described preferred embodiments, and the scope of the present invention is defined by the claims.

[0030] In the description of this invention, it should be noted that, unless otherwise stated, "a plurality of" means two or more; the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance; those skilled in the art can understand the specific meaning of the above terms in this invention as appropriate.

[0031] To facilitate understanding, the terminology involved in this invention will first be explained.

[0032] To clearly define the scope of protection of this invention, the following core terms are first explained in a unified manner: 1. Table structure records A table structure record is a data representation of the overall framework used in a database to define data storage logic within a computer system. It is the top-level container that carries business data, corresponding to a specific business table (such as the "account table" or "transaction table") in a credit card system.

[0033] Components: The table structure record mainly consists of table attributes and a field list. Table attributes include the English table name, Chinese table name, system code, data source type, and the core state machine status of this invention (such as pending review, approved, etc.). The field list is a collection of all fields attached to this table structure.

[0034] Function: Table structure records are the primary carriers of approval processes, snapshot version management, and access control. The "table structure records in a pending review status" mentioned in this application refer to data entities that contain the aforementioned list of attributes and fields and are awaiting review.

[0035] 2. Fields A field is a constituent unit of a table structure, corresponding to a column in a business table, and in this application, it is represented as a single entry in the field list. It is the smallest data carrier of specific business meaning (e.g., "customer number" and "balance" in the "account table").

[0036] Components: Each field has a unique field ID and a series of data describing its characteristics (i.e., metadata). Fields are tracked across versions through the "field ID" and are associated with the parent table structure through the "belonging table structure ID".

[0037] Function: Fields are the direct objects of standardization verification and the basic units for difference comparison during incremental DDL generation. This application distinguishes between field renaming (ID remains the same, name changes) and deletion and reconstruction (ID changes, name remains the same) by locking the field ID.

[0038] 3. Field List A field list is an ordered collection of all fields under a specific table structure, which in this application is represented as a dataset attached to a "table structure record". It is not an isolated entity, but a core component of the table structure record.

[0039] Components: Composed of several fields arranged in a certain logical order (such as field sort number, primary key priority, etc.). In version snapshots, the list of fields is fixed as a whole.

[0040] Function: The field list serves as a bridge connecting the table structure and specific fields. In approval processes, the system often operates on the entire field list (e.g., submitting a list, restoring a list); in snapshot management, the system saves a complete image of the field list at a specific point in time. For example, in this application, "restoring the field list using historical snapshots" means overwriting the current field set with the entire set of fields fixed in the historical version.

[0041] 4. Metadata Metadata is data that describes data; in this application, it specifically refers to a structured collection of data that describes the characteristics and attributes of fields. It is not an entity independent of the table structure and fields, but rather specific descriptive information attached to the fields.

[0042] Components include, but are not limited to, database field names, English field names, Chinese field names (comments), field types, field lengths, decimal precision, whether they are NOT nullable, default values, whether they are primary keys, and enumeration value definitions.

[0043] Purpose: Metadata serves as the basis for standardization verification (the content compared with the standard field library) and is also the source of parameters for generating ALTER DDL scripts. For example, when this application mentions "extracting the metadata of fields," it means extracting the aforementioned attribute values ​​for logical judgment.

[0044] 5. Field ID The field ID specifically refers to a stable identifier used to uniquely identify fields across versions, preferably a database auto-incrementing ID or a globally unique identifier (UUID). It is fundamentally different from the "field's English name" or "database field name": the former is the field's internal identity card, while the latter is its external name. As long as the ID remains unchanged, even if the field name is modified to any value, the system will still treat it as the same field. This is the core basis for this invention to achieve "rename recognition" rather than misjudgment based on "deletion + addition".

[0045] Figure 2 This is a diagram illustrating the overall architecture of the automatic data standard governance platform provided in this embodiment of the invention. The invention can be composed of a browser front-end, back-end services, a relational database, and optional deployment components. The back-end services can be implemented using technologies such as Spring Boot, MyBatis, MySQL, Spring Security, JWT, and Apache POI.

[0046] 1. Metadata Access Module This module is used to respond to DDL scripts in user-submitted table creation requests. Access methods include single-table interface registration, automatic DDL parsing registration, and batch import from Excel. This module is the system's physical entry point.

[0047] 2. DDL Structure and Semantic Parsing Module Used for parsing DDL scripts. Its core function is to handle complex data types (such as DECIMAL(18,2)), accurately extracting field definitions by maintaining a bracket level counter, and avoiding parsing errors caused by internal commas.

[0048] 3. Standard Field Three-Index Caching Module This is used to load the corresponding English field names, database field names, and Chinese field names into the memory cache. By creating an in-memory index, the database query is avoided for each validation, significantly improving batch processing performance.

[0049] 4. Similarity Standard Verification Module This module is used to perform standardization verification on the parsed DDL script and generate table structure records in the pending review status. It implements a mechanism of "precise matching first, fuzzy matching as a fallback".

[0050] 5. Table-structured approval status machine module It is used to control the status flow of table structure records in the credit card system. The statuses it manages include at least: pending review, pending execution, approved, rejected, and pending deletion of approval. It serves as the scheduling center for the entire business process.

[0051] 6. Field Identity Snapshot Module This is used to retrieve the most recent historical snapshot record that was in a "passed" state in response to a review rejection operation; or to synchronously generate a current version of the table structure snapshot and field snapshots in response to a review approval operation. The field snapshot contains a field ID, which is the core of this invention for achieving field renaming identification.

[0052] 7. Incremental ALTER DDL generation module This module is used to respond to confirmation operations, converting changes to table structure records in the pending execution state into incremental ALTERDDL scripts and issuing them for execution. It performs difference comparisons based on field IDs rather than field names, thereby generating precise scripts such as RENAMECOLUMN.

[0053] 8. Enumerate standard hierarchical coding modules Used to generate standard hierarchical encoding in response to registration requests for enumeration fields. A three-part structure—prefix code, first-level encoding, and second-level sequence number—enables interpretability and scalability of enumeration values.

[0054] 9. Permission Context and System Isolation Module Used to verify user permissions. JWT tokens are used to parse the system code to which the user belongs, achieving multi-tenant data isolation and ensuring that users in system A cannot access data in system B.

[0055] 10. Operation Log and Audit Traceability Module This is used to record operation logs containing both the JSON before and after the change when the table structure records a state transition, meeting financial-grade compliance audit requirements.

[0056] Specifically, the present invention provides an automatic data standard governance platform for credit card systems, which executes any of the following automatic data standard governance methods: The metadata access module is used to respond to the DDL script in the table creation request submitted by the user. The DDL structure semantic parsing module is used to parse DDL scripts; The similarity verification module is used to verify the parsed DDL script and generate table structure records in the pending review status; the table structure records include a list of fields. The Field Identity Snapshot module is used to extract the most recent historical snapshot record in the "passed" state in response to a review rejection operation. When a historical snapshot record in the "passed" state exists, the field ID and metadata in the historical snapshot record are used to overwrite and restore the table structure record in the "to be reviewed" state, and the state of the table structure record in the "to be reviewed" state is reset to the state before the review rejection. When no historical snapshot record in the "passed" state exists, the state of the table structure record in the "to be reviewed" state is updated to the "rejected" state with no historical version. In response to a review pass operation, the state of the table structure record is updated to the "pending execution" state, and the current version of the table structure snapshot and field snapshot are generated simultaneously. The field snapshot contains the field ID. The incremental ALTER DDL generation module is used to respond to the execution confirmation operation by converting the changes to the table structure records in the pending state into incremental ALTER DDL scripts and sending them for execution. After successful execution, the status of the table structure records in the pending state is updated to the passed status.

[0057] One possible approach also includes: a standard field three-index cache module, used to load the English field name, database field name and Chinese field name corresponding to the field into the memory cache; The table structure approval state machine module is used to control the state of table structure records in the credit card system. The enumeration standard-level encoding module is used to respond to registration requests for enumerated fields. It extracts the English field name of the enumerated field, splits the English field name according to a preset separator, and extracts the first letter of the first few words to form a prefix code. Based on the prefix code, it queries for the largest existing first-level code starting with the prefix code. If a largest first-level code exists, it extracts the numeric part after the prefix code from the largest first-level code, adds 1 to the numeric part, and concatenates it back to the prefix code to generate the current first-level code. If no largest first-level code is found, it concatenates the prefix code with the initial numeric sequence to generate the initial first-level code. Based on the current first-level code, it queries for the largest existing second-level sequence number starting with the current first-level code. If a largest second-level sequence number exists, it extracts the numeric part after the current first-level code from the largest second-level sequence number, adds 1 to the numeric part, and generates the current second-level sequence number. If no largest second-level sequence number is found, it generates the initial second-level sequence number based on the current first-level code and the preset initial numeric sequence. Finally, it concatenates the current first-level code and the current second-level sequence number to generate the standard-level encoding of the enumerated field and associates this standard-level encoding with the field ID of the enumerated field for storage.

[0058] The permission context and system isolation module is used to verify user permissions. When a user lacks permissions, the DDL script is rejected and an insufficient permission message is returned. When a user has permissions, the English table names in the DDL script are extracted, and the system is queried to see if a table structure record with the same name exists. If no table structure record with the same name is found, the submission is determined to be a new request. If a table structure record with the same name and a status of "approved" is found, the submission is determined to be a modification request. If a table structure record with the same name and a status of "pending review" or "pending execution" is found, the submission is rejected and a record conflict message is returned.

[0059] The operation log and audit traceability module is used to record operation logs when a state transition occurs in the table structure. The operation log includes module type, operation type, business object ID, business object name, JSON data before change, JSON data after change, operator, operator IP address, system code, and operation time. Among them, the operator IP address is obtained according to a preset priority. The X-Forwarded-For, X-Real-IP, Proxy-Client-IP, WL-Proxy-Client-IP, HTTP_CLIENT_IP, and HTTP_X_FORWARDED_FOR header information are parsed in sequence, and the first valid address is taken from the multi-level proxy IPs.

[0060] The main data objects of the data standard automatic governance platform include: user table, table structure information table, table field information table, standard field table, enumerated standard table, table structure snapshot table, field snapshot table, system configuration table, system announcement table, and operation log table. Among them, table structure snapshots and field snapshots are used to save the valid version after each review; the field snapshots save the original field IDs, which are used to identify the field identity in subsequent versions.

[0061] Figure 1 A flowchart illustrating the automatic data standard governance method provided in the embodiments of the present invention. Figure 3 The table structure governance and approval execution closed-loop flowchart provided in this embodiment of the invention, combined with Figure 1 and 3 This invention provides an automatic data standard governance method for credit card systems, comprising: Step S1, Construction of the pending review status: In response to the DDL script in the user's table creation request, the DDL script is parsed and verified to generate the table structure record of the pending review status. (This step is executed collaboratively by the metadata access module, the DDL structure semantic parsing module, the similarity standard verification module, and the table structure approval state machine module. See "Detailed Explanation of Step S1" below for more information.) Step S2, Review Rejection Branch: In response to the review rejection operation, extract the most recent historical snapshot record that was in the "passed" state; (This step is triggered by the table structure approval state machine module and executed by the field identity snapshot module. See "Detailed Explanation of Step S2" below for more information.) Step S3: When there is a historical snapshot record of the passed status, use the ID field and metadata in the historical snapshot record to overwrite and restore the table structure record of the status to be reviewed, and reset the status of the table structure record of the status to be reviewed to the status before the review rejection. (This step is performed by the Field Identity Snapshot module. The core of this step is to use the field ID for precise overwriting, rather than simply matching field names. See "Detailed Explanation of Step S3" below for more information.) Step S4: When there is no historical snapshot record of the passed status, the status of the table structure record of the status to be reviewed is updated to the rejection status with no historical version. (This step is executed by the table structure approval state machine module) Step S5, Review Passed Branch: In response to the review passed operation, the status of the table structure record is updated to the pending execution status, and a table structure snapshot and field snapshot of the current version are generated simultaneously; the field snapshot contains the field ID; (This step is driven by the table structure approval state machine module, and the field identity snapshot module performs the solidification operation.) Step S6: In response to the execution confirmation operation, the table structure record change in the pending execution state is converted into an incremental ALTERDDL script and sent for execution. After successful execution, the status of the table structure record in the pending execution state is updated to the passed status.

[0062] (This step generates a script from the incremental ALTER DDL generation module, and is then sent out after being verified by high-risk interception logic. See "Detailed Explanation of Step S6" below for more information.) The following is a detailed explanation of step S1.

[0063] Figure 5 This is a flowchart illustrating the standard field matching and compliance verification process provided for embodiments of the present invention. The table structure records include a list of fields.

[0064] First, permission and type determination (performed by the permission context and system isolation module and the table structure approval state machine module): In one possible implementation, before responding to the DDL script in the user-submitted table creation request, the following steps are also included: verifying the user's permissions; if the user does not have permissions, rejecting the DDL script and returning a permission insufficient message; if the user has permissions, extracting the English table name from the DDL script and querying whether a table structure record with the same name exists in the system; if no table structure record with the same name is found, then the submission is determined to be a new request; if a table structure record with the same name and a status of "approved" is found, then the submission is determined to be a modification request; if a table structure record with the same name and a status of "pending review" or "pending execution" is found, then the submission is rejected and a record conflict message is returned.

[0065] In one example, the permission context and system isolation module parses the user ID, username, role, and associated system code using a JWT token and saves it to the thread context. The platform performs data isolation based on roles and system codes. (1) Administrators can query and manage data from all systems; (2) Review users and ordinary users can only query, create, modify, and delete data in this system; (3) Review and execution operations are only permitted to be performed by administrators or review users; (4) Reviewing users can only review or execute data within this system; (5) Clean up the thread context after the operation is completed to avoid context interference caused by thread reuse.

[0066] The permission context and system isolation module is suitable for multi-system and multi-team collaboration scenarios in the credit card industry, ensuring that data standard assets of different business systems are isolated from each other.

[0067] Secondly, DDL parsing (performed by the DDL structure semantic parsing module): DDL script parsing: Remove redundant line breaks and spaces from the DDL script to obtain normalized DDL text. Locate the field definitions of table creation statements in the normalized DDL text, split the field definitions, and maintain a bracket level counter during splitting to ignore commas inside data type definitions; extract the field ID and metadata of each field; the metadata includes at least the database field name, English field name, Chinese field name, field type, field length, and decimal precision.

[0068] In one example, the DDL structure semantics parsing module is used to convert table creation statements into structured field objects. Its processing steps include: S301: Receives the DDL string, removes newline characters, merges extra spaces, and forms a standardized DDL text; S302: Locate the field definition area using the CREATE TABLE statement, i.e., the content within the outermost parentheses; S303: Field definitions are split by commas, but the bracket level count is maintained during splitting. If a comma is inside brackets such as DECIMAL(18,2), it is not used as a split point. S304: Skip constraint definitions such as PRIMARY KEY, KEY, UNIQUE KEY, INDEX, CONSTRAINT, FOREIGN KEY, etc. S305: Extract information such as the English name of a regular field, field type, field length, whether it is NOT NULL, default value, and COMMENT comment from the field definition. S306: If COMMENT exists, then COMMENT will be used as the Chinese name and description of the field; if COMMENT does not exist, then the English name of the field will be used as the default Chinese name and description. S307: Determine if a field is a primary key by using an inline PRIMARY KEY or table-level PRIMARY KEY(field) constraint; S308: Generate field sorting sequence number and mark the field by default as eligible for standardization verification.

[0069] Through the above processing, the present invention can automatically convert common MySQL table creation statements in credit card systems into a standardized list of fields, reducing the cost of manually entering field attributes.

[0070] In a preferred implementation, in addition to regular expression and bracket-level parsing, a dedicated SQL Parser component can be used to parse database dialects such as MySQL, Oracle, and PostgreSQL, and the parsing results can be uniformly mapped to the platform field model.

[0071] Next, standardization verification (performed by the standard field three index caching module and the similarity standardization verification module): In one possible implementation, after parsing and verifying the DDL script, the table structure record to be reviewed is generated by performing the following steps for each field: Standard field three-index construction: Load the corresponding English field name, database field name, and Chinese field name into the memory cache; Standardization verification: Based on the standard field library, perform database field name or English field name exact match, Chinese field name exact match, English field name fuzzy match, and Chinese field name fuzzy match in sequence; If any standard field in the standard field library is matched, the consistency of the field type, field length, and decimal precision is further verified, and a standardization verification result is generated; including: (1) Single table interface registration: Users submit information such as the English name of the table, the Chinese name of the table, the system to which it belongs, the data source, the field list, the DDL, and the applicant through the interface; (2) Automatic DDL parsing registration: When the submitted content does not explicitly include a field list, the platform automatically parses the CREATE TABLE DDL to obtain the field list; (3) Batch import of Excel: The platform provides an import template, which includes the English table name, Chinese table name, number of fields and table creation DDL. After reading the uploaded file, the platform parses the table information row by row and records the file name, size, content type, SHA-256 digest, total number of rows, number of successful rows and failure details.

[0072] For batch modeling scenarios in credit card systems, business personnel can import multiple tables such as account table, card table, transaction table, bill table, and repayment table into the platform at once, and then the platform will automatically decompose the fields and enter the review process.

[0073] In one example, the standard field three-index caching module loads the standard fields that are enabled into the memory cache and creates three indexes when the service starts or is manually refreshed: (1) Index of English field names: The key is the English name of the field converted to uppercase; (2) Database field name index: The database field name converted to uppercase is used as the key, and has higher priority than ordinary English field names; (3) Chinese field name index: using the Chinese name of the field as the key.

[0074] The platform prioritizes accessing the memory cache when validating fields, avoiding database queries for each field. When a standard field is added, modified, or deleted, the platform triggers a cache refresh, ensuring subsequent validations immediately use the latest standard. The three-index design accommodates three naming conventions in the credit card system: Chinese business names, English logical field names, and database physical field names, adapting to scenarios with inconsistent naming in existing systems.

[0075] In one example, the similarity standard verification module is used to determine whether the field to be registered meets the standard field requirements. The matching order is as follows: S501: Prioritize using database field names or English field names for exact matching; S502: If no match is found, use the Chinese field name for exact matching; S503: If no match is found, perform a fuzzy English match. S504: If the English fuzzy match fails, then perform the Chinese fuzzy match. S505: If a standard field is hit in any stage, proceed to consistency verification; otherwise, it is considered that the field has not yet hit the standard field library.

[0076] For English fuzzy matching, edit distance similarity can be used, calculated as: Similarity = (1 - Edit Distance / Maximum String Length) × 100. When the similarity reaches the first threshold, such as 75 points, the English field name is considered sufficiently similar to the standard field. For Chinese fuzzy matching, the similarity can be calculated using the ratio of character intersection to union, calculated as: Similarity = Number of Intersection Characters / Number of Union Characters × 100. When the similarity reaches the second threshold, such as 60 points, the Chinese field name is considered sufficiently similar to the standard field.

[0077] After the standard field is matched, the platform performs the following validations: (1) If a field is hit by the standard library but the user has not marked it as a standard, an error message will be returned; (2) Verify whether the field type is consistent with the standard field type; (3) Verify whether the field length is consistent with the standard field length; (4) When the field type is DECIMAL or NUMERIC, parse the decimal places in the field length and compare them with the standard decimal places; (5) If the standard field is hit by the Chinese name but the English name is inconsistent with the recommended database field name, a warning will be returned instead of a forced error.

[0078] This module implements a standardization mechanism that prioritizes precise matching, provides a fallback option for fuzzy matching, and layers errors and warnings. This ensures both the strength of standard control and compatibility with differences in field naming in the credit card history system.

[0079] In a preferred implementation, English similarity can be replaced by Jaro-Winkler, cosine similarity, n-gram similarity, or word root splitting similarity; Chinese similarity can be replaced by pinyin similarity, semantic vector similarity, or industry-specific thesaurus weight matching.

[0080] Finally, the record generation is associated with the ID field (executed by the table structure approval state machine module): The parsed field metadata is associated with the standardization verification results to generate a table structure record in the pending review status. If the current table creation request is determined to be a new request, a globally unique field ID is assigned to each field. If the current table creation request is determined to be a modification request, the original field ID is associated with the fields based on the historical snapshot record.

[0081] In one example, the table structure approval state machine module is used to control the lifecycle of credit card system table structure records from application to execution. Its states include at least: pending review, pending execution, approved, rejected, and pending deletion of approval.

[0082] When adding a new table structure, the platform executes the following process: S601: Verify whether the user has the right to create table structures under the target system; S602: Check if English table names are duplicated in the same system; S603: Save the main information of the table structure; S604: Save the field list; if the field list is empty, call the DDL parsing module. S605: Update the number of fields; S606: Record creation log; S607: Set the status to pending review.

[0083] When modifying the table structure, the platform executes the following process: S611: Query the data before modification and verify whether the user has the right to modify it; S612: Reset the status to pending review; S613: If the DDL changes, obtain the field list of the latest valid snapshot as the old field list; if no snapshot exists, obtain the old field list from the current field table. S614: Get the list of new fields; if empty, parse the new DDL. S615: Invoke the incremental ALTER DDL generation module to generate the change script; S616: Delete the old field and save the new field; S617: Save table structure record changes and incremental scripts; S618: Record update log.

[0084] The following is a detailed explanation of step S2.

[0085] The field identity snapshot module is a key technical feature that distinguishes this invention from ordinary DDL difference tools. Ordinary tools typically use the English name of a field as its identity, assuming that a change in the field name indicates the deletion of the old field and the addition of a new one. This invention saves the field ID in the field snapshot, which serves as the field's identity identifier. As long as subsequent submissions of new fields carry the original field ID, even if attributes such as the field's English name, Chinese name, type, and length change, the platform can still determine that they belong to the same field.

[0086] In one example, the field identity snapshot module includes: (1) Valid version creation: Each time the review is approved, an incrementing version number is generated, and table-level snapshots and field-level snapshots are saved; (2) Field identity preservation: Field-level snapshots preserve the original field IDs for cross-version tracking of field identities; (3) Historical compatibility: For data in historical snapshots where the ID field is empty, the platform can enable field name fallback comparison to ensure that historical data can still generate change scripts; (4) Rejection recovery: When the review is rejected, the platform restores the main table fields according to the latest snapshot to avoid polluting the valid version by the changes pending review.

[0087] The following is a detailed explanation of step S3.

[0088] In one possible implementation, overwrite recovery of the table structure records in the review state is performed using the ID and metadata of fields in the historical snapshot records, including: Extract the ID field and its corresponding metadata from historical snapshot records; Iterate through the list of fields in the pending review status. For each field in the list, if its field ID exists in the historical snapshot record, then use the metadata in the historical snapshot record to overwrite and update the current attribute of the field; if its field ID does not exist in the historical snapshot record, then remove the field from the list of fields in the pending review status. Clear the ALTER DDL scripts associated with the table structure records in the pending review state to ensure that the restored data is completely consistent with the historical snapshot records.

[0089] In a preferred implementation, when the standard field library is large, a two-level caching scheme of local caching plus distributed caching can be used; when deployed on multiple nodes, cache refresh events can be broadcast through message queues or configuration centers.

[0090] In a preferred implementation, in addition to using the database auto-incrementing field ID, the field identity can also use a globally unique field identifier, a field fingerprint, a field lineage ID, or a stable identifier generated by the table ID, field creation time, and field sequence number.

[0091] This method uses the field ID, not the field name, for overwriting. Even if the field name is changed to "temp_name", as long as the ID remains unchanged, the system can retrieve its original metadata. This is crucial to preventing unauthorized changes from corrupting the valid version. The following is a detailed explanation of step S4.

[0092] When a review rejection occurs, if a latest valid snapshot exists, the platform automatically restores the main table information and field information to that snapshot version and clears the pending ALTER DDL. If no snapshot exists, a rejection status with no historical version is recorded. Deletion operations are not immediately physically deleted; instead, the table is first placed under review for deletion, and the state before deletion is saved. If the deletion review is rejected, the state before deletion is restored. If the deletion review is approved, physical deletion is performed.

[0093] The following is a detailed explanation of step S5.

[0094] Upon successful review, the platform does not immediately mark the table structure as final approved. Instead, it first sets it to "pending execution" and creates table-level and field-level snapshots. The field-level snapshot saves the field ID, version number, field name, field type, field length, field description, whether it is a primary key, whether it is nullable, whether it adheres to standards, default value, and sort number. After the executor confirms execution, the status changes from "pending execution" to "approved." This design separates "business review" and "technical execution" into two steps, making it more suitable for production change management in credit card systems.

[0095] The following is a detailed explanation of step S6.

[0096] Figure 4 The flowchart for generating incremental ALTER DDL with field identity awareness provided in the embodiments of the present invention is shown.

[0097] In one possible implementation, in response to performing a confirmation operation, converting the table structure record changes in the pending execution state into an incremental ALTER DDL script includes: Retrieve snapshots of the fields in the current version associated with the table structure records in the pending execution state, as well as snapshots of the fields in the historical version associated with the modification baseline; Based on the field ID, establish a mapping relationship between the current version's field snapshot and the historical version's field snapshot associated with the modification baseline. Compare the metadata of the corresponding fields in the two snapshots and generate an incremental ALTER DDL script. Rename recognition: If the database field name or English field name corresponding to the same field ID is inconsistent in the two snapshots, a RENAME COLUMN statement will be generated; Attribute modification identification: If the field type, field length, decimal precision, non-null constraint, default value or comment information corresponding to the same field ID are inconsistent in the two snapshots, a MODIFY COLUMN statement will be generated. Added identification: If a field ID only exists in the current version's field snapshot, then an ADD COLUMN statement will be generated; Deletion identification: If a field ID only exists in the field snapshot of a historical version, then a DROP COLUMN statement is generated; The incremental ALTER DDL script is associated with the table structure record in the pending execution state for later use in the confirmation operation.

[0098] In one example, the incremental ALTER DDL generation module generates a minimal change statement based on the old and new field lists. The processing logic is as follows: S801: Map the old field list to oldById by field ID, and map the new field list to newById by field ID; S802: For the same ID field that exists in both the old and new versions, if the English names of the fields are different, a RENAMECOLUMN statement will be generated; S803: For the same field ID, if the attributes such as Chinese name, type, length, whether it is nullable, default value, whether it is a primary key, and field description change, a MODIFY COLUMN statement will be generated. S804: For fields where the old field ID exists but the new field ID does not exist, generate a DROP COLUMN statement; S805: For new field IDs that are empty or do not exist on the old field side, generate an ADD COLUMN statement; S806: For cases where the historical field does not have an ID field, use the field name as a fallback for deletion, modification, and addition.

[0099] The generated ADD / MODIFY statement can include field type, length, NOT NULL, default value, and COMMENT comment; the generated RENAME statement is used to rename a field; and the generated DROP statement is used to delete a field. By prioritizing field ID in the comparison, this invention can preserve the field's identity when renaming a field, preventing accidental deletion of production data.

[0100] In a preferred implementation, the platform can either generate only ALTER DDL for manual execution, or it can connect to a database change platform, execute automatically after approval, and write the execution result back to the platform.

[0101] In one possible implementation, after generating the incremental ALTER DDL script, the following is also included: High-risk interception: Scan incremental ALTER DDL scripts to identify DROP COLUMN statements or MODIFY COLUMN statements that may cause data truncation; when a DROP COLUMN statement or a MODIFY COLUMN statement that may cause data truncation is identified, a high-risk warning message is generated and the issuance of incremental ALTER DDL scripts is suspended until a secondary confirmation instruction for the warning is received; in response to the secondary confirmation instruction, the suspension state is lifted and the issuance and execution of incremental ALTER DDL scripts are allowed.

[0102] In one possible implementation, the method further includes: a deletion branch: in response to a user's deletion request for a table structure record in the pending review state, the status of the table structure record in the pending review state is updated to the pending deletion state, and the table structure record in the pending deletion state is saved as a recovery base point; in response to a deletion confirmation operation, the table structure record in the pending deletion state is deleted; in response to a deletion rejection operation, the status of the table structure record in the pending deletion state is reset to the state before the deletion rejection.

[0103] Figure 6 This is a schematic diagram illustrating the generation of the standard hierarchical encoding for credit card enumeration provided in an embodiment of the present invention. One possible implementation also includes: enumerating standard hierarchical codes: In response to the registration request of the enumeration field, extract the English field name of the enumeration field, split the English field name according to a preset separator, and extract the first letter of the first few words to form a prefix code; query the largest existing first-level code starting with the prefix code based on the prefix code; if a largest first-level code exists, extract the numeric part after the prefix code in the largest first-level code, add 1 to the numeric part and concatenate it back to the prefix code to generate the current first-level code; if no largest first-level code is found, concatenate the prefix code with the initial numeric sequence to generate the initial first-level code; query the largest existing second-level sequence number starting with the current first-level code based on the current first-level code; if a largest second-level sequence number exists, extract the numeric part after the current first-level code in the largest second-level sequence number, add 1 to the numeric part and generate the current second-level sequence number; if no largest second-level sequence number is found, generate the initial second-level sequence number based on the current first-level code and the preset initial numeric sequence; concatenate the current first-level code and the current second-level sequence number to generate the standard hierarchical code of the enumeration field, and associate and store the standard hierarchical code with the field ID of the enumeration field.

[0104] In one example, a credit card system has numerous fields with enumerated values, such as card status, transaction status, repayment method, bill type, channel type, currency, and whether / not specified. The enumeration standard hierarchy encoding module is used to generate interpretable and extensible standard numbers for these enumerated values. Its encoding methods include: S901: Based on the English name of the field, split it by underscores and take the first letters of the first few words to form a two-digit prefix; if it is less than two digits, take the first two digits of the first word. S902: Query the existing highest level code under the same prefix. If it does not exist, generate "prefix + 01"; if it exists, increment the numeric part. S903: If the same field's English name already exists in an enumerated record, then its first-level code will be reused; S904: Query the maximum second-level sequence number under the first-level code. If it does not exist, generate 0001. If it exists, increment it. S905: Concatenate the first-level code and the second-level sequence number to form the enumeration standard number.

[0105] For example, WAIVE_ANNUAL_FEE_FLAG can generate the prefix WA, with the first-level code being WA01. Specific enumeration values ​​can be sequentially generated as standard numbers such as WA010001, WA010002, etc. This scheme ensures that multiple enumeration values ​​of the same field naturally belong to the same first-level code, facilitating retrieval, reuse, and regulatory reporting mapping.

[0106] Alternatives to enumeration encoding: The first-level enumeration encoding can be generated from the English prefix of the field name, or from the business domain, regulatory subject, system code, or data subject; the second-level serial number can be generated using decimal increment, hexadecimal increment, or encoding with a check digit.

[0107] One possible implementation also includes: audit trail: when a state transition occurs in a table structure record, an operation log is recorded; the operation log includes module type, operation type, business object ID, business object name, JSON data before change, JSON data after change, operator, operator IP address, system code, operation time and remarks; The acquisition of the operator's IP address follows a preset priority. The X-Forwarded-For, X-Real-IP, Proxy-Client-IP, WL-Proxy-Client-IP, HTTP_CLIENT_IP, and HTTP_X_FORWARDED_FOR header information are parsed sequentially, and the first valid address is taken from the multi-level proxy IP.

[0108] In one example, the operation log and audit traceability module generates logs when operations such as adding, modifying, deleting, and review occur in objects such as data tables, standard fields, enumeration standards, system configurations, and announcements. This log structure supports queries by module, operation type, operator, business object, and time range, providing a complete chain of evidence for internal control audits of financial systems.

[0109] In a preferred implementation, the approval state machine can be extended to multi-level approval, such as submission by ordinary developers, review by the system manager, approval by the data governance committee, and confirmation by the DBA; it can also be integrated into the enterprise's existing BPM or work order system.

[0110] The core uses of this invention include: (1) Credit card system data standard governance: The data tables, fields, field types, field lengths, Chinese meanings, default values, primary keys, whether nullables are allowed, and whether standards are implemented are submitted by various business systems and other metadata are uniformly incorporated into the platform management to form data standard assets that are queryable, auditable, and traceable.

[0111] (2) Automatic standardization verification: The fields to be registered are matched precisely and similarly with the standard field library. The system automatically determines whether the field matches the standard field and verifies the field type, field length, decimal places, Chinese name, and standardization mark to reduce omissions in manual review.

[0112] (3) Structural change risk control: Based on field identity and approval snapshot, when the table structure is modified, the addition, deletion, modification and renaming of fields are automatically identified, and the minimal incremental ALTER DDL is generated to avoid misjudging the field renaming as "deletion + addition" and causing data loss.

[0113] (4) Closed-loop approval and execution: The status management of the table structure submission, review, pending execution, execution approval, rejection, deletion of application, deletion review, etc., ensures that changes to the table structure records of the credit card system take effect only after authorization and confirmation.

[0114] (5) Audit traceability: Record the data before and after the change of objects such as data tables, standard fields, enumeration standards, and system configurations, as well as the operator, IP, business object, operation time, and module type, to provide a basis for internal control, compliance, auditing, and fault tracing.

[0115] (6) Batch access: Supports uploading multiple table structures and their DDLs through Excel templates and importing them into the system at once. It is suitable for scenarios such as launching new credit card products, inventorying existing systems, rectifying regulatory fields, and connecting to the data platform.

[0116] Compared with the prior art, the present invention has the following beneficial effects: (1) Reduce manual standardization costs. The platform automatically parses the DDL and generates a field list, avoiding manual field entry; through standard field caching and similarity matching, it can automatically discover similar fields such as customer_id and cust_id, card_status and card_stat, significantly reducing the workload of credit card system field standard review.

[0117] (2) Reduce the risk of production change scripts. By using the field ID as the field identity, the platform can identify field renaming and generate RENAME COLUMN instead of mistakenly generating DROP COLUMN and ADD COLUMN, thereby reducing the risk of historical data loss due to field renaming.

[0118] (3) Improve batch processing performance. After the standard field is enabled, it is loaded into the memory three-index cache. Exact matching can be completed quickly through the hash index. Fuzzy matching is only entered when exact matching fails, reducing the number of database accesses. It is suitable for scenarios where multiple credit card business tables are imported in batches.

[0119] (4) Improve data standard consistency. The platform systematically verifies field type, field length, decimal places, Chinese names, and whether the standard is followed, which can move field standard control from post-event inspection to the table structure application and review stage.

[0120] (5) Forming a closed loop of approval and execution. When a table structure is added or modified, it first enters the pending review stage. After the review is passed, it enters the pending execution stage. Only after the execution is confirmed does it become approved. The technical script is generated by the platform based on the approval object to avoid the approval content and the execution script being disconnected.

[0121] (6) Supports version tracking and automatic recovery. Each time a review is approved, a table-level and field-level snapshot is generated; when a new modification is rejected, the platform can automatically restore to the latest valid version, avoiding the current valid metadata from being polluted by unapproved changes.

[0122] (7) Strengthen financial audit compliance. The operation log saves the JSON before and after the change, the operator, IP, system code, business object and operation time, which can meet the needs of internal control review of credit card system, production problem tracking and regulatory rectification review.

[0123] (8) Enhance the governance capabilities of enumeration values. The hierarchical coding method groups the enumeration values ​​of the same field into the same level of coding, so that credit card enumeration values ​​such as transaction status, card status, and repayment method have unified coding rules and readability.

[0124] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. An automatic data standard governance method for credit card systems, characterized in that, include: Pending review status construction: In response to the DDL script in the table creation request submitted by the user, after parsing and standardizing the DDL script, a table structure record for the pending review status is generated; the table structure record includes a list of fields; Review rejection branch: In response to the review rejection operation, extract the most recent historical snapshot record that was in the "passed" state; When a historical snapshot record of a passed status exists, the table structure record of the pending review status is overwritten and restored using the ID field and metadata in the historical snapshot record, and the status of the table structure record of the pending review status is reset to the status before the review rejection. If there is no historical snapshot record of the passed state, then the status of the table structure record of the state to be reviewed is updated to the rejection state with no historical version. Review passed branch: In response to the review passed operation, the status of the table structure record is updated to the pending execution status, and a table structure snapshot and field snapshot of the current version are generated simultaneously; the field snapshot contains the field ID; In response to the confirmation operation, the table structure record change in the pending execution state is converted into an incremental ALTER DDL script and sent for execution. After successful execution, the status of the table structure record in the pending execution state is updated to the passed status.

2. The automatic data standard governance method according to claim 1, characterized in that, Also includes: Delete branch: In response to the user's request to delete the table structure record in the pending review state, update the status of the table structure record in the pending review state to the pending deletion state, and save the table structure record in the pending deletion state as the recovery base point. In response to the deletion confirmation operation, delete the table structure records in the pending deletion state; In response to a deletion rejection operation, the state of the table structure record to be deleted is reset to the state before the deletion rejection.

3. The automatic data standard governance method according to claim 1, characterized in that, After parsing and verifying the DDL script, the generated table structure record for the pending review status includes: DDL script parsing: Remove redundant newline characters and spaces from the DDL script to obtain the normalized DDL text; Locate the field definitions of the table creation statements in the standardized DDL text, split the field definitions, and maintain a bracket level counter during splitting to ignore commas inside the data type definitions; extract the field ID and metadata of each field; the metadata includes at least the database field name, English field name, Chinese field name, field type, field length, and decimal precision; For each field, perform the following steps: Standard field three-index construction: Load the corresponding English field name, database field name, and Chinese field name into the memory cache; Standardization verification: Based on the standard field library, perform database field name or English field name exact match, Chinese field name exact match, English field name fuzzy match, and Chinese field name fuzzy match in sequence; If any standard field in the standard field library is matched, the consistency of the field type, field length and decimal precision is further verified, and the standardization verification result is generated. The parsed metadata of the fields is associated with the standardization verification results to generate a table structure record for the pending review status. If the current table creation request is determined to be a new request, a globally unique field ID is assigned to each field. If the current table creation request is determined to be a modification request, the original field ID is associated with the fields based on the historical snapshot record.

4. The automatic data standard governance method according to claim 1, characterized in that, Prior to the DDL script in the response to the user-submitted table creation request, the following is also included: Verify the user's permissions; When the user does not have the necessary permissions, the DDL script will not be received and an insufficient permissions message will be returned. When the user has the necessary permissions, extract the English table names from the DDL script and query whether a table structure record with the same name exists in the system: If no record with the same table structure is found, the submission is determined to be a new request; If a table structure record with the same name and a status of "approved" is found, then this submission is determined to be a modification request. If a record with the same name is found and its status is either pending review or pending execution, the submission will be rejected and a record conflict warning will be returned.

5. The automatic data standard governance method according to claim 1, characterized in that, The step of responding to the confirmation operation by converting the table structure record changes in the pending execution state into an incremental ALTER DDL script includes: Retrieve the field snapshots of the current version associated with the table structure records of the pending execution state, as well as the field snapshots of the historical versions associated with the modification baseline; Based on the field ID, establish a mapping relationship between the current version's field snapshot and the historical version's field snapshot associated with the modification baseline. Compare the metadata of the corresponding fields in the two snapshots and generate an incremental ALTER DDL script. Rename recognition: If the database field name or English field name corresponding to the same field ID is inconsistent in the two snapshots, a RENAME COLUMN statement will be generated; Attribute modification identification: If the field type, field length, decimal precision, non-null constraint, default value or comment information corresponding to the same field ID are inconsistent in the two snapshots, a MODIFY COLUMN statement will be generated. Added identification: If a field ID only exists in the current version's field snapshot, then an ADD COLUMN statement will be generated; Deletion identification: If a field ID only exists in the field snapshot of a historical version, then a DROP COLUMN statement is generated; The incremental ALTER DDL script is associated with the table structure record of the pending execution state for storage, so that it can be called for execution confirmation operation.

6. The automatic data standard governance method according to claim 5, characterized in that, After generating the incremental ALTERDDL script, the process also includes: High-risk interception: Scan the incremental ALTER DDL script to identify any DROP COLUMN statements or MODIFY COLUMN statements that may cause data truncation. When a DROP COLUMN statement or a MODIFY COLUMN statement that may cause data truncation is detected, a high-risk warning message is generated and the issuance of the incremental ALTER DDL script is suspended until a secondary confirmation instruction for the warning is received. In response to the secondary confirmation command, the pause state is lifted, allowing the incremental ALTER DDL script to be issued and executed.

7. The automatic data standard governance method according to claim 1, characterized in that, The step of using the ID and metadata fields in the historical snapshot records to overwrite and restore the table structure records in the pending review state includes: Extract the ID field and its corresponding metadata from the historical snapshot record; Iterate through the list of fields in the pending review status. For each field in the list, if its field ID exists in the historical snapshot record, then use the metadata in the historical snapshot record to overwrite and update the current attribute of the field; if its field ID does not exist in the historical snapshot record, then remove the field from the list of fields in the pending review status. Clear the ALTER DDL scripts associated with the table structure records in the pending review state to ensure that the restored data is completely consistent with the historical snapshot records.

8. The automatic data standard governance method according to claim 1, characterized in that, Also includes: Enumeration standard hierarchical encoding: In response to the registration request of the enumeration field, extract the English field name of the enumeration field, split the English field name according to the preset delimiter, and extract the first letter of the first few words to form a prefix code; Based on the prefix code, query the largest existing first-level code that starts with the prefix code; If a maximum level code exists, extract the numeric part of the maximum level code that is located after the prefix code, add 1 to the numeric part and concatenate it back to the prefix code to generate the current level code; If the maximum first-level code is not found, the prefix code is concatenated with the initial number sequence to generate the initial first-level code; Based on the current first-level code, query the existing largest second-level sequence number that starts with the current first-level code; If a maximum second-level sequence number exists, extract the numerical part of the maximum second-level sequence number that is located after the current first-level code, add 1 to the numerical part, and generate the current second-level sequence number; If the maximum second-level sequence number is not found, an initial second-level sequence number is generated based on the current first-level code and the preset initial number sequence. The current first-level code and the current second-level sequence number are concatenated to generate the standard hierarchical code of the enumeration field, and the standard hierarchical code is associated with and stored with the field ID of the enumeration field.

9. The automatic data standard governance method according to claim 1, characterized in that, Also includes: Audit trail: When a state transition occurs in a table structure record, an operation log is recorded; the operation log includes module type, operation type, business object ID, business object name, JSON data before change, JSON data after change, operator, operator IP address, system code, and operation time; The acquisition of the operator's IP address follows a preset priority. The X-Forwarded-For, X-Real-IP, Proxy-Client-IP, WL-Proxy-Client-IP, HTTP_CLIENT_IP, and HTTP_X_FORWARDED_FOR header information are parsed sequentially, and the first valid address is taken from the multi-level proxy IP.

10. An automated data standards governance platform for credit card systems, characterized in that, The automatic data standard governance method according to any one of claims 1-9 includes: The metadata access module is used to respond to the DDL script in the table creation request submitted by the user. The DDL structure semantic parsing module is used to parse the DDL script; The similarity verification module is used to verify the parsed DDL script and generate a table structure record in the pending review status; the table structure record includes a list of fields. The Field Identity Snapshot module is used to extract historical snapshot records that were last approved in response to review rejection operations; When a historical snapshot record of a passed status exists, the table structure record of the pending review status is overwritten and restored using the ID field and metadata in the historical snapshot record, and the status of the table structure record of the pending review status is reset to the status before the review rejection. If there is no historical snapshot record of the passed state, then the status of the table structure record of the state to be reviewed is updated to the rejection state with no historical version. In response to the approval operation, the status of the table structure record is updated to the pending execution status, and a snapshot of the table structure and field snapshots of the current version are generated simultaneously; the field snapshots contain field IDs; The incremental ALTER DDL generation module is used to respond to the execution confirmation operation by converting the table structure record changes in the pending execution state into an incremental ALTER DDL script and sending it for execution. After successful execution, the status of the table structure record in the pending execution state is updated to the passed status.

Images