A method and system for automatic generation and optimization of database table structure

Abstract

This invention discloses a method and system for automated generation and optimization of database table structures. The method specifically includes: receiving the user's backend project source code; extracting a semantic information network graph related to data persistence through static code scanning; inputting the semantic information network graph into an intelligent parsing engine to analyze code logic relationships and obtain index recommendation strategies and potential table structure design flaws; based on the index recommendation strategies and potential table structure design flaws, identifying sensitive fields and recommending encryption or de-identification schemes to obtain a first table structure; performing automated stress testing on the first table structure and adjusting the index strategy and partitioning scheme based on the test results; and optimizing the first table structure according to the adjusted index strategy and partitioning scheme to obtain a second table structure. This invention achieves intelligent generation and optimization of database table structures, improving development efficiency, enhancing maintainability, improving user experience, and ensuring data security.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and in particular to a method and system for automatically generating and optimizing database table structures. Background Technology

[0002] In today's information age, databases play a crucial role as the core data storage and management component of various application systems. During application system development, developers must carefully design and create database tables based on business requirements to ensure that data can be stored and accessed efficiently, securely, and systematically.

[0003] However, the traditional method of manually creating database tables has many drawbacks. Firstly, it is extremely inefficient. The manual creation process is tedious and complex, involving numerous details and rules to consider. Developers must determine the structure, field types, and constraints of each table one by one. This not only consumes a significant amount of time and effort, but also becomes even more difficult in large projects due to the sheer number and complexity of the database tables involved. It is highly prone to omissions and errors, severely impacting development progress and efficiency. For example, in a large e-commerce system, multiple modules such as products, orders, and users involve numerous related tables. Slight carelessness during manual creation can lead to incorrect field definitions or missing relationships, thereby affecting the implementation of subsequent business logic.

[0004] Secondly, maintainability is poor. Manually created database tables lack unified specifications and standards, making centralized and unified management and maintenance difficult. Especially when requirements change frequently, each adjustment may require modifications to multiple related tables. Manual operation is not only prone to errors but also struggles to ensure consistency, leading to a chaotic database structure and significantly reduced maintainability. For example, when business requirements change to add new fields or modify field types, manually modifying multiple related tables may result in omissions or inconsistencies, causing considerable trouble for subsequent system maintenance.

[0005] Third, the user experience is poor. Developers need to invest a significant amount of time and energy in the tedious task of database table design, preventing them from fully focusing on implementing business logic. This not only prolongs the project development cycle but may also affect the effectiveness of business functions due to unreasonable database table design, thereby degrading the user experience. For example, due to inefficient querying caused by unreasonable database table design, users may experience long wait times when browsing products or querying orders, severely impacting the user experience.

[0006] Fourth, there are security issues. Manual operations lack effective standards and constraints, easily leading to non-standard database table designs, thus creating potential security vulnerabilities. For example, failure to properly encrypt or de-identify sensitive fields may result in the leakage of user privacy information; unreasonable table structure design may make the database vulnerable to malicious attacks, such as SQL injection attacks, causing huge losses to enterprises.

[0007] While some tools exist on the market to assist in database design, most have significant shortcomings. These tools often require developers to perform extensive manual configuration work, resulting in low levels of automation and failing to meet the rapid iteration needs of modern application systems. For example, some tools only provide basic table structure generation capabilities and cannot automatically handle complex foreign key relationships, indexing strategies, and security policies, still requiring manual intervention from developers. Consequently, they cannot truly achieve efficient and intelligent database table design and management. Summary of the Invention

[0008] The purpose of this invention is to provide a method and system for automated generation and optimization of database table structures, which realizes intelligent generation and optimization of database table structures, improves development efficiency, enhances maintainability, improves user experience and ensures data security, thereby solving at least one of the aforementioned problems in the prior art.

[0009] In a first aspect, the present invention provides a method for automatically generating and optimizing database table structures, the method specifically comprising: Receive the user's backend project source code and extract a semantic information network graph related to data persistence through static code scanning; The semantic information network graph is input into the intelligent parsing engine, and a pre-trained machine learning model is called to analyze the logical relationships in the code, infer the foreign key relationships between entities and predict data access patterns, and obtain index recommendation strategies and potential table structure design defects. Based on the index recommendation strategy and potential table structure design flaws, the security policy engine automatically identifies sensitive fields and recommends encryption or de-identification schemes to obtain the first table structure. The first table structure was automatically stress-tested using performance testing tools to obtain test results, and the index strategy and partitioning scheme were optimized based on the test results. The structure of the first table is optimized based on the index tuning strategy and partitioning scheme to obtain the structure of the second table. The structure of the second table is then adapted to the target cloud database environment, and an executable data definition language script, security policy configuration file, and structure optimization suggestion report are generated in a unified manner.

[0010] Secondly, this invention provides a system for automatically generating and optimizing database table structures, the system specifically comprising: The code scanning module is used to receive the user's backend project source code and extract semantic information network graphs related to data persistence through static code scanning. The semantic parsing module is used to input the semantic information network graph into the intelligent parsing engine, call the pre-trained machine learning model to analyze the logical relationships in the code, infer the foreign key relationships between entities and predict data access patterns, and obtain index recommendation strategies and potential table structure design defects. The security strategy module is used to automatically identify sensitive fields and recommend encryption or de-identification schemes based on index recommendation strategies and potential table structure design defects, thereby obtaining the first table structure. The performance testing module is used to perform automated stress testing on the first table structure using performance testing tools, obtain test results, and provide feedback on the test results to optimize index strategies and partitioning schemes. The optimization and deployment module is used to optimize the structure of the first table based on the tuning index strategy and partitioning scheme to obtain the structure of the second table, adapt the structure of the second table to the target cloud database environment, and uniformly generate executable data definition language scripts, security policy configuration files and structure optimization suggestion reports.

[0011] Thirdly, the present invention provides a computer device, comprising: a memory and a processor, and a computer program stored in the memory, wherein when the computer program is executed on the processor, it implements the method for automatically generating and optimizing database table structures as described in any of the above methods.

[0012] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the method for automatically generating and optimizing database table structures as described in any of the above methods.

[0013] Compared with the prior art, the present invention has at least one of the following technical effects: 1. This invention realizes intelligent generation and optimization of database table structure, improves development efficiency, enhances maintainability, improves user experience and ensures data security.

[0014] 2. This invention receives the source code of a backend project, automatically extracts the semantic information network graph, and uses an intelligent parsing engine to analyze the logical relationships in the code, infer foreign key relationships, predict data access patterns, and then generate an index recommendation strategy. This avoids the tedious design process of manually creating database tables one by one, greatly shortens the development cycle, and significantly improves development efficiency.

[0015] 3. This invention generates database table structures based on a unified method and produces a structure optimization suggestion report, ensuring that the database table structures have unified specifications and standards, facilitating centralized management and maintenance. When requirements change, the table structure can be quickly adjusted according to the optimization suggestions, ensuring consistency of modifications and effectively enhancing the maintainability of the database.

[0016] 4. This invention frees developers from spending excessive time and effort on database table design, allowing them to focus more on implementing business logic. This accelerates the development of business functions and improves their quality. Furthermore, a well-designed table structure helps improve database query efficiency, reduces user waiting time, and ultimately enhances the user experience.

[0017] 5. This invention automatically identifies sensitive fields and recommends encryption or de-identification schemes through a security policy engine, which can effectively avoid the leakage of sensitive information caused by improper manual operation, enhance database security, and protect the data security of enterprises and users.

[0018] 6. This invention realizes the fully automated generation and optimization of database table structures from code extraction to final adaptation to the cloud database environment, which improves the efficiency and accuracy of database table structure design and reduces manual design costs and errors.

[0019] 7. This invention, through a multilingual syntax parser, a unified abstract syntax tree, and a code semantic understanding model, can accurately extract semantic information network graphs related to data persistence from the source code of backend projects in different languages, providing a foundation for subsequent analysis.

[0020] 8. This invention utilizes a relational reasoning model, an access pattern prediction model, an index strategy rule engine, and a defect identification model to comprehensively reason about foreign key relationships, predict data access patterns, generate index recommendation strategies, and identify potential table structure design defects, thereby improving table structure quality.

[0021] 9. This invention, through a pre-trained relational graph attention neural network model, can accurately infer and output a list of proposed foreign key relationships to be established between entities, providing a reliable basis for the design of foreign key relationships in table structures.

[0022] 10. This invention extracts multi-level features and utilizes a multi-task deep learning model to predict the weights of each field and field combinations in multiple future data access scenarios in parallel, providing data support for index recommendation.

[0023] 11. Based on multiple rule engines and foreign key, single field, and composite index rules, this invention can generate a comprehensive set of index recommendation strategies that have undergone conflict detection and resolution, thereby optimizing database query performance.

[0024] 12. This invention combines a defect pattern library and a graph neural network classification model to comprehensively identify explicit and implicit potential table structure design defects in semantic information network graphs, thereby improving the rationality of table structure design.

[0025] 13. Based on multidimensional context, sensitive field classifier and security policy engine, this invention can automatically identify sensitive fields and recommend encryption or desensitization schemes to generate a secure first table structure, thus ensuring data security.

[0026] 14. This invention improves database performance by orchestrating performance test load scenarios, collecting performance indicators, analyzing performance bottlenecks, and generating tuning actions. It can also provide feedback on the test results to tune index strategies and partitioning schemes. Attached Figure Description

[0027] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 This is a flowchart illustrating an automated database table structure generation and optimization method according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of a database table structure automatic generation and optimization system provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0029] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0030] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0031] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0032] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0033] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0034] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0035] In this application embodiment, the entity executing the process includes a terminal device. This terminal device includes, but is not limited to, devices capable of executing the methods disclosed in this application, such as servers, computers, smartphones, and tablets. Figure 1 A flowchart illustrating an embodiment of the automated database table structure generation and optimization method disclosed in this invention is shown below: S101 receives the user's backend project source code and extracts a semantic information network graph related to data persistence through static code scanning.

