A dynamically configurable database management method for aerospace simulation

Abstract

This invention discloses a dynamically configurable database management method for aerospace simulation. By establishing a meta-model inheritance system, it allows users to dynamically create data structures for materials and simulation models through a graphical designer, defining attribute sets and constraints. It decouples the data model from the user interface through form definitions, table definitions, and query definitions, generating reusable query logic. When responding to data access requests, the dynamic engine loads the corresponding metadata definitions, employs a hybrid persistence strategy combining basic information relationship tables and extended attribute JSONB to store data, and indexes frequently queried fields. Finally, it dynamically renders the data management page. This invention achieves flexible data model expansion and zero-code configurable management, ensuring flexibility while maintaining query performance, significantly reducing development and maintenance costs, and is suitable for aerospace simulation data management scenarios with complex structures and frequent iterations.

Description

Technical Field

[0001] This invention relates to the field of database management technology, and more specifically to a dynamically configurable database management method for aerospace simulation. Background Technology

[0002] Currently, in aerospace simulation systems, efficiently managing complex and frequently iterated material data and simulation model data is a core technological challenge. Existing solutions mainly rely on relational databases with fixed structures, which pre-define table structures for each type of material or model. This leads to system rigidity, and any addition of attributes requires cumbersome database schema changes and full-stack code modifications, making it unable to adapt to rapidly evolving simulation requirements.

[0003] While flexible solutions such as Entity-Attribute-Value (EAV) models or document databases (NoSQL) exist to address the flexibility issue, the former, the EAV model, suffers from a sharp deterioration in query performance due to a large number of table joins, while the latter, document databases, are weak in handling complex relational queries and transaction consistency.

[0004] In addition, all these traditional architectures suffer from tight coupling between the data model and the user interface. Even minor changes in the data structure can trigger a chain of code modifications and redeployments from the backend to the frontend, resulting in high system maintenance costs and long development cycles, which severely restricts the agility and innovation efficiency of simulation experiments.

[0005] Therefore, there is an urgent need in this field for a new data management technology that can balance flexibility, performance, and maintainability. Summary of the Invention

[0006] Therefore, this invention provides a dynamically configurable database management method for aerospace simulation to solve the problems in the prior art.

[0007] To achieve the above objectives, the present invention provides the following technical solution: A dynamically configurable database management method for aerospace simulation includes the following steps: Step 1. Establish a metamodel inheritance hierarchy, which includes the basic metamodel and the inheritance relationships between models; Step 2. Receive model definition information input by the user through the graphical interface, and dynamically create a target model based on the metamodel inheritance system. The model definition information includes the attribute set of the target model and the set of constraints acting on the attribute set. Step 3. Receive the user's data display configuration information for the target model, and generate form definitions and / or table definitions bound to the target model; Step 4. Receive the user's data filtering configuration information for the target model, and generate a reusable query definition bound to the target model; Step 5. Respond to the data access requests from the front-end user; Step 6. Load the target model definition, form definition, table definition and query definition corresponding to the data access request through the dynamic engine, and dynamically render the corresponding data management page.

[0008] Furthermore: In step 2, when dynamically creating the target model, the target model inherits from a parent model and automatically obtains all the attributes and constraints of the parent model.

[0009] Furthermore, each attribute in the attribute set consists of a name, data type, constraints, and business metadata.

[0010] Furthermore, the data types include associated reference types, which are used to represent references to another model in the system to establish relationships between models.

[0011] Furthermore: In step 3, the form definition maps the attributes of the target model to the user interface control and defines the layout information of the control; the table definition selects the attributes of the target model as the display columns of the data list and configures the display attributes of the display columns.

[0012] Furthermore, in step 4, the query definition is formalized into a logical expression tree, and the dynamic engine can parse the logical expression tree into the underlying database query language and execute it.

[0013] Furthermore: In step 6, the dynamic rendering employs a hybrid data persistence strategy, including: The basic information of the model is stored in the first fixed table of the relational database; The model's custom extended attributes are stored in a semi-structured data format in the second table and associated with the first fixed table via foreign keys.

[0014] Furthermore, database indexes are created for commonly used query fields in the semi-structured data format.

[0015] To achieve the above objectives, the present invention also provides a dynamically configurable database management system for aerospace simulation; comprising: The metamodel and modeling module is used to implement the metamodel inheritance hierarchy and the dynamic creation of models; The data definition and mapping module is used to configure and manage form definitions, table definitions, and query definitions. A dynamic page loading and rendering engine is used to parse metadata definitions and dynamically generate user interfaces; The data persistence module is used to implement hybrid data storage strategies.

