Generation method of complex data model based on natural language

Abstract

The invention relates to the technical field of informatization system development, in particular to a natural language-based complex data model generation method, which comprises the following steps of receiving business requirement input in a natural language form, preprocessing and normalizing input contents, processing ambiguity and incompleteness of requirements through a multi-round dialogue complementation mechanism, and generating a complex data model. Obtaining a complete and clear business demand description; and carrying out deep semantic analysis on the normalized business requirements by adopting a large language model. Aiming at the pain points that an existing data modeling technology is high in threshold, low in efficiency, difficult in quality guarantee, weak in integration adaptation and the like, the method has the remarkable advantage of multiple dimensions, non-technical background personnel can directly input service requirements through natural language interaction and deep semantic analysis on the premise of reducing the technical threshold, database knowledge and SQL specifications do not need to be elaborated, and the method is suitable for large-scale popularization and application. The cognitive gap of business and technology is spanned, the dependence on professional design talents is reduced, and the learning cycle of green hands is shortened.

Description

TECHNICAL FIELD

[0001] 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. BACKGROUND

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

[0003] Generally, the traditional manual coding method includes: the developer manually writes SQL DDL (Data Definition Language) statements based on the business requirement document; directly executes the table creation operation using the database management tool; defines the data type, constraint condition, index, etc. field by field through the text editor to write the SQL script; needs to manually maintain the database version change and migration script; the graphical design tool uses professional database design tools such as ER / Studio and PowerDesigner; creates an entity relationship diagram through drag-and-drop; automatically generates the corresponding SQL DDL statement; supports reverse engineering to generate design documents from existing databases; the model-driven architecture (MDA) method creates platform-independent models (PIM) based on UML modeling tools; generates platform-specific models through model conversion technology; finally converts to specific data model code; predefines data model templates and code generation rules based on template code generation; drives the code generation process through configuration parameters; generates basic data access layer code and table structure; the basic large language model application uses a general large language model to generate simple SQL statements; implements basic data table creation functions based on prompt word engineering; outputs the standard CREATE TABLE statement.

[0004] However, the prior art has the following defects; the technical threshold requires too high professional knowledge: the designer needs to be proficient in business domain knowledge, database theory foundation, SQL language specification and specific database product characteristics, such compound talents are scarce and the training cost is high; the learning curve is steep, it takes a long time for novice designers to master complete data modeling skills, including data type selection, index design, performance optimization, etc. Cross-disciplinary communication barriers, the technical understanding of business personnel and the understanding of business by technical personnel have a gap, leading to distorted demand transmission; the complete process from requirement analysis, conceptual design, logical design to physical design usually takes several days or even weeks, which cannot meet the rapid iteration development requirements, the data model of similar business scenarios needs to be designed repeatedly, there is a lack of intelligent reuse mechanism, the structure adjustment of the existing data model involves a chain of modifications of multiple links, which is time-consuming and easy to miss, different design personnel adopt different naming specifications, data type selection standards and constraint definition methods, leading to internal inconsistency of the system, manual design is prone to technical errors such as incorrect field type selection, missing constraints and index omission, there is a lack of early performance estimation, and many design defects are exposed under the pressure of large data volume after the system goes online.

[0005] Based on this, the present application provides a natural language complex data model generation method to solve the above technical problems. SUMMARY

[0006] The present application aims to provide a natural language complex data model generation method to solve the problems in the background art.

[0007] To achieve the above purpose, the present application provides the following technical solutions:

[0008] The present application provides a natural language complex data model generation method, comprising the following steps:

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

[0010] S2. Use a large language model to deeply analyze the standardized business requirement, extract core modeling elements including entities, attributes, association relationships and explicit and implicit constraint conditions, and generate a structured intermediate representation;

[0011] S3. Based on the structured intermediate representation, follow the database design specifications and best practices to generate standard database DDL statements, including table structure definition, constraint condition configuration 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] log() ;

[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] Fig. 1 This is a flowchart of the generation method based on a complex natural language data model according to the present invention;

[0068] Fig. 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] Fig. 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 Figs. 1-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] log() ;

