Middleware dynamic database table structure mapping method based on version awareness

Abstract

The invention provides a middleware dynamic database table structure mapping method based on version awareness. Table structure information of new and old databases is obtained through a middleware layer; identifying structure inconsistency between the new database and the old database according to the table structure information; generating a mapping rule based on the structure inconsistency; dynamically executing table structure mapping conversion on a middleware layer through the mapping rule; verifying the mapped data to ensure data integrity; a log of mapping and conversion operations is recorded. According to the technology, when the old database is migrated to the new database, it is ensured that the old application can continue to run without being modified, multi-version compatibility can be supported, and when multiple-version applications are applied, it can be ensured that the applications of different versions can access the same database, and multiple database copies do not need to be maintained.

Description

Technical Field

[0001] The present invention relates to the field of information data processing, and in particular to a middleware dynamic database table structure mapping method based on version perception. Background Art

[0002] During the long-term operation of the system, the business system database needs to be maintained for persistent operation. As the business develops, there will inevitably be maintenance work such as compatibility and migration of the data tables of the previous system database. During the database migration and compatibility process, there will be inconsistencies in the table structures between the old and new business system databases. Some functions of the old business may have been discontinued, or there may be no data tables designed for new business functions. During the migration and adaptation process, the key table structures of the new and old versions of the database overlap but are inconsistent (such as field name / type changes, table splitting, constraint differences). For example, some fields are deleted, renamed, or the type is changed in the new version, while the old version of the application still depends on these fields.

[0003] Existing technologies and solutions typically handle these inconsistencies one by one by manually writing adapters or scripts, but this approach is inefficient and error-prone. Furthermore, this hard-coded handling of multi-version compatibility (such as branch judgment or redundant code) leads to bloated code and high maintenance costs. Summary of the Invention

[0004] The main purpose of the present invention is to provide a middleware dynamic database table structure mapping method based on version awareness, which solves the problem that existing technologies and solutions usually handle these inconsistencies one by one by manually writing adapters or scripts, but this method is inefficient and prone to errors.

[0005] To solve the above technical problems, the technical solution adopted by the present invention is: a middleware dynamic database table structure mapping method based on version awareness, the method comprising: obtaining table structure information of the new and old databases through the middleware layer; A semantic network is constructed based on the knowledge graph embedding algorithm, and the semantic association of fields is represented by vectors, where the entity relationship satisfies: , is the head entity vector, is the relationship vector, is the tail entity vector; Identifying structural inconsistencies between the new and old databases based on the table structure information; generating a mapping rule based on the structural inconsistency; Dynamically perform table structure mapping conversion at the middleware layer through the mapping rules; Verify the mapped data to ensure data integrity; Logs mapping and transformation operations.

[0006] In a preferred solution, obtaining the table structure information of the new and old databases through the middleware layer includes: Collecting table structure data in the original database, wherein the table structure data includes table name, field name, field type and constraint conditions; Collecting table structure data in the new database, wherein the table structure data also includes table name, field name, field type and constraint conditions; Storing the table structure data of the original database and the new database to form a version knowledge base; Providing basic data for subsequent mapping rule generation through the version knowledge base; Establish corresponding version indexes for different versions of business software to quickly obtain adaptation information; The table structure data and the business software version are associated through the version index.

[0007] In a preferred embodiment, the table structure information identifies structural inconsistencies between the old and new databases, including: Compare the table structure data of the new and old databases to determine if any fields are missing; Identify cases where fields are renamed; Determine the change of field type; Analyze the differences between table splits or merges; Detect differences in constraints; Through the above comparison and analysis, an inconsistency report is generated; Providing a basis for the formulation of subsequent mapping rules based on the inconsistency report; Storing the inconsistency report in a version knowledge base; Use dynamic programming algorithm to generate the optimal mapping path based on the dependency graph The topological sort of determines the execution order, where is a field node, is the dependency edge.

[0008] In the preferred solution, the structural inconsistency generates mapping rules including: Formulate default value filling rules for missing fields; Generate name replacement rules for field renaming; Formulate type conversion rules for field type changes; Generate splitting or merging logic rules for table splitting or merging; Formulate constraint adaptation rules based on the differences in constraint conditions; Integrate the above rules into a complete mapping rule set; The mapping rule set is stored in a version knowledge base for dynamic invocation; Associating the mapping rule set according to the business software version index; Genetic algorithm is used to optimize the generation of mapping rules, and chromosome encoding is used as field mapping matrix , through the fitness function Iterative optimization, where .

[0009] In the preferred solution, the mapping rules dynamically execute table structure mapping conversion at the middleware layer, including: Receive data requests from terminal business software; Parsing the data request to obtain the business software version number; Query the corresponding mapping rule according to the business software version number; Performing table structure conversion on the data request based on the mapping rule; Forward the converted data request to the new database; Get the data returned by the new database; Performing reverse conversion on the returned data according to the mapping rules; Send the reverse-converted data back to the terminal business software; During the low-frequency period of business data, the simulated annealing algorithm is used to smooth the transition rule, and the state transition probability is: ,in is the energy difference, is the temperature parameter.

[0010] In a preferred embodiment, the mapped data is validated to ensure data integrity, including: Check whether the numerical range of the mapped data meets expectations; Determine whether there are unmapped inconsistencies; Verify that foreign key relationships remain intact; If the value range is found to be inconsistent with expectations, the relevant data will be remapped; If unmapped inconsistencies are found, the corresponding mapping rules are supplemented; If the foreign key relationship is incomplete, repair the relevant constraints; Through the above verification and repair, the business logic consistency of the mapped data is ensured; Record the verification results in a log for subsequent analysis; Use graph isomorphism algorithm to match the new and old table structure topology, and judge the consistency of foreign key relationship through subgraph isomorphism. The isomorphism condition is the existence of bijection satisfy ; in, : Represents the node set in the old database table structure topology diagram, Represents the node set in the new database table structure topology diagram, It is the set of edges in the old database table structure topology graph. is the set of edges in the new database table structure topology graph, Indicates that in the old table structure topology, the node and nodes There is an edge between them, that is, there is a foreign key association relationship between them.