[0016] The present invention has the following advantages: By establishing a meta-model inheritance system and providing a graphical model designer, users can dynamically create new material types or simulation model types without writing code, and can extend the property structure at any time, realizing the flexible definition and agile expansion of the data model, which greatly adapts to the ever-changing needs of the aerospace simulation field. By decoupling the data model from the user interface and adopting a metadata-driven mechanism of form definition, table definition, and query definition, the interface can automatically adapt when the data model changes without modifying the application code. Furthermore, reusable query definitions support complex combinations of conditions based on model attributes, facilitating users to deeply mine and trace simulation data.

[0017] Other features and advantages of the present invention will be set forth in the following description. Attached Figure Description

[0018] To more intuitively illustrate the prior art and this application, exemplary drawings are provided below. It should be understood that the specific shapes and structures shown in the drawings should not generally be regarded as limiting conditions for implementing this application; for example, based on the technical concept disclosed in this application and the exemplary drawings, those skilled in the art are able to easily make conventional adjustments or further optimizations to the addition / reduction / classification, specific shapes, positional relationships, connection methods, size ratios, etc. of certain units (components).

[0019] Figure 1 This is a flowchart illustrating the implementation of a dynamically configurable database management method for aerospace simulation, as provided in an embodiment of this application. Detailed Implementation

[0020] The following specific embodiments illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. It should be understood that these embodiments are only for further illustration of the present invention and should not be construed as limiting the scope of protection of the present invention. Those skilled in the art can make some non-essential improvements and adjustments to the present invention based on the above-described content.

[0021] This invention abstracts all the hard-coded data structures, business logic, and user interfaces in traditional software development into configurable metadata, and interprets and executes this metadata at runtime through a high-performance dynamic engine, thereby achieving automatic generation and seamless integration from data definition to application functions.

[0022] Please see Figure 1 A dynamic, configurable database management method for aerospace simulation includes the following steps: Step 1. Establish the meta-model inheritance hierarchy; The system predefines a basic meta-model (such as entity, material, simulation model) as the root of the entire system. This basic meta-model specifies the basic attribute set (such as unique identifier, name, creator, creation time, version number, etc.) and behavioral specifications common to all models. In addition, the meta-models support inheritance relationships, which allows any user-defined model created later to inherit one or more parent models and automatically obtain all the attributes, constraints and associated configurations of the parent models, thereby realizing attribute reuse and standardization.

[0023] The specific implementation of the metamodel architecture and dynamic modeling is as follows: (1) Let the set of all models in the system be . There exists a most basic prototype metamodel. As the foundation of the entire system, the prototype metamodel Defines the set of basic attributes that all entities must possess. Examples include ID (unique identifier), name, creatorID, createdTime, and version.

[0024] Any user-defined target model (business model) All of these can be formally defined as a six-tuple, such as "titanium alloy material" or "finite element analysis model"; business model The six-tuple is represented as follows: ; Where B represents the inheritance relationship, indicating the target model. The inherited parent model, This is an "is-a" relationship; for example, the "composite materials" model can inherit from the "basic materials" model; through inheritance, the target model... All attributes, constraints, and related interface definitions of B were automatically obtained; therefore, the target model... The complete set of attributes is ,in, It is the complete set of attributes of parent model B; this mechanism greatly promotes code reuse and the unification of data standards. A is a set of attributes, which is the target model. A self-defined set of attributes that are distinct from its parent model. These attributes describe the data fields specific to this target model; C is the set of constraints, which is the set of constraints that act on the attribute set A. in Corresponding to Constraints ensure the integrity and validity of the data. F, T, and Q are associated configurations. F is the set of form definitions bound to the target model; T is the set of table definitions bound to the target model; and Q is the set of query definitions bound to the target model. F, T, and Q determine how data is displayed, manipulated, and retrieved.

[0025] (2) Detailed description of attributes and constraints Each attribute It is itself a structured tuple: Where name is the unique identifier of the attribute; type is the data type, and its value range is... In particular, The type represents another model in the system. For example, a “simulation model” can be associated with a “material model”.

[0026] constraints is a collection of key-value pairs used to define data validation rules; for example These represent required fields, minimum value, maximum value, and regular expression pattern, respectively.

[0027] Metadata is also a collection of key-value pairs used to store rich business semantic information, such as This information can be used by the UI rendering engine to generate more user-friendly prompts and grouped displays.

