A method for generating a natural language complex data model

Abstract

The present application relates to the technical field of information system development, in particular to a generation method of a complex data model based on natural language, comprising the following steps: receiving a business requirement input in the form of natural language, preprocessing and normalizing the input content, processing the ambiguity and incompleteness of the requirement through a multi-round dialogue completion mechanism, and obtaining a complete and clear business requirement description; and performing deep semantic analysis on the normalized business requirement by using a large language model.The present application has multiple significant advantages in overcoming the pain points of high technical threshold, low efficiency, difficult quality guarantee, weak integration and adaptation, etc.of existing data modeling techniques, and in reducing the technical threshold, through natural language interaction and deep semantic analysis, non-technical personnel can directly input business requirements without the need to master database knowledge and SQL specifications, thereby bridging the cognitive gap between business and technology, reducing the dependence on professional design personnel, and shortening the learning period of beginners.

Description

Technical Field

[0001] This invention relates to the field of information system development technology, specifically to a method for generating complex data models based on natural language. Background Technology

[0002] In the current field of information system development, especially in low-code / no-code platforms and rapid enterprise application development environments, the design and implementation of data models mainly adopt the following technical solutions.

[0003] Traditional manual coding methods typically include: developers manually writing SQLDDL (Data Definition Language) statements based on business requirements documents; directly executing table creation operations using database management tools; writing SQL scripts using text editors, defining data types, constraints, indexes, etc., field by field; requiring manual maintenance of database version change and migration scripts; using professional database design tools such as ER / Studio and PowerDesigner for graphical design tools; creating entity-relationship diagrams through drag-and-drop; tools automatically generating corresponding SQLDDL statements; supporting reverse engineering to generate design documents from existing databases; Model-Driven Architecture (MDA) methods create platform-independent models (PIM) based on UML modeling tools; generating platform-specific models through model transformation technology; ultimately converting into specific data model code; template-based code generation of predefined data model templates and code generation rules; driving the code generation process through configuration parameters; generating basic data access layer code and table structures; basic large language model applications using general large language models to generate simple SQL statements; implementing basic data table creation functions based on prompt word engineering; and outputting standard CREATE TABLE statements.

[0004] However, existing technologies have the following drawbacks: The technical threshold requires excessively high levels of expertise: designers need to be proficient in business domain knowledge, database theory, SQL language specifications, and the characteristics of specific database products. Such multi-skilled talents are scarce and costly to train. The learning curve is steep; novice designers need a considerable amount of time to master complete data modeling skills, including data type selection, index design, and performance optimization. Cross-domain communication barriers exist, with a gap between business personnel's technical understanding and technical personnel's understanding of the business, leading to distorted requirements transmission. The complete process from requirements analysis, conceptual design, logical design to physical design typically takes several days or even weeks, failing to meet the demands of rapid iteration. Data models for similar business scenarios require repeated design, lacking intelligent reuse mechanisms. Structural adjustments to existing data models involve chain modifications across multiple stages, resulting in a large workload and potential for oversights. Different designers use different naming conventions, data type selection standards, and constraint definition methods, leading to inconsistencies within the system. Manual design is prone to technical errors such as incorrect field type selection, missing constraints, and missing indexes. Furthermore, there is a lack of early performance forecasting, with many design flaws only becoming apparent after system deployment under heavy data loads.

[0005] Based on this, the present invention provides a method for generating complex data models based on natural language to solve the aforementioned technical problems. Summary of the Invention

[0006] The purpose of this invention is to provide a method for generating complex data models based on natural language, thereby solving the problems mentioned in the background.

[0007] To achieve the above objectives, the present invention provides the following technical solution:

[0008] This invention proposes a method for generating complex data based on natural language, comprising the following steps:

[0009] S1. Receive business requirement input in natural language form, preprocess and standardize the input content, and handle the ambiguity and incompleteness of the requirements through a multi-turn dialogue completion mechanism to obtain a complete and clear description of the business requirements.

[0010] S2. Use a large language model to perform deep semantic parsing on the standardized business requirements, extract core modeling elements, including entities, attributes, relationships and explicit and implicit constraints, and generate a structured intermediate representation;

[0011] S3. Based on the structured intermediate representation, following database design specifications and best practices, it generates standard database DDL statements, including table structure definitions, constraint configurations, and index strategy design.

[0012] S4. Establish a triple mapping system from general DDL statements to the target platform data model to achieve accurate mapping and intelligent completion of basic technical attributes, business relationships and platform extended attributes, and generate platform-adaptive data model configuration information;

[0013] S5. Verify the integrity, consistency and performance of the generated platform data model. If it fails, optimize and adjust it based on the verification results. If it passes, persist the data and output multi-format results and API interfaces.

[0014] S6. Record key parameters and quality indicators during the model generation process, continuously optimize model generation rules based on user feedback and detection results, and realize dynamic iteration of technical solutions.

[0015] Preferably, the implementation process of step S1 is as follows:

[0016] It provides multimodal input interfaces for text, voice, and document uploads, and performs text cleaning and word segmentation preprocessing on the input content;

[0017] Core business elements are extracted using a key phrase weighting algorithm. The algorithm formula is as follows:

[0018] ;

[0019] In the formula, The weight of the j-th phrase in the i-th requirement text is given. The higher the weight value, the greater the likelihood that the phrase is a core element in the modeling (the threshold is set to 0.6; phrases exceeding the threshold are considered core phrases). The term frequency of the j-th phrase in the i-th requirement text is the number of times the phrase appears in the text divided by the total number of phrases in the text, reflecting the importance of the phrase in the current requirement. Let be the inverse document frequency of the j-th phrase, i.e.:

[0020] ;

[0021] In the formula, N represents the total number of documents in the domain corpus. The number of documents containing the j-th phrase reflects the phrase's generality within the domain. The lower the generality, the higher the IDF value, and the more likely it is to be a business-specific element. This is the domain matching coefficient, with a value range of [0.8, 1.2]. If the phrase exists in the domain dictionary, then... =1.2, otherwise =0.8, used to reinforce the weight of domain-specific terms; This is the semantic association coefficient, with a value range of [0.9, 1.1]. If the phrase has a semantic association with an identified core entity (such as "user table") (e.g., "user's mobile number" and "user table"), then... =1.1, otherwise =0.9, used to strengthen the weight of entity-related attributes;

[0022] For requests that lack core elements, the system requests supplementation through multiple rounds of dialogue, and automatically completes the default information based on the domain knowledge base.

[0023] Preferably, the implementation process of step S2 is as follows:

[0024] Based on the phrase weights calculated in step S1, the selection is performed. Phrases with a value ≥0.6 are used as candidate entities, and the core entity set is determined by entity type classification.

[0025] For each core entity, semantically related phrases are associated as attributes and constraint information is extracted;

