A geological data management system

Abstract

This invention provides a geological data management system, belonging to the field of database technology. Based on an existing relational metadata database, this invention adds a dynamic field configuration module, a metadata-driven model, and an adaptive data storage engine. The dynamic automatic configuration module allows for the customization of dynamic fields, which are represented by metadata through the metadata-driven model. The adaptive data storage engine dynamically maps the defined dynamic fields to the physical storage layer of the relational metadata database. A dynamic field rule table is added to the relational metadata database to associate the dynamic fields with the original data tables, and this table is updated in the server-side model. This invention enables the addition, modification, and storage of dynamic fields for pumped storage geological data, solving the problem that managing data with a fixed field structure is difficult to adapt to the differentiated needs of different pumped storage projects.

Description

Technical Field

[0001] This invention relates to the field of database technology, and in particular to a geological data management system. Background Technology

[0002] Existing geological data management systems typically employ fixed field structures, making it difficult to adapt to the diverse needs of different pumped storage projects. In the pumped storage industry, geological data management faces the following industry-specific challenges:

[0003] Complex geological conditions: Pumped storage power station sites often involve high mountain and canyon areas, requiring the processing of multi-dimensional data such as fault zones, karst development, and groundwater. Existing systems are unable to dynamically adjust fields to adapt to the geological features of different terrains.

[0004] Rigid data models: Existing systems are mostly based on preset field templates, which cannot dynamically expand or adjust field attributes, resulting in poor data compatibility across projects.

[0005] Insufficient scalability: Traditional database structures (such as relational databases) cannot support the real-time addition and deletion of dynamic fields, requiring frequent modifications to the table structure and affecting system stability.

[0006] Dynamic monitoring requirements: High-frequency data such as reservoir seepage monitoring and groundwater level changes need to be entered in real time, but traditional databases cannot support dynamic expansion of sensor fields (such as adding "seepage flow monitoring points") due to their fixed table structure.

[0007] Lack of standardization across projects: Different pumped storage projects have different focuses on geological parameters (such as reservoir stability vs. classification of surrounding rock in water conveyance tunnels), fixed templates are difficult to reuse, and manual configuration is inefficient. Summary of the Invention

[0008] The purpose of this invention is to provide a geological data management system that can dynamically expand fields for pumped storage.

[0009] This invention provides a geological data management system, comprising: a client, a server, and external services. The server includes a relational metadata database, a NoSQL database, and a web API for accessing the relational metadata database, as well as a dynamic field metadata management module. The dynamic field metadata management module includes a dynamic field configuration module, a metadata-driven model, and an adaptive data storage engine. Any two of the relational metadata database, dynamic field configuration module, metadata-driven model, and adaptive data storage engine can call and access each other. The client accesses, modifies, and stores data in the database with the server through the web API. The external services at least provide authentication for the client. The dynamic field configuration module pre-configures a geological data template library suitable for pumped storage. Using the geological data template library, dynamic fields are defined in the relational meta-database according to the project type. The dynamic fields include: the dynamic field name, data type, association rules with the corresponding original data table in the relational meta-database, dynamic field ID, and dynamic field sequence number. The dynamic values ​​corresponding to the dynamic fields are stored in NoSQL. The metadata-driven model parses the dynamic fields, generates a dynamic field rule table in the relational meta-database according to association rules, describes the dynamic fields using metadata, and stores the metadata of the dynamic fields in the relational meta-database in JSON format. Clients access the dynamic fields in the relational database by accessing the metadata of the dynamic fields. The dynamic field rule table includes a dynamic field information table and a field rule data table. The dynamic field information table includes the data of the dynamic fields, and the field rule data table includes display rule fields and storage rule fields. An adaptive data storage engine, combined with a NoSQL database, dynamically maps the defined dynamic fields to the physical storage layer of the relational meta-database according to association rules. The relational meta-database stores the structured metadata of the dynamic fields and the core business data of the fixed fields. In use, the client reads data from the relational meta-database through the server's web API. The client can also modify the dynamic field rule table as needed after reading it, and store the modified data in the relational database through the web API.

[0010] Preferably, the display rule fields include: field status id, field usage name, associated original data table name, whether to delete, whether to display, and sorting position in the field rule data table; the storage rule fields include data restrictions and whether it is unique.

