An embedded rule-based data sharing method and system

Abstract

The application provides a kind of data sharing method and system based on embedded rule, extracts entity under each subject domain and the association between entities, constructs entity relationship model, and embeds data constraint rules in entity relationship model, maps entity relationship model into physical data model, after extracting the business data required by customer, the rules embedded in physical data model can be directly called to check data. Based on the traditional mode, the business rules are scattered in the application code, database trigger or artificial experience, it is difficult to extract and reuse. Through systematic analysis, the core business rules (verified by pilot) are coded into the entity relationship model, and the data is issued together. After receiving, customers can directly call these preset rules for data verification, without starting from scratch to build a verification system, significantly reducing implementation costs.

Description

Technical Field

[0001] This invention relates to the field of data verification, and more specifically, to a data sharing method and system based on embedded rules. Background Technology

[0002] In the field of natural resource management, data sharing between ministerial-level units and provincial-level units is a routine and frequent core business operation. For a long time, this process has primarily relied on traditional ETL (Extract-Transform-Load) tools to extract, transform, and load data according to administrative divisions and specific business types. While this model appears efficient, it actually suffers from deep-seated structural flaws, severely impacting the efficiency and quality assurance of data application at the receiving end.

[0003] This traditional data-sharing method can be likened to "parts delivery": ministerial-level units are like large manufacturing plants with complete production lines and product design blueprints; while provincial-level units are like downstream factories that need to assemble equipment. During data transmission, ministerial-level units only package isolated database tables (such as land supply tables, temporary land use project tables, land transaction records, etc.) as "parts" and send them to provincial-level units, similar to disassembling a complex piece of equipment into screws, circuit boards, casings, and other components and mailing them separately.

[0004] However, the key issue is that the "assembly instructions" were not shipped with the "parts." Here, the "assembly instructions" refer to a series of business rule validation logics that support the correct use of the data.

[0005] These rules are the core safeguards for ensuring data compliance, integrity, and availability. However, in existing ETL processes, these rules are not systematically encapsulated or transmitted, forcing provincial units to expend significant human and material resources to re-examine business logic, rebuild verification mechanisms, and even reverse-engineer the original system's operational logic after receiving the "parts." This not only prolongs the data preparation cycle but also greatly increases the risk of data misuse due to misunderstandings.

[0006] More seriously, a significant amount of cross-table relationships are lost during transmission. Taking the typical business chain of "land supply → transaction → public announcement" as an example, these three stages correspond to different database tables, and the dependencies between them (such as the land supply plan number serving as a primary key across multiple tables) constitute a complete business flow. However, in traditional ETL extraction, these tables are often exported independently, and the topological connections between them are not preserved. This is equivalent to disassembling and repackaging multiple parts that should be working in tandem, making it difficult for provincial units to reconstruct their collaborative mechanisms.

[0007] Furthermore, as natural resource management becomes more refined and spatialized, the importance of spatial context information is increasingly prominent. For example, determining whether a plot of land is located within an ecological protection red line or overlaps with permanent basic farmland relies not only on attribute data but also on its precise spatial location and its topological relationship with other geographical elements. However, current data sharing methods generally weaken the expression of spatial information, making it difficult for recipients to effectively conduct spatial analysis and compliance reviews.

[0008] In summary, the current data sharing model faces three core pain points:

[0009] (1) Missing rules: Key business rules were not transmitted synchronously with the data, and provincial units had to repeatedly build verification systems, resulting in a waste of resources;

[0010] (2) Loss of composite relationships: The logical connection between cross-business tables is broken, resulting in data semantic breakage and increased application difficulty;

[0011] (3) Context weakening: Contextual information such as spatial location, temporal validity, and inter-topic linkage is not fully preserved, affecting the interpretability and usability of the data.

[0012] These issues collectively result in provincial-level units typically experiencing application preparation cycles of several weeks or even months after receiving data, and the data quality pass rate consistently falls below expectations. According to pilot statistics, some provinces, after receiving data from the ministry level, need to invest a significant amount of work in data cleaning and rule reconstruction, leading to an insufficient first-time data pass rate.

[0013] Therefore, there is an urgent need for a new data sharing mechanism that can transmit business rules, related logic and spatial context while ensuring data integrity, so as to realize a paradigm upgrade from "parts delivery" to "complete machine delivery". Summary of the Invention

[0014] This invention addresses the technical problems existing in the prior art by providing a data sharing method and system based on embedded rules, overcoming the resource waste caused by the separation of existing business rules and data.

[0015] According to a first aspect of the present invention, a data sharing method based on embedded rules is provided, comprising:

[0016] The source database system is systematically deconstructed to identify the core business modules that constitute the shared entity, and the logical relationships between the core business modules are clarified to form a relational topology map that shows the overall architecture of the system.

[0017] Extract all key entities from the source database system, standardize the definition of the attributes of each key entity, and perform preliminary quality checks on the attribute data of each key entity.

[0018] Based on the relationship topology graph, the relationships between key entities are extracted, and the attribute data of each key entity is combined to construct an entity relationship model. Multi-level data constraint rules are then embedded in the entity relationship model.

