Heterogeneous database compatible adaptation method and system

Abstract

The application provides a heterogeneous database compatible adaptation method and system, relates to the technical field of database compatibility, and comprises the following steps: obtaining a data migration request containing a source database type identifier and a target database type identifier, and obtaining schema definition information of the source database; based on a preset type mapping rule, analyzing data type declaration, constraint conditions and index structures in the schema definition information, generating an intermediate representation structure, performing compatibility detection on each metadata unit in the intermediate representation structure, mapping incompatible metadata units into equivalent metadata expression forms supported by the target database, and maintaining semantic constraint relationships; finally, creating a database object based on a target schema definition, and establishing a data access adaptation layer. The application can realize efficient compatible adaptation between heterogeneous databases, and ensures the accuracy and integrity of data migration.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of database compatibility, in particular to a heterogeneous database compatibility adaptation method and system. BACKGROUND

[0002] With the in-depth development of enterprise informatization construction, database systems have become the core infrastructure supporting various business applications. In actual application scenarios, different enterprises or different business systems of the same enterprise often use different types of database products, such as relational databases, distributed databases, etc. Due to technical evolution, cost optimization, localization replacement and other needs, enterprises often face the needs of database migration and heterogeneous database integration. The existing database migration technology mainly uses a simple type mapping table for data type conversion, and lacks deep analysis capabilities for complex constraint conditions and index structures. This superficial mapping method cannot handle the unique data type characteristics, precision requirements and composite constraint relationships in the source database, resulting in the target database after migration being unable to completely retain the original data semantics and business rules, and easily causing problems such as data precision loss and constraint invalidation, affecting the normal operation of the business system.

[0003] When performing database migration, the traditional method usually only focuses on the conversion of static schema definitions, and ignores the compatibility problems at the runtime data access level. When the application program contains a large number of SQL statements specific to the syntax of the source database, these statements may not be executed correctly or may produce different execution results in the target database. The existing technology lacks a dynamic adaptation mechanism for runtime SQL statements, resulting in the need for large-scale code modification of the application system after completing the database migration, which is high in migration cost and has a high risk of business interruption.

[0004] The existing database compatibility detection method lacks systematicness and completeness, and can only find some obvious incompatible problems, and it is difficult to effectively identify hidden semantic differences, performance characteristic differences and special function support differences. This insufficient compatibility analysis can lead to omissions in the migration scheme, and compatibility problems are exposed only after actual deployment, which brings hidden dangers to system stability and data security, and increases the difficulty and cost of later maintenance and problem repair. SUMMARY

[0005] The embodiments of the present application provide a heterogeneous database compatibility adaptation method and system, which can solve the problems in the prior art.

[0006] In a first aspect of the embodiments of the present application, a heterogeneous database compatibility adaptation method is provided, comprising:

[0007] Obtaining a data migration request containing a source database type identifier and a target database type identifier, and obtaining schema definition information of the source database;

[0008] parsing the data type declaration, the constraint condition and the index structure in the schema definition information based on a preset type mapping rule to generate an intermediate representation structure;

[0009] performing compatibility detection on each metadata unit in the intermediate representation structure according to a corresponding syntax specification and characteristic set of the target database type identifier, identifying metadata units incompatible with the target database, and generating a compatibility analysis result;

[0010] According to the compatibility analysis result, by constructing a semantically equivalent conversion path, the incompatible metadata units are mapped to the equivalent metadata expression form supported by the target database, and the semantic constraint relationship of the metadata units in the source database is maintained, and a target schema definition is generated.

[0011] Based on the target schema definition, corresponding database objects are created in the target database, and a data access adaptation layer between the source database and the target database is established, and data operation statements for the target database are dynamically converted at runtime.

[0012] Based on the preset type mapping rule, the data type declaration, the constraint condition and the index structure in the schema definition information are parsed to generate an intermediate representation structure, which comprises:

[0013] For each data type declaration in the data type declaration set, determine its corresponding standardized type identifier according to the preset type mapping rule, and establish a mapping relationship between the data type declaration and the standardized type identifier to generate a type mapping table;

[0014] For each constraint condition in the constraint condition set, identify the constraint category and constraint scope of the constraint condition, and convert the constraint condition into a unified constraint expression to generate a constraint mapping table;

[0015] For each index structure in the index structure set, extract the index type, index field and index attribute of the index structure, and convert the index structure into a standardized index description to generate an index mapping table;

[0016] The type mapping table, the constraint mapping table and the index mapping table are assembled according to the association relationship between each metadata unit in the logical schema of the source database to generate the intermediate representation structure.

[0017] According to the corresponding syntax specification and characteristic set of the target database type identifier, the compatibility detection is performed on each metadata unit in the intermediate representation structure, the metadata units incompatible with the target database are identified, and the compatibility analysis result is generated, which comprises:

[0018] obtaining a syntax specification and a feature set corresponding to the target database type identifier, traversing each metadata unit in the intermediate representation structure, extracting metadata category and metadata attribute description of the metadata unit, the syntax specification including data type syntax definition, constraint syntax definition and index syntax definition supported by the target database, the feature set including functional feature identifiers supported by the target database;

[0019] matching the metadata attribute description with the syntax specification, determining whether the metadata unit conforms to the syntax specification, and comparing the functional features relied on by the metadata unit with the feature set, determining whether the target database supports the functional features relied on by the metadata unit, when the metadata unit does not conform to the syntax specification or the target database does not support the functional features relied on by the metadata unit, identifying the metadata unit as an incompatible metadata unit;

[0020] recording metadata identifier, incompatible type and incompatible reason of the incompatible metadata unit, and establishing dependency relationship record between the incompatible metadata unit and other metadata units in the intermediate representation structure, generating the compatibility analysis result.

[0021] mapping the incompatible metadata unit to an equivalent metadata expression form supported by the target database by constructing a semantically equivalent conversion path, and maintaining the semantic constraint relationship of the metadata unit in the source database, generating a target schema definition including:

[0022] extracting the semantic constraint relationship of the incompatible metadata unit from the intermediate representation structure, the semantic constraint relationship including data integrity constraint, reference constraint and business logic constraint of the incompatible metadata unit;

[0023] based on the incompatible type of the incompatible metadata unit and the semantic constraint relationship, determining a candidate metadata expression form semantically equivalent to the incompatible metadata unit from a set of metadata expression forms supported by the target database, and constructing a conversion path from the incompatible metadata unit to the candidate metadata expression form by analyzing the semantic difference between the candidate metadata expression form and the incompatible metadata unit;

[0024] verifying whether the candidate metadata expression form obtained through the conversion path maintains the semantic constraint relationship, when the candidate metadata expression form maintains the semantic constraint relationship, determining the candidate metadata expression form as an equivalent metadata expression form;

[0025] mapping the incompatible metadata unit into the equivalent metadata expression form and marking the implementation mode of the semantic constraint relationship in the equivalent metadata expression form to generate a converted metadata unit.

[0026] establishing a data access adaptation layer between the source database and the target database, and dynamically converting a data operation statement for the target database at runtime includes:

[0027] based on the intermediate representation structure and the target schema definition, establishing a bidirectional mapping relationship between the metadata unit of the source database and the metadata unit of the target database, and recording a conversion rule corresponding to each bidirectional mapping relationship;

[0028] deploying a data access adaptation layer between the source database and the target database, the data access adaptation layer storing the bidirectional mapping relationship and the conversion rule;

[0029] when receiving a data operation statement for the target database, intercepting the data operation statement through the data access adaptation layer, and parsing the data operation statement to extract a target metadata identifier and an operation type involved in the data operation statement;