[0011] In the preferred embodiment, the logs of mapping and conversion operations are recorded, including: Record the input data and output data of each mapping operation; Record the time and version information of each conversion operation; Record the calling of mapping rules; Record data verification results and repair actions; generating an operation report through the log; analyzing the applicability of the mapping rules according to the operation report; Optimizing the mapping rules based on the analysis results; Update the optimized mapping rules to the version knowledge base; Support subsequent troubleshooting and system improvements through the logs; Analyze time series patterns through LSTM neural networks.

[0012] In the preferred solution, the table structure mapping conversion is dynamically performed through the middleware layer, including: Update middleware programs during periods of low business data frequency; Implementing dynamic table structure mapping function through the middleware program; Receiving data requests from terminal devices; determining version information of the terminal device according to the data request; Calling corresponding mapping rules based on the version information; Convert the data request to adapt to the new database using the mapping rules; Get the response data of the new database; Performing adaptation processing on the response data according to the mapping rule; Returning the adapted response data to the terminal device; The above process enables old devices to seamlessly access the new database.

[0013] In the preferred solution, when generating mapping rules, the isolation forest algorithm is used to detect data anomalies, and the anomaly score is calculated as: ,in For samples The path length, is the average path length of the tree.

[0014] In the preferred solution, the mapping rules support extension through configuration files or plug-ins, and semantic-level mapping extension is achieved based on the ontology mapping algorithm, through ontology concept similarity calculation: ,in The lowest common ancestor.

[0015] This invention provides a version-aware dynamic database table structure mapping method for middleware. 1) This method enables dynamic adaptation, performed when business software issues a request, dynamically processing database request mapping to generate converted query accesses without modifying the business code on the original device, achieving zero-intrusive adaptation. That is, the business layer does not need to be aware of changes to the underlying table structure; dynamic mapping is automatically generated solely through version declarations. This method is particularly useful for legacy devices that have lost their business software source code or where the original business software provider has gone bankrupt, making it impossible to modify the business software.

[0016] The present invention has strong versatility and can support a variety of adaptation scenarios, such as field deletion, renaming, type change, etc. The present invention has good scalability. By collecting databases to form mapping rules, it can be extended through configuration files (mapping rules) or plug-ins to support more complex adaptation and expansion requirements.

[0017] This technology ensures that legacy applications can continue to run without modification when migrating old databases to new ones. It supports multi-version compatibility and ensures that different versions of applications can access the same database without having to maintain multiple database copies. This technology integrates multiple data sources through dynamic mapping, dynamically handling table structure differences between different data sources, and achieving consistent data access and management. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The present invention will be further described below with reference to the accompanying drawings and examples: Figure 1 This is the knowledge base acquisition process of the present invention version; Figure 2 This is the dynamic table structure mapping detection process. DETAILED DESCRIPTION

[0019] Example 1 like Figure 1-2 As shown, a middleware dynamic database table structure mapping method based on version awareness includes: obtaining table structure information of the new and old databases through the middleware layer; A semantic network is constructed based on the knowledge graph embedding algorithm, and the semantic association of fields is represented by vectors, where the entity relationship satisfies: , is the head entity vector, is the relationship vector, is the tail entity vector; Identifying structural inconsistencies between the new and old databases based on the table structure information; generating a mapping rule based on the structural inconsistency; Dynamically perform table structure mapping conversion at the middleware layer through the mapping rules; Verify the mapped data to ensure data integrity; Logs mapping and transformation operations.

[0020] The middleware layer obtains table structure information from both the old and new databases. This involves using the middleware program to collect table structure data from both the original and new business databases, including table names, field names, field types, and constraints. This data is then stored in a version knowledge base, providing foundational data support for subsequent mapping rule generation and adaptation. Furthermore, a version index is established for different versions of business software, linking table structure data with business software versions for quick query of adaptation information.

[0021] When building a semantic network based on the knowledge graph embedding algorithm, database entities such as fields and tables, as well as their inter-entity relationships (foreign key constraints and business logic associations), are converted into semantic representations in a low-dimensional vector space, where the sum of the head entity vector h and the relationship vector r is approximately equal to the tail entity vector t. This vector representation accurately identifies the semantic correspondence between fields in the old and new table structures by calculating the semantic similarity between vectors. Even if the field name or type changes, its business logic-level mapping can be determined based on semantic associations, providing a semantic basis for subsequent inconsistency identification.

[0022] After obtaining the table structure information, by comparing the table structure data of the old and new databases, structural inconsistencies such as field missing, renaming, type change, table splitting or merging, and constraint differences are identified, and an inconsistency report is generated and stored in the version knowledge base, providing a clear problem-oriented approach for the formulation of mapping rules, ensuring that the rules can specifically solve structural difference problems.

[0023] When generating mapping rules based on structural inconsistencies, default value filling rules are developed for missing fields, name replacement rules are generated for field renaming, type conversion rules are developed for type changes, logical rules are generated for table splitting or merging, and adaptation rules are developed for constraint differences. This complete mapping rule set is formed and associated with the business software version index. Furthermore, a genetic algorithm is used to optimize the rule generation process, encoding the field mapping matrix as chromosomes. Iterative optimization is performed using a fitness function (F = α·accuracy retention rate + β·foreign key integrity rate, where α+β=1) to ensure that the mapping rules achieve optimal results in terms of data accuracy retention and foreign key integrity.