[0019] The constructed entity relationship model is mapped to a physical data model, and the business rules are embedded in the physical data model;

[0020] Based on the customer's request, the relevant business dataset is retrieved from the physical data model, and the business rules embedded in the physical data model are used to perform batch rule verification on the business dataset to generate a "factory inspection report". The business dataset and the factory inspection report are embedded in a data package, and the data package and the rule metadata XML file are delivered to the customer together.

[0021] According to a second aspect of the present invention, a data sharing system based on embedded rules is provided, comprising:

[0022] The first building module is used to systematically deconstruct the source database system, identify the core business modules that constitute the shared entity, clarify the logical relationships between the core business modules, and construct a relationship topology map that shows the overall architecture of the system.

[0023] The extraction module is used to extract all key entities from the source database system, standardize the definition of the attributes of each key entity, and perform preliminary quality checks on the attribute data of each key entity.

[0024] The second construction module is used to extract the association relationships between key entities based on the relationship topology graph, and to construct an entity relationship model by combining the attribute data of each key entity, and to embed multi-level data constraint rules into the entity relationship model.

[0025] An embedding module is used to map the constructed entity relationship model to a physical data model and embed business rules into the physical data model;

[0026] The data delivery module is used to find relevant business datasets from the physical data model according to customer requests, perform batch rule verification on the business datasets using the business rules embedded in the physical data model, generate a "factory quality inspection report", embed the business datasets and the factory quality inspection report into a data package, and deliver the data package and rule metadata XML file together to the customer.

[0027] This invention provides a data sharing method and system based on embedded rules. Addressing the problem in traditional models where business rules are scattered across application code, database triggers, or manual experience, making them difficult to extract and reuse, this invention systematically organizes and encodes up to 92% of core business rules (verified through pilot testing) into the entity relationship model, distributing them along with the data. Upon receiving the data, provincial-level units can directly invoke these pre-defined rules for data verification, eliminating the need to build a verification system from scratch and significantly reducing implementation costs. Attached Figure Description

[0028] Figure 1 A flowchart of a data sharing method based on embedded rules is provided in one embodiment of the present invention;

[0029] Figure 2 This is an overall architecture diagram of a data sharing method based on embedded rules according to an embodiment of the present invention;

[0030] Figure 3 This is a structural block diagram of a data sharing system based on embedded rules, provided as an embodiment of the present invention. Detailed Implementation

[0031] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. In addition, the technical features of the various embodiments or individual embodiments provided by the present invention can be arbitrarily combined with each other to form feasible technical solutions. Such combinations are not constrained by the order of steps and / or structural composition patterns, but must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed by the present invention.

[0032] To address the pain points mentioned in the background technology, this invention proposes a fundamental technological innovation: embedding a business rule verification mechanism into the Entity-Relationship Model (ERM) to form a "smart assembly specification" with self-checking capabilities, and driving the entire data sharing and extraction process through this model.

[0033] The so-called "intelligent assembly specification" refers to a composite metadata carrier that, based on the traditional entity-relationship model, not only describes the structure of data (entities, attributes, relationships) but also solidifies business rules, constraints, and verification logic. This makes it a comprehensive metadata carrier integrating data structure definition, business semantic expression, and quality control. This "specification" is not only a blueprint for data organization but also a guardian of data quality.

[0034] The core innovation of this invention is reflected in four aspects:

[0035] 1. Rules and data are transmitted simultaneously, eliminating reconstruction costs.

[0036] In traditional models, business rules are scattered across application code, database triggers, or manual experience, making them difficult to extract and reuse. This invention systematically organizes and encodes up to 92% of core business rules (verified through pilot testing) into the entity relationship model, distributing them along with the data. Upon receiving this data, provincial-level units can directly invoke these pre-defined rules for data verification, eliminating the need to build a verification system from scratch and significantly reducing implementation costs.

[0037] For example, regarding the rule that "the temporary land use period shall not exceed two years," provincial-level units no longer need to write their own SQL judgment statements. Instead, ministerial-level units predefine a time-limited constraint in the model and implement automated checks through triggers or CHECK constraints (CHECK is a column-level / table-level constraint). When provincial-level units load data, the system can automatically execute this rule and provide real-time feedback on any anomalies.

[0038] 2. Ensure the integrity of the combination relationship and restore the business context.

[0039] To address the issue of broken cross-table relationships, this invention introduces a "relationship topology graph" technique, which explicitly models the entity relationships between different subject areas in the form of a graph structure. For example, "Land Reserve Project" and "Land Use Control Approval" are connected through "Approval Document Number," and "Land Supply Plan" and "Land Transaction" form a chain dependency through "Plan Number."

[0040] These relationships are not only explicitly defined in the logical model, but also solidified at the physical implementation level through foreign key constraints, cascading operations, and other methods to ensure that they are not broken during data extraction. The recipient can quickly understand the collaborative logic between the various "parts" based on this graph, thereby reconstructing the complete "business assembly line".

[0041] 3. Supports dynamic expansion to adapt to new business needs.