[0036] In this embodiment, a dedicated code receiving module is established, equipped with interfaces compatible with various common development environments and version control systems. When a user initiates a request for automated generation and optimization of the database table structure, the code receiving module retrieves the backend project source code from the user-specified code repository through these interfaces. Specifically, the code receiving module connects to the corresponding version control system based on the repository address, access credentials, and other information provided by the user. Then, according to the branch or tag specified by the user, it downloads the entire backend project source code to the local specified storage area. During the download process, the code receiving module performs integrity verification on the downloaded files to ensure that the obtained source code is consistent with that in the repository, avoiding problems in subsequent processing due to transmission errors.

[0037] Launch the static code analysis tool, which will perform a comprehensive scan of the received backend project source code. During the scan, it will analyze every file, function, and class line by line. For code related to data persistence, the tool will focus on statements and logic related to database operations. For example, in a Java project, it will look for code snippets using persistence frameworks such as JDBC, Hibernate, and MyBatis; in a Python project, it will look for code snippets using persistence tools such as SQLAlchemy and Django ORM.

[0038] After identifying the code related to data persistence, static code analysis tools further analyze the semantic information within this code. It parses the entity classes defined in the code, which typically correspond to table structures in the database. For example, in the backend code of an e-commerce system, there might be product entity classes, order entity classes, and user entity classes. The analysis tool extracts the attribute information of these entity classes, such as product name, price, and inventory attributes in the product entity class; these attributes correspond to fields in the database tables. Simultaneously, the analysis tool also analyzes the relationships between entity classes. For instance, the order entity class might contain references to the user entity class, indicating a relationship between the order table and the user table.

[0039] Based on the extracted semantic information, static code scanning tools construct a semantic information network graph. In this graph, each entity class is represented as a node, and the attributes of the entity class are stored as the attributes of the node. The relationships between entity classes are represented by edges, with the direction of the edge indicating the direction of the relationship. For example, a path from an order node to a user node indicates a relationship from order to user. The type of relationship is also labeled on the edges, such as one-to-one, one-to-many, or many-to-many. In this way, static code scanning tools visually present the semantic information related to data persistence in the backend project's source code in the form of a network graph, providing foundational data for subsequent intelligent parsing engine processing.

[0040] S102, input the semantic information network graph into the intelligent parsing engine, call the pre-trained machine learning model to analyze the code logic relationship, infer the foreign key relationship between entities and predict the data access pattern, and obtain the index recommendation strategy and potential table structure design defects.

[0041] In this embodiment, a runtime environment for the intelligent parsing engine is constructed. This environment is built on a high-performance server cluster, possessing powerful computing and storage capabilities to handle the processing requirements of large-scale semantic information network graphs. A dedicated machine learning framework, such as TensorFlow or PyTorch, is installed on the server to provide runtime support for pre-trained machine learning models. Simultaneously, a corresponding database management system is configured to store and manage the semantic information network graph, as well as intermediate and result data generated during subsequent processing.

[0042] The extracted semantic information network graph is imported into the designated storage area of ​​the intelligent parsing engine. The semantic information network graph is stored using a specific data structure, such as a graph database, where each node represents an entity, node attributes store relevant entity information, and edges represent relationships between entities. The intelligent parsing engine performs preliminary preprocessing on the imported semantic information network graph, including data cleaning and format conversion, to ensure that the network graph's data format meets the input requirements of machine learning models. For example, it checks whether the attributes of nodes and edges are complete and converts non-standard data formats into uniform numerical or string formats.

[0043] The pre-trained machine learning model, trained on a large amount of labeled code logic relationship data, is invoked. This model possesses the ability to analyze code logic, infer entity relationships, and predict data access patterns. When invoking the model, the intelligent parsing engine dynamically allocates computing resources based on the size and complexity of the semantic information network graph to ensure efficient model operation. The pre-processed semantic information network graph is then passed as input data to the machine learning model, which begins analyzing the nodes and edges in the network graph.

[0044] In analyzing code logic relationships, machine learning models identify the strength and type of associations between entities. For example, by analyzing the weights and attributes of edges between nodes, they determine whether the relationship between two entities is one-to-one, one-to-many, or many-to-many. For inferring foreign key relationships, the model determines which fields are foreign key fields, and the primary table and primary key they reference, based on the associations between entities and common foreign key reference patterns in the code. For example, if there is an association between an order entity and a user entity, and a field in the order entity has a value that corresponds to the primary key value in the user entity, the model will infer that this field is a foreign key field referencing the user table.

[0045] In predicting data access patterns, machine learning models analyze the frequency and methods of accessing different entities in the code. For example, by counting the number of query, insert, update, and delete operations on a particular entity in the code, the model predicts the data access hotspots for that entity in subsequent business operations. Simultaneously, the model also considers the impact of relationships between entities on data access patterns. For instance, when querying order information, user information is usually accessed simultaneously, thus predicting a joint access pattern between the order and user entities.

[0046] Based on the inferred foreign key relationships and predicted data access patterns, the machine learning model generates index recommendation strategies. For entities that are frequently accessed in a join, the model recommends creating indexes on the fields that are related between them to improve query efficiency. For example, if the order and user entities are frequently joined and are related by the user ID field, the model would recommend creating an index on the user ID field of the order table. Simultaneously, the model analyzes the rationality of the table structure and identifies potential table design flaws. For example, if an entity has too many fields, resulting in an overly broad table, the model will indicate that this may affect query performance and suggest splitting or optimizing the table.

[0047] Finally, the intelligent parsing engine organizes and stores the index recommendation strategies and potential table structure design flaws generated by the machine learning model for use in subsequent processing steps. Simultaneously, these results are presented to developers in a visual manner for easy understanding and evaluation.

[0048] S103, based on the index recommendation strategy and potential table structure design flaws, automatically identifies sensitive fields through the security policy engine and recommends encryption or de-identification schemes to obtain the first table structure.

[0049] In this embodiment, the index recommendation strategy and potential table structure design flaw data are imported into the designated storage area of ​​the security policy engine. The security policy engine then begins analyzing the data to identify sensitive fields. It matches these fields against a pre-defined sensitive field rule base. The rule base contains feature information for various common sensitive fields. For example, for user information-related tables, fields such as ID card numbers, mobile phone numbers, and bank card numbers are defined as sensitive fields. The rule base records detailed characteristics such as the length, format, and location of these fields. The security policy engine compares each field in the table with the features in the rule base. If a field's features highly match the sensitive field features in the rule base, then that field is determined to be a sensitive field. For example, in a user table, if there is a field with an 18-digit length and a format conforming to ID card encoding rules, the security policy engine will identify it as an ID card number sensitive field.

[0050] After identifying sensitive fields, the security policy engine recommends appropriate encryption or de-identification schemes for each field based on its sensitivity and business requirements. For highly sensitive fields, such as passwords, strong encryption algorithms, such as AES, are recommended. This algorithm offers high security and encryption strength, effectively protecting data from leakage. For fields that require partial display but whose original information is not fully exposed, such as phone numbers, de-identification schemes are recommended, such as displaying only the first three and last four digits, replacing the middle part with specific symbols.

[0051] When recommending encryption or data masking solutions, the security policy engine also fully considers the consistency of business logic and data consistency. For example, if a field has relationships in multiple tables and all require encryption or data masking, the engine ensures that the processing methods in these tables are consistent to avoid data relationship problems caused by different processing methods. At the same time, the engine records the recommended processing method for each sensitive field, forming a detailed solution document.

[0052] Based on the identified sensitive fields and their recommended encryption or de-identification schemes, the security policy engine adjusts and optimizes the original table structure, combining index recommendation strategies and potential table structure design flaws. For tables with recommended indexes but without considering security factors, the engine integrates the index strategy into the table structure while ensuring security. For example, if a sensitive field is recommended for encryption and is also an indexed field, the engine ensures that the encrypted field still meets the functional requirements of the index. For tables with potential table structure design flaws, the engine makes corresponding improvements according to the security policy, such as splitting tables containing too many sensitive fields to reduce the risk of data leakage. After this series of adjustments and optimizations, the first table structure is finally obtained.

[0053] Finally, the security policy engine presents the first table structure to the developers in a visual way, while generating a detailed report. The report includes sensitive field identification results, recommended encryption or de-identification schemes, and optimization instructions for the table structure, making it easier for developers to understand and evaluate.

[0054] S104 uses performance testing tools to perform automated stress testing on the structure of the first table, obtains test results, and provides feedback on the indexing strategy and partitioning scheme based on the test results.

[0055] In this embodiment, a performance testing environment is set up. A stable server with high configuration is selected as the test host, ensuring it has sufficient computing resources, memory capacity, and storage space to simulate real and complex business scenarios. Professional performance testing tools are installed on the test host. These tools need to have powerful automated testing capabilities, be able to simulate various types of concurrent user access, and support precise monitoring of database-related performance indicators. Simultaneously, a database instance corresponding to the first table structure is deployed in the test environment. The version and configuration of this instance should be as consistent as possible with the actual production environment to ensure the accuracy and reliability of the test results.

[0056] Configure performance testing tools. Based on the business characteristics and expected user access patterns of the first table structure, set reasonable test parameters in the performance testing tools. For example, set the number of concurrent users to simulate peak user access times during different periods, such as the high concurrency scenario of an e-commerce system during promotional activities; set the frequency and types of requests, covering common operations such as queries, inserts, updates, and deletes, and determine the execution ratio of these operations based on business logic. Simultaneously, configure the testing tools to monitor database performance metrics, including query response time, transaction processing time, database connection count, and disk I / O operation frequency, to comprehensively evaluate the performance of the first table structure under pressure.

[0057] Launch a performance testing tool to perform automated stress testing. The tool automatically generates a large number of simulated user requests according to preset parameters and scenarios, and concurrently sends these requests to the database instance with the first table structure. During the test, the tool collects and records various performance metrics in real time, storing this data in dedicated log files or a database for later analysis. For example, it records the response time of each query request and calculates the average and maximum transaction processing times under a specific number of concurrent users.

