A multi-table association wide table generation and publishing verification method and system based on declarative relationship constraints
Patent Information
- Application Number
- CN202611278002.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-08-21
- Publication Date
- 2026-11-03
AI Technical Summary
Existing technologies lack declarative relationship constraints in multi-table association analysis, leading to data bloat and distorted metrics, especially in stringent scenarios such as medical quality review and financial reconciliation, where the risk of unacceptable metric distortion is particularly high.
The metamodel management module receives and verifies the relationship declarations between tables, applies declarative relationship constraints in both the service layer and storage layer, performs pre-polymerization with master-level anchoring during the generation phase, and performs row count consistency verification during the release phase to ensure that the number of rows in the wide table is consistent with the number of rows in the main table, thus preventing the release of erroneous models and distorted data.
By forcibly constraining erroneous models during the data modeling phase, eliminating data inflation during the generation phase, and ensuring data correctness during the release phase, the system achieves proactive prevention of data inflation and automatic verification before release, thus ensuring data quality.
Smart Images
Figure FT_1 
Figure FT_2
Abstract
Description
Technical Field
[0001] This invention belongs to the field of data processing technology, and relates to the generation and publication of data warehouse summary tables. Specifically, it relates to a method and system for generating, publishing, and verifying wide tables with multi-table associations based on declarative relational constraints. Background Technology
[0002] In multi-table join analysis, one-to-many joins cause the main table's measure to appear repeatedly based on the number of rows in the subordinate table, resulting in repeated counting during aggregation, a phenomenon known in the industry as data bloat (fan-out). Existing technologies fall into four categories: (a) Query-time correction type—duplicates are removed by unique keys during query execution (symmetric aggregation), or the query is rewritten as "aggregate first, then join" when a many-to-many join is detected; correction occurs in every query, and correctness depends on the query engine rewriting it each time; (b) Relationship and cardinality declaration type—the relationship fields and cardinality types between tables are registered at the semantic model or data model layer, but the declaration is only used to guide the join method and does not impose any mandatory constraints on the aggregation semantics, which can lead to the model still being built despite the bloat; (c) Query function layer validation type—the validity of user-written aggregation metrics is validated at the query formula level, the validation object is the query expression rather than the model itself, and it occurs at runtime; (d) Materialization acceleration type—materialized views are built based on metric metadata, the pre-calculated results are retrieved when the query hits, and real-time calculation is rolled back when the query misses, the purpose of materialization is to accelerate the query, it does not include anti-bloat constraints, and there is no data correctness verification before release.
[0003] The common problem with the four existing technologies mentioned above is that anti-expansion measures are concentrated on "post-event correction" during the query period, there is a lack of mandatory constraints during the data modeling period (incorrect models can be built), and there is a lack of correctness gates in the summary table publishing stage (distorted data can be published). The problem only becomes apparent at the data consumption end. In scenarios such as medical quality assessment and financial reconciliation, where the accuracy of indicator definitions is strictly required, this means an unacceptable risk of indicator distortion. Therefore, this application provides a method and system for generating and publishing wide tables with multi-table relationships based on declarative relational constraints, moving the governance point forward: mandatory operators during the declarative period address the issue of "incorrect models being built," structure elimination during the generation period addresses the issue of "repeatedly incurring correction costs for each query," and row count gates during the publishing period address the issue of "distorted data being published."
[0004] The information disclosed in this background section is intended only to enhance the understanding of the overall background of the invention and should not be construed as an admission or in any way implying that the information constitutes prior art known to those skilled in the art. Summary of the Invention
[0005] The purpose of this invention is to provide a method and system for generating and publishing wide tables with multiple tables based on declarative relational constraints, so as to solve the problems of lack of mandatory constraints during data modeling and lack of correctness gates in the summary table publishing process.
[0006] To achieve the above objectives, the present invention provides the following technical solution: A system for generating, publishing, and validating wide tables with multi-table relationships based on declarative relational constraints includes: The metamodel management module is used to receive requests for relationship declarations between registration forms and send each declaration to the constraint verification module for inspection. The constraint verification module is used to verify the cardinality type value of each relation declaration to ensure that it is valid. When the cardinality type is one-to-many, it verifies that the aggregation operator is not empty and belongs to the preset whitelist. If the verification fails, the declaration is refused to be saved. If the verification passes, it is written to the metadata storage. The wide table generation module is used to read the declaration, generate a materialized wide table, and send the materialization result to the release access control module for inspection. The access control module is used to perform row count consistency checks on the materialized results. After passing the checks, the transaction is published to the data warehouse and the metadata registration is written back. Metadata storage is used to store validated claims and impose database constraints on written claims.
[0007] As a preferred approach, the system applies the same set of constraints to both the application service layer and the storage layer, and the value sets of the two layers are completely identical. Specifically, the storage layer constraints include: ① cardinality type value enumeration check; ② aggregate operator non-null check when the cardinality is one-to-many; ③ aggregate operator value check if it belongs to a preset whitelist member; ④ check if the main table identifier is not equal to the slave table identifier. The application service layer performs the same set of checks and returns business errors before saving, and the storage layer constraints are enforced under any write path.
[0008] As a preferred option, the system enforces mandatory constraints during the declaration period, specifically: When registering relationships between data tables, all one-to-many relationship declarations must include an aggregation operator, which is taken from a preset whitelist. The aggregation operator whitelist includes: numerical operators, existence checks, and non-existence checks. Declarations with missing operators, operators not on the whitelist, many-to-many relationships, or table-to-table relationships are rejected.
[0009] Preferably, the associated fields in the relationship declaration are one or more field pairs, and each field pair participates in the comparison of the connection conditions one by one in a preset order.
[0010] As a preferred approach, when generating the materialized wide table, the system uses the granularity of the main table as the anchor, and for each one-to-many association, it first performs pre-aggregation and convergence on the side of the slave table according to the declared aggregation operator, and then materializes it by left join with the main table.
[0011] 6. The system for generating and publishing a wide table based on declarative relational constraints for multi-table association according to claim 1, characterized in that a preview is generated before the wide table is published, and in addition to returning the estimated number of rows and columns, this step also returns the duplicate count of the main table on the selected granularity key.
[0012] As a preferred approach, before publishing the wide table, the system automatically compares the number of rows in the wide table with the number of rows in the main table under the same range conditions at the time of generation. If the number of rows in the wide table is not equal to the number of rows in the main table, the system rejects the publication, outputs a difference report containing the expected number of rows, the actual number of rows, the difference, and the list of related items, and rolls back the transaction. If the number of rows in the wide table is equal to the number of rows in the main table, the transaction is published and metadata is registered, including the source table, source field, and operator involved for each column of the wide table.
[0013] Preferably, the difference report includes at least the expected number of rows, the actual number of rows, the difference, and the list of related items.
[0014] As a preferred approach, after a wide table is published, the metadata should be used to register the wide table objects and the origin of each column, thus forming a column-level lineage.
[0015] As a preferred approach, the wide table deployment process first materializes the generated results into an intermediate table, performs row consistency checks on the intermediate table, and then atomically switches the intermediate table to the official table after the check passes, while keeping the original table as a backup; if the check fails, the official table is never touched.
[0016] Preferably, the system supports both persistent wide table path and ad-hoc query path for the same association declaration, with both paths governed by the same aggregation operator constraint; the two paths read the same relation declaration record and apply the same aggregation operator constraint to the same association.
[0017] This invention also provides a method for generating, publishing, and validating a multi-table related wide table based on declarative relational constraints, comprising the following steps: S1. Receive request for declaration of inter-table relationships; S2, Application layer constraint check; S3. The database constraint layer executes secondary mandatory constraints; S4. Declaration saving, version registration; S5. Receive wide table generation request; S6. Traverse one-to-many relationships and generate pre-aggregate subqueries from the tables according to declared operators; S7. The main table and each pre-aggregated subquery are left-joined and concatenated to materialize a wide table; S8, Row Count Equality Check: Determines if the number of rows in the wide table is equal to the number of rows in the main table; if they are not equal, reject the release, output a difference report, and roll back. S9. After the verification is successful, the transaction is published to the data warehouse and the metadata registration is written back.
[0018] The present invention also provides a computer-readable storage medium storing a computer program, a method for generating, publishing, and verifying wide tables with multiple table associations.
[0019] The present invention also provides an electronic device, including a computer-readable storage medium and a processor, wherein the computer-readable storage medium is the computer-readable storage medium of claim 7, and the processor is capable of executing a computer program stored therein.
[0020] Compared with the prior art, the present invention has the following beneficial effects: (1) The multi-table association wide table generation and release verification system based on declarative relation constraints of the present invention executes mandatory constraints during the declaration period. These constraints are implemented in both the application service layer and the database constraint layer. No write path can bypass them, thus blocking the erroneous model of data inflation at the source during the modeling period.
[0021] (2) The multi-table association wide table generation and publishing verification system based on declarative relation constraints of the present invention performs pre-aggregation of master granularity when generating summary data table (wide table), so that the number of rows in the wide table is structurally equal to the number of rows in the master table. The expansion is eliminated in advance rather than corrected after the query period, and there is zero additional overhead during the query period.
[0022] (3) The multi-table association wide table generation and release verification system based on declarative relation constraints of the present invention performs row number consistency gate during the wide table release period. If the number of rows in the wide table is not equal to the number of rows in the main table under the same range conditions, the release is rejected, making data correctness an automatically verifiable precondition for release.
[0023] (4) The multi-table association wide table generation and publishing verification system based on declarative relation constraints of the present invention performs dual-path same-origin constraints on the same association declaration, and supports both persistent wide table path and ad-hoc query path, so that both paths are governed by the same aggregation operator constraint; since the two paths read the same declaration record and apply the same operator constraint, the two paths have the same scope. Attached Figure Description
[0024] Figure 1 This is a schematic diagram of the system structure according to an embodiment of the present invention; Figure 2 This is a flowchart of a method according to an embodiment of the present invention; Explanation of key figure labels: 101. Metamodel Management Module; 102. Constraint Verification Module; 103. Wide Table Generation Module; 104. Access Control Publish Module; 105. Metadata Storage. Detailed Implementation
[0025] The technical solution of this invention patent will be clearly and completely described below. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of this invention.
[0026] In the description of this invention, it should be noted that the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer", etc., indicating the orientation or positional relationship are based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention.
[0027] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "joining" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to a connection within two components. Those skilled in the art will understand the specific meaning of the above terms in this invention based on the specific circumstances.
[0028] See attached document Figure 1 The present invention provides a multi-table association wide table generation and publishing verification system based on declarative relational constraints, comprising: a metamodel management module 101, a constraint verification module 102, a wide table generation module 103, a publishing access control module 104, and metadata storage 105.
[0029] See attached document Figure 2 The present invention also provides a method for generating, publishing, and validating a multi-table related wide table based on declarative relational constraints, comprising the following steps: S1 Receive association declaration request → S2 Application layer constraint verification (if it fails, refuse to save) → S3 Database constraint layer secondary enforcement → S4 Declaration saving and version registration → S5 Receive wide table generation request → S6 Traverse one-to-many associations to generate pre-aggregate subqueries → S7 Left join concatenation and materialization → S8 Row count consistency verification (if they are not equal, refuse to publish, output a difference report and rollback) → S9 Transaction publication and metadata registration.
[0030] This invention employs a progressively layered approach, consisting of "declaration-time constraints → generation-time structure elimination → release-time verification fallback." Sequence restrictions: S2 / S3 must precede S4—associations that fail declaration verification cannot be saved; pre-aggregation in S6 must precede connection in S7 (aggregation before connection is a structural prerequisite for preventing expansion; reversing the order results in degeneration into ordinary connection); S8 must occur after the materialization of S7 and before the release of S9, and S8 verification must be completed to ensure there is no intermediate state of "released but not verified."
[0031] Because one-to-many relationships require declared operators, the generator always has a definite aggregation basis; because the generator pre-aggregates before left joining, the number of rows in the wide table is structurally equal to the number of rows in the main table, eliminating the need for sequential corrections during the query period and resulting in zero query overhead; because mandatory row count comparisons are enforced before deployment, even if data quality anomalies occur outside the first two lines of defense (such as dirty data in the join key), distorted results cannot be deployed; because both paths originate from the same source, the materialized and ad-hoc consumption methods must be consistent. In summary, the data inflation problem shifts from "post-event discovery at the consumption end" to "structural prevention during modeling / deployment."
[0032] In this embodiment, the metamodel management module 101 maintains at least four types of objects, including: data table node objects, inter-table association objects, derived column objects, and wide table registration objects. Among them, the inter-table association object includes at least the following fields: association identifier, main table identifier, secondary table identifier, main table association field, secondary table association field, cardinality type (enumeration: one-to-one / one-to-many / many-to-one), aggregation operator, aggregation target field, memo name, enabled status, and version number.
[0033] The storage layer (database) applies the following checks and constraints to related objects: ① Cardinality type value enumeration check; ② Aggregate operator non-null check when the cardinality is one-to-many; ③ Aggregate operator value belonging to a whitelist member check; ④ Primary table identifier not equal to secondary table identifier (self-association prohibited); ⑤ Many-to-many relationship prohibited (many-to-many values are not set in the enumeration, excluded from the type system); ⑥ Unique index of the primary table in the same wide table; ⑦ Foreign key reference integrity of related nodes. The application service layer performs the same set of checks before saving and returns a readable business error; the storage layer constraints ensure that even if the application bypasses and writes directly to the database, it will be rejected—the two layers together constitute "declaration-time rejection checks".
[0034] Examples of whitelisted aggregate operators: summation, count, maximum value, minimum value, existence check, and count by condition; non-existence check is also allowed in derived column scenarios. All operators are implemented using database vendor-neutral standard expressions. For example, "count by condition" uses the SUM(CASE WHEN condition THEN 1 ELSE 0 END) form instead of database-specific aggregate syntax, allowing wide table definitions to be ported across database systems.
[0035] The generator receives a wide table definition (main table, selected main table fields, selected aggregate columns under each one-to-many relationship, and derived column expressions), and generates a wide table query according to the following template: SELECT m.primary key, m.selected dimension fields, ..., s1.aggregate column 1, s2.aggregate column 2, ..., derived column expression... FROM main table m LEFT JOIN (SELECT key, aggregate operator(aggregate target field) AS aggregate column1) FROM table1 GROUP BY joinkey s1 ON m.primaryjoinfield = s1.joinkey LEFT JOIN (SELECT join_key, aggregate_operator(aggregate_target_field) AS aggregate_column2) FROM table2 GROUP BY joinkey s2 ON m.primary join field = s2.joinkey... It's important to note that each one-to-many subordinate table is first converged to one row per key using the GROUP BY clause within the subquery; aggregation occurs before the join—this ensures that the row count relationship on both sides of the join is always one-to-one or one-to-zero, structurally preventing bloat; the join method is always a left join to guarantee that no rows from the main table are lost. Derived column expressions undergo expression security validation (based on a dual validation of a blacklist of dangerous words and a safe character set) before saving; the generated preview supports pre-running, and the pre-run query enforces an additional row count limit protection (in one embodiment, the limit is 1000 rows).
[0036] The deployment process is executed sequentially within the same transaction boundary: materialization (creating the table and writing the results of the generated query) → validation → registration. On storage engines that support transactional data definition statements, table switching and metadata registration after successful validation are completed within the same transaction. On storage engines that do not support this, intermediate tables and failure compensation deletions ensure that there is no intermediate state of "deployed but not validated." Validation is implemented as follows: A COUNT operation is performed on the materialized output to obtain the actual number of rows; a COUNT operation is performed on the main table using the same range parameters (such as time window conditions) as during generation to obtain the expected number of rows; if the two are equal, the process continues; otherwise, the entire process is rolled back and a difference report is generated—the report at least includes the expected number of rows, the actual number of rows, the difference, and a list of related data, allowing users to locate data quality issues with related keys. After successful validation, the wide table object and the source of each column (source table, source field, aggregate operator used) are registered in the metadata, forming a column-level lineage.
[0037] The release process does not involve directly writing the data into the official table and then verifying and rolling back if it fails. Instead, the generated results are first materialized into an intermediate table, and a row count consistency check is performed on the intermediate table. If the check passes, the intermediate table is atomically switched to the official table, and the original table is kept as a backup. If the check fails, the official table is never touched.
[0038] This invention can be applied to retail, finance, and other fields. In this embodiment, using medical data is only one implementation method. Assume the main table "Medical Visit Records" has 10,000 rows (one row per visit), the subsidiary table "Billing Details" has 47,000 rows (an average of 4.7 charges per visit), and the subsidiary table "Diagnosis Records" has 23,000 rows. If the three tables are directly joined, the result is approximately 108,000 rows, with visit-level metrics (such as fees) being counted repeatedly. According to this method: during the modeling phase, declare the "Medical Visit-Billing" relationship as one-to-many with the summation operator (target field: amount), and declare the "Medical Visit-Diagnosis" relationship as one-to-many with the counting operator; during the generation phase, produce a wide table with 10,000 rows, where the amount column represents the total charges for each visit, and the diagnosis column represents the number of diagnoses for each visit; during the release phase, verify that the COUNT=10000 of the wide table is equal to the COUNT=10000 of the main table, and then publish the transaction.
[0039] The following two counterexamples illustrate this point: Counterexample 1 (Declaration-time interception): When a user registers a one-to-many relationship without selecting an aggregate operator, the application layer refuses to save and returns "A one-to-many relationship must specify an aggregate operator"; even if a direct write request is constructed to bypass the application layer, the database constraint check still rejects it.
[0040] Counterexample 2 (Release Period Interception): During a certain generation, due to duplicate dirty data in the join key of the secondary table, the number of rows in the wide table was 10012, which was different from the 10000 in the primary table. The release was rejected, the transaction was rolled back, and the difference report output the difference value of 12 and the related join. After the user repaired the data, the generation was successfully completed and released.
[0041] In another embodiment, the aggregation operator can be any member of the whitelist, which can be expanded without changing the mechanism; the main table can be any business granularity table, and the application industry is not limited (medical, retail, finance, manufacturing, etc. can all be implemented); the row count consistency check can be expanded to segmented row count verification based on grouping conditions (comparing group by group, with finer difference location); the materialized target can be a physical table, materialized view, or cache table; in the incremental refresh scenario, the verification can be performed in incremental batches (comparing the row count within the batch with the incremental row count of the main table); in the ad-hoc query path, when the same association declaration dynamically generates a query statement, the declared operator is also forced to be applied, and this path can replace or coexist with the materialized path; in the multi-master granularity scenario, this method can be implemented separately for each master granularity to generate multiple wide tables.
[0042] The core pipeline of this application has been implemented and is running in the online system; the alternative implementations listed in the specification are extensions that can be implemented by those skilled in the art based on this specification. The foregoing description of specific exemplary embodiments of the invention is for illustrative and explanatory purposes. These descriptions are not intended to limit the invention to the precise forms disclosed, and it will be apparent that many changes and variations can be made in accordance with the foregoing teachings. The exemplary embodiments were chosen and described in order to explain the specific principles of the invention and its practical application, thereby enabling those skilled in the art to implement and utilize various different exemplary embodiments of the invention, as well as various different choices and variations. The scope of the invention is intended to be defined by the claims and their equivalents.
Claims
1. A system for generating, publishing, and validating wide tables with multi-table associations based on declarative relational constraints, characterized in that: include: The metamodel management module is used to receive requests for relationship declarations between registration forms and send each declaration to the constraint verification module for inspection. The constraint verification module is used to verify the cardinality type value of each relation declaration to ensure that it is valid. When the cardinality type is one-to-many, it verifies that the aggregation operator is not empty and belongs to the preset whitelist. If the verification fails, the declaration is refused to be saved. If the verification passes, it is written to the metadata storage. The wide table generation module is used to read the declaration, generate a materialized wide table, and send the materialization result to the release access control module for inspection. The access control module is used to perform row count consistency checks on the materialized results. After passing the checks, the transaction is published to the data warehouse and the metadata registration is written back. Metadata storage is used to store validated claims and impose database constraints on written claims.
2. The system for generating and publishing wide tables with multi-table associations based on declarative relational constraints according to claim 1, characterized in that, The system applies the same set of constraints to both the application service layer and the storage layer, and the value sets of the two layers are completely consistent. Specifically, the storage layer constraints include: ① cardinality type value enumeration check; ② aggregate operator non-null check when the cardinality is one-to-many; ③ aggregate operator value check if it belongs to a preset whitelist member; ④ check if the main table identifier is not equal to the slave table identifier. The application service layer performs the same set of checks and returns business errors before saving, and the storage layer constraints are enforced under any write path.
3. The system for generating and publishing wide tables with multi-table associations based on declarative relational constraints according to claim 1, characterized in that, The system enforces mandatory constraints during declaration time, specifically: When registering relationships between data tables, all one-to-many relationship declarations must include an aggregation operator, which is taken from a preset whitelist. The aggregation operator whitelist includes: numerical operators, existence checks, and non-existence checks. Declarations with missing operators, operators not on the whitelist, many-to-many relationships, or table-to-table relationships are rejected.
4. The system for generating and publishing wide tables with multi-table associations based on declarative relational constraints according to claim 1, characterized in that, The related fields in the relationship declaration are one or more field pairs, and each field pair participates in the comparison of the connection conditions one by one in a preset order.
5. The system for generating and publishing wide tables with multi-table associations based on declarative relational constraints according to claim 1, characterized in that, When generating a materialized wide table, the system uses the granularity of the main table as the anchor. For each one-to-many relationship, it first performs pre-aggregation and convergence on the side of the slave table according to the declared aggregation operators, and then materializes it by left join with the main table.
6. The system for generating and publishing wide tables with multi-table associations based on declarative relational constraints according to claim 1, characterized in that, Before publishing the wide table, a preview is generated. In addition to returning the estimated number of rows and columns, this step also returns the duplicate count of the main table on the selected granularity key.
7. The system for generating and publishing wide tables with multi-table associations based on declarative relational constraints according to claim 1, characterized in that, Before publishing the wide table, the system automatically compares the number of rows in the wide table with the number of rows in the main table under the same range conditions at the time of generation; if the number of rows in the wide table is not equal to the number of rows in the main table, the system rejects the publication, outputs a difference report containing the expected number of rows, the actual number of rows, the difference, and the list of related tables, and rolls back the table. If the number of rows in the wide table is equal to the number of rows in the main table, the transaction is published and metadata is registered, including the source table, source field, and operator used for each column in the wide table.
8. The system for generating and publishing wide tables with multi-table associations based on declarative relational constraints according to claim 7, characterized in that, The difference report should include at least the expected number of rows, the actual number of rows, the difference, and the list of related items.
9. The system for generating and publishing wide tables with multi-table associations based on declarative relational constraints according to claim 7, characterized in that, After a wide table is published, the metadata records the wide table objects and the origin of each column, forming a column-level lineage.
10. The system for generating and publishing wide tables with multi-table associations based on declarative relational constraints according to claim 7, characterized in that, The wide table deployment process is to first materialize the generated results into an intermediate table, perform row consistency checks on the intermediate table, and then atomically switch the intermediate table to the official table after the checks pass, while keeping the original table as a backup. When the validation fails, the formal table has never been touched.
11. The system for generating and publishing wide tables with multi-table associations based on declarative relational constraints according to claim 1, characterized in that, The system supports both persistent wide table path and ad-hoc query path for the same association declaration, with both paths governed by the same aggregate operator constraint; the two paths read the same relation declaration record and apply the same aggregate operator constraint to the same association.
12. A method for generating, publishing, and validating wide tables with multi-table associations based on declarative relational constraints, characterized in that... Includes the following steps: S1. Receive request for declaration of inter-table relationships; S2, Application layer constraint check; S3. The database constraint layer executes secondary mandatory constraints; S4. Declaration saving, version registration; S5. Receive wide table generation request; S6. Traverse one-to-many relationships and generate pre-aggregate subqueries from the tables according to declared operators; S7. The main table and each pre-aggregated subquery are left-joined and concatenated to materialize a wide table; S8, Row Count Equality Check, determines whether the number of rows in the wide table is equal to the number of rows in the main table; If they are not equal, reject the release, output a difference report, and roll back. S9. After the verification is successful, the transaction is published to the data warehouse and the metadata registration is written back.
13. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed, it can implement the method for generating, publishing, and verifying a multi-table association wide table based on declarative relational constraints as described in claim 12.
14. An electronic device comprising a computer-readable storage medium and a processor, characterized in that, The computer-readable storage medium is the computer-readable storage medium of claim 13, wherein the processor can execute a computer program stored therein.