[0042] Natural resource management is constantly evolving, with new approval processes, new land use types, and new regulatory requirements emerging one after another. To address this, the present invention designs a metadata-driven relation extension mechanism, namely a "relationship type library".

[0043] This mechanism allows for the addition of new relationships between entities through configuration without modifying the underlying database structure. For example, when a new business scenario of "temporary land use renewal" arises, simply adding a record to the relationship metadata table describing the relationship between the "original approval form" and the "renewal application form" will allow the system to automatically identify and support relevant queries and validations.

[0044] This "zero-code extension" capability greatly enhances the system's flexibility and adaptability, avoiding frequent database reconstructions due to business changes.

[0045] 4. Implement joint verification of spatial and attribute data to accurately pinpoint data location.

[0046] Considering the highly spatial attributes of natural resource data, this invention deeply integrates the PostGIS spatial engine, endowing the ERM model with powerful spatial processing capabilities. All spatial entities (such as land parcels, administrative regions, and ecological red lines) are stored using standard geometric fields (GEOMETRY type) and uniformly adopt the geodetic coordinate system (EPSG:4490).

[0047] Based on this, the model incorporates various spatial constraint rules, such as:

[0048] The ST_Within(geom, admin_boundary) function ensures that each parcel is located within its administrative boundary. Here, the spatial judgment function ST_Within determines whether the parcel geometry geoom falls completely within its administrative boundary admin_boundary.

[0049] The ST_Intersects(geom, ecological_redline) function is used to detect whether there is any illegal occupation of the ecological protection zone. The intersection judgment function ST_Intersects determines whether the geometry of the plot (geom) intersects with the ecological protection zone red line (ecological_redline), thus detecting whether there is illegal occupation.

[0050] The actual area is calculated using the area function ST_Area(geom) and compared with the declared area to prevent false reporting.

[0051] These spatial rules, combined with attribute rules (such as usage restrictions and approval status), form a "joint verification mechanism," truly achieving precise dual positioning of "parts" in both physical space and business logic.

[0052] Figure 1 The following is a flowchart illustrating a data sharing method based on embedded rules according to an embodiment of the present invention, as shown in the figure. Figure 1 and Figure 2 As shown, the system includes the following steps:

[0053] Step 1: Systematically deconstruct the source database system, identify the core business modules that constitute the shared entity, clarify the logical relationships between the core business modules, and form a relational topology map that shows the overall architecture of the system.

[0054] Understandably, to achieve high-quality data sharing, it is essential to first clearly define the business boundaries and data scope of the sharing.

[0055] The core task of this step is to systematically deconstruct the natural resource management system, identify several core business modules (subject areas) that constitute the main body of data sharing, and clarify the logical relationships within and between each module. The specific implementation steps are as follows:

[0056] Step 11: Based on the natural resource management functions, divide the business into multiple subject areas and assign a unique identifier to each subject area.

[0057] Specifically, based on the functions of natural resource management, the business within the natural resource management system is divided into several thematic domains, such as "Land Market" (TDSC), "Land Use Control" (YTGZ), "Land Reserves" (TDCB), and agricultural facility land (SSNYD). Each thematic domain is assigned a unique identifier to facilitate subsequent tracking and management.

[0058] Step 12: Analyze the database structure and data dictionary of the source business system, identify the key business objects under each subject area and their sequential relationship in the business flow, so as to further subdivide each subject area into indivisible atomic business units.

[0059] Specifically, by deeply analyzing the database structure and data dictionary of the source business system, key business objects (such as "supply plan table", "land supply scheme table", and "land transaction table") and their sequential relationships in the business flow are identified. For example, in the land market, a typical business chain is: "supply plan → land supply scheme → land transaction → public announcement". This chain is the "transmission link" of data organization.

[0060] Based on the identification method described above, each subject area is further subdivided into indivisible "atomic business units." For example, the "land market" can be broken down into seven basic units: "land sources," "supply plans," "land supply schemes," "land supply announcements," "transaction information," "public disclosure status," and "contract filing." Each atomic business unit corresponds to a core database table, forming the basic granularity for subsequent modeling.

[0061] Step 13: Identify the data linkage points between data tables in different subject areas and construct the association relationships between data tables in different subject areas.

[0062] Specifically, this involves identifying data linkage points between data tables in different thematic domains. For example, the zz_xmjbqk (basic information on agricultural land conversion) table in the "Land Use Control" module is connected to the t_crgy_kz (transfer information) table in the "Land Market" module through the "electronic supervision number" field; the t_zjgg_proj_info (project approval information) table in the "Land Increase / Decrease Linkage" module interacts with the td_zd_dk (land parcel information) table in the "Land Market" module through spatial overlay relationships. These cross-domain connections constitute "multi-component collaboration scenarios" in complex business scenarios.

[0063] Step 14: Construct and display the relationship topology map of the overall system architecture based on the list of subject domains, the mapping table of atomic business units under each subject domain, and the association matrix of data tables under different subject domains.