[0030] According to the target metadata identifier, query the source metadata identifier corresponding to the target metadata identifier from the bidirectional mapping relationship, and obtain the conversion rule between the target metadata identifier and the source metadata identifier;

[0031] According to the conversion rule and the operation type, the expression form based on the target database syntax in the data operation statement is converted into the equivalent expression form based on the source database syntax, and according to the semantic constraint relationship recorded in the intermediate representation structure, the constraint verification logic required by the source database is supplemented in the equivalent expression form, and a converted data operation statement is generated.

[0032] According to the target metadata identifier, query the source metadata identifier corresponding to the target metadata identifier from the bidirectional mapping relationship, and obtain the conversion rule between the target metadata identifier and the source metadata identifier includes:

[0033] extracting a database object type identifier and an object qualified name in the target metadata identifier;

[0034] based on the database object type identifier, locating a mapping relationship subset corresponding to the database object type identifier in the bidirectional mapping relationship, and in the mapping relationship subset, retrieving a mapping relationship record matching the target metadata identifier according to the object qualified name;

[0035] extracting a source metadata identifier corresponding to the target metadata identifier from the mapping relationship record;

[0036] extracting a conversion rule between the target metadata identifier and the source metadata identifier from the mapping relationship record, the conversion rule including a type conversion rule, a constraint conversion rule and a syntax conversion rule, wherein the type conversion rule defines a mapping manner between a data type of the target database and a data type of the source database, the constraint conversion rule defines a conversion manner between a constraint expression of the target database and a constraint expression of the source database, and the syntax conversion rule defines a conversion manner between an operation syntax of the target database and an operation syntax of the source database.

[0037] In a second aspect of the embodiment of the present application, a heterogeneous database compatible adaptation system is provided, comprising:

[0038] a first unit configured to acquire a data migration request containing a source database type identifier and a target database type identifier, and acquire schema definition information of the source database;

[0039] a second unit configured to parse data type declarations, constraint conditions and index structures in the schema definition information based on a preset type mapping rule, and generate an intermediate representation structure;

[0040] a third unit configured to perform compatibility detection on each metadata unit in the intermediate representation structure according to a syntax specification and a characteristic set corresponding to the target database type identifier, identify metadata units incompatible with the target database, and generate a compatibility analysis result;

[0041] a fourth unit configured to map the incompatible metadata units to an equivalent metadata expression form supported by the target database by constructing a semantically equivalent conversion path according to the compatibility analysis result, maintain semantic constraint relationships of the metadata units in the source database, and generate a target schema definition;

[0042] a fifth unit configured to create corresponding database objects in the target database based on the target schema definition, establish a data access adaptation layer between the source database and the target database, and dynamically convert data operation statements for the target database at runtime.

[0043] In a third aspect of the embodiment of the present application, a heterogeneous database compatible adaptation method is provided, comprising:

[0044] An electronic device is provided, comprising:

[0045] a processor;

[0046] a memory for storing processor-executable instructions;

[0047] The processor is configured to invoke instructions stored in the memory to perform the method described above.

[0048] A fourth aspect of the embodiments of the present application,

[0049] A computer readable storage medium is provided, which stores computer program instructions. The computer program instructions are executed by a processor to implement the method described above.

[0050] The present application introduces an intermediate representation structure as a bridge between the source database and the target database, realizes the standardized abstract expression of the database schema definition, effectively decouples the direct dependency relationship between the source database and the target database, so that the data migration process is no longer limited to point-to-point conversion between specific database types, and the scalability and universality of the data migration scheme are significantly improved. The differences between the source database and the target database in terms of data types, constraint conditions and index structures can be accurately identified, and the intelligent mapping of incompatible metadata can be realized by constructing a semantically equivalent conversion path. The semantic constraint relationship of the metadata unit in the source database is maintained during the conversion process, ensuring that the target database after migration can accurately restore the business logic and data integrity requirements of the source database, effectively avoiding the problems of data loss or semantic deviation caused by database differences. By establishing a data access adaptation layer between the source database and the target database, the application system can transparently access the target database without modifying the original data access code, reducing the impact of database migration on the upper application system, reducing the workload and technical risk of system modification, and supporting the progressive migration strategy, providing a more smooth and low-risk database upgrade and replacement path for enterprises. BRIEF DESCRIPTION OF DRAWINGS

[0051] Figure 1 The flowchart of the heterogeneous database compatibility adaptation method of the embodiments of the present application. DETAILED DESCRIPTION

[0052] To make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions of the embodiments of the present application will be described in detail below with reference to the drawings of the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, not all embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0053] The technical solutions of the present application will be described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments.

[0054] Figure 1 A flowchart of a heterogeneous database compatible adaptation method for an embodiment of the present application is shown in FIG. 1. As shown, the method comprises: Figure 1

[0055] obtaining a data migration request containing a source database type identifier and a target database type identifier, and obtaining schema definition information of the source database;

[0056] parsing data type declarations, constraint conditions and index structures in the schema definition information based on a preset type mapping rule, to generate an intermediate representation structure;

[0057] performing compatibility detection on each metadata unit in the intermediate representation structure according to a syntax specification and a characteristic set corresponding to the target database type identifier, identifying metadata units incompatible with the target database, and generating a compatibility analysis result;

[0058] According to the compatibility analysis result, mapping the incompatible metadata units into an equivalent metadata expression form supported by the target database through constructing a semantically equivalent conversion path, and maintaining the semantic constraint relationship of the metadata units in the source database, to generate a target schema definition;

[0059] creating corresponding database objects in the target database based on the target schema definition, and establishing a data access adaptation layer between the source database and the target database, to dynamically convert data operation statements for the target database at runtime.

[0060] In an optional implementation, parsing data type declarations, constraint conditions and index structures in the schema definition information based on a preset type mapping rule to generate an intermediate representation structure comprises:

[0061] For each data type declaration in the set of data type declarations, determining a corresponding standardized type identifier according to the preset type mapping rule, and establishing a mapping relationship between the data type declaration and the standardized type identifier to generate a type mapping table;

[0062] For each constraint condition in the set of constraint conditions, identifying the constraint category and constraint scope of the constraint condition, and converting the constraint condition into a unified constraint expression to generate a constraint mapping table;

[0063] For each index structure in the set of index structures, extracting the index type, index field and index attribute of the index structure, and converting the index structure into a standardized index description to generate an index mapping table;

[0064] ​The type mapping table, the constraint mapping table and the index mapping table are assembled according to the association relationship between each metadata unit in the logical schema of the source database to generate the intermediate representation structure.

[0065] In the database migration process, the schema definition information of the source database needs to be deeply parsed and converted into an intermediate representation structure. The process starts from obtaining the complete schema definition information of the source database, which includes data table structure, field definition, constraint rule and index configuration, and other core elements. The system pre-configures a type mapping rule library, which stores the corresponding relationship between the data types of various database systems and the standardized types.

[0066] In the processing process of data type declaration, the parser traverses each data table in the schema definition information and extracts the data type declaration of each field in the table one by one. Taking the user information table as an example, the table contains the user identification field declaration as an integer type, the user name field declaration as a variable length character type with a maximum length of 50 characters, the registration time field declaration as a timestamp type, and the account balance field declaration as a decimal numerical type with a precision of ten integer digits and two decimal places. After the parser reads the integer type declaration, it looks up the matching item in the type mapping rule library to determine that its standardized type identifier is INT32, which represents a 32-bit signed integer. For the declaration of the variable length character type with a maximum length of 50, the parser identifies that the base type is a variable string and the length constraint is 50. After mapping rule matching, the standardized type identifier VARCHAR is generated with the length parameter 50. The timestamp type is converted to the TIMESTAMP standard type after mapping, and the decimal numerical type is converted to the DECIMAL standard type according to the precision parameter and retains the precision information ten and the scale information two. The parser establishes a key-value pair relationship between the original data type declaration and the corresponding standardized type identifier and records it in the type mapping table. The mapping table uses a three-column structure to store information, the first column records the complete path of the field including the table name and the field name, the second column records the complete text of the original type declaration, and the third column records the converted standardized type identifier and its parameters.