[0011] Preferably, the dynamic field information table includes a dynamic field ID, a dynamic field name, a dynamic field variable name, a dynamic field data type, and dynamic field data. The dynamic field name is in Chinese and is used for display, while the dynamic field variable name is in English and is used in the code.

[0012] Preferably, the dynamic field rule table is updated in real time, updating the name and order of the dynamic fields.

[0013] Preferably, the metadata-driven model is integrated with the GIS system to dynamically associate geological attributes with spatial coordinates.

[0014] Preferably, the adaptive data storage engine uses a MongoDB sharded cluster to store time-series data for high-frequency monitoring data, where high frequency refers to a sampling frequency greater than a preset frequency.

[0015] Preferably, the client reads data from the relational metadata database on the server via a web API through the following process: In step S101, the client initiates a data read request to the server through the server's web API, the server initiates an authentication request to the external service, and the external service authenticates the client and obtains the authentication. Step S102: The server retrieves a data table containing dynamic fields from the relational meta-database; Step S103: The client obtains data containing dynamic fields from the dynamic field rule table through the server's web API; Step S104: The server retrieves the dynamic field rule table of the corresponding data type from the relational meta-database and sends it to the client; In step S105, the client maps the acquired data to the corresponding model object through the dynamic field rule table obtained from the server.

[0016] Preferably, the client modifies the data of dynamic fields in the relational meta-database on the server via a web API through the following process: Step S201: The client sends a request to the server's web API to retrieve data for a certain type of dynamic field; Step S202: The server retrieves the corresponding type of dynamic field from the dynamic field rule table in the relational metadata database and returns the field rule data table to the client. In step S203, the client modifies the received field rule data table and sends the modified JSON format field rule data table to the server via web API.

[0017] Preferably, the client stores the modified data in the relational metadata database through the following process: Step S301: The client maps the modified JSON data submitted to the server to the model object in the server that supports the dynamic fields via a web API. Step S302: Check whether the JSON data conforms to the storage rules by retrieving the dynamic field rule table corresponding to the data of the corresponding data type; if it passes the check, it is submitted to the database; otherwise, an exception is thrown.

[0018] Compared with the prior art, the beneficial effects of the present invention are as follows: Improved compatibility: Supports data differentiation needs for different project types, improving configuration efficiency by 70% (compared to traditional manual field modification).

[0019] Enhanced scalability: Dynamic fields are updated in real time, reducing system downtime by 90%.

[0020] Reduce storage costs: Data redundancy is reduced by 40% through adaptive storage engine optimization.

[0021] Reduce operation and maintenance costs: By storing structured metadata through a relational metadata database, a hybrid storage engine is implemented, reducing the cost of high-frequency monitoring data storage by 50%.

[0022] This invention enables dynamic field addition, modification, and storage by adding new data to an existing relational metadata database and updating services, while maintaining compatibility with traditional data management systems.

[0023] This invention enables the real-time addition, deletion, and definition of dynamic fields through a data management client, without requiring system downtime or modification of the database structure, thus achieving real-time configuration of dynamic fields.

[0024] This invention optimizes the mapping efficiency between metadata and physical storage, and supports high-concurrency data writing and querying. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the structures shown in these drawings without creative effort.

[0026] Figure 1 This is a block diagram of a geological data management system according to an embodiment of the present invention.

[0027] Figure 2 This is a flowchart illustrating the data reading process of a relational meta-database according to an embodiment of the present invention.

[0028] Figure 3 This is a flowchart illustrating the data modification process of a relational meta-database according to an embodiment of the present invention.

[0029] Figure 4 This is a data storage flowchart of a relational meta-database according to an embodiment of the present invention.

[0030] Figure 5 This is a flowchart illustrating the collaboration of various modules in one embodiment of the present invention. Detailed Implementation

[0031] The specific embodiments of the present invention will be described in detail below.

