Cross-database unified management and operation method and system

Abstract

The invention provides a cross-database unified management and operation method and system, and relates to the technical field of databases, and the method comprises the following steps: establishing a connection by obtaining database connection information; extracting a database structure by using a dialect strategy processor and mapping the database structure into a unified description; converting the operation instruction into a standard intermediate statement; converting the intermediate statement into a target database execution statement by using a grammar analysis module and a conversion rule; and executing and monitoring in a transaction unit mode. Unified management and operation of different types of databases are realized, the consistency and reliability of database operation are improved, and the development difficulty of cross-database operation is reduced.

Description

Technical Field

[0001] The present invention relates to database technology, and in particular to a cross-database unified management and operation method and system. Background Art

[0002] With the continuous advancement of enterprise informatization, the coexistence of various heterogeneous database systems has become the norm. Significant differences in data types, syntax rules, and operational interfaces between these database systems pose significant challenges to database management and operation.

[0003] Existing technologies typically develop separate management tools for different databases, or use simple string replacement methods to handle cross-database operations. These solutions suffer from issues such as high duplication of development work, high maintenance costs, and poor scalability. Furthermore, the lack of a unified data structure description and standardized operation conversion mechanism makes it difficult to ensure the accuracy and consistency of cross-database operations.

[0004] Traditional solutions cannot effectively handle complex database dialect conversions and lack reliable transaction control mechanisms, making it difficult to detect and recover from exceptions during execution. Therefore, a cross-database management and operation method is urgently needed that can uniformly manage heterogeneous databases, automatically perform dialect conversions, and provide comprehensive transaction control and status monitoring mechanisms. Summary of the Invention

[0005] The embodiments of the present invention provide a cross-database unified management and operation method and system, which can solve the problems in the prior art.

[0006] A first aspect of an embodiment of the present invention provides a cross-database unified management and operation method, including: Obtain database type identification, database access address and access credential information, establish a database connection, and generate connection identification information; Obtaining and instantiating the dialect policy processor corresponding to the database type identifier from a preset dialect policy registry, calling the metadata extraction method of the dialect policy processor to extract database structure information from the target database, mapping the database structure information into a unified structure description according to preset metadata mapping rules, and generating a structure mapping file; Parse the database operation instructions sent by the visual interface and convert them into standard operation description objects, and generate standardized intermediate operation statements after verification according to the structure mapping file; The syntax parsing module of the dialect policy processor is called to parse the intermediate operation statement, generate a syntax tree node sequence, obtain a conversion rule set that matches the database type identifier from the syntax conversion rule library, and convert the syntax tree node sequence into an execution statement for the target database; Encapsulate the execution statement into a transaction unit with a rollback mechanism, submit it to the target database for execution, monitor the connection status corresponding to the connection identification information, receive the execution status information, generate an operation result report based on the execution status information, and return it to the visual interface for display.

[0007] In an optional embodiment, Obtain the database type identifier, database access address, and access credential information, establish a database connection, and generate connection identification information including: Obtain database connection information including database type identifier, database access address and access credential information, and determine the database type identifier from a preset database type mapping table; obtaining a corresponding connection parameter verification rule according to the database type identifier, performing validity verification on the database connection information based on the connection parameter verification rule, and when the database connection information passes the verification, searching for an idle connection that matches the database type identifier and the database access address from a preset database connection pool; if no matching idle connection is found, establishing a database connection based on the database connection information; Performing a connectivity test on the established database connection, adding the database connection to the database connection pool for unified management after the test passes, and generating connection identification information including database type identification, database access address and connection timestamp; Establish a correspondence between the connection identification information and the database connection, store the correspondence in a connection mapping table, and start a connection monitoring thread. The connection monitoring thread periodically detects the connectivity status of the database connection, and automatically reconnects and updates the connection mapping table when a connection anomaly is detected.

[0008] In an optional embodiment, Obtain the dialect policy processor corresponding to the database type identifier from the preset dialect policy registry and instantiate it. Call the metadata extraction method of the dialect policy processor to extract database structure information from the target database. Map the database structure information to a unified structure description according to the preset metadata mapping rules. Generate a structure mapping file including: Obtaining dialect policy processor type information corresponding to the database type identifier from a preset dialect policy registry; the dialect policy processor type information includes a class name and a class path; The bytecode file of the dialect policy processor is loaded according to the class path, the class object of the dialect policy processor is obtained through the reflection mechanism based on the class name, the construction method of the class object is called to generate a dialect policy processor instance, the dialect policy processor instance implements a predefined metadata extraction interface, and the database structure information is extracted from the target database through the metadata extraction interface; Executing preset sampling rules on field values in the database structure information to obtain numerical distribution characteristics, performing intelligent inference on the data type in the database structure information based on the numerical distribution characteristics, outputting inferred type information and inference confidence, comparing the inference confidence with a preset confidence threshold, and when the inference confidence is greater than the preset confidence threshold, using the inferred type information to update the data type mapping relationship in the preset metadata mapping rule library to obtain an optimized metadata mapping rule; The database structure information is input into the optimized metadata mapping rules for conversion, and a structure mapping file with unified structure description is output.

[0009] In an optional embodiment, The preset sampling rules are executed on the field values in the database structure information to obtain the numerical distribution characteristics. Based on the numerical distribution characteristics, the data types in the database structure information are intelligently inferred. The inferred type information and inference confidence are output, including: Dividing the field values in the database structure information into multiple numerical intervals, randomly sampling sample values in each numerical interval, sorting the sample values by numerical value, and then calculating a difference sequence between adjacent sample values, and generating a numerical distribution feature based on the difference sequence; Counting the number of decimal places of numerical data of the sample value to obtain a decimal place distribution feature, counting the character length of character data to obtain a length distribution feature, combining the decimal place distribution feature and the length distribution feature to generate a character structure feature; matching the character structure feature with a preset format template to generate a data pattern feature; The numerical distribution features, character structure features and data pattern features are combined to generate a numerical distribution feature vector, the similarity between the numerical distribution feature vector and the standard feature vector in the preset data type library is calculated, the data type with the highest similarity is selected as the inferred type information, the matching degree between the numerical distribution feature vector and the feature rule set corresponding to the inferred type information is calculated to obtain a feature matching score, the inference confidence is generated based on the comparison result of the feature matching score and the preset matching threshold, and finally the inferred type information and the inference confidence are output.

[0010] In an optional embodiment, Parse the database operation instructions sent by the visual interface and convert them into standard operation description objects. After verification according to the structure mapping file, generate standardized intermediate operation statements including: Receive database operation instructions sent by the visual interface, perform lexical analysis on the database operation instructions, and extract the operation type, target object and filtering conditions; Constructing a weighted abstract syntax tree based on the operation type, target object, and filtering condition, setting priority weights for nodes in the abstract syntax tree according to the complexity of the operation, and connecting nodes with dependency relationships through directed edges to generate an operation dependency graph; Rearranging the operation sequence based on the priority weights of the nodes in the operation dependency graph to obtain an execution path, and converting the execution path into a standard operation description object; Acquire table structure information and field attribute information from a structure mapping file, perform type checking on the standard operation description object, and when type incompatibility is detected, identify an optimal type conversion path from a preset conversion template library, and generate a type conversion code segment according to the type conversion path; The standard operation description object is split into multiple atomic operation units according to the execution cost, and each atomic operation unit is reorganized based on the type conversion code segment to generate a standardized intermediate operation statement.

[0011] In an optional embodiment, The syntax parsing module of the dialect policy processor is called to parse the intermediate operation statement, generate a syntax tree node sequence, obtain the conversion rule set that matches the database type identifier from the syntax conversion rule library, and convert the syntax tree node sequence into an execution statement for the target database, including: Invoking a syntax parsing module of a dialect policy processor to parse the intermediate operation statement into an initial syntax unit including an operation identifier and a parameter identifier; Establishing a dependency index table for the initial grammatical unit, wherein the dependency index table records the upstream call node and downstream reference node of each grammatical unit, constructing a directed dependency graph based on the dependency index table, calculating the reference depth and call breadth of each grammatical unit, and generating a node weight value; Dividing the initial grammatical units into different processing priorities according to node weight values, clustering grammatical units within the same priority based on semantic similarity, constructing a hierarchical grammar tree containing multiple semantic clusters, and generating a grammar tree node sequence; Obtaining a rule template that matches the database type identifier from a grammar conversion rule library, constructing a rule linked list based on the rule template, setting an execution order for the rule items in the rule linked list, traversing the grammar tree node sequence, calculating the execution cost and resource consumption of the nodes, marking nodes whose execution cost exceeds a preset cost threshold as performance-sensitive nodes, and applying the rule linked list to the performance-sensitive nodes for structural optimization and grammar conversion; The associated processing scope is determined based on the converted performance-sensitive nodes, and the syntax tree nodes within the associated processing scope are sequentially converted into syntax structures according to the execution order to generate execution statements for the target database.