[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 toFigs. 1-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., log() , 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 within 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, 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;

[0164] Semantic association coefficient, ranging from [0.9, 1.1]. If the phrase has a semantic association with the identified core entity (such as "user table") (e.g., "user 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": "用户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, if the discrimination index is ≤0.2, then =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 method for generating a natural language-based complex data model, characterized in that, Comprise the following steps: S1. Receive the business requirement input in natural language form, preprocess and normalize the input content, handle the ambiguity and incompleteness of the requirement through multi-round dialogue completion mechanism, and obtain a complete and clear business requirement description; S2. Adopt a large language model to perform deep semantic analysis on the normalized business requirement, extract core modeling elements including entities, attributes, association relationships and explicit and implicit constraint conditions, and generate a structured intermediate representation; S3. Based on the structured intermediate representation, follow the database design specifications and best practices to generate standard database DDL statements, including table structure definition, constraint configuration and index strategy design; S4. Establish a triple mapping system from general DDL statements to target platform data models, realize accurate mapping and intelligent completion of basic technical attributes, business association relationships and platform extension attributes, and generate platform-adapted data model configuration information; S5. Verify the integrity, consistency and performance of the generated platform data model, optimize and adjust based on the verification results if it fails, and output multi-format achievements and API interfaces after passing; S6. Record the key parameters and quality indicators in the model generation process, continuously optimize the model generation rules based on user feedback and detection results, and realize dynamic iteration of the technical scheme. 2.The method of claim 1, wherein, The implementation process of step S1 is: Provide a multi-modal input interface for text, voice, and document uploading, and perform text cleaning and word segmentation preprocessing on the input content; Extract core business elements through a key phrase weight calculation algorithm, and the algorithm formula is: ； wherein, is the weight of the jth phrase in the ith requirement text, the higher the weight value, the greater the possibility that the phrase is a core element of modeling; is the term frequency of the jth phrase in the ith requirement text, i.e., the number of times the phrase appears in the text / total number of phrases in the text, reflecting the importance of the phrase in the current requirement; is the inverse document frequency of the jth phrase, i.e.: log() ; In the formula, N is the total number of domain corpus documents, is the number of documents containing the jth phrase, reflecting the generality of the phrase in the domain, the lower the generality, the higher the IDF value, the more likely it is a business-specific element; is the domain matching coefficient, the value range is [0.8, 1.2], if the phrase exists in the domain dictionary, then =1.2, otherwise =0.8, used to strengthen the weight of domain-specific terms; is the semantic association coefficient, the value range is [0.9, 1.1], if the phrase has semantic association with the identified core entity, then =1.1, otherwise =0.9, used to strengthen the weight of entity-related attributes; For requirements missing core elements, supplement through multi-round dialogue request, and automatically complete default information based on domain knowledge base.

3. The method of claim 2, wherein, The implementation process of step S2 is: Based on the phrase weight calculated in step S1, filter phrases with a score ≥ 0.6 as candidate entities, determine a core entity set by entity type classification; For each core entity, associate semantic-related phrases as attributes and extract constraint information; Deduce the relationship type between entities through association relationship confidence calculation, and the algorithm formula is: ； In the formula, is the association confidence of entity A and entity B, and the value range is [0, 1], 0.7 is determined as "strong association", is determined as "weak association", 0.7 is determined as "no association"; is the co-occurrence times of entity A and entity B in the demand text; is the semantic association degree of entity A and entity B, which is a semantic similarity score calculated based on a pre-trained language model, and the value range is [0, 1]; is the total occurrence times of entity A in the demand text, is the total occurrence times of entity B in the demand text, which is used for normalizing the co-occurrence times to avoid the interference of high-frequency entities; and the final output includes a JSON format structured intermediate representation of entities, attributes, and relationships, and clearly shows the business labels, data types, constraint conditions, and association confidence of each element.

4. The method of claim 3, wherein, The implementation process of step S3 is: According to the structured intermediate representation, determine the table name according to "business label + table", determine the field name according to "business label first letter in lowercase + underscore", and match the basic data type; Generate constraint conditions: default to select fields containing "ID" and "number" as primary keys, select candidate primary keys based on field uniqueness scores, generate foreign key constraint statements, and map non-empty / unique constraints; Determine the index field through index necessity score calculation, and the algorithm formula is: ； Optimize data types and storage engines, adapt to different databases such as MySQL, PostgreSQL, and Oracle, and generate standard DDL statements.

5. The method of claim 4, wherein, The implementation process of step S4 is: Realize the mapping of basic technical attributes, convert the data types and constraints in DDL to platform-supported formats; Convert the relationship between entities to platform association configuration, configure "one-to-many" relationship as master-slave association, and automatically generate intermediate table and bidirectional foreign key constraint for "many-to-many" relationship; Automatically complete platform attributes through extension attribute matching degree calculation, and the algorithm formula is: ； In the formula, is the matching degree of the field f and the platform attribute p, and the value range is [0, 1], 0.7 automatically configures the attribute p for the field f; is the semantic similarity of the field f and the attribute p, which is calculated based on a platform attribute dictionary and field business semantics, and the value range is [0, 1]; is the rule matching degree of the field f and the attribute p, which is calculated based on a preset rule, and the value range is [0, 1]; is a weight coefficient, and the value is 0.4, which is used to balance the semantic similarity and the rule matching degree and ensure the accuracy of the result; Based on field semantics and type inference, query type, display format and verification rules, and generate platform data model configuration information containing business label and extension attributes.

6. The method of claim 5, wherein, The implementation process of step S5 is: Integrity verification is performed on the generated platform data model to check the completeness of entities, attributes, and relationships. Reference integrity verification is performed to ensure that foreign key fields are consistent with the primary key data types of the main table and the joint primary key of the intermediate table is complete. The entity relationship network is constructed to check for circular dependencies and isolated entities and provide optimization suggestions. The database design best practice library is applied to check naming conventions, normal form specifications, and performance specifications, and the user is prompted in case of conflicts. After verification, the model metadata is stored in a relational database, and the platform configuration file in Excel format, DDL script execution, RESTful API specification, and technical documentation are output to support CI / CD pipeline integration.

7. The method of claim 6, wherein, The implementation process of the large language model processing engine used in step S2 is as follows: Select Qwen-7B / Doubao-13B / GLM-4 with semantic understanding accuracy ≥ 90% and reasoning speed ≤ 1 second / sentence as the base model. Fine-tune the model based on the data modeling field corpus, aiming for entity recognition accuracy ≥ 95%, attribute extraction accuracy ≥ 92%, and relationship inference accuracy ≥ 90%. Optimize performance using model quantization and distillation techniques, with single requirement processing time ≤ 30 seconds; establish a "main model + special model" collaborative mechanism to improve accuracy through result fusion. Import industry domain dictionaries and business rules, regularly collect feedback to update dictionaries and rules, and achieve continuous learning.

8. The method of claim 7, wherein, The implementation process of the data model mapping and configuration engine in step S4 is as follows: Configure mapping rules for basic attributes, associated relationships, and extended attributes, including conditions, results, and priority levels 1-10. Built-in database design best practice library automatically applies naming conventions, third normal form, and performance specifications, and prompts the user in case of conflicts. Handle special cases such as many-to-many relationships, composite primary keys, and historical data compatibility; provide rule templates and visual configuration wizards, support rule hot loading and change log recording, and take effect without restarting the system.

9. The method of claim 8, wherein, 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. Generate data access layer code, API interface code, and front-end calling code, supporting integration with SpringBoot, Flask / Django frameworks. Generate field validation, relationship validation, and performance test cases based on data models, supporting export to JUnit / PyTest format. Implement model version and application version synchronization, support multi-condition query metadata, and export to Excel.

10. The method of claim 9, wherein, The implementation process of business rule extraction and implementation in step S2 is as follows: Identify "must" "unique" "greater than" keywords in the requirements, extract non-empty, unique, range, format verification rules, and parameters. Extract derived fields and calculation logic, specify derived field names, calculation formulas, data types, and update timing. Convert verification rules to database constraints and application layer verification code, and convert calculation rules to database generated columns, triggers, or application layer calculation logic. Based on user feedback and detection results, the parameters of the calibration DDL generation and platform mapping are generated every 10 batches of models, the rule engine and model parameters are optimized, and the stable cycle and iteration of the technical solution are realized.

Images