[0067] The parsing process of the constraint condition needs to identify different levels of constraint rules. Scan the constraint condition set in the schema definition information and extract the definition statement of each constraint condition. Taking the constraint definition of the order table as an example, the table has a primary key constraint declaration that the order number field is the primary key, a unique constraint declaration that the order serial number field value is unique, a foreign key constraint declaration that the customer identifier field references the customer number field of the customer table, a non-empty constraint declaration that the order amount field is not allowed to be empty, and a check constraint declaration that the value of the order status field must be within the range of three enumerated values: to be paid, paid, and canceled.

[0068] When the parser processes the primary key constraint, it identifies the constraint category as PRIMARY KEY and the constraint scope as the order number single field. The generated unified constraint expression format is constraint type plus field list plus additional conditions, and the specific content is PRIMARY KEY acting on the order number field without additional conditions. When processing the uniqueness constraint, the parser identifies the constraint category as UNIQUE and the scope as the order serial number field. The generated constraint expression is UNIQUE acting on the order serial number field. The processing of the foreign key constraint is more complex. The parser identifies the constraint category as FOREIGN KEY, extracts the referencing relationship of the table field customer identifier, the referenced table name customer table, and the referenced field customer number. It also identifies the cascade operation rules including delete when cascading deletion and update when cascading update. It organizes this information into a structured constraint expression FOREIGN KEY acting on the customer identifier field referencing the customer table dot customer number field with additional delete and update cascade operations. To check the constraint, the parser needs to parse the specific check logic expression. It extracts the value domain restriction condition of the order status field and converts it into a CHECK constraint expression acting on the order status field with the value belonging to the set of to be paid, paid, and canceled. All the converted constraint expressions are organized into a constraint mapping table according to the table name, constraint name, constraint category, action field, and constraint expression structure.

[0069] The processing of the index structure involves the identification and conversion of multiple index types. The parser extracts the index structure set from the schema definition information and analyzes the definition statement of each index. Taking the index configuration of the commodity table as an example, the table creates a normal index acting on the commodity name field to speed up the query by name, a unique index acting on the commodity code field to ensure the uniqueness of the code, a composite index acting on the classification identifier and on-shelf time two fields to support combined queries, and a full-text index acting on the commodity description field to support text retrieval. When the parser processes the normal index, it identifies the index type as BTREE, the index field as the commodity name single field, and the index attributes including the index method as balanced tree, the sorting direction as ascending, and whether it is unique as no. After extracting this information, it generates a standardized index description containing the index name, the index type identifier BTREE, the field list containing the commodity name, the sorting rule ascending, and the uniqueness identifier no. The processing of the composite index needs to maintain the field order. The parser maintains the order relationship when generating the standardized index description by taking the classification identifier as the first index field and the on-shelf time as the second index field, and records the sorting direction for each field. The conversion of the full-text index needs to identify the special index method. The parser maps the full-text index type to the FULLTEXT standard type and records that it acts on the commodity description field and uses the text analyzer. The index mapping table uses a multi-column structure to store, including the table name to which the index belongs, the index name, the standardized index type, the index field list and order, the sorting rule of each field, the index attribute parameters, and other information.

[0070] After the generation of the three types of mapping tables, these independent mapping tables need to be assembled according to the association relationship in the source database logical mode. The assembly process takes the data table as the core node, and associates the type mapping record, the constraint mapping record, and the index mapping record related to the table to the corresponding table node. Taking the order table as an example, all records of the table name order table are retrieved from the type mapping table, and the type mapping information of each field of the table is extracted to form a field definition set. All constraint records of the order table are retrieved from the constraint mapping table, and the primary key constraint, the foreign key constraint, the check constraint, etc. are grouped according to the constraint category and attached to the table structure. The index definition of the order table is retrieved from the index mapping table, and each index description is attached to the index configuration part of the table structure. The table object structure is constructed, which includes the table basic information layer record table name and table attribute, the field definition layer includes the field list and the type mapping information of each field, the constraint definition layer includes the expression set of each type of constraint, and the index definition layer includes the index description set. When processing the foreign key constraint, the assembler identifies the two tables involved in the reference relationship, establishes a reference link between the table objects, and records the relationship that the order table references the customer table through the customer identifier field. After traversing all data tables to complete the construction of each table object, the table objects are organized into a graph structure according to the reference relationship, the nodes in the graph represent the data table objects, and the edges represent the reference relationship between the tables, and finally a complete intermediate representation structure is formed, which completely retains the logical mode information of the source database and adopts a standardized description method to facilitate subsequent target database adaptation processing.

[0071] In an optional implementation, according to the syntax specification and the feature set corresponding to the target database type identifier, compatibility detection is performed on each metadata unit in the intermediate representation structure, incompatible metadata units are identified, and a compatibility analysis result is generated, including:

[0072] The syntax specification includes the data type syntax definition, the constraint syntax definition, and the index syntax definition supported by the target database, and the feature set includes the functional feature identifier supported by the target database.

[0073] The metadata attribute description is matched with the syntax specification to determine whether the metadata unit conforms to the syntax specification, and the functional features relied on by the metadata unit are compared with the feature set to determine whether the target database supports the functional features relied on by the metadata unit. When the metadata unit does not conform to the syntax specification or the target database does not support the functional features relied on by the metadata unit, the metadata unit is identified as an incompatible metadata unit.

[0074] The metadata identifier, incompatible type and incompatible reason of the incompatible metadata unit are recorded, and the dependency record between the incompatible metadata unit and other metadata units in the intermediate representation structure is established, to generate the compatibility analysis result.

[0075] In the database migration process, the complete syntax specification and feature set corresponding to the target database type identifier are loaded from the configuration storage module. The syntax specification is stored in a structured data form, including three main parts: data type syntax definition, constraint syntax definition and index syntax definition. The data type syntax definition records all data types supported by the target database and their parameter ranges, for example, the character types supported by a certain target database include VARCHAR type with maximum length of 8000 characters, and TEXT type without length limit but not supported as primary key.

[0076] The constraint syntax definition records the support and syntax requirements of the CHECK constraint, UNIQUE constraint and FOREIGNKEY constraint of the target database, for example, the CHECK constraint of a certain database does not support subquery expressions. The index syntax definition records the index types supported by the target database and the creation syntax, for example, a certain database supports BTREE index and HASH index but does not support full-text index. The feature set is stored in the form of a list of functional feature identifiers, including partition table support, materialized view support, trigger support, storage procedure syntax version and other functional feature identifiers.

[0077] The traversal program of the intermediate representation structure is started, and each metadata unit is accessed in turn according to the order of table definition, field definition, constraint definition, index definition, view definition and storage procedure definition. For each metadata unit, the metadata category attribute and metadata attribute description are extracted by the parsing program. Taking the field F_CREATE_TIME of the table T_ORDER as an example, the extracted metadata category is field definition, and the metadata attribute description contains attribute information such as data type DATETIME, precision 6, whether nullable FALSE, default value CURRENT_TIMESTAMP, and automatic setting of current timestamp when updating. For the metadata unit of constraint definition type, such as the constraint CK_PRICE on the table T_PRODUCT, the extracted metadata attribute description contains constraint type CHECK, constraint expression price greater than 0 and price less than or equal to 999999.99, and constraint effective time for insertion and update operations.