[0058] After completing the stress test, conduct a detailed analysis of the collected test results. Utilize the data analysis functions built into the performance testing tool, or export the data to professional data analysis software to generate intuitive charts and reports. By analyzing this data, identify performance issues and bottlenecks in the first table structure. For example, if the response time of certain query operations is found to be too long, it may indicate that the relevant index design is unreasonable; if the disk I / O operation frequency is too high, it may indicate that there are problems with the table's data distribution or partitioning strategy.

[0059] Based on the analysis of test results, feedback is provided to optimize indexing strategies. If it is found that some queries do not fully utilize indexes or that indexes are inefficient, consider redesigning the indexes. For example, for fields that are frequently queried but do not have appropriate indexes, add the corresponding indexes; for composite indexes, adjust the order of index fields according to query frequency and selectivity. At the same time, evaluate the number and type of existing indexes, and delete some redundant or inefficient indexes to reduce index maintenance overhead and improve the overall performance of the database.

[0060] Optimize the partitioning scheme. If test results show obvious hotspots in data access, or if the large amount of data in some partitions causes performance degradation, consider adjusting the partitioning strategy. For example, for a table partitioned by time range, if the data access frequency of a certain time period is much higher than that of other time periods, the data in that time period can be further subdivided into partitions; for a table partitioned by business type, if the data of certain business types grows too quickly, resulting in insufficient partition space, the partition size can be replanned or new partitions can be added.

[0061] Finally, the optimized indexing strategy and partitioning scheme should be documented in detail. This document should include the reasons for the optimization, the specific adjustments made, and the expected results, for future maintenance and optimization. Simultaneously, the optimized strategy should be applied to the first table structure to prepare for further optimization and deployment in the actual production environment.

[0062] S105: Optimize the structure of the first table based on the index tuning strategy and partitioning scheme to obtain the structure of the second table. Adapt the structure of the second table to the target cloud database environment and uniformly generate an executable data definition language script, a security policy configuration file, and a structure optimization suggestion report.

[0063] In this embodiment, after obtaining the optimized indexing strategy and partitioning scheme, the index portion of the first table structure is first optimized. Based on the index recommendation strategy, for fields that were originally missing indexes but were frequently queried, corresponding indexes are added to the second table structure. For example, if it is found that a field used for user order status queries in the first table structure lacks an index, leading to low query efficiency, then a suitable index is created for that field in the second table structure to improve query speed. Simultaneously, redundant or inefficient indexes are deleted or adjusted. For instance, if a composite index exists, but analysis reveals that a certain field within it is rarely used in queries, then the composite index can be rebuilt, removing this infrequently used field to reduce index maintenance overhead.

[0064] To optimize the partitioning scheme, the structure of the first table is adjusted based on the optimized partitioning strategy. If the original partitioning scheme is based on time ranges, but testing reveals that the data volume in certain time periods is too large, leading to a decrease in query performance, then the partitions for those time periods can be further subdivided in the second table structure. For example, a table originally partitioned by year can be changed to partition by month for years with large data volumes, making the data distribution more even and improving query efficiency.

[0065] After optimizing the indexes and partitions, other elements in the table structure, such as field types and constraints, are checked and adjusted. This ensures that field types meet business requirements and maximize storage efficiency, and that constraints guarantee data integrity and consistency. After these comprehensive optimizations, the second table structure is obtained.

[0066] After obtaining the second table structure, it needs to be adapted to the target cloud database environment. First, understand the characteristics and requirements of the target cloud database. Different cloud databases may differ in data type support, index types, partitioning methods, etc. For example, some cloud databases may not support specific index types or have limitations on the number of partitions.

[0067] The structure of the second table needs to be adjusted according to the characteristics of the target cloud database. If the target cloud database does not support a certain index type used in the second table structure, then a similarly performing index type that is supported by the cloud database needs to be selected for replacement. If the cloud database has a limit on the number of partitions, and the number of partitions in the second table structure exceeds the limit, then the partitioning strategy needs to be replanned, such as merging some partitions or using different partitioning fields.

[0068] Simultaneously, consider the performance optimization parameters and configuration of the target cloud database. Based on cloud database documentation and best practices, adjust parameters related to the second table structure, such as cache size and concurrent connections, to ensure the second table structure achieves optimal performance in the target cloud database environment.

[0069] After adapting the second table structure to the target cloud database environment, the next step is to generate an executable Data Definition Language (DDL) script. Using a dedicated script generation tool or according to the cloud database's syntax rules, the second table structure is converted into an executable SQL script. This script should contain all necessary statements for creating tables, adding indexes, and setting partitions, ensuring that the second table structure is created accurately and without error in the target cloud database.

[0070] Next, a security policy configuration file is generated. Based on the encryption or de-identification schemes recommended by the security policy engine, the relevant security policy configuration information is organized into a configuration file. This configuration file should clearly specify which fields need to be encrypted or de-identified, as well as the specific encryption algorithm or de-identification method used, so as to implement corresponding security measures in the target cloud database environment.

[0071] Finally, generate a structural optimization recommendation report. The report should detail the entire optimization process, including the basis for tuning index strategies and partitioning schemes, specific optimizations to the second table structure, and adjustments made to adapt to the target cloud database environment. Simultaneously, it should evaluate and analyze the expected improvements in performance, security, and maintainability of the optimized second table structure, providing a reference for subsequent system maintenance and further optimization. The generated scripts, configuration files, and reports should be organized and stored for future use and management.

[0072] In some embodiments, step S101 above, which involves receiving the user's backend project source code and extracting a semantic information network graph related to data persistence through static code scanning, specifically includes: Receive the user's backend project source code, and distribute the backend project source code of different programming languages ​​to the corresponding multi-language syntax parser according to the project structure and file type; A multilingual syntax parser is used to perform lexical and syntactic analysis on the backend project source code to generate a unified abstract syntax tree. The nodes of the unified abstract syntax tree are input into a pre-trained code semantic understanding model. By analyzing identifier naming, code context and comment text, business semantic annotation and relationship inference are performed on the nodes, and structural information containing the business meaning of data entities and fields, potential relationships between entities and data operation intentions are identified. A semantic information network graph is constructed based on structural information and data operation intentions. The nodes of the semantic information network graph are used to represent entities, fields, application interface endpoints, and query fragments, and the edges of the semantic information network graph are used to represent the inclusion, calling, referencing, or mapping relationships between nodes.

[0073] In this embodiment, upon receiving the backend project source code submitted by the user, the system first performs a comprehensive scan and analysis of the project's overall structure. Based on the file types and structural characteristics of the project, it accurately determines the programming language used in the source code. For example, if the project directory contains files with the .java extension, and the file content conforms to the syntax of the Java language, and the project structure follows the common organizational form of Java projects, such as including directory levels like src, main, and java, then the system will determine that the backend project source code uses the Java language.

[0074] After determining the programming language, the system accurately assigns the backend project source code in different programming languages ​​to the corresponding multi-language parser based on the pre-configured language-parser mapping. For example, Java source code is assigned to a dedicated Java parser, while Python source code is assigned to a Python parser. This assignment mechanism ensures that the source code in each language receives the most suitable parsing processing, laying the foundation for subsequent lexical and syntactic analysis.

[0075] The backend project source code, assigned to the corresponding multilingual syntax parser, will then enter the lexical and syntax analysis phases. The lexical analyzer will scan the source code character by character, breaking it down into meaningful lexical units, such as keywords, identifiers, operators, and constants. For example, in Java code, keywords such as `public` and `class` will be identified as specific lexical units, and identifiers such as variable names and method names will be accurately extracted.

[0076] The parser, based on lexical analysis and according to the syntax rules of the corresponding programming language, combines these lexical units into meaningful syntactic structures, generating an Abstract Syntax Tree (AST). While the ASTs generated by different programming languages ​​may differ in structure, the system adopts a unified AST representation for easier subsequent processing. Through specific transformation rules and mapping mechanisms, ASTs generated by different languages ​​are converted into a unified format. This unified AST clearly displays the syntactic structure of the source code in a tree-like structure, providing a structured data foundation for subsequent semantic analysis.

[0077] Each node of the unified abstract syntax tree is input into a pre-trained code semantic understanding model. This model, trained on a large number of code samples, possesses the ability to deeply understand code semantics. When processing nodes, the model comprehensively considers multiple aspects of information for business semantic annotation and relationship inference. First, the model analyzes the naming of identifiers. Identifiers in code are typically used to represent elements such as variables, methods, and classes, and their names often reflect certain business meanings. For example, in the code of an e-commerce system, the identifier `orderTotalPrice` likely represents the total price of an order. The model performs preliminary business semantic annotation of the identifier based on this common naming convention and business scenario knowledge. Second, the model combines the contextual information of the code. The code context can provide richer semantic clues, helping the model to more accurately understand the meaning of nodes. For example, in a method, if a variable is used to calculate the total price of goods in a series of operations, and this method is called by other methods related to order processing, then the model can infer that the variable is related to order business. Furthermore, the model also considers comment text. Comments are textual explanations added by developers to explain code functionality, often containing important business information. The model performs natural language processing on the annotation text, extracts key information, and associates it with the corresponding code nodes, further enriching the business semantic annotation of the nodes. By comprehensively analyzing identifier naming, code context, and annotation text, the model can accurately annotate nodes with business semantics, identifying the business meaning of data entities (such as users, products, orders, etc.), fields (such as user name, product price, order status, etc.), and structural information about potential relationships between entities. It can also infer the intent of data operations, such as whether the data is being queried, inserted, updated, or deleted.

[0078] Based on the structural information and data operation intentions identified earlier, the system begins to construct a semantic information network graph. The semantic information network graph uses a graph structure to represent the semantic relationships in the code, where nodes and edges each have specific meanings.