[0026] The algorithm for inferring the type of relationship between entities by calculating the confidence level of the association relationship is as follows:

[0027] ;

[0028] In the formula, Let be the association confidence score between entity A and entity B, with a value range of [0, 1]. 0.7 is considered a "strong correlation". Determined as "weak association" 0.7 was determined to be "unrelated"; This refers to the number of times entity A and entity B co-occur in the requirement text (e.g., the number of times "order table" and "user table" appear together). The semantic similarity score is calculated based on a pre-trained language model (such as BERT) and represents the semantic association between entity A and entity B. The value range is [0, 1]. This represents the total number of times entity A appears in the requirements text. The total number of times entity B appears in the requirement text is used to normalize the co-occurrence count and avoid interference from high-frequency entities in the results; the final output is a structured intermediate representation in JSON format containing entities, attributes, and relationships, clearly defining the business tags, data types, constraints, and association confidence of each element.

[0029] Preferably, the implementation process of step S3 is as follows:

[0030] Based on the structured intermediate representation, the table name is determined by "business tag + table", and the field name is determined by "the first letter of the business tag is lowercase + underscore", matching the basic data type;

[0031] Generate constraints: By default, fields containing "ID" and "number" are selected as primary keys. Candidate primary keys are selected based on the uniqueness score of the fields. Foreign key constraint statements are generated and mapped to NOT NULL / unique constraints.

[0032] The indexed fields are determined by index necessity scoring, and the algorithm formula is as follows:

[0033] ;

[0034] Optimize data types and storage engines to adapt to different databases such as MySQL, PostgreSQL, and Oracle, and generate standard DDL statements.

[0035] Preferably, the implementation process of step S4 is as follows:

[0036] Implement basic technical attribute mapping, converting data types and constraints in DDL into platform-supported formats;

[0037] Convert the relationships between entities into platform association configurations. Configure "one-to-many" relationships as master-slave associations, and automatically generate intermediate tables and bidirectional foreign key constraints for "many-to-many" relationships.

[0038] The platform attributes are automatically completed by calculating the extended attribute matching degree. The algorithm formula is as follows:

[0039] ;

[0040] In the formula, This represents the matching degree between field f and platform attribute p, with a value range of [0,1]. 0.7 Automatically configures attribute p for field f; The semantic similarity between field f and attribute p is calculated based on the platform attribute dictionary (such as "display label" and "query method") and the business semantics of the field, with a value range of [0,1]. The rule matching degree between field f and attribute p is calculated based on preset rules (such as "if the field name contains 'ID card', the query method is 'exact match'" and "if the field name contains 'date', the display format is 'YYYY-MM-DD'"). The value range is [0,1]. This is a weighting coefficient with a value of 0.4, used to balance semantic similarity and rule matching to ensure the accuracy of the results; based on field semantics and type, it infers the query type, display format, and validation rules, and generates platform data model configuration information containing business tags and extended attributes.

[0041] Preferably, the implementation process of step S5 is as follows:

[0042] Perform integrity verification on the generated platform data model, checking the integrity of entities, attributes, and relationships;

[0043] Perform referential integrity checks to ensure that the data type of the foreign key field is consistent with the primary key data of the main table and that the composite primary key of the intermediate table is complete;

[0044] Build an entity relationship network, check for circular dependencies and isolated entities, and suggest optimizations;

[0045] Apply the best practices library for database design, validate naming conventions, normalization conventions, and performance specifications, and alert users when conflicts occur;

[0046] After successful verification, the model metadata is stored in a relational database, and the platform configuration file in Excel format, one-click execution of DDL scripts, RESTful API specifications and technical documentation are output, supporting integration with CI / CD pipelines.

[0047] Preferably, the implementation process of the large language model processing engine used in step S2 is as follows:

[0048] Qwen-7B / Doubao-13B / GLM-4, with a semantic understanding accuracy of ≥90% and an inference speed of ≤1 second / sentence, was selected as the base model.

[0049] Based on a corpus in the field of data modeling, the model is fine-tuned with the following objectives: entity recognition accuracy ≥ 95%, attribute extraction accuracy ≥ 92%, and relation inference accuracy ≥ 90%.

[0050] Performance is optimized using model quantization and distillation techniques, with a single request processing time of ≤30 seconds; a collaborative mechanism of "master model + dedicated model" is established to improve accuracy through result fusion;

[0051] Import industry-specific dictionaries and business rules, and regularly collect feedback to update the dictionaries and rules to achieve continuous learning.

[0052] Preferably, the implementation process of the data model mapping and configuration engine in step S4 is as follows:

[0053] Configure mapping rules for basic attributes, relationships, and extended attributes. The rules include conditions, results, and priority levels 1-10.

[0054] It includes a built-in database design best practices library, automatically applies naming conventions, third normal form, and performance specifications, and alerts the user when conflicts occur.

[0055] It handles many-to-many relationships, composite primary keys, and special cases of historical data compatibility; it provides rule templates and a visual configuration wizard, supports hot loading of rules and recording of change logs, and takes effect without restarting the system.

[0056] Preferably, the output and integration module implementation process in step S5 is as follows:

[0057] Generate database deployment artifacts (DDL scripts, index scripts), platform deployment artifacts (configuration files, resource files), and API deployment artifacts (specification documents, test scripts);

[0058] Generates data access layer code, API interface code, and front-end call code, supporting integration with Spring Boot and Flask / Django frameworks;

[0059] Generates field validation, relationship validation, and performance test cases based on the data model, and supports exporting to JUnit / PyTest format; synchronizes the model version with the application version, supports multi-condition querying of metadata and exporting to Excel.

[0060] Preferably, the implementation process for extracting and implementing business rules in step S2 is as follows:

[0061] Identify the keywords "must," "unique," and "greater than" in the requirements, and extract the non-empty, unique, range, and format validation rules and parameters;

[0062] Extract the derived fields and calculation logic, and clarify the derived field names, calculation formulas, data types, and update timing;

[0063] The validation rules are converted into database constraints (NOT, QUECK constraints) and application layer validation code, and the calculation rules are converted into database generated columns, triggers, or application layer calculation logic.

[0064] Based on user feedback and testing results, after every 10 batches of models are generated, the parameters of DDL generation and platform mapping are calibrated, and the rule engine and model parameters are optimized to achieve stable cycle and iteration of the technical solution.

[0065] Compared with the prior art, the beneficial effects of the present invention are:

[0066] This invention addresses the pain points of existing data modeling technologies, such as high barriers to entry, low efficiency, difficulty in ensuring quality, and weak integration and adaptability. It offers significant advantages in multiple dimensions. In lowering the technical barrier, it utilizes natural language interaction and deep semantic parsing, allowing non-technical personnel to directly input business requirements without needing expertise in database knowledge and SQL standards. This bridges the cognitive gap between business and technology, reduces reliance on professional design talent, and shortens the learning cycle for beginners. Regarding improved efficiency and cost control, it constructs an end-to-end intelligent generation process, compressing the design cycle from days to minutes. Intelligent reuse mechanisms avoid repetitive work, and model adjustments automatically link relevant processes. It supports rapid iteration, reduces development and maintenance costs, and ensures design quality by incorporating a best practice library and automated verification mechanism. It unifies design specifications, avoids issues such as field errors and missing constraints, and optimizes indexing and partitioning strategies in advance to avoid performance risks after deployment. In terms of platform integration and intelligence, it establishes a triple mapping system, automatically completes platform metadata, achieves smooth integration with the development toolchain, accurately identifies explicit and implicit constraints and entity associations, automatically handles many-to-many relationships, and can adapt to changes in business to adjust the model, greatly improving intelligence and integration adaptability, and comprehensively meeting the rapid development needs of low-code / no-code platforms and enterprise-level applications. Attached Figure Description

[0067] Figure 1 This is a flowchart of the generation method based on a complex natural language data model according to the present invention;

[0068] Figure 2 This is a schematic diagram of the platform data model structure for the generation method based on complex natural language data models of the present invention;

[0069] Figure 3 This is a system architecture diagram of the generation method based on complex data models of natural language according to the present invention. Detailed Implementation

[0070] The technical solutions of the present invention will be clearly and completely described below with reference to the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0071] Example 1, please refer to Figures 1 to 3 This invention proposes a generation method based on a complex data model of natural language, comprising the following steps:

[0072] S1. Receive business requirement input in natural language form, preprocess and standardize the input content, and handle the ambiguity and incompleteness of the requirements through a multi-turn dialogue completion mechanism to obtain a complete and clear description of the business requirements.

[0073] S2. Use a large language model to perform deep semantic parsing on the standardized business requirements, extract core modeling elements, including entities, attributes, relationships and explicit and implicit constraints, and generate a structured intermediate representation;

[0074] S3. Based on the structured intermediate representation, following database design specifications and best practices, it generates standard database DDL statements, including table structure definitions, constraint configurations, and index strategy design.

[0075] S4. Establish a triple mapping system from general DDL statements to the target platform data model to achieve accurate mapping and intelligent completion of basic technical attributes, business relationships and platform extended attributes, and generate platform-adaptive data model configuration information;

[0076] S5. Verify the integrity, consistency and performance of the generated platform data model. If it fails, optimize and adjust it based on the verification results. If it passes, persist the data and output multi-format results and API interfaces.

[0077] S6. Record key parameters and quality indicators during the model generation process, continuously optimize model generation rules based on user feedback and detection results, and realize dynamic iteration of technical solutions.

[0078] In this embodiment, it should also be noted that the implementation process of step S1 is as follows:

[0079] It provides multimodal input interfaces for text, voice, and document uploads, and performs text cleaning and word segmentation preprocessing on the input content;

[0080] Core business elements are extracted using a key phrase weighting algorithm. The algorithm formula is as follows:

[0081] ;

[0082] In the formula, The weight of the j-th phrase in the i-th requirement text is given. The higher the weight value, the greater the likelihood that the phrase is a core element in the modeling (the threshold is set to 0.6; phrases exceeding the threshold are considered core phrases). The term frequency of the j-th phrase in the i-th requirement text is the number of times the phrase appears in the text divided by the total number of phrases in the text, reflecting the importance of the phrase in the current requirement. Let be the inverse document frequency of the j-th phrase, i.e.:

[0083] ;

[0084] In the formula, N represents the total number of documents in the domain corpus. The number of documents containing the j-th phrase reflects the phrase's generality within the domain. The lower the generality, the higher the IDF value, and the more likely it is to be a business-specific element. This is the domain matching coefficient, with a value range of [0.8, 1.2]. If the phrase exists in the domain dictionary, then... =1.2, otherwise =0.8, used to reinforce the weight of domain-specific terms; This is the semantic association coefficient, with a value range of [0.9, 1.1]. If the phrase has a semantic association with an identified core entity (such as "user table") (e.g., "user's mobile number" and "user table"), then... =1.1, otherwise =0.9, used to strengthen the weight of entity-related attributes;

[0085] For requests that lack core elements, the system requests supplementation through multiple rounds of dialogue, and automatically completes the default information based on the domain knowledge base.

[0086] In this embodiment, it should also be noted that the implementation process of step S2 is as follows:

[0087] Based on the phrase weights calculated in step S1, the selection is performed. Phrases with a value ≥0.6 are used as candidate entities, and the core entity set is determined by entity type classification.

[0088] For each core entity, semantically related phrases are associated as attributes and constraint information is extracted;

[0089] The algorithm for inferring the type of relationship between entities by calculating the confidence level of the association relationship is as follows:

[0090] ;

[0091] In the formula, Let be the association confidence score between entity A and entity B, with a value range of [0, 1]. 0.7 is considered a "strong correlation". Determined as "weak association" 0.7 was determined to be "unrelated"; This refers to the number of times entity A and entity B co-occur in the requirement text (e.g., the number of times "order table" and "user table" appear together). The semantic similarity score is calculated based on a pre-trained language model (such as BERT) and represents the semantic association between entity A and entity B. The value range is [0, 1]. This represents the total number of times entity A appears in the requirements text. The total number of times entity B appears in the requirement text is used to normalize the co-occurrence count and avoid interference from high-frequency entities in the results; the final output is a structured intermediate representation in JSON format containing entities, attributes, and relationships, clearly defining the business tags, data types, constraints, and association confidence of each element.

[0092] In this embodiment, it should also be noted that the implementation process of step S3 is as follows:

[0093] Based on the structured intermediate representation, the table name is determined by "business tag + table", and the field name is determined by "the first letter of the business tag is lowercase + underscore", matching the basic data type;

[0094] Generate constraints: By default, fields containing "ID" and "number" are selected as primary keys. Candidate primary keys are selected based on the uniqueness score of the fields. Foreign key constraint statements are generated and mapped to NOT NULL / unique constraints.

[0095] The indexed fields are determined by index necessity scoring, and the algorithm formula is as follows:

[0096] ;

[0097] Optimize data types and storage engines to adapt to different databases such as MySQL, PostgreSQL, and Oracle, and generate standard DDL statements.

[0098] In this embodiment, it should also be noted that the implementation process of step S4 is as follows:

[0099] Implement basic technical attribute mapping, converting data types and constraints in DDL into platform-supported formats;

[0100] Convert the relationships between entities into platform association configurations. Configure "one-to-many" relationships as master-slave associations, and automatically generate intermediate tables and bidirectional foreign key constraints for "many-to-many" relationships.

[0101] The platform attributes are automatically completed by calculating the extended attribute matching degree. The algorithm formula is as follows:

[0102] ;