[0024] When dynamically performing table structure mapping conversion at the middleware layer, when the terminal business software issues a data request, the middleware parses the request to obtain the version number, queries the corresponding mapping rule based on the version number, converts the table structure of the data request, and forwards it to the new database. The data returned by the new database is then reverse-converted and transmitted back to the terminal. During periods of low business data frequency, a simulated annealing algorithm is used to smoothly transition between the old and new mapping rules, enabling middleware program updates and ensuring uninterrupted business during the migration process.

[0025] Post-mapping data verification ensures data integrity by checking value ranges, detecting unmapped inconsistencies, and verifying the integrity of foreign key relationships. A graph isomorphism algorithm is used to match the topology of the new and old table structures. The consistency of foreign key relationships is verified by determining whether a bijection f: V1→V2 exists such that (u,v)∈E1 is equivalent to (f(u),f(v))∈E2. If verification fails, the data is remapped, mapping rules are supplemented, or constraints are fixed to ensure the business logic consistency of the mapped data. Verification results are logged to provide data support for subsequent troubleshooting and rule optimization.

[0026] Log records cover the input and output data of mapping operations, conversion time, version information, rule call status, verification results, and repair operations. The LSTM neural network analyzes the log time series patterns, predicts potential mapping conflicts, and optimizes rules, forming a closed loop of "collection-mapping-verification-optimization."

[0027] Through the dynamic mapping mechanism of the middleware layer, transparent access to the same database by new and old applications is achieved without modifying the application code, which solves the problem of old equipment source code loss or manufacturer bankruptcy that cannot be modified, and achieves zero-intrusion adaptation; using version indexing and dynamic rule conversion, migration is completed during business-free periods to ensure that the system runs without downtime; supports various structural difference scenarios such as field missing, renaming, type change, etc., and extends mapping rules through configuration files or plug-ins, with strong versatility and scalability; integrates the access requirements of multiple versions of applications to the same database, avoids maintaining multiple database copies, reduces system complexity and management costs, and ensures data consistency and business continuity through semantic-level mapping and dynamic verification.

[0028] In a preferred solution, obtaining the table structure information of the new and old databases through the middleware layer includes: Collecting table structure data in the original database, wherein the table structure data includes table name, field name, field type and constraint conditions; Collecting table structure data in the new database, wherein the table structure data also includes table name, field name, field type and constraint conditions; Storing the table structure data of the original database and the new database to form a version knowledge base; Providing basic data for subsequent mapping rule generation through the version knowledge base; Establish corresponding version indexes for different versions of business software to quickly obtain adaptation information; The table structure data and the business software version are associated through the version index.

[0029] Obtaining table structure information from both the old and new databases through the middleware layer specifically involves using the middleware program to collect the table structures of both the original and new databases. This collection includes key information such as table names, field names, field types, and constraints. This information is the core component of the database table structure and fully reflects the database's organizational structure and data specifications. For example, table names identify different data sets, field names and types determine the data's storage format, and constraints ensure data integrity and consistency.

[0030] After the collection is complete, the table structure data of the new and old databases is stored to form a version knowledge base. This knowledge base acts as a central storage warehouse, systematically storing all information related to the table structure and providing a solid foundation for the subsequent generation of mapping rules. Subsequent comparisons of the old and new table structures, identification of inconsistencies, and formulation of mapping rules all rely on analysis and processing of the data in the knowledge base.

[0031] Establishing corresponding version indexes for different versions of business software effectively creates a fast retrieval channel for data in the knowledge base. Business software may have multiple versions, each with different requirements and dependencies on database table structures. Using version indexes, matching table structure data can be quickly located based on the business software version number. This association mechanism enables the middleware to quickly obtain the required adaptation information when processing requests from different software versions, improving the system's response efficiency and accuracy and avoiding errors or delays caused by version mismatches.

[0032] By comprehensively collecting and storing table structure data from both the old and new databases, a unified version knowledge base has been formed, providing an accurate and complete data foundation for the entire dynamic mapping technology and ensuring reliable data support for all subsequent operations. The establishment of a version index enables a precise association between table structure data and business software versions, enabling the middleware to quickly find corresponding adaptation information based on the requirements of different software versions, greatly improving the efficiency and accuracy of the system in processing multi-version software requests. This mechanism ensures that when faced with complex scenarios involving transitions between old and new systems and the coexistence of multiple versions, the middleware can efficiently and accurately complete the table structure mapping conversion, providing an important guarantee for achieving zero-intrusion, non-stop database migration and compatibility. It also reduces the complexity and cost of system maintenance and improves the stability and availability of the overall system.

[0033] In a preferred embodiment, the table structure information identifies structural inconsistencies between the old and new databases, including: Compare the table structure data of the new and old databases to determine if any fields are missing; Identify cases where fields are renamed; Determine the change of field type; Analyze the differences between table splits or merges; Detect differences in constraints; Through the above comparison and analysis, an inconsistency report is generated; Providing a basis for the formulation of subsequent mapping rules based on the inconsistency report; Storing the inconsistency report in a version knowledge base; Use dynamic programming algorithm to generate the optimal mapping path based on the dependency graph The topological sort of determines the execution order, where is a field node, is the dependency edge.

[0034] By comparing the table structure data of the old and new databases, various structural inconsistencies can be identified. For example, determining field missing situations, that is, the new database table lacks certain fields in the old table, which may cause the old business functions to not run normally due to missing data; identifying field renaming situations, where the name of a field in the old table is changed in the new table, which will prevent the old application from correctly accessing the corresponding data if not handled; judging field type changes, such as changing a field from integer to character type, which will cause data storage and reading errors if not converted; analyzing table splitting or merging differences, where the old table is split into multiple new tables or multiple old tables are merged into one new table, which will change the organization of the data; detecting differences in constraints, such as changes in primary keys, foreign keys, or unique constraints, which may affect the integrity and consistency of the data.

[0035] After identifying these inconsistencies, an inconsistency report is generated. This report details the specific differences between the old and new table structures, providing a clear basis for developing mapping rules that can be used to address various structural issues. The report is also stored in the version knowledge base for easy subsequent query and use.