[0078] The extracted metadata attribute description is matched with the syntax specification of the target database item by item. Taking field F_CREATE_TIME as an example, the detection program queries the data type syntax definition of the target database to find out whether there is a DATETIME type and whether the precision parameter 6 is supported. If the target database only supports the DATETIME type but does not support the precision parameter, or only supports the TIMESTAMP type, it is determined that the data type definition of the field does not conform to the syntax specification. The detection program further verifies the syntax representation of the default value CURRENT_TIMESTAMP in the target database. If the target database uses the GETDATE function to represent the current time instead of the CURRENT_TIMESTAMP keyword, it is determined that the default value syntax does not conform to the specification. For the feature of automatically setting the timestamp when updating, the detection program needs to query whether the target database supports the ON UPDATE clause. If it does not support it, it is determined that the attribute definition does not conform to the syntax specification.

[0079] In the detection process of the constraint CK_PRICE, the detection program analyzes the operators and numerical ranges used in the constraint expression. If the CHECK constraint syntax of the target database requires the use of the AND keyword to connect multiple conditions and does not support the BETWEEN syntax, the detection program needs to verify whether the expression syntax format meets the requirements. The detection program also needs to verify whether the target database supports the comparison of boundary values of decimal types in the CHECK constraint. If the constraint expression contains references to other tables or uses subqueries, and the constraint syntax definition of the target database explicitly states that it does not support such complex expressions, it is determined that the constraint definition does not conform to the syntax specification.

[0080] For each metadata unit, identify the functional features it depends on, and establish a mapping relationship of functional feature dependencies. For the partition table T_LOG, its metadata attribute description contains the definition of RANGE partitioning by the date field, and the detection program identifies that the table depends on the partition table functional feature. The detection program searches for the partition table support identifier in the feature set of the target database. If the feature set does not contain the identifier, it is determined that the target database does not support the functional feature that the metadata unit depends on.

[0081] For the materialized view MV_SALES_SUMMARY, the detection program identifies that it depends on the materialized view functional feature and the automatic refresh mechanism feature. If the target database only supports materialized views but does not support the automatic refresh mechanism, it is determined that part of the functional features are not supported.

[0082] For the stored procedure P_CALCULATE_TOTAL, the detection program analyzes the cursor syntax, exception handling syntax, and dynamic SQL syntax used inside it, identifies multiple functional features it depends on, and verifies them one by one with the feature set of the target database.

[0083] When the detection program determines that a metadata unit does not conform to the syntax specification or the target database does not support the functional features it depends on, the metadata unit is immediately identified as an incompatible metadata unit. Detailed incompatible records are generated for each incompatible metadata unit, recording the metadata identification, incompatible type, and incompatible reason as the three core elements.

[0084] Taking field F_CREATE_TIME as an example, the generated incompatible record has metadata identification T_ORDER.F_CREATE_TIME, incompatible type data type incompatible and default value syntax incompatible, and incompatible reason description target database does not support the precision parameter of DATETIME type and uses GETDATE function instead of CURRENT_TIMESTAMP keyword. For constraint CK_PRICE, the incompatible record has metadata identification T_PRODUCT.CK_PRICE, incompatible type constraint expression syntax incompatible, and incompatible reason description target database CHECK constraint does not support decimal boundary value comparison operation in complex expression.

[0085] A dependency relationship analysis module is constructed to traverse all metadata units in the intermediate representation structure, identify the reference relationship and dependency relationship between the metadata units. Foreign key constraint FK_ORDER_USER defines that field F_USER_ID of table T_ORDER references the primary key field of table T_USER, and dependency relationship analysis module records that the foreign key constraint depends on the primary key index of table T_USER.

[0086] The definition of view V_ORDER_DETAIL references multiple fields of table T_ORDER and table T_PRODUCT, and the analysis module records that the view depends on the field definitions of the two tables.

[0087] The stored procedure P_UPDATE_STOCK internally operates table T_INVENTORY and calls function F_CHECK_QUANTITY, and the analysis module records that the stored procedure depends on the table definition and function definition.

[0088] For each incompatible metadata unit, extract its direct dependency and dependent metadata units list from dependency records. If field F_CREATE_TIME is identified as incompatible, find the dependency records of this field as dependee, find index IDX_ORDER_TIME depends on this field, find view V_RECENT_ORDER's query condition references this field, find trigger TRG_ORDER_LOG reads this field value in trigger logic. Integrate these dependencies into the incompatible record of this field, build the complete dependency chain. For incompatible materialized view MV_SALES_SUMMARY, record its dependent base tables include T_ORDER and T_ORDER_ITEM, and record the report query program identification that depends on this materialized view.

[0089] Summarize all incompatible metadata unit records and their dependency records, generate structured compatibility analysis result dataset. The dataset is organized in a hierarchical structure, the top layer is the list of incompatible metadata units, each metadata unit node contains incompatible type, incompatible reason, other metadata units that depend on this unit, and other metadata units that this unit depends on. The compatibility analysis result also contains statistical information, recording the total number of incompatible metadata units, the distribution of incompatible numbers grouped by metadata categories, and the problem distribution grouped by incompatible types. The compatibility analysis result is persisted and returned to the migration process control module, providing decision basis for subsequent conversion rule matching and code conversion.

[0090] In an optional implementation, by constructing a semantically equivalent conversion path, the incompatible metadata unit is mapped to an equivalent metadata expression form supported by the target database, and the semantic constraint relationship of the metadata unit in the source database is maintained, and the target schema definition is generated, including:

[0091] Extracting the semantic constraint relationship of the incompatible metadata unit from the intermediate representation structure, the semantic constraint relationship includes data integrity constraint, reference constraint and business logic constraint of the incompatible metadata unit;

[0092] Based on the incompatible type of the incompatible metadata unit and the semantic constraint relationship, determine the candidate metadata expression form semantically equivalent to the incompatible metadata unit from the set of metadata expression forms supported by the target database, and construct a conversion path from the incompatible metadata unit to the candidate metadata expression form by analyzing the semantic difference between the candidate metadata expression form and the incompatible metadata unit;

[0093] verifying whether the candidate metadata representation form obtained through the conversion path maintains the semantic constraint relationship, and determining the candidate metadata representation form as an equivalent metadata representation form when the candidate metadata representation form maintains the semantic constraint relationship;

[0094] mapping the incompatible metadata unit into the equivalent metadata representation form, and marking the implementation of the semantic constraint relationship in the equivalent metadata representation form, to generate a converted metadata unit.

[0095] In the implementation of the database migration process, for the incompatible metadata unit existing in the source database Oracle, it is necessary to map it into the equivalent metadata representation form supported by the target database MySQL through the construction of a semantically equivalent conversion path. When a table structure containing a custom data type is defined in the source database, for example, a table named EMPLOYEE is defined, which contains a field EMP_ID of the NUMBER type, a field EMP_NAME of the VARCHAR2 type, and a field HIRE_DATE of the DATE type, and the table also defines a CHECK constraint to ensure that the value of the HIRE_DATE field cannot be earlier than a certain specific date, and a foreign key constraint is associated with the DEPT_ID field of the DEPARTMENT table. When the complete semantic constraint relationship of the incompatible metadata unit is extracted from the intermediate representation structure, it is necessary to parse the data integrity constraint including the primary key constraint defining EMP_ID as the primary key and self-incrementing, and the non-empty constraint requiring the EMP_NAME field to be non-empty. The reference constraint part includes the foreign key DEPT_ID referencing the primary key field of the DEPARTMENT table, and sets the ON DELETE CASCADE and ON UPDATE RESTRICT cascade deletion and update rules. The business logic constraint part includes the CHECK constraint verifying that HIRE_DATE must be greater than or equal to the date of establishment of the enterprise, and the trigger logic automatically updates the total number of employees in the department field when a new employee record is inserted.