[0064] Specifically, step 14 ultimately outputs a structured list of subject domains, a business unit mapping table, and a cross-subject association matrix, forming a relational topology map. This is equivalent to drawing a "blueprint for the overall assembly of intelligent devices" for the entire data sharing project. It clearly demonstrates the overall architecture of the system, the division of functional modules, and the connection methods between modules, providing a top-level design basis for subsequent modeling.

[0065] Step 2: Extract all key entities from the source database system, standardize the definition of the attributes of each key entity, and perform a preliminary quality check on the attribute data of each key entity.

[0066] Understandably, after clarifying the overall architecture in step 1, this step identifies the "basic components" that constitute the system, namely the core business entities, and formulates unified technical specifications for them.

[0067] The goal of this step is to extract all key entities from the source system, standardize the attributes of each key entity, and complete preliminary data quality checks, especially the validity verification of spatial data. The specific implementation steps are as follows:

[0068] Step 21: Scan the source database using an automated script to extract the structural information of all data tables. The structural information includes the data table name, field name, field data type, field data length, and whether the field data is empty, forming a preliminary "parts box drawing".

[0069] Step 22: Select the data tables that carry the core business semantics as the carriers of key entities, and define the attribute data of each key entity.

[0070] Understandably, tables that carry the core business semantics are selected from various tables in the source database to serve as entity carriers. For example, the "t_crgy_kz" table represents the "land supply and transfer" entity, the "t_hbgy_kz" table represents the "land supply and allocation" entity, and the "td_gyzd" table represents the "land parcel" entity. Each entity is treated as an independent "part" with a clear identity and function.

[0071] The attributes of each selected entity are standardized. First, the entity is identified by determining the primary key field (e.g., zd_guid) and strict coding rules are established (e.g., "administrative division code + year + serial number") to ensure uniqueness and traceability.

[0072] Next, spatial positioning is performed to identify the geometric fields of each entity (such as the land parcel geom), unify its coordinate reference system to EPSG:4490 (geocentric coordinate system), and standardize the geometric description format to WKT (Well-Known Text) or WKB (Well-Known Binary), laying the foundation for spatial operations.

[0073] Finally, business attribute processing is performed: parsing field constraints (such as NOT NULL, CHECK) and establishing associations with the standard data dictionary. For example, the "Land Category Code" field needs to reference the code table in the standard "Classification of Current Land Use" (GB / T 21010-2017) to ensure that the value is valid.

[0074] Step 23: Perform basic verification on all spatial entities and finally generate the entity-attribute matrix.

[0075] Among them, three basic checks are performed on all spatial entities.

[0076] (1) Geometric validity: Call the error checking function ST_IsValid(geom) to check for topological errors such as self-intersection and broken lines;

[0077] (2) Coordinate system consistency: Verify that the SRID (spatial reference ID) of all spatial fields is consistent with 4490;

[0078] (3) Boundary closure: For areal features (such as land parcels), check whether their boundaries form a closed loop to prevent the appearance of "open polygons".

[0079] This step produces an authoritative entity-attribute matrix, equivalent to a "precision parts specification library." It records in detail the model number (field name), material requirements (data type), dimensional tolerances (length / precision), installation requirements (mandatory), allowable range (CHECK constraint), and spatial coordinate information of each "part," providing standardized input for subsequent modeling.

[0080] Step 3: Based on the relationship topology graph, extract the relationships between key entities, and combine the attribute data of each key entity to construct an entity relationship model, and embed multi-level data constraint rules into the entity relationship model.

[0081] Understandably, once the "parts" and "specifications" are in place, the next step is to design the "assembly process" between them, that is, the relationship between the entities, and to set "safety thresholds" and "process standards" for key assembly points.

[0082] The core of this step is to construct a high-fidelity Entity-Relationship Model (ERM) and embed multi-level data constraint rules within it to ensure the correctness of the data in terms of structure, logic, and space. The specific implementation steps are as follows:

[0083] Step 31: Analyze the foreign key relationships in the database, determine the connection paths between different data tables, extract the association relationships between key entities, and construct an entity relationship model.

[0084] Specifically, analyze the foreign key relationships in the database to clarify the connection paths between different data tables. For example, t_gyjh.gyjh_guid→td_gyjh_zd.zd_guid represents a "1:N" relationship (one supply plan can correspond to multiple land parcel information).

[0085] Identify and model three basic relation types:

[0086] 1:1 (one-to-one): such as "transaction records" and "public information";

[0087] 1:N (one-to-many, N is a natural number): such as "supply plan" and "land supply scheme";

[0088] N:M (many-to-many, where N and M are both natural numbers): such as "land source" and "supply plan" (one source can be used for multiple plans, and one plan can also contain multiple sources).

[0089] Based on the connection paths between different data tables, the relationships between different entities are obtained in order to construct an entity relationship model.

[0090] Step 32: Design constraint rules for database tables and key entities to form a constraint rule set. The constraint rule set includes spatial constraints, time constraints, and logical constraints. Embed the constraint rule set into the entity relationship model.

[0091] Understandably, constraint rules are designed for database tables and key entity data. These constraints primarily include spatial constraints, time-related constraints, and logical constraints.