[0032] like Figures 1-4 As shown, this invention provides a geological data management system, including: a client, a server, and external services. The server includes a relational metadata database, a NoSQL database, and a web API for accessing the relational metadata database, as well as a dynamic field metadata management module. The dynamic field metadata management module includes a dynamic field configuration module, a metadata-driven model, and an adaptive data storage engine. Any two of the relational metadata database, dynamic field configuration module, metadata-driven model, and adaptive data storage engine can call and access each other. The client accesses, modifies, and stores data in the database with the server through the web API. The external services at least provide authentication for the client. The dynamic field configuration module pre-configures a geological data template library suitable for pumped storage. Using the geological data template library, dynamic fields are defined in the relational meta-database according to the project type. The dynamic fields include: the dynamic field name, data type, association rules with the corresponding original data table in the relational meta-database, dynamic field ID, and dynamic field sequence number. The dynamic values ​​corresponding to the dynamic fields are stored in NoSQL. The metadata-driven model parses the dynamic fields, generates a dynamic field rule table in the relational meta-database according to association rules, describes the dynamic fields using metadata, and stores the metadata of the dynamic fields in the relational meta-database in JSON format. Clients access the dynamic fields in the relational database by accessing the metadata of the dynamic fields. The dynamic field rule table includes a dynamic field information table and a field rule data table. The dynamic field information table includes the data of the dynamic fields, and the field rule data table includes display rule fields and storage rule fields. An adaptive data storage engine, combined with a NoSQL database, dynamically maps the defined dynamic fields to the physical storage layer of the relational meta-database according to association rules. The relational meta-database stores the structured metadata of the dynamic fields and the core business data of the fixed fields. In use, the client reads data from the relational meta-database through the server's web API. The client can also modify the dynamic field rule table as needed after reading it, and store the modified data in the relational database through the web API.

[0033] According to a specific embodiment of the present invention, the display rule field includes: field status id, field usage name, associated original data table name, whether to delete, whether to display, and sorting position in the field rule data table; the storage rule field includes data restrictions and whether it is unique.

[0034] According to a specific embodiment of the present invention, the dynamic field information table includes a dynamic field ID, a dynamic field name, a dynamic field variable name, a dynamic field data type, and dynamic field data. The dynamic field name is in Chinese and is used for display, while the dynamic field variable name is in English and is used in the code.

[0035] According to a specific embodiment of the present invention, the dynamic field rule table is updated in real time, updating the name and order of the dynamic fields.

[0036] According to a specific embodiment of the present invention, the metadata-driven model is integrated with the GIS system to dynamically associate geological attributes with spatial coordinates.

[0037] According to a specific embodiment of the present invention, the geological data management system integrates with the GIS system through a metadata-driven model to achieve dynamic association between geological attributes and spatial coordinates. The specific management method is as follows: 1. Metadata-driven association mechanism (1) Metadata definition association rules: The metadata-driven model predefines the association fields between geological attributes (such as lithology, stratigraphic age, porosity, etc.) and spatial coordinates (latitude and longitude, elevation, etc.) (such as through unique identifiers, spatial topological relationships, etc.) to ensure that attribute data corresponds one-to-one with spatial location.

[0038] (2) Dynamic mapping and updating: When the geological attribute data changes (such as adding borehole data or updating core analysis results), the metadata model automatically triggers the synchronization mechanism with the GIS system. The attribute changes are dynamically mapped to the corresponding spatial coordinate points through a preset interface (such as the OGC standard interface) without manual intervention.

[0039] 2. Spatial coordinate management of GIS systems (1) Spatial data storage and indexing: The GIS system is responsible for managing spatial coordinate data (such as vector data and raster data) and using spatial indexing technology (such as R-tree and quadtree) to optimize coordinate retrieval efficiency and support rapid location of spatial positions associated with geological attributes.

[0040] (2) Visualization and analysis integration: Through the map rendering engine of the GIS system, geological attribute data (such as stratum thickness and mineral grade) are overlaid and displayed with spatial coordinates, supporting spatial analysis functions (such as buffer analysis and overlay analysis), and intuitively presenting the spatial distribution pattern of geological features.

[0041] 3. Implementation methods of dynamic association (1) Real-time interaction and linkage query: When a user clicks on a spatial coordinate point in the GIS interface, the system automatically retrieves the geological attribute data corresponding to that location through metadata association rules; conversely, when querying a geological attribute (such as "sandstone layer"), the GIS system can highlight all spatial areas containing that attribute.