[0036] When using a dynamic programming algorithm to generate the optimal mapping path, the execution order is determined based on the topological sorting of the dependency graph G = (V, E), where V represents field nodes and E represents dependency edges. By analyzing the dependencies between fields, such as foreign key associations, mapping operations are performed in topological order. This ensures that dependent fields are processed before fields that depend on other fields during the mapping process. This avoids data inconsistencies or mapping failures caused by improper dependency handling, thereby improving mapping efficiency and accuracy and ensuring the orderliness and correctness of the mapping process.

[0037] Comprehensively and meticulously identify various inconsistencies in the table structures of the old and new databases, providing an accurate and comprehensive basis for the subsequent formulation of mapping rules, ensuring that the rules can effectively solve structural differences; store inconsistency reports in the knowledge base for easy subsequent maintenance and optimization; use dynamic programming algorithms combined with dependency graph topological sorting to generate the optimal mapping path, ensure that mapping operations are performed in a reasonable order, avoid affecting the mapping effect due to dependency issues, improve mapping efficiency and reliability, provide strong support for the smooth transition of the old and new databases and the continuous operation of the business, ensure data integrity and consistency during database migration and compatibility, and reduce migration risks and costs.

[0038] In the preferred solution, the structural inconsistency generates mapping rules including: Formulate default value filling rules for missing fields; Generate name replacement rules for field renaming; Formulate type conversion rules for field type changes; Generate splitting or merging logic rules for table splitting or merging; Formulate constraint adaptation rules based on the differences in constraint conditions; Integrate the above rules into a complete mapping rule set; The mapping rule set is stored in a version knowledge base for dynamic invocation; Associating the mapping rule set according to the business software version index; Genetic algorithm is used to optimize the generation of mapping rules, and chromosome encoding is used as field mapping matrix , through the fitness function Iterative optimization, where .

[0039] When generating mapping rules for structural inconsistencies, targeted rules need to be formulated according to different types of differences. When a field is missing, a default value filling rule is formulated. For example, when a field in the old table is missing in the new table, in order to ensure the integrity of the old application accessing the data, the preset default value is automatically filled (0 for numeric types and a blank string for character types) to avoid query anomalies caused by missing fields; for field renaming, a name replacement rule is generated and a mapping comparison table of the old and new field names is established. When the old application requests to access the old field name, the middleware automatically converts it to the new field name according to the rule to ensure the correctness of the data access path; in the face of field type changes, type conversion rules are formulated based on the semantic association between the old and new types (integer to string). When processing table splitting or merging differences, the system generates splitting or merging logic rules. If the old table is split into multiple new tables, the rules define the data distribution logic between the new tables. If multiple old tables are merged into a new table, the rules specify the data aggregation method to ensure the continuity of business logic after the data organization form is changed. For differences in constraint conditions, constraint adaptation rules are formulated. For example, when the primary key rule of the new table is changed, the rules define the conversion logic from the old table primary key to the new table primary key to ensure that data integrity constraints are met in both the old and new structures.

[0040] After integrating these various rules into a complete mapping rule set, they are stored in a version knowledge base, enabling centralized rule management and dynamic call access. At the same time, rule sets are associated based on the business software version index, enabling application requests from different versions to be quickly matched to the corresponding adaptation rules. For example, when an application with version V1.0 is accessed, the middleware automatically calls a compatible rule set for mapping conversion.

[0041] A genetic algorithm is used to optimize the mapping rule generation process. The field mapping matrix is ​​encoded as chromosomes, with each chromosome representing a set of mapping rule combinations. The fitness function F = α·Precision Retention Rate + β·Foreign Key Integrity Rate (α+β=1) is used to evaluate the quality of the rules. Precision retention rates measure the numerical and semantic accuracy of the converted data, while foreign key integrity rates verify the consistency of the mapped foreign key relationships. The algorithm iteratively optimizes chromosomes through selection, crossover, and mutation operations to achieve an optimal balance between data precision and foreign key integrity. For example, through multiple generations of evolution, a rule combination is identified that achieves a numerical conversion error rate of less than 0.1% and a foreign key association success rate of 100%.

[0042] The rules formulated for various structural differences are highly targeted and can accurately solve problems such as missing fields and renaming, ensuring the accuracy of mapping conversions; the integration and storage of rule sets realize dynamic calls and improve the response efficiency of the middleware in processing application requests of different versions; the rule association mechanism based on version index makes adaptation operations in multi-version compatibility scenarios more efficient, and can automatically match rules without manual intervention; the optimization process of the genetic algorithm improves the quality of rules through iterative quantitative indicators, avoiding possible omissions in manually written rules, and making the mapping rules reach the optimal state in data accuracy and foreign key integrity, thereby ensuring data consistency and business continuity during the migration process between the old and new databases. It is especially suitable for automated adaptation in scenarios with complex structural differences, reducing manual maintenance costs while improving system stability and reliability.

[0043] In the preferred solution, the mapping rules dynamically execute table structure mapping conversion at the middleware layer, including: Receive data requests from terminal business software; Parsing the data request to obtain the business software version number; Query the corresponding mapping rule according to the business software version number; Performing table structure conversion on the data request based on the mapping rule; Forward the converted data request to the new database; Get the data returned by the new database; Performing reverse conversion on the returned data according to the mapping rules; Send the reverse-converted data back to the terminal business software; During the low-frequency period of business data, the simulated annealing algorithm is used to smooth the transition rule, and the state transition probability is: ,in is the energy difference, is the temperature parameter.

[0044] When dynamically performing table structure mapping conversion at the middleware layer, it first receives data requests from the terminal business software. These requests carry the information required for business operations and the software version identifier. The middleware parses the data requests and extracts the business software version number. This step is critical, as different software versions may correspond to different database table structure mapping rules.