[0028] Step 2. Dynamically create user-defined models Users input model definition information through a graphical model designer and create a target model based on the meta-model inheritance system.

[0029] The model definition information includes the set of attributes, the set of constraints, and inheritance relationships.

[0030] The attribute set adds custom attributes to the target model. Each attribute consists of a name, data type (such as text, integer, floating-point number, boolean value, enumeration, file, associated reference, etc.), constraints (such as required, numerical range, regular expression), and business metadata (such as unit, description, grouping). A set of constraints, which are validation rules applied to each attribute, to ensure the integrity and validity of the data; Inheritance relationship: Specifies the parent model that this model inherits from (if it exists), thereby automatically incorporating all the attributes and constraints of the parent model.

[0031] The system persistently stores the above model definitions as metadata in the metadata table, eliminating the need to create physical database tables and enabling dynamic definition and flexible expansion of the data model.

[0032] For example, users can create "composite material" models using a graphical model designer. The process is as follows: The user first selects their parent model in the interface. That is, the "materials" basic model.

[0033] Then, add a custom property set A dynamically by dragging and dropping: ; ; ; The system defines this model. The data is saved to the database as metadata without the need to create physical database tables; the entire process is declarative, not imperative.

[0034] Step 3, Configure the data display interface (i.e., configure the data definition and mapping). For the created target model, users input data and display configuration information through the graphical form designer and table designer, generating form definitions and / or table definitions bound to the model; responsible for transforming the abstract data model into specific user interaction interfaces and functions.

[0035] a. Form definition: Map the attributes of the target model to specific user interface controls (such as input boxes, drop-down menus, file upload components, etc.), and define the layout information of the controls (such as rows, columns, grid span) and control-specific options to form the metadata of the data entry and editing page; b. Table definition: Select the attribute columns to be displayed on the data list page, configure the column order, width, sorting rules, and whether filtering is supported, and form the metadata for the data query and display page.

[0036] These definitions are also stored as metadata for use in subsequent dynamic rendering.

[0037] In this embodiment, the form definition process is as follows: Form definition Responsible for the target model The properties are mapped to specific user interface controls, and their layout is defined. A form is an ordered collection of controls: ; Each control It is a tuple: ; in, To point to the target model a certain attribute Control types, such as input textinput number select, file upload color picker； The system can provide default controls based on the attribute's type and metadata, which users can override. For layout information, a grid system is typically used, such as... This indicates that the grid starts in the first row and first column, with a width of 12 grid cells; options are control-specific options, such as the options list of a drop-down menu, the configuration of a rich text editor, etc.

[0038] Step 4: Configure reusable query definitions Users input data filtering configuration information through a graphical query designer to generate reusable query definitions bound to the target model. The query definition is formalized as a logical expression tree, which is composed of basic comparison conditions (attribute path, operator, value) combined by logical connectors (AND / OR). This reusable query definition supports complex condition combinations based on model attributes (including associated attributes) and can be reused by multiple table definitions. The system stores the query definition as metadata to provide filtering logic for subsequent efficient data retrieval.

[0039] For example, a basic query condition can be expressed as: ; in, It is an attribute path, such as "tensileModulus" or "material.density" via association; It is a comparison operator; It could be a user-input value, a constant, or even another subquery; More generally, a basic query condition can be represented as a binary tree: ; in, It can be AND or OR; LeftExpr and RightExpr are subtrees, and Leaf is a leaf node, representing a basic comparison condition.

[0040] Step 5: Receive front-end data access requests Front-end users (such as materials engineers) initiate data access requests through their browsers, such as requesting a list page of the target model or a new / edit form page; the dynamic page loading and rendering engine locates the corresponding target model and its associated metadata definitions (model definition, form definition, table definition, query definition) based on the request path or parameters.

[0041] In this embodiment, for example, one of the core functions of the dynamic engine is to define abstract queries. Parse and convert the query into the underlying database's query language; let D be the database query builder. If we are the transformation function, then we have:

[0043] in, This represents the WHERE clause in the generated SQL statement; For example, for the query condition ("density" < 2.0) AND ("tensileModulus" > 100), the transformation function... This will generate the following SQL fragment (using PostgreSQL JSONB as an example):

[0044] ; This process automates the writing of SQL, avoiding the errors and tediousness of manual coding.