[0092] Spatial constraints: Geographic rules are implemented using PostGIS functions. For example, the spatial determination function ST_Within ensures that each piece of land is within its administrative region; the boundary contact function ST_Touches or the partial intersection function ST_Overlaps controls the boundary relationships between adjacent plots.

[0093] Time constraints: Use database triggers to limit the business time window. For example, when inserting a "temporary land use" record, if the start date to end date exceeds two years, an exception is triggered to prevent illegal data from being entered into the database.

[0094] Logical constraints: Complex business logic is implemented through CHECK constraints or stored procedures. For example, "converting farmland to construction land" must be allowed; otherwise, the change should be rejected.

[0095] Step 33: Create a "relationship metadata table" to store the source table, target table, related fields, and relationship types.

[0096] Specifically, a "relation metadata table" (relation_metadata) is created to store information such as the source table, target table, related fields, and relationship types. This table supports dynamically adding new relationships through the configuration interface without modifying the database structure, achieving "zero-code expansion".

[0097] The outcome of this step is a complete entity-relationship model definition file, constraint rule set, and relation metadata table, equivalent to an "assembly process card" and a "safety operation manual." It not only specifies how parts are connected, but also clarifies which operations are prohibited and which states are dangerous, fundamentally improving the intrinsic quality of the data.

[0098] Step 4: Map the constructed entity relationship model to a physical data model, and embed the business rules into the physical data model.

[0099] Understandably, the entity-relationship model constructed in step 3 primarily focuses on the logical relationships between entities. After the logical model is designed, it needs to be transformed into a physical database structure that can run efficiently in a production environment. This process is akin to building "custom-made tooling fixtures" and "automated production lines" for manufacturing equipment, with the goal of improving data access efficiency and system stability.

[0100] The key to this step lies in performance optimization and automated deployment. The specific implementation steps are as follows:

[0101] Step 41: Map the logical entities in the entity relationship model to physical tables, map the attribute data of the logical entities to fields, and specify the data type of the fields.

[0102] Specifically, logical entities in the entity-relationship model are mapped to physical tables (e.g., the "Land Supply" entity → t_crgy_kz table), attributes are mapped to fields, and precise data types are specified (e.g., VARCHAR(18) for fixed-length encoding (text type that can store up to 18 characters), NUMERIC(12,2) for amount (total length of significant digits, with 2 decimal places)). Spatial fields are declared as GEOMETRY(POLYGON, 4490) type (which can only store polygon graphics in the CGCS2000 coordinate system) to ensure spatial operation compatibility.

[0103] Step 42: Create a GiST index for each spatial field, a composite B-Tree index for combinations of high-frequency query fields, and a BRIN (Block Range Index) index for each time interval field.

[0104] Understandably, creating high-performance indexes for each field in the mapped physical table mainly includes:

[0105] Fast spatial location: Create a GiST (Generalized Search Tree) index for the spatial field and set the fill factor to 90% to significantly improve the efficiency of spatial queries (such as "find all industrial land in a county").

[0106] Accelerated queries with combined conditions: Create composite B-Tree indexes for combinations of frequently queried fields (such as region code + start date + land use type) to reduce full table scans.

[0107] Efficient retrieval of time ranges: Using BRIN indexes on time range fields (such as the validity period start and end date range field valid_periodDATERANGE) is suitable for data archiving and querying with large time spans.

[0108] Step 43: Automatically generate DDL scripts based on the mapped physical tables and fields. The DDL scripts include table creation statements, index definitions, foreign key constraints, and cascading delete / update statements.

[0109] Step 44: Construct the physical data model by executing the DDL script.

[0110] Understandably, based on the physical tables and fields mapped above, a DDL (Data Definition Language) script is automatically generated on the development side, containing table creation statements, index definitions, foreign key constraints, cascading deletes / updates, and other "linked security mechanisms." This DDL script can be executed with a single click in the target database, quickly building a high-performance physical data model.

[0111] This step produces a set of executable DDL scripts, essentially the blueprints for a "high-performance automated assembly line." It ensures the smoothness and responsiveness of subsequent data processing flows, providing solid technical support for large-scale data sharing.

[0112] After constructing the physical data model, business rules are embedded into it. It is understood that this invention adopts a layered embedding architecture, integrating business rules into the database model in different forms to form a multi-layered self-checking system. The specific implementation steps are as follows:

[0113] Step 45: Configure business rules in a layered embedded architecture. The business rules include structural constraint rules, business logic layer coding rules, and cross-table consistency verification rules.

[0114] Understandably, the business rules of the physical data model mainly include structural layer constraint rules, business logic layer coding rules, and cross-table consistency verification rules. The following sections introduce several different types of business rules:

[0115] (1) Implementation of structural layer constraints (basic specification check).

[0116] The most basic quality control is equivalent to "parts must be installed correctly and no parts can be missing". This includes things like forcing key fields to be NOT NULL, setting unique indexes to prevent duplicate coding, and defining simple numerical ranges (such as supply_area > 0).

[0117] 2. Business logic layer coding (complex assembly logic).

[0118] Write PL / pgSQL stored procedures to encapsulate complex status checks. For example, when a new record for "farmland converted to construction land" is added, the program automatically checks whether its approval level meets the requirements; if not, it throws an exception.