[0045] Based on the obtained version number, the middleware searches the version knowledge base for the corresponding mapping rules. These rules are pre-defined to account for the differences between the software version and the new database structure, and include logic for field conversion, table splitting and merging, and more. Then, based on these mapping rules, the middleware performs table structure conversion on the data request, converting the old table structure and field names mentioned in the request into a format that the new database can recognize.

[0046] After the conversion is complete, the middleware forwards the data request to the new database, which processes the request and returns the result. After receiving the returned data, the middleware performs a reverse conversion based on the mapping rules, converting the data format returned by the new database into the old structure understandable by the terminal business software. Finally, the reverse-converted data is transmitted back to the terminal business software, completing the communication process.

[0047] During periods of low business data frequency, the middleware will use the simulated annealing algorithm to smooth the transition rules. The state transition probability of the simulated annealing algorithm is ,in The energy difference represents the difference between the old and new rules when transitioning. T is the temperature parameter, which gradually decreases over time and controls the probability of accepting the rule transition. During this process, the algorithm decides whether to accept the new rule based on the energy difference and temperature parameter, avoiding business anomalies caused by sudden rule changes and ensuring smooth rule updates.

[0048] The beneficial effects of this process include: by dynamically querying and executing mapping rules based on version numbers, transparent access to the new database is achieved for different versions of business software. Terminal software can adapt to the new database structure without code modifications, achieving zero-intrusive adaptation. The middleware's bidirectional conversion of data requests and return results ensures the consistency and correctness of data interactions between the old and new systems, guaranteeing business continuity. During periods of low business activity, the simulated annealing algorithm is used to smoothly transition rules, avoiding the impact of rule updates on business. This allows for non-disruptive migration, improving system availability and stability, while also reducing business losses and maintenance costs caused by system downtime.

[0049] In a preferred embodiment, the mapped data is validated to ensure data integrity, including: Check whether the numerical range of the mapped data meets expectations; Determine whether there are unmapped inconsistencies; Verify that foreign key relationships remain intact; If the value range is found to be inconsistent with expectations, the relevant data will be remapped; If unmapped inconsistencies are found, the corresponding mapping rules are supplemented; If the foreign key relationship is incomplete, repair the relevant constraints; Through the above verification and repair, the business logic consistency of the mapped data is ensured; Record the verification results in a log for subsequent analysis; Use graph isomorphism algorithm to match the new and old table structure topology, and judge the consistency of foreign key relationship through subgraph isomorphism. The isomorphism condition is the existence of bijection satisfy ; in, : Represents the node set in the old database table structure topology diagram, Represents the node set in the new database table structure topology diagram, It is the set of edges in the old database table structure topology graph. is the set of edges in the new database table structure topology graph, Indicates that in the old table structure topology, the node and nodes There is an edge between them, that is, there is a foreign key association relationship between them.

[0050] : Represents a bijective function from the set of nodes in the old table structure topology graph to the set of nodes in the new table structure topology graph, that is, each node in the old table can uniquely correspond to a node in the new table, and each node in the new table has a corresponding node in the old table.

[0051] :Indicates that through bijective function After mapping, the old table node Corresponding new table node and old table nodes Corresponding new table node There is an edge between them in the new table structure topology graph, that is, the relationship between them is also preserved in the new table.

[0052] When verifying the mapped data, it is necessary to ensure data integrity in multiple dimensions. First, check whether the numerical range of the mapped data meets expectations. For example, if a field is defined as an integer from 0 to 100 in the old database, it is necessary to verify whether its value is still within the range after mapping to the new database to avoid data overflow or invalidity due to type conversion or rule omissions. Secondly, determine whether there are unmapped inconsistencies, such as field renaming or constraint differences that were omitted when comparing the old and new table structures, and ensure that all structural differences are covered. Thirdly, verify whether the foreign key relationship remains intact, for example, whether the foreign key association between the order table and the customer table is still valid after mapping, to avoid isolated data or broken associations.

[0053] If validation discovers discrepancies within numerical ranges, the relevant data must be remapped, adjusting type conversion rules or default value policies. If unmapped inconsistencies exist, the corresponding mapping rules must be added to the version knowledge base, such as adding field alias mapping entries. If foreign key relationships are incomplete, the relevant constraints must be repaired, such as by re-establishing inter-table associations. This verification and repair mechanism ensures that mapped data remains consistent at the business logic level. For example, after order data is mapped, it can still be correctly associated with customer information, maintaining business process continuity.

[0054] During the verification process, the graph isomorphism algorithm (VF2) is used to match the new and old table structure topologies, and to determine whether there is a bijective function , so that the edge in the old table topology graph If and only if the edge in the new table topology graph , strictly verifying the consistency of foreign key relationships. For example, the foreign key association between the customer ID field in the old table and the customer identification field in the new table can be fully preserved after mapping through the graph isomorphism algorithm. Verification results are recorded in the log, including numerical anomalies, details of unmapped fields, and foreign key repair records. This provides data support for subsequent rule optimization and troubleshooting. For example, log analysis can be used to identify frequently occurring mapping errors and tailor type conversion rules.

[0055] Through a multi-level verification and repair process, we ensure that the mapped data meets the requirements in terms of numerical accuracy, structural integrity, and business logic consistency, avoiding business anomalies caused by mapping errors. The introduction of the graph isomorphism algorithm strictly verifies foreign key relationships from the topological structure level, eliminating the problem of data association failure caused by table structure changes, and is particularly suitable for consistency assurance in complex table relationship scenarios. The logging and analysis mechanism forms a closed loop of "verification-repair-optimization", so that the mapping rules can be continuously iterated and improved according to the actual operation situation, improving the stability and reliability of the system, and providing a solid guarantee for the long-term stable operation after the migration of the old and new databases. At the same time, it reduces the cost and time overhead of manually troubleshooting data consistency issues.