[0079] The nodes in a semantic information network graph represent entities, fields, application programming interface (API) endpoints, and query fragments. Entities are the core objects in the business logic, such as users, products, and orders; fields are the attributes of entities, such as a user's age, a product's price, and an order's date; API endpoints are the interfaces in the system that provide data access and manipulation, such as interfaces for retrieving user information or submitting orders; and query fragments are code snippets used to retrieve data from the database, such as parts of an SQL query statement.

[0080] Edges in a semantic information network graph are used to represent inclusion, invocation, reference, or mapping relationships between nodes. For example, an order entity node may contain multiple order field nodes, such as order number and order amount, which are connected by inclusion edges; a method node may call another method node, which are connected by invocation edges; a variable node may reference another variable node, which are connected by reference edges; in database operations, field nodes in the code may have mapping relationships with field nodes in the database table, which are connected by mapping edges.

[0081] By constructing a semantic information network graph, the system can present the semantic information related to data persistence in the backend project source code in an intuitive and structured way, providing an important semantic foundation for subsequent database table structure generation and optimization.

[0082] In some embodiments, step S102 above, which involves inputting the semantic information network graph into the intelligent parsing engine, calling a pre-trained machine learning model to analyze code logic relationships, inferring foreign key relationships between entities and predicting data access patterns, and obtaining index recommendation strategies and potential table structure design defects, specifically includes: The semantic information network graph is input into the relational reasoning model trained on the graph neural network. By learning the graph structure and calculating the confidence of the potential associations between entity nodes in the semantic information network graph, the model infers and outputs a list of foreign key relationships to be established between entities. The frequency of field-level operations and contextual features contained in the semantic information network graph are input into the access pattern prediction model based on multi-task learning and training, and the weights of each field and field combination under multiple future data access scenarios are predicted in parallel. Based on the foreign key relationship suggestion list and the weights of each field and field combination under future data access scenarios, a corresponding set of index recommendation strategies is generated according to the preset index strategy rule engine. Based on a pre-built defect pattern library and a pre-trained graph neural network classification model, the semantic information network graph is scanned and analyzed to identify potential table structure design defects.

[0083] In this embodiment, the constructed semantic information network graph is input into a relational reasoning model trained based on a graph neural network. During the training phase, this relational reasoning model uses a large number of semantic information network graph samples containing known foreign key relationships for learning. After inputting the current semantic information network graph, the model extracts features from the entity nodes in the graph. These entity node features include the node type (e.g., representing different business entities such as users, orders, and products), the field information associated with the node, and the node's topological position in the graph.

[0084] Relational reasoning models leverage the characteristics of graph neural networks to learn the graph structure of semantic information networks. They analyze structural features such as connection paths between entity nodes, edge types (e.g., inclusion relationships, call relationships), and edge weights (if weight information exists). Through this learning process, the model can uncover potential association patterns between entity nodes.

[0085] After completing graph structure learning, the relational reasoning model calculates confidence scores. For each pair of entity nodes that may have a foreign key relationship, the model calculates a confidence score based on the learned features and association patterns to indicate the likelihood of a foreign key relationship between them. A higher confidence score indicates a greater probability of a foreign key relationship between the pair of entity nodes.

[0086] Finally, the relational inference model sorts all possible foreign key relationships based on confidence scores and outputs a suggested list of foreign key relationships to be established between entities. This list is arranged from highest to lowest confidence, providing important reference for subsequent database design. For example, in the semantic information network graph of an e-commerce system, the model might infer that there is a foreign key relationship to be established between the "order table" and the "user table," and that this relationship ranks high in the suggestion list, indicating a high necessity for establishing a foreign key relationship between these two tables.

[0087] The field-level operation frequencies and contextual features contained in the semantic information network graph are input into an access pattern prediction model trained based on multi-task learning. During the data preparation phase, operation frequency information for each field is extracted from the semantic information network graph, such as the number of times a field is queried, inserted, updated, or deleted in the code. Simultaneously, contextual features of the fields are extracted, including the entity to which the field belongs, the relationship between the field and other fields, and the field's position in the business process.

[0088] The access pattern prediction model employs a multi-task learning architecture, enabling it to handle multiple related prediction tasks simultaneously. After inputting field-level operation frequencies and contextual features, the access pattern prediction model predicts multiple future data access scenarios in parallel. These future data access scenarios can be different business scenarios, such as peak shopping periods or promotional activities, or different user behavior scenarios, such as new user registration or repeat purchases by existing users.

[0089] For each future data access scenario, the access pattern prediction model predicts the weights of individual fields and field combinations. Field weights indicate the importance of a field in that scenario; higher weights mean the field is more likely to be accessed frequently. Field combination weights indicate the likelihood of multiple fields being accessed together. For example, in a user information query scenario, the model might predict a high weight for the combination of "user name" and "user phone number," indicating that these two fields are frequently queried together in that scenario. By predicting field and field combination weights in parallel across multiple scenarios, the access pattern prediction model can comprehensively understand data access patterns in different scenarios.

[0090] Based on the previously obtained list of suggested foreign key relationships and the weights of each field and field combinations under future data access scenarios, a corresponding set of index recommendation strategies is generated according to the preset index strategy rule engine. The index strategy rule engine is a set of predefined rules that comprehensively consider factors such as foreign key relationships, field weights, and database performance optimization.

[0091] For example, for foreign key relationships between entities with high confidence in the foreign key relationship suggestion list, the rule engine will recommend creating foreign key indexes on the relevant fields to improve data consistency and query efficiency. For fields with high weight in future data access scenarios, the rule engine will recommend appropriate index types, such as B-tree indexes and hash indexes, based on the field type (e.g., primary key field, frequently queried field) and the characteristics of the database storage engine.

[0092] In addition, the rule engine also considers index combinations. If multiple fields are frequently accessed together in multiple scenarios and have high weights, the rule engine will recommend creating composite indexes on these fields to reduce the number of database queries and improve query performance. By comprehensively applying these rules, the rule engine can generate a comprehensive and reasonable set of index recommendation strategies, providing scientific guidance for database index design.

[0093] Based on a pre-built defect pattern library and a pre-trained graph neural network classification model, the semantic information network graph is scanned and analyzed to identify potential table structure design defects. The pre-built defect pattern library contains various common table structure design defect patterns, such as data redundancy patterns (e.g., a large number of duplicate fields in multiple tables), field type mismatch patterns (e.g., storing string type fields in numeric type columns), and lack of primary key patterns (the table does not have an explicit primary key field).

[0094] During the training phase, the pre-trained graph neural network classification model uses a large number of semantic information network graph samples containing both normal and defective table structures. Upon inputting the current semantic information network graph, the model extracts features from the table structure nodes. These features include the number of fields in the table, the distribution of field types, and the relationships between tables.

[0095] Next, the graph neural network classification model matches and compares the extracted features with patterns in the defect pattern library. Simultaneously, leveraging the classification capabilities of the graph neural network, it classifies and judges the table structures in the semantic information network graph to determine if they contain potential design flaws. If the graph neural network classification model determines that a table structure has a defect, it further determines the type and location of the defect and outputs a detailed defect report. For example, the graph neural network classification model might identify a data redundancy defect in a table, pointing out the names of redundant fields and other tables involved, providing developers with clear information to fix the table structure design flaws.

[0096] Furthermore, the step of inputting the semantic information network graph into the relational reasoning model trained based on a graph neural network, and inferring and outputting a list of proposed foreign key relationships between entities by performing graph structure learning and confidence calculation on the potential associations between entity nodes in the semantic information network graph, specifically includes: The semantic information network graph is input into a pre-trained relational graph attention neural network model. Information of different types of neighbor nodes is aggregated iteratively through multiple graph attention layers to generate a high-order embedding vector containing the global context semantics for each entity node in the semantic information network graph. For any two entity nodes in the semantic information network graph, the high-order embedding vectors of the two entity nodes are concatenated and combined, and then input into the relation scorer to calculate the binary classification confidence that there is a foreign key relationship between the two entity nodes in parallel, and predict the specific foreign key relationship type. For entity node pairs that are determined to have a foreign key relationship, a bidirectional semantic matching algorithm is used to calculate the similarity between the field nodes of the source entity and the target entity in order to determine the candidate associated field mapping. Based on the preset confidence threshold, high-confidence entity node pairs are selected, and a preliminary set of foreign key relationship suggestions is generated by combining the predicted foreign key relationship type with the candidate association field mapping. The system invokes a domain-knowledge-based rule engine to perform data type compatibility checks and logical conflict resolution on the initial set of foreign key relationship suggestions. After filtering and correction, it outputs the target list of foreign key relationship suggestions.

[0097] In this embodiment, the constructed semantic information network graph is input into a pre-trained relational graph attention neural network model. This model consists of multiple graph attention layers, and when processing the semantic information network graph, it performs operations on each entity node in the graph. For each entity node, the model considers its different types of neighboring nodes. For example, in the semantic information network graph of an e-commerce system, the "order" entity node may have different types of neighboring nodes such as "user," "product," and "payment."

[0098] Within each graph attention layer, the model iteratively aggregates information from different types of neighbor nodes. Specifically, the model assigns different attention weights to each neighbor node based on its importance to the current node. The criteria for determining importance can include the closeness of the business logic connection between the neighbor node and the current node, the frequency of connections in the graph, etc. In this way, the model can selectively aggregate neighbor node information, rather than simply averaging all neighbor node information.

[0099] After iterative processing through multiple graph attention layers, the model generates a high-order embedding vector for each entity node in the semantic information network graph, containing its global context semantics. This high-order embedding vector comprehensively reflects the features and positional information of the entity node in the entire semantic information network graph, providing a rich semantic foundation for subsequent foreign key relationship reasoning. For example, the high-order embedding vector of the "order" entity node may contain comprehensive semantic information related to entities such as users, products, and payments.

[0100] For any two entity nodes in the semantic information network graph, their higher-order embedding vectors are concatenated. The concatenated vector integrates the semantic information of the two entity nodes, thus better representing the potential relationship between them.