[0096] In the determination of incompatible types, it is found by analysis that the NUMBER type has no direct corresponding data type in the target database, the VARCHAR2 type needs to be converted to the VARCHAR type, and the precision range of the DATE type is different. Based on these incompatible types and the extracted semantic constraint relationships, candidate schemes are retrieved in the set of metadata expression forms supported by the target database. For the field EMP_ID of the NUMBER type, the candidate metadata expression forms include the INT type with the AUTO_INCREMENT attribute, the BIGINT type with the AUTO_INCREMENT attribute, and the DECIMAL type with specified precision and decimal places. For the field EMP_NAME of the VARCHAR2 type, the candidate metadata expression form is the VARCHAR type with the same length limit. For the field HIRE_DATE of the DATE type, the candidate metadata expression forms include the DATE type, the DATETIME type, and the TIMESTAMP type.

[0097] In the analysis of the semantic differences between the candidate metadata expression forms and the incompatible metadata units, for the EMP_ID field, the value range of the INT type is -2 31 to 2 31 -1, the value range of the BIGINT type is larger, and the DECIMAL type can accurately control the precision and decimal places of the value. The NUMBER type in the source database supports up to thirty-eight significant digits by default, so it is necessary to evaluate the value range of the employee number in the actual business scenario. Through analysis of historical data and business growth prediction, it is determined that the employee number will not exceed ten million, so the INT type can meet the value range requirement. For the VARCHAR2 type, it uses byte length calculation in the source database, while the VARCHAR type of the target database uses character length calculation, so the length parameter needs to be adjusted according to the character encoding method. When the source database uses UTF8 encoding and the field length is defined as one hundred bytes, the target database should adjust the length to thirty-three characters to ensure that the same number of multi-byte characters can be stored. For the DATE type, the source database supports time precision to the second level, while the DATETIME type of the target database supports to the microsecond level, the DATE type only supports the date part without time information, and the TIMESTAMP type supports time zone information but has specific time range limitations.

[0098] When constructing the conversion path from the incompatible metadata units to the candidate metadata table expression form, the conversion path is established for the EMP_ID field to convert the NUMBER type to the INT type and add the UNSIGNED modifier to extend the range of positive numbers, while adding the AUTO_INCREMENT attribute to maintain the auto-increment feature. The conversion path is established for the EMP_NAME field to convert the VARCHAR2 type of one hundred bytes to the VARCHAR type of thirty-three characters, while maintaining the NOT NULL constraint. The conversion path is established for the HIRE_DATE field to convert the DATE type to the DATETIME type to maintain the integrity of the time information. The conversion path is established for the CHECK constraint to create a trigger to implement the business date validation logic, as the older version of the target database does not directly support the CHECK constraint syntax. The conversion path is established for the foreign key constraint to define the reference relationship using the FOREIGN KEY syntax, and directly map the ON DELETE CASCADE and ON UPDATE RESTRICT rules to the corresponding syntax of the target database.

[0099] When verifying the correctness of the conversion path, a test data set is constructed for semantic equivalence checking. A test data set containing one thousand employee records is created, with the EMP_ID values ranging from 1-1000, the EMP_NAME containing various length and character type employee names, and the HIRE_DATE covering all time points from the date of establishment of the enterprise to the current date. The test data is inserted into the original table structure of the source database and the converted table structure of the target database respectively, to verify whether the data integrity constraints are maintained. When testing the primary key constraint, a duplicate EMP_ID value is attempted to be inserted, to verify whether the system correctly rejects the operation. When testing the non-null constraint, an empty value for the EMP_NAME is attempted to be inserted, to verify whether the system correctly rejects the operation. When testing the CHECK constraint, a record with the HIRE_DATE earlier than the date of establishment of the enterprise is attempted to be inserted, to verify whether the trigger is correctly triggered and prevents the operation. When testing the foreign key constraint, a DEPT_ID value that does not exist is attempted to be inserted, to verify whether the system correctly rejects the operation. When testing the cascading deletion rule, a certain department record in the DEPARTMENT table is deleted, to verify whether the associated employee records are automatically deleted. When testing the cascading update rule, an attempt is made to update the primary key value in the DEPARTMENT table, to verify whether the system correctly rejects the operation.

[0100] When all the validation tests pass, the candidate metadata representation is determined as the equivalent metadata representation. When mapping the incompatible metadata units to the equivalent metadata representation, the DDL statements defining the structure of the EMPLOYEE table for the target database are generated, in which the EMP_ID field is defined as INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, the EMP_NAME field is defined as VARCHAR thirty-three characters NOT NULL, and the HIRE_DATE field is defined as DATETIME NOT NULL. The implementation of the semantic constraint relationship is marked in the equivalent metadata representation, and the CHECK constraint is recorded to be implemented through a BEFORE INSERT trigger named TRG_CHECK_HIRE_DATE, and the trigger code contains the condition judgment logic to compare the HIRE_DATE value of the newly inserted record with the establishment date constant of the enterprise.

[0101] The foreign key constraint is recorded to be implemented through the CONSTRAINT FK_EMP_DEPT FOREIGN KEY statement, which specifies that the DEPT_ID field refers to the DEPT_ID primary key field of the DEPARTMENT table, and sets the ON DELETE CASCADE and ON UPDATE RESTRICT options. The self-increment attribute is implemented through the AUTO_INCREMENT keyword, and the initial value is set to one. The converted metadata units containing all these definition information are generated and stored in the data structure defined by the target schema for subsequent data migration stages.

[0102] In an optional implementation, a data access adaptation layer between the source database and the target database is established, and dynamically converting the data operation statement for the target database at runtime includes:

[0103] Based on the intermediate representation structure and the target schema definition, a bidirectional mapping relationship between the metadata units of the source database and the metadata units of the target database is established, and the conversion rule corresponding to each bidirectional mapping relationship is recorded;

[0104] A data access adaptation layer between the source database and the target database is deployed, and the data access adaptation layer stores the bidirectional mapping relationship and the conversion rule;

[0105] When receiving a data operation statement for the target database, the data operation statement is intercepted through the data access adaptation layer, and the target metadata identifier and the operation type involved in the data operation statement are extracted by parsing the data operation statement;

[0106] According to the target metadata identifier, a source metadata identifier corresponding to the target metadata identifier is queried from the bidirectional mapping relationship, and a conversion rule between the target metadata identifier and the source metadata identifier is obtained;

[0107] According to the conversion rule and the operation type, an expression form based on the target database syntax in the data operation statement is converted into an equivalent expression form based on the source database syntax, and constraint verification logic required by the source database is supplemented in the equivalent expression form according to a semantic constraint relationship recorded in the intermediate representation structure, to generate a converted data operation statement.

[0108] When establishing a data access adaptation layer between the source database and the target database, the metadata structures of the two database systems need to be deeply analyzed. Taking a relational database as an example, the source database includes a data table with a table name of "employee_records", which includes fields of "emp_id", "full_name", "hire_date" and "salary_amount". In the target database, the corresponding data table name is "EmployeeInfo", and the field names are "id", "name", "joinDate" and "payAmount" respectively. Through the intermediate representation structure, a one-to-one mapping relationship is established between each metadata unit of the source database and the metadata unit of the target database. In specific implementation, the table-level mapping relationship is recorded as "employee_records" mapping to "EmployeeInfo", and the field-level mapping relationship is recorded as "emp_id" mapping to "id", "full_name" mapping to "name", "hire_date" mapping to "joinDate", and "salary_amount" mapping to "payAmount".