[0042] (2) Data consistency verification: The system has a built-in verification mechanism. When geological attributes or spatial coordinates are updated individually, it automatically checks whether the correlation relationship is conflicted (such as the attribute misalignment caused by coordinate offset), and prompts the abnormality through log recording or alarm to ensure data accuracy.

[0043] According to a specific embodiment of the present invention, through the dynamic correlation between geological attributes and spatial coordinates, the system can produce integrated data results that fuse geological attributes and spatial location, specifically including: 1. Spatialized geological attribute dataset (1) Attribute records with coordinate labels: Each geological attribute data (such as borehole data and geophysical data) is attached with precise spatial coordinate labels to form an attribute value-coordinate key-value pair, such as "Borehole ID: ZK123, Lithology: Granite, Coordinates: (116.4°E, 39.9°N, Altitude 500m)".

[0044] (2) Multi-dimensional related data table: Generates a joint data table containing geological attribute fields (lithology, density, permeability, etc.) and spatial coordinate fields (X / Y / Z axis coordinates, coordinate system parameters), supporting structured query and statistical analysis.

[0045] 2. Spatial analysis results data (1) Spatial distribution thematic map data: Geological attribute spatial distribution maps generated based on associated data, such as “Regional lithology distribution map” and “Mineral resource reserve spatial contour map”. The data format can be exported as GIS compatible shp, GeoTIFF and other formats.

[0046] (2) Spatial statistical indicators: statistical data obtained through correlation analysis, such as "average porosity in a certain area" and "proportion of geological attribute anomalies around the fault zone", which support numerical or graphical output.

[0047] 3. Relationship metadata (1) Association rule log: Records the association logic between geological attributes and spatial coordinates (such as "association by borehole ID" and "association by stratigraphic boundary topology"), update time, operator and other metadata, which are used to trace the historical changes of data association.

[0048] (2) Association quality assessment data: The system automatically calculates association accuracy indicators (such as coordinate matching error and attribute coverage) and generates association quality reports to help users judge the reliability of data.

[0049] According to a specific embodiment of the present invention, the adaptive data storage engine uses a MongoDB sharded cluster to store time-series data for high-frequency monitoring data, wherein the high frequency refers to the sampling frequency being greater than a preset frequency.

[0050] According to a specific embodiment of the present invention, the client reads data from the relational meta-database of the server via a web API through the following process: In step S101, the client initiates a data read request to the server through the server's web API, the server initiates an authentication request to the external service, and the external service authenticates the client and obtains the authentication. Step S102: The server retrieves a data table containing dynamic fields from the relational meta-database; Step S103: The client obtains data containing dynamic fields from the dynamic field rule table through the server's web API; Step S104: The server retrieves the dynamic field rule table of the corresponding data type from the relational meta-database and sends it to the client; In step S105, the client maps the acquired data to the corresponding model object through the dynamic field rule table obtained from the server.

[0051] According to a specific embodiment of the present invention, the client modifies the data of dynamic fields in the relational meta-database of the server through a web API via the following process: Step S201: The client sends a request to the server's web API to retrieve data for a certain type of dynamic field; Step S202: The server retrieves the corresponding type of dynamic field from the dynamic field rule table in the relational metadata database and returns the field rule data table to the client. In step S203, the client modifies the received field rule data table and sends the modified JSON format field rule data table to the server via web API.

[0052] According to a specific embodiment of the present invention, the client stores the modified data in the relational metadata database through the following process: Step S301: The client maps the modified JSON data submitted to the server to the model object in the server that supports the dynamic fields via a web API. Step S302: Check whether the JSON data conforms to the storage rules by retrieving the dynamic field rule table corresponding to the data of the corresponding data type; if it passes the check, it is submitted to the database; otherwise, an exception is thrown.