[0045] Step 6: The dynamic engine parses metadata and renders the data management page. The dynamic engine performs corresponding processing based on the request type: (1) If it is a list page request: A. Load the table definitions of the target model and the currently active query definition; B. Parse the logical expression tree in the query definition into the underlying database query language (such as the WHERE clause of SQL), and automatically generate query conditions using conversion functions; C. Perform hybrid data persistence queries: jointly retrieve data from the base relation table (which stores basic model information) and the extended attribute table (which stores custom extended attributes in JSONB format), and optimize query performance using GIN indexes pre-built for frequently queried fields; D. Based on the column configuration in the table definition, dynamically render the query results into an HTML list page containing interactive elements such as pagination and sorting.

[0046] The process of the list page rendering algorithm is as follows: 1) Request Reception and Routing: Front-end user requests access the target model The list page (e.g., / materials / composite); the routing layer forwards the request to the dynamic engine; 2) Metadata parsing: The engine locates the target model based on the request identifier. and load its configured table definition. and the currently active query definition .

[0047] 3) Dynamic query construction and data acquisition: a. Constructing the basic query: ; b. Column data concatenation: Traversing the table definition Each column defined in (corresponding to the attribute path) Add it to the SELECT clause. If These are basic attributes (from the basic attribute set) If it is an extended attribute (from attribute set A), it is extracted directly from the entities table; if it is an extended attribute (from attribute set A), it is extracted from the JSONB field of the extended_attributes table using a database JSON function (such as ->>). c. Apply query filters: Define the query Through conversion function Generate the SQL WHERE condition and append it to the base query: ; d. Execution and Retrieval: Execute the final constructed SQL query to retrieve the data set D that meets the conditions from the database.

[0048] 4) Interface rendering: Based on the table definition The column configurations (such as header, width, sorting, and custom renderer) are used by the dynamic engine to call the rendering function R, which renders the dataset D into the final HTML table page. This process also generates interactive elements such as pagination and sorting.

[0049] (2) If it is a form page request: a. Load the form definition of the target model; b. Recursively collect the complete attribute set of the model and all its parent models to ensure that inherited attributes are fully represented; c. Map each attribute to the corresponding UI control according to the form definition, and generate front-end validation rules based on the constraints of the attributes; d. Dynamically generate an HTML form page containing all controls (for adding or editing), and arrange it according to the defined layout.

[0050] The form page rendering algorithm is illustrated below with an example: Input: User request model, target model Add or edit forms; Analysis: The engine loads the target model. Form definition ; Recursive attribute collection: In order to fully display all the information of an entity, the engine needs to recursively collect the target model. Complete property set ; Let the function The logic for implementing this function is as follows: Where B is the target model The parent model; this process recursively returns to the most basic prototype metamodel. (Root Model).

[0051] Control generation and layout rendering: for complete property sets Each attribute in The dynamic engine defines the form. Find the corresponding control definition in the search bar. ; Then, according to the control definition widget type layout and options, and each attribute Its own constraints (used to generate front-end validation rules, such as the required attribute) dynamically generate HTML form controls; Ultimately, the HTML output of the entire form is a layout combination of the HTML of all controls: ; Where G is the control generation function; Layout is the layout arrangement function.

[0052] Step 7: Hybrid Data Persistence Storage and Retrieval All model instance data is managed using a hybrid persistence strategy; specifically: Basic information (such as ID, name, creator, creation time, and other attributes inherited from the metamodel) is stored in the core entity table of the relational database; Custom extended attributes are stored in the extended attribute table in semi-structured JSONB format and linked to the entity table via foreign keys; Relationships are managed through a dedicated relationship table.

[0053] For frequently queried attributes in JSONB fields, the system automatically or manually creates GIN indexes to ensure query performance under large data volumes. When users perform data addition, editing, or query operations, the engine completes data storage and retrieval according to the above strategy, realizing dynamic management throughout the entire process from data definition to storage and then to interface interaction.

[0054] In this embodiment, to resolve the conflict between extreme flexibility and high database performance, the present invention designs a hybrid data storage scheme that combines multiple performance optimization techniques; specifically including: (1) Hybrid data storage model Structured storage of basic information: the fundamental information of all models (i.e., from the prototype metamodel) Inherited basic property set These are neatly stored in the core relational table `entities`; this facilitates efficient relational operations on the basic fields (such as sorting by name, querying by creation time range); for example: entities (id UUID PRIMARY KEY, model_id VARCHAR, name VARCHAR,creator_id UUID, created_time TIMESTAMP, ...); Semi-structured storage for extended attributes: All custom extended attributes (i.e., set A) of all models are uniformly stored in a single extended_attributes table, using the flexible JSONB (binary JSON) format; JSONB supports complex nested structures and is perfectly suited for dynamic attributes; extended_attributes (entity_id UUID REFERENCES entities(id), attributes JSONB); Data integrity: The complete data of an entity e is the union of its basic information and its extended attribute JSON objects.

