A heterogeneous database logical association construction and privacy compliance code generation method for intelligent programming assistance

Abstract

This invention discloses a method for constructing logical associations and generating privacy-compliant code for heterogeneous databases in intelligent programming assistance. It introduces a custom metadata description file independent of the database's physical schema, defining cross-domain logical association attributes and data security attributes, including the target database identifier. The description file is parsed, comparing the associated target with the database identifier of the current context, and automatically selecting either an intra-database join strategy or an application-layer aggregation strategy based on the comparison result. An enhanced context hint containing architectural constraints and security rules is constructed, and the target code is generated by inputting a large language model. De-identification processing logic is automatically embedded based on the data security attributes. This invention effectively solves the problems of AI programming context breakage, cross-database association code generation errors, and data privacy compliance risks caused by missing physical foreign keys in microservice architectures, achieving automatic code generation and source-level data privacy protection for complex cross-service business logic.

Description

Technical Field

[0001] This invention relates to the fields of computer software engineering, artificial intelligence-assisted development, and data security technology, and in particular to a method for constructing logical associations of heterogeneous databases and generating privacy-compliant code for intelligent programming assistance. Background Technology

[0002] With the widespread application of intelligent programming aids based on large language models (such as code auto-completion plugins and conversational programming assistants) in software development, development efficiency has been significantly improved. Typically, these tools obtain data structure information by reading the database schema definition file (DDL) in the project and thereby understand the developer's programming context. However, in modern enterprise application development, especially under microservice and distributed database architectures, existing technical solutions face three core challenges: 1. The absence of physical foreign keys leads to logical breaks. To improve database performance and support database sharding and horizontal scaling, modern database design generally abandons physical foreign key constraints at the database level, instead delegating the maintenance of table relationships to application-layer code. This design paradigm means that DDL files no longer explicitly include references between tables. Intelligent programming assistants cannot recognize these implicit business relationships based solely on DDL, resulting in their inability to automatically generate correct join query code when faced with natural language commands involving multi-table queries. Developers are forced to manually write data join logic, severely weakening the effectiveness of intelligent programming assistance.

[0003] II. Lack of Microservice Architecture Awareness In a microservices architecture, business data is distributed across multiple independent physical databases based on domain boundaries, with each database belonging to a different microservice. Intelligent programming assistants, lacking awareness of system deployment topology and data source physical boundaries, cannot distinguish between "table joins within the same database" and "table joins across databases and services." In actual assisted programming, tools often incorrectly generate SQL JOIN statements attempting to execute across databases, when the correct approach should be to generate API call code for the target microservice and perform data aggregation at the application layer. This lack of architecture awareness means the generated code cannot run directly in a microservices environment.

[0004] III. Data Privacy Compliance Risks Database schema definition files only describe the data types of fields and cannot convey the security attributes of the data involved in those fields, such as whether it is sensitive personal information or what de-identification or encryption algorithms are used. Without such security metadata guidance, the code generated by intelligent programming assistants typically directly queries and returns plaintext data for sensitive fields, resulting in inherent privacy compliance flaws and failing to meet relevant legal and regulatory requirements. Relying entirely on developers for manual review afterward is not only inefficient but also carries the risk of oversight.

[0005] In summary, existing technologies have systemic defects in three dimensions: lack of physical foreign keys, architecture awareness, and data privacy. There is an urgent need for a technical solution that enables intelligent programming assistants to understand implicit logical relationships, perceive the boundaries of microservice architecture, and automatically implement privacy compliance processing during the code generation stage. Summary of the Invention

[0006] This invention proposes a method for constructing logical associations in heterogeneous databases and generating privacy-compliant code for intelligent programming assistance, in order to solve the problems of AI's inability to recognize implicit associations, lack of architectural awareness, and insufficient code privacy compliance in existing technologies.

[0007] To achieve the above objectives, the present invention adopts the following technical solution: a method for constructing logical associations of heterogeneous databases and generating privacy-compliant code for intelligent programming assistance, comprising the following steps: S1: Obtain the target system's custom metadata description file; Furthermore, the description file is independent of the database physical schema. In the description file, an extended attribute group is defined for each field that needs to be described in terms of association and security. This attribute group consists of a cross-domain logical association six-tuple J and a data security triple Sec.

[0008] The cross-domain logical association six-tuple J has the form: J=(D target ,S target ,T target C target ,R type M service ,f map ); where D target S is the identifier for the target database. target For the target service identifier, T target For the target table name, C target For the target field name, R type For association types (values ​​can be One To One, One To Many, or Many To One), M service f is the name of the service call method. map This represents the mapping relationship from the source field to the target field.