[0012] In an optional embodiment, Encapsulate the execution statement into a transaction unit with a rollback mechanism, submit it to the target database for execution, monitor the connection status corresponding to the connection identification information, receive execution status information, generate an operation result report based on the execution status information, and return it to the visual interface for display, including: Parsing the data table access identifier, data operation type, and associated field information in the execution statement, establishing an association relationship table between data tables based on the associated field information, and organizing the execution statements with field references into transaction unit groups based on the association relationship table; Constructing an operation sequence chain for the transaction unit group, generating a corresponding compensation operation for each operation in the operation sequence chain according to the data operation type, and encapsulating the operation sequence chain and the compensation operation into a transaction unit with a rollback mechanism; Perform syntax verification and data consistency check on the execution statements in the transaction unit. After passing the verification, obtain the database connection and submit it to the target database for execution; Record the database connection identification information, collect the network connection status and database session status corresponding to the connection identification information in real time, obtain the checkpoint information of the most recent successful execution when an abnormal state is detected, determine the scope of operations that need to be rolled back based on the checkpoint information, perform the rollback in the reverse order of the compensation operations, and re-initiate the execution request after completion; The operation sequence number, execution time, number of affected rows and error information during the execution process are recorded and organized into a structured operation result report, which is then returned to the visual interface for display.

[0013] A second aspect of an embodiment of the present invention provides a cross-database unified management and operation system, including: The first unit is used to obtain a database type identifier, a database access address and access credential information, establish a database connection, and generate connection identification information; The second unit is used to obtain and instantiate the dialect policy processor corresponding to the database type identifier from a preset dialect policy registry, call the metadata extraction method of the dialect policy processor to extract database structure information from the target database, map the database structure information into a unified structure description according to preset metadata mapping rules, and generate a structure mapping file; The third unit is used to parse the database operation instructions sent by the visual interface and convert them into standard operation description objects, and generate standardized intermediate operation statements after verification according to the structure mapping file; The fourth unit is used to call the syntax parsing module of the dialect policy processor to parse the intermediate operation statement, generate a syntax tree node sequence, obtain a conversion rule set that matches the database type identifier from the syntax conversion rule library, and convert the syntax tree node sequence into an execution statement for the target database; The fifth unit is used to encapsulate the execution statement into a transaction unit with a rollback mechanism, submit it to the target database for execution, monitor the connection status corresponding to the connection identification information, receive the execution status information, generate an operation result report based on the execution status information, and return it to the visual interface for display.

[0014] According to a third aspect of an embodiment of the present invention, an electronic device is provided, including: processor; a memory for storing processor-executable instructions; The processor is configured to call the instructions stored in the memory to execute the aforementioned method.

[0015] According to a fourth aspect of an embodiment of the present invention, a computer-readable storage medium is provided, on which computer program instructions are stored. When the computer program instructions are executed by a processor, the method described above is implemented.

[0016] In this embodiment, by establishing a unified database operation interface, the complexity of managing multiple heterogeneous databases is effectively resolved, allowing users to complete cross-database operations without having to understand the specific syntax of different databases, greatly improving data management efficiency. By adopting a dialect strategy processing mechanism and metadata mapping technology, unified description and operation conversion of different types of database structures are achieved, enabling the system to automatically adapt to various database products, enhancing the system's scalability and compatibility and reducing technology migration costs. Through transaction management and status monitoring mechanisms, the security and reliability of cross-database operations are guaranteed. At the same time, an intuitive visual interface and detailed operation result feedback are provided, optimizing the user experience and lowering the technical threshold for database management. This makes it suitable for various complex enterprise-level data environments. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 Schematic diagram of the process of unified management and operation method across databases according to an embodiment of the present invention; Figure 2 A histogram showing the relationship between feature matching scores and inference confidence levels according to an embodiment of the present invention; Figure 3 This is a system architecture diagram of the cross-database unified management and operation method according to an embodiment of the present invention. DETAILED DESCRIPTION

[0018] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts shall fall within the scope of protection of the present invention.

[0019] The following specific embodiments are used to describe the technical solution of the present invention in detail. 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.

[0020] Figure 1 FIG. 1 is a flow chart of a unified management and operation method across databases according to an embodiment of the present invention. Figure 1 As shown, the method includes: Obtain database type identification, database access address and access credential information, establish a database connection, and generate connection identification information; Obtaining and instantiating the dialect policy processor corresponding to the database type identifier from a preset dialect policy registry, calling the metadata extraction method of the dialect policy processor to extract database structure information from the target database, mapping the database structure information into a unified structure description according to preset metadata mapping rules, and generating a structure mapping file; Parse the database operation instructions sent by the visual interface and convert them into standard operation description objects, and generate standardized intermediate operation statements after verification according to the structure mapping file; The syntax parsing module of the dialect policy processor is called to parse the intermediate operation statement, generate a syntax tree node sequence, obtain a conversion rule set that matches the database type identifier from the syntax conversion rule library, and convert the syntax tree node sequence into an execution statement for the target database; Encapsulate the execution statement into a transaction unit with a rollback mechanism, submit it to the target database for execution, monitor the connection status corresponding to the connection identification information, receive the execution status information, generate an operation result report based on the execution status information, and return it to the visual interface for display.

[0021] In an optional embodiment, Obtain the database type identifier, database access address, and access credential information, establish a database connection, and generate connection identification information including: Obtain database connection information including database type identifier, database access address and access credential information, and determine the database type identifier from a preset database type mapping table; obtaining a corresponding connection parameter verification rule according to the database type identifier, performing validity verification on the database connection information based on the connection parameter verification rule, and when the database connection information passes the verification, searching for an idle connection that matches the database type identifier and the database access address from a preset database connection pool; if no matching idle connection is found, establishing a database connection based on the database connection information; Performing a connectivity test on the established database connection, adding the database connection to the database connection pool for unified management after the test passes, and generating connection identification information including database type identification, database access address and connection timestamp; Establish a correspondence between the connection identification information and the database connection, store the correspondence in a connection mapping table, and start a connection monitoring thread. The connection monitoring thread periodically detects the connectivity status of the database connection, and automatically reconnects and updates the connection mapping table when a connection anomaly is detected.

[0022] Exemplarily, the process of obtaining database connection information includes receiving user input or reading database type identifier, database access address and access credential information from a configuration file. The database type identifier can be a string such as "MySQL", "Oracle", "SQLServer", "PostgreSQL", etc. The database access address includes the host address and port number, such as "192.168.1.100:3306", and the access credential information includes the user name and password, such as the user name "dbadmin" and the password "pass123". A preset database type mapping table is maintained to convert the database type identifier provided by the user into an internal standardized identifier. For example, different forms of input such as "mysql", "MySQL", "MYSQL", etc. are uniformly mapped to "MYSQL". The mapping table is stored in the form of key-value pairs, where the key is the database type name in various forms that the user may enter, and the value is the standardized identifier used internally.

[0023] Connection parameter validation rules set different validation rules for different types of databases. For MySQL databases, the host address must be a valid IP address or domain name, and the port number must be an integer between 1024 and 65535, with the default being 3306. The user name must be no longer than 32 characters and cannot contain special characters. The password must be no less than 6 characters long. For Oracle databases, the host address must be a valid IP address or domain name, and the port number must be an integer between 1024 and 65535, with the default being 1521. The user name must start with a letter, contain only letters, numbers, and underscores, and must be no more than 30 characters long. The password must be no less than 8 characters long and must contain at least one uppercase letter, one lowercase letter, and one number. After receiving the database connection information, the corresponding validation rule is selected based on the database type identifier for verification. If verification fails, a specific error message will be returned, such as "The port number is out of the valid range" or "The password does not meet the complexity requirements."

[0024] The database connection pool is managed using a two-level hash table structure. The first-level hash table uses the database type identifier as the key and the second-level hash table as the value. The second-level hash table uses the database access address as the key and the connection object list as the value. When a new database connection is needed, the connection pool is first checked for a matching idle connection. The first-level hash table is searched for the corresponding second-level hash table based on the database type identifier. Then, the second-level hash table is searched for the connection object list based on the database access address. If the connection object list is found and not empty, a connection object is retrieved from the list and reused. If the list is empty or no matching list is found, a new database connection is created. For example, if a user requests a connection to a database of type "MYSQL" and address "192.168.1.100:3306", the first-level hash table entry with the key "MYSQL" is searched, followed by the second-level hash table entry with the key "192.168.1.100:3306". If the connection object list exists and is not empty, a connection object is retrieved and reused; otherwise, a new connection is created.

[0025] The database connection establishment process uses different connection methods depending on the database type. For MySQL databases, use the JDBC driver, construct the connection URL as "jdbc:mysql: / / host address:port number / database name", and set connection properties such as autocommit, connection timeout, and character set. For Oracle databases, construct the connection URL as "jdbc:oracle:thin:@host address:port number:service name", and set Oracle-specific connection properties such as NLS_LANG and NLS_DATE_FORMAT. When establishing a connection, possible exceptions such as connection timeouts, authentication failures, and network errors are captured and handled, and appropriate error handling and retry logic are implemented based on the exception type. For example, if a connection timeout exception is encountered, the error information will be logged and a retry will be performed after a period of time. If an authentication failure exception is encountered, the provided credentials will be checked and the user will be asked to re-enter them.

[0026] The connectivity test verifies that the database connection is functioning properly by executing a simple SQL query. For a MySQL database, execute the "SELECT 1" query; for an Oracle database, execute the "SELECT 1 FROM DUAL" query; and for a SQL Server database, execute the "SELECT 1" query. Set the query timeout to 5 seconds. If the query is successfully executed and the results are obtained within the timeout, the connectivity test is considered passed; otherwise, the test is considered failed. For connections that fail the test, an attempt is made to close the connection and release related resources. The configuration then determines whether to retry establishing the connection. For example, when attempting to connect to a MySQL database and executing the "SELECT 1" query, if the result "1" is successfully returned within 5 seconds, the connectivity test passes; if no result is returned or an error is returned after more than 5 seconds, the test fails.