[0101] The concatenated vector is input into the relation scorer. The relation scorer is a trained module that can calculate the binary classification confidence score of whether there is a foreign key relationship between the two entity nodes in parallel. The binary classification confidence score is a value between 0 and 1; the closer the value is to 1, the greater the probability that there is a foreign key relationship between the two entity nodes.

[0102] Simultaneously, the relationship scorer also predicts the specific foreign key relationship type between the two entity nodes. For example, in a school management system, if the two entity nodes are "student" and "class", the relationship scorer might predict that the foreign key relationship between them is "student belongs to class". By parallel computing of binary classification confidence and predicting the foreign key relationship type, the relationship scorer can quickly and accurately make a preliminary judgment on the relationship between entity nodes.

[0103] For entity node pairs determined to have a foreign key relationship, a bidirectional semantic matching algorithm is used to calculate the similarity between the field nodes of the source and target entities. Taking the entity node pair "student" and "class" as an example, the "student" entity may have field nodes such as "student name", "student ID", and "class number", while the "class" entity may have field nodes such as "class name", "class number", and "class teacher's name".

[0104] Bidirectional semantic matching algorithms calculate similarity in two directions. First, starting from the field nodes of the source entity (e.g., "student"), they calculate the similarity between these field nodes and the field nodes of the target entity (e.g., "class"). Second, starting from the field nodes of the target entity, they calculate the similarity between these field nodes and the field nodes of the source entity. By comprehensively considering the similarity calculation results from both directions, candidate related field mappings are determined. For example, the "Class Number" field of the "Student" entity and the "Class Number" field of the "Class" entity might be identified as candidate related field mappings because they have a high degree of semantic similarity and relevance.

[0105] Based on a preset confidence threshold, the entity node pairs with foreign key relationships calculated earlier are filtered. Only entity node pairs with a binary classification confidence score higher than this threshold are retained. For example, if the preset confidence threshold is 0.8, then only entity node pairs with a binary classification confidence score greater than 0.8 will proceed to the next step.

[0106] By combining the predicted foreign key relationship types with the candidate association field mappings, a preliminary foreign key relationship suggestion set is generated. This set contains entity node pairs that may have foreign key relationships, the foreign key relationship types between them, and the corresponding candidate association field mapping information. For example, the preliminary foreign key relationship suggestion set may contain the entity node pair "student" and "class", with the foreign key relationship type being "student belongs to class", and the candidate association field mapping being "student.class number-class.class number".

[0107] The rule engine, based on domain knowledge, is invoked to perform data type compatibility checks and resolve logical conflicts on the initial set of foreign key relationship suggestions. Regarding data type compatibility checks, the rule engine examines whether the data types of candidate association fields match. For example, if the "Class Number" field of the "Student" entity is an integer type, while the "Class Number" field of the "Class" entity is a string type, then these two fields are incompatible in terms of data type and need to be corrected.

[0108] Regarding the resolution of logical conflicts, the rule engine checks for logical conflicts in the initial set of foreign key relationship suggestions based on domain knowledge. For example, in a library management system, if the initial set of foreign key relationship suggestions contains both foreign key relationships between "books" and "borrowers" and between "borrowers" and "books," this may constitute a logical conflict, which the rule engine will resolve.

[0109] After data type compatibility checks and logical conflict resolution, the rule engine filters and modifies the initial set of foreign key relationship suggestions, ultimately outputting a target list of foreign key relationship suggestions. This list of foreign key relationship suggestions is highly accurate and reasonable, providing valuable reference for database design.

[0110] Furthermore, the step of inputting the field-level operation frequencies and contextual features contained in the semantic information network graph into an access pattern prediction model trained based on multi-task learning, and predicting the weights of each field and field combinations in multiple future data access scenarios in parallel, specifically includes: Multi-level features of each field in the target data table are extracted from the semantic information network graph. The multi-level features include static attribute features of the field, dynamic operation frequency features based on code context, and co-occurrence relationship features between fields. The multi-level features of each field are input into a pre-trained multi-task deep learning model. General feature learning is performed through a shared low-level feature encoder. The independent weight values ​​of each field under multiple pre-set data access scenarios are output through multiple parallel task-specific prediction towers. The access scenarios include clause query conditions, sorting criteria, grouping criteria, operation connection keys, and operation modification.

[0111] In this embodiment, for the target data table in the semantic information network graph, multi-level feature extraction is performed for each field. For the static attribute features of a field, this covers some inherent attribute information of the field itself. For example, in a product data table of an e-commerce system, the static attribute features of the "product price" field may include its data type as numeric, its value range (e.g., 0 to 10000 yuan), and whether null values ​​are allowed; the static attribute features of the "product name" field may include its data type as string and its maximum length limit. These static attribute features can describe the characteristics of the field at a basic level.

[0112] Next, dynamic operation frequency features based on code context are extracted. By analyzing the code related to this data table in the system, the frequency of each field appearing in different operation scenarios is statistically analyzed. Taking an e-commerce system as an example, in the code for querying product information, the frequency of the "product price" field appearing in the price filter clause and the frequency of the "product name" field appearing in the fuzzy query clause are statistically analyzed. At the same time, the changes in these operation frequencies over different time periods are considered; for example, the operation frequency of the "product price" field may increase significantly during promotional activities.

[0113] Finally, we extract the co-occurrence characteristics of fields. We observe which fields frequently appear together in specific operational scenarios during code execution. For example, in the order query code of an e-commerce system, "order number" and "order date" might frequently appear together in the query conditions to locate orders within a specific time period; while "product number" and "product quantity" might appear together in order details queries. By analyzing these co-occurrence patterns, we can uncover the potential relationships between fields.

[0114] The extracted multi-level features of each field are input into a pre-trained multi-task deep learning model. This model has a unique structure, firstly learning general features from the input multi-level features through a shared low-level feature encoder. The shared low-level feature encoder acts as a general information processing center, capable of extracting common feature representations from the multi-level features of different fields. For example, whether it's the "product price" or "product name" field, the low-level feature encoder can extract general features such as their importance in the data table and their correlation with other fields.

[0115] After learning the general features, the model outputs independent weight values ​​for each field under multiple pre-defined data access scenarios in the future through multiple parallel task-specific prediction towers. These pre-defined data access scenarios include clause query conditions, sorting criteria, grouping criteria, operation join keys, and operation modifications. Taking the clause query condition scenario as an example, for the "product price" field, the task-specific prediction tower outputs a weight value based on the previously learned general features and the characteristics of this scenario. This weight value represents the likelihood that the "product price" field will be used as a clause query condition in the future. Similarly, for other fields and different data access scenarios, the task-specific prediction tower outputs corresponding independent weight values. For example, in the sorting criteria scenario, the "product price" field may receive a higher weight value due to its numerical characteristics, indicating that it is likely to be used as a sorting criterion; while in the grouping criteria scenario, the "product category" field may receive a higher weight value because it can reasonably classify products. In this way, the model can predict the weight of each field in different future data access scenarios in parallel, providing an important basis for subsequent data access pattern analysis and optimization.

[0116] Furthermore, based on the foreign key relationship suggestion list and the weights of each field and field combination under future data access scenarios, a corresponding index recommendation strategy set is generated according to the preset index strategy rule engine, specifically including: The list of foreign key relationship suggestions, the weights of each field and field combination under future data access scenarios, and the semantic information network graph are linked and integrated to construct an enhanced graph for indexing decisions. The enhanced graph is input into the preset indexing strategy rule engine, and foreign key indexing rules are applied. Based on the high-confidence relationships in the foreign key relationship suggestion list, preliminary index creation suggestions are generated for the corresponding foreign key fields. Based on the index strategy rule engine, single-field index rules are applied to traverse the field nodes in the enhanced graph. Based on whether the weight of each field exceeds the preset weight threshold, single-field index suggestions are generated for fields that meet the conditions. Based on the index strategy rule engine, the composite index synthesis rules are applied. According to the weight of the field combination, the high-frequency co-occurrence field combination is identified, and the order of the fields in the combination is determined by the heuristic sorting algorithm to generate composite index suggestions. The suggestions for initial index creation, single-field indexes, and composite indexes are integrated, and conflict detection and resolution are performed to generate a set of index recommendation strategies.

[0117] In this embodiment, the foreign key relationship suggestion list, the weights of each field and field combinations under future data access scenarios, and the semantic information network graph are correlated and integrated. The semantic information network graph originally contains information such as semantic relationships between fields in the data tables. The foreign key relationship suggestion list records the possible foreign key relationships between different data tables and the confidence levels of these relationships. The weights of each field and field combinations under future data access scenarios reflect the importance of the fields in different access scenarios. For example, in an e-commerce system, the semantic information network graph may include product tables, order tables, user tables, etc., and some basic semantic relationships between them, such as the order table being associated with the product table through product ID, and with the user table through user ID. The foreign key relationship suggestion list may further clarify the strength and reliability of these relationships, for example, the foreign key relationship formed by the user ID in the order table and the user ID in the user table has a high confidence level. Under future data access scenarios, it may be found that the "product price" field has a high weight in price filtering query scenarios, and the combination of "product name" and "product price" has a high weight in fuzzy query and sorting scenarios.

[0118] This information is then integrated into a semantic information network graph to construct an enhanced graph. This enhanced graph not only preserves the original semantic relationships but also adds confidence information about foreign key relationships and weight information about fields and field combinations. For example, the confidence level of the foreign key relationship is annotated on the association edge between the order table and the user table; the weight value of the "product price" field node in a price filtering query scenario is annotated; and the weight value of the combination edge of "product name" and "product price" in a fuzzy query and sorting scenario is annotated.