[0119] Deploy database triggers to perform real-time validation the moment data changes.

[0120] Integrate spatial functions to determine geographic rules. For example, use the area function ST_Area(NEW.geom) to get the area of ​​a new plot of land (NEW.geom); if it is less than the minimum allowed value, it is rejected from being added to the database.

[0121] 3. Cross-table consistency check (cross-part box consistency).

[0122] Establish a "rule_repository table" to centrally manage the metadata (ID, name, target table, SQL logic, error code) of all validation rules.

[0123] Enable asynchronous verification using message queues (such as Kafka or RabbitMQ) to avoid blocking the main thread under high concurrency. For example, coordinating the verification of whether the "land transaction amount" and "contract amount" are consistent involves cross-database queries between two tables.

[0124] Based on the business rules embedded in the physical data model, a "real-time quality inspection report" is generated, recording the results of each verification, including passed items, failed items, and specific error reasons.

[0125] Step 46: Embed the configured business rules into the physical data model.

[0126] Understandably, if the business rules configured in step 45 are embedded into the physical data model, they can be invoked later.

[0127] Step 47: Generate a lightweight rule metadata XML file for all business rules. The rule metadata XML file includes the rule ID, scope, validation logic fragment, expected output, and error code.

[0128] Understandably, all business rules embedded in the physical data model generate lightweight metadata description files (XML format). The XML files contain rule IDs, scopes, validation logic fragments, expected outputs, and error codes.

[0129] This XML file is distributed along with the physical data model, serving as a kind of "intelligent diagnostic manual" for provincial units to reuse in their local environments.

[0130] The final output of this step is a physical data model with self-checking capabilities, along with a corresponding rule metadata XML file. This enables the data to "self-verify" from the very beginning of its generation, greatly improving the data's credibility and usability.

[0131] Step 5: Based on the customer's request, find the relevant business dataset from the physical data model, and use the business rules embedded in the physical data model to perform batch rule verification on the business dataset to generate a "factory quality inspection report". Embed the business dataset and the factory quality inspection report into a data package, and attach the data package and the rule metadata XML file together and deliver it to the customer.

[0132] Understandably, the final stage of this invention is the delivery of the completed "intelligent assembly" to the customer. This is not merely a simple data export, but an intelligent and verifiable whole-machine delivery process. The specific implementation steps are as follows:

[0133] Step 61: Receive a JSON format request from the client, which includes the subject, administrative region, and time range.

[0134] Understandably, the system receives JSON requests from clients, parses the requests, and clarifies the required topics (e.g., "land market"), administrative divisions (e.g., "Sichuan Province"), time ranges, and other conditions.

[0135] Step 62: Parse the topic identifier in the request, dynamically query the association paths of all entities under the topic domain corresponding to the topic identifier from the "relationship metadata table", and automatically generate an SQL query plan containing all necessary JOIN conditions.

[0136] Understandably, based on the customer's request, the system locates the relevant business tables and automatically constructs multi-table join queries based on the entity relationship model. This process is not a simple table join, but rather intelligent navigation based on a "relationship topology graph." When a customer request is received, the system parses the topic identifier in the request and dynamically queries the "relationship metadata table" to find the relationship paths of all entities under the corresponding topic domain, automatically generating a complete SQL query plan containing all necessary JOIN conditions. For example, when requesting "land market" data, the system can automatically construct a complete query chain from supply plans to land supply schemes to transaction information, ensuring that all related data is captured completely and at once.

[0137] Step 63: Based on the SQL query plan, find the relevant business dataset from the physical data model.

[0138] Understandably, the first stage involves joint spatial and attribute data extraction: executing the intelligent SQL query plan generated in step 62 to extract the business dataset that meets the conditions from the source database. This business data includes both business spatial data and business attribute data. This process ensures data integrity and relevance, avoiding data fragmentation caused by independent extraction in traditional ETL.

[0139] Step 64: Using the business rules embedded in the physical data model, perform structural layer checks, business logic layer checks, spatial joint checks, and cross-table consistency checks on the business dataset according to the structural layer constraint rules, business logic layer coding rules, and cross-table consistency check rules, and generate a factory quality inspection report. The factory quality inspection report records all rules that passed and failed, as well as the specific data records and error reasons for those that failed.

[0140] Understandably, the second phase initiates a "pre-installation self-check" on the business dataset captured in the first phase: immediately after data extraction and before packaging, it invokes the pre-built "intelligent chip system" (i.e., embedded business rules) in the physical data model to perform batch rule verification on the entire captured business dataset. This includes:

[0141] Structure layer checks: Verify whether key fields are empty and whether primary keys are duplicated.

[0142] Business logic layer checks: Verify complex rules such as "temporary land use period" and "approval level for converting farmland to construction land" through stored procedures and trigger logic.

[0143] Spatial joint verification: Call PostGIS functions to verify whether the spatial location, area, topological relationship, etc. of the plot meet the requirements.

[0144] Cross-table consistency check: Asynchronously initiates verification of the consistency of cross-table data such as "transaction amount" and "contract amount" through a message queue.