[0056] In the preferred embodiment, the logs of mapping and conversion operations are recorded, including: Record the input data and output data of each mapping operation; Record the time and version information of each conversion operation; Record the calling of mapping rules; Record data verification results and repair actions; generating an operation report through the log; analyzing the applicability of the mapping rules according to the operation report; Optimizing the mapping rules based on the analysis results; Update the optimized mapping rules to the version knowledge base; Support subsequent troubleshooting and system improvements through the logs; Analyze time series patterns through LSTM neural networks.

[0057] When recording the logs of mapping and conversion operations, the input data and output data of each mapping operation will be recorded in detail, such as the field parameters of the old table query request and the converted data returned by the new database, so as to facilitate intuitive comparison of the differences before and after mapping. At the same time, the time and version information of each conversion operation are recorded, accurate to the specific time point and business software version number, to provide a timeline basis for subsequent tracing of the mapping status of a specific version. The calling of the mapping rule will also be recorded, including the name of the called rule, parameter configuration, etc., to clearly present the actual usage scenario of the rule. The results of data verification and repair operations will also be recorded, such as the fields with abnormal value ranges and the remapping process, and the constraint repair steps when the foreign key relationship is incomplete.

[0058] Based on this log information, an operation report is generated. The report provides statistics and analysis on the overall status of the mapping operation, such as the mapping success rate for different software versions and common mapping error types. The report is used to analyze the applicability of the mapping rules and identify any deficiencies in their actual application. For example, certain field type conversion rules may result in significant precision loss in specific scenarios. Based on the analysis results, the mapping rules are optimized, such as adjusting the type conversion algorithm or adding new default value population rules. The optimized mapping rules are then updated to the version knowledge base, ensuring that subsequent mapping operations use the more comprehensive rules.

[0059] Logs also support subsequent troubleshooting and system improvements. When business anomalies occur, logs can quickly identify the specific mapping operation, the rules involved, and the data conversion process, assisting in troubleshooting the root cause. Furthermore, LSTM neural networks analyze temporal patterns in logs. Using their unique gating mechanisms (such as forget gates, input gates, and output gates), LSTM neural networks process the time series of log data and learn historical patterns and trends in mapping operations. For example, they can identify an increase in mapping error rates for a specific software version within a certain time period, predict potential mapping conflicts, optimize rules in advance, and implement proactive system improvements.

[0060] Comprehensive and detailed logging provides a complete traceability chain for mapping operations, facilitating troubleshooting and quality tracing, and improving the system's maintainability. The closed-loop mechanism of operation reporting and rule optimization enables mapping rules to continuously iterate and evolve based on actual operational conditions, continuously improving mapping accuracy and applicability, and better adapting to changes in business needs and database structure. The LSTM neural network's analysis of time series patterns empowers the system to predict potential issues, shifting from passive repair to active optimization. This further enhances system stability and reliability, reduces business risks caused by mapping rule defects, and provides data-driven decision support for the system's long-term evolution and optimization, reducing the cost and errors of manual analysis and improving the overall system's intelligence and operational efficiency.

[0061] In the preferred solution, the table structure mapping conversion is dynamically performed through the middleware layer, including: Update middleware programs during periods of low business data frequency; Implementing dynamic table structure mapping function through the middleware program; Receiving data requests from terminal devices; determining version information of the terminal device according to the data request; Calling corresponding mapping rules based on the version information; Convert the data request to adapt to the new database using the mapping rules; Get the response data of the new database; Performing adaptation processing on the response data according to the mapping rule; Returning the adapted response data to the terminal device; The above process enables old devices to seamlessly access the new database.

[0062] When dynamically performing table structure mapping conversions through the middleware layer, middleware updates are optimized during periods of low business data frequency to minimize disruption to normal business processes. The updated middleware program incorporates dynamic table structure mapping capabilities, enabling real-time processing of data requests from terminal devices. When a terminal device issues a data request, the middleware first parses the request to determine its version information. Different device versions may correspond to different database table structures and mapping rules. Accurately identifying the version is essential for subsequent correct mapping.

[0063] Based on the determined version information, the middleware invokes the corresponding mapping rules from the version knowledge base. These rules are pre-defined based on the structural differences between the device and the new database, and include logic such as field conversion and table structure adaptation. Using these mapping rules, the middleware converts the terminal device's data request into a format that the new database can recognize and process, ensuring the request's validity and compatibility. Once the conversion is complete, the middleware sends the data request to the new database and retrieves the new database's response data.

[0064] To enable the terminal device to correctly understand and use the data returned by the new database, the middleware adapts the response data according to mapping rules, converting it into a format recognizable by the terminal device, and finally returns the adapted response data to the terminal device. This entire process requires no modifications to the terminal device's hardware or software. Through the middleware's dynamic mapping and conversion, legacy devices can seamlessly access the new database.

[0065] Choosing to update the middleware program during a low-frequency business period avoids business interruptions caused by program updates and ensures system continuity and availability; the middleware dynamically calls mapping rules based on version information to achieve accurate adaptation to terminal devices of different versions, eliminating the need to develop separate adapter programs for different versions of devices, reducing development and maintenance costs; through the middleware's two-way conversion (request conversion and response adaptation), the smoothness and consistency of data interaction between old devices and the new database are ensured, allowing old devices to access the new database normally without modifying any configuration, achieving a truly seamless transition; this dynamic mapping conversion mechanism improves the system's compatibility and scalability, provides a flexible solution for subsequent new device access and database upgrades, and ensures the long-term stable operation of the system.

[0066] In the preferred solution, when generating mapping rules, the isolation forest algorithm is used to detect data anomalies, and the anomaly score is calculated as: ,in For samples The path length, is the average path length of the tree.