[0109] At the same time of establishing the mapping relationship, the conversion rule corresponding to each mapping relationship needs to be recorded. For the mapping of the field "hire_date" to "joinDate", since the source database stores the date in the format of "YYYY-MM-DD" and the target database uses the timestamp format, the calling mode of the date format conversion function needs to be recorded in the conversion rule. For the mapping of the field "salary_amount" to "payAmount", the source database uses the DECIMAL type with a precision of two decimal places, and the target database uses the floating point type, so the conversion rule needs to include the data type conversion logic and the precision processing mode. These conversion rules are stored in the form of structured data, including key information such as source field identifier, target field identifier, data type conversion function, format conversion function, default value processing strategy and null value processing strategy.

[0110] The deployment position of the data access adaptation layer is in the communication link between the application program and the database system. The adaptation layer is implemented as an independent service component, which listens to the standard access port of the target database. When the application program initiates a database connection request, the adaptation layer takes over the connection and establishes an actual connection with the source database. The adaptation layer internally maintains a mapping relationship storage module and a conversion rule execution module. The mapping relationship storage module adopts a hash table structure, taking the target metadata identifier as the key and the source metadata identifier and the conversion rule as the value, supporting fast query operations. The conversion rule execution module includes three sub-components: a syntax parser, a statement rewriter, and a constraint verifier.

[0111] When the application program sends a data operation statement to the target database, the interception mechanism of the adaptation layer immediately captures the statement. Assuming that the query statement sent by the application program is "SELECT id, name, joinDate FROM EmployeeInfo WHERE payAmount>5000", the syntax parser of the adaptation layer performs lexical analysis and syntax analysis on the statement. In the lexical analysis stage, the statement is decomposed into basic units such as the keyword "SELECT", the identifier "id", the identifier "name", the identifier "joinDate", the keyword "FROM", the identifier "EmployeeInfo", the keyword "WHERE", the identifier "payAmount", the operator ">", and the numerical value "5000". In the syntax analysis stage, the abstract syntax tree of the statement is constructed, and it is identified that the statement is a query operation, involving the target metadata including the table "EmployeeInfo" and the fields "id", "name", "joinDate", and "payAmount", the operation type is data query, and the filter condition is "payAmount>5000".

[0112] After the target metadata is identified, the adaptation layer accesses the mapping relationship storage module for querying. Taking the table identifier "EmployeeInfo" as the query key, the corresponding source table identifier "employee_records" is obtained. Taking the field identifier "id" as the query key, the source field identifier "emp_id" is obtained, and at the same time, the conversion rule corresponding to the mapping relationship is obtained. The rule content indicates that both fields are integer types and do not need data format conversion. The field identifier "name" is queried to obtain the source field identifier "full_name", and the conversion rule indicates that both are string types. The field identifier "joinDate" is queried to obtain the source field identifier "hire_date", and the conversion rule indicates that the timestamp format needs to be converted to the date format. The field identifier "payAmount" is queried to obtain the source field identifier "salary_amount", and the conversion rule indicates that the float number needs to be converted to the DECIMAL type.

[0113] The statement rewriter converts the original data operation statement to an equivalent expression form based on the source database syntax according to the obtained mapping relationship and conversion rule. The table name "EmployeeInfo" is replaced by "employee_records", the field name "id" is replaced by "emp_id", the field name "name" is replaced by "full_name", the field name "joinDate" is replaced by "hire_date", and the field name "payAmount" is replaced by "salary_amount". For fields involving data format conversion, the corresponding conversion function call is added in the SELECT clause. For the "hire_date" field, since the target database expects to receive the timestamp format, the rewritten statement modifies the reading expression of the field to the function call form to convert the date value to the timestamp. For the "salary_amount" field, the numerical comparison logic remains unchanged in the WHERE clause, because numerical comparison has equivalence between the two data types.

[0114] The constraint validator supplements the constraint validation logic required by the source database in the transformed statement based on the semantic constraint relationships recorded in the intermediate representation structure. The intermediate representation structure records the integrity constraints for the "employee_records" table in the source database, including that the "emp_id" field is the primary key and cannot be null, and that the "salary_amount" field must be greater than zero and not exceed a certain upper limit value. For the query operation, the constraint validator adds implicit filter conditions in the WHERE clause to ensure that the returned data rows satisfy these constraints. The transformed complete statement is in the form of "SELECT emp_id, full_name, CONVERT_TO_TIMESTAMP(hire_date), salary_amount FROM employee_records WHERE salary_amount > 5000 AND emp_id IS NOT NULL AND salary_amount > 0 AND salary_amount <= 999999", where the supplemented constraint conditions "emp_id IS NOT NULL", "salary_amount > 0", and "salary_amount <= 999999" are from the metadata definition of the source database.

[0115] For data insertion operation, the conversion process is more complex. Assuming the application sends the insert statement "INSERT INTO EmployeeInfo (id, name, joinDate, payAmount) VALUES(1001, 'John Smith', 1609459200, 6000)", the adaptation layer parses and identifies the operation type as insert, involving the target metadata and the insert value list. Through mapping relationship query and conversion rule application, the table name is converted to "employee_records", the field names are replaced one by one according to the mapping relationship, the timestamp value 1609459200 is converted to the date format "2021-01-01", and the numerical value 6000 remains unchanged but the data type is converted to DECIMAL. The constraint verifier checks whether the insert value meets the constraint condition of the source database, verifies that the "emp_id" value 1001 is not empty and does not conflict with the existing record, and verifies that the "salary_amount" value 6000 is greater than zero and less than the upper limit value. The converted statement is "INSERT INTO employee_records(emp_id, full_name, hire_date, salary_amount) VALUES (1001, 'John Smith', '2021-01-01', 6000.00)", which meets the syntax specification and constraint requirements of the source database and can be correctly executed by the source database.

[0116] In an optional implementation, according to the target metadata identifier, the source metadata identifier corresponding to the target metadata identifier is queried from the bidirectional mapping relationship, and the conversion rule between the target metadata identifier and the source metadata identifier is obtained, comprising:

[0117] Extracting the database object type identifier and object qualified name in the target metadata identifier;

[0118] Based on the database object type identifier, the mapping relationship subset corresponding to the database object type identifier is located in the bidirectional mapping relationship, and in the mapping relationship subset, the mapping relationship record matching the target metadata identifier is searched according to the object qualified name;

[0119] Extracting the source metadata identifier corresponding to the target metadata identifier from the mapping relationship record;

[0120] extracting a conversion rule between the target metadata identifier and the source metadata identifier from the mapping relationship record, the conversion rule including a type conversion rule, a constraint conversion rule, and a syntax conversion rule, wherein the type conversion rule defines a mapping manner between a data type of the target database and a data type of the source database, the constraint conversion rule defines a conversion manner between a constraint expression of the target database and a constraint expression of the source database, and the syntax conversion rule defines a conversion manner between an operation syntax of the target database and an operation syntax of the source database.