[0145] The verification process generates a detailed "factory quality inspection report," recording all rules that passed and failed, as well as the specific data records and reasons for errors in the failed records. This report serves as direct proof of data quality.

[0146] After validating the captured business data using business rules, the business data captured in the first stage is encapsulated. Specifically, business attribute data is serialized and compressed using the efficient Avro (line-based binary serialization format). The Avro format has advantages such as self-descriptiveness, high compression ratio, and good cross-platform compatibility, making it very suitable for large-scale data transmission.

[0147] Business spatial data is encapsulated in WKB (Well-Known Binary) format. WKB is a standard binary format in the GIS field, which is small in size, fast to read and write, and can be directly parsed by mainstream GIS platforms (such as ArcGIS and QGIS), ensuring "plug and play" of spatial data.

[0148] After the business dataset captured in the first stage is packaged into a data packet according to a certain format, the summary of the "factory inspection report" generated in the second stage (such as rule pass rate and statistics of major error types) is embedded in the data packet as a "quality inspection snapshot" to provide the recipient with an intuitive quality assessment.

[0149] The "rule metadata XML file" is attached as the core "intelligent diagnostic manual" for customers to perform subsequent data verification, problem troubleshooting, and system integration locally.

[0150] When delivering data to customers, the business data package, the "factory inspection report", and the "rule metadata XML file" are integrated into a complete data package, encrypted using the AES-256 high-strength encryption algorithm, and transmitted to the provincial unit through a secure channel such as HTTPS or VPN.

[0151] Step 6 of this process realizes the transformation from "passive export" to "proactive service". What provincial units receive is no longer scattered "parts", but a "complete machine" that has been tested and comes with an instruction manual, which can be put into use immediately.

[0152] See Figure 3 An embodiment of the present invention provides a data sharing system based on embedded rules, the system comprising:

[0153] The first construction module 301 is used to systematically deconstruct the source database system, identify the core business modules that constitute the shared entity, clarify the logical relationships between the core business modules, and construct a relationship topology map that displays the overall architecture of the system.

[0154] Extraction module 302 is used to extract all key entities from the source database system, standardize the definition of the attributes of each key entity, and perform preliminary quality checks on the attribute data of each key entity.

[0155] The second construction module 303 is used to extract the association relationships between key entities based on the relationship topology graph, and to construct an entity relationship model by combining the attribute data of each key entity, and to embed multi-level data constraint rules into the entity relationship model.

[0156] Embedding module 304 is used to map the constructed entity relationship model to a physical model and embed business rules into the physical model;

[0157] The data delivery module 305 is used to search for relevant business datasets from the natural resource management system according to customer requests, perform batch rule verification on the business datasets using the business rules embedded in the physical model, generate a "factory inspection report", embed the business datasets and the factory inspection report into a data package, and deliver the data package and the rule metadata XML file together to the customer.

[0158] It is understood that the data sharing system based on embedded rules provided by the present invention corresponds to the data sharing method based on embedded rules provided in the foregoing embodiments. The relevant technical features of the data sharing system based on embedded rules can be referred to the relevant technical features of the data sharing method based on embedded rules, and will not be repeated here.

[0159] The data sharing method and system based on embedded rules provided in this invention have the following beneficial effects:

[0160] (1) Construct a composite entity-relationship model. This model not only includes traditional entity, attribute, and relationship definitions, but also embeds business rule verification logic as part of the metadata directly within the model. Using this embedded rule entity-relationship model as the driving engine, it receives data sharing requests, automatically constructs association queries based on the relationship topology in the model, finds business data, automatically initiates data verification according to the embedded business rules, and finally generates a delivery package containing business data, spatial data, verification reports, and rule metadata.

[0161] (2) A layered and automated rule validation architecture was implemented in the database physical model to validate the business data before delivery, ensuring the correctness of the data at the business level. Rules can be transmitted along with the data.

[0162] It should be noted that the descriptions of each embodiment in the above embodiments have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0163] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0164] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0165] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0166] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0167] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0168] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A data sharing method based on embedded rules, characterized in that, include: The source database system is systematically deconstructed to identify the core business modules that constitute the shared entity, and the logical relationships between the core business modules are clarified to form a relational topology map that shows the overall architecture of the system. Extract all key entities from the source database system, standardize the definition of the attributes of each key entity, and perform preliminary quality checks on the attribute data of each key entity. Based on the relationship topology graph, the relationships between key entities are extracted, and the attribute data of each key entity is combined to construct an entity relationship model. Multi-level data constraint rules are then embedded in the entity relationship model. The constructed entity relationship model is mapped to a physical data model, and the business rules are embedded in the physical data model; Based on the customer's request, the relevant business dataset is retrieved from the physical data model, and the business rules embedded in the physical data model are used to perform batch rule verification on the business dataset to generate a "factory quality inspection report". The business dataset and the factory quality inspection report are embedded in a data package, and the data package and the rule metadata XML file are delivered to the customer together.