[0027] Connection identification information is generated using a specific format, consisting of the database type, database access address, and connection timestamp, separated by underscores. For example, for a database connection of type "MYSQL," address "192.168.1.100:3306," and connection time "2023-06-20 15:30:45," the generated connection identifier is "MYSQL_192.168.1.100:3306_20230620153045." The correspondence between connection identification information and database connections is stored in a connection mapping table, which uses a hash table structure with the connection identifier as the key and the database connection object as the value. An interface is provided to retrieve the database connection object based on the connection identifier, allowing upper-layer applications to perform database operations simply by using the connection identifier without having to worry about the specific database connection details.

[0028] The connection monitoring thread is responsible for periodically detecting the connectivity status of the database connection, with a default detection period of 60 seconds. The monitoring thread traverses all connections in the connection mapping table and performs a connectivity test on each connection. If the test fails, the monitoring thread attempts to close the current connection and re-establish the database connection based on the information in the connection identifier. If the reconnection is successful, the monitoring thread updates the corresponding entry in the connection mapping table; if the reconnection fails, the monitoring thread records the error information in the log and attempts to reconnect again in the next detection period. The monitoring thread is also responsible for detecting the idle time of the connection. If the idle time of a connection exceeds the preset threshold (the default is 30 minutes), the monitoring thread will mark the connection as recyclable. Recycling operations are performed periodically to close and remove recyclable connections to free up system resources. For example, when the monitoring thread detects that the connection "MYSQL_192.168.1.100:3306_20230620153045" cannot be connected, it attempts to close the connection and re-establish the connection using the same database type identifier and access address, generating a new connection identifier such as "MYSQL_192.168.1.100:3306_20230620154545", and then updates the connection mapping table.

[0029] In this embodiment, a unified connection management mechanism enables indiscriminate access to different types of databases, reduces the coupling between applications and specific database types, and improves the scalability and maintainability of the system. Connection pooling technology effectively reuses database connection resources, reduces the overhead of frequently establishing and closing connections, and improves system performance. A connection parameter verification mechanism proactively detects and blocks illegal connection requests, enhancing system security and stability. Connection monitoring and automatic reconnection mechanisms promptly detect and repair connection anomalies, improving system reliability and fault tolerance. Connection identifiers and mapping tables enable unified management and efficient access to connection resources, simplifying the development complexity of upper-layer applications. These technical effects collectively promote efficient, stable, and secure data access and management in a cross-database environment.

[0030] In an optional embodiment, Obtain the dialect policy processor corresponding to the database type identifier from the preset dialect policy registry and instantiate it. Call the metadata extraction method of the dialect policy processor to extract database structure information from the target database. Map the database structure information to a unified structure description according to the preset metadata mapping rules. Generate a structure mapping file including: Obtaining dialect policy processor type information corresponding to the database type identifier from a preset dialect policy registry; the dialect policy processor type information includes a class name and a class path; The bytecode file of the dialect policy processor is loaded according to the class path, the class object of the dialect policy processor is obtained through the reflection mechanism based on the class name, the construction method of the class object is called to generate a dialect policy processor instance, the dialect policy processor instance implements a predefined metadata extraction interface, and the database structure information is extracted from the target database through the metadata extraction interface; Executing preset sampling rules on field values in the database structure information to obtain numerical distribution characteristics, performing intelligent inference on the data type in the database structure information based on the numerical distribution characteristics, outputting inferred type information and inference confidence, comparing the inference confidence with a preset confidence threshold, and when the inference confidence is greater than the preset confidence threshold, using the inferred type information to update the data type mapping relationship in the preset metadata mapping rule library to obtain an optimized metadata mapping rule; The database structure information is input into the optimized metadata mapping rules for conversion, and a structure mapping file with unified structure description is output.

[0031] The dialect policy registry is a configuration mapping structure used to store dialect policy processor information corresponding to different database types. The registry uses a key-value pair format, where the key is the database type identifier, such as "MYSQL", "ORACLE", "SQLSERVER", etc., and the value is the corresponding dialect policy processor type information, including the class name and class path. For example, the dialect policy processor type information corresponding to the MySQL database may be the class name "MySQLDialectProcessor" and the class path "com.database.dialect.mysql.MySQLDialectProcessor"; the dialect policy processor type information corresponding to the Oracle database may be the class name "OracleDialectProcessor" and the class path "com.database.dialect.oracle.OracleDialectProcessor". The dialect policy registry can be initialized through a configuration file or dynamically registered through a program. When a specific type of database needs to be processed, the corresponding dialect policy processor type information is searched from the dialect policy registry using the database type identifier.

[0032] The dialect policy processor instantiation process utilizes Java reflection. First, the class loader loads the corresponding bytecode file based on the class path obtained from the dialect policy registry. For example, for the MySQL database, the bytecode file corresponding to "com.database.dialect.mysql.MySQLDialectProcessor" is loaded. After loading, the dialect policy processor class object is obtained using the Class.forName() method. A processor instance is then created by calling the class object's newInstance() method or the Constructor object's newInstance() method. If the dialect policy processor constructor requires parameters, the corresponding parameters are read from the configuration and passed in. For example, some processors may require database connection information as a construction parameter; the database connection established in the previous step is passed to the constructor. Exceptions that may occur during instantiation include ClassNotFoundException, InstantiationException, and IllegalAccessException. These exceptions are caught and appropriate error handling is performed, such as logging, trying alternative handlers, or reporting the error to the user.

[0033] Dialect policy processors implement a predefined metadata extraction interface, which defines standard methods for extracting structural information from different database types. This metadata extraction interface includes methods such as extractDatabases() (extracts a list of databases), extractTables(String database) (extracts a list of tables from a specified database), extractColumns(String database, String table) (extracts column information from a specified table), extractPrimaryKeys(String database, String table) (extracts primary key information), and extractForeignKeys(String database, String table) (extracts foreign key information). Dialect policy processors for each database type implement these interface methods to provide database-specific metadata extraction logic. For example, a MySQL dialect policy processor might execute the SQL query "SHOW TABLESFROM database_name" when implementing the extractTables method; whereas an Oracle dialect policy processor might query the system table "ALL_TABLES" and filter by the OWNER condition.

[0034] The process of extracting database structure information is performed by the instantiated dialect strategy processor. The processor first calls the extractDatabases() method to obtain a list of all databases or schemas in the target database. For MySQL databases, this might be achieved by executing the "SHOW DATABASES" query; for Oracle databases, this might be achieved by querying the "ALL_USERS" system table. After obtaining the database list, the processor iterates over each database, calling the extractTables() method to extract table information. Table information includes table name, table type (e.g., regular table, view, temporary table), and table comment. The processor then iterates over each table, calling the extractColumns() method to extract column information, including column name, data type, length / precision, nullability, default value, and column comment. It calls the extractPrimaryKeys() method to extract primary key information, including the primary key name and the columns that make up the primary key. It calls the extractForeignKeys() method to extract foreign key information, including the foreign key name, referenced tables and columns, and constraint behavior. The processor may also extract index information, trigger information, stored procedure information, and more, depending on system requirements and database support.

[0035] After the database structure information is extracted, the preset sampling rules are executed on the field values to obtain the numerical distribution characteristics. The sampling rules define how to select sample data from the database for analysis. For example, for large tables, a random sampling strategy may be adopted to randomly select a certain proportion (such as 10%) or a fixed number (such as 1,000) of records from the table for analysis; for small tables, all data may be analyzed. The sampled data is used to analyze the numerical distribution characteristics of each field, including data type, value range, unique value ratio, null value ratio, numerical distribution (such as mean, median, standard deviation, etc.), text length distribution, date and time distribution, etc. For example, for a field defined as a VARCHAR type, if the sampled data shows that 99% of the values are in numeric form and are all within a specific range, it may be inferred that the field should actually use INTEGER or DECIMAL type.

[0036] Based on the numerical distribution characteristics, intelligent inference is performed on the data type in the database structure information, and the inferred type information and inference confidence are output. The intelligent inference algorithm considers multiple factors, including the currently defined data type of the field, the field name (such as containing keywords such as "id", "date", "amount", etc.), the mode of the field value (such as all numbers, date format, email format, etc.), the statistical characteristics of the field value, etc. A confidence score is calculated for each possible data type, and the type with the highest confidence is selected as the inference result. For example, for a field named "create_time" defined as VARCHAR(20), if most of its values conform to the "YYYY-MM-DD HH:MM:SS" format, it may be inferred that its actual type should be DATETIME or TIMESTAMP, and a high confidence level (such as 0.95) is given. The inference result includes inferred type information (such as data type, length / precision, whether it is nullable, etc.) and inference confidence (a value between 0 and 1 indicating the degree of confidence of the inference).

[0037] The inference confidence is compared with the preset confidence threshold. When the inference confidence is greater than the preset confidence threshold, the inference type information is used to update the data type mapping relationship in the preset metadata mapping rule base. The preset confidence threshold is usually set to a high value (such as 0.9) to ensure that only highly reliable inference results are adopted. The metadata mapping rule base is a set of rules maintained by the system for mapping various database-specific data types to unified standard types. For example, the INT type of MySQL, the NUMBER(10) type of Oracle, and the INT type of SQL Server may all be mapped to the INTEGER type in the unified standard. When the result of intelligent inference is adopted, the corresponding mapping relationship in the metadata mapping rule base is updated. For example, if it is inferred that a TINYTEXT type field in MySQL actually stores date and time data, and the confidence exceeds the threshold, a rule may be added to map TINYTEXT to DATETIME for this specific scenario. These optimized mapping rules will be applied to the subsequent structure mapping process.