[0103] In the formula, This represents the matching degree between field f and platform attribute p, with a value range of [0,1]. 0.7 Automatically configures attribute p for field f; The semantic similarity between field f and attribute p is calculated based on the platform attribute dictionary (such as "display label" and "query method") and the business semantics of the field, with a value range of [0,1]. The rule matching degree between field f and attribute p is calculated based on preset rules (such as "if the field name contains 'ID card', the query method is 'exact match'" and "if the field name contains 'date', the display format is 'YYYY-MM-DD'"). The value range is [0,1]. This is a weighting coefficient with a value of 0.4, used to balance semantic similarity and rule matching to ensure the accuracy of the results; based on field semantics and type, it infers the query type, display format, and validation rules, and generates platform data model configuration information containing business tags and extended attributes.

[0104] In this embodiment, it should also be noted that the implementation process of step S5 is as follows:

[0105] Perform integrity verification on the generated platform data model, checking the integrity of entities, attributes, and relationships;

[0106] Perform referential integrity checks to ensure that the data type of the foreign key field is consistent with the primary key data of the main table and that the composite primary key of the intermediate table is complete;

[0107] Build an entity relationship network, check for circular dependencies and isolated entities, and suggest optimizations;

[0108] Apply the best practices library for database design, validate naming conventions, normalization conventions, and performance specifications, and alert users when conflicts occur;

[0109] After successful verification, the model metadata is stored in a relational database, and the platform configuration file in Excel format, one-click execution of DDL scripts, RESTful API specifications and technical documentation are output, supporting integration with CI / CD pipelines.

[0110] In this embodiment, it should also be noted that the implementation process of the large language model processing engine used in step S2 is as follows:

[0111] Qwen-7B / Doubao-13B / GLM-4, with a semantic understanding accuracy of ≥90% and an inference speed of ≤1 second / sentence, was selected as the base model.

[0112] Based on a corpus in the field of data modeling, the model is fine-tuned with the following objectives: entity recognition accuracy ≥ 95%, attribute extraction accuracy ≥ 92%, and relation inference accuracy ≥ 90%.

[0113] Performance is optimized using model quantization and distillation techniques, with a single request processing time of ≤30 seconds; a collaborative mechanism of "master model + dedicated model" is established to improve accuracy through result fusion;

[0114] Import industry-specific dictionaries and business rules, and regularly collect feedback to update the dictionaries and rules to achieve continuous learning.

[0115] In this embodiment, it should also be noted that the implementation process of the data model mapping and configuration engine in step S4 is as follows:

[0116] Configure mapping rules for basic attributes, relationships, and extended attributes. The rules include conditions, results, and priority levels 1-10.

[0117] It includes a built-in database design best practices library, automatically applies naming conventions, third normal form, and performance specifications, and alerts the user when conflicts occur.

[0118] It handles many-to-many relationships, composite primary keys, and special cases of historical data compatibility; it provides rule templates and a visual configuration wizard, supports hot loading of rules and recording of change logs, and takes effect without restarting the system.

[0119] In this embodiment, it should also be noted that the implementation process of the output and integration module in step S5 is as follows:

[0120] Generate database deployment artifacts (DDL scripts, index scripts), platform deployment artifacts (configuration files, resource files), and API deployment artifacts (specification documents, test scripts);

[0121] Generates data access layer code, API interface code, and front-end call code, supporting integration with Spring Boot and Flask / Django frameworks;

[0122] Generates field validation, relationship validation, and performance test cases based on the data model, and supports exporting to JUnit / PyTest format; synchronizes the model version with the application version, supports multi-condition querying of metadata and exporting to Excel.

[0123] In this embodiment, it should also be noted that the implementation process of business rule extraction and implementation in step S2 is as follows:

[0124] Identify the keywords "must," "unique," and "greater than" in the requirements, and extract the non-empty, unique, range, and format validation rules and parameters;

[0125] Extract the derived fields and calculation logic, and clarify the derived field names, calculation formulas, data types, and update timing;

[0126] The validation rules are converted into database constraints (NOT, QUECK constraints) and application layer validation code, and the calculation rules are converted into database generated columns, triggers, or application layer calculation logic.

[0127] Based on user feedback and testing results, after every 10 batches of models are generated, the parameters of DDL generation and platform mapping are calibrated, and the rule engine and model parameters are optimized to achieve stable cycle and iteration of the technical solution.

[0128] Example 2, please refer to Figures 1 to 3 In practical applications, this invention is based on a method for generating complex data models of natural language. Specifically, the steps are as follows:

[0129] First, a large language model is used as the core of intelligent processing for the entire system, which is used for deep semantic understanding and intent recognition of natural language, extraction and structured organization of business concepts, identification and relationship construction of data model elements, reasoning for design decisions and generation of optimization suggestions.

[0130] Two precise transformations establish a complete transformation pipeline. The first transformation converts unstructured natural language descriptions into standardized database DDL statements; the second transformation converts general DDL statements into platform-specific data model configuration information.

[0131] Triple deep mapping enables comprehensive attribute mapping and enhancement: basic technical attribute mapping: accurate mapping of basic technical attributes such as data types, constraints, and indexes; business relationship mapping: complete preservation of business semantics such as entity relationships, business rules, and constraints; and platform extended attribute mapping: intelligent completion of platform-specific attributes such as display rules, query methods, and validation logic.

[0132] It should be noted that the natural language interaction interface layer of this invention supports multi-channel input, specifically including:

[0133] Web graphical interface: Provides text input boxes (supports line breaks and paste), document upload buttons (supports Word / Excel formats), and voice input buttons (supports real-time speech-to-text conversion). The interface includes modules such as "Requirement Preview", "History", and "Help Documentation".

[0134] Language User Interface: Supports voice interaction, including voice wake-up (e.g., "Start data modeling"), voice commands (e.g., "Add fields to the order table"), and voice feedback (e.g., "Order table identified, core fields need to be added").

[0135] API Interface: Provides a RESTful API interface, allowing third-party systems (such as requirement management systems and project management systems) to pass in natural language requirements through the interface. The interface parameters include "input_type" (text / document / voice), "input_content" (text content / document URL / voice file URL), and "target_platform" (target platform name).