[0053] According to a specific embodiment of the present invention, adaptive storage engine optimization is further performed, and the specific optimization method is as follows: 1. Intelligent storage selection (1) Frequently used fields are stored separately, while infrequently used fields are stored in a bundle; (2) Numbers and text are compressed using different methods; 2. Handling null values (1) Do not store NULL values; use a flag bit to record them. (2) Special compression for fields with a large number of null values; 3. Automatically adapt to changes (1) The system automatically learns the frequency of field usage; (2) Store hot data quickly and cold data compactly; 4. Hybrid storage format (1) Fixed parts are stored using traditional row and column storage; (2) The changed parts use flexible formats such as JSON / BLOB.

[0054] The optimization effects of the adaptive storage engine are as follows: (1) Storage space is reduced by about half; (2) Faster query speed; (3) It is easier to cope with changes in data structure.

[0055] Simply put, it means allowing the system to automatically select the most suitable storage method for each type of data, avoiding waste caused by a "one-size-fits-all" approach to storage.

[0056] According to a specific embodiment of the present invention, the method further includes optimizing the mapping efficiency between metadata and physical storage to support high-concurrency data writing and querying. The specific optimization method is as follows: (1) Layered metadata: like express sorting center → delivery station, to distribute the pressure; (2) Dynamic compression: Automatically identify field characteristics and select the storage method that saves the most space; (3) Lock-free concurrency: Allocate independent channels for different data to avoid congestion.

[0057] The following problems existed before optimization: (1) The metadata mapping is rigid, and changing the field structure requires a full table lock; (2) Severe preemption during high concurrency leads to a sharp drop in performance; (3) Null values / sparse data occupy space.

[0058] The optimization results in the following ways: (1) Write speed increased by 3 times or more; (2) Storage space is reduced by half; (3) Modifying the field structure does not require system downtime.

[0059] Example 1 This invention provides a geological data management system, comprising: a client, a server, and external services. The server includes a relational metadata database, a NoSQL database, and a web API for accessing the relational metadata database, as well as a dynamic field metadata management module. The dynamic field metadata management module includes a dynamic field configuration module, a metadata-driven model, and an adaptive data storage engine. Any two of the relational metadata database, dynamic field configuration module, metadata-driven model, and adaptive data storage engine can call and access each other. The client accesses, modifies, and stores data in the database with the server through the web API. The external services at least provide authentication for the client. The dynamic field configuration module pre-configures a geological data template library suitable for pumped storage. Using the geological data template library, dynamic fields are defined in the relational meta-database according to the project type. The dynamic fields include: the dynamic field name, data type, association rules with the corresponding original data table in the relational meta-database, dynamic field ID, and dynamic field sequence number. The dynamic values ​​corresponding to the dynamic fields are stored in NoSQL. The metadata-driven model parses the dynamic fields, generates a dynamic field rule table in the relational meta-database according to association rules, describes the dynamic fields using metadata, and stores the metadata of the dynamic fields in the relational meta-database in JSON format. Clients access the dynamic fields in the relational database by accessing the metadata of the dynamic fields. The dynamic field rule table includes a dynamic field information table and a field rule data table. The dynamic field information table includes the data of the dynamic fields, and the field rule data table includes display rule fields and storage rule fields. An adaptive data storage engine, combined with a NoSQL database, dynamically maps the defined dynamic fields to the physical storage layer of the relational meta-database according to association rules. The relational meta-database stores the structured metadata of the dynamic fields and the core business data of the fixed fields. In use, the client reads data from the relational meta-database through the server's web API. The client can also modify the dynamic field rule table as needed after reading it, and store the modified data in the relational database through the web API.