[0121] When performing query processing according to the target metadata identifier, the target metadata identifier needs to be parsed and decomposed into structured components. The target metadata identifier usually adopts a hierarchical naming structure and includes a database object type identifier and an object qualified name as two core parts. The database object type identifier is used to identify the object category to which the metadata belongs, such as a table object, a view object, an index object, a stored procedure object, and the like. The object qualified name is used to uniquely identify the position of the object in the database and usually includes hierarchical information such as a database name, a schema name, and an object name. In the parsing process, the complete identifier is split into the database object type identifier and the object qualified name by identifying the separator and the keyword in the target metadata identifier. Taking a specific target metadata identifier as an example, the format of the target metadata identifier is "TABLE: targetdb.public.employee_info". Through parsing, the database object type identifier is "TABLE", and the object qualified name is "targetdb.public.employee_info", wherein targetdb represents the target database name, public represents the schema name, and employee_info represents the table name.

[0122] After the parsing is completed, the database object type identifier extracted is used to perform positioning operation in the bidirectional mapping relationship. The bidirectional mapping relationship adopts a hierarchical storage structure, and the first layer is classified and organized according to the database object type, and each object type corresponds to an independent mapping relationship subset. By taking the database object type identifier as an index key, the corresponding mapping relationship subset can be quickly positioned. The mapping relationship subset stores metadata records of all established mapping relationships under the object type. Each mapping relationship subset is internally organized in a hash table or a tree structure, and the object qualified name is taken as a retrieval key to realize efficient search of the mapping relationship records. After the mapping relationship subset corresponding to the TABLE type is positioned, the subset includes mapping relationship records of all table objects, and each record includes the target metadata identifier, the source metadata identifier, and the corresponding conversion rule.

[0123] In the mapping relationship subset, the extracted object qualified name "targetdb.public.employee_info" is used as a search condition to traverse all mapping relationship records in the subset. The search process uses exact matching to compare the search condition with the object qualified name part of the target metadata identifier in each record. When the object qualified name of a record is found to be exactly the same as the search condition, it is confirmed that the record is the target mapping relationship record. Considering that the object qualified name may have case sensitivity differences, the search process needs to be adapted according to the naming conventions of the target database. After matching is completed, the corresponding mapping relationship record is obtained, which fully describes the corresponding relationship and conversion rules between the target metadata and the source metadata. Assume that the retrieved mapping relationship record shows that the target metadata identifier "TABLE: targetdb.public.employee_info" corresponds to the source metadata identifier "TABLE: sourcedb.hr_schema.emp_details".

[0124] The process of extracting the source metadata identifier from the retrieved mapping relationship record needs to read the field in the record that specifically stores the source metadata identifier. The source metadata identifier also uses a hierarchical naming structure, including the object type identifier and object qualified name of the source database. By parsing the source metadata identifier "TABLE: sourcedb.hr_schema.emp_details", it can be known that the corresponding object in the source database is a table type, located in the hr_schema schema of the sourcedb database, and the table name is emp_details. After extracting the source metadata identifier, the explicit corresponding relationship between the target database object and the source database object is established, providing accurate positioning information for subsequent data migration or synchronization operations.

[0125] The conversion rule stored in the mapping relationship record includes three-dimensional conversion definition. The type conversion rule defines the mapping relationship between the target database and the source database in the data type system. Different database systems support different data types, and the type conversion rule describes in detail how to convert the data type of each field. In the mapping of the employee_info table and the emp_details table, the type conversion rule record shows that the employee_id field of the target table is of integer type and has a length of 64 bits, corresponding to the emp_id field of the source table which is of integer type and has a length of 32 bits, and the conversion rule specifies that bit length expansion is required. The employee_name field of the target table is of variable length string and has a maximum length of 200 characters, corresponding to the emp_name field of the source table which is of variable length string and has a maximum length of 100 characters, and the conversion rule also specifies length expansion. The salary field of the target table is of fixed-point number and has a precision of 15 bits after the decimal point, and the sal field of the source table is of floating-point number, and the conversion rule specifies that the floating-point number needs to be converted to fixed-point number to ensure the precision.

[0126] The constraint conversion rule defines the conversion method of the database constraint between the two systems. The constraint includes primary key constraint, foreign key constraint, unique constraint, non-empty constraint and check constraint, etc. The primary key constraint of the target table employee_info is defined on the employee_id field, and the constraint name is pk_employee_info. The primary key constraint of the source table emp_details is defined on the emp_id field, and the constraint name is pk_emp_details. The constraint conversion rule records the correspondence of the primary key field and the conversion rule of the constraint name. The salary field of the target table has a check constraint, which requires that the salary value must be greater than zero and less than one million. The sal field of the source table has a check constraint, which requires that the sal value must be greater than zero and less than 500,000. The constraint conversion rule not only records the correspondence of the constraint condition, but also records the adjustment rule of the constraint boundary value. The department_id field of the target table has a foreign key constraint, which references the id field of the department table. The dept_id field of the source table has a foreign key constraint, which references the dept_id field of the dept table. The constraint conversion rule records in detail the mapping of the foreign key relationship and the correspondence of the reference table.

[0127] The syntax conversion rule defines the difference between the target database and the source database in the SQL syntax level and the conversion method when performing the database operation. The SQL dialects of different database systems have significant differences, including function names, operators, keywords, and the like. In the operation of the employee_info table and the emp_details table, the target database uses the CURRENT_TIMESTAMP function to obtain the current timestamp, and the source database uses the NOW function to realize the same function, and the syntax conversion rule explicitly records the corresponding relationship of the function names. The target database uses the double vertical line operator when performing the string splicing operation, and the source database uses the CONCAT function to complete the string splicing, and the syntax conversion rule defines the conversion mode between the operator and the function. The target database uses the IDENTITY keyword when creating the self-increment sequence, and the source database uses the AUTO_INCREMENT keyword, and the syntax conversion rule records the replacement rule of the keyword. For the paging query syntax, the target database uses the OFFSET and LIMIT clauses, the source database uses the LIMIT and OFFSET clauses but the order is opposite, and the syntax conversion rule accurately describes the order adjustment rule of the clauses.

[0128] The embodiment of the application provides a heterogeneous database compatible adaptation system, which comprises:

[0129] A first unit is configured to obtain a data migration request comprising a source database type identifier and a target database type identifier, and obtain schema definition information of the source database;

[0130] A second unit is configured to parse data type declarations, constraint conditions and index structures in the schema definition information based on a preset type mapping rule, and generate an intermediate representation structure;

[0131] A third unit is configured to perform compatibility detection on each metadata unit in the intermediate representation structure according to syntax specifications and characteristic sets corresponding to the target database type identifier, identify metadata units incompatible with the target database, and generate a compatibility analysis result;

[0132] A fourth unit is configured to map the incompatible metadata units to equivalent metadata expression forms supported by the target database by constructing a semantically equivalent conversion path according to the compatibility analysis result, maintain semantic constraint relationships of the metadata units in the source database, and generate a target schema definition;

[0133] A fifth unit is configured to create corresponding database objects in the target database based on the target schema definition, establish a data access adaptation layer between the source database and the target database, and dynamically convert data operation statements for the target database at runtime.

[0134] A third aspect of the embodiments of the present application,

[0135] An electronic device is provided, comprising:

[0136] a processor;

[0137] a memory for storing processor-executable instructions;

[0138] wherein the processor is configured to invoke the instructions stored by the memory to perform the method described above.

[0139] A fourth aspect of the embodiments of the present application,

[0140] A computer-readable storage medium is provided, which stores computer program instructions, and the computer program instructions are executed by a processor to implement the method described above.

[0141] The present application can be a method, apparatus, system and / or computer program product. The computer program product can include a computer-readable storage medium having computer-readable program instructions stored therein, the computer-readable program instructions being executable by a computer processor to perform various aspects of the present application.