[0067] In the preferred solution, the mapping rules support extension through configuration files or plug-ins, and semantic-level mapping extension is achieved based on the ontology mapping algorithm, through ontology concept similarity calculation: ,in The lowest common ancestor.

[0068] When generating mapping rules, the isolation forest algorithm is used to detect data anomalies. Its core principle is to identify outliers by constructing a binary tree set (isolation forest). , It represents the length of the path from the root node to the sample. The shorter the path, the more likely the sample is an outlier. is the average path length of the tree, used for normalization. By formula When the score is close to 1, the sample is an outlier, and when it is close to 0, it is a normal point. This algorithm can effectively detect data anomalies caused by missing fields, type mismatches, etc. during the mapping process. For example, it can identify unexpected field values ​​that suddenly appear in a batch of converted data, providing abnormal data samples for rule optimization.

[0069] Mapping rules can be extended through configuration files or plug-ins, and semantic-level extensions can be achieved based on the ontology mapping algorithm. The ontology mapping algorithm establishes the association between new and old semantics by calculating the similarity of concepts. Representing ontology concepts and The similarity of calculate, is the lowest common ancestor of the two concepts, Indicates the depth of a concept within the ontology tree. This algorithm can go beyond superficial differences in field names and types to identify relationships at a semantic level. For example, a "Customer ID" field in a new database can be mapped to a "User ID" field in an old database based on semantic similarity, allowing for correct association even when the field names and types differ.

[0070] The isolation forest algorithm provides data anomaly detection capabilities for mapping rule generation, can automatically discover potential problems in the mapping process, avoid rule failures caused by abnormal data, and improve the robustness of the rules; the ontology mapping algorithm implements semantic-level mapping extensions, enabling rules to adapt to more complex business semantic changes, especially suitable for scenarios such as field renaming and semantic migration, improving the accuracy and flexibility of mapping; the extension of configuration files and plug-ins lowers the technical threshold for rule maintenance, and users can quickly adapt to new business needs through customized configuration or plug-in development without modifying the core code, enhancing the system's scalability and adaptability, enabling dynamic mapping technology to continuously respond to the evolution of database structure and business semantics, and ensuring the long-term stable operation of the system.

[0071] Example 2 Further illustrate with reference to Example 1, Figure 1-2 The present invention implements database table structure mapping technology based on version awareness on the web middleware between the terminal program and the database communication. This technology first collects the same business database table structure in the existing database, including table structure, field types, constraints, indexes and other information.

[0072] Through semantic analysis, the meaning and corresponding relationship of data at the business logic level are identified, that is, the dependency relationship of data used in business processes is identified to form a knowledge base.

[0073] When the terminal sends data to the database, this technology dynamically handles the inconsistencies between the old and new database table structures. By parsing the metadata of the old and new databases and based on the knowledge base of the new database's table structure, it automatically generates mapping logic, including field type mapping, character set length mapping adjustment, and primary key mapping conversion. Precision is not lost during the mapping process, and the integrity of foreign key relationships is maintained.

[0074] After the mapping is completed, the semantic consistency is checked, mainly including whether the value range is consistent, whether there are inconsistencies that are not mapped, and whether the foreign key relationship is complete. If the verification fails, the inconsistent points are re-mapped and repaired.

[0075] Monitor logs of all mappings and validations to troubleshoot issues and optimize the mapping process.

[0076] Ensure that legacy business applications can seamlessly access the new database without modifying the application code, and achieve zero-code-intrusion adaptation for legacy terminal devices.

[0077] The web (middleware layer) program can be replaced when there is no business data gap or low data transmission gap, so that the old business can be adapted to the new database without interrupting the business.

[0078] The version knowledge base collection process is as follows: 1) Use the program to collect the database table structure of the original business, including but not limited to table name, field name, field type, constraints, etc.

[0079] 2) Use the program to collect the database table structure used in the new business, including but not limited to table name, field name, field type, constraints, etc.

[0080] 3) Compare old and new metadata to identify inconsistencies in table structure, such as missing fields, renamed fields, and changed field types.

[0081] 4) Generate mapping rules based on inconsistencies. Mapping rules include but are not limited to type conversion, default value filling, table splitting logic, field name replacement, etc.

[0082] 5) Store in the knowledge base.

[0083] 6) Create an index of the business software version numbers of the terminal program to facilitate the search for adaptation rules.

[0084] The dynamic table structure mapping detection process is as follows: 1) Convert the existing data in the business database according to the conversion rules and embed it into the new database.

[0085] 2) When business data is low-frequency, update the middleware web program to implement dynamic table structure mapping function.

[0086] 3) The business software of the old terminal equipment sends a data request to the web middleware program.

[0087] 4) Web middleware, which parses the request and obtains the terminal service software version number.

[0088] 5) Query the mapping rules based on the software version number.

[0089] 6) Perform mapping conversion based on mapping rules.

[0090] 7) Perform data validation to ensure data integrity, accuracy and compliance with database rules.

[0091] 8) Use the mapped access to the new database.

[0092] 9) Or use the mapped data to send back to the terminal device business software.

[0093] 10) Record logs of all mapping and transformation operations to facilitate troubleshooting and rule optimization.

[0094] 11) Complete the communication process.

[0095] The above embodiments are merely preferred technical solutions of the present invention and should not be construed as limiting the present invention. The scope of protection of the present invention shall be the technical solutions set forth in the claims, including equivalent alternatives to the technical features of the technical solutions set forth in the claims. In other words, equivalent alternatives and improvements within this scope are also within the scope of protection of the present invention.

Claims

1. A method for mapping a dynamic database table structure of a middleware based on version awareness, characterized by: The method comprises: obtaining table structure information of the new and old databases through the middleware layer; A semantic network is constructed based on the knowledge graph embedding algorithm, and the semantic association of fields is represented by vectors, where the entity relationship satisfies: , is the head entity vector, is the relationship vector, is the tail entity vector; Identifying structural inconsistencies between the new and old databases based on the table structure information; generating a mapping rule based on the structural inconsistency; Dynamically perform table structure mapping conversion at the middleware layer through the mapping rules; Verify the mapped data to ensure data integrity; Logs mapping and transformation operations.