[0060] Example 2 This invention provides a geological data management system, comprising: a client, a server, and external services. The server includes a relational metadata database, a NoSQL database, and a web API for accessing the relational metadata database, as well as a dynamic field metadata management module. The dynamic field metadata management module includes a dynamic field configuration module, a metadata-driven model, and an adaptive data storage engine. Any two of the relational metadata database, dynamic field configuration module, metadata-driven model, and adaptive data storage engine can call and access each other. The client accesses, modifies, and stores data in the database with the server through the web API. The external services at least provide authentication for the client. The dynamic field configuration module pre-configures a geological data template library suitable for pumped storage. Using the geological data template library, dynamic fields are defined in the relational meta-database according to the project type. The dynamic fields include: the dynamic field name, data type, association rules with the corresponding original data table in the relational meta-database, dynamic field ID, and dynamic field sequence number. The dynamic values ​​corresponding to the dynamic fields are stored in NoSQL. The metadata-driven model parses the dynamic fields, generates a dynamic field rule table in the relational meta-database according to association rules, describes the dynamic fields using metadata, and stores the metadata of the dynamic fields in the relational meta-database in JSON format. Clients access the dynamic fields in the relational database by accessing the metadata of the dynamic fields. The dynamic field rule table includes a dynamic field information table and a field rule data table. The dynamic field information table includes the data of the dynamic fields, and the field rule data table includes display rule fields and storage rule fields. An adaptive data storage engine, combined with a NoSQL database, dynamically maps the defined dynamic fields to the physical storage layer of the relational meta-database according to association rules. The relational meta-database stores the structured metadata of the dynamic fields and the core business data of the fixed fields. In use, the client reads data from the relational meta-database through the server's web API. The client can also modify the dynamic field rule table as needed after reading it, and store the modified data in the relational database through the web API.

[0061] Furthermore, the display rule fields include: field status id, field usage name, associated original data table name, whether to delete, whether to display, and sorting position in the field rule data table; the storage rule fields include data restrictions and whether it is unique.

[0062] Furthermore, the dynamic field information table includes dynamic field ID, dynamic field name, dynamic field variable name, dynamic field data type, and dynamic field data. The dynamic field name is in Chinese and is used for display, while the dynamic field variable name is in English and is used in the code.

[0063] Furthermore, the dynamic field rule table is updated in real time, updating the name and order of the dynamic fields.

[0064] Furthermore, the metadata-driven model is integrated with the GIS system to dynamically associate geological attributes with spatial coordinates.

[0065] Furthermore, the adaptive data storage engine uses a MongoDB sharded cluster to store time-series data for high-frequency monitoring data, where high frequency refers to a sampling frequency greater than a preset frequency.

[0066] Furthermore, the client reads data from the relational metadata database on the server via the web API through the following process: In step S101, the client initiates a data read request to the server through the server's web API, the server initiates an authentication request to the external service, and the external service authenticates the client and obtains the authentication. Step S102: The server retrieves a data table containing dynamic fields from the relational meta-database; Step S103: The client obtains data containing dynamic fields from the dynamic field rule table through the server's web API; Step S104: The server retrieves the dynamic field rule table of the corresponding data type from the relational meta-database and sends it to the client; In step S105, the client maps the acquired data to the corresponding model object through the dynamic field rule table obtained from the server.

[0067] Furthermore, the client modifies the data of dynamic fields in the relational metabase of the server via the web API through the following process: Step S201: The client sends a request to the server's web API to retrieve data for a certain type of dynamic field; Step S202: The server retrieves the corresponding type of dynamic field from the dynamic field rule table in the relational metadata database and returns the field rule data table to the client. In step S203, the client modifies the received field rule data table and sends the modified JSON format field rule data table to the server via web API.

[0068] Furthermore, the client stores the modified data in the relational metadata database through the following process: Step S301: The client maps the modified JSON data submitted to the server to the model object in the server that supports the dynamic fields via a web API. Step S302: Check whether the JSON data conforms to the storage rules by retrieving the dynamic field rule table corresponding to the data of the corresponding data type; if it passes the check, it is submitted to the database; otherwise, an exception is thrown.

[0069] Example 3 This invention provides a geological data management system, implemented through the following design: 1. System Module Composition Table 1. System Module Table

[0070] 2. Database Design (1) Fixed fields (core business data) SQLCREATE TABLE customer ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL, email VARCHAR(100), created_at TIMESTAMP ); (2) Metadata table (stores dynamic field definitions) SQLCREATE TABLE metadata_fields ( id INT PRIMARY KEY AUTO_INCREMENT, entity_type VARCHAR(50) NOT NULL COMMENT 'The associated entity type, such as customer', field_name VARCHAR(50) NOT NULL COMMENT 'Field name, such as hobby', field_label VARCHAR(100) NOT NULL COMMENT 'Display name, such as hobbies', field_type ENUM('string', 'number', 'date', 'boolean') NOT NULL, default_value VARCHAR(255), validation_rules JSON COMMENT 'For example: {"required": true, "maxLength":100}' ); (3) Dynamic value storage table (general key-value pair design) SQLCREATE TABLE customer_ext ( id INT PRIMARY KEY AUTO_INCREMENT, customer_id INT NOT NULL COMMENT 'Associated customer.id', field_name VARCHAR(50) NOT NULL COMMENT 'Associated metadata_fields.field_name', field_value TEXT COMMENT 'Value of dynamic field', FOREIGN KEY (customer_id) REFERENCES customer(id) ); 3. The process of defining dynamic fields Scenario: The administrator adds two dynamic fields through the configuration module: hobbies (string type, required, maximum length 100); membership level (numeric type, default value 1).