[0119] The constructed enhanced graph is input into the preset indexing strategy rule engine. The indexing strategy rule engine applies foreign key indexing rules, generating preliminary index creation suggestions for the corresponding foreign key fields based on high-confidence relationships in the foreign key relationship suggestion list. For example, in the enhanced graph of an e-commerce system, a high-confidence foreign key relationship is found between the user ID in the order table and the user ID in the user table. According to the foreign key indexing rules, to improve the efficiency of querying order information by user ID, the indexing strategy rule engine will generate a preliminary suggestion to create an index on the user ID field in the order table. This preliminary suggestion will explicitly indicate that an index should be created on the user ID field in the order table to speed up query operations based on user ID.

[0120] Continuing with the index strategy rule engine, single-field index rules are applied. The field nodes in the augmented graph are traversed, checking if the weight of each field exceeds a preset weight threshold. For fields that meet the criteria, single-field index suggestions are generated. Assuming the preset weight threshold is 0.7, in the augmented graph of the e-commerce system, the weight of the "product price" field in price filtering queries is found to be 0.8, exceeding the preset threshold. According to the single-field index rules, the index strategy rule engine will generate a single-field index suggestion for the "product price" field, i.e., create an index on the "product price" field in the product table to optimize the performance of price filtering queries. Similarly, if the weight of the "product inventory" field in inventory query scenarios also exceeds the threshold, a corresponding single-field index suggestion will also be generated for it.

[0121] Based on the index strategy rule engine, composite index synthesis rules are applied. High-frequency co-occurrence field combinations are identified according to their weights. For example, in the enhanced graph of an e-commerce system, the combination of "product name" and "product price" is found to have a high weight in fuzzy query and sorting scenarios, indicating it is a high-frequency co-occurrence field combination.

[0122] Then, a heuristic sorting algorithm is used to determine the order of the fields within the composite. This algorithm may consider factors such as field selectivity (i.e., the ratio of distinct values ​​to the total number of records) and query frequency. For example, "product name" might have high selectivity and is often used as the primary query condition in fuzzy queries, while "product price" is used for sorting. Therefore, the field order is determined to be "product name" first, followed by "product price". Finally, a composite index suggestion is generated, which involves creating a composite index on the product table with "product name" and "product price" in that order.

[0123] The suggestions for creating initial indexes, single-field indexes, and composite indexes are consolidated. During this consolidation process, conflicts may be found between some suggestions. For example, an initial index creation suggestion might create an index for a specific field, while a single-field index suggestion might also create an index for the same field, but with different index types or parameters.

[0124] Conflict detection and resolution are performed by analyzing factors such as the purpose and performance impact of the indexes to determine which suggestions to retain or to merge and adjust. For example, if both the initial index creation suggestion and the single-field index suggestion aim to improve query performance and have the same index type but slightly different index parameters, then the parameter with better performance optimization can be retained. After conflict detection and resolution, a final set of recommended index strategies is generated. This set contains all optimized and integrated index creation suggestions, providing comprehensive and reasonable guidance for creating database indexes.

[0125] Furthermore, the semantic information network graph is scanned and analyzed based on the pre-built defect pattern library and the pre-trained graph neural network classification model to identify potential table structure design defects, specifically including: A defect pattern library and a pre-trained graph neural network classification model corresponding to complex defect patterns are constructed. The defect pattern library includes a formalized set of detection rules for describing design defects of different table structures. The semantic information network graph is decomposed into multiple entity-centric local subgraphs. The static analysis engine is called to load the detection rules in the defect pattern library. Rule matching based on graph traversal and statistical calculation is performed on each local subgraph to capture explicit design defect instances that meet the rule conditions. Each local subgraph is input into a graph neural network classification model for inference. By encoding and classifying the structure of the local subgraph, instances of hidden design defects that conform to complex defect patterns are identified. By summarizing instances of explicit and implicit design flaws and performing cross-instance fusion and deduplication based on location and type, a unified set of potential table structure design flaws is generated.

[0126] In this embodiment, a defect pattern library is constructed. The construction of this library focuses on collecting and organizing various table structure design defects and transforming them into a formalized set of detection rules. For example, in database table structure design, there may be data redundancy defects, where multiple tables store the same or highly similar data. For this type of defect, formalized detection rules can be formulated, such as checking whether multiple tables contain the same combination of fields, and whether the data update logic of these field combinations is independent but there is duplicate storage. Another example is the missing foreign key constraint defect, which can be addressed by formulating rules to check for situations where there are relationships between tables but no foreign key constraints are set. These detection rules corresponding to various table structure design defects are summarized to form the defect pattern library.

[0127] To address complex defect patterns, a pre-trained graph neural network (Graph Neural Network) classification model is constructed. Taking performance issues caused by complex table structure relationships as an example, a large number of semantic information network (SIN) graph samples containing both such defects and normal table structures are collected. These samples are labeled to identify which samples exhibit complex defect patterns. Then, a suitable graph neural network architecture, such as a graph convolutional network (GCN), is selected, and the model is trained using the labeled samples. During training, the model parameters are adjusted so that the model can learn the feature representations of complex defect patterns in the SIN graph, thereby enabling it to classify SIN graphs containing complex defect patterns.

[0128] The semantic information network graph to be analyzed is decomposed into multiple entity-centric local subgraphs. For example, in the semantic information network graph of an e-commerce database, there are multiple entity tables such as the product table, order table, and user table, as well as the relationships between them. Centered on the product table entity, a local subgraph can be formed by the fields and tables directly related to the product table. This subgraph includes the basic information fields of the product table and the parts related to the order table, supplier table, etc., through foreign keys.

[0129] The static analysis engine loads detection rules from the defect pattern library and performs rule matching based on graph traversal and statistical calculations on each local subgraph. Taking the detection of data redundancy defects as an example, the static analysis engine traverses the fields and table structures in the local subgraph, counting the occurrence of the same field combinations in different tables. If multiple tables are found to have the same field combination, and the data update logic of these field combinations is independent but shows signs of duplicate storage, the local subgraph is determined to meet the rule conditions for data redundancy defects, and an explicit design defect instance is captured. Similarly, for foreign key constraint missing defects, the engine checks the relationships between tables in the local subgraph. If a relationship is found but no foreign key constraint is set, the corresponding explicit design defect instance is captured.

[0130] Each local subgraph is input into a pre-trained graph neural network classification model for inference. The graph neural network classification model first encodes the structure of the local subgraph, converting the nodes (representing fields in a table or the table itself) and edges (representing relationships between fields or between tables) in the subgraph into numerical vector representations that the model can process. For example, for nodes, factors such as their field type and whether they are primary keys can be considered when encoding; for edges, they can be encoded based on the type and strength of the relationship.

[0131] Then, the graph neural network classification model classifies the local subgraphs based on the encoded vector representations. Taking performance issues caused by complex table structure relationships as an example, the model analyzes factors such as the complexity of relationships between tables and data flow in the local subgraph to determine whether the local subgraph conforms to a complex defect pattern. If the model determines that it does, it identifies an instance of a latent design defect. For example, if a local subgraph contains multiple tables forming a complex network structure through multi-level relationships, and data queries require joint operations across multiple tables, performance issues may exist, and the model will identify it as an instance of a latent design defect.

[0132] This section summarizes explicit and implicit design flaw instances captured using the two methods described above. Since different detection methods may repeatedly detect the same flaw, or flaws may be detected in the same location in different subgraphs, cross-instance fusion and deduplication based on location and type are necessary. For example, for data redundancy flaws, data redundancy between the same tables may be detected in multiple subgraphs. By comparing the location (i.e., the tables and fields involved) and type of the flaws, these duplicate instances are merged. Simultaneously, flaws of different types but in close locations also require comprehensive analysis to ensure that no potential table structure design flaws are overlooked. After fusion and deduplication, a unified list of potential table structure design flaws is generated, providing an accurate basis for optimizing the database table structure.

[0133] In some embodiments, step S103 above, which involves automatically identifying sensitive fields and recommending encryption or de-identification schemes based on index recommendation strategies and potential table structure design flaws to obtain the first table structure, specifically includes: Based on index recommendation strategies and potential table structure design flaws, a multidimensional context for security analysis is constructed. Based on a pre-built sensitive field classifier, each field in the multi-dimensional context is processed. By comprehensively parsing the naming semantics of each field, the code annotation context, and the data flow path, each field is assigned a sensitivity level label and at least one sensitive type label. The sensitivity level label and sensitivity type label are input into the pre-configured security policy engine. Combined with the index recommendation policy and business constraints of the corresponding fields, the policy reasoning and conflict resolution are performed by matching the built-in declarative security rule library. For each field that needs to be protected, an encryption or de-identification scheme is decided to obtain data protection suggestions. Based on data protection recommendations, the index recommendation strategy was adjusted and synthesized for security adaptation to generate the first table structure.

[0134] In this embodiment, a multidimensional context is constructed by comprehensively considering index recommendation strategies and potential table structure design flaws. Regarding index recommendation strategies, the index usage of each table in the database is analyzed; for example, which fields are frequently used as query conditions, and which indexes have high or low query efficiency. For fields that are frequently used as query conditions and have low query efficiency, their index requirements are highlighted in the multidimensional context. Regarding potential table structure design flaws, previously detected flaws are reviewed, such as data redundancy and missing foreign key constraints. If a table has a data redundancy flaw, the structural characteristics of the table and the potential data security risks it may cause are recorded in the multidimensional context. Integrating the information from index recommendation strategies and potential table structure design flaws forms a multidimensional context containing information on table structure, index usage, and potential flaws, providing a comprehensive foundation for subsequent sensitive field identification.

[0135] Each field in a multi-dimensional context is processed based on a pre-built sensitive field classifier. Information about each field is comprehensively analyzed from multiple dimensions to accurately assign sensitivity level and sensitivity type labels. Regarding naming semantics, the field name is analyzed. For example, if the field name contains words clearly related to sensitive information such as "password," "ID number," or "bank card number," it is initially determined to be a sensitive field, and a corresponding sensitivity level is assigned based on the sensitivity of the words, such as assigning a high sensitivity level to the "password" field. Regarding code annotation context, comments for the field in the code are examined. If the comments explicitly indicate that the field stores sensitive data, its sensitivity attribute is further confirmed, and the sensitivity level may be adjusted based on the detailed explanations in the comments. Regarding data flow path, the flow of the field in database operations is tracked, such as whether the field will be transmitted to external systems or used to generate reports. If the field will be transmitted to untrusted external systems, its sensitivity level is increased, and a sensitivity type label such as "data transmission sensitive" is assigned. By comprehensively analyzing information from these three dimensions, each field is accurately assigned a sensitivity level label and at least one sensitivity type label.