[0136] Completeness verification: Checks whether the input content contains core elements (at least one entity and the entity's core attributes). If it is incomplete, it prompts for supplementation (e.g., "The core fields of the user table are not mentioned, please supplement them").

[0137] Improvement suggestions: Provide input improvement suggestions based on best practices, such as "It is recommended to add an 'order status' field to the order table to facilitate business flow management" and "It is recommended to clarify the relationship between the user table and the order table to facilitate the generation of foreign key constraints".

[0138] Rich context: Based on the domain knowledge base, default information is supplemented. For example, the "user table" is supplemented with the fields "user_id (primary key), user_name (not null), create_time (default current time)" by default, and the "order table" is supplemented with the fields "order_id (primary key), order_time (default current time), order_status (default 'pending payment')" by default.

[0139] Selection of the basic model for large language model processing engines:

[0140] Large language models such as Qwen-7B, Doubao-13B, and GLM-4 are used as the base models, with the selection criteria being "semantic understanding accuracy ≥90% and inference speed ≤1 second / sentence". The base models are fine-tuned based on a data modeling domain corpus (containing business requirement text, corresponding data models, and DDL scripts). The fine-tuning targets are "entity recognition accuracy ≥95%, attribute extraction accuracy ≥92%, and relationship inference accuracy ≥90%". Model quantization (quantizing 32-bit floating-point numbers into 16-bit / 8-bit numbers to reduce memory usage) and model distillation (training small models based on large models to improve inference speed) are used to ensure that the inference speed meets the requirement of "single requirement processing time ≤30 seconds". A collaborative mechanism of "main model + special model" is established. The main model is used for overall semantic understanding, and special models (such as entity recognition special models and relationship inference special models) are used for specific tasks. Accuracy is improved through "result fusion" (taking the intersection of the results of each model, and judging by confidence if there are differences).

[0141] The domain adaptation mechanism includes domain dictionary management: it supports importing industry domain dictionaries (such as government affairs, finance, and healthcare), which contain industry-specific terms (such as "application" and "certificate" in government affairs, and "account" and "transaction" in finance), term explanations, and associated attributes to improve the accuracy of understanding industry requirements. It also supports configuring industry business rules (such as "account balance cannot be negative" in finance and "project number is unique" in municipal affairs), which include trigger conditions (such as field names containing "construction period") and rule content (such as "range verification (≥0)") to automatically supplement industry-specific constraints and attributes. It also regularly collects user feedback (such as "entity recognition error" and "relationship inference error") and success cases (such as correct requirement-model correspondence), updates the domain dictionary and business rules, and fine-tunes the model to continuously improve domain adaptation capabilities.

[0142] It should also be noted that the data model mapping and configuration engine of this invention includes a rule-driven mapping system, which supports configuring basic attribute mapping rules (such as "MySQL's int type → numeric type of low-code platform"), relationship mapping rules (such as "one-to-many relationship → master-slave relationship configuration of platform"), and extended attribute mapping rules (such as "field name contains 'ID card' → query method is exact match"). Rules include "conditions" (such as data type, field name characteristics), "results" (such as platform attribute values), and "priority" (levels 1-10, with higher priority rules executed first). It also includes a built-in database design best practices library, containing naming conventions (such as using lowercase English letters + underscores for table names, and business semantics + ...). The system includes underscores, normalization guidelines (such as satisfying the third normal form to avoid data redundancy), and performance guidelines (such as creating indexes for frequently queried fields and partitioning large tables). These guidelines are automatically applied during model generation. If the requirements conflict with the guidelines, the user is prompted (e.g., "The order table contains a 'user name' field, which violates the third normal form (user name should be in the user table). Do you want to continue?"). Built-in special case handling rules include "many-to-many relationship handling" (automatically generating an intermediate table containing the primary key and related attributes of the two related entities), "composite primary key handling" (configuring a composite primary key if multiple fields are explicitly required to be unique), and "historical data compatibility handling" (selecting the same field type as the historical data if the model needs to be compatible with historical data).

[0143] The platform's data model management module includes a metadata management system that uses a relational database (such as MySQL / PostgreSQL) to store metadata. This system includes a model metadata table (storing model ID, name, version, business tag, and creation time), a field metadata table (storing field ID, model ID, field name, data type, constraints, business tag, and extended attributes), and a relation metadata table (storing relation ID, source model ID, source field ID, target model ID, target field ID, relation type, and confidence level). It supports multi-condition metadata queries, such as queries by model name, by field name, and by relation type. Query results can be exported to Excel format.

[0144] The output and integration module is specifically a multi-target output system that generates directly deployable artifacts, including:

[0145] ① Database deployment artifacts (DDL scripts, index creation scripts, data initialization scripts (optional));

[0146] ② Platform deployment artifacts (platform configuration files, resource files (such as control icons));

[0147] ③ API deployment artifacts (API specification documents, API test scripts (such as Postman scripts)), generating integration code that matches the model, including ① data access layer code (such as Java's DAO layer, Python's ORM model), implementing database operations (CRUD operations).

[0148] ② API interface code (such as Java's Controller layer, Python's Flask / Django interface) to implement API request processing and response return;

[0149] ③ Front-end calling code (such as JavaScript API calling functions) to realize the interaction between the front-end and the API, and generate test cases based on the data model, including ① field validation test cases (such as testing the format validation and non-empty validation of the "phone number" field).

[0150] ② Relationship verification test cases (such as testing whether the association query between the "order table" and the "user table" is normal);

[0151] ③ Performance test cases (such as testing the query response time of frequently queried fields), test cases can be exported to JUnit / PyTest format.

[0152] Based on the above modules, the core processing flow of the generation method based on complex natural language data models in this invention specifically includes the following steps:

[0153] S1 Natural Language Input and Intelligent Parsing;

[0154] It provides a multimodal input interface that supports multiple methods such as text input, voice input, and document upload;

[0155] It enables the preprocessing and standardization of input content, including text cleaning, word segmentation, and key information extraction;

[0156] It supports context-aware multi-turn dialogue interaction, allowing for the gradual refinement and improvement of requirements descriptions;

[0157] Key phrase extraction implementation;

[0158] The core algorithm formula for extracting business entities and attributes through "term weight calculation" is as follows;

[0159] Formula 1: Key phrase weight calculation (based on TF-IDF and domain weight correction);

[0160] The weight of the j-th phrase in the i-th requirement text. The higher the weight value, the greater the likelihood that the phrase is a core element of the model (the threshold is set to 0.6, and phrases exceeding the threshold are considered core phrases).

[0161] The word frequency of the j-th phrase in the i-th requirement text, i.e., the number of times the phrase appears in the text / the total number of phrases in the text, reflects the importance of the phrase in the current requirement;

[0162] The inverse document frequency of the j-th phrase, i.e. , where N is the total number of documents in the domain corpus, and \(N_j\) is the number of documents containing the j-th phrase, reflecting the generality of the phrase in the domain (the lower the generality, the higher the IDF value, and the more likely it is a business-specific element).

[0163] Domain matching coefficient, ranging from [0.8, 1.2]. If the phrase exists in the domain dictionary, then... =1.2, otherwise =0.8, used to reinforce the weight of domain-specific terms;

[0164] Semantic association coefficient, ranging from [0.9, 1.1]. If the phrase has a semantic association with an identified core entity (such as "user table") (e.g., "user's mobile number" and "user table"), then... =1.1, otherwise =0.9, used to strengthen the weight of entity-related attributes;

[0165] S2. Large Language Model Structured Understanding: Achieves the conversion from natural language to structured elements in 4 steps;

[0166] Entity recognition: Filtering based on phrase weights calculated using Formula 1. Phrases with a value ≥0.6 are used as candidate entities, and then the core entity set is determined by entity type classification (e.g., "User Table" and "Order Table" are classified as "Data Entities", and "Processing Department" and "ID Number" are classified as "Attributes");

[0167] Attribute extraction: For each core entity, associate it with semantically related phrases (through... The coefficient determination is used as an attribute, and the constraint information of the attribute is extracted at the same time (such as ">0" in "amount must be greater than 0" and "unique" in "unique mobile phone number").

[0168] Relationship inference: The type of relationship between entities is determined by "relationship confidence calculation". The core algorithm formula is as follows;

[0169] Formula 2: Calculation of confidence level for association relationship;

[0170] : The association confidence between entity A and entity B, with a value range of [0,1]. 0.7 is considered a "strong correlation". Determined as "weak association" 0.7 was determined to be "unrelated";

[0171] The number of times entity A and entity B co-occur in the requirement text (e.g., the number of times "order table" and "user table" appear together);

[0172] : The semantic relevance between entity A and entity B, based on the semantic similarity score calculated using a pre-trained language model (such as BERT), with a value range of [0,1].

[0173] The total number of times entity A appears in the requirements document. The total number of times entity B appears in the requirement text is used to normalize the co-occurrence count and avoid interference from high-frequency entities in the results.

[0174] The structured output uses JSON format, clearly defining the core elements of the data model such as entities, attributes, and relationships. Example code is as follows:

[0175] {

[0176] "data_models":[

[0177] {

[0178] "model_name":"orders",

[0179] "business_label":"Order Form",

[0180] "description":"Stores core information about customer orders",

[0181] "fields":[

[0182] {

[0183] "field_name":"order_id",

[0184] "business_label":"Order ID",

[0185] "data_type":"bigint",

[0186] "constraints":["PRIMARYKEY","AUTO_INCREMENT"],

[0187] "index_type":"PRIMARY",

[0188] "nullable":false

[0189] },

[0190] {

[0191] "field_name":"user_id",

[0192] "business_label":"User ID",

[0193] "data_type":"bigint",

[0194] "constraints":["FOREIGNKEY"],

[0195] "relationship":{

[0196] "target_model":"users",

[0197] "target_field":"id",

[0198] "relation_type":"many-to-one"

[0199] }

[0200] }

[0202] }

[0203] ,

[0204] "relationships":

[0205] {

[0206] "from_model":"orders",

[0207] "from_field":"user_id",

[0208] "to_model":"users",

[0209] "to_field":"id",

[0210] "relation_type":"many-to-one",

[0211] "confidence":0.92 / / confidence calculated based on formula 2

[0212] }

[0213] } ​;

[0215] S3. Standard database table structure generation:

[0216] The DDL generation process involves four steps to generate DDL statements that conform to database specifications.

[0217] Basic table structure definitions: Based on the structured information output by S2, determine the table name (using the naming convention of "business tag + table", such as "order table" corresponding to "orders"), field names (using the format of "business tag first letter lowercase + underscore", such as "order ID" corresponding to "order_id"), and basic data types (such as "bigint", "varchar", "date").

[0218] Constraint generation: ① Primary key constraint: The field whose name contains "ID" or "number" is selected as the primary key by default. If there are multiple candidate fields, the selection is made by "field uniqueness score" (score = number of times the field is mentioned as a "unique" constraint in the requirements × 1.5 + semantic relevance of the field to the entity × 0.5); ② Foreign key constraint: Based on the relation information output by S2, the statement "FOREIGNKEY(field name)REFERENCES target table(target field)" is generated; ③ NOT NULL / Unique constraint: Directly maps the attribute constraint information extracted by S2;

[0219] Index generation: The fields that need to be indexed are determined by the "index necessity score". The core algorithm formula is as follows;

[0220] Formula 3: Index necessity score;

[0221] : Index necessity score for field f, with a value range of [0,1]. It is recommended to create an index. We recommend selecting based on your business scenario. 0.3 It is not recommended to create an index;

[0222] The expected query frequency for field f is calculated based on the number of times that keywords such as "query," "filter," and "statistics" co-occur with field f in the requirements. The value range is [0,1] (if the number of co-occurrences is ≥3, then...). If the co-occurrence count is 0, then... ;

[0223] The data discrimination of field f is the expected number of distinct values ​​for field f divided by the total number of records, with a value range of [0,1] (discrimination ≥ 0.8). =1, discrimination index ≤0.2 =0);

[0224] : Data type compatibility of field f, numeric / date field =1, short string type (length ≤ 50) field =0.8, long string type (length > 50) field =0.2, used to exclude field types that are not suitable for indexing;

[0225] Structure optimization: ① Data type optimization: Adjust the data type according to the expected length of the field (e.g., "phone number" is fixed at 11 digits, choose "char(11)" instead of "varchar(20)") and precision (e.g., "amount" retains 2 decimal places, choose "decimal(10,2)"); ② Storage engine selection: InnoDB is selected by default (supports transactions and foreign keys);

[0226] Multi-database platform adaptation: Adjust DDL statements for different database characteristics, such as "auto_increment" in MySQL corresponding to "serial" in PostgreSQL, and "NUMBER" in Oracle corresponding to "int / bigint" in MySQL;

[0227] S4. Platform Data Model Deep Mapping and Generation: Mapping rule implementation, realizing the mapping from general DDL to platform model in 3 dimensions;

[0228] Basic technical attribute mapping: Convert the data types and constraints in the DDL into platform-supported formats, such as mapping the "date" type to a "date picker" control in the low-code platform, and mapping the "decimal(10,2)" type to a "numeric input box (keeping 2 decimal places)".

[0229] Relationship mapping: Converts the relationships between entities into platform relationship configurations, such as configuring a "one-to-many" relationship in the platform as "the main table field is associated with the foreign key field of the subordinate table, and the main table data is used to filter the subordinate table data";

[0230] Platform extended attribute completion: Automatically completes platform-specific attributes through "extended attribute matching degree calculation". The core algorithm formula is as follows;

[0231] Formula 4: Calculation of extended attribute matching degree;

[0232] : The degree of matching between field f and platform attribute p, with a value range of [0,1]. 0.7 Automatically configures attribute p for field f;

[0233] : The semantic similarity between field f and attribute p, calculated based on the platform attribute dictionary (such as "display label" and "query method") and the business semantics of the field, with a value range of [0,1].

[0234] The rule matching degree between field f and attribute p is calculated based on preset rules (such as "if the field name contains 'ID card', the query method is 'exact match'" and "if the field name contains 'date', the display format is 'YYYY-MM-DD'"). The value range is [0,1].

[0235] : Weight coefficient, with a value of 0.4, is used to balance semantic similarity and rule matching degree to ensure the accuracy of the results;

[0236] Example of key extended property configuration:

[0237] Business Tag Generation: Generate user-friendly tags based on field names and business context, such as generating "User ID" from "user_id" and "Order Creation Time" from "order_create_time". Supports multi-language tags (such as Chinese "User ID" and English "UserID").

[0238] Query type configuration: Based on field type and business semantics, the default is "range query" for numeric / date fields (e.g., "amount ≥ 1000" "creation time ≥ 2024-01-01"); the default is "exact match" for identifier fields (e.g., "ID number" "order ID"); and the default is "fuzzy search" for descriptive fields (e.g., "order remarks" "product name").

[0239] Verification rule configuration: generated based on attribute constraints and business rules, such as configuring "format verification (11 digits)" for "phone number", "range verification (>0)" for "amount", and "format verification (including @ and domain name)" for "email".

[0240] S5. Model persistence and API output;

[0241] Platform configuration format: Generate an Excel-formatted configuration file based on the target platform's metadata specifications, containing all model attributes (basic attributes, extended attributes, and relationships) to ensure it can be directly imported into the platform for use;

[0242] Standard DDL format: Outputs DDL scripts adapted to different databases, including table creation, constraint addition, and index creation statements, and supports "one-click execution" for table creation;

[0243] API specification format: Generate RESTful API specifications based on data models, including interface path (e.g., " / api / project"), request method (GET / POST / PUT / DELETE), request parameters (e.g., "project_id"), and response format (e.g., return all fields from the order table).

[0244] Technical documentation format: Automatically generated data model documentation, including model description (business meaning, applicable scenarios), field description (field name, data type, constraints, business tags), relationship description (related entities, relationship type), and usage suggestions (query methods, index information).

[0245] Through the above steps, this invention addresses the pain points of existing data modeling technologies, such as high barriers to entry, low efficiency, difficulty in ensuring quality, and weak integration and adaptation. It offers significant advantages in multiple dimensions. Regarding lowering the technical barrier, through natural language interaction and deep semantic parsing, it allows non-technical personnel to directly input business requirements without needing expertise in database knowledge and SQL specifications, bridging the cognitive gap between business and technology, reducing reliance on professional design talent, and shortening the learning cycle for beginners. In terms of improving efficiency and controlling costs, it constructs an end-to-end intelligent generation process, compressing the design cycle from several days to minutes. It avoids repetitive work through intelligent reuse mechanisms, and automatically links to relevant systems when adjusting the model. In key areas, it supports rapid iteration, reducing development and maintenance costs. To ensure design quality, it has a built-in best practice library and automated verification mechanism, unifies design specifications, avoids issues such as field errors and missing constraints, and optimizes indexing and partitioning strategies in advance to avoid performance risks after deployment. In terms of platform integration and intelligence, it establishes a triple mapping system, automatically completes platform metadata, achieves smooth integration with the development toolchain, accurately identifies explicit and implicit constraints and entity relationships, automatically handles many-to-many relationships, and can adapt to business changes to adjust the model, greatly improving intelligence and integration adaptability, and comprehensively meeting the rapid development needs of low-code / no-code platforms and enterprise-level applications.

[0246] In the description of this specification, references to terms such as "an embodiment," "example," "specific example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0247] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The invention is limited only by the claims and their full scope and equivalents.

Claims

1. A generation method based on a complex data model of natural language, characterized in that, Includes the following steps: S1. Receive business requirement input in natural language form, preprocess and standardize the input content, and handle the ambiguity and incompleteness of the requirements through a multi-turn dialogue completion mechanism to obtain a complete and clear description of the business requirements. S2. Use a large language model to perform deep semantic parsing on the standardized business requirements, extract core modeling elements, including entities, attributes, relationships and explicit and implicit constraints, and generate a structured intermediate representation; S3. Based on the structured intermediate representation, following database design specifications and best practices, it generates standard database DDL statements, including table structure definitions, constraint configurations, and index strategy design. S4. Establish a three-tiered mapping system from general DDL statements to the target platform's data model, achieving accurate mapping and intelligent completion of basic technical attributes, business relationships, and platform extended attributes, and generating platform-adaptive data model configuration information, specifically including: Basic technical attribute mapping: Converts the data types and constraints in the DDL into a format supported by the target platform; Business relationship mapping: Convert the relationship between entities into platform relationship configuration. One-to-many relationship configuration is master-slave relationship, and many-to-many relationship automatically generates intermediate table and two-way foreign key constraints; Platform extended attribute mapping: Automatically completes platform attributes by calculating the matching degree of extended attributes, and generates platform data model configuration information containing business tags and extended attributes; S5. Verify the integrity, consistency and performance of the generated platform data model. If it fails, optimize and adjust it based on the verification results. If it passes, persist the data and output multi-format results and API interfaces. S6. Record key parameters and quality indicators during the model generation process, continuously optimize model generation rules based on user feedback and detection results, and realize dynamic iteration of technical solutions.

2. The generation method based on a complex natural language data model according to claim 1, characterized in that, The implementation process of step S1 is as follows: It provides multimodal input interfaces for text, voice, and document uploads, and performs text cleaning and word segmentation preprocessing on the input content; Core business elements are extracted using a key phrase weighting algorithm. The algorithm formula is as follows: ； In the formula, Let be the weight of the j-th phrase in the i-th requirement text. The higher the weight value, the greater the likelihood that the phrase is a core element of the modeling. The term frequency of the j-th phrase in the i-th requirement text is the number of times the phrase appears in the text divided by the total number of phrases in the text, reflecting the importance of the phrase in the current requirement. Let be the inverse document frequency of the j-th phrase, i.e.: ； In the formula, N represents the total number of documents in the domain corpus. The number of documents containing the j-th phrase reflects the phrase's generality within the domain. The lower the generality, the higher the IDF value, and the more likely it is to be a business-specific element. This is the domain matching coefficient, with a value range of [0.8, 1.2]. If the phrase exists in the domain dictionary, then... =1.2, otherwise =0.8, used to reinforce the weight of domain-specific terms; This is the semantic association coefficient, with a value range of [0.9, 1.1]. If the phrase has a semantic association with the identified core entity, then... =1.1, otherwise =0.9, used to strengthen the weight of entity-related attributes; For requests that lack core elements, the system requests supplementation through multiple rounds of dialogue, and automatically completes the default information based on the domain knowledge base.

3. The generation method based on a complex natural language data model according to claim 2, characterized in that, The implementation process of step S2 is as follows: Based on the phrase weights calculated in step S1, the filter is performed. Phrases with a value ≥0.6 are used as candidate entities, and the core entity set is determined by entity type classification. For each core entity, semantically related phrases are associated as attributes and constraint information is extracted; The algorithm for inferring the type of relationship between entities by calculating the confidence level of the association relationship is as follows: ； In the formula, Let be the association confidence score between entity A and entity B, with a value range of [0, 1]. 0.7 is considered a "strong correlation". It was determined to be a "weak association". Determined as "unrelated"; This represents the number of times entity A and entity B co-occur in the requirement text. The semantic similarity score is calculated based on a pre-trained language model and represents the semantic association between entity A and entity B. The value range is [0, 1]. This represents the total number of times entity A appears in the requirements text. The total number of times entity B appears in the requirement text is used to normalize the co-occurrence count and avoid interference from high-frequency entities in the results; the final output is a structured intermediate representation in JSON format containing entities, attributes, and relationships, clearly defining the business tags, data types, constraints, and association confidence of each element.

4. The generation method based on a complex natural language data model according to claim 3, characterized in that, The implementation process of step S3 is as follows: Based on the structured intermediate representation, the table name is determined by "business tag + table", and the field name is determined by "the first letter of the business tag is lowercase + underscore", matching the basic data type; Generate constraints: By default, the field containing "ID" or "number" is selected as the primary key. Candidate primary keys are selected based on the field's uniqueness score. Foreign key constraint statements are generated and mapped to NOT NULL / unique constraints. The indexed fields are determined by index necessity scoring, and the algorithm formula is as follows: ； In the formula, : Index necessity score for field f, with a value range of [0,1]. It is recommended to create an index. We recommend selecting based on your business scenario. 0.3 It is not recommended to create an index; The expected query frequency for field f is calculated based on the co-occurrence count of keywords such as "query," "filter," and "statistics" with field f in the requirements. The value range is [0,1]. If the co-occurrence count is ≥3, then... If the co-occurrence count is 0, then... ; The data discrimination of field f is the expected number of distinct values ​​for field f divided by the total number of records. The value range is [0,1]. A discrimination ≥ 0.8 indicates a good data distribution. =1, if the discrimination index is ≤0.2, then =0; : Data type compatibility of field f, numeric / date field =1, short string field =0.8, long string type field =0.2, used to exclude field types that are not suitable for indexing; Optimize data types and storage engines to adapt to different databases such as MySQL, PostgreSQL, and Oracle, and generate standard DDL statements.

5. The generation method based on a complex natural language data model according to claim 4, characterized in that, The implementation process of step S4 is as follows: Implement basic technical attribute mapping, converting data types and constraints in DDL into platform-supported formats; Convert the relationships between entities into platform association configurations. Configure "one-to-many" relationships as master-slave associations, and automatically generate intermediate tables and bidirectional foreign key constraints for "many-to-many" relationships. The platform attributes are automatically completed by calculating the extended attribute matching degree. The algorithm formula is as follows: ； In the formula, This represents the matching degree between field f and platform attribute p, with a value range of [0,1]. 0.7 Automatically configures attribute p for field f; The semantic similarity between field f and attribute p is calculated based on the platform attribute dictionary and field business semantics, with a value range of [0,1]. The rule matching degree between field f and attribute p is calculated based on preset rules, and the value range is [0,1]. This is a weighting coefficient with a value of 0.4, used to balance semantic similarity and rule matching to ensure the accuracy of the results; Based on field semantics and type inference, query types, display formats, and validation rules are generated to produce platform data model configuration information that includes business tags and extended attributes.

6. The generation method based on a complex natural language data model according to claim 5, characterized in that, The implementation process of step S5 is as follows: Perform integrity verification on the generated platform data model, checking the integrity of entities, attributes, and relationships; Perform referential integrity checks to ensure that the data type of the foreign key field is consistent with the primary key data of the main table and that the composite primary key of the intermediate table is complete; Build an entity relationship network, check for circular dependencies and isolated entities, and suggest optimizations; Apply the best practices library for database design, validate naming conventions, normalization conventions, and performance specifications, and alert users when conflicts occur; After successful verification, the model metadata is stored in a relational database, and the platform configuration file in Excel format, one-click execution of DDL scripts, RESTful API specifications and technical documentation are output, supporting integration with CI / CD pipelines.

7. The generation method based on a complex natural language data model according to claim 6, characterized in that, The implementation process of the large language model processing engine used in step S2 is as follows: Qwen-7B / Doubao-13B / GLM-4, with a semantic understanding accuracy of ≥90% and an inference speed of ≤1 second / sentence, was selected as the base model. Based on a corpus in the field of data modeling, the model is fine-tuned with the following objectives: entity recognition accuracy ≥ 95%, attribute extraction accuracy ≥ 92%, and relation inference accuracy ≥ 90%. Performance is optimized using model quantization and distillation techniques, with a single request processing time of ≤30 seconds; a collaborative mechanism of "master model + dedicated model" is established to improve accuracy through result fusion; Import industry-specific dictionaries and business rules, and regularly collect feedback to update the dictionaries and rules to achieve continuous learning.

8. The generation method based on a complex natural language data model according to claim 7, characterized in that, The implementation process of data model mapping and configuration engine in step S4 is as follows: Configure mapping rules for basic attributes, relationships, and extended attributes. The rules include conditions, results, and priority levels 1-10. It includes a built-in database design best practices library, automatically applies naming conventions, third normal form, and performance specifications, and alerts the user when conflicts occur. It handles many-to-many relationships, composite primary keys, and special cases of historical data compatibility; it provides rule templates and a visual configuration wizard, supports hot loading of rules and recording of change logs, and takes effect without restarting the system.

9. The generation method based on a complex natural language data model according to claim 8, characterized in that, The implementation process of the output and integration module in step S5 is as follows: Generate database deployment artifacts, platform deployment artifacts, and API deployment artifacts; Generates data access layer code, API interface code, and front-end call code, supporting integration with Spring Boot and Flask / Django frameworks; Generates field validation, relationship validation, and performance test cases based on the data model, and supports exporting to JUnit / PyTest format; It enables synchronization between model and application versions, supports multi-condition querying of metadata, and exports to Excel.

10. The generation method based on a complex natural language data model according to claim 9, characterized in that, The implementation process for extracting and implementing business rules in step S2 is as follows: Identify the keywords "must", "unique", and "greater than" in the requirements, and extract the non-empty, unique, range, and format validation rules and parameters; Extract the derived fields and calculation logic, and clarify the derived field names, calculation formulas, data types, and update timing; The validation rules are converted into database constraints and application-layer validation code, and the calculation rules are converted into database-generated columns, triggers, or application-layer calculation logic. Based on user feedback and testing results, after every 10 batches of models are generated, the parameters of DDL generation and platform mapping are calibrated, and the rule engine and model parameters are optimized to achieve stable cycle and iteration of the technical solution.

Images