[0009] The data security triple Sec is in the form of: Sec=(isMask,algo M algo E Where isMask is a boolean value indicating whether the field is a sensitive field, algo M For desensitization algorithm type, algo E This refers to the encryption algorithm type.

[0010] Furthermore, this is determined by all fields that satisfy isMask=true and their corresponding algo. M The values ​​are used to form the desensitization rule set Rules Mask .

[0011] S2: Parse the description file, extract the database identifier of the associated target, compare it with the database identifier of the current context, and determine the code generation strategy based on the comparison result: when the identifiers match, select the database intra-join strategy; when the identifiers do not match, select the application layer aggregation strategy. S21: Parse the metadata description file constructed in S1 and extract the target database identifier D from each associated object J. target Define the database identifier of the current development context as D. context ; S22: Based on the identifier extracted in S21, execute the policy routing function Route. This function takes the associated object J as input and calculates D. target With D context Matching relationships: If D target With D context If they are consistent, then the function Route outputs strategy P. local (Database inner join strategy); If D target With D context If they are inconsistent, the Route function will output strategy P. remote (Application layer aggregation strategy).

[0012] S23: When the decision result of S22 activates strategy P remote At that time, the system, based on this strategy, forcibly defines the code generation task corresponding to the user instruction as an ordered sequence of operations, Seq, subject to the following constraint set Const. remote .

[0013] Among them, Const={Disable cross-database SQL JOIN, Force step-by-step data retrieval, Force memory association key merging}.

[0014] Seq remote =(Op (query_main) Op(extract_keys) Op (call_remote) Op (merge_in_memory) Each step in this sequence corresponds to a specific code generation subtask: Op (query_main) Generate data query logic for the main data source; Op (extract_keys) Apply a mapping function f to the master data query results. extract To extract the set of associated keys K, and apply the deduplication operation distinct(K) to K; Op (call_remote) With K as a parameter, M is defined according to the metadata. service Generate the logic for calling remote services; Op (merge_in_memory) Define the merging function f merge This generates logic that merges the data returned by the remote call into the main data in memory according to the association key.

[0015] S3: Receives natural language programming instructions from users, retrieves logical association paths from the parsed metadata based on entity keywords in the instructions, and constructs enhanced context hints that include cross-service call relationships or table join relationships; S31: Receives natural language programming instructions Q input by the user, extracts a set of entity keywords E from Q through named entity recognition, and retrieves all logical association paths that match E from the metadata parsed by S1 to form a set of association paths related to the current task.

[0016] S32: Set the database identifier D containing the current service name and current development context. context S31 The set of associated paths retrieved; S22 The code generation strategy determined (P) local or P remote ) and its corresponding constraint set Const and desensitization rule set Rules Mask The parameters are filled into the preset structured prompt template T to generate a complete architectural constraint description.

[0017] S33: Concatenate the architectural constraint description generated in S32 with the user's original instruction Q to construct the enhanced context hint C. enhanced It serves as the direct input to the large language model.

[0018] S4: Input the enhanced contextual hints into the large language model to generate target code, and automatically implant desensitization processing logic into the sensitive fields involved according to the data security attributes.

[0019] S41: Enhanced context hints C built from S3 enhancedInput a large language model (LLM) to obtain initial generated code. init .

[0020] S42: Compliance audit module for Code init The scan is performed, and based on the security triple Sec defined in S1, the de-identification function f is automatically applied to all fields where isMask=true. mask Perform logical wrapping to generate de-identified code. masked The desensitization function f mentioned above... mask The prototype is v masked =f mask (v plain algo M ), where v plain v is the original value. masked Algo is the desensitization value. M This refers to the desensitization algorithm type.

[0021] S43: If the security triple Sec of the field contains algo E If ≠ NULL, then encryption and decryption logic will be automatically injected based on S42: Define the encryption function f enc The prototype is v encrypted =f enc (v plain algo E Define the decryption function f. dec The prototype is v plain =f dec (v) encrypted algo E For data write operations, replace the parameter values ​​with the encrypted call f. enc (v plain algo E For data read operations, first apply the decryption call f to the result. dec Then apply the desensitization call f mask , constitute a combined processing f mask (f dec (v encrypted algo E ), algo M For log printing operations, inject judgment logic to replace sensitive values ​​with the safe placeholder "***".

[0022] S5: When the user command Q retrieves the set of associated paths Paths in S31, which contains multiple associated objects J, and after the policy routing function Route in S22 determines each one, and there is an output P, local With P remote When the path is specified, the system initiates mixed association processing.

[0023] S51: Construct the data association graph G for the current task based on Paths, where nodes are data table entities and edges are the association six-tuples J defined in S1. Traverse all edges in G to satisfy Route(J,D) context )=P remote Edges are labeled as cross-library edges, and the remaining edges are labeled as same-library edges. Based on the labeling results, G is divided into two disjoint subgraphs: the cross-library subgraph Gi. remote (Including only cross-library edges and their associated nodes) and the same-library subgraph G local (Only includes edges within the same database and their associated nodes).

[0024] S52: For subgraphs G in the same library local The system reuses the S22 strategy P local This generates a database inner join subtask, which contains the logic for performing JOIN queries on related data tables at the SQL level; and it also generates a cross-database subgraph G. remote System reuse strategy P remote and the constraint set Const and the ordered sequence of operations Seq defined therein. remote This generates an application-layer aggregation subtask, which sequentially includes Op... (query_main) Op (extract_keys) Op (call_remote) and Op (merge_in_memory) Each step of the logic. Based on this, the system adds a final cascaded union subtask, defining a global merge function f. (merge_global) , will G local The result set R output by the subtask local With G remote The result set R output by the subtask remote Perform a memory-level join and merge based on the primary association key to form the complete output result set R. final =f (merge_global) (R local ,R remote ).

[0025] Compared with the prior art, the beneficial effects of the present invention are as follows: By introducing logical association metadata containing database name / service name, the problem of AI being unable to recognize implicit associations due to missing physical foreign keys is solved, enabling AI to automatically generate correct multi-table association code; By using a policy-based routing mechanism, the problem of AI's lack of architecture awareness is solved, ensuring that API calls and memory aggregation code that conform to specifications are generated in a microservice architecture, rather than erroneous cross-database SQL. By designing a desensitization mechanism, data privacy protection is brought forward to the code generation stage, solving the problem of AI-generated code violating data security regulations and preventing the leakage of sensitive data from the source. Attached Figure Description

[0026] Figure 1 This is a flowchart of Embodiment 1 of the present invention. Detailed Implementation

[0027] To provide a further understanding of the purpose, structure, features, and functions of the present invention, detailed descriptions are provided below with reference to specific embodiments.

[0028] Example 1: A method for constructing logical associations in heterogeneous databases and generating privacy-compliant code for intelligent programming assistance, comprising the following sub-steps: S1: Obtain the target system's custom metadata description file; In this embodiment, the developer creates and maintains a custom metadata description file in the target system project. This file is independent of the database physical schema, stored in a structured format (such as XML, JSON, or YAML), and supports a hot-reload mechanism, allowing it to be updated in real time without restarting the integrated development environment.

[0029] In the description file, for each table field that needs to be described as having a logical relationship, a cross-domain logical relationship six-tuple J is defined, which is formally defined as: J=(D target ,S target ,T target C target ,R type M service ,f map ), where D target S is the identifier for the target database. target For the target service identifier, T target For the target table name, C target For the target field name, R type For association types (values ​​can be One To One, One To Many, or Many To One), M service f is the name of the service call method. map This represents the mapping relationship from the source field to the target field.

[0030] Using the department code field (dept) from the employees table code For example, its association logic is formalized as a specific six-tuple instance: J dept =("hr db ","Hr Service","dept dict ","code",Many To One,"getDepartments By Codes",{dept code→code}); The specific values ​​for each parameter are as follows: D target =hr db ": Target database identifier, indicating where the associated data is located in hr db This heterogeneous database; S target =="Hr Service": Target service identifier, specifying the name of the microservice that provides departmental data; T target =dept dict ": The name of the target table, i.e., the target data table to which it is associated; C target =="code": The name of the target field, i.e., dept dict The fields in the table used for association matching; R type =Many To One: Association type, with a value of many to one, indicating that multiple employee records may correspond to the same department; M service =="get Departments By Codes": Service call method name, indicating the specific remote interface to be called during application-layer aggregation; f map ={dept code →code}: The mapping relationship from the source field to the target field, which maps the current table's field dept. code The value is mapped to the target table field code.

[0031] For sensitive fields, define a data security triple Sec, which is formally defined as follows: Sec=(isMask,algo M algo E Taking the phone number field "phone" as an example, its security attribute is formalized as a specific triple instance: Sec phone = (true, phone) mask (AES256) The specific values ​​for each parameter are as follows: isMask=true: A boolean value that indicates the field is sensitive and requires de-identification processing.

[0032] algo M =phone mask : De-identification algorithm type, specifying the mobile phone number masking rules (e.g., retaining the first 3 and last 4 digits, and masking the middle digits).

[0033] algo E=AES256: Encryption algorithm type, specifies that the AES256 algorithm is used for encrypted storage.

[0034] Furthermore, this is determined by all fields that satisfy isMask=true and their corresponding algo. M The values ​​are used to form the desensitization rule set Rules Mask .

[0035] S1 formalizes cross-domain logical associations and data security attributes as six-tuples J and three-tuples Sec, respectively, and explicitly configures the specific values ​​of these parameters in the early stages of development. This provides AI programming assistants with precisely parsable structured knowledge, fundamentally solving the problems of logical breaks caused by missing physical foreign keys and the inability of DDL to carry security attributes.

[0036] S2: Parse the description file, extract the database identifier of the associated target, compare it with the database identifier of the current context, and determine the code generation strategy based on the comparison result: when the identifiers match, select the database intra-join strategy; when the identifiers do not match, select the application layer aggregation strategy. S21: Parse the metadata description file constructed in S1 and extract the target database identifier D from each associated object J. target Define the database identifier of the current development context as D. context ; The system parses and traverses the metadata description file constructed in S1, and extracts its D for each defined six-tuple J instance. target The value of the parameter. (Using J) dept For example, the system extracts D target =hr db Simultaneously, the system reads the database connection information configured in the current integrated development environment and defines the database identifier of the current project development context as D. context In the user service module development scenario of this embodiment, D context ="obwechat".

[0037] S22: Based on the identifier extracted in S21, execute the policy routing function Route. This function takes the associated object J as input and calculates D. target With D context Matching relationships: If D target With D context If they are consistent, then the function Route outputs strategy P. local (Database inner join strategy); If D target With D context If they are inconsistent, the Route function will output strategy P. remote(Application layer aggregation strategy).

[0038] The system takes each associated object J extracted in S21 as input and feeds it one by one into the policy routing function Route for decision-making. The decision-making logic of this function is: calculate D in J. target The value of the parameter and D context The equivalence relation of values. Taking J as an example. dept For example, the system executes the judgment: D target =hr db ",D context =="obwechat", the two are inconsistent, therefore Route(J dept The output of ) is policy P remote (Application layer aggregation strategy). If there is another related J salary , its D target =obwechat", with D context If they are consistent, then Route(J) salary Output strategy P local (Database inner join strategy).

[0039] S23: When the decision result of S22 activates strategy P remote At that time, the system, based on this strategy, forcibly defines the code generation task corresponding to the user instruction as an ordered sequence of operations, Seq, subject to the following constraint set Const. remote .

[0040] Among them, Const={Disable cross-database SQL JOIN, Force step-by-step data retrieval, Force memory association key merging}.

[0041] Seq remote =(Op (query_main) Op (extract_keys) Op (call_remote) Op (merge_in_memory) Each step in this sequence corresponds to a specific code generation subtask: Op (query_main) Generate data query logic for the main data source; Op (extract_keys) Apply a mapping function f to the master data query results. extract To extract the set of associated keys K, and apply the deduplication operation distinct(K) to K; Op (call_remote) With K as a parameter, M is defined according to the metadata. service Generate the logic for calling remote services; Op (merge_in_memory) Define the merging function f mergeThis generates logic that merges the data returned by the remote call into the main data in memory according to the association key.

[0042] When the decision result of S22 activates strategy P remote Then, the system performs the following mandatory definition operations. First, it generates a constraint set Const, which contains three inviolable rules: prohibiting the generation of cross-database SQL JOIN statements, forcing the use of a step-by-step data retrieval mode, and forcing the merging of join keys to be completed in application memory. Subsequently, the system normalizes this code generation task into a strictly ordered sequence of operations, Seq. remote The sequence consists of four subtasks in sequence: First subtask Op (query_main) Its responsibility is to generate query logic for the main data source. Taking Jdept as an example, this subtask generates query statements for the employees table.

[0043] Second subtask Op (extract_keys) Its responsibility is to generate the logic for extracting and deduplicating related keys. This subtask will apply a mapping function f to the query results of the first subtask. extract This function is based on J dept f defined in map ={dept code →code}, extract dept from the result set code The values ​​of the fields form the association key set K. Then, logic is generated to apply the distinct(K) operation to set K.

[0044] Third sub-task Op (call_remote) Its responsibility is to generate remote service call logic. This subtask takes the deduplicated set of association keys K as input parameter, and according to J... dept S as defined in target =="Hr Service" and M service =="getDepartments By Codes", generates the logic for calling the getDepartments By Codes(K) interface of the remote service Hr Service.

[0045] Fourth subtask Op (merge_in_memory) Its responsibility is to generate the memory merging logic. This subtask defines the merge function f. merge This is a complete in-memory aggregation logic that generates a result set of the master data, searches for matching records in the data returned by the remote call based on the association key, and assigns the matched field values ​​(such as department names) back to the master data records.

[0046] Step S2 involves parsing D in J. target Parameters and D contextThrough precise comparison, the system possesses the architecture awareness capability to distinguish between intra-database and cross-database scenarios. When a cross-database association is determined, it activates P... remote Strategies and Const and Seq remote By mandating the definition of code generation tasks and solidifying the microservice architecture specification into an insurmountable code generation template for AI, the generation of cross-database SQL JOINs that cannot be executed is fundamentally eliminated.

[0047] S3: Receives natural language programming instructions from users, retrieves logical association paths from the parsed metadata based on entity keywords in the instructions, and constructs enhanced context hints that include cross-service call relationships or table join relationships; S31: Receives natural language programming instructions Q input by the user, extracts a set of entity keywords E from Q through named entity recognition, and retrieves all logical association paths that match E from the metadata parsed by S1 to form a set of association paths related to the current task.

[0048] The system first receives a natural language programming instruction Q input by the user in the integrated development environment, such as: "Get all employee information and populate their department names." The system executes a named entity recognition algorithm on Q to extract a set of keywords E representing data entities. From this instruction, E = {"employees", "department"} can be extracted. Subsequently, the system searches the metadata index parsed in step S1 to find all six-tuple instances J related to entities in set E. In this example, the system matches the association defined on the employee table (employees) with the department table (dept). dict J dept All matched associated objects J together constitute the set of associated paths related to the current task.

[0049] S32: Set the database identifier D containing the current service name and current development context. context S31 The set of associated paths retrieved; S22 The code generation strategy determined (P) local or P remote ) and its corresponding constraint set Const and desensitization rule set Rules Mask The parameters are filled into the preset structured prompt template T to generate a complete architectural constraint description.

[0050] The system invokes a pre-designed structured prompt template T. This template contains multiple parameter slots to be filled. The system performs the following parameter filling operations: fills the service name slot with the current microservice name ("User Service"); fills the service name slot with the current database identifier D defined in S21. context("obwechat") is filled into the database identifier slot; the associated path set Paths obtained from S31 (containing J) is used to fill in the database identifier slot. dept Fill in the associated topology slot with the complete information; fill in the code generation strategy (P) determined in S22. remote The policy constraint slot is filled with the constraint set Const and its corresponding constraint set Const; the de-identification rule set Rules, selected based on isMask=true in the Sec triplet of S1, is then used. Mask Fill in the security rule slots. After all parameters are filled in, template T generates a complete and unambiguous description of the architecture constraints containing all the above information.

[0051] S33: Concatenate the architectural constraint description generated in S32 with the user's original instruction Q to construct the enhanced context hint C. enhanced It serves as the direct input to the large language model.

[0052] The system performs a string concatenation operation, placing the architecture constraint description text generated by S32 at the beginning and the user's original natural language programming instruction Q at the end. The two are combined to form the enhanced context prompt C. enhanced The C enhanced It fully includes the user's development intent, the data relationship topology required to achieve that intent, the architectural strategies and constraints that must be followed, and the data security rules that must be met. The system will then... enhanced It serves as the sole direct input to the Large Language Model (LLM), replacing the simple input method in traditional schemes that only contain the user's raw commands.

[0053] This step enables automatic retrieval of associated paths through named entity recognition, and transforms static metadata and dynamic strategies scattered in S1 and S2 into contextual instructions that the large language model can accurately understand and strictly follow by using parameterized filling of structured prompt templates. This ensures the correctness of the generated code in both architectural and compliance dimensions from the input level.

[0054] S4: Input the enhanced contextual hints into the large language model to generate target code, and automatically implant desensitization processing logic into the sensitive fields involved according to the data security attributes.

[0055] S41: Enhanced context hints C built from S3 enhanced Input a large language model (LLM) to obtain initial generated code. init .

[0056] The system will complete the enhanced context hint C built by S33. enhanced The large language model (LLM) is submitted to the backend via API calls. The model is in C... enhanced P contained in remoteStrategy and Seq remote Guided by an ordered sequence of operations, the code logic is arranged and generated, producing an initial code that strictly follows a four-step pattern: "querying master data—extracting association keys—calling remote services—merging in memory". init .

[0057] S42: Compliance audit module for Code init The scan is performed, and based on the security triple Sec defined in S1, the de-identification function f is automatically applied to all fields where isMask=true. mask Perform logical wrapping to generate de-identified code. masked The desensitization function f mentioned above... mask The prototype is v masked =f mask (v plain algo M ), where v plain v is the original value. masked Algo is the desensitization value. M This refers to the desensitization algorithm type.

[0058] The compliance audit module starts the initial generated code. init Static scanning. The module locates the Code based on the security triplet Sec instance defined in step S1. init All field access points marked as isMask=true in the metadata. (In Sec) phone For example, its isMask=true. The module automatically searches for and matches algo. M =phone MASK Matching desensitization function f mask And in Code init In the abstract syntax tree, a call node for the function is created, logically encapsulating all calls that read the original value v of the field. plain The positions. After this step, the value retrieval logic for these positions is replaced by v. masked =f mask (v plain phone MASK This ensures that any reading and use of the phone field yields a de-identified value (v) processed according to phone number masking rules. masked This step generates the anonymized code. masked .

[0059] S43: If algoE ≠ NULL in the security triple Sec of a field, then further automatic encryption and decryption logic is injected based on S42: Define the encryption function f enc The prototype is v encrypted=f enc (v plain algo E Define the decryption function f. dec The prototype is v plain =f dec (v) encrypted algo E For data write operations, replace the parameter values ​​with the encrypted call f. enc (v plain algo E For data read operations, first apply the decryption call f to the result. dec Then apply the desensitization call f mask , constitute a combined processing f mask (f dec (v encrypted algo E ), algo M For log printing operations, inject judgment logic to replace sensitive values ​​with the safe placeholder "***".

[0060] For the security triple Sec in algo E For fields where the parameter value is not NULL, the system generates the code in S42. masked This involves a deeper rewriting of security logic. Still based on Sec... phone For example, its algo E =AES256. The system performs the following three automatic injection operations: For data write operations (such as INSERT and UPDATE statements), the system changes the corresponding parameter value from the original value v. plain Replace with encrypted function call expression f enc (v plain (AES256), ensuring that the value stored in the database is in encrypted form.

[0061] For data read operations (such as SELECT statements), the system replaces the corresponding output processing logic with a composite function call expression f. mask (f dec (v encrypted (AES256), PHONE MASK ), where the internal f dec The function first processes the ciphertext v read from the database. encrypted Performing AES256 decryption yields the plaintext v. plain ; external f mask The function then performs phone number masking on the plaintext to obtain the final compliant value used for display.

[0062] For log printing operations (such as log output statements), the system injects a conditional decision logic node, which forces the values ​​of sensitive fields to be uniformly replaced with the safe placeholder "***" before the execution path of the log output statement, thereby preventing sensitive data from entering the log system.

[0063] This step moves data security protection measures from the runtime or manual review stage to the design stage of code generation. It automatically matches and inserts the de-identification function f based on the specific values ​​of each parameter in the Sec triplet. mask and encryption function f enc This ensures that the generated code automatically meets compliance requirements throughout the entire data writing, reading, display, and logging process, achieving source governance.

[0064] S5: When the user command Q retrieves the set of associated paths Paths in S31, which contains multiple associated objects J, and after the policy routing function Route in S22 determines each one, and there is an output P, local With P remote When the path is specified, the system initiates mixed association processing.

[0065] S51: Construct the data association graph G for the current task based on Paths, where nodes are data table entities and edges are the association six-tuples J defined in S1. Traverse all edges in G to satisfy Route(J,D) context )=P remote Edges are labeled as cross-library edges, and the remaining edges are labeled as same-library edges. Based on the labeling results, G is divided into two disjoint subgraphs: the cross-library subgraph Gi. remote (Including only cross-library edges and their associated nodes) and the same-library subgraph G local (Only includes edges within the same database and their associated nodes).

[0066] When the set of associated paths obtained in step S31 contains multiple associated objects J, and after the policy routing function Route in step S22 determines each one, the result shows that P also exists. local and P remote This step is activated at this time. The system first constructs an undirected data association graph G=(V,E) using all data table entities involved in Paths as nodes V and the association six-tuples J defined in S1 as edges E. Then, the system traverses each edge in graph G (i.e., each J) and calls the Route function in S22 to determine whether the edge satisfies Route(J,D). context )=P remote The edges in the condition are marked as "cross-database edges", and the rest satisfy Route(J,D) context )=P localThe edges are labeled as "same-database edges". Based on the edge labeling attributes, the system performs a graph partitioning operation, dividing the original graph G into two disjoint subgraphs: one is a cross-database subgraph G. remote One contains only J, marked as "cross-library edge," and the data table nodes connected by these edges; the other is a subgraph G within the same library. local It contains only J marked as "same library edge" and the nodes it is connected to.

[0067] S52: For subgraphs G in the same library local The system reuses the S22 strategy P local This generates a database inner join subtask, which contains the logic for performing JOIN queries on related tables at the SQL level. For the cross-database subgraph G... remote System reuse strategy P remote and the constraint set Const and the ordered sequence of operations Seq defined therein. remote This generates an application-layer aggregation subtask, which sequentially includes Op... (query_main) Op (extract_keys) Op (call_remote) and Op (merge_in_memory) Each step of the logic. Based on this, the system adds a final cascaded union subtask, defining a global merge function f. (merge_global) , will G local The result set R output by the subtask local With G remote The result set R output by the subtask remote Perform a memory-level join and merge based on the primary association key to form the complete output result set R. final =f (merge_global) (R local ,R remote ).

[0068] The system performs differentiated code generation operations on the two subgraphs obtained from the S51 partition: for subgraphs G in the same library... local The system reuses strategy P defined in step S22. local .

[0069] The system generates a database inner join subtask based on the data table entities and relationships involved in the subgraph. The core logic of this subtask is to perform inner join queries on the relevant data tables using the JOIN keyword at the SQL level.

[0070] For cross-library subgraph G remote The system reuses strategy P defined in step S22. remote The policy also includes the constraint set Const and the ordered sequence of operations Seq. remote .

[0071] The system is based on M of J in this subgraph.service and f map Parameters such as these are used to generate a complete application-layer aggregation subtask, whose logic strictly includes Op in sequence. (query_main) Op (extract_keys) Op (call_remote) and Op (merge_in_memory) Four steps.

[0072] After the above two subtasks are generated, the system adds a final cascaded subtask.

[0073] This subtask defines a global merging function f. (merge_global) This function receives G. local The same database query result set R output after the subtask is executed local and G remote The cross-database aggregation result set R output after the subtask is executed remote As input.

[0074] f (merge_global) The function performs a memory-level union operation based on the association keys (such as employee IDs or department codes) of the main entities in the two result sets. Ultimately, the function outputs a complete result set R that integrates all associated data and contains all the fields the user needs. final .

[0075] This solution addresses the problem that existing AI programming tools fail to generate correct code in scenarios involving both intra-database and cross-database interactions. By constructing an association graph and performing graph segmentation based on the Route function's decision, the system can automatically identify the boundaries of different data sources in complex requirements and apply optimal P values ​​to both intra-database and cross-database components. local and P remote The strategy, ultimately through f (merge_global) By performing cascading and merging, we ensured that the final generated code was architecturally correct and data-complete.

[0076] Example 2: This example is applied to an enterprise employee management system under a typical microservice architecture. The developers pre-configured the metadata description file according to step S1, which defines two related six-tuples: Same-database association J salary =("obwechat","User Service","salary","employeesid",OneTo One,"",{id→employeesid}), its D target Parameters and the current development context D context It is consistent with ="obwechat".

[0077] Cross-database association J dept=("hr db ","Hr Service","dept dict ","code",Many To One,"getDepartments By Codes",{dept code →code}), its D target =hr db ", with D context Inconsistent.

[0078] In the integrated development environment, the user enters the natural language command Q: "Query the names, salaries, and department names of all employees." The system executes S31, extracts the entity set E={"employees","salary","department"} from Q, and retrieves Paths={J} from the metadata. salary J dept The system executes the S22 policy routing: Route(J salary )=P local Route(J) dept )=P remote Because the judgment result contains both strategies, the system triggers S5 hybrid association processing. In S5, the system constructs and partitions the association graph G. For G... local (including J) salary Generate an SQL JOIN subtask for G. remote (including J) dept Generate based on M service The API call subtask of "getDepartments By Codes" ultimately passes through f (merge_global) Complete the level union and output a complete result set in R that includes name, salary, and department name. final .

[0079] Result: The system generated composite code that integrates intra-database SQL joins and cross-database API calls in one go, automatically completing the architecture determination and logic assembly throughout the process, without requiring developers to ask questions step by step or manually combine them.

[0080] Example 3: Based on the above system configuration, the metadata also defines the security triple Sec for the mobile phone number field. phone =(true, phone MASK (AES256). The user inputs command Q: "Add an employee and enter their mobile phone number, then export all employee mobile phone numbers." After the system executes S3 and S41 to generate the initial code, the compliance audit module in step S4 is started. S42 uses isMask=true and algo... M =phone MASK Inject f into the exported code maskPackage logic. S43 according to algo E =AES256, replace the phone number parameter with f in the newly added code. enc Encrypted calls; the display logic in the exported code will be modified to a composite function f. mask (f dec (...),phone MASK Inject masking logic into the log printing code to replace the real value with "***".

[0081] Result: The automatically generated code has full lifecycle privacy protection capabilities. Data exists in encrypted form when stored, is immediately desensitized after decryption when displayed in the application, and is completely masked when logging, without the need for manual security review throughout the process.

[0082] The present invention has been described in the above-described embodiments; however, these embodiments are merely examples for implementing the present invention. It must be noted that the disclosed embodiments do not limit the scope of the present invention. Conversely, any modifications and refinements made without departing from the spirit and scope of the present invention are within the scope of patent protection of the present invention.

Claims

1. A method for constructing logical associations in heterogeneous databases and generating privacy-compliant code for intelligent programming assistance, characterized in that, include: S1: Obtain the target system's custom metadata description file; S2: Parse the description file, extract the database identifier of the associated target, compare it with the database identifier of the current context, and determine the code generation strategy based on the comparison result: when the identifiers match, select the database intra-join strategy; when the identifiers do not match, select the application layer aggregation strategy. S3: Receives natural language programming instructions from users, retrieves logical association paths from the parsed metadata based on entity keywords in the instructions, and constructs enhanced context hints that include cross-service call relationships or table join relationships; S4: Input the enhanced contextual hints into the large language model to generate target code, and automatically implant desensitization processing logic into the sensitive fields involved according to the data security attributes.

2. The method for constructing logical associations of heterogeneous databases and generating privacy-compliant code for intelligent programming assistance as described in claim 1, characterized in that, When selecting the application layer aggregation strategy in step S2, the system prohibits the generation of cross-database SQLJOIN statements and controls the large language model to generate code logic for step-by-step execution and memory aggregation. The code logic includes, in sequence: querying the main table data, extracting the set of related keys and deduplicating them, calling the remote service interface with the deduplicated set as parameters according to the service call method defined by the metadata, and merging the data returned by the remote call into the main data in the application memory based on the related keys.

3. The method for constructing logical associations of heterogeneous databases and generating privacy-compliant code for intelligent programming assistance as described in claim 2, characterized in that, Step S2 specifically includes: Parse the metadata description file and extract the target database identifier D from each associated object. target And define the database identifier of the current development context as D. context ; The policy routing function Route is executed, which takes the associated object J as input and calculates D. target With D context If the matching relationship is consistent, the database inner join strategy P is output. local If they are inconsistent, output the application layer aggregation strategy P. remote .

4. The method for constructing logical associations of heterogeneous databases and generating privacy-compliant code for intelligent programming assistance as described in claim 1, characterized in that: It also includes step S5: As a supplement to step S2, when a user command retrieves multiple associated objects in step S3, and after the policy routing function Route determines them one by one, there is an output P. local With P remote When the path is specified, the system initiates mixed association processing, which specifically includes: Construct a data association graph based on all associated paths, and assign routes that satisfy Route(J, D) to the graph. context )=P remote Edges are marked as cross-library edges, and the rest are marked as same-library edges, and the association graph is divided into same-library subgraphs and cross-library subgraphs accordingly; For the same-database subgraph, generate an SQL inner join subtask; for the cross-database subgraph, generate an application-layer aggregation subtask; and append a level union subtask. Then, merge the result sets output by the two subtasks in memory according to the primary join key to form the final result.

5. The method for constructing logical associations of heterogeneous databases and generating privacy-compliant code for intelligent programming assistance as described in claim 1, characterized in that: The construction of enhanced contextual hints in step S3 specifically includes: Obtain the current service name, the database identifier of the current development context, the retrieved set of logically related paths, the determined code generation strategy and its corresponding constraint set, and the de-identification rule set; The above-mentioned items are used as parameters and filled into the preset structured prompt template to generate an architectural constraint description that includes role constraints, database topology, association topology, prohibited behaviors and desensitization rules. The enhanced contextual hints are formed by concatenating the architectural constraint description with the user's original natural language programming instructions.

6. The method for constructing logical associations of heterogeneous databases and generating privacy-compliant code for intelligent programming assistance as described in claim 1, characterized in that: The cross-domain logical association attribute in step S1 is formalized as a cross-domain logical association six-tuple J=(D target ,S target ,T target C target ,R type M service ,f map ), where D target S is the identifier for the target database. target For the target service identifier, T target For the target table name, C target For the target field name, R type For association types, the value can be One To One, One To Many, or Many To One, M service f is the service call method name. map This represents the mapping relationship from the source field to the target field.

7. The method for constructing logical associations of heterogeneous databases and generating privacy-compliant code for intelligent programming assistance as described in claim 1, characterized in that: The data security attribute in step S1 is formalized as a data security triple Sec=(isMask,algo M algo E ), where isMask is a boolean value indicating whether the field is a sensitive field, algo M For desensitization algorithm type, algo E The encryption algorithm type; consisting of all fields that satisfy isMask as true and their corresponding algorithms. M The values ​​are used to form a set of de-identification rules to guide code generation.

8. The method for constructing logical associations of heterogeneous databases and generating privacy-compliant code for intelligent programming assistance as described in claim 7, characterized in that: The automatic implantation of desensitization processing logic in step S4 specifically includes: The compliance audit module scans the initially generated code, locates all fields where isMask is true based on the data security triple Sec, and automatically applies the de-identification function f. mask Perform a logical wrapping to make the original value v of the corresponding field... plain Replaced with the desensitized value v masked And satisfy v masked =f mask (v plain algo M ); When the data security triple Sec contains algo E Define the encryption function f when it is not empty. enc Satisfy v encrypted =f enc (v plain algo E ), and the decryption function f dec Satisfy v plain =f dec (v encrypted algo E For data write operations, automatically replace the parameter value with f. enc Call; for data read operations, automatically apply f sequentially to the results. dec and f mask The calls constitute a combined processing; for log printing operations, judgment logic is automatically injected to replace sensitive values ​​with safe placeholders.

Images