[0136] The assigned sensitivity level and sensitivity type labels are input into the pre-configured security policy engine. The security policy engine combines the recommended indexing strategy for the corresponding field with business constraints to perform policy reasoning and conflict resolution. For example, for a field with a high sensitivity level and a "data transmission sensitive" type label, if the recommended indexing strategy is to create an index to improve query efficiency, but business constraints stipulate that the field must be encrypted during transmission, the security policy engine will match it with the built-in declarative security rule base. This rule base contains security handling rules for various situations, such as rules for encrypting highly sensitive data transmission and rules for de-identifying specific sensitive data types. The engine reasons based on these rules. If it finds that encryption processing will affect the efficiency of index usage, creating a conflict, it uses a conflict resolution mechanism, such as prioritizing business constraints and security requirements, to decide on an encryption scheme for the field, selecting an encryption algorithm that ensures data security while minimizing the impact on the index. Similar reasoning and decision-making are performed for other fields, ultimately determining an encryption or de-identification scheme for each protected field, obtaining data protection recommendations.

[0137] Based on the obtained data protection recommendations, the index recommendation strategy is adjusted and synthesized for security adaptability. For example, if the data protection recommendations use an encryption scheme for a certain field, and the encrypted data may require special processing during querying, the original index recommendation strategy may no longer be applicable. In this case, the index strategy for that field is adjusted according to the characteristics of the encryption scheme; for example, it may be necessary to reassess whether an index should still be created for that field, or what type of index should be created. The adjusted index recommendation strategy is then synthesized with the data protection recommendations to form a table structure scheme that comprehensively considers data security and query efficiency, namely the first table structure. This first table structure can effectively protect sensitive data while meeting the database's query performance requirements.

[0138] In some embodiments, step S104 above, which involves performing automated stress testing on the first table structure using a performance testing tool, obtaining test results, and then feeding back the index tuning strategy and partitioning scheme based on the test results, specifically includes: Based on the semantic information network graph associated with the first table structure, a performance test load scenario containing simulated business operation sequences and concurrency models is orchestrated and generated. Deploy the first table structure in an isolated test environment, perform automated stress tests according to the performance test load scenario, and collect panoramic performance indicators and query language execution details of the database in real time through integrated monitoring probes; The intelligent diagnostic engine is invoked to analyze the overall performance indicators and query language execution details, locate the specific queries and data tables that cause performance bottlenecks, and attribute the performance bottlenecks to specific defects in the table structure design by parsing the query execution plan. The attributed performance defects are input into the tuning decision engine, which generates targeted table structure optimization actions based on the pre-set tuning knowledge base rules. These table structure optimization actions include adjusting the indexing strategy or recommending a data partitioning scheme.

[0139] In this embodiment, the semantic information network graph associated with the first table structure uses each table in the first table structure as its core nodes, and the relationships between tables (such as foreign key relationships) as edges. Simultaneously, business semantic information related to the tables, such as the purpose of the table and the data types stored, is attached to the nodes as attributes. Based on this semantic information network graph, a performance test load scenario containing simulated business operation sequences and a concurrency model is orchestrated. For example, if the semantic information network graph shows that a certain table is used to store user order information and is associated with a user information table, the simulated business operation sequence can be designed to first query user information, then query its order information based on the user information, and simultaneously simulate the concurrency of multiple users performing such query operations at the same time. The concurrency model can be set according to the actual number of concurrent users during peak business periods, such as setting it to 100 users simultaneously initiating query requests. In this way, a performance test load scenario that can realistically reflect the actual operation of the business is generated.

[0140] Deploy the first table structure in an isolated test environment, ensuring that the test environment is as consistent as possible with the actual production environment in terms of hardware configuration and software version, to minimize the impact of environmental differences on test results. Execute automated stress tests using performance testing tools based on the orchestrated performance test load scenarios. During the test, integrate monitoring probes to collect real-time comprehensive performance metrics and query execution details of the database. Comprehensive performance metrics include database CPU utilization, memory usage, disk I / O rate, etc., which reflect the overall operating status of the database. Query execution details record information such as the execution time, execution plan, and size of the returned result set for each query statement, helping to gain a deeper understanding of the query execution. For example, the monitoring probes can collect CPU utilization data at regular intervals (e.g., 1 second) and record the detailed process of each query statement from start to finish.

[0141] The intelligent diagnostic engine analyzes the collected panoramic performance metrics and query execution details. First, the engine comprehensively evaluates the panoramic performance metrics. When a metric (such as persistently high CPU usage) exceeds the normal range, it is marked as a potential performance bottleneck. Then, combined with query execution details, it further pinpoints the specific query and data table causing the bottleneck. For example, if a query takes too long to execute, and the data table involved also shows abnormalities in the panoramic performance metrics (e.g., high disk I / O rate), then the query and its corresponding data table are identified as the performance bottleneck. Next, by analyzing the query execution plan, the performance bottleneck is attributed to specific flaws in the table structure design. For example, if the query execution plan shows that a query needs to scan a large number of data rows, it may be because the table lacks suitable indexes, leading to a full table scan and thus performance degradation.

[0142] The attributed performance defects are input into the tuning decision engine. The engine analyzes and processes these defects based on pre-defined tuning knowledge base rules. These rules include various common table structure performance defects and their corresponding optimization solutions. For example, for performance issues caused by missing indexes, the rules might suggest adding appropriate indexes to relevant fields based on query frequency and selectivity; for performance bottlenecks caused by uneven data distribution, the rules might recommend a data partitioning scheme, distributing data across different storage areas according to certain rules. Based on these rules, the tuning decision engine generates targeted table structure optimization actions. These actions include adjusting indexing strategies, such as adding, deleting, or modifying indexes, or recommending data partitioning schemes, such as choosing appropriate partitioning keys and partitioning methods. For example, if a field in a table is frequently used as a query condition and has low query efficiency, the engine might generate an optimization action to add a B-tree index to that field; if a table has a large amount of data and obvious business classification characteristics, it might generate an optimization action to perform range partitioning according to business classification.

[0143] Reference Figure 2 An embodiment of the present invention provides a database table structure automated generation and optimization system 2, wherein system 2 specifically includes: The code scanning module 201 is used to receive the user's backend project source code and extract semantic information network graphs related to data persistence through static code scanning. The semantic parsing module 202 is used to input the semantic information network graph into the intelligent parsing engine, call the pre-trained machine learning model to analyze the code logic relationship, infer the foreign key relationship between entities and predict the data access pattern, and obtain the index recommendation strategy and potential table structure design defects. Security policy module 203 is used to automatically identify sensitive fields and recommend encryption or de-identification schemes based on index recommendation strategies and potential table structure design defects, thereby obtaining the first table structure. Performance testing module 204 is used to perform automated stress testing on the structure of the first table using performance testing tools, obtain test results, and provide feedback on the indexing strategy and partitioning scheme based on the test results. The optimization deployment module 205 is used to optimize the structure of the first table according to the tuning index strategy and partitioning scheme to obtain the structure of the second table, adapt the structure of the second table to the target cloud database environment, and uniformly generate executable data definition language scripts, security policy configuration files and structure optimization suggestion reports.

[0144] It is understandable that, such as Figure 1 The content of the database table structure automated generation and optimization method embodiments shown are all applicable to the database table structure automated generation and optimization system embodiments. The specific functions implemented by the database table structure automated generation and optimization system embodiments are the same as those shown in the examples. Figure 1 The method for automatically generating and optimizing database table structures shown is the same as the embodiment described above, and the beneficial effects achieved are the same as those described above. Figure 1 The beneficial effects achieved by the illustrated method for automatically generating and optimizing database table structures are the same.

[0145] It should be noted that the information interaction and execution process between the above systems are based on the same concept as the method embodiments of the present invention. For details on their specific functions and technical effects, please refer to the method embodiments section, which will not be repeated here.

[0146] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0147] Reference Figure 3The present invention also provides a computer device 3, including: a memory 302 and a processor 301, and a computer program 303 stored on the memory 302. When the computer program 303 is executed on the processor 301, it implements the automated generation and optimization method of database table structure as described in any of the above methods.

[0148] The computer device 3 may be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device 3 may include, but is not limited to, a processor 301 and a memory 302. Those skilled in the art will understand that... Figure 3 The computer device 3 is merely an example and does not constitute a limitation on the computer device 3. It may include more or fewer components than shown in the figure, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0149] The processor 301 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0150] In some embodiments, the memory 302 may be an internal storage unit of the computer device 3, such as a hard disk or memory of the computer device 3. In other embodiments, the memory 302 may be an external storage device of the computer device 3, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 3. Furthermore, the memory 302 may include both internal and external storage units of the computer device 3. The memory 302 is used to store the operating system, applications, boot loader, data, and other programs, such as the program code of the computer program. The memory 302 can also be used to temporarily store data that has been output or will be output.

[0151] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the automated generation and optimization method for database table structures as described in any of the above methods.

[0152] In this embodiment, if the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographing device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0153] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0154] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0155] In the embodiments disclosed in this application, it should be understood that the disclosed devices / terminal equipment and methods can be implemented in other ways. For example, the device / terminal equipment embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling or direct coupling or communication connection may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0156] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

Claims