[0071] (1) Operation of dynamic field configuration module The administrator fills out a form in the UI, and the configuration module inserts two records into the metadata_fields table: SQL -- Define the field for inserting interests and hobbies INSERT INTO metadata_fields (entity_type, field_name, field_label, field_type, default_value,validation_rules) VALUES ('customer', 'hobby', 'interests', 'string', NULL, '{"required": true,"maxLength": 100}'); -- Insert Member Level Field Definition INSERT INTO metadata_fields (entity_type, field_name, field_label, field_type, default_value,validation_rules) VALUES ('customer', 'member_level', 'member level', 'number', '1', '{"min": 1, "max": 5}'); (2) Metadata-driven model loading When the system starts up or receives a field change notification, it reads the definitions from the metadata_fields table and generates an in-memory metadata object (pseudocode): Python class FieldMeta: def __init__(self, field_name, field_type, rules): self.name = field_name self.type = field_type self.rules = rules # Example of loaded metadata metadata = { "customer": [ FieldMeta("hobby", "string", {"required": True, "maxLength": 100}), FieldMeta("member_level", "number", {"min": 1, "max": 5}) ]} 4. Process of CRUD Dynamic Fields Scenario 1: Adding a Customer (with Dynamic Fields) Request Data: Json{ "name": "Zhang San", "email": "zhangsan@example.com", "hobby": "Swimming", "member_level": 2 } (1)Adaptive Storage Engine Processing 1. Fixed Fields: Write to the customer table SQLINSERT INTO customer (name, email) VALUES ('Zhang San', 'zhangsan@example.com'); 2. Dynamic Fields: Write to the customer_ext table after verification according to metadata SQL-- Assume the generated customer.id is 1001 INSERT INTO customer_ext (customer_id, field_name, field_value) VALUES (1001, 'hobby', 'Swimming'), (100, 'member_level', '2'); (2)Key Logic 1. The engine checks through metadata whether hobby is a non-empty string and its length ≤ 100.

[0072] 2. Check whether member_level is a number and within the range of 1 to 5.

[0073] [[ID=4)]]Scenario 2: Querying Customer Information Request: GET / customer / 1001 (1)Adaptive Storage Engine Processing 1. Read fixed fields from the customer table: SQLSELECT id, name, email FROM customer WHERE id = 1001;[[ID=)6]] ] 2. Jointly query dynamic fields from the customer_ext table: SQLSELECT field_name, field_value FROM customer_ext WHERE customer_id= 1001; 3. Merge the results and return them: Json{ "id": 1001, "name": "Zhang San", "email": "zhangsan@example.com", "hobby": "swimming" "member_level": 2 } (2) Key Logic The engine converts the string value of member_level into a numeric type based on the metadata.

[0074] Scenario 3: Modifying dynamic fields Request: Update hobby to "Mountain Climbing" Json{"hobby": "mountain climbing"} (1) Adaptive storage engine processing 1. Verify whether the new value conforms to the metadata rules (length ≤ 100).

[0075] 2. Update the customer_ext table: SQLUPDATE customer_ext SET field_value = 'mountain climbing' WHERE customer_id = 1001 AND field_name = 'hobby'; 5. Collaboration flowchart for each module The collaboration process of each module is as follows: Figure 5 As shown.

[0076] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention are included within the scope of protection of the present invention.

Claims