[0142] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand: it can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for part or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for heterogeneous database compatibility adaptation, characterized in that, The method comprises the following steps: acquiring a data migration request containing a source database type identifier and a target database type identifier, and acquiring schema definition information of the source database; analyzing data type declarations, constraint conditions and index structures in the schema definition information based on a preset type mapping rule to generate an intermediate representation structure; performing compatibility detection on each metadata unit in the intermediate representation structure according to a syntax specification and a characteristic set corresponding to the target database type identifier, identifying metadata units incompatible with the target database, and generating a compatibility analysis result; mapping the incompatible metadata units into equivalent metadata expression forms supported by the target database while maintaining semantic constraint relationships of the metadata units in the source database by constructing a semantically equivalent conversion path according to the compatibility analysis result, and generating a target schema definition, comprising: extracting semantic constraint relationships of the incompatible metadata units from the intermediate representation structure, the semantic constraint relationships including data integrity constraints, reference constraints and business logic constraints of the incompatible metadata units; based on the incompatible types of the incompatible metadata units and the semantic constraint relationships, determining candidate metadata expression forms semantically equivalent to the incompatible metadata units from a set of metadata expression forms supported by the target database, and constructing a conversion path from the incompatible metadata units to the candidate metadata expression forms by analyzing semantic differences between the candidate metadata expression forms and the incompatible metadata units; verifying whether the candidate metadata expression forms obtained through the conversion path maintain the semantic constraint relationships, and determining the candidate metadata expression forms as equivalent metadata expression forms when the candidate metadata expression forms maintain the semantic constraint relationships; mapping the incompatible metadata units into the equivalent metadata expression forms and marking implementation manners of the semantic constraint relationships in the equivalent metadata expression forms to generate converted metadata units; creating corresponding database objects in the target database based on the target schema definition, and establishing a data access adaptation layer between the source database and the target database to dynamically convert data operation statements for the target database at runtime.

2. The method of claim 1, wherein, The method comprises the following steps: analyzing data type declarations, constraint conditions and index structures in the schema definition information based on a preset type mapping rule to generate an intermediate representation structure, comprising: for each data type declaration in the set of data type declarations, determining a corresponding standardized type identifier according to the preset type mapping rule, and establishing a mapping relationship between the data type declaration and the standardized type identifier to generate a type mapping table; for each constraint condition in the set of constraint conditions, identifying a constraint category and a constraint scope of the constraint condition, and converting the constraint condition into a unified constraint expression to generate a constraint mapping table; For each index structure in the index structure set, extract the index type, index field and index attribute of the index structure, and convert the index structure into a standardized index description to generate an index mapping table; Assemble the type mapping table, the constraint mapping table and the index mapping table according to the association relationship between each metadata unit in the logical schema of the source database to generate the intermediate representation structure.

3. The method of claim 1, wherein, According to the corresponding syntax specification and feature set of the target database type identifier, compatibility detection is performed on each metadata unit in the intermediate representation structure, incompatible metadata units are identified, and a compatibility analysis result is generated, including: Obtain the corresponding syntax specification and feature set of the target database type identifier, traverse each metadata unit in the intermediate representation structure, extract the metadata category and metadata attribute description of the metadata unit, the syntax specification includes the data type syntax definition, constraint syntax definition and index syntax definition supported by the target database, and the feature set includes the functional feature identifier supported by the target database; Match the metadata attribute description with the syntax specification to determine whether the metadata unit conforms to the syntax specification, and compare the functional features relied on by the metadata unit with the feature set to determine whether the target database supports the functional features relied on by the metadata unit. When the metadata unit does not conform to the syntax specification or the target database does not support the functional features relied on by the metadata unit, the metadata unit is identified as an incompatible metadata unit; Record the metadata identifier, incompatible type and incompatible reason of the incompatible metadata unit, and establish the dependency relationship record between the incompatible metadata unit and other metadata units in the intermediate representation structure to generate the compatibility analysis result.

4. The method of claim 1, wherein, Establish a data access adaptation layer between the source database and the target database, and dynamically convert data operation statements for the target database in runtime, including: Based on the intermediate representation structure and the target schema definition, a bidirectional mapping relationship is established between the metadata units of the source database and the metadata units of the target database, and the conversion rule corresponding to each bidirectional mapping relationship is recorded; Deploy a data access adaptation layer between the source database and the target database, and the data access adaptation layer stores the bidirectional mapping relationship and the conversion rule; When receiving a data operation statement for the target database, the data operation statement is intercepted through the data access adaptation layer, and the target metadata identifier and operation type involved in the data operation statement are extracted by parsing the data operation statement; According to the target metadata identifier, the source metadata identifier corresponding to the target metadata identifier is queried from the bidirectional mapping relationship, and the conversion rule between the target metadata identifier and the source metadata identifier is obtained; According to the target metadata identifier, the source metadata identifier corresponding to the target metadata identifier is queried from the bidirectional mapping relationship, and the conversion rule between the target metadata identifier and the source metadata identifier is obtained; According to the conversion rule and the operation type, the expression form based on the target database syntax in the data operation statement is converted into an equivalent expression form based on the source database syntax, and according to the semantic constraint relationship recorded in the intermediate representation structure, constraint verification logic required by the source database is supplemented in the equivalent expression form, and a converted data operation statement is generated.

5. The method of claim 4, wherein, According to the target metadata identifier, the source metadata identifier corresponding to the target metadata identifier is queried from the bidirectional mapping relationship, and the conversion rule between the target metadata identifier and the source metadata identifier is obtained, including: Extracting a database object type identifier and an object qualified name in the target metadata identifier; Based on the database object type identifier, the mapping relationship subset corresponding to the database object type identifier is located in the bidirectional mapping relationship, and according to the object qualified name, the mapping relationship record matched with the target metadata identifier is searched in the mapping relationship subset; The source metadata identifier corresponding to the target metadata identifier is extracted from the mapping relationship record; The conversion rule between the target metadata identifier and the source metadata identifier is extracted from the mapping relationship record, including the type conversion rule, the constraint conversion rule and the syntax conversion rule, wherein the type conversion rule defines the mapping mode between the data type of the target database and the data type of the source database, the constraint conversion rule defines the conversion mode between the constraint expression of the target database and the constraint expression of the source database, and the syntax conversion rule defines the conversion mode between the operation syntax of the target database and the operation syntax of the source database.

6. A heterogeneous database compatible adaptation system for implementing the method according to any one of claims 1 to 5, characterized in that, Comprising: The first unit is used for obtaining a data migration request containing a source database type identifier and a target database type identifier, and obtaining schema definition information of the source database; The second unit is used for parsing data type declaration, constraint condition and index structure in the schema definition information based on a preset type mapping rule, and generating an intermediate representation structure; The third unit is used for performing compatibility detection on each metadata unit in the intermediate representation structure according to the syntax specification and characteristic set corresponding to the target database type identifier, identifying incompatible metadata units with the target database, and generating a compatibility analysis result; The fourth unit is used for mapping the incompatible metadata units into an equivalent metadata expression form supported by the target database according to the compatibility analysis result by constructing a semantically equivalent conversion path, and maintaining the semantic constraint relationship of the metadata units in the source database, and generating a target schema definition; The fifth unit is used for creating corresponding database objects in the target database based on the target schema definition, establishing a data access adaptation layer between the source database and the target database, and dynamically converting data operation statements for the target database at runtime.

7. An electronic device, comprising: Comprising: A processor; A memory for storing processor-executable instructions; The processor is configured to invoke the instructions stored in the memory to execute the method in any one of claims 1 to 5.

8. A computer-readable storage medium having stored thereon computer program instructions, wherein, The computer program instructions, when executed by the processor, implement the method in any one of claims 1 to 5.

Images