1. A method for automatically generating and optimizing database table structures, characterized in that, The method specifically includes: Receive the user's backend project source code and extract a semantic information network graph related to data persistence through static code scanning; The semantic information network graph is input into the intelligent parsing engine, and a pre-trained machine learning model is called to analyze the logical relationships in the code, infer the foreign key relationships between entities and predict data access patterns, and obtain index recommendation strategies and potential table structure design defects. Based on the index recommendation strategy and potential table structure design flaws, the security policy engine automatically identifies sensitive fields and recommends encryption or de-identification schemes to obtain the first table structure. The first table structure was automatically stress-tested using performance testing tools to obtain test results, and the index strategy and partitioning scheme were optimized based on the test results. The structure of the first table is optimized based on the index tuning strategy and partitioning scheme to obtain the structure of the second table. The structure of the second table is then adapted to the target cloud database environment, and an executable data definition language script, security policy configuration file, and structure optimization suggestion report are generated in a unified manner.

2. The method according to claim 1, characterized in that, The backend project source code that receives the user's data is extracted through static code scanning to obtain a semantic information network graph related to data persistence, specifically including: Receive the user's backend project source code, and distribute the backend project source code of different programming languages ​​to the corresponding multi-language syntax parser according to the project structure and file type; A multilingual syntax parser is used to perform lexical and syntactic analysis on the backend project source code to generate a unified abstract syntax tree. The nodes of the unified abstract syntax tree are input into a pre-trained code semantic understanding model. By analyzing identifier naming, code context and comment text, business semantic annotation and relationship inference are performed on the nodes, and structural information containing the business meaning of data entities and fields, potential relationships between entities and data operation intentions are identified. A semantic information network graph is constructed based on structural information and data operation intentions. The nodes of the semantic information network graph are used to represent entities, fields, application interface endpoints, and query fragments, and the edges of the semantic information network graph are used to represent the inclusion, calling, referencing, or mapping relationships between nodes.

3. The method according to claim 2, characterized in that, The process involves inputting the semantic information network graph into the intelligent parsing engine, calling a pre-trained machine learning model to analyze code logic relationships, inferring foreign key relationships between entities and predicting data access patterns, and obtaining index recommendation strategies and potential table structure design flaws. Specifically, this includes: The semantic information network graph is input into the relational reasoning model trained on the graph neural network. By learning the graph structure and calculating the confidence of the potential associations between entity nodes in the semantic information network graph, the model infers and outputs a list of foreign key relationships to be established between entities. The frequency of field-level operations and contextual features contained in the semantic information network graph are input into the access pattern prediction model based on multi-task learning and training, and the weights of each field and field combination under multiple future data access scenarios are predicted in parallel. Based on the foreign key relationship suggestion list and the weights of each field and field combination under future data access scenarios, a corresponding set of index recommendation strategies is generated according to the preset index strategy rule engine. Based on a pre-built defect pattern library and a pre-trained graph neural network classification model, the semantic information network graph is scanned and analyzed to identify potential table structure design defects.

4. The method according to claim 3, characterized in that, The process of inputting the semantic information network graph into a relational reasoning model trained on a graph neural network, and inferring and outputting a list of proposed foreign key relationships between entities by learning the graph structure and calculating confidence scores for the potential associations between entity nodes in the semantic information network graph, specifically includes: The semantic information network graph is input into a pre-trained relational graph attention neural network model. Information of different types of neighbor nodes is aggregated iteratively through multiple graph attention layers to generate a high-order embedding vector containing the global context semantics for each entity node in the semantic information network graph. For any two entity nodes in the semantic information network graph, the high-order embedding vectors of the two entity nodes are concatenated and combined, and then input into the relation scorer to calculate the binary classification confidence that there is a foreign key relationship between the two entity nodes in parallel, and predict the specific foreign key relationship type. For entity node pairs that are determined to have a foreign key relationship, a bidirectional semantic matching algorithm is used to calculate the similarity between the field nodes of the source entity and the target entity in order to determine the candidate associated field mapping. Based on the preset confidence threshold, high-confidence entity node pairs are selected, and a preliminary set of foreign key relationship suggestions is generated by combining the predicted foreign key relationship type with the candidate association field mapping. The system invokes a domain-knowledge-based rule engine to perform data type compatibility checks and logical conflict resolution on the initial set of foreign key relationship suggestions. After filtering and correction, it outputs the target list of foreign key relationship suggestions.

5. The method according to claim 3, characterized in that, The step of inputting the field-level operation frequency and contextual features contained in the semantic information network graph into an access pattern prediction model trained based on multi-task learning, and predicting the weights of each field and field combinations in multiple future data access scenarios in parallel, specifically includes: Multi-level features of each field in the target data table are extracted from the semantic information network graph. The multi-level features include static attribute features of the field, dynamic operation frequency features based on code context, and co-occurrence relationship features between fields. The multi-level features of each field are input into a pre-trained multi-task deep learning model. General feature learning is performed through a shared low-level feature encoder. The independent weight values ​​of each field under multiple pre-set data access scenarios are output through multiple parallel task-specific prediction towers. The access scenarios include clause query conditions, sorting criteria, grouping criteria, operation connection keys, and operation modification.

6. The method according to claim 3, characterized in that, The foreign key relationship suggestion list and the weights of each field and field combination under future data access scenarios are used to generate a corresponding index recommendation strategy set according to the preset index strategy rule engine, specifically including: The list of foreign key relationship suggestions, the weights of each field and field combination under future data access scenarios, and the semantic information network graph are linked and integrated to construct an enhanced graph for indexing decisions. The enhanced graph is input into the preset indexing strategy rule engine, and foreign key indexing rules are applied. Based on the high-confidence relationships in the foreign key relationship suggestion list, preliminary index creation suggestions are generated for the corresponding foreign key fields. Based on the index strategy rule engine, single-field index rules are applied to traverse the field nodes in the enhanced graph. Based on whether the weight of each field exceeds the preset weight threshold, single-field index suggestions are generated for fields that meet the conditions. Based on the index strategy rule engine, the composite index synthesis rules are applied. According to the weight of the field combination, the high-frequency co-occurrence field combination is identified, and the order of the fields in the combination is determined by the heuristic sorting algorithm to generate composite index suggestions. The suggestions for initial index creation, single-field indexes, and composite indexes are integrated, and conflict detection and resolution are performed to generate a set of index recommendation strategies.

7. The method according to claim 3, characterized in that, The pre-built defect pattern library and pre-trained graph neural network classification model scan and analyze the semantic information network graph to identify potential table structure design defects, specifically including: A defect pattern library and a pre-trained graph neural network classification model corresponding to complex defect patterns are constructed. The defect pattern library includes a formalized set of detection rules for describing design defects of different table structures. The semantic information network graph is decomposed into multiple entity-centric local subgraphs. The static analysis engine is called to load the detection rules in the defect pattern library. Rule matching based on graph traversal and statistical calculation is performed on each local subgraph to capture explicit design defect instances that meet the rule conditions. Each local subgraph is input into a graph neural network classification model for inference. By encoding and classifying the structure of the local subgraph, instances of hidden design defects that conform to complex defect patterns are identified. By summarizing instances of explicit and implicit design flaws and performing cross-instance fusion and deduplication based on location and type, a unified set of potential table structure design flaws is generated.

8. The method according to claim 1, characterized in that, Based on the index recommendation strategy and potential table structure design flaws, the security policy engine automatically identifies sensitive fields and recommends encryption or de-identification schemes to obtain the first table structure, which specifically includes: Based on index recommendation strategies and potential table structure design flaws, a multidimensional context for security analysis is constructed. Based on a pre-built sensitive field classifier, each field in the multi-dimensional context is processed. By comprehensively parsing the naming semantics of each field, the code annotation context, and the data flow path, each field is assigned a sensitivity level label and at least one sensitive type label. The sensitivity level label and sensitivity type label are input into the pre-configured security policy engine. Combined with the index recommendation policy and business constraints of the corresponding fields, the policy reasoning and conflict resolution are performed by matching the built-in declarative security rule library. For each field that needs to be protected, an encryption or de-identification scheme is decided to obtain data protection suggestions. Based on data protection recommendations, the index recommendation strategy was adjusted and synthesized for security adaptation to generate the first table structure.

9. The method according to claim 1, characterized in that, The process of performing automated stress testing on the first table structure using performance testing tools, obtaining test results, and then optimizing index strategies and partitioning schemes based on the test results specifically includes: Based on the semantic information network graph associated with the first table structure, a performance test load scenario containing simulated business operation sequences and concurrency models is orchestrated and generated. Deploy the first table structure in an isolated test environment, perform automated stress tests according to the performance test load scenario, and collect panoramic performance indicators and query language execution details of the database in real time through integrated monitoring probes; The intelligent diagnostic engine is invoked to analyze the overall performance indicators and query language execution details, locate the specific queries and data tables that cause performance bottlenecks, and attribute the performance bottlenecks to specific defects in the table structure design by parsing the query execution plan. The attributed performance defects are input into the tuning decision engine, which generates targeted table structure optimization actions based on the pre-set tuning knowledge base rules. These table structure optimization actions include adjusting the indexing strategy or recommending a data partitioning scheme.

10. A system for automatically generating and optimizing database table structures, characterized in that, The system specifically includes: The code scanning module is used to receive the user's backend project source code and extract semantic information network graphs related to data persistence through static code scanning. The semantic parsing module is used to input the semantic information network graph into the intelligent parsing engine, call the pre-trained machine learning model to analyze the logical relationships in the code, infer the foreign key relationships between entities and predict data access patterns, and obtain index recommendation strategies and potential table structure design defects. The security strategy module is used to automatically identify sensitive fields and recommend encryption or de-identification schemes based on index recommendation strategies and potential table structure design defects, thereby obtaining the first table structure. The performance testing module is used to perform automated stress testing on the first table structure using performance testing tools, obtain test results, and provide feedback on the test results to optimize index strategies and partitioning schemes. The optimization and deployment module is used to optimize the structure of the first table based on the tuning index strategy and partitioning scheme to obtain the structure of the second table, adapt the structure of the second table to the target cloud database environment, and uniformly generate executable data definition language scripts, security policy configuration files and structure optimization suggestion reports.

Images