1. A geological data management system, characterized in that, include: The system comprises a client, a server, and external services. The server includes a relational metadata database, a NoSQL database, and a web API for providing access to the relational metadata database. It also includes a dynamic field metadata management module, which comprises a dynamic field configuration module, a metadata-driven model, and an adaptive data storage engine. Any two of the relational metadata database, the dynamic field configuration module, the metadata-driven model, and the adaptive data storage engine can call and access each other. The client accesses, modifies, and stores data in the database with the server through the web API service interface; the external service at least provides authentication for the client. The dynamic field configuration module pre-configures a geological data template library suitable for pumped storage. Using the geological data template library, dynamic fields are defined in the relational meta-database according to the project type. The dynamic fields include: the dynamic field name, data type, association rules with the corresponding original data table in the relational meta-database, dynamic field ID, and dynamic field sequence number. The dynamic values ​​corresponding to the dynamic fields are stored in NoSQL. The metadata-driven model parses the dynamic fields, generates a dynamic field rule table in the relational meta-database according to association rules, describes the dynamic fields using metadata, and stores the metadata of the dynamic fields in the relational meta-database in JSON format. Clients access the dynamic fields in the relational database by accessing the metadata of the dynamic fields. The dynamic field rule table includes a dynamic field information table and a field rule data table. The dynamic field information table includes the data of the dynamic fields, and the field rule data table includes display rule fields and storage rule fields. An adaptive data storage engine, combined with a NoSQL database, dynamically maps the defined dynamic fields to the physical storage layer of the relational meta-database according to association rules. The relational meta-database stores the structured metadata of the dynamic fields and the core business data of the fixed fields. In use, the client reads data from the relational meta-database through the server's web API. The client can also modify the dynamic field rule table as needed after reading it, and store the modified data in the relational database through the web API.

2. The geological data management system according to claim 1, characterized in that, The display rule fields include: field status id, field usage name, associated original data table name, whether to delete, whether to display, and sorting position in the field rule data table. The storage rule fields include data restrictions and whether it is unique.

3. The geological data management system according to claim 1, characterized in that, The dynamic field information table includes dynamic field ID, dynamic field name, dynamic field variable name, dynamic field data type, and dynamic field data. The dynamic field name is in Chinese and is used for display, while the dynamic field variable name is in English and is used in the code.

4. The geological data management system according to claim 1, characterized in that, The dynamic field rule table is updated in real time, updating the name and order of the dynamic fields.

5. The geological data management system according to claim 1, characterized in that, The metadata-driven model is integrated with the GIS system to dynamically associate geological attributes with spatial coordinates.

6. The geological data management system according to claim 1, characterized in that, The adaptive data storage engine uses a MongoDB sharded cluster to store time-series data for high-frequency monitoring data, where high frequency refers to a sampling frequency greater than a preset frequency.

7. The geological data management system according to claim 1, characterized in that, The client reads data from the relational metadata database on the server via the web API through the following process: In step S101, the client initiates a data read request to the server through the server's web API, the server initiates an authentication request to the external service, and the external service authenticates the client and obtains the authentication. Step S102: The server retrieves a data table containing dynamic fields from the relational meta-database; Step S103: The client obtains data containing dynamic fields from the dynamic field rule table through the server's web API; Step S104: The server retrieves the dynamic field rule table of the corresponding data type from the relational meta-database and sends it to the client; In step S105, the client maps the acquired data to the corresponding model object through the dynamic field rule table obtained from the server.

8. The geological data management system according to claim 1, characterized in that, The client modifies the data of dynamic fields in the relational metabase database on the server through the web API, which is achieved through the following process: Step S201: The client sends a request to the server's web API to retrieve data for a certain type of dynamic field; Step S202: The server retrieves the corresponding type of dynamic field from the dynamic field rule table in the relational metadata database and returns the field rule data table to the client. In step S203, the client modifies the received field rule data table and sends the modified JSON format field rule data table to the server via web API.

9. The geological data management system according to claim 1, characterized in that, The client stores the modified data in the relational metadata database through the following process: Step S301: The client maps the modified JSON data submitted to the server to the model object in the server that supports the dynamic fields via a web API. Step S302: Check whether the JSON data conforms to the storage rules by retrieving the dynamic field rule table corresponding to the data of the corresponding data type; if it passes the check, it is submitted to the database; otherwise, an exception is thrown.

Images