A data base-based business semantic-driven data governance method and system
Patent Information
- Application Number
- CN202611512347.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-09-28
- Publication Date
- 2026-10-30
AI Technical Summary
[0011]为了克服现有技术中数据底座与业务语义之间缺乏稳定承载判断、候选语义匹配结果难以直接转化为治理动作、语言模型验证成本高且证据不可复核的问题,本发明提供了一种基于数据底座的业务语义驱动数据治理方法及系统
[0023](1)针对现有候选匹配结果难以直接转化为治理动作的问题,本发明将标准数据底座图谱节点与业务语义图谱节点之间的候选语义承载关系转化为write、review、reject、no-match和flag等可执行治理动作,使候选识别结果能直接服务于业务语义目录写入、人工复核、候选拒绝、无匹配确认和治理问题标记,提高了数据治理处置的可执行性。
Smart Images

Figure CN123011894A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the fields of enterprise data governance and data asset management, specifically to a business semantics-driven data governance method and system based on a data foundation. This invention can be applied to scenarios such as data governance, business semantic catalog construction, and data asset management in discrete manufacturing enterprises. Background Technology
[0002] Discrete manufacturing enterprises continuously generate a large amount of business data during their procurement, production, sales, inventory, quality, equipment, and financial processes. This data is typically distributed across ERP, MES, WMS, SRM, business middleware, data warehouses, and enterprise-built systems. Inconsistencies exist between these systems, including inconsistent field names, coding rules, incomplete field descriptions, and inconsistent business definitions. Furthermore, the same business field may have different meanings depending on the stage of the business process. For example, application quantity, order quantity, received quantity, and warehousing quantity are related but cannot be simply considered as having the same business semantics.
[0003] To improve data reuse capabilities, enterprises typically build data catalogs, metadata platforms, data standard platforms, data quality platforms, or data infrastructures to uniformly maintain information such as data tables, fields, field dictionaries, data standards, inter-table relationships, and data lineage. These platforms can solve problems related to data asset registration, field standardization, data retrieval, and quality rule management. However, in actual governance, governance personnel also need to determine whether data-side nodes can support a specific business semantic, whether candidate results can be written into the catalog, whether manual review is required, and whether governance issues such as missing field descriptions, missing transformation rules, or missing inter-table relationships are exposed.
[0004] Existing methods for field matching, semantic alignment, and data governance planning can generate candidate matching results based on field names, field descriptions, sample values, rule configurations, or semantic vectors. Some methods can also combine knowledge bases or large language models to generate governance suggestions. However, these results usually remain at the level of candidate recommendations or planning suggestions, lacking structural evidence organization based on standard data foundation graphs and business semantic graphs, cross-graph constraint verification, and handling and diversion mechanisms. When candidate semantic relationships involve cross-table paths, process stages, field write-backs, or historical directory conflicts, relying solely on similarity scores or model judgments is prone to misjudgment.
[0005] In summary, the existing technology has at least the following shortcomings:
[0006] First, existing data governance methods typically do not simultaneously construct and utilize standard data foundation graphs and business semantic graphs, making it difficult to form executable governance actions such as catalog writing, manual review, candidate rejection, no-match confirmation, and problem marking based on the technical relationships and business semantic relationships of data assets.
[0007] Second, the candidate semantic carrying relationships generated based on the dual graph lack verifiable supporting evidence and conflict evidence consisting of dual graph hierarchy, relationship endpoints, structural neighborhoods and process paths, making it difficult for governance personnel to trace the basis for judgment.
[0008] Third, the direct confirmation of candidates, candidates awaiting model validation, candidates awaiting manual review, candidate rejections, and unmatched confirmations are not differentiated, which can easily increase the workload of model validation and manual review.
[0009] Fourth, the results of manual review and the handling of governance issues are difficult to feed back to update subsequent governance strategies and the nodes, edges, and governance status in the dual graph.
[0010] To address the aforementioned issues, a business semantics-driven data governance method oriented towards the data foundation is needed. This method constructs a standard data foundation graph and a business semantic graph, and generates candidate semantic carrying relationships and graph structure features or evidence indexes based on the dual graphs. The candidate semantic carrying relationships are sorted, multi-source fused, and compressed in number. The compressed set of candidates to be processed undergoes hierarchical consistency, relation endpoint consistency, and candidate competition constraint detection. Candidates are then split according to their confidence level and constraint detection results. Only for candidates to be verified, a filtered business evidence package is constructed from the dual graphs and verified. Finally, governance actions are generated based on various candidate results and written to the corresponding governance objects and the dual graph governance status. Summary of the Invention
[0011] To overcome the problems in existing technologies, such as the lack of stable bearing judgment between data foundation and business semantics, the difficulty in directly converting candidate semantic matching results into governance actions, the high cost of language model verification, and the lack of verifiable evidence, this invention provides a business semantics-driven data governance method and system based on data foundation.
[0012] In a first aspect, the present invention provides a business semantics-driven data governance method based on a data foundation, comprising: Construct a standard data foundation graph and a business semantic graph, generate a set of candidate semantic bearing relationships based on the standard data foundation graph and the business semantic graph, and calculate the candidate confidence of each candidate semantic bearing relationship; The candidate semantic carrying relationships are sorted, multi-source fused, and compressed in sequence, and a compressed candidate set to be processed is output. Constraint detection is performed on the compressed candidate set to be processed, and candidate splitting is performed based on the candidate confidence and constraint detection results to determine the splitting result of the semantic carrying relationship of each candidate; Construct a filtered business evidence package for the candidate semantic bearer relationships that need to be verified in the traffic splitting results, and verify the results based on the filtered business evidence package. Based on the traffic splitting results and the verification results, a governance action is generated and written into the corresponding governance object; Collect feedback information on the review of the governance actions and update the governance strategy parameters.
[0013] Preferably, the standard data foundation graph uses tables, fields, field combinations, interfaces, indicators, reports, field dictionaries, data standards, and governance results as data-side nodes, and the technical and governance relationships between data-side nodes as data-side edges; the business semantic graph uses business objects, business attributes, business relationships, business indicators, business rules, and business process stages as business-side nodes, and the subordinate, association, flow, constraint, derivation, and verification relationships between business-side nodes as business-side edges.
[0014] Preferably, the sorting criteria include multi-source features of candidate semantic carrying relationships, wherein the multi-source features include candidate confidence, candidate source credibility, historical verification status, and candidate type compatibility.
[0015] Preferably, the constraint detection includes hierarchical consistency detection and relation endpoint consistency detection; the hierarchical consistency detection is used to check whether the field-level candidate mapping is consistent with the table-level candidate mapping, and the relation endpoint consistency detection is used to check whether the candidate mappings at both ends of the data relationship are closed with the objects at both ends of the business relationship.
[0016] Preferably, the filtered business evidence package includes supporting evidence and conflicting evidence; the supporting evidence includes at least one or more of node name consistency evidence, hierarchy consistency evidence, structure consistency evidence, relation endpoint consistency evidence, path consistency evidence, and rule consistency evidence, and the conflicting evidence includes at least constraint conflict evidence detected in the constraint detection.
[0017] Preferably, the governance actions include writing to the business semantic directory, entering manual review, rejecting candidates, confirming no match, and marking governance issues. When the governance action is writing to the business semantic directory, the corresponding candidate semantic bearer relationship is written to the business semantic directory. When the governance action is entering manual review, the corresponding candidate semantic bearer relationship is written to the manual review queue. When the governance action is rejecting candidates, the corresponding candidate semantic bearer relationship is written to the candidate rejection record. When the governance action is confirming no match, the corresponding data-side node is written to the no-match list. When the governance action is marking governance issues, the corresponding issue is written to the governance issue list.
[0018] Secondly, the present invention provides a business semantics-driven data governance system based on a data foundation, comprising: The dual-graph construction and candidate relation generation module is used to construct a standard data base graph and a business semantic graph, generate a set of candidate semantic bearer relations based on the standard data base graph and the business semantic graph, and calculate the candidate confidence of each candidate semantic bearer relation; The candidate sorting, fusion and compression module is used to sort, fuse multiple sources and compress the quantity of the candidate semantic carrying relationships in sequence, and output the compressed candidate set to be processed. The graph constraint detection and candidate splitting module is used to perform constraint detection on the compressed candidate set to be processed, and to split the candidates according to the candidate confidence and constraint detection results, and to determine the splitting result of the semantic carrying relationship of each candidate. The dual-graph evidence verification module is used to construct and verify the candidate semantic bearer relationships that need to be verified in the traffic splitting results, and determine the verification results. The governance action generation module is used to generate governance actions based on the traffic splitting results and the verification results, and write the governance actions into the corresponding governance objects; The feedback update module is used to collect the review feedback information of the governance actions and update the governance strategy parameters.
[0019] Preferably, the dual-graph construction and candidate relationship generation module includes: a data-side node and edge construction unit, used to construct a standard data foundation graph using tables, fields, field combinations, interfaces, indicators, reports, field dictionaries, data standards, and governance results as data-side nodes, and using the technical and governance relationships between data-side nodes as data-side edges; a business-side node and edge construction unit, used to construct a business semantic graph using business objects, business attributes, business relationships, business indicators, business rules, and business process stages as business-side nodes, and using the subordinate, association, flow, constraint, derivation, and verification relationships between business-side nodes as business-side edges; and a candidate generation unit, used to generate a set of candidate semantic carrying relationships based on the data-side nodes, the data-side edges, the business-side nodes, and the business-side edges, and to calculate the candidate confidence for each candidate semantic carrying relationship.
[0020] Thirdly, the present invention provides an electronic device including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described in any of the first aspects above.
[0021] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the method described in any of the first aspects above.
[0022] Compared with the prior art, the present invention has at least the following beneficial effects:
[0023] (1) In view of the problem that existing candidate matching results are difficult to be directly converted into governance actions, this invention transforms the candidate semantic bearing relationship between standard data base graph nodes and business semantic graph nodes into executable governance actions such as write, review, reject, no-match and flag, so that the candidate identification results can directly serve business semantic directory writing, manual review, candidate rejection, no-match confirmation and governance problem marking, thereby improving the executability of data governance and disposal.
[0024] (2) In view of the lack of verifiable evidence for existing candidate semantic bearing relationships, this invention extracts node attributes, hierarchical affiliation, structural neighborhood, relation endpoints, process paths, rules, support, conflicts, sorting and historical evidence from standard data base graph and business semantic graph around a single cross-graph candidate semantic bearing relationship. This avoids making disposal conclusions based solely on field names, similarity scores or single model judgments, and improves the traceability and verifiability of the basis for judging candidate semantic bearing relationships.
[0025] (3) To address the issue that candidates with different credibility and dual graph constraint states are not processed differently, this invention divides the semantic relationship of candidates into directly confirmed candidates, candidates to be verified by the model, candidates to be manually reviewed, candidate rejection objects, and no-match confirmed objects by candidate ranking fusion, Top-K compression, candidate competition judgment, no-match trigger judgment, and dual graph constraint detection such as hierarchical consistency and relation endpoint consistency. Only candidates to be verified by the model and candidates to be manually reviewed are verified by evidence, which reduces the occupation of low-value candidates on model verification and manual review resources, and also reduces the risk of misjudgment caused by different business stages, inconsistent field types, or local similarity of relation paths.
[0026] (4) In view of the difficulty in feeding back the results of manual review and governance problem handling to update subsequent governance strategies, this invention records the review results, no-match confirmation results and governance problem handling results while generating governance actions, and uses them to update evidence filtering rules, no-match rules, action diversion thresholds and candidate source credibility, thereby forming a data governance closed loop that can be continuously improved. Attached Figure Description
[0027] Figure 1 This is a flowchart illustrating the business semantics-driven data governance method based on a data foundation, as described in this invention. Figure 2 This is a schematic diagram illustrating the construction of a filtered business evidence package and the generation of a structured verification request in an embodiment of the present invention. Figure 3 This is a result table of the comprehensive governance experiment of the procurement collaboration process according to the embodiments of the present invention. Detailed Implementation
[0028] The present invention will now be further described with reference to the accompanying drawings. The specific embodiments described below are for illustrative purposes only and should not be construed as limiting the scope of the invention.
[0029] To facilitate understanding of this invention, the following definitions are provided for the key terms involved:
[0030] Data infrastructure: refers to the foundational data asset layer that uniformly carries enterprise data assets, metadata, field dictionaries, data standards, table relationships, data lineage, quality rules, permission information, business process configurations, semantic relationships, and governance results. Data infrastructure can be implemented by a single platform, or it can be provided jointly by a metadata platform, a data standards platform, a data catalog platform, a quality platform, and a business configuration system.
[0031] Knowledge graph: A knowledge graph is a structured semantic network that uses entities or events with clear semantic meaning as nodes, semantic relationships between nodes as edges, and configures attributes, sources, versions, states, confidence levels, or governance information for the nodes and edges, thereby forming a network that can express entities, relationships, attributes, and their constraints. Knowledge graphs use entity-relationship-entity triples, as well as entity attributes, relationship attributes, and graph structure constraints to represent relational data.
[0032] A standard data foundation graph, also known as a data foundation map, refers to a structured knowledge graph formed by using tables, fields, field combinations, interfaces, metrics, reports, field dictionaries, data standards, and governance results within the data foundation as nodes, and using primary and foreign key relationships, logical associations, field mapping relationships, transformation relationships, lineage relationships, process push relationships, and status write-back relationships as edges. The data foundation graph is used to describe the technical and governance relationships between data-side nodes.
[0033] Business semantic graph: refers to a semantic knowledge graph on the business side, formed by business objects, business attributes, business relationships, business metrics, business rules, and business process stages as nodes, and subordinate, associated, flow, constraint, derivation, and validation relationships as edges. The business semantic graph is used to describe the semantic and process relationships between business concepts.
[0034] Dual graphs: These refer to a standard data foundation graph and a business semantic graph, which are constructed and maintained independently. The two graphs establish verifiable connections through cross-graph candidate semantic carrying relationships, but are not merged into a set of semantically empty nodes or a regular data directory.
[0035] Data-side nodes: refer to data objects that can be identified, described, governed, and reused, including at least database tables, fields, field combinations, inter-table relationships, field mapping rules, interfaces, metrics, reports, data services, and business documents.
[0036] Business-side nodes: refer to the standardized expression of objects, attributes, relationships or indicators on the business side, such as purchase requisition, purchase order, requisition quantity, ordered quantity, received quantity, invoice verification status and the relationship between purchase requisition and purchase order generation.
[0037] Candidate semantic bearing relationships: These refer to the possible bearing, mapping, supporting, or interpreting relationships between data-side nodes and business-side nodes. This invention establishes a verifiable connection between the data foundation graph and the business semantic graph through candidate semantic bearing relationships.
[0038] Filtered business evidence package: refers to the collection of node attributes, hierarchical affiliation, structural neighborhood, relation endpoints, process paths, supporting evidence, conflicting evidence, ranking evidence, rule evidence, and historical evidence selected from the standard data base graph and business semantic graph around the cross-graph candidate semantic carrying relationship of the candidate to be verified.
[0039] Candidate classification results: These refer to the directly confirmed candidates, candidates awaiting model validation, candidates awaiting manual review, candidate rejection objects, and confirmed objects without matching, formed based on candidate confidence and dual-graph constraint detection results; among them, only candidates awaiting model validation and candidates awaiting manual review enter the evidence verification process.
[0040] no-match: refers to the state where the data-side node has not found a stable business semantic carrier object, or the business-side node has not found a stable data-side node carrier object.
[0041] Governance actions refer to executable handling results such as write, review, reject, no-match, and flag generated based on the candidate diversion results and the verification results of candidates to be validated by the model and candidates to be manually reviewed.
[0042] Example 1
[0043] This embodiment uses the procurement collaboration process of a discrete manufacturing enterprise as a scenario to verify and illustrate the method of the present invention. The experimental dataset comes from the databases of three business systems of a certain enterprise: sales, production, and procurement. It contains a total of 48 business tables, 1260 fields, 86 relationship paths, 37 mapping rules, and 19 write-back rules.
[0044] like Figure 1 As shown, the business semantics-driven data governance method based on a data foundation described in this embodiment includes steps S100 to S700. Each step is described in detail below.
[0045] Step S100: Construct a standard data base graph and a business semantic graph, and generate a set of cross-graph candidate semantic bearing relationships based on the dual graphs, forming a candidate confidence level and graph structure feature or evidence index for each candidate semantic bearing relationship.
[0046] This step aims to provide standardized input with a graph structure and clear semantics for subsequent governance and disposal. The system reads the original data assets from the data foundation and constructs a standard data foundation graph, while extracting business-side nodes from business data and constructing a business semantic graph. Subsequently, semantic alignment is performed based on the constructed dual graphs to establish cross-graph candidate semantic carrying relationships between data-side nodes and business-side nodes, and candidate confidence scores and graph structure features or evidence indexes are generated for each candidate relationship.
[0047] S101: Standardize the raw data assets in the data base and construct a standard data base map.
[0048] The system first reads the raw data assets from the data base. The input data includes: a list of data sources, database instances, business system identifiers, a list of standard tables, a list of standard fields, field comments, field types, field lengths, field dictionaries, primary and foreign key configurations, index information, inter-table relationships, field mapping rules, field dependencies, process configurations, write-back rules, interface configurations, and source system information.
[0049] The system parses the above input information and extracts three types of assets: field-level assets, table-level assets, and relation-level assets. 1) Field-level assets should at least include field identifier, field name, field type, field length, field comment, table to which they belong, and system to which they belong; 2) Table-level assets must include at least the table identifier, table name, table description, source system, and table type; 3) Relationship-level assets include at least the source table, target table, source field, target field, association type, transformation rule, and write-back rule.
[0050] After the above analysis is completed, the system outputs the original data asset set D0, where D0 represents the original data asset set that has not undergone standardization processing.
[0051] Subsequently, the system performs standardization processing on the original data asset set D0. The standardization processing includes: unifying asset identification, unifying system coding, merging duplicate assets, completing the tables to which fields belong, completing the business systems to which fields belong, extracting Chinese names, extracting English names, extracting aliases, cleaning comments, extracting sample values, and normalizing dictionary values.
[0052] After standardization, the system uses tables, fields, field combinations, interfaces, metrics, reports, field dictionaries, data standards, and governance results as data-side nodes, and primary and foreign key relationships, logical associations, field mapping relationships, transformation relationships, lineage relationships, process push relationships, and status write-back relationships as data-side edges, constructing a standard data foundation graph G. D The standardized set of data-side nodes can be represented as:
[0053] Where D represents the set of data-side nodes in the standard data base map; d i This represents the i-th data-side node; n represents the number of data-side nodes.
[0054] S102: Extract business semantic units from business data and construct a business semantic graph.
[0055] The system inputs business process configurations, business object definitions, business field definitions, indicator definitions, policy documents, expert annotations, and historical semantic directories. The system extracts business objects, business attributes, business relationships, and business indicators from these inputs, and merges synonyms, abbreviations, historical names, and cross-system names.
[0056] After the merging is complete, the system constructs a business semantic graph G, using business objects, business attributes, business relationships, business metrics, business rules, and business process stages as business-side nodes, and subordinate, association, flow, constraint, derivation, and validation relationships as business-side edges. B The set of business-side nodes can be represented as:
[0057] Where B represents the set of business-side nodes in the business semantic graph; b j This represents the j-th business-side node; m represents the number of business-side nodes.
[0058] S103: Generate a set of candidate semantic bearing relationships based on the standard data base map and the business semantic map, and form a candidate confidence level and graph structure feature or evidence index for each candidate semantic bearing relationship.
[0059] The system inputs a standard data base graph data-side node set D, a business semantic graph business-side node set B, the candidate generation module output results, historical directory migration results, and expert configuration results. The candidate generation module can include one or more of the following methods: semantic recognition, rule matching, vector retrieval, graph representation learning, manual annotation, and historical directory migration. The semantic recognition module is used to identify semantically similar candidate relationships based on the names, aliases, field descriptions, and business definitions of data-side nodes and business-side nodes. Common methods such as edit distance, character n-gram, TF-IDF, or BM25 can be used. The rule matching module is used to filter candidate relationships that meet preset conditions based on field type, field dictionary, indicator caliber, conversion rules, and business rules. The vector retrieval module is used to convert data-side nodes and business-side nodes into text vectors and obtain semantically similar candidates through near-nearest neighbor retrieval. The graph representation learning module is used to generate candidate structural features based on graph nodes, relationship types, structural neighborhoods, and reachable paths. Graph neural networks, graph attention networks, or other existing graph representation methods can be used. The manual annotation module is used to receive candidate relationships selected, confirmed, or corrected by experts. The historical directory migration module is used to generate candidate relationships based on existing business semantic directories and historical review records. The expert configuration results include one or more of the following: candidate source credibility, candidate type compatibility, business rules, threshold parameters, evidence weights, or manually specified mapping constraints. The above methods are all commonly used in this field, and this invention does not limit their specific implementation. Each candidate generation method outputs candidate business-side nodes, candidate sources, source credibility, and evidence indexes. Subsequent steps S200 to S600 involve sorting, compression, constraint detection, evidence verification, and governance action routing. The system records for each candidate semantic carrier relationship: data-side node identifier, business-side node identifier, candidate relationship type, candidate confidence level, candidate source, candidate source credibility, graph structure features and / or evidence index, historical review status, and generation version. Graph structure features include the hierarchical position, structural neighborhood, relationship endpoints, reachable paths, and structural consistency information of the data-side nodes and business-side nodes associated with the candidate semantic carrier relationship. These are used for hierarchical consistency detection, relationship endpoint consistency detection, and other graph structure constraint detection in step S303. The evidence index is an index or pointer to evidence objects such as associated nodes, edges, paths, field dictionaries, indicator definitions, business rules, and historical review records. It is used in step S401 to determine the scope of evidence retrieval and extraction, and to reference the corresponding evidence in steps S402 to S403.
[0060] In one embodiment, the system provides candidate semantic bearer relations (d) i ,b j Constructing multi-source candidate feature vectors:
[0061] Among them, z ij Represents the candidate semantic carrier relation (d) i ,b j (Multi-source candidate feature vectors); , , , and These represent the characteristics of name, structure, path, rules, and historical evidence, respectively; p i0 express Data-side node d i There is a lack of matching priors for stable business semantic carrier objects. The unmatched prior p... i0 The determination is based on rules such as historical no-match confirmation records of similar data-side nodes, whether the data-side node belongs to a synchronization field, audit field, temporary field, or batch processing field, and whether the field description and business process attribution are missing. When there are many no-match confirmation records or the technical field rules are matched, the no-match prior is increased; when there is a clear business name, business description, and business process attribution, the no-match prior is decreased. When there are no historical records, a system-preset initial value is used, and the no-match prior value ranges from 0 to 1.
[0062] The system calculates candidate confidence based on multi-source candidate features:
[0063] Among them, s ij Represents the candidate semantic carrier relation (d) i ,b j The candidate confidence scores are calculated as follows: a0 to a5 are selected based on their confidence scores, and weights are calculated for each confidence score. The meanings of each multi-source candidate feature are as follows: Name Evidence Characteristics The similarity can be determined based on the standardized name similarity between the data-side node name and the business-side node name. Name standardization may include removing differences in capitalization, separator differences, unit suffixes, and generic suffixes without actual semantic meaning. When the names are the same or match the alias dictionary, the name evidence takes a higher value, and when the names are completely unrelated, a lower value is taken. Structural Evidence Features The consistency of business neighborhoods can be compared based on the node type, relationship type, and neighborhood name category of candidate nodes in their respective one-hop neighborhoods in the graph. The more nodes and relationships of the same type in the neighborhood, the higher the structural evidence. Path evidence features The comparison can be made based on the node types, relationship types, and business stage order in the data-side reachable path and the business-side reachable path. When all path nodes and relationship types are consistent and in the same order, the higher value is taken. When they are partially consistent, the value is determined according to the proportion of matched nodes and relationships. When they are completely inconsistent, the lower value is taken. Features of Rule Evidence The determination is based on the satisfaction of the applicable field types, field dictionaries, indicator definitions, conversion rules, and business rules for the current candidate. The more rules that are satisfied, the stronger the rule evidence. Historical Evidence Characteristics It can be determined based on the historical acceptance, rejection, no-match confirmation, and manual review records of the same or similar candidates. Historical acceptance records enhance historical evidence, while historical rejection records reduce historical evidence.
[0064] All of the above features are normalized to the range of 0 to 1; when corresponding evidence is missing, the feature adopts the system's preset default value, and the evidence missing status is recorded in the evidence package. For the specific calculation method of each feature, please refer to the evidence extraction and calculation methods in subsequent steps S402 to S405.
[0065] The system records the data-side node identifier, business-side node identifier, candidate relationship type, candidate confidence level, candidate source, candidate source credibility, graph structure features or evidence index, historical review status, and generated version for each candidate semantic-carrying relationship. Among them, the graph structure features are used to quickly locate the neighborhood information of the candidate pair in the dual graph in the subsequent constraint detection (step S300), and the evidence index is used to reference the corresponding evidence in the subsequent evidence package construction (step S400).
[0066] The system outputs a set C of candidate semantic-carrying relations, which can be represented as:
[0067] Where C represents the set of candidate semantic-carrying relations; Represents data-side node d i With business side node b j A candidate semantic carrying relationship between them; t ij Indicates the type of candidate semantic relationship; s ij Indicates the candidate confidence level; q ij Indicates the credibility of the candidate source; r ij Indicates historical review status; no-match indicates no candidate tags for stable business semantic objects; t0 indicates no matching candidate types; s i0 Represents data-side node d i The confidence level corresponding to no matching candidates; q i0 Indicates the credibility of no matching candidate source; r i0 This indicates a historical review status with no matching candidate.
[0068] Step S200: Sort the candidate semantic carrying relationships sequentially, perform multi-source fusion and Top-K compression, and output a global candidate set to be processed.
[0069] This step aims to sort, fuse multiple sources, and compress the candidate semantic bearer relationship set generated by S100, in order to reduce the number of candidates for subsequent verification and processing, while retaining high-quality candidate semantic bearer relationships.
[0070] S201: Calculate the ranking score based on the multi-source features of the candidate semantic carrying relationship.
[0071] The system input S103 outputs the candidate semantic carrying relation set C and the candidate confidence s. ij Credibility of candidate sources q ij Historical review status r ij Compatibility with candidate types T ij .
[0072] The system calculates the candidate ranking score based on the candidate confidence weight α, the candidate source confidence weight β, the historical review status weight γ, and the candidate type compatibility weight λ.
[0073] Among them, R ij Represents data-side node d i With business side node b j The ranking score of candidate semantic carrying relationships between them; α, β, γ and λ represent weight parameters, the values of which can be determined based on validation samples or expert configuration; H(r ij ) represents the historical review status mapping function, used to map historical review statuses (such as accepted, rejected, pending review) to numerical values; T ij This indicates the compatibility of candidate types. A higher value is taken when the candidate semantic relationship type is compatible with the business-side node type; otherwise, a lower value is taken.
[0074] The system outputs a set C of candidate semantic-carrying relations with ranking scores. R C R This indicates an increase in the sorting score R. ij The subsequent set of candidate semantic carrier relationships. By introducing source credibility, historical verification status, and type compatibility, the ranking score can prioritize candidate semantic carrier relationships with high confidence, high credibility, historical confirmation, and type matching, making it easier for subsequent compression steps to retain more reliable candidates.
[0075] S202: Perform multi-source fusion of candidate semantic bearing relationships for the same data-side nodes and the same business-side nodes.
[0076] The system input is a set C of candidate semantic bearer relations with ranking scores. R Because multiple candidate generation modules may target the same data-side node d. i and the same business-side node bj When multiple candidate records are generated (e.g., the semantic recognition module and the rule matching module simultaneously output the same pair of candidate semantic relationships), the system performs the same analysis on the same data-side node d. i and the same business-side node b j The candidate semantic carrier relationships are merged, and the scores, source credibility and evidence summaries of each candidate source are retained.
[0077] When conclusions from different sources are consistent, the system increases the processing priority of candidate semantic-carrying relationships; when conclusions from different sources conflict, the system retains the conflict marker I. src (d i ,b j ), where I src (d i ,b j ) represents the candidate semantic carrying relation (d i ,b j Does the source conclusion conflict?
[0078] The system outputs a fused set of candidate semantic-carrying relations, C. F C F This represents the set of candidate semantic bearer relations after fusion from multiple sources. The fusion process reduces duplicate candidates in subsequent processing, while providing additional evidence clues for subsequent steps through source consistency and conflict marking.
[0079] S203: For each data-side node, retain the top K candidate semantic carrying relationships with the highest sorting scores and retain the corresponding unmatched candidates. Merge the candidates from each data-side node and output a global set of candidates to be processed.
[0080] The system input is the fused set of candidate semantic-carrying relations C F The threshold K for the number of candidates to retain and the condition for no matching candidates. For each data-side node d i The system selects all business candidates from the data-side node according to their sorted scores R. ij The top K business candidates are retained, along with the no-match candidates corresponding to the data-side node.
[0081] The system outputs a compressed set of candidate data to be processed:
[0082] Among them, C'(d i ) indicates that the data-side node d i Compressed candidate set to be processed; TopK K (•) indicates the score R in sorting order. ijThe top K candidates from the input candidate set are retained; "no-match" indicates candidate labels without stable business semantic carriers; s i0 q i0 and r i0 They represent the data-side node d respectively. i The confidence level, source credibility, and historical verification status are corresponding to the absence of matching candidates.
[0083] The system merges the candidate sets to be processed corresponding to each data-side node to form a global candidate set to be processed:
[0084] Where C' represents the global set of candidate cases to be processed, which serves as the input for the subsequent step S300.
[0085] Step S300: Perform dual-graph constraint detection on the global candidate set to be processed, and perform candidate splitting based on candidate confidence and constraint detection results.
[0086] This step aims to perform constraint detection on the candidate set to be disposed of from the S200 compressed candidate set, based on the hierarchy, relation endpoints, structural neighborhoods and process paths of the standard data base graph and business semantic graph, and determine the candidate diversion result by combining the candidate competition result and the no-match trigger result.
[0087] S301: Calculate the score interval between the highest and second-highest service candidates for each data-side node. When the score interval is less than or equal to a preset score interval threshold, a candidate competition marker is formed and used together with the dual-graph constraint detection result for candidate splitting.
[0088] System input data side node d i The corresponding candidate set to be disposed of is C'(d) i For each data-side node d i The system starts from C'(d) i Select the business candidate with the highest ranking score R from the list. i(1) And the second highest ranked business candidate score R i(2) And calculate the fractional interval:
[0089] Where, Δ i Represents data-side node d i The score interval between the highest and second-highest business candidate; R i(1) Represents data-side node d i The corresponding highest business candidate ranking score; R i(2) Represents data-side node d iThe corresponding second-highest business candidate ranking score.
[0090] When Δ i ≤τ Δ At that time, the system will send data-side node d i The corresponding candidate is marked as a candidate with candidate competition, where τ Δ This represents the score interval threshold. The smaller the score interval, the less obvious the advantage between the highest and second-highest candidates, indicating selection uncertainty. The candidate competition marker, along with the candidate confidence, no-match trigger marker, and dual-graph constraint detection results, are used together to determine the candidate splitting result.
[0091] S302: When the confidence level of no matching candidate is greater than or equal to the preset no-match trigger threshold, the corresponding data-side node is marked as a no-match candidate.
[0092] For each data side node d i System input data side node d i The corresponding highest business candidate ranking score R i(1) No matching candidate confidence s i0 And the no-match trigger threshold τ0.
[0093] When the confidence level of no matching candidate is greater than or equal to the preset no-match trigger threshold, the system marks the corresponding data-side node as a no-match candidate. This judgment is used to identify data-side nodes that do not have stable business semantic carrying objects.
[0094] The system outputs no matching trigger flag Inm(d) i ).
[0095] S303: Perform constraint detection on candidate semantic bearing relationships, the constraint detection including hierarchical consistency detection and relation endpoint consistency detection, and output candidate conflict markers.
[0096] The system inputs candidate semantic bearer relationships, business process stages, business object types, field data types, business rules, inter-table relationship endpoints, historical review results, and directory version information. Based on the data-side node identifiers, business-side node identifiers, graph structure features, and / or evidence indexes associated with the candidate semantic bearer relationships, it obtains their hierarchical position, structural neighborhood, relationship endpoints, and related path information in the standard data base graph and business semantic graph.
[0097] The system detects the following types of conflicts respectively: 1) Business phase conflict: The business phase corresponding to the candidate semantic carrying relationship is inconsistent with the actual process phase; 2) Object conflict: The business object type corresponding to the candidate semantic relationship is inconsistent with the actual data-side node type; 3) Field type conflict: The data type of the candidate field is inconsistent with the expected type of the business attribute; 4) Rule conflict: The semantic relationship of the candidate violates the established business rules or indicator definitions; 5) Inconsistent hierarchy: When the candidate semantic relationship involves both table-level business objects and field-level business attributes, the field candidate is inconsistent with the business object candidate of its table. 6) Unclosed Relationship Endpoints: The mapping between the business objects in the tables at both ends of the data relationship and the objects at both ends of the business relationship are not closed; 7) Historical review conflicts: There are rejection or negative opinions in the historical review records; 8) Directory version conflict: There is a conflict between the candidate semantic carrying relationship and the current semantic directory version.
[0098] When candidate semantic relationships involve both table-level business objects and field-level business attributes, the system can use the following formula to calculate hierarchical consistency constraints:
[0099] Among them, Ψ hier Indicates hierarchical consistency deviation; S TF A matrix representing the membership relationships between tables and fields; A candidate mapping matrix representing fields to business attributes; This represents a candidate mapping matrix from tables to business objects; A matrix representing the membership relationships between business objects and business attributes; Let Ψ denote the F-norm of the matrix. hier When it is larger, it indicates that the candidate field is related to its The system has inconsistent business object candidates in the relevant tables. This can be used as evidence of object conflict or business phase conflict.
[0100] When candidate semantic relationships involve inter-table relationships, field mapping relationships, transformation paths, or write-back paths, the system can use the following formula to calculate endpoint consistency between data relationship e and business relationship g:
[0101] in, This indicates endpoint consistency between data relation e and business relation g; src(•) and dst(•) represent the source and target endpoints of the relation, respectively. When When the threshold is lower than the preset endpoint threshold, it indicates that the assets at both ends of the data relationship and the objects at both ends of the business relationship cannot be closed, and the system uses this as evidence that the relationship endpoints are not closed.
[0102] The system inputs the business stage, object type, field type, rule constraints, hierarchical consistency, relation endpoint consistency, and historical review results into the conflict determination function:
[0103] Where Φ(•) represents the conflict determination function; Ψ stage Ψ obj Ψ type and Ψ rule These represent conflicts related to business stage, object type, field type, and rule constraint, respectively; H ij This indicates the results of a historical review.
[0104] The system outputs candidate conflict markers I based on the conflict intensity. conf (d i ,b j ): When there is no conflict, I conf (d i ,b j )=0; when there is a minor conflict or insufficient evidence, I conf (d i ,b j )=1; when a serious conflict exists, I conf (d i ,b j =2.
[0105] S304: Form candidate splitting conditions based on the candidate competition flag, the no-match trigger flag, and the candidate conflict flag.
[0106] System input fractional interval Δ i No matching trigger flag I nm (d i ), Candidate Conflict Label I conf (d i ,b j ), fractional interval threshold τ Δ And the no-match trigger threshold τ0.
[0107] The system calculates the candidate labeling function to be verified:
[0108] Among them, I bd (d i ) represents the data-side node d i Does a boundary candidate exist? 1(•) indicates an indicator function; I nm (d i ) represents the data-side node d i Whether to trigger a no-match check; max j I conf (d i ,bj ) indicates the data-side node d i The maximum conflict intensity is taken for all business candidate semantic carrying relationships; ∨ represents logical OR.
[0109] The system outputs the set of candidates to be verified:
[0110] Among them, C bd This represents the set of candidates to be verified.
[0111] S305: Determine the candidate diversion result based on the candidate diversion conditions.
[0112] The system inputs a global set of candidate cases to be processed, C', and a set of candidate cases to be verified, C'. bd Candidate confidence level s ij Fractional interval Δ i No matching candidate confidence s i0 No matching trigger flag I nm (d i ), Candidate Conflict Label I conf (d i ,b j ) and historical review results H ij And read high confidence through threshold τ w Fractional interval threshold τ Δ And the no-match trigger threshold τ0.
[0113] When s ij ≥τ w Δ i >τ Δ s i0 <τ0、I nm (d i )=0 and I conf (d i ,b j When )=0, the corresponding candidate is classified as a direct confirmation candidate.
[0114] When a candidate belongs to the candidate set C to be verified bd I conf (d i ,b j )<2 and H ij If a situation does not fall under a historical conflict state, it is classified as a candidate for model validation.
[0115] When H ij When a historical conflict occurs, the corresponding candidate will be classified as a candidate awaiting manual review.
[0116] When I conf (d i ,b jWhen s = 2, the corresponding candidate is classified as a candidate rejection object; when s i0 When ≥τ0 and the business candidate lacks stable support, the corresponding data-side node will be classified as an object without matching confirmation.
[0117] Of these, only candidates awaiting model validation and candidates awaiting manual review proceed to steps S400 and S500. Candidates awaiting model validation have an evidence sufficiency score below τ. E When the model output is uncertain, the model results conflict with the evidence package, or involve writing to a critical business directory, the process will be redirected to manual review.
[0118] Step S400: Construct a filtered business evidence package from the standard data base map and the business semantic map for the candidate to be verified, and calculate the evidence sufficiency score based on the filtered business evidence package.
[0119] This step aims to construct a filtered business evidence package based on the candidate semantic carrying relationships and calculate the evidence sufficiency score, providing structured input for subsequent dual-graph evidence verification. The candidates to be verified include candidates to be verified by the model and candidates to be manually reviewed.
[0120] like Figure 2 As shown, the system uses candidate semantic bearer relations (d) to be verified. i ,b j Centered on the standard data foundation graph and the business semantic graph, the scope (d) of evidence extraction is determined. i ,b j Evidence related to the current candidate semantic bearing relationship is extracted from the evidence extraction range and combined to form a filtered business evidence package E(d). i ,b j The system calculates the sufficiency score Q based on the filtered business evidence package. E And generate a structured validation request Req(d) i ,b j The evidence sufficiency score and structured verification request will then be output to step S500.
[0121] S401: Determine the scope of evidence extraction based on candidate semantic carrying relationships.
[0122] The system inputs the semantic bearer relationship of the candidate to be processed (d) i ,b j ), data-side node context, business semantic context, field dictionary, inter-table relationships, process path, field mapping rules, write-back rules, indicator definitions, historical review records, and governance issue records.
[0123] The system uses candidate semantics to carry relations (d) i ,bj Centered on the evidence index or graph structure features of candidate semantic relationships, the system locates the evidence extraction range in the standard data base graph and business semantic graph. Only evidence related to the candidate semantic relationship is extracted; unrelated entire table fields, full lineage links, or large segments of business text are excluded. By limiting the evidence extraction range, the system avoids introducing irrelevant information into the subsequent verification process and reduces the input scale that the verification model needs to process.
[0124] The system outputs the evidence extraction scope (Scope(d)) of candidate semantic-carrying relationships. i ,b j ), where Scope(d i ,b j ) represents the semantic relationship carried by the candidate (d) i ,b j The determined scope of evidence retrieval and extraction is used for subsequent evidence extraction in S402 to S403.
[0125] S402: Extract evidence from the evidence extraction range and combine it into a filtered business evidence package.
[0126] The system starts from Scope(d) i ,b j Extract the Chinese field name, English field name, field alias, field comment, table name, system, business process node, field dictionary, sample value, and business object description from the data to form name and context evidence E. name .
[0127] The system extracts the relevant table, upstream and downstream fields, primary and foreign key relationships, logical associations, and structural neighborhoods to form structural evidence E. struct Structural evidence is used to illustrate the position of candidate data side nodes in the standard data base diagram and their relationship with surrounding data elements.
[0128] The system extracts source table, target table, field mapping path, transformation path, process path, write-back path, and traceability path to form path evidence E. path Path evidence is used to illustrate the position of candidate data-side nodes in the business process and their flow relationships with other data elements.
[0129] The system extracts business rules, indicator definitions, dictionary values, transformation rules, write-back rules, and applicable scope to form rule evidence E. rule .
[0130] The system extracts name consistency, dictionary consistency, path consistency, rule consistency, and historical acceptance records to support the establishment of candidate semantic bearer relationships, forming supporting evidence E. support .
[0131] The system extracts business phase conflicts, object conflicts, field type conflicts, rule conflicts, non-closed relation endpoints, and historical rejection records to form conflict evidence E. conflict .
[0132] The system extracts candidate ranking, candidate score interval, no-match candidate position, and candidate source information to form ranking evidence E. rank .
[0133] The system extracts historical governance results, manual review comments, reasons for rejection, no-match confirmation records, governance issue processing status, and version change records to form historical evidence E. history .
[0134] The system combines the various types of evidence extracted above into a filtered business evidence package:
[0135] Among them, E(d) i ,b j ) indicates surrounding the data-side node d i With business side node b j Constructed filter-based business evidence packages.
[0136] S403: Calculate the sufficiency score of the evidence based on the filtered business evidence package, and generate a structured verification request.
[0137] System input filtering business evidence package E(d) i ,b j The name evidence score Q is calculated using the evidence weight parameters and other parameters. name Structural evidence score Q struct Path Evidence Score Q path Rule-based evidence scoring Q rule Supporting evidence scoring Q support Historical Evidence Score Q history Conflict Evidence Score Q conflict Each piece of evidence is scored based on the degree to which the corresponding evidence is satisfied, and is uniformly normalized to a range of 0 to 1. A higher value is taken when the evidence fully supports the candidate semantic relationship; when it partially supports it, the score is determined based on the number of satisfied evidence items or the proportion of evidence content; and a score of 0 is taken when no corresponding evidence is found, and it is recorded as evidence missing.
[0138] The system calculates the sufficiency of evidence score according to the following formula:
[0139] Among them, Q E (d i ,b j) represents the candidate semantic carrying relation (d i ,b j The sufficiency of evidence is scored; w1 to w7 represent the weights of evidence, corresponding to name, structure, path, rule, supporting, historical, and conflicting evidence, respectively; the score for name evidence is Q. name The degree of support for the names, aliases, and field descriptions of the corresponding candidates; structural evidence score Q. struct The degree of consistency between the candidate parties in terms of their respective tables, business objects, neighboring nodes, and relationship types; path evidence score Q. path The degree of consistency between the corresponding data-side path and the business-side process path; rule evidence score Q. rule The degree to which the corresponding field dictionary, indicator definitions, conversion rules, and business rules are satisfied; evidence scoring Q is supported. support Corresponding to the quantity and consistency of evidence that directly supports the candidate's validity; Historical evidence score Q history The degree of support for historical review and catalog maintenance records; Conflict evidence score Q conflict The severity of conflicts corresponding to business stages, objects, field types, rules, non-closed relation endpoints, and historical rejected records.
[0140] The system generates a structured verification request based on the filtered business evidence package:
[0141] Among them, Req(d i ,b j The ) indicates a structured validation request; Template(•) indicates a validation request template function used to organize evidence packets and candidate information into an input format acceptable to the subsequent validation model; R ij Indicates the candidate ranking score; Δ i Indicates fractional interval; I conf (d i ,b j The symbol ) indicates a candidate conflict marker. A structured validation request includes the data-side node context, business semantic definition, supporting evidence, conflict evidence, candidate ranking, score interval, conflict marker, and the issue to be validated.
[0142] The system outputs a sufficiency score for evidence, Q. E (d i ,b j ) and structured validation request Req(d i ,b j ), as input to S500.
[0143] Step S500: Perform dual-spectrum evidence verification and determine the verification result.
[0144] This step aims to perform differentiated verification processing on the semantic bearer relationships of the candidates to be processed based on the filtered business evidence package and evidence sufficiency score constructed by S400, and to determine the verification result of each candidate from top to bottom through a segmented function. Dual-graph evidence verification is performed on the candidates to be verified to determine the verification result; other traffic results besides the candidates to be verified do not invoke the verification model.
[0145] S501: Determine the input for dual-spectrum evidence verification.
[0146] The system inputs candidate semantic carrying relation (d) i ,b j ), candidate confidence level s ij Candidate ranking score R ij Fractional interval Δ i Sufficiency of evidence score Q E (d i ,b j ), Candidate Conflict Label I conf (d i ,b j Candidate type compatibility T ij Historical review results H ij No matching candidate confidence s i0 and structured validation request Req(d i ,b j ).
[0147] The system reads high confidence threshold τ w 1. Threshold for sufficiency of evidence τ E Fractional interval threshold τ Δ And the no-match trigger threshold τ0.
[0148] S502: Perform the candidate route judgment. Directly confirm that the candidate has been determined by step S300, and do not repeat the verification in this step.
[0149] When s ij ≥τ w Q E (d i ,b j )≥τ E Δ i >τ Δ And I conf (d i ,b j When )=0, the system will verify the candidate semantic carrying relationship as directly passed and output the verification result pass.
[0150] S503: Perform model verification judgment.
[0151] When the candidate semantic carrying relationship belongs to the candidate set C to be verifiedbd And there is no serious conflict (I conf (d i ,b j When )≠2), the system will send the structured verification request Req(d) i ,b j The system can input rule validators, language model validators, or other semantic verification models. The selection logic among these models is configurable; the system selects the appropriate verification model based on the candidate relation type, verification requirements, or application scenario. The language model validator includes a large language model validator, but the output of the large language model is not used as the final arbiter; instead, it serves as structured verification results and explanatory evidence for subsequent governance actions.
[0152] The verification model determines whether the candidate semantic carrying relationship satisfies business semantic consistency, structural path consistency, rule consistency, and historical evidence consistency based on the filtered business evidence package.
[0153] The validation model outputs the structured model validation results:
[0154] Among them, M(d) i ,b j ) represents the candidate semantic carrying relation (d i ,b j The model validation result; Ω(•) represents the rule validator, language model validator, or other semantic validation model; y ij This represents the model's judgment label, with values including support, oppose, and uncertain, representing support, opposition, and uncertainty, respectively. Indicates the confidence level of model validation; This represents the explanatory evidence for the model's output; This indicates a label representing a governance issue discovered by the model.
[0155] The system will validate the model results M(d) i ,b j ) and the sufficiency of evidence score Q E (d i ,b j ), Candidate Conflict Label I conf (d i ,b j ) and historical review results H ij Joint validation. When the model determines the label as support and the model validation confidence level reaches the model validation threshold τ. M When the model determines the label as "oppose" and the model's validation confidence reaches τ, the output is "verify". MWhen the model determines the label as uncertain and the model validation confidence is below τ, the output is "reject"; when the model determines the label as uncertain and the model validation confidence is below τ, the output is "reject". M If the model output conflicts with the evidence package, output the manual review result.
[0156] In one embodiment, the prompt words for large model validation are as follows: You are the data governance semantic relation validator. Based solely on the input candidate semantic relationships and filtered business evidence packages, determine whether a data-side node can support a specified business-side node. Do not introduce facts outside the evidence packages. Output only JSON, not interpretable natural language.
[0157] enter: { "data_asset": { "asset_id": "field_pr_detail_apply_qty", "table": "Purchase Request Details", "field": "Number of applications", "type": "decimal", "comment": "Quantity of materials requested for purchase", "context_fields": ["Purchase requisition number", "Material code", "Requisitioning department", "Date of request", "Unit of measurement"] }, "business_semantic_unit": { "semantic_id": "bsu_purchase_requisition_quantity", "name": "Quantity of Purchase Request", "type": "Business Attribute", "definition": "The quantity of materials required during the purchase requisition phase, used to express the required quantity of a specific material in the purchase requisition." }, "candidate": { "candidate_relation": "Purchase requisition details. Requested quantity -> Purchase requisition quantity", "candidate_type": "Field to business attribute", "candidate_confidence": 0.91, "rank_score": 0.89, "score_gap": 0.17, "evidence_sufficiency_score": 0.82, "conflict_flag": 0, "no_match_confidence": 0.18 }, "evidence": { "name": "The field name 'Application Quantity' is consistent with the business attribute 'Purchase Application Quantity' in name." "structure": "This field is located in the purchase requisition details table, which includes context fields such as purchase requisition number, material code, requisition department, required date, and unit of measurement." "path": "The purchase requisition precedes the purchase order, conforming to the business process where the requested quantity precedes the ordered quantity." "rule": "The application quantity can be used as the source field for the quantity of subsequent purchase orders, but it is not equivalent to the received quantity or the quantity put into storage." "support": [ "The field name matches the business attribute name." "The field is located in the purchase requisition details table, which corresponds to the purchase requisition stage." "The process path shows the procurement requesting unit before the purchase order." Historical evidence shows that fields with the same name in the same business domain were previously manually accepted as the quantity of purchase requests. ], "history": "A field with the same name in the same business domain was previously manually accepted as the quantity of a purchase request." "conflict": [] }, "output_schema": { "y_ij": "support | oppose | uncertain", "c_ij^M": "A decimal number between 0 and 1", "e_ij^M": "Refers to the key evidence array in the evidence package; no new external facts may be added." "z_ij^M": "A list of governance issues flagged for missing fields, missing field descriptions, missing transformation rules, inconsistent write-back endpoints, missing inter-table relationships, missing business semantic concepts, and conflicting or missing historical directories." } }
[0158] The above example prompt words illustrate one implementation of a language model validator receiving structured verification requests and outputting structured model verification results. Here, `data_asset` describes the data-side node to be verified, `business_semantic_unit` describes the candidate business-side node, `candidate` describes the candidate semantic carrier relationship and its candidate confidence, ranking score, score interval, evidence sufficiency score, conflict marker, and no-match candidate confidence, `evidence` describes the filtered business evidence package constructed around the current candidate semantic carrier relationship, and `output_schema` constrains the model output fields and their value ranges. The language model validator makes judgments only based on the input filtered business evidence package. The output `y_ij`, `c_ij^M`, `e_ij^M`, and `z_ij^M` correspond to the model judgment label, model verification confidence, explanatory evidence of the model output, and governance issue markers discovered by the model, respectively. This example prompt word is only one implementable configuration; the field names, number of fields, prompt text, and model type can be adjusted according to the business domain, data infrastructure structure, and validator implementation method, and are not intended to limit the scope of protection of this invention.
[0159] S504: Perform manual review and judgment.
[0160] When the sufficiency of evidence score is below τ E When there are conflicts in historical review results, the verification model cannot provide stable conclusions, or the candidate semantic bearing relationship involves writing to a critical business directory, the system will write the candidate semantic bearing relationship to the manual review path and output the verification result review.
[0161] S505: Perform rejection and no-match judgment.
[0162] When I conf (d i ,b j When )=2, the system outputs the candidate rejection result: reject.
[0163] When s i0 When ≥τ0 and there is insufficient evidence for business candidates, the system outputs no-match result.
[0164] When a no-match state simultaneously exposes missing field dictionaries, missing business semantic concepts, missing field descriptions, or missing data-side node modeling, the system outputs a governance issue flag.
[0165] S506: Use piecewise functions to represent selective verification results.
[0166] The system determines priorities from top to bottom according to the following piecewise function: when a candidate semantic relationship satisfies multiple conditions simultaneously, the verification result corresponding to the condition that is satisfied first is used first.
[0167] Wherein V(d) i ,b j ) represents the candidate semantic carrying relation (d i ,b j Selective verification results of G; issue (d i ,b j ) indicates whether the candidate semantic relationship triggers a governance issue flag; τ w Indicates the high-confidence pass threshold; τ E τ represents the threshold for sufficiency of evidence. M H represents the confidence threshold for model validation. ij Indicates historical review results; y ij This indicates that the model determines the label; Indicates the confidence level of model validation; This indicates a governance issue flag identified by the model; y is used when model validation is not invoked. ij empty tags =0 and =0; flag, reject, no-match, pass, review, and verify represent flag governance respectively. Question, Reject Candidate, Confirm No Match, Direct Pass, Enter Manual Review, and Model Validation Pass. Verify is mapped to write when the write condition is met, otherwise it is mapped to review; ∧ represents logical AND.
[0168] Step S600: Generate governance actions based on candidate traffic splitting results and verification results, and write the governance actions into the corresponding governance objects.
[0169] This step aims to generate executable governance actions such as write, review, reject, no-match, and flag based on the candidate routing results of S305 and the verification results of S500, and write them to the corresponding governance objects.
[0170] S601: Generate governance actions.
[0171] The system inputs the selective verification result V(d) i ,b j ), candidate confidence level sij Filtered business evidence package E(d) i ,b j ), historical review results H ij Governance issues are marked with G issue (d i ,b j ).
[0172] The system generates governance actions through a governance action routing function:
[0173] Among them, A(d) i ,b j ) indicates that the candidate semantic carrier relation (d) i ,b j The generated data governance actions; Ψ(•) represents the governance action routing function; write, review, reject, no-match and flag represent writing to the business semantic directory, entering manual review, rejecting candidates, confirming no match and marking governance issues, respectively.
[0174] S602: Determine the object to be written for governance actions.
[0175] System input governance action A(d) i ,b j The write target is determined based on the governance action:
[0176] Where O(A) represents the write object corresponding to governance action A; O dir Represents a business semantic directory; O rev Indicates the manual review queue; O rej Indicates candidate rejection record; O nom Indicates no matching list; O flag This indicates a list of governance issues.
[0177] S603: Perform business semantic directory writing.
[0178] When the governance action is "write", the system writes the data-side node identifier, business-side node identifier, candidate type, evidence package digest, write time, source version, effective status, and traceable evidence link into the business semantic directory O. dir .
[0179] S604: Perform manual review queue writing.
[0180] When the governance action is "review", the system writes the candidate semantic bearer relationship into the manual review queue O. revThey also presented the reviewers with supporting evidence, conflicting evidence, candidate ranking, recommended actions, issues to be confirmed, and historical review records.
[0181] S605: Writes due to rejection, no match, or governance issues.
[0182] When the governance action is "reject", the system writes the candidate semantic bearer relationship into the candidate rejection record O. rej It also saves the reasons for rejection, evidence of conflict, verification results, reviewer comments, and version information.
[0183] When the governance action is "no-match", the system writes the data-side nodes into the no-match list O. nom It also records the reason for no match, field type, source system, historical confirmation results, and subsequent review cycle.
[0184] When a governance action is flagged, the system adds the issue to the governance issue list O. flag The governance issues include missing field dictionaries, missing field descriptions, missing conversion rules, inconsistent write-back endpoints, missing inter-table relationships, missing business semantic concepts, historical directory conflicts, and missing data-side node modeling.
[0185] Step S700: Collect review feedback information and update the standard data base map, business semantic map, and governance strategy parameters.
[0186] This step aims to collect feedback information and update governance strategy parameters based on the results of manual review and governance issue handling, so as to continuously optimize the candidate disposal strategies for subsequent batches.
[0187] S701: Collect feedback information.
[0188] The system inputs manual review results, governance issue handling results, catalog maintenance results, no-match confirmation results, and version change records.
[0189] The system will display the feedback information as follows:
[0190] in, Let t represent the feedback set of the t-th round; This indicates acceptance of the feedback; This indicates a refusal to provide feedback; Indicate the review comments; This indicates that no matching confirmation has been received. This indicates feedback on the handling of governance issues; This indicates feedback on version changes.
[0191] System output feedback set Where t is the governance feedback iteration round, and the initial value can be 0 or 1. Whenever the system completes the processing of a batch of candidate semantic carrying relationships and collects the corresponding acceptance, rejection, review, no-match confirmation, problem handling or version change feedback, it forms the current round feedback set and performs a governance strategy parameter update; after the update is completed, the round number increments, entering the (t+1)th round.
[0192] S702: Update governance strategy parameters.
[0193] The system inputs the set of governance strategy parameters for the t-th round. Feedback set And update step size η.
[0194] The system updates the governance strategy parameters according to the following formula:
[0195] in, This represents the set of governance strategy parameters for round t, which includes at least the evidence filtering rules, no-match rules, action diversion threshold, candidate source credibility, and review priority. This represents the updated set of governance strategy parameters; η represents the feedback update step size; and U(•) represents the feedback update function. The system outputs the updated set of governance strategy parameters. .
[0196] S703: Update the rules for handling subsequent candidates.
[0197] Based on the updated governance strategy parameters, the system executes the following rule updates:
[0198] When the review results indicate that a certain type of candidate semantic bearing relationship is stable and accepted, the system increases the automatic writing priority of candidates with the same source or the same evidence pattern.
[0199] When the review results indicate that a certain type of candidate semantic carrying relationship is stable and is rejected, the system reduces the recommendation priority of candidates with the same conflict mode.
[0200] When the review results confirm that a certain type of data-side node has no stable business semantic carrier object, the system updates the no-match rule.
[0201] When the review results point to a gap in the governance of the data foundation or business semantic graph, the system will include the issue handling status in the subsequent candidate disposal judgment.
[0202] The system outputs updated evidence filtering rules, no-match rules, action diversion thresholds, candidate source credibility, review priority, and business semantic graph version. Specific Implementation
[0204] This embodiment uses an experimental dataset of a procurement collaboration process to illustrate the data governance method of the present invention. This experimental dataset originates from the data foundation assets, process configurations, field mapping rules, write-back rules, field dictionaries, business semantic definitions, and expert review records in the procurement collaboration process of discrete manufacturing enterprises. It covers nodes such as sales order triggering, production material list generation, purchase requisition, purchase order and purchase contract, material receiving notification, purchase warehousing, and purchase invoice, reflecting the typical business chain of demand-driven procurement, material receiving, and invoice closure in discrete manufacturing enterprises.
[0205] Experimental Data Preparation: In one embodiment, the experimental dataset for the procurement collaboration process comes from three business system databases: the sales and contract database, the production and materials database, and the procurement and inventory database. These three databases contain a total of 48 business tables, 1260 fields, 86 inter-table relationship paths, 37 field mapping rules, 19 status write-back rules, and approximately 1.2 million sample business records. The data foundation maintains 934 field dictionaries, 1086 field comments, 73 primary / foreign key or logical association configurations, 416 historical directory records, and 947 manually reviewed records.
[0206] The experimental dataset for the procurement collaboration process includes three task subsets: a procurement requirement generation task subset, a procurement execution collaboration task subset, and a warehouse receipt invoice closure-loop task subset. The procurement requirement generation task subset mainly covers data-side nodes such as sales orders, production material lists, and purchase requests; the procurement execution collaboration task subset mainly covers data-side nodes such as purchase requests, purchase orders, purchase contracts, and material receipt notices; and the warehouse receipt invoice closure-loop task subset mainly covers data-side nodes such as material receipt notices, procurement receipt, purchase invoices, invoice verification, and status write-back. Each task subset includes a set of fields to be covered by the task, a set of core tables to be covered by the task, a set of relationship paths to be covered by the task, a set of candidate assets for system output, a set of governance actions for system output, and expert review results.
[0207] In this embodiment, the system constructs 7 business objects, 42 business attributes, 12 business relationships, and 8 state-type business-side nodes, totaling 69 business-side nodes. The candidate generation module outputs 3826 initial candidate semantic relationships, including 3148 field-to-business attribute candidate semantic relationships, 218 table-to-business object candidate semantic relationships, 263 relationship path-to-business relationship candidate semantic relationships, and 197 no-match candidate semantic relationships. After candidate compression, the system retains 1284 candidate semantic relationships to be processed, of which 376 are candidates to be verified.
[0208] In this embodiment, the parameters are configured as follows: Top-K candidate retention threshold K=5; high confidence pass threshold τ. w=0.85; No-match trigger threshold τ0=0.60; Score interval threshold τ Δ =0.08; Threshold for sufficiency of evidence τ E =0.70; Model validation confidence threshold τ M =0.75; Feedback update step size η=0.05. In the candidate confidence calculation weights, a1=0.25, a2=0.25, a3=0.20, a4=0.20, a5=0.10, a0=0.20. In the evidence sufficiency score weights, w1=0.15, w2=0.10, w3=0.15, w4=0.10, w5=0.20, w6=0.10, w7=0.20. The above parameters are used to illustrate one implementable configuration of the present invention and are not intended to limit the scope of protection of the present invention.
[0209] Experimental Step 1: Construct a dual graph of the procurement process and generate cross-graph candidate semantic carrying relationships.
[0210] The system reads the 48 business tables, 1260 fields, 86 inter-table relationship paths, 37 field mapping rules, and 19 status write-back rules corresponding to the above documents from the data base, and registers the fields, tables, relationship paths, transformation rules, and write-back rules as data-side nodes.
[0211] The system extracts business objects such as purchase requisitions, purchase orders, purchase contracts, material receipt notices, purchase receipts, purchase invoices, and invoice verification from business process configurations and business semantic definitions, and extracts business attributes such as application quantity, order quantity, material receipt quantity, warehouse receipt quantity, tax-inclusive amount, tax rate, invoice verification status, and synchronization status.
[0212] The system merges the candidate results output by the semantic recognition module, rule matching module, vector retrieval module, optional graph representation learning module, historical directory migration module, and expert configuration module to form field-level, table-level, relation-level, and no-match candidate semantic carrying relationships. The graph representation learning module can use methods such as relation-aware graph attention networks to learn structural neighborhood features in the standard data base graph to assist in generating candidate semantic carrying relationships, but the candidate generation method does not limit the scope of protection of this invention.
[0213] Experimental Step Two: Perform candidate compression, dual-graph constraint detection, and five-class flow division on the candidate semantic carrying relationships of the procurement process.
[0214] The system sorts the 3,826 initial candidate semantic bearer relationships according to candidate confidence, candidate source credibility, and historical verification status, and retains Top-K candidates for each data-side node, where K=5.
[0215] The system retains no-match candidates and uses synchronization status, deletion flag, interface control status, temporary calculation fields, batch processing fields, and audit fields as no-match confirmation objects or governance issue identification objects.
[0216] The system calculates the candidate score interval. When the score interval between the highest and second-highest candidates is less than or equal to 0.08, a candidate competition marker is formed, and the five types of diversion results are determined in combination with the dual-graph constraint detection results; when the confidence of the no-match candidate is greater than or equal to 0.60, the corresponding data-side node is included in the no-match confirmation process.
[0217] The system identifies business stage conflicts, object conflicts, field type conflicts, rule conflicts, and non-closed relationship endpoints. For the application quantity field in a purchase requisition, if there is sufficient evidence that the candidate semantic relationship carries the business attribute of the purchase requisition quantity, and the score is significantly different from other candidate scores, it will proceed to automatic write judgment. For quantity fields between purchase orders, receiving notices, and purchase receipts, if the candidate semantic relationship involves conversion rules, receiving rules, or warehousing rules, and the meanings of quantities at different stages are similar, it will be added to the candidate set to be verified.
[0218] The process of handling semantic relationships for a single candidate is illustrated using "Purchase Request Form. Request Quantity" as a field-level example. The system reads field d from the data base. i The table it belongs to is a purchase requisition form. The field name is "requisition quantity," the field type is numeric, and the field comment is the required quantity of materials to be purchased. The field dictionary includes the unit of quantity and precision configuration. The system generates candidate b1 (purchase requisition quantity) and candidate b2 (purchase order quantity) from the business-side node set, and retains no-match candidates. After the candidates are generated, (d i Candidate confidence s of b1) i1 =0.91, Source credibility q i1 =0.88, sorting score R i1 =0.89; (d i Candidate confidence s of b2) i2 =0.74, Source credibility q i2 =0.76, sorting score R i2 =0.72; no-match candidate confidence score s i0 =0.18. The system calculates the fractional interval Δ. i =R i1 -R i2 =0.17, which is greater than the score interval threshold of 0.08, therefore this field does not belong to the candidates with candidate competition; at the same time s i0 The value is below the no-match trigger threshold of 0.60, therefore the no-match confirmation process is not initiated.
[0219] The system revolves around (d) i b1) Construct a filtered business evidence package. Name evidence shows that the field name "Request Quantity" matches the business attribute "Purchase Request Quantity"; structural evidence shows that this field is located in the purchase requisition details table, and the same table contains context fields such as material code, requesting department, requirement date, and unit of measurement; path evidence shows that the purchase requisition precedes the purchase order, conforming to the business process of request quantity preceding order quantity; rule evidence shows that the request quantity can be used as a source field for the quantity in subsequent purchase orders, but is not equivalent to the received quantity or the quantity put into storage; historical evidence shows that the same field with the same name in the same business domain has been manually accepted as the purchase requisition quantity. Based on this, the system calculates the evidence sufficiency score Q. E (d i b1) = 0.82, Conflict marker I conf (d i ,b1)=0.
[0220] The system performs five categories of candidate traffic allocation, generates governance actions, and updates the dual-graph governance status. Due to s i1 =0.91 is greater than the high confidence pass threshold of 0.85, Q E (d i b1) = 0.82, which is greater than the sufficiency of evidence threshold of 0.70. i If the score is 0.17, which is greater than the score interval threshold of 0.08, and there are no conflicts in business stage, object, field type, or unclosed relation endpoints, the system will determine the selective verification result of the candidate semantic relationship as "pass" and generate a "write" action to write the relationship between the field "Purchase Request Form. Request Quantity" and the business-side node "Purchase Request Quantity" into the business semantic directory. For candidate b2 "Purchase Order Order Quantity", since its business stage is after the purchase request and its ranking score is lower than b1, the system will not write it into the directory results for this field.
[0221] After the above processing, the system retained 1,284 candidate semantic bearer relationships from the initial 3,826 candidate semantic bearer relationships, and determined a total of 376 candidates to be verified by the model and candidates to be manually reviewed.
[0222] Experimental Step 3: Construct the evidence package and generate governance output.
[0223] The system transforms the procurement process into data-side node packages such as demand sources, material requirements, purchase requisitions, procurement execution, material receipt and warehousing, invoice verification, and write-back status. It also constructs corresponding filtered business evidence packages for candidate semantic carrying relationships of fields, tables, and relational paths.
[0224] For core purchase orders and material fields, the system generates a write action when the candidate confidence level reaches 0.85, the evidence sufficiency score reaches 0.70, and there are no conflicts. For rule-dependent fields, fields with similar quantity stages, and fields requiring confirmation of write-back endpoints, the system generates a structured validation request and inputs it into the rule validator or large language model validator. The model outputs a judgment label, validation confidence level, explanatory evidence, and governance issue marker. When the model validation confidence level reaches 0.75 and supports evidence consistency, the system generates a write action; otherwise, it generates a review action. For status write-back fields and technical control fields, the system generates a no-match action. For fields with missing dictionaries, missing transformation rules, inconsistent write-back endpoints, or missing business semantic concepts, the system generates a flag action. For candidate semantic relationships that are significantly inconsistent with business stages or relationship endpoints, the system generates a reject action.
[0225] In this embodiment, 1284 candidate semantic bearer relationships awaiting processing were selectively verified and merged with similar issues to generate 993 governance outputs, including 462 write actions, 276 review actions, 128 reject actions, 117 no-match actions, and 10 flag actions. Among the 10 flag actions, 3 were missing field dictionaries, 2 were missing field descriptions, 2 were missing conversion rules, 1 had inconsistent write-back endpoints, 1 had missing inter-table relationships, and 1 had missing business semantic concepts.
[0226] Experimental Step 4: Define evaluation indicators and verify them using procurement process tasks as evaluation units.
[0227] This embodiment uses Field Recall (FR), Table Recall (TR), Path Correctness (PR), Asset Precision (AP), Task-Level Expert Acceptance (EA), Review Reduction (RR), and Number of Issues (QN) as task-level evaluation indicators to quantitatively analyze the governance and handling effect of this invention on candidate semantic relationships in the procurement collaboration process.
[0228] Field recall FR is calculated using the following formula:
[0229] Where, N fc N represents the number of task fields correctly discovered by the system, included in the candidate evidence chain, and eligible for governance and processing coverage. fa This indicates the total number of fields that the task should cover. Field recall measures the system's ability to cover task-related field assets.
[0230] The recall TR is calculated using the following formula:
[0231] Where, Ntc N represents the number of core documents correctly identified by the system and entering the candidate processing flow. ta This indicates the total number of core document tables that the task should cover. Table recall measures the system's ability to discover core table assets in the procurement process.
[0232] If the path is correct, the PageRank (PR) is calculated using the following formula:
[0233] Where, N pc N represents the number of relationship paths that have been confirmed as correct by experts. po This indicates the number of relational paths output by the system. Path correctness is used to measure whether the field mapping paths, process paths, traceability paths, or write-back paths output by the system can support the corresponding governance actions.
[0234] Asset accuracy (AP) is calculated using the following formula:
[0235] Where, N aa N represents the number of assets in the candidate data side nodes output by the system that have been confirmed by experts as acceptable and eligible for governance and disposal. ao This represents the total number of candidate data-side nodes output by the system. Asset accuracy is used to measure the governability and effectiveness of the candidate assets output by the system.
[0236] Task-level experts receive EA calculations according to the following formula:
[0237] Where, N ea N represents the number of task-level outputs that have been accepted after expert review. eo This indicates the total number of task-level outputs that have entered expert review or sampling confirmation. Task-level experts accept these outputs to measure the overall acceptability of the candidate assets, evidence packages, and governance recommendations generated by the system across the task dimension.
[0238] The reduction in RR upon review is calculated using the following formula:
[0239] Where, N all N represents the number of candidate outputs that require manual review when this invention is not used. review This indicates the number of candidate outputs that still require manual review after employing the candidate compression, filtering business evidence package, and selective verification methods of this invention. Review reduction is used to measure the ability of this invention to reduce the workload of manual review.
[0240] The issue count (QN) represents the number of issues discovered and added to the governance issue list by the system in the corresponding task. These issues include missing field dictionaries, missing field descriptions, missing transformation rules, inconsistent write-back endpoints, missing inter-table relationships, missing business semantic concepts, and conflicts in the historical directory. The issue count measures the ability of this invention to discover data foundation governance gaps beyond the generation of governance actions.
[0241] refer to Figure 3 This data displays the comprehensive governance results of the procurement collaboration process. The table recall for the three tasks—procurement requirement generation, procurement execution collaboration, and warehousing invoice closure—was 100.00%, indicating that the system can fully identify the core document assets supporting the governance and handling of the procurement process. Field recall rates were 95.24%, 93.33%, and 92.86% respectively, with a comprehensive field recall of 93.81%, indicating that most task fields could be identified and included in the candidate evidence chain. Figure 3 The field recall results correspond to the following: the procurement requirement generation task correctly identified 60 task fields and should have covered 63 task fields, resulting in a 95.24% success rate; the procurement execution collaboration task correctly identified 98 task fields and should have covered 105 task fields, resulting in a 93.33% success rate; the warehousing invoice closure task correctly identified 39 task fields and should have covered 42 task fields, resulting in a 92.86% success rate; and the three tasks combined correctly identified 197 task fields and should have covered 210 task fields, resulting in a comprehensive field recall rate of 93.81%.
[0242] Regarding the correctness of the path, the three tasks of procurement demand generation, procurement execution coordination, and warehousing invoice closure were 90.00%, 88.89%, and 87.50% respectively, with a combined score of 88.80%. Figure 3 The correct path results are consistent, but the closed loop of the invoice is slightly lower. This is mainly because the write-back relationship, invoice verification, and tax rate rules involve more complex endpoint constraints and business rules.
[0243] Regarding asset accuracy, the rates for the three tasks were 82.10%, 81.40%, and 80.20%, respectively, with an overall score of 81.23%. In terms of task-level expert acceptance, the rates for the three tasks were 84.00%, 83.10%, and 82.30%, respectively, with an overall score of 83.13%. Regarding the reduction in review, the rates for the three tasks were 76.50%, 74.80%, and 73.20%, respectively, with an overall score of 74.83%, all consistent with... Figure 3 The corresponding results are consistent.
[0244] In terms of the number of issues, 3 issues were found in the procurement requirement generation task, 4 issues were found in the procurement execution collaboration task, and 3 issues were found in the warehousing invoice closure task, for a total of 10 issues. This indicates that this method can discover governance gaps in the data foundation beyond recommending the correct fields and core document assets.
[0245] Experimental Step 5: Expert sampling verification of the treatment actions.
[0246] The system extracted 947 outputs from field mappings, table-level assets, relationship paths, and governance actions generated from a subset of the procurement process, categorized by governance action type: write, review, no-match, reject, and flag, for expert review. Reviewers checked each output against business semantic definitions, process rules, field dictionaries, and relationship endpoints to determine if it was suitable for the appropriate governance action. Verification results showed that 833 out of the 947 sampled outputs were accepted by experts, resulting in an expert acceptance rate of 87.96% for the governance action sampling. Specifically, write corresponds to writing to a high-confidence semantic directory, review corresponds to manual review, no-match corresponds to objects without stable business semantic support, reject corresponds to candidate rejection, and flag corresponds to marking governance issues. This 87.96% figure, used to evaluate the expert acceptance rate for governance action routing, differs from the 83.13% overall acceptance rate for task-level expert evaluation.
[0247] As can be seen from this embodiment, the present invention can not only transform candidate semantic carrying relationships into business semantic directory writing, manual review, candidate rejection, no-match confirmation, and governance issue marking, but also discover governance gaps in the data foundation. For issues such as missing field dictionaries, missing transformation rules, inconsistent write-back endpoints, and missing business semantic graph concepts, the system can output governance markers as input for subsequent data governance tasks, and continuously update evidence filtering rules, no-match rules, and governance action diversion strategies based on manual review feedback.
[0248] Example 2
[0249] This invention also provides a business semantics-driven data governance system based on a data foundation, used to execute the steps in the above method embodiments. The system includes the following modules:
[0250] 1. A dual-graph construction and candidate relationship generation module is used to construct a standard data foundation graph and a business semantic graph, and generate a set of candidate semantic bearing relationships based on the dual graphs. Specifically, this module reads the original data-side nodes from the data foundation, standardizes the original data-side nodes, outputs a standardized set of data-side nodes D, and constructs the standard data foundation graph; it extracts business objects, business attributes, business relationships, and business indicators from business process configurations, business object definitions, business field definitions, indicator definitions, policy documents, expert annotations, and historical semantic directories, merges synonyms, abbreviations, historical names, and cross-system names, outputs a set of business-side nodes B, and constructs the business semantic graph; then, it generates a set of candidate semantic bearing relationships C based on the set of data-side nodes D and the set of business-side nodes B, and calculates the candidate confidence s for each candidate semantic bearing relationship. ij This module includes one or more combinations of semantic recognition, rule matching, vector retrieval, graph representation learning, manual annotation, and historical directory migration units. The graph representation learning unit can use graph neural networks, graph attention networks, or other structural representation learning methods to generate candidate similarity or candidate semantic relationship features.
[0251] 2. Candidate ranking, fusion, and compression module, used to rank candidates according to their confidence level s. ij Credibility of candidate sources q ij Historical review status r ij Compatibility with candidate types T ij Calculate the candidate ranking score R ij The system performs multi-source fusion on the candidate semantic carrying relationships of the same data-side nodes and the same business-side nodes, and retains the top K business candidates for each data-side node while retaining the corresponding no-match candidates, outputting a global set of candidates to be processed, C'.
[0252] 3. Graph Constraint Detection and Candidate Triage Module: This module identifies boundary candidates from the set of candidates to be processed. It includes a score interval calculation unit, a no-match trigger judgment unit, a candidate conflict detection unit, and a boundary candidate marking unit. The score interval calculation unit calculates the score interval Δ between the highest-ranking and second-highest-ranking business candidates. i When Δ i ≤τ Δ Candidates are marked as having candidate competition. The no-match trigger judgment unit outputs a no-match trigger flag I when the confidence of no-match candidate is greater than or equal to the no-match trigger threshold. nm (d iThe candidate conflict detection unit is used to detect conflicts such as business phase conflicts, object conflicts, field type conflicts, rule conflicts, hierarchical inconsistencies, unclosed relationship endpoints, historical review conflicts, and directory version conflicts, and outputs candidate conflict flags I. conf (d i ,b j The boundary candidate marking unit is used to output the candidate set C to be verified based on the above determination results. bd .
[0253] 4. A dual-graph evidence package construction module, used to construct candidate semantic-carrying relations (d i ,b j Construct a filtered business evidence package E(d) i ,b j ), including name evidence E name Structural evidence E struct Evidence of Path path Rule Evidence rule Supporting evidence E support Conflicting Evidence E conflict Order of evidence E rank And historical evidence E history And calculate the sufficiency score Q based on the weight of evidence. E (d i ,b j Generate a structured validation request Req(d) i ,b j ).
[0254] 5. A dual-spectrum selective validation module, used to validate candidate confidence levels s. ij Sufficiency of evidence score Q E (d i ,b j ), fractional interval Δ i Candidate Conflict Marker I conf (d i ,b j High confidence threshold τ w 1. Threshold for sufficiency of evidence τ E Fractional interval threshold τ Δ And the unmatched trigger threshold τ0, through the piecewise function V(d i ,b j Output the verification results, which include direct pass, model verification pass, manual review, candidate rejection, no match confirmation, and governance issue marking.
[0255] 6. Model validation module, used to process the structured validation request Req(d) when the candidate semantic relationship belongs to the candidate set to be validated and there is no serious conflict. i ,b jInput a rule validator or language model validator, and output the structured model validation results. , where y ij This indicates the label that the model determines, and its values include support, oppose, and uncertain. Indicates the confidence level of model validation; This represents the explanatory evidence for the model's output; This indicates the governance issues identified by the model. The model validation results, along with the evidence sufficiency score, candidate conflict markers, and historical review results, are used to determine the appropriate governance actions.
[0256] 7. Governance action generation module, used to generate actions based on selective verification results V(d) i ,b j ), candidate confidence level s ij Filtered business evidence package E(d) i ,b j ), historical review results H ij Governance issues are marked with G issue (d i ,b j The governance action A(d) is generated through the governance action diversion function Ψ(•). i ,b j The governance actions include write, review, reject, no-match, and flag. This module also includes a write unit for writing the data-side node identifier, business-side node identifier, candidate type, evidence package digest, write time, source version, effective status, and traceable evidence link corresponding to the write action into the business semantic directory O. dir Write the candidate semantic relationships corresponding to the review action into the manual review queue O. rev Write the candidate semantic relationship corresponding to the reject action into the candidate rejection record O. rej Write the data-side node corresponding to the no-match action into the no-match list O. nom Add the issues corresponding to the flag action to the governance issue list. flag .
[0257] 8. Feedback Update Module: This module collects manual review results, governance issue handling results, catalog maintenance results, no-match confirmation results, and version change records to form a feedback set. According to the feedback set And update the set of governance strategy parameters by updating the step size η. The set of governance strategy parameters includes at least evidence filtering rules, no-match rules, action diversion thresholds, candidate source credibility, and review priority, and the subsequent candidate disposal rules are updated according to the updated parameters.
[0258] The specific implementation methods of each module are the same as the corresponding steps in the aforementioned method embodiments, and will not be repeated here.
[0259] Example 3
[0260] This invention also provides an electronic device. The electronic device includes: Memory, used to store computer programs; A processor for executing a computer program stored in the memory to implement the steps of any of the above-described business semantics-driven data governance methods based on a data foundation.
[0261] The processor can be a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices. The memory can be any medium capable of storing program code, such as Random Access Memory (RAM), flash memory, Read-Only Memory (ROM), Erasable Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), registers, hard disks, external hard disks, magnetic disks, or optical disks.
[0262] The electronic device also includes a bus for connecting the memory and the processor.
[0263] When the computer program is executed by the processor, the electronic device performs the following operations: Construct a standard data foundation graph and a business semantic graph, and generate a set of cross-graph candidate semantic carrying relationships based on the dual graphs; The candidate semantic relationships are sorted, merged, and compressed. Perform dual-graph constraint detection to classify candidate semantic-carrying relations into five categories; A filtered dual-spectrum business evidence package is constructed only for candidates to be validated by the model and candidates to be manually reviewed. Perform dual-spectrum evidence verification; Generate governance actions and write them to the corresponding governance objects and dual-graph governance status; The standard data base map, business semantic map, and governance strategy are updated based on the review feedback. This electronic device can be used to execute all or part of the steps in the foregoing method embodiments; for specific implementation details, please refer to the method embodiments, which will not be repeated here.
[0264] Example 4
[0265] This invention also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the business semantics-driven data governance method based on a data foundation described above.
[0266] The computer-readable storage medium may be any tangible medium capable of storing program code, including but not limited to: USB flash drive, portable hard drive, read-only memory (ROM), random access memory (RAM), magnetic disk, optical disk, register, server cache, cloud storage medium or other optical disk storage, magnetic disk storage medium or other magnetic storage device, or any other medium capable of carrying or storing program code in the form of instructions or data structures and accessible by a computer.
[0267] When the computer program is executed by the processor, the following steps are performed: Construct a set of data-side nodes, a set of business-side nodes, and a set of candidate semantic carrying relationships, and form candidate confidence scores; The candidate semantic relationships are sorted, merged, and compressed. Identify boundary candidates, perform constraint detection, and determine the verification path; Construct a filtered business evidence package and calculate the evidence sufficiency score; Perform selective validation; Generate governance actions and write them to the corresponding governance objects; The governance strategy will be updated based on the review feedback.
[0268] When the computer program stored in the storage medium is executed by the processor, it can be used to perform all or part of the steps in the foregoing method embodiments. For specific implementation methods, please refer to the method embodiments, which will not be repeated here.
Claims
1. A business semantics-driven data governance method based on a data foundation, characterized in that, Includes the following steps: Construct a standard data foundation graph and a business semantic graph, generate a set of candidate semantic bearing relationships based on the standard data foundation graph and the business semantic graph, and calculate the candidate confidence of each candidate semantic bearing relationship; The candidate semantic carrying relationships are sorted, multi-source fused, and compressed in sequence, and a compressed candidate set to be processed is output. Constraint detection is performed on the compressed candidate set to be processed, and candidate splitting is performed based on candidate confidence and constraint detection results to determine the splitting result of the semantic carrying relationship of each candidate; Construct a filtered business evidence package for the candidate semantic bearer relationships that need to be verified in the traffic splitting results, and verify the results based on the filtered business evidence package. Based on the traffic splitting results and the verification results, a governance action is generated and written into the corresponding governance object; Collect feedback information on the review of the governance actions and update the governance strategy parameters.
2. The method according to claim 1, characterized in that, The steps of constructing a standard data foundation graph and a business semantic graph, generating a set of candidate semantic bearer relationships based on the standard data foundation graph and the business semantic graph, and calculating the candidate confidence of each candidate semantic bearer relationship include: Using tables, fields, field combinations, interfaces, metrics, reports, field dictionaries, data standards, and governance results as data-side nodes, and the technical and governance relationships between data-side nodes as data-side edges, a standard data foundation graph is constructed. A business semantic graph is constructed by taking business objects, business attributes, business relationships, business metrics, business rules, and business process stages as business-side nodes, and taking the subordinate, association, flow, constraint, derivation, and verification relationships between business-side nodes as business-side edges. A set of candidate semantic bearer relationships is generated based on the data-side node, the data-side edge, the business-side node, and the business-side edge, and a candidate confidence score is calculated for each candidate semantic bearer relationship.
3. The method according to claim 1, characterized in that, The steps of sequentially sorting, fusing multiple sources, and compressing the candidate semantic carrying relationships to output a compressed candidate set to be processed include: The ranking score is calculated based on the multi-source features of the candidate semantic carrying relationship. The multi-source features include candidate confidence, candidate source credibility, historical review status, and candidate type compatibility. Multi-source fusion is performed on candidate semantic carrying relationships of the same data-side nodes and the same business-side nodes, and conflict markers are retained when the conclusions of different sources conflict. For each data-side node, retain the top K candidate semantic carrying relationships with the highest sorting scores and retain the corresponding unmatched candidates. Merge the candidates from each data-side node and output a compressed set of candidates to be processed.
4. The method according to claim 1, characterized in that, The steps of performing constraint detection on the compressed candidate set to be processed, and performing candidate splitting based on candidate confidence and constraint detection results to determine the splitting result of the semantic carrying relationship of each candidate include: Perform hierarchical consistency checks and relation endpoint consistency checks on the candidate semantic carrying relationships, and output candidate conflict flags; the hierarchical consistency check is used to check whether the field-level candidate mapping and the table-level candidate mapping are consistent, and the relation endpoint consistency check is used to check whether the candidate mappings at both ends of the data relationship are closed with the objects at both ends of the business relationship; Calculate the score interval between the highest and second-highest candidates of the same data-side node. When the score interval is less than or equal to a preset threshold, mark the candidate semantic carrying relationship corresponding to the data-side node as having candidate competition conflict. Based on the candidate conflict marker, the candidate competition conflict, the candidate confidence, the confidence of the unmatched candidate, and the historical review results, the candidate semantic carrying relationship is divided into directly confirmed candidates, candidates to be verified by the model, candidates to be manually reviewed, candidate rejection objects, and unmatched confirmed objects; among them, only the candidates to be verified by the model and the candidates to be manually reviewed enter the subsequent evidence verification process.
5. The method according to claim 1, characterized in that, The steps of constructing a filtered business evidence package for the candidate semantic bearer relationships that need to be verified in the traffic splitting results, and verifying the results based on the filtered business evidence package, include: The evidence extraction scope is determined around the candidate semantic bearer relationships that need to be verified, and evidence is extracted from the evidence extraction scope and combined into a filtered business evidence package; the filtered business evidence package includes supporting evidence and conflicting evidence. The evidence sufficiency score is calculated based on the filtered business evidence package, and a structured verification request is generated. Input the structured verification request into the verification model and output the verification result.
6. The method according to claim 1, characterized in that, The step of generating a governance action based on the traffic splitting result and the verification result, and writing the governance action into the corresponding governance object, includes: Based on the traffic splitting results and the verification results, governance actions are generated, including writing to the business semantic directory, entering manual review, rejecting candidates, confirming no match, and marking governance issues. The corresponding write object is determined based on the governance action; When the governance action is to write to the business semantic directory, the corresponding candidate semantic bearer relationship is written to the business semantic directory; when the governance action is to enter manual review, the corresponding candidate semantic bearer relationship is written to the manual review queue; when the governance action is to reject a candidate, the corresponding candidate semantic bearer relationship is written to the candidate rejection record; when the governance action is to confirm no match, the corresponding data-side node is written to the no-match list; when the governance action is to mark a governance issue, the corresponding issue is written to the governance issue list.
7. A business semantics-driven data governance system based on a data foundation, characterized in that, include: The dual-graph construction and candidate relation generation module is used to construct a standard data base graph and a business semantic graph, generate a set of candidate semantic bearer relations based on the standard data base graph and the business semantic graph, and calculate the candidate confidence of each candidate semantic bearer relation; The candidate sorting, fusion and compression module is used to sort, fuse multiple sources and compress the quantity of the candidate semantic carrying relationships in sequence, and output the compressed candidate set to be processed. The graph constraint detection and candidate splitting module is used to perform constraint detection on the compressed candidate set to be processed, and to split the candidates according to the candidate confidence and constraint detection results, and to determine the splitting result of the semantic carrying relationship of each candidate. The dual-graph evidence verification module is used to construct and verify the candidate semantic bearer relationships that need to be verified in the traffic splitting results, and determine the verification results. The governance action generation module is used to generate governance actions based on the traffic splitting results and the verification results, and write the governance actions into the corresponding governance objects; The feedback update module is used to collect the review feedback information of the governance actions and update the governance strategy parameters.
8. The system according to claim 7, characterized in that, The dual-map construction and candidate relation generation module includes: The data-side node and edge construction unit is used to construct a standard data foundation graph by using tables, fields, field combinations, interfaces, indicators, reports, field dictionaries, data standards, and governance results as data-side nodes, and the technical and governance relationships between data-side nodes as data-side edges. Business-side nodes and edge construction units are used to construct a business semantic graph by taking business objects, business attributes, business relationships, business indicators, business rules and business process stages as business-side nodes, and the subordinate, association, flow, constraint, derivation and verification relationships between business-side nodes as business-side edges. The candidate generation unit is used to generate a set of candidate semantic bearing relationships based on the data-side node, the data-side edge, the business-side node, and the business-side edge, and to calculate the candidate confidence level for each candidate semantic bearing relationship.
9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing a computer program stored in the memory to implement the steps of the business semantics-driven data governance method based on a data foundation as described in any one of claims 1 to 6.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the business semantics-driven data governance method based on a data foundation as described in any one of claims 1 to 6.