2. The data sharing method based on embedded rules according to claim 1, characterized in that, The process of systematically deconstructing the source database system, identifying the core business modules that constitute the shared entity, clarifying the logical relationships between these core business modules, and forming a relational topology diagram that displays the overall system architecture includes: Based on the functions of natural resource management, the business in the source database system is divided into multiple subject areas, and each subject area is assigned a unique identifier; Analyze the database structure and data dictionary of the source database system, identify the key business objects under each subject area and their sequential relationship in the business flow, so as to further subdivide each subject area into indivisible atomic business units; Identify the data linkage points between data tables in different subject areas, and construct the relationships between data tables under different subject areas; Based on the list of subject domains, the mapping table of atomic business units under each subject domain, and the association matrix of data tables under different subject domains, a relational topology map of the overall system architecture is constructed to display the system.

3. The data sharing method based on embedded rules according to claim 1, characterized in that, The process involves extracting all key entities from the source database system, standardizing the definition of attributes for each key entity, and performing preliminary quality checks on the attribute data of each key entity, including: The source database is scanned by an automated script to extract the structural information of all data tables. The structural information includes the data table name, field name, field data type, field data length, and whether the field data is empty. Select the data tables that carry the core business semantics as the carriers of key entities, and define the attribute data of each key entity: Determine the primary key field for each key entity and define the coding rules; Identify the geometric fields of each key entity; Parse the constraints of each field and establish a relationship with the standard data dictionary; Perform basic verification on all spatial entities, and finally generate an entity-attribute matrix.

4. The data sharing method based on embedded rules according to claim 1, characterized in that, Based on the relationship topology graph, the relationships between key entities are extracted, and an entity relationship model is constructed by combining the attribute data of each key entity. Multi-level data constraint rules are then embedded in the entity relationship model, including: Analyze foreign key relationships in the database to determine the connection paths between different data tables in order to extract the relationships between key entities and construct an entity relationship model; Constraint rules are designed for data tables and key entities to form a constraint rule set, which includes spatial constraints, time constraints and logical constraints. The constraint rule set is then embedded into the entity relationship model. Create a "relationship metadata table" to store the source table, target table, related fields, and relationship types.

5. The data sharing method based on embedded rules according to claim 1, characterized in that, The process of mapping the constructed entity relationship model to a physical data model includes: Map the entities in the entity relationship model to physical tables, map the attribute data of the entities to fields, and specify the data type of the fields; Create a GiST index for each spatial field, a composite B-Tree index for combinations of frequently queried fields, and a BRIN index for each time interval field. DDL scripts are automatically generated based on the mapped physical tables and fields. The DDL scripts include table creation statements, index definitions, foreign key constraints, and cascading delete / update statements. A physical data model is constructed by executing the DDL script.

6. The data sharing method based on embedded rules according to claim 5, characterized in that, The embedding of business rules into the physical data model includes: Business rules are configured using a layered embedded architecture, and these business rules include structural layer constraint rules, business logic layer coding rules, and cross-table consistency verification rules. Embed the configured business rules into the physical data model; All business rules are generated into lightweight rule metadata XML files, which include rule ID, scope, validation logic fragment, expected output and error code.

7. The data sharing method based on embedded rules according to claim 6, characterized in that, The step of retrieving relevant business datasets from the physical data model based on customer requests includes: Receive a JSON-formatted request from a client, the request including the subject, administrative region, and time range; Parse the topic identifier in the request, dynamically query the association paths of all entities under the topic domain corresponding to the topic identifier from the "relationship metadata table", and automatically generate an SQL query plan containing all necessary JOIN conditions; Based on the SQL query plan, relevant business data is retrieved from the physical data model to form a business dataset.

8. The data sharing method based on embedded rules according to claim 7, characterized in that, The business dataset is batch-verified using the business rules embedded in the physical data model to generate a "factory quality inspection report", including: Using the business rules embedded in the physical data model, the business dataset is subjected to structural layer checks, business logic layer checks, spatial joint checks, and cross-table consistency checks according to structural layer constraint rules, business logic layer coding rules, and cross-table consistency checks, respectively, and a factory quality inspection report is generated. The factory quality inspection report records all rules that pass and fail, as well as the specific data records and error reasons for those that fail.

9. A data sharing system based on embedded rules, characterized in that, include: The first building module is used to systematically deconstruct the source database system, identify the core business modules that constitute the shared entity, clarify the logical relationships between the core business modules, and construct a relationship topology map that shows the overall architecture of the system. The extraction module is used to extract all key entities from the source database system, standardize the definition of the attributes of each key entity, and perform preliminary quality checks on the attribute data of each key entity. The second construction module is used to extract the association relationships between key entities based on the relationship topology graph, and to construct an entity relationship model by combining the attribute data of each key entity, and to embed multi-level data constraint rules into the entity relationship model. An embedding module is used to map the constructed entity relationship model to a physical data model and embed business rules into the physical data model; The data delivery module is used to find relevant business datasets from the physical data model according to customer requests, perform batch rule verification on the business datasets using the business rules embedded in the physical data model, generate a "factory quality inspection report", embed the business datasets and the factory quality inspection report into a data package, and deliver the data package and rule metadata XML file together to the customer.

Images