[0055] Foreign key constraints in the database ensure that each record in the extended_attributes table corresponds to a valid entity.

[0056] (2) Query optimization theory and formula To overcome the performance issues that may arise from JSONB field queries, this invention employs an aggressive indexing strategy; For frequently queried attributes in JSONB fields For example, for 'tensileModulus', we create a GIN (General Inverted Index) index; the index creation formula is: CREATE INDEX idx_gin_composite_tensile ONextended_attributes USING GIN ((attributes -> 'tensileModulus')); Executing the query function When (("tensileModulus">100)) is an index, the database optimizer will use this index to quickly locate all records in the attributes field where tensileModulus is greater than 100, improving query performance from O(n) of full table scan to near O(log n); for common equality queries, even a more efficient jsonb_path_ops index can be created.

[0057] In addition, for deep join queries (such as "material.supplier.country" = 'China'), the engine will use JOIN statements to connect multiple entity tables and extended attribute tables, and leverage the join query optimization capabilities of relational databases to ensure the response speed of complex queries.

[0058] This invention realizes end-to-end dynamic and automated processing from data modeling to interface rendering, providing a comprehensive solution for managing complex and ever-changing simulation data that combines extreme flexibility, powerful functionality, and high performance.

[0059] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A dynamically configurable database management method for aerospace simulation, characterized in that, Includes the following steps: Step 1. Establish a metamodel inheritance hierarchy, which includes the basic metamodel and the inheritance relationships between models; Step 2. Receive model definition information input by the user through the graphical interface, and dynamically create a target model based on the metamodel inheritance system. The model definition information includes the set of attributes of the target model and the set of constraints acting on the set of attributes. Step 3. Receive the user's data display configuration information for the target model, and generate form definitions and / or table definitions bound to the target model; Step 4. Receive the user's data filtering configuration information for the target model, and generate a reusable query definition bound to the target model; Step 5. Respond to the data access requests from the front-end user; Step 6. Load the target model definition, form definition, table definition and query definition corresponding to the data access request through the dynamic engine, and dynamically render the corresponding data management page.

2. The method for managing a dynamically configurable database for aerospace simulation according to claim 1, characterized in that, In step 2, when the target model is dynamically created, the target model inherits from a parent model and automatically obtains all the attributes and constraints of the parent model.

3. The method for managing a dynamically configurable database for aerospace simulation according to claim 2, characterized in that, Each attribute in the attribute set consists of a name, data type, constraints, and business metadata.

4. The method for managing a dynamically configurable database for aerospace simulation according to claim 3, characterized in that, The data types include associated reference types, which are used to represent references to another model in the system in order to establish associations between models.

5. The method for managing a dynamically configurable database for aerospace simulation according to claim 1, characterized in that, In step 3, the form definition maps the attributes of the target model to the user interface control and defines the layout information of the control; the table definition selects the attributes of the target model as the display columns of the data list and configures the display attributes of the display columns.

6. The method for managing a dynamically configurable database for aerospace simulation according to claim 1, characterized in that, In step 4, the query definition is formalized into a logical expression tree, and the dynamic engine can parse the logical expression tree into the underlying database query language and execute it.

7. A dynamically configurable database management method for aerospace simulation according to any one of claims 1-6, characterized in that, In step 6, dynamic rendering employs a hybrid data persistence strategy, including: The basic information of the model is stored in the first fixed table of the relational database; The model's custom extended attributes are stored in a semi-structured data format in the second table and associated with the first fixed table via foreign keys.

8. The method for managing a dynamically configurable database for aerospace simulation according to claim 7, characterized in that, Create database indexes for commonly used query fields in the semi-structured data format.

9. A database management system that implements the dynamically configurable database management method for aerospace simulation as described in any one of claims 1-6; characterized in that, include: The metamodel and modeling module is used to implement the metamodel inheritance hierarchy and the dynamic creation of models; The data definition and mapping module is used to configure and manage form definitions, table definitions, and query definitions. A dynamic page loading and rendering engine is used to parse metadata definitions and dynamically generate user interfaces; The data persistence module is used to implement hybrid data storage strategies.

Images