[0038] Database structure information is input into optimized metadata mapping rules for conversion, outputting a structure mapping file with a unified structure description. This conversion process follows predefined mapping rules, converting database-specific structural features into a unified standard format. This conversion involves multiple aspects, including data type conversion (e.g., converting MySQL's TINYINT to a standard INTEGER type), length and precision conversion (e.g., adjusting the precision representation of numeric types), constraint conversion (e.g., addressing differences in foreign key implementations across databases), and naming convention conversion (e.g., standardizing uppercase and lowercase). The converted unified structure description is typically stored in JSON or XML format and contains structural information at all levels, including databases, tables, columns, primary keys, foreign keys, indexes, and detailed attributes for each structural element. For example, a table description might include information such as the table name, table type, storage engine, character set, and comments; a column description might include information such as the column name, data type, length / precision, nullability, default value, and comments. The generated structure mapping file can be used for subsequent database operations, such as generating cross-database queries, performing data migrations, and performing database structure comparisons.

[0039] In this embodiment, a unified interface for extracting metadata from different types of databases is implemented through the dialect policy processor mechanism, which shields the differences in metadata acquisition among various databases and simplifies the complexity of cross-database operations. The dialect policy processor is dynamically loaded and instantiated through the reflection mechanism, which improves the scalability of the system and supports new database types without modifying the core code. Through data sampling and intelligent type inference, type mismatch problems in database design can be discovered, data type mapping rules can be optimized, and the accuracy and efficiency of data processing can be improved. By generating a structure mapping file in a unified format, a structure description that is independent of the specific database type is provided to the upper-level application, enabling the application to process data from different databases in a unified manner, thereby realizing true cross-database unified management and operation.

[0040] In an optional embodiment, The preset sampling rules are executed on the field values in the database structure information to obtain the numerical distribution characteristics. Based on the numerical distribution characteristics, the data types in the database structure information are intelligently inferred. The inferred type information and inference confidence are output, including: Dividing the field values in the database structure information into multiple numerical intervals, randomly sampling sample values in each numerical interval, sorting the sample values by numerical value, and then calculating a difference sequence between adjacent sample values, and generating a numerical distribution feature based on the difference sequence; Counting the number of decimal places of numerical data of the sample value to obtain a decimal place distribution feature, counting the character length of character data to obtain a length distribution feature, combining the decimal place distribution feature and the length distribution feature to generate a character structure feature; matching the character structure feature with a preset format template to generate a data pattern feature; The numerical distribution features, character structure features and data pattern features are combined to generate a numerical distribution feature vector, the similarity between the numerical distribution feature vector and the standard feature vector in the preset data type library is calculated, the data type with the highest similarity is selected as the inferred type information, the matching degree between the numerical distribution feature vector and the feature rule set corresponding to the inferred type information is calculated to obtain a feature matching score, the inference confidence is generated based on the comparison result of the feature matching score and the preset matching threshold, and finally the inferred type information and the inference confidence are output.

[0041] In this embodiment, the process of partitioning field values in the database structure information into multiple numerical intervals employs an adaptive interval partitioning algorithm. First, the minimum and maximum values of the field are obtained, the numerical range is calculated, and then the number of intervals is determined based on the number and distribution characteristics of the field values. For numerical fields, such as integer or floating-point types, they are typically partitioned into equal-width intervals. For fields with uneven distribution, the intervals are partitioned using the quantile method to ensure a relatively balanced number of samples within each interval. For example, for an integer field with a value range of 0 to 10,000, if the sample distribution is relatively uniform, it may be partitioned into 10 equal-width intervals, each with a width of 1,000. If the samples are primarily concentrated in the range of 0 to 100, a nonlinear partitioning algorithm may be employed, such as 0-10, 10-50, 50-100, 100-500, 500-1,000, or 1,000-10,000 intervals. After the interval partitioning is completed, sample values are randomly sampled within each interval. The number of sampled values is determined proportionally to the number of values within the interval, ensuring that the total number of samples does not exceed a preset upper limit (e.g., 1,000 samples).

[0042] The process of calculating the difference sequence between adjacent sample values after sorting them by numerical magnitude provides fine-grained characterization of the data distribution. The sample values are sorted in ascending order, and the differences between adjacent sample values are calculated to form a difference sequence. The difference sequence reflects the density and distribution pattern of the data. By analyzing the difference sequence, it is possible to determine whether the data is uniformly distributed, clustered, or exhibits other patterns. For example, for an auto-incrementing primary key, the difference sequence may primarily consist of fixed values of 1 or smaller. For a timestamp field, the difference sequence may reflect the temporal pattern of data entry. For randomly distributed values, the difference sequence may not exhibit a clear pattern. Statistical characteristics of the difference sequence, including the mean difference, the standard deviation of the differences, and the ratio of the maximum to minimum differences, are calculated. These characteristics collectively constitute part of the numerical distribution. For example, a small standard deviation of the difference sequence may indicate that the data increases with a fixed step size, such as in the case of auto-incrementing IDs. A periodic distribution of the difference values may indicate that the data is time-dependent, such as the number of records per day or per week.

[0043] The process of calculating the number of decimal places in sample values for numeric data to determine decimal distribution characteristics is performed for fields that may contain floating-point numbers. Each sample value is checked for decimals and the number of decimal places is counted. Characteristics such as the proportion of samples containing decimals, the average number of decimal places, and the maximum number of decimal places are calculated to form a decimal distribution characteristic. For example, if approximately 95% of a field's values contain two decimal places, the field is likely suitable for the DECIMAL(x, 2) data type. If the field values rarely contain decimals, an integer type may be appropriate. The decimal distribution is also analyzed to determine if there are consistent patterns, such as consistently using two decimal places (possibly for monetary amounts) or using scientific notation (possibly for exact scientific data).

[0044] The process of calculating the length of character data to obtain length distribution characteristics is applicable to string type fields. The character length of each sample value is calculated to generate length distribution characteristics, including average length, maximum length, minimum length, length standard deviation, etc. These characteristics help determine the optimal storage type and length for string fields. For example, if the character length distribution is mainly concentrated between 50 and 200, the VARCHAR(255) type may be suitable; if the length is fixed, such as 36 characters, the CHAR(36) type (perhaps a UUID) may be suitable; if the length frequently exceeds 255 characters, the TEXT type may be necessary. In addition, the character composition is analyzed, such as whether it is all numbers, letters, special characters, or mixed characters, which helps determine the specific purpose of the field and the most suitable data type.

[0045] The process of combining decimal distribution features and length distribution features to generate character structure features creates a structured description of the field content. The features obtained from the previous analysis are combined to form a multidimensional feature vector that describes the structural pattern of the field value. For numeric data, features include the distribution of digits in the integer and decimal parts; for character data, features include character length distribution and character type distribution (such as the proportion of letters, numbers, and special characters). For example, a field storing a phone number might be characterized by an all-numeric character set with a length concentrated between 10 and 15 characters; a field storing an email address might be characterized by containing the "@" symbol, a mixture of letters and numbers, and an average length between 20 and 30 characters. Character structure features provide the basis for subsequent format template matching.

[0046] The process of generating data pattern features by matching character structure features with preset format templates identifies common patterns in field values. A set of preset format templates is maintained, covering common data types such as date and time ("YYYY-MM-DD", "YYYY / MM / DD", etc.), email addresses (containing "@" and a domain suffix), phone numbers (a specific combination of numbers and hyphens), IP addresses (four groups of 0-255 numbers separated by dots), and UUIDs (a hexadecimal string in a specific format). Field values are then attempted to be matched against these templates, and the percentage of successful matches is calculated. If the matching percentage exceeds a certain threshold (e.g., 90%), the field is considered to conform to the corresponding data pattern. For example, if most values in a field conform to the "YYYY-MM-DD" format, it is identified as a date type; if they conform to the "name@domain.com" format, it is identified as an email type. The identification results form a data pattern feature, including the pattern type and the degree of match.

[0047] The process of combining numerical distribution features, character structure features, and data pattern features to generate a numerical distribution feature vector creates a comprehensive representation of field characteristics. The various features obtained from the previous analysis are integrated into a multidimensional feature vector, with each dimension corresponding to a characteristic. The feature vector contains information such as basic statistical characteristics (such as mean, standard deviation, maximum, and minimum values), distribution characteristics (such as difference sequence characteristics and distribution skewness), structural characteristics (such as decimal places and character length), and pattern characteristics (such as format template matching results). This comprehensive feature vector comprehensively describes the data characteristics of the field and provides a basis for subsequent type inference. For example, a field representing age might have a feature vector with a mean of approximately 30, a standard deviation of approximately 15, a minimum of 0, a maximum of 120, and almost all integers with no decimal places and no conformance to a specific format template.

[0048] The core process of type inference is to calculate the similarity between the numerical distribution feature vector and the standard feature vectors in the preset data type library. The preset data type library contains standard feature vectors for various common data types, such as integer, floating point, string, date, time, and Boolean. Each type may also include multiple subtypes (such as TINYINT, SMALLINT, and INTEGER). The similarity between the sample feature vector and each standard feature vector is calculated using metrics such as cosine similarity or Euclidean distance. The similarity calculation takes into account the weights of features in each dimension, as different features have varying importance for type determination. For example, format template matching results are given a higher weight for determining whether a data type is a date; decimal places are given a higher weight for determining numerical precision. The data type with the highest similarity is selected as the inferred type information, and the similarity value is recorded as the initial confidence level.

[0049] The inference result is further verified by calculating the degree of match between the numerical distribution feature vector and the feature rule set corresponding to the inferred type information to obtain a feature matching score. In addition to the standard feature vector, each data type is also associated with a set of feature rules to verify the key features of the specific type. For example, the rules for the date type may include: the value must conform to the date format, the month value must be between 1 and 12, the date value must be within the valid range, etc. Check whether the sample values meet these rules, calculate the proportion of samples that meet the rules, and obtain the feature matching score. This step can filter out some cases that are similar in form but do not actually conform to the semantics of a specific type. For example, a string composed entirely of numbers may be similar in form to an integer, but if it is actually a product code or a phone number, it should not be inferred as an integer.

[0050] The process of generating an inference confidence based on the comparison of the feature matching score with the preset matching threshold determines the final degree of inference credibility. The feature matching score is compared with the preset matching threshold. If the score is significantly higher than the threshold, it indicates that the inference result is highly reliable; if the score is close to or slightly higher than the threshold, it indicates that there may be uncertainty in the inference result; if the score is lower than the threshold, it indicates that the inference result may be inaccurate. The final inference confidence is generated based on the comparison results, usually expressed as a value between 0 and 1. For example, if the feature matching score is 0.95 and the preset matching threshold is 0.8, an inference confidence of 0.9 may be generated; if the feature matching score is 0.82, which is close to the threshold, an inference confidence of 0.7 may be generated. Finally, the inference type information and inference confidence are output for subsequent processing.

[0051] In existing technologies, database type inference often relies on simple rule matching or pattern recognition, lacking in-depth analysis of the actual data distribution characteristics, resulting in low inference accuracy. For example, traditional methods may infer data based solely on field names or simple value checks, such as inferring a field name containing "date" as a date type, and a value containing a decimal point as a floating point type. This method is prone to misjudgment when faced with complex data, cannot adapt to type differences between different databases, and cannot detect type mismatches in database design. In this embodiment, through multi-dimensional data sampling and feature analysis, combined with matching verification of preset data type templates and rule sets, more accurate intelligent data type inference is achieved. Specifically, the present application performs multi-interval sampling of field values, analyzes value distribution and structural characteristics, identifies data patterns, and generates a comprehensive feature vector. By calculating similarity with standard feature vectors and verifying matching with feature rule sets, a highly reliable type inference result is obtained. This inference method based on the actual data characteristics significantly improves the accuracy of type judgment, can adapt to type differences between different databases, and can detect and correct type mismatches.

[0052] Figure 2 This is a bar graph showing the relationship between feature matching scores and inference confidence levels in an embodiment of the present invention. Figure 2 As shown in the figure, it shows how the feature matching score in this technical solution affects the final inference confidence. The feature matching score is divided into five intervals (0.5-0.6, 0.6-0.7, 0.7-0.8, 0.8-0.9, 0.9-1.0), and the average inference confidence corresponding to each interval is counted. It can be clearly seen from the figure that with the increase of the feature matching score, the inference confidence shows a significant growth trend. When the feature matching score is in the range of 0.5-0.6, the average inference confidence is only 0.62; when the feature matching score reaches the range of 0.9-1.0, the average inference confidence is as high as 0.97, which is almost close to complete credibility. It is particularly noteworthy that the confidence threshold of 0.8 (red dotted line) is marked in the figure. When the feature matching score exceeds the range of 0.7-0.8, the inference confidence begins to exceed this threshold, indicating that the inference result has a high reliability, providing the data processing system with a more accurate basis for type judgment, especially when processing data with fuzzy boundaries or multi-type compatibility, and can provide more valuable decision support.

[0053] In an optional embodiment, Parse the database operation instructions sent by the visual interface and convert them into standard operation description objects. After verification according to the structure mapping file, generate standardized intermediate operation statements including: Receive database operation instructions sent by the visual interface, perform lexical analysis on the database operation instructions, and extract the operation type, target object and filtering conditions; Constructing a weighted abstract syntax tree based on the operation type, target object, and filtering condition, setting priority weights for nodes in the abstract syntax tree according to the complexity of the operation, and connecting nodes with dependency relationships through directed edges to generate an operation dependency graph; Rearranging the operation sequence based on the priority weights of the nodes in the operation dependency graph to obtain an execution path, and converting the execution path into a standard operation description object; Acquire table structure information and field attribute information from a structure mapping file, perform type checking on the standard operation description object, and when type incompatibility is detected, identify an optimal type conversion path from a preset conversion template library, and generate a type conversion code segment according to the type conversion path; The standard operation description object is split into multiple atomic operation units according to the execution cost, and each atomic operation unit is reorganized based on the type conversion code segment to generate a standardized intermediate operation statement.

[0054] Exemplarily, the process of receiving database operation instructions sent by the visual interface is implemented through a preset communication interface. A dedicated instruction receiving module is set up to monitor operation requests from the visual interface. These operation requests may be encapsulated in JSON or XML format and include the operation type (such as query, insert, update, delete), target object (such as database name, table name, field name), filter conditions (such as WHERE clause content), sorting rules, paging information, etc. For example, a JSON format instruction for a query operation may be: {"operationType":"query","targetObject":"user_info","fields":["user_id","user_name","age"],"conditions":{"age":{"gt":18}},"orderBy":{"user_id":"asc"},"limit":10}. After receiving the operation instruction, the integrity and legitimacy of the instruction format are first verified to ensure that it contains the necessary operation information, and then the instruction is passed to the lexical analysis module for further processing.

[0055] A custom lexical analyzer is used to perform lexical analysis on database operation instructions to extract the operation type, target object, and filter conditions. The lexical analyzer breaks down the operation instructions into a sequence of tokens, identifying elements such as keywords, identifiers, operators, and constants. For instructions in JSON or XML format, they are first parsed into an internal data structure and then key information is extracted. The operation type is typically obtained directly from the operation type field in the instruction; the target object is obtained from the target object field, which may include a multi-level structure such as the database name, schema name, and table name; and the filter conditions are obtained from the condition field, requiring parsing of various comparison operators (such as equals, greater than, less than, and LIKE) and logical operators (such as AND, OR, and NOT). For example, after lexical analysis of the above JSON instruction, the extracted operation type is "query", the target object is the "user_info" table, and the filter condition is "age > 18". The lexical analysis results are stored in a structured format to provide input for subsequent syntax analysis.

[0056] The process of constructing a weighted abstract syntax tree based on the operation type, target object, and filter conditions converts linear instructions into a tree-structured representation. This structure is constructed using a bottom-up approach, first constructing leaf nodes and then gradually building higher-level nodes. Leaf nodes typically represent basic operation elements, such as field names and constant values; intermediate nodes represent operators or compound conditions; and the root node represents the entire operation. Each node in the abstract syntax tree is assigned a priority weight, determined by the complexity of the operation. Operation complexity considers multiple factors: the basic complexity of the operation type (e.g., delete operations are more complex than queries), the number of tables and fields involved, the complexity of the conditional expressions, and the amount of data potentially affected. For example, a simple field query node might have a low weight, such as 1; a node involving multi-table joins might have a higher weight, such as 5; and a delete operation node that potentially affects a large amount of data might have a very high weight, such as 10. Nodes with dependencies are connected with directed edges to generate an operation dependency graph. Dependencies represent constraints on the order in which operations can be executed; for example, a query on one table might depend on the results of a query on another table.

[0057] The process of rearranging the operation sequence to obtain an execution path based on the priority weights of the nodes in the operation dependency graph is to determine the optimal operation order. The operation dependency graph is analyzed using optimization algorithms, such as topological sorting combined with priority queues. The sorting process considers the priority weights and dependencies of the nodes to ensure that the dependencies are satisfied, while giving priority to operations with lower weights. The rearranged operation sequence forms an execution path, indicating that the operation steps will be executed in the order of this path. The execution path is converted into a standard operation description object, which is a unified internal representation that contains information such as the operation type, target object, field list, conditional expression, execution order, etc., regardless of the specific database type. The standard operation description object uses a structured format to facilitate subsequent processing and conversion.

[0058] The process of obtaining table structure and field attribute information from the structure mapping file prepares data for subsequent type verification. Based on the target object information in the standard operation description object, the corresponding table structure information, including the table's field list, field data type, length / precision, and constraints, is retrieved from the previously generated structure mapping file. Type verification is performed on the standard operation description object to verify that the field types involved in the operation are compatible with the intended operation. Type verification primarily checks the following aspects: type compatibility of comparison operations in conditional expressions (e.g., direct comparison of strings and numbers is not possible); compatibility of values in insert or update operations with the target field type; and support for the type of sorting or grouping fields. When type incompatibility is detected, the optimal type conversion path is identified from a pre-defined conversion template library. This library contains conversion rules between various types, such as string-to-number and date-to-string. The optimal conversion path is selected based on the feasibility of the conversion, precision loss, and performance impact. For example, converting the string "123" to the integer 123 may be safe, but converting "abc" to an integer may result in an error. Based on the selected type conversion path, type conversion code segments are generated. These code segments will be embedded in the final operation statement to ensure type compatibility.

[0059] The process of splitting a standard operation description object into multiple atomic operation units according to the execution cost is to decompose complex operations into basic steps. Analyze the complexity of the standard operation description object, consider factors such as the operation type, the number of tables and fields involved, and the complexity of the conditions, and split it into multiple atomic operation units. Atomic operation units are basic operation steps that cannot be divided any further, such as single-table query, single-field update, etc. The principle of splitting is to balance execution efficiency and resource consumption, and avoid low execution efficiency due to excessive complexity of a single operation. Based on the type conversion code segment generated previously, each atomic operation unit is reorganized to ensure that the type conversion is performed at the appropriate location and generate standardized intermediate operation statements. The intermediate operation statements use a unified format, are independent of the specific database type, and can be converted into SQL statements or API calls for a specific database by the subsequent translation module.

[0060] In this embodiment, through lexical analysis and abstract syntax tree construction, an accurate understanding of the semantics of operation instructions is achieved, avoiding errors that may be caused by simple string replacement; through weighted operation dependency graphs and priority sorting, the operation execution order is optimized, and the execution efficiency of complex operations is improved; through type verification and intelligent conversion, type compatibility issues between different databases are resolved, and the reliability of cross-database operations is enhanced; through atomic operation splitting and reorganization, execution efficiency and resource consumption are balanced, and the operation requirements of databases of different scales and complexities are adapted. These technical effects jointly promote the unified processing and optimized execution of operation instructions in a cross-database environment, simplify application development and database management, and improve the overall system performance and user experience.

[0061] In an optional embodiment, The syntax parsing module of the dialect policy processor is called to parse the intermediate operation statement, generate a syntax tree node sequence, obtain the conversion rule set that matches the database type identifier from the syntax conversion rule library, and convert the syntax tree node sequence into an execution statement for the target database, including: Invoking a syntax parsing module of a dialect policy processor to parse the intermediate operation statement into an initial syntax unit including an operation identifier and a parameter identifier; Establishing a dependency index table for the initial grammatical unit, wherein the dependency index table records the upstream call node and downstream reference node of each grammatical unit, constructing a directed dependency graph based on the dependency index table, calculating the reference depth and call breadth of each grammatical unit, and generating a node weight value; Dividing the initial grammatical units into different processing priorities according to node weight values, clustering grammatical units within the same priority based on semantic similarity, constructing a hierarchical grammar tree containing multiple semantic clusters, and generating a grammar tree node sequence; Obtaining a rule template that matches the database type identifier from a grammar conversion rule library, constructing a rule linked list based on the rule template, setting an execution order for the rule items in the rule linked list, traversing the grammar tree node sequence, calculating the execution cost and resource consumption of the nodes, marking nodes whose execution cost exceeds a preset cost threshold as performance-sensitive nodes, and applying the rule linked list to the performance-sensitive nodes for structural optimization and grammar conversion; The associated processing scope is determined based on the converted performance-sensitive nodes, and the syntax tree nodes within the associated processing scope are sequentially converted into syntax structures according to the execution order to generate execution statements for the target database.

[0062] The process of calling the dialect policy processor's syntax parsing module to parse the intermediate operation statement into initial syntax units containing operation identifiers and parameter identifiers is the starting point of syntax conversion. The syntax parsing module receives the standardized intermediate operation statement generated in the previous step, performs lexical analysis and syntax analysis on it, and identifies operation identifiers (such as SELECT, INSERT, UPDATE, DELETE, etc.) and parameter identifiers (such as table names, field names, conditional expressions, etc.). For example, for the intermediate operation statement "QUERY:TABLE(user_info)|FIELDS(user_id,user_name,age)|WHERE(age>18)|ORDER_BY(user_id,ASC)|LIMIT(10)", the syntax parsing module parses it into initial syntax units such as the operation identifier "QUERY" and the parameter identifiers "TABLE(user_info)", "FIELDS(user_id,user_name,age)", "WHERE(age>18)", "ORDER_BY(user_id,ASC)", and "LIMIT(10)". The parsing process uses recursive descent or table-driven analysis methods to identify sentence structures and constituent elements according to predefined grammatical rules.

[0063] The process of building a dependency index table for the initial grammatical unit involves analyzing the relationships between grammatical units. The dependency index table records the upstream call nodes and downstream reference nodes of each grammatical unit, reflecting the call and reference relationships between grammatical units. Upstream call nodes refer to other units that call the current grammatical unit, while downstream reference nodes refer to other units referenced by the current grammatical unit. For example, the WHERE grammatical unit may reference field names in the FIELDS grammatical unit. Therefore, FIELDS is the upstream call node of WHERE, and WHERE is the downstream reference node of FIELDS. A directed dependency graph is constructed based on the dependency index table. The nodes in the graph represent grammatical units, and the directed edges represent call or reference relationships. The reference depth and call breadth are calculated for each grammatical unit. The reference depth represents the longest path length from the root node to the current node, while the call breadth represents the number of other nodes directly referenced by the current node. The reference depth and call breadth are combined to generate a node weight. For example, a node with a reference depth of 3 and a call breadth of 2 might have a weight of 3 × 2 = 6.

[0064] The process of dividing initial grammatical units into different processing priorities based on node weight values is used to determine the order for subsequent processing. Syntax units are grouped according to node weight values, with units with higher weight values being processed first. Within the same priority level, grammatical units are clustered based on semantic similarity, grouping grammatical units with similar functions. Semantic similarity is calculated by analyzing factors such as the operation type, parameter type, and object of the grammatical unit. For example, although the filtering conditions for multiple fields have different contents, they are semantically part of the WHERE clause and can be clustered for processing. Based on priority grouping and semantic clustering, a hierarchical syntax tree containing multiple semantic clusters is constructed. Each layer contains grammatical units of a specific priority, and the layers within the same layer are organized by semantic clusters. Starting from the root node of the syntax tree, the syntax tree is traversed in depth-first or breadth-first order to generate a sequence of syntax tree nodes that serves as input for subsequent transformations.

[0065] The process of obtaining rule templates that match the database type identifier from the grammar conversion rule library is to prepare conversion rules. The grammar conversion rule library stores grammar conversion rules for different database types, with each database type corresponding to a set of rule templates. Rule templates define how to convert standardized grammatical structures into database-specific grammatical structures. For example, a rule template for a MySQL database might include a rule that converts "LIMIT x, y" to "LIMIT y OFFSET x"; a rule template for an Oracle database might include a rule that converts "LIMIT x to WHERE ROWNUM <= x." Based on the target database type identifier, the corresponding rule template set is retrieved from the rule library. A rule list is constructed based on the rule templates, with each node in the list corresponding to a conversion rule, and nodes are connected by pointers. An execution order is set for the rule items in the rule list, taking into account dependencies and conflicts between rules to ensure the correctness of the conversion process.

[0066] Traverse the sequence of syntax tree nodes and calculate the execution cost and resource consumption of each node. The execution cost reflects the complexity and performance impact of the operation corresponding to the node, and factors considered include the type of operation (such as query, update, etc.), the amount of data involved, the complexity of the conditions, etc. Resource consumption reflects the occupation of system resources when the operation is executed, including memory usage, CPU usage, IO operations, etc. Nodes whose execution costs exceed the preset cost threshold are marked as performance-sensitive nodes, and these nodes require special optimization during the conversion process. For example, query nodes involving large table connections and filter nodes containing complex conditions may be marked as performance-sensitive nodes. Apply rule linked lists to performance-sensitive nodes for structural optimization and syntax conversion. Optimization includes rewriting query conditions, adjusting the connection order, adding index hints, etc. Conversion includes converting standard syntax into a syntax structure unique to the target database.

[0067] The process of determining the scope of associated processing based on the converted performance-sensitive nodes is called expanding the optimization scope. The contextual dependencies of performance-sensitive nodes are analyzed to determine the scope of associated nodes that need to be processed together. The associated processing scope may include directly dependent nodes, indirectly dependent nodes, or functionally related nodes. The syntax tree nodes within the associated processing scope are sequentially converted to grammatical structures in the execution order. The previously constructed rule list is applied to convert the standardized syntax structure into the target database's specific syntax structure. For example, "DATE_ADD(date, INTERVAL 1 DAY)" in MySQL is converted into "date + 1" in Oracle. The conversion process considers factors such as the target database's syntax characteristics, function support, and type system to ensure that the generated execution statement executes correctly in the target database. Finally, the converted syntax tree nodes are reorganized to generate a complete execution statement for the target database, such as a SQL query or API call sequence.

[0068] In this embodiment, through syntax parsing and dependency analysis, the semantic structure and component relationship of the operation statement are accurately understood, providing a basis for subsequent conversion; through node weight calculation and priority division, key processing nodes are identified and the conversion order is optimized; through semantic clustering and hierarchical syntax tree, a structured processing flow is organized to improve the systematic nature of the conversion; through execution cost evaluation and performance-sensitive node identification, optimization resources are focused and conversion efficiency is improved; through rule linked lists and associated processing scopes, context-related syntax conversion is achieved, ensuring the consistency of conversion results. These technical effects jointly promote the accuracy, efficiency and reliability of cross-database operations, reduce the technical threshold for migration and integration between different databases, and improve the development efficiency and user experience of database applications.

[0069] In an optional embodiment, Encapsulate the execution statement into a transaction unit with a rollback mechanism, submit it to the target database for execution, monitor the connection status corresponding to the connection identification information, receive execution status information, generate an operation result report based on the execution status information, and return it to the visual interface for display, including: Parsing the data table access identifier, data operation type, and associated field information in the execution statement, establishing an association relationship table between data tables based on the associated field information, and organizing the execution statements with field references into transaction unit groups based on the association relationship table; Constructing an operation sequence chain for the transaction unit group, generating a corresponding compensation operation for each operation in the operation sequence chain according to the data operation type, and encapsulating the operation sequence chain and the compensation operation into a transaction unit with a rollback mechanism; Perform syntax verification and data consistency check on the execution statements in the transaction unit. After passing the verification, obtain the database connection and submit it to the target database for execution; Record the database connection identification information, collect the network connection status and database session status corresponding to the connection identification information in real time, obtain the checkpoint information of the most recent successful execution when an abnormal state is detected, determine the scope of operations that need to be rolled back based on the checkpoint information, perform the rollback in the reverse order of the compensation operations, and re-initiate the execution request after completion; The operation sequence number, execution time, number of affected rows and error information during the execution process are recorded and organized into a structured operation result report, which is then returned to the visual interface for display.

[0070] Exemplarily, a parser is used to analyze the execution statement generated in the previous step and extract key information. Table access identifiers include the database name, schema name, and table name, uniquely identifying the table involved in the operation. Operation types, such as query (SELECT), insert (INSERT), update (UPDATE), and delete (DELETE), indicate the data processing method. Related field information, including primary keys, foreign keys, and fields used in join conditions, reflects the relationships between tables. For example, for the execution statement "SELECT o.order_id, o.order_date, c.customer_name FROM orders o JOIN customers c ON o.customer_id=c.customer_id WHERE o.order_date>'2023-01-01'," the extracted table access identifiers are "orders" and "customers," the operation type is "SELECT," and the related field information is "orders.customer_id" and "customers.customer_id." Based on the associated field information, a relationship table is created between data tables. This table uses a graph structure, with nodes representing data tables and edges representing relationships. The edges are labeled with the associated fields and the relationship type (e.g., one-to-one, one-to-many, etc.). Based on the relationship table, the dependencies between execution statements are analyzed, and execution statements with field references are organized into transaction units. This ensures that associated operations are executed within the same transaction, maintaining data consistency.

[0071] The process of constructing an operation sequence chain for a transaction unit group involves determining the execution order of operations. The order of operations is determined based on the data operation type and inter-table relationships, and the operation sequence chain is constructed. The operation order follows the following principles: queries generally precede modifications; master table operations generally precede detail table operations; inserts generally precede updates; and updates generally precede deletes. The operation sequence chain employs a linked list structure, with each node containing an operation and its associated information. Based on the data operation type, a corresponding compensation operation is generated for each operation in the operation sequence chain to roll back the executed operation in the event of a transaction failure. The compensation operation generation rules are as follows: for insert operations, the compensation operation is to delete the corresponding record; for delete operations, the compensation operation is to reinsert the deleted record (pre-deletion data must be saved); for update operations, the compensation operation is to restore the updated field to its original value (pre-update data must be saved); and for query operations, no compensation operation is generally required. The operation sequence chain and compensation operation are encapsulated into a transaction unit with a rollback mechanism. This unit contains the execution statement sequence, the compensation operation sequence, and checkpoint information to support exception handling.

[0072] The process of performing syntax validation and data consistency checks on the executed statements within a transaction unit ensures the correctness of the operations. Syntax validation verifies that the executed statements conform to the target database's syntax specifications by parsing their structure, checking for correctness of field names, table names, and keywords. Data consistency checks verify that the operations satisfy data integrity constraints, such as foreign key constraints, uniqueness constraints, and not-null constraints. For example, the checks include whether insert or update operations violate unique index constraints and whether foreign key references are valid. The validation process combines static analysis with pre-execution verification. Static analysis is based on syntax rules and database schema information, while pre-execution verification checks data status by constructing lightweight query statements. Once validation passes, the transaction unit is submitted to the target database for execution, either by obtaining a database connection from the connection pool or using a previously established connection. The submission process sets an appropriate transaction isolation level and timeout to ensure the security and reliability of the operation.

[0073] Transaction monitoring is achieved by recording database connection identification information and collecting connection status in real time. This information includes the connection ID, database type, host address, and username for executing transactions. The network connection status and database session status of the connection are collected in real time. Network connection status includes connection activity, latency, and packet loss rate. Database session status includes session activity, lock wait status, and resource usage. This collection process uses a combination of periodic polling and event triggering. The polling interval is dynamically adjusted based on the importance of the operation, with more frequent monitoring for important operations. When an abnormality is detected, such as a connection loss, session timeout, or lock wait timeout, the most recent successful checkpoint is immediately retrieved. This checkpoint records the progress of transaction execution, including the identification and status of completed operations. Based on the checkpoint information, the scope of operations to be rolled back is determined. All executed operations between the checkpoint and the current operation are rolled back. Rollback is performed in reverse order of compensating operations, starting with the last executed operation and executing each corresponding compensating operation until the rollback reaches the checkpoint. After the rollback is complete, you can choose to abandon the current transaction or re-initiate the execution request from the checkpoint to continue the remaining operations.

[0074] The process of recording operation information during execution and generating an operation result report provides user feedback. The execution status of each operation is recorded, including the operation sequence number (order within the transaction), execution time (start and end time), number of rows affected (number of records inserted, updated, or deleted), and error information (if any errors occur). This information is organized into a structured operation result report in JSON or XML format, containing both overall transaction information and detailed information for each operation. Overall transaction information includes the transaction ID, start and end time, total number of operations, number of successful operations, number of failed operations, and total number of affected rows. Detailed operation information is organized by operation sequence number, and each operation includes its type, target table, execution time, number of affected rows, and error information. The operation result report is returned to the visualization interface for display, which displays the execution results based on the report content, such as success / failure status, amount of data affected, and execution time. For errors, detailed error information and possible resolution suggestions are displayed.

[0075] In this embodiment, through data table association analysis and transaction unit organization, dependencies between operations are identified, ensuring the consistent execution of related operations. Through operation sequence chains and compensation operation mechanisms, orderly transaction execution and exception rollback are achieved, improving the system's fault tolerance. Syntax validation and data consistency checks prevent the execution of erroneous operations and reduce the risk of data anomalies. Through connection status monitoring and checkpoint recovery, real-time supervision of the execution process and exception handling are achieved, enhancing system stability. Structured operation result reporting provides detailed execution feedback and error diagnosis, optimizing the user experience. These technical effects collectively promote the security, reliability, and availability of operation execution in a cross-database environment, providing strong support for database management and application development.

[0076] Figure 3 This is a system architecture diagram of the cross-database unified management and operation method according to an embodiment of the present invention, as shown in Figure 3. Starting from the user request on the left, the resource table is encapsulated and processed through ResourceTable. The port listener receives the request and passes it to the AbstractDatabaseObject abstract database object class. As a core component, this abstract class implements a unified interface for different database dialect policy processors. The figure shows two specific database object implementation classes of MySQL and Oracle. Through the design of this factory pattern, the system realizes unified access and management of different database types. The data generated during the execution process is displayed to the user interface through the data flow on the right, and the system will record data changes and execution status. This architectural design perfectly matches the core functions such as the dialect policy processor mechanism, database connection management, structure mapping, syntax conversion and transaction processing mentioned above, and realizes unified operation and management in a cross-database environment.

[0077] A second aspect of an embodiment of the present invention provides a unified cross-database management and operation system, the system comprising: The first unit is used to obtain a database type identifier, a database access address and access credential information, establish a database connection, and generate connection identification information; The second unit is used to obtain and instantiate the dialect policy processor corresponding to the database type identifier from a preset dialect policy registry, call the metadata extraction method of the dialect policy processor to extract database structure information from the target database, map the database structure information into a unified structure description according to preset metadata mapping rules, and generate a structure mapping file; The third unit is used to parse the database operation instructions sent by the visual interface and convert them into standard operation description objects, and generate standardized intermediate operation statements after verification according to the structure mapping file; The fourth unit is used to call the syntax parsing module of the dialect policy processor to parse the intermediate operation statement, generate a syntax tree node sequence, obtain a conversion rule set that matches the database type identifier from the syntax conversion rule library, and convert the syntax tree node sequence into an execution statement for the target database; The fifth unit is used to encapsulate the execution statement into a transaction unit with a rollback mechanism, submit it to the target database for execution, monitor the connection status corresponding to the connection identification information, receive the execution status information, generate an operation result report based on the execution status information, and return it to the visual interface for display.

[0078] According to a third aspect of an embodiment of the present invention, an electronic device is provided, including: processor; a memory for storing processor-executable instructions; The processor is configured to call the instructions stored in the memory to execute the aforementioned method.

[0079] According to a fourth aspect of an embodiment of the present invention, a computer-readable storage medium is provided, on which computer program instructions are stored. When the computer program instructions are executed by a processor, the method described above is implemented.

[0080] The present invention may be a method, an apparatus, a system and / or a computer program product. The computer program product may include a computer-readable storage medium carrying computer-readable program instructions for executing various aspects of the present invention.

[0081] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A unified management and operation method across databases, characterized in that: include: Obtain database type identification, database access address and access credential information, establish a database connection, and generate connection identification information; Obtaining and instantiating the dialect policy processor corresponding to the database type identifier from a preset dialect policy registry, calling the metadata extraction method of the dialect policy processor to extract database structure information from the target database, mapping the database structure information into a unified structure description according to preset metadata mapping rules, and generating a structure mapping file; Parse the database operation instructions sent by the visual interface and convert them into standard operation description objects, and generate standardized intermediate operation statements after verification according to the structure mapping file; The syntax parsing module of the dialect policy processor is called to parse the intermediate operation statement, generate a syntax tree node sequence, obtain a conversion rule set that matches the database type identifier from the syntax conversion rule library, and convert the syntax tree node sequence into an execution statement for the target database; Encapsulate the execution statement into a transaction unit with a rollback mechanism, submit it to the target database for execution, monitor the connection status corresponding to the connection identification information, receive the execution status information, generate an operation result report based on the execution status information, and return it to the visual interface for display.

2. The method according to claim 1, characterized in that Obtain the database type identifier, database access address, and access credential information, establish a database connection, and generate connection identification information including: Obtain database connection information including database type identifier, database access address and access credential information, and determine the database type identifier from a preset database type mapping table; obtaining a corresponding connection parameter verification rule according to the database type identifier, performing validity verification on the database connection information based on the connection parameter verification rule, and when the database connection information passes the verification, searching for an idle connection that matches the database type identifier and the database access address from a preset database connection pool; if no matching idle connection is found, establishing a database connection based on the database connection information; Performing a connectivity test on the established database connection, adding the database connection to the database connection pool for unified management after the test passes, and generating connection identification information including database type identification, database access address and connection timestamp; Establish a correspondence between the connection identification information and the database connection, store the correspondence in a connection mapping table, and start a connection monitoring thread. The connection monitoring thread periodically detects the connectivity status of the database connection, and automatically reconnects and updates the connection mapping table when a connection anomaly is detected.

3. The method according to claim 1, characterized in that Obtain the dialect policy processor corresponding to the database type identifier from the preset dialect policy registry and instantiate it. Call the metadata extraction method of the dialect policy processor to extract database structure information from the target database. Map the database structure information to a unified structure description according to the preset metadata mapping rules. Generate a structure mapping file including: Obtaining dialect policy processor type information corresponding to the database type identifier from a preset dialect policy registry; the dialect policy processor type information includes a class name and a class path; The bytecode file of the dialect policy processor is loaded according to the class path, the class object of the dialect policy processor is obtained through the reflection mechanism based on the class name, the construction method of the class object is called to generate a dialect policy processor instance, the dialect policy processor instance implements a predefined metadata extraction interface, and the database structure information is extracted from the target database through the metadata extraction interface; Executing preset sampling rules on field values in the database structure information to obtain numerical distribution characteristics, performing intelligent inference on the data type in the database structure information based on the numerical distribution characteristics, outputting inferred type information and inference confidence, comparing the inference confidence with a preset confidence threshold, and when the inference confidence is greater than the preset confidence threshold, using the inferred type information to update the data type mapping relationship in the preset metadata mapping rule library to obtain an optimized metadata mapping rule; The database structure information is input into the optimized metadata mapping rules for conversion, and a structure mapping file with unified structure description is output.

4. The method according to claim 3, characterized in that The preset sampling rules are executed on the field values in the database structure information to obtain the numerical distribution characteristics. Based on the numerical distribution characteristics, the data types in the database structure information are intelligently inferred. The inferred type information and inference confidence are output, including: Dividing the field values in the database structure information into multiple numerical intervals, randomly sampling sample values in each numerical interval, sorting the sample values by numerical value, and then calculating a difference sequence between adjacent sample values, and generating a numerical distribution feature based on the difference sequence; Counting the number of decimal places of numerical data of the sample value to obtain a decimal place distribution feature, counting the character length of character data to obtain a length distribution feature, combining the decimal place distribution feature and the length distribution feature to generate a character structure feature; matching the character structure feature with a preset format template to generate a data pattern feature; The numerical distribution features, character structure features and data pattern features are combined to generate a numerical distribution feature vector, the similarity between the numerical distribution feature vector and the standard feature vector in the preset data type library is calculated, the data type with the highest similarity is selected as the inferred type information, the matching degree between the numerical distribution feature vector and the feature rule set corresponding to the inferred type information is calculated to obtain a feature matching score, the inference confidence is generated based on the comparison result of the feature matching score and the preset matching threshold, and finally the inferred type information and the inference confidence are output.

5. The method according to claim 1, wherein Parse the database operation instructions sent by the visual interface and convert them into standard operation description objects. After verification according to the structure mapping file, generate standardized intermediate operation statements including: Receive database operation instructions sent by the visual interface, perform lexical analysis on the database operation instructions, and extract the operation type, target object and filtering conditions; Constructing a weighted abstract syntax tree based on the operation type, target object, and filtering condition, setting priority weights for nodes in the abstract syntax tree according to the complexity of the operation, and connecting nodes with dependency relationships through directed edges to generate an operation dependency graph; Rearranging the operation sequence based on the priority weights of the nodes in the operation dependency graph to obtain an execution path, and converting the execution path into a standard operation description object; Acquire table structure information and field attribute information from a structure mapping file, perform type checking on the standard operation description object, and when type incompatibility is detected, identify an optimal type conversion path from a preset conversion template library, and generate a type conversion code segment according to the type conversion path; The standard operation description object is split into multiple atomic operation units according to the execution cost, and each atomic operation unit is reorganized based on the type conversion code segment to generate a standardized intermediate operation statement.

6. The method according to claim 1, characterized in that The syntax parsing module of the dialect policy processor is called to parse the intermediate operation statement, generate a syntax tree node sequence, obtain the conversion rule set that matches the database type identifier from the syntax conversion rule library, and convert the syntax tree node sequence into an execution statement for the target database, including: Invoking a syntax parsing module of a dialect policy processor to parse the intermediate operation statement into an initial syntax unit including an operation identifier and a parameter identifier; Establishing a dependency index table for the initial grammatical unit, wherein the dependency index table records the upstream call node and downstream reference node of each grammatical unit, constructing a directed dependency graph based on the dependency index table, calculating the reference depth and call breadth of each grammatical unit, and generating a node weight value; Dividing the initial grammatical units into different processing priorities according to node weight values, clustering grammatical units within the same priority based on semantic similarity, constructing a hierarchical grammar tree containing multiple semantic clusters, and generating a grammar tree node sequence; Obtaining a rule template that matches the database type identifier from a grammar conversion rule library, constructing a rule linked list based on the rule template, setting an execution order for the rule items in the rule linked list, traversing the grammar tree node sequence, calculating the execution cost and resource consumption of the nodes, marking nodes whose execution cost exceeds a preset cost threshold as performance-sensitive nodes, and applying the rule linked list to the performance-sensitive nodes for structural optimization and grammar conversion; The associated processing scope is determined based on the converted performance-sensitive nodes, and the syntax tree nodes within the associated processing scope are sequentially converted into syntax structures according to the execution order to generate execution statements for the target database.

7. The method according to claim 1, characterized in that Encapsulate the execution statement into a transaction unit with a rollback mechanism, submit it to the target database for execution, monitor the connection status corresponding to the connection identification information, receive execution status information, generate an operation result report based on the execution status information, and return it to the visual interface for display, including: Parsing the data table access identifier, data operation type, and associated field information in the execution statement, establishing an association relationship table between data tables based on the associated field information, and organizing the execution statements with field references into transaction unit groups based on the association relationship table; Constructing an operation sequence chain for the transaction unit group, generating a corresponding compensation operation for each operation in the operation sequence chain according to the data operation type, and encapsulating the operation sequence chain and the compensation operation into a transaction unit with a rollback mechanism; Perform syntax verification and data consistency check on the execution statements in the transaction unit. After passing the verification, obtain the database connection and submit it to the target database for execution; Record the database connection identification information, collect the network connection status and database session status corresponding to the connection identification information in real time, obtain the checkpoint information of the most recent successful execution when an abnormal state is detected, determine the scope of operations that need to be rolled back based on the checkpoint information, perform the rollback in the reverse order of the compensation operations, and re-initiate the execution request after completion; The operation sequence number, execution time, number of affected rows and error information during the execution process are recorded and organized into a structured operation result report, which is then returned to the visual interface for display.

8. A unified management and operating system across databases, used to implement the method according to any one of claims 1 to 7, characterized in that: include: The first unit is used to obtain a database type identifier, a database access address and access credential information, establish a database connection, and generate connection identification information; The second unit is used to obtain and instantiate the dialect policy processor corresponding to the database type identifier from a preset dialect policy registry, call the metadata extraction method of the dialect policy processor to extract database structure information from the target database, map the database structure information into a unified structure description according to preset metadata mapping rules, and generate a structure mapping file; The third unit is used to parse the database operation instructions sent by the visual interface and convert them into standard operation description objects, and generate standardized intermediate operation statements after verification according to the structure mapping file; The fourth unit is used to call the syntax parsing module of the dialect policy processor to parse the intermediate operation statement, generate a syntax tree node sequence, obtain a conversion rule set that matches the database type identifier from the syntax conversion rule library, and convert the syntax tree node sequence into an execution statement for the target database; The fifth unit is used to encapsulate the execution statement into a transaction unit with a rollback mechanism, submit it to the target database for execution, monitor the connection status corresponding to the connection identification information, receive the execution status information, generate an operation result report based on the execution status information, and return it to the visual interface for display.

9. An electronic device, characterized in that: include: processor; a memory for storing processor-executable instructions; The processor is configured to call the instructions stored in the memory to execute the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having computer program instructions stored thereon, characterized in that: When the computer program instructions are executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Images