2. The method for mapping a dynamic database table structure of a middleware based on version awareness according to claim 1, characterized in that: The process of obtaining the table structure information of the new and old databases through the middleware layer includes: Collecting table structure data in the original database, wherein the table structure data includes table name, field name, field type and constraint conditions; Collecting table structure data in the new database, wherein the table structure data also includes table name, field name, field type and constraint conditions; Storing the table structure data of the original database and the new database to form a version knowledge base; Providing basic data for subsequent mapping rule generation through the version knowledge base; Establish corresponding version indexes for different versions of business software to quickly obtain adaptation information; The table structure data and the business software version are associated through the version index.

3. The method for mapping a dynamic database table structure of a middleware based on version awareness according to claim 1, characterized in that: Table structure information identifies structural inconsistencies between the old and new databases, including: Compare the table structure data of the new and old databases to determine if any fields are missing; Identify cases where fields are renamed; Determine the change of field type; Analyze the differences between table splits or merges; Detect differences in constraints; Through the above comparison and analysis, an inconsistency report is generated; Providing a basis for the formulation of subsequent mapping rules based on the inconsistency report; Storing the inconsistency report in a version knowledge base; Use dynamic programming algorithm to generate the optimal mapping path based on the dependency graph The topological sort of determines the execution order, where is a field node, is the dependency edge.

4. The method for mapping a dynamic database table structure of a middleware based on version awareness according to claim 1, characterized in that: Structural inconsistencies generate mapping rules, including: Formulate default value filling rules for missing fields; Generate name replacement rules for field renaming; Formulate type conversion rules for field type changes; Generate splitting or merging logic rules for table splitting or merging; Formulate constraint adaptation rules based on the differences in constraint conditions; Integrate the above rules into a complete mapping rule set; The mapping rule set is stored in a version knowledge base for dynamic invocation; Associating the mapping rule set according to the business software version index; Genetic algorithm is used to optimize the generation of mapping rules, and chromosome encoding is used as field mapping matrix , through the fitness function Iterative optimization, where .

5. The method for mapping a dynamic database table structure of a middleware based on version awareness according to claim 1, characterized in that: Mapping rules dynamically perform table structure mapping conversions at the middleware layer, including: Receive data requests from terminal business software; Parsing the data request to obtain the business software version number; Query the corresponding mapping rule according to the business software version number; Performing table structure conversion on the data request based on the mapping rule; Forward the converted data request to the new database; Get the data returned by the new database; Performing reverse conversion on the returned data according to the mapping rules; Send the reverse-converted data back to the terminal business software; During the low-frequency period of business data, the simulated annealing algorithm is used to smooth the transition rule, and the state transition probability is: ,in is the energy difference, is the temperature parameter.

6. The method for mapping a dynamic database table structure of a middleware based on version awareness according to claim 1, characterized in that: The mapped data is validated to ensure data integrity, including: Check whether the numerical range of the mapped data meets expectations; Determine whether there are unmapped inconsistencies; Verify that foreign key relationships remain intact; If the value range is found to be inconsistent with expectations, the relevant data will be remapped; If unmapped inconsistencies are found, the corresponding mapping rules are supplemented; If the foreign key relationship is incomplete, repair the relevant constraints; Through the above verification and repair, the business logic consistency of the mapped data is ensured; Record the verification results in a log for subsequent analysis; Use graph isomorphism algorithm to match the new and old table structure topology, and judge the consistency of foreign key relationship through subgraph isomorphism. The isomorphism condition is the existence of bijection satisfy ; in, : Represents the node set in the old database table structure topology diagram, Represents the node set in the new database table structure topology diagram, It is the set of edges in the old database table structure topology graph. is the set of edges in the new database table structure topology graph, Indicates that in the old table structure topology, the node and nodes There is an edge between them, that is, there is a foreign key association relationship between them.

7. The method for mapping a dynamic database table structure of a middleware based on version awareness according to claim 1, characterized in that: Logs mapping and transformation operations, including: Record the input data and output data of each mapping operation; Record the time and version information of each conversion operation; Record the calling of mapping rules; Record data verification results and repair actions; generating an operation report through the log; analyzing the applicability of the mapping rules according to the operation report; Optimizing the mapping rules based on the analysis results; Update the optimized mapping rules to the version knowledge base; Support subsequent troubleshooting and system improvements through the logs; Analyze time series patterns through LSTM neural networks.

8. The method for mapping a dynamic database table structure of a middleware based on version awareness according to claim 1, characterized in that: Dynamically perform table structure mapping conversion through the middleware layer, including: Update middleware programs during periods of low business data frequency; Implementing dynamic table structure mapping function through the middleware program; Receiving data requests from terminal devices; determining version information of the terminal device according to the data request; Calling corresponding mapping rules based on the version information; Convert the data request to adapt to the new database using the mapping rules; Get the response data of the new database; Performing adaptation processing on the response data according to the mapping rule; Returning the adapted response data to the terminal device; The above process enables old devices to seamlessly access the new database.

9. The method for mapping a dynamic database table structure of a middleware based on version awareness according to claim 1, characterized in that: When generating mapping rules, data anomalies are detected using the isolation forest algorithm, and the anomaly score is calculated as: ,in For samples The path length, is the average path length of the tree.

10. The method for mapping a dynamic database table structure of a middleware based on version awareness according to claim 9, characterized in that: The above mapping rules can be extended through configuration files or plug-ins, and semantic-level mapping extensions can be achieved based on the ontology mapping algorithm. The similarity calculation of ontology concepts is performed: ,in The lowest common ancestor.

Images