Unified standard fusion governance modeling method for multi-campus multi-service domain school affairs data

Abstract

The application provides a multi-campus multi-service domain school affair data unified standard fusion governance modeling method, belonging to the technical field of data processing, which comprises the following steps: obtaining source data, uniformly accessing and adding campus identifier and service domain mark, and performing data cleaning; performing cross-service domain entity analysis based on master data management rules to generate fusion master data entities; constructing an inter-entity association network using the reserved cross-service domain association field to form a school affair data base. The base is iteratively executed with multi-level quality checks including integrity checks and post-consistency checks, each iteration generates a version snapshot with a timestamp and traceability and outputs the quality score of each service domain. If the score does not meet the standard or the post-check finds that the entity merger causes a consistency violation, adjust the cleaning parameters according to the check results, rollback based on the version snapshot, reiterate from the cleaning or entity analysis step until the quality conditions are met and there is no violation, and finally output a unified data view.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a unified standard integration governance modeling method and system for school affairs data across multiple campuses and business domains. Background Technology

[0002] As the scale of education expands and business complexity increases, the need for global data integration across multiple campuses and business domains is becoming increasingly urgent, and existing technical solutions are struggling to adapt to the new scenarios. Because each campus and business domain independently develops and maintains its data coding and format standards, cross-domain integration is only achieved through field conversion and data table concatenation. This results in multiple independent records for the same entity, with no clear association between entity attributes across different business domains. Furthermore, existing technologies only perform a single field NOT NULL check before data loading, and there is no continuous quality monitoring after integration. Inconsistencies in entity attribute values ​​are only discovered during cross-domain analysis. By this time, historical data has been overwritten, making it impossible to trace the problem back to its source. The only solution is to rerun the entire ETL process, which is both resource-intensive and leads to data service interruptions. With continuous data updates and the integration of new businesses, problems accumulate, and integration costs rise exponentially. Summary of the Invention

[0003] To address the aforementioned technical issues, this application provides a unified standard integration governance modeling method and system for multi-campus and multi-business domain school affairs data.

[0004] A first aspect of this application provides a unified standard fusion governance modeling method for multi-campus, multi-business domain school affairs data, including: The source data of school affairs data from multiple campuses and business domains is obtained, and after adding metadata including campus identifiers and business domain tags through a unified access standard, the data is cleaned based on preset data cleaning parameters, and the cleaned data is output. Based on preset master data management rules, cross-business domain entity parsing is performed on the cleaned data to generate merged master data entities; Based on the cross-business domain related fields retained in the cleaned data, an inter-entity relationship network is constructed with the merged master data entity as the node; The system integrates master data entities and the network of relationships between entities to form a school affairs data base. The school affairs data base is iteratively subjected to multi-level data quality checks, including integrity checks and consistency checks. The consistency checks include post-consistency checks. After each iteration of the base update, a version snapshot with timestamps and operation traceability is generated, and data quality scores for each business domain are output. When the data quality score fails to meet the preset quality conditions, or when the post-consistency check detects a consistency violation caused by entity merging, the data cleaning parameters are adjusted according to the check results, a version rollback is triggered based on the corresponding version snapshot, and the iteration is re-executed from the data cleaning or entity parsing steps until the data quality score meets the preset quality conditions and there are no consistency violations, and finally a unified data view is output.

[0005] A second aspect of this application provides a unified standard fusion governance modeling system for multi-campus, multi-business domain school affairs data, including: The data access and cleaning module is used to acquire source data of school affairs data from multiple campuses and business domains. After adding metadata including campus identifiers and business domain tags through a unified access standard, the data is cleaned based on preset data cleaning parameters and the cleaned data is output. The entity parsing module is used to perform cross-business domain entity parsing on the cleaned data based on preset master data management rules, and generate merged master data entities; The association network construction module is used to build an inter-entity association network based on the cross-business domain association fields retained in the cleaned data, with the merged master data entities as nodes; The base construction and quality verification module is used to aggregate the master data entities and the relationship network between entities to form the school affairs data base. It iteratively performs multi-level data quality verification on the school affairs data base. The multi-level data quality verification includes integrity verification and consistency verification. Consistency verification includes post-consistency verification. After each iteration of the base update, a version snapshot with timestamp and operation traceability is generated, and the data quality score of each business domain is output. The iterative governance module is used to adjust the data cleaning parameters of the data access and cleaning module according to the verification results when the data quality score fails to meet the preset quality conditions or when the post-consistency verification detects consistency violations caused by entity merging. It also triggers version rollback based on the corresponding version snapshot and controls the data access and cleaning module and / or entity parsing module to re-execute the iteration from the data cleaning step or entity parsing step until the data quality score meets the preset quality conditions and there are no consistency violations, and finally outputs a unified data view.

[0006] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and running on the processor. When the processor executes the computer program, it implements the steps of the above-described unified standard fusion governance modeling method for multi-campus and multi-business domain school affairs data.

[0007] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described unified standard fusion governance modeling method for multi-campus, multi-business-domain school affairs data.

[0008] The beneficial effects of the unified standard fusion governance modeling method and system for multi-campus and multi-business domain school affairs data provided in this application are as follows: First, this application adds metadata with campus identifiers and business domain tags to the source data of multiple campuses and multiple business domains to clarify the data ownership and source boundaries; then, it removes noisy data through standardized cleaning. Data silos between various business systems are broken down through cross-business domain entity parsing, generating a unified fusion master data entity; an inter-entity association network is constructed based on the retained association fields, forming a complete school affairs data foundation. Data quality is comprehensively evaluated through multi-level quality checks including post-consistency verification, and full-process traceability is achieved by combining version snapshots with timestamps and operation traceability; consistency issues caused by entity merging are continuously corrected through score-driven iterative optimization and version rollback mechanisms, ultimately outputting a high-quality, highly consistent unified data view. This application realizes the establishment of a unified data governance mechanism covering the entire process from data access to data output in the dynamic school affairs data integration scenario of multiple campuses and multiple business domains, improving the entity uniqueness, association integrity, and quality controllability of the integrated data. Attached Figure Description

[0009] Figure 1 A flowchart illustrating a unified standard fusion governance modeling method for multi-campus, multi-business-domain school affairs data provided in an embodiment of this application; Figure 2 A structural block diagram of a unified standard fusion governance modeling system for multi-campus, multi-business domain school affairs data provided in an embodiment of this application; Figure 3 This is a schematic block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0010] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0011] To make the purpose, technical solution, and advantages of this application clearer, the following will be described in conjunction with the appendix. Figure 1 -Appendix Figure 3 The following is an explanation using specific examples.

[0012] Please refer to Figure 1 , Figure 1 A flowchart illustrating a unified standard fusion governance modeling method for multi-campus, multi-business domain school affairs data provided in an embodiment of this application is shown. The method includes: S101: Obtain source data of school affairs data from multiple campuses and business domains, add metadata including campus identifiers and business domain tags through a unified access standard, perform data cleaning based on preset data cleaning parameters, and output the cleaned data.

[0013] In this embodiment, multi-campus, multi-business-domain school administration data refers to school management-related data originating from different campuses and multiple business departments (such as academic affairs, student affairs, finance, etc.). A unified access standard refers to a set of pre-defined rules or specifications used to guide how raw data from different sources is received and processed by the system, ensuring consistency in data format, encoding, and metadata appending. Metadata refers to data describing the data; in this embodiment, it includes campus identifiers and business-domain tags, used to indicate the source and contextual information of the raw data. Data cleaning parameters refer to settings or rules used to configure data cleaning operations; these parameters guide the cleaning operators to identify and correct errors, inconsistencies, or redundancies in the data.

[0014] In this embodiment, the source data for the multi-campus, multi-business-domain school affairs data comes from the academic affairs system, student affairs system, financial system, etc., of each campus, and their formats and encodings may differ. During data access, metadata such as campus identifiers and business-domain tags are added to each record using manual configuration or methods based on file paths and system interface identification to clarify the data source. Subsequently, the data with added metadata is cleaned based on preset data cleaning parameters. For example, data cleaning parameters include deduplication rules, null value filling rules, or format standardization rules for specific fields. The cleaning process uses a batch processing method, performing a one-time cleaning on all accessed data; for example, standardizing the format of all date fields or removing duplicate student records, ultimately outputting the cleaned data.

[0015] In this embodiment, the initial parameter thresholds for various cleaning operators are set as follows: The trigger threshold for the null value filling rule is to enable mean / mode filling when the field null value rate exceeds 5%. This value is determined based on the statistical analysis of the natural missing rate of core fields (name, student ID, class) in each business domain (taking the 95th percentile); The date format of the format standardization rule is uniformly YYYY-MM-DD, and the encoding format is uniformly UTF-8. This is the baseline configuration, and no flexible threshold is set; The initial similarity deduplication threshold for the deduplication rule is set to 0.85 (based on Jaccard similarity). This value is determined by performing ROC curve analysis on 1000 manually labeled duplicate / non-duplicate records in each business domain and selecting the threshold corresponding to the maximum Youden index.

[0016] S102: Based on the preset master data management rules, perform cross-business domain entity parsing on the cleaned data to generate a merged master data entity.

[0017] In this embodiment, cross-business domain entity resolution refers to the process of identifying and integrating records representing the same real entity (e.g., the same student or the same course) but originating from different business domains or systems. Merged master data entity refers to a unique and unified representation of the real entity formed by merging multiple records from different business domains after entity resolution.

[0018] Master data management rules include a series of logics for identifying the same entity. For example, it stipulates that two records are considered to represent the same entity if their names, ID numbers, and dates of birth are exactly the same. The entity resolution process can first attempt to match, for example, by comparing pre-defined unique identifiers (such as student IDs or employee IDs) in the cleaned data to identify and merge records. For records that fail to match, a fuzzy matching strategy is used. For example, by calculating the string similarity of key attributes (such as name and address) in the records and setting a fixed similarity threshold, when the similarity exceeds the threshold, these records are determined to be the same entity and merged. In this way, multiple records from different business domains but pointing to the same real entity are integrated into a single merged master data entity.

[0019] S103: Based on the cross-business domain related fields retained in the cleaned data, construct an inter-entity relationship network with the merged master data entity as the node.

[0020] In this embodiment, the inter-entity association network refers to a graph structure constructed with the integrated master data entities as nodes and the relationships between entities as edges, used to display the complex relationships between entities in school administration data.

[0021] By utilizing cross-business domain association fields retained in the cleaned data—identifiers common to different business domains—for example, student entities and course entities can be associated through course selection numbers, and teacher entities and project entities can be associated through project leader numbers, the network is constructed by traversing all records in the cleaned data and identifying record pairs that include association fields. When two merged master data entities establish a connection through a certain association field, an edge is created between them. For example, if student A's student record and student A's grade record both include the same student ID, an association is established between student A's merged master data entity and the corresponding grade merged master data entity. The edge labels are manually assigned based on the semantics of the association fields, such as elective relationship or responsibility relationship. This forms an association network representing the complex relationships between school administration data entities.

[0022] S104: The system integrates master data entities and the network of relationships between entities to form a school affairs data base. Iteratively performs multi-level data quality checks on the school affairs data base. The multi-level data quality checks include integrity checks and consistency checks. The consistency checks include post-consistency checks. After each iteration of the base update, a version snapshot with timestamps and operation traceability is generated, and the data quality scores of each business domain are output.

[0023] In this embodiment, the school administration data base refers to a centralized and unified school administration data repository, which consists of a merged master data entity and its associated network, serving as the foundational layer for data analysis and application. Multi-level data quality verification refers to the process of conducting a comprehensive quality assessment of the school administration data base, including checks at multiple levels or of different types to ensure the accuracy, completeness, consistency, and validity of the data. Post-consistency verification refers to a consistency check performed after data integration or entity merging operations are completed, aiming to identify data conflicts or inconsistencies introduced during the merging process.

[0024] Specifically, multi-level data quality verification includes integrity verification and consistency verification. Integrity verification, for example, checks for null values ​​in key fields; consistency verification, for example, checks whether the name of the same student is completely consistent across different business domains. Post-consistency verification is specifically used to detect potential data conflicts after entity merging; for example, when two student records are merged, their gender attributes may contradict each other. After each update to the base system, a version snapshot is generated. This snapshot records the current state of the base system, the generation time, and the operation information that led to the update, facilitating subsequent traceability. Simultaneously, based on the verification results, a data quality score for each business domain is output to quantitatively assess the data quality level.

[0025] S105: When the data quality score fails to meet the preset quality conditions, or when the post-consistency check detects a consistency violation caused by entity merging, adjust the data cleaning parameters according to the check results, trigger version rollback based on the corresponding version snapshot, and re-execute the iteration from the data cleaning or entity parsing steps until the data quality score meets the preset quality conditions and there are no consistency violations, and finally output a unified data view.

[0026] In this embodiment, a version snapshot refers to a copy of the administrative data base at a specific point in time, including a timestamp and operation traceability information, used to record the data evolution process and support backtracking. Version rollback refers to restoring the administrative data base to the state recorded in a historical version snapshot to undo erroneous operations or restore data to a known good state. Version rollback only restores the administrative data base to the snapshot state; cleaning parameters and entity resolution parameters retain their currently adjusted values ​​and are not rolled back, thus continuing the iterative optimization effect. A unified data view refers to the final, well-governed and integrated high-quality administrative data set, provided in a standardized and consistent manner for easy use by various business applications and data analysis.

[0027] In this embodiment, if a large number of null values ​​are found, the parameters of the null value filling rule are adjusted; if inconsistent formats are found in specific fields, the format standardization rule is adjusted. Subsequently, a version rollback is triggered based on the most recently generated version snapshot, restoring the school administration data base to its previous state. After the rollback, the iterative process will be re-executed from the data cleaning or entity parsing steps. This iterative process will continue until the data quality score meets the preset quality conditions and there are no more consistency violations. Finally, when the data quality meets the requirements, a high-quality and unified school administration data view is output.

[0028] The preset quality conditions are a combination of a comprehensive quality score threshold and key indicator compliance requirements. The comprehensive quality score is a weighted average of the data quality scores for each business domain, with weights allocated proportionally to the number of records in each business domain relative to the total number of records. The comprehensive quality score threshold is set at 85 points (out of 100), determined by surveying industry standards for school data governance (such as the DAMA-DMBOK data quality dimension scoring conventions) and the actual acceptance requirements in the informatization construction of multiple universities, taking the median value. Simultaneously, the preset quality conditions also include mandatory key indicator compliance: the integrity verification pass rate for any business domain must not be lower than 95%, and the number of non-compliant records in subsequent consistency verification must not exceed 1% of the total number of records in that business domain. Both the comprehensive score and key indicators must be met simultaneously to be considered as meeting the preset quality conditions. The 1% non-compliance tolerance is based on the consistency tolerance standards for core master data in the financial industry's data governance, and is determined by rounding down the accuracy requirements for core fields such as student status and grades in school data, ensuring that the output unified data view can be directly used for cross-domain statistical analysis without generating substantial ambiguity.

[0029] As can be seen from the above, this application first adds metadata with campus and business domain identifiers to multi-campus, multi-business domain source data to clarify data ownership and source boundaries; then, it removes noisy data through standardized cleaning. By breaking down data silos between business systems through cross-business domain entity parsing, a unified fused master data entity is generated; based on the retained related fields, an inter-entity relationship network is constructed, forming a complete foundation for school administration data. Data quality is comprehensively evaluated through multi-level quality checks, including post-consistency verification, and full-process traceability is achieved by combining version snapshots with timestamps and operation traceability; through score-driven iterative optimization and version rollback mechanisms, consistency issues caused by entity merging are continuously corrected, ultimately outputting a high-quality, highly consistent unified data view. This application establishes a unified data governance mechanism covering the entire process from data access to data output in dynamic school administration data integration scenarios involving multiple campuses and multiple business domains, improving the entity uniqueness, relationship integrity, and quality controllability of the integrated data.

[0030] In one embodiment of this application, based on preset master data management rules, cross-business domain entity parsing is performed on the cleaned data to generate a merged master data entity, including: Based on the globally unique code preset in the master data management rules, deterministic matching is performed on the records in the cleaned data, and records with the same globally unique code are associated with the same entity, resulting in a set of deterministically matched entity records and a set of remaining records that did not pass the deterministic matching. Extract the campus identifier and other entity attributes carried by each record in the remaining record set to form similarity features; for the pair of records to be matched in the remaining record set, determine the business domain pair combination composed of the source business domains of the two records based on the source business domains indicated by the business domain tags of the two records in the pair of records to be matched. Based on the combination of business domain pairs, obtain the credibility coefficient corresponding to the combination of business domain pairs, and use the credibility coefficient to adjust the preset initial matching threshold to obtain the dynamic matching threshold. The higher the credibility coefficient, the lower the dynamic matching threshold. Based on the preset feature weights corresponding to the entity attributes in each similarity feature, the weighted similarity score of the record pairs to be matched is calculated. Record pairs with weighted similarity scores greater than the dynamic matching threshold are judged as the same entity and merged to generate a similarity matching entity record set. The records that are identified as the same entity in the deterministic matching entity record set and the similarity matching entity record set are merged to generate a fused master data entity.

[0031] In this embodiment, deterministic matching refers to precise matching using fields with unique identifiers in the data. Globally unique codes are predefined identifiers that guarantee uniqueness across all campuses and business domains, such as student IDs, employee IDs, and national ID numbers. By comparing these codes, different records belonging to the same physical entity are accurately identified. This is achieved through database equi-join operations.

[0032] Similarity features are a set of attributes used to measure the degree of similarity between two records. Campus identifiers distinguish the physical campus to which a record belongs, while other entity attributes include information that describes the entity's characteristics, such as name, date of birth, gender, major, and department. These attributes serve as the basis for determining whether records belong to the same entity when calculating similarity.

[0033] Business domain tags indicate the original source business system of each record, such as the academic affairs system, student affairs system, and financial system. By identifying the source business domain of the record pairs to be matched, business domain pair combinations are formed, such as (academic affairs system, student affairs system) or (financial system, human resources system), which provide contextual information for subsequent dynamic matching strategies.

[0034] The method for determining the initial matching threshold is as follows: randomly sample from historically labeled matching record pairs, calculate the similarity score distribution of each record pair, and select the score value that maximizes the F1-score as the initial threshold; if there is no historical labeled data, the benchmark value is set by expert experience and then iteratively adjusted.

[0035] The credibility coefficient is an indicator that measures the reliability of data matching between business domains. Different business domains have varying data association reliability due to differences in data entry habits, standardization, and data quality. For example, data between the academic affairs system and the student affairs system will have high credibility, while data between the academic affairs system and the library system will have lower credibility.

[0036] The credibility coefficient is obtained based on feedback from historical matching results and expert experience. For example, determining the credibility coefficient includes two stages: initial value setting and dynamic calibration. The initial value is a weighted composite of data quality maturity assessment and historical association credibility statistics. The data quality maturity score is normalized after scoring each business domain on a 5-point scale using the DCMM model. The historical association credibility statistics are the average attribute consistency rate of matched record pairs from the past two academic years. The two are weighted at 0.4:0.6, with the initial value set in the range [0.3, 0.9]. New business domains are assigned a default value of 0.6, which is switched to composite calculation after data accumulation.

[0037] The confidence coefficient is used to dynamically adjust the initial matching threshold, enabling the matching strategy to adapt to the characteristics of different business domain pairs. When the confidence coefficient is high, it means that the data quality and relevance of the business domain pair are good, and the matching threshold can be lowered to improve the recall rate; conversely, when the confidence coefficient is low, the matching threshold should be increased to ensure the accuracy of matching and avoid false matches.

[0038] Preset feature weights characterize the importance of different entity attributes in determining entity identity. For example, name and date of birth may have higher weights than place of origin or phone number. The weighted similarity score is a comprehensive score obtained by multiplying the similarity value of each similarity feature by its corresponding preset feature weight and then summing the results. The similarity calculation method uses Jaccard similarity; by comparing the weighted similarity score with a dynamic matching threshold, it is determined whether two records are similar enough to be identified as the same entity. If the weighted similarity score is greater than the dynamic matching threshold, these records are merged to form a similarity-matched entity record set.

[0039] For example, the preset feature weights are determined using a combined weighting method: First, at least three experts in the field of school data governance compare each attribute pairwise based on its contribution to the entity uniqueness determination, constructing a judgment matrix and then calculating the subjective weight vector using the Analytic Hierarchy Process (AHP). Simultaneously, from a historically labeled set of positive and negative matching records, the information gain of each attribute in distinguishing matching / non-matching records is calculated using the entropy weight method, yielding the objective weight vector. The final weight is the arithmetic mean of the subjective and objective weights, and then normalized. Taking a student entity as an example, typical weight allocations are: name 0.25, date of birth 0.20, ID number (in cases of partial matching) 0.30, contact information 0.15, and other attributes (such as place of origin, ethnicity, etc.) 0.10. These weights are fixed in the first iteration. In subsequent iterations, if a certain attribute continues to cause consistency violations, it is dynamically fine-tuned through a parameter correction mechanism, with the fine-tuning step not exceeding 5% of the original weight of that attribute.

[0040] A merged master data entity is a collection of all relevant records identified as representing the same physical entity after deterministic and similarity matching. The merging process integrates the results of the two matching strategies to form a more comprehensive and accurate view of the entity. Data quality rules are used to resolve attribute conflicts during the merging process, such as selecting the latest value, the most complete value, or the majority voting principle. The resulting merged master data entity is a component of the university's administrative data infrastructure.

[0041] By adopting the above technical solution, deterministic matching is first performed based on globally unique encoding to quickly complete high-confidence entity associations and ensure the accuracy of basic matching. For the remaining records that fail deterministic matching, similarity features such as campus identifiers are extracted. Based on the business domain pairs of the records to be matched, corresponding confidence coefficients are obtained, and the matching threshold is dynamically adjusted to make the matching of high-confidence business domain pairs more lenient to improve recall, and the matching of low-confidence domain pairs more stringent to ensure accuracy. A weighted similarity score is calculated by combining preset feature weights to determine and merge the same entity. Finally, the two types of matching results are integrated to generate a fused master data entity, achieving an optimal balance between accuracy and recall in cross-business domain entity recognition.

[0042] In one embodiment of this application, the method for calibrating the credibility coefficient corresponding to the combination of business domains includes: Obtain the similarity matching entity record set generated by the combination of the business domain in the previous iteration, and the consistency violation records of the similarity matching entity record set detected by the post-consistency check in the multi-level data quality check; Calculate the percentage of records that violate consistency rules in the total number of records in the similarity-matching entity record set; When the proportion exceeds the preset violation tolerance threshold for K consecutive iterations, the credibility coefficient corresponding to the combination of business domains is reduced based on the preset decay step size, and the dynamic matching threshold is readjusted based on the reduced credibility coefficient in the entity parsing of subsequent iterations. When the proportion falls below the violation tolerance threshold for M consecutive iterations in subsequent iterations, the credibility coefficient corresponding to the business domain pair combination is gradually restored based on the preset recovery step size until it is less than or equal to the initial value of the credibility coefficient, and the credibility coefficient is always greater than or equal to the preset lower limit value of the credibility coefficient.

[0043] In this embodiment, obtaining the similarity-matching entity record set generated by the business domain pair combination in the previous iteration, as well as the consistency violation records detected by the post-consistency check in the multi-level data quality verification, means that after each iteration completes entity parsing and data quality verification, the system stores the similarity-matching entity record set and the post-consistency check results (including the identifiers of the violation records) in a historical log or database table for querying in the next iteration. Alternatively, through a message queue or event-driven mechanism, when a violation is detected by the post-consistency check, a violation event is published in real time, and the credibility coefficient calibration module subscribes to and collects these events, while simultaneously obtaining the corresponding similarity-matching entity record set from the entity parsing module.

[0044] Calculating the percentage of consistency violation records in the total number of records in the similarity-matching entity record set involves dividing the number of obtained consistency violation records by the total number of records in the similarity-matching entity record set generated in the previous iteration for that business domain pair combination, resulting in a percentage or decimal value. Alternatively, the data quality verification module can directly output the number of violation records and the total number of matching records for each business domain pair combination, and then the credibility coefficient calibration module can perform a division operation to calculate the percentage.

[0045] The method for determining the violation tolerance threshold is as follows: based on statistical analysis of historical matching results, the 95th percentile of the violation rate of each business domain pair combination under normal operating conditions is taken as the initial value of the tolerance threshold for that combination; when historical data is lacking, it is set to 5% by default and dynamically adjusted according to the actual violation distribution in the first iteration. This violation tolerance threshold (default 5%) is a local tolerance for a specific business domain pair combination, which is different from the 1% violation rate requirement for the entire business domain in the overall quality conditions.

[0046] When the proportion exceeds the preset violation tolerance threshold for K consecutive iterations, the credibility coefficient corresponding to the business domain pair combination is reduced based on a preset decay step size. In subsequent iterations of entity parsing, the dynamic matching threshold is readjusted based on the reduced credibility coefficient. This means the system maintains a historical queue of violation proportions for each business domain pair combination. When K consecutive values ​​in the queue are greater than the preset violation tolerance threshold, the credibility coefficient decay is triggered. The number of consecutive iterations, K, is set to 3 to exclude false triggers caused by occasional fluctuations.

[0047] When the proportion falls below the violation tolerance threshold for M consecutive iterations in subsequent iterations, the credibility coefficient corresponding to the business domain pair is gradually restored based on the preset recovery step size until it is less than or equal to the initial value of the credibility coefficient. The credibility coefficient is always greater than or equal to the preset lower limit of the credibility coefficient. This means that, similar to the decay mechanism, another counter is maintained. When the violation proportion is lower than the threshold for M consecutive iterations, the recovery of the credibility coefficient is triggered.

[0048] The decay step size and recovery step size are determined as follows: the decay step size is set to 10% of the current value of the confidence coefficient and not exceeding 0.05, and the recovery step size is set to 50% of the decay step size, so as to realize the asymmetric adjustment strategy of slow rise and fast fall and avoid excessive recovery.

[0049] The method for determining the lower limit of the credibility coefficient is as follows: based on the recall constraint of entity parsing, it is deduced to ensure that under the most stringent matching conditions, the matching recall rate of each business domain for the combination is not less than 80%, and the minimum value of the credibility coefficient is constrained by this lower limit; when the recall requirement cannot be met, 0.3 is used as the absolute lower limit value.

[0050] The number of consecutive iterations M is set to 2, making the recovery condition slightly more lenient than the decay condition, thus avoiding frequent oscillations of the confidence coefficient near the boundary.

[0051] By employing the above technical solution, the credibility coefficient of the corresponding business domain pair combination is calibrated by utilizing the violation rate of the similarity matching entity record set detected in the post-consistency check of the previous iteration. When the violation rate exceeds the tolerance threshold for K consecutive times, the credibility coefficient is reduced by a decay step size to increase the dynamic matching threshold of the business domain pair and reduce false matches. When the violation rate falls below the threshold for M consecutive times, the credibility coefficient is gradually increased by a recovery step size to avoid excessive suppression of matching. Simultaneously, a lower limit for the credibility coefficient is set to prevent excessively low matching recall. This achieves adaptive dynamic calibration of the credibility coefficient, enabling continuous optimization of entity parsing performance as data quality improves.

[0052] In one embodiment of this application, the method of extracting campus identifiers and other entity attributes carried by each record in the remaining record set to constitute similarity features further includes: When the campus identifiers of the two records to be matched are different, identify whether the two records carry a predefined cross-campus entity movement marker field. The cross-campus entity movement marker field includes the student status change number or the joint training program number. If at least one record has a cross-campus entity movement marker field and the field values ​​are the same, the campus identifier difference is deemed invalid, and the contribution of the campus identifier difference to the weighted similarity score calculation is set to zero. If neither of the two records has a cross-campus entity movement marker field, or the field values ​​are inconsistent, the campus identifier difference is treated as a binary penalty feature and given a negative penalty weight. This causes the weighted similarity score of the pair of records to be matched to be reduced by the preset penalty value, in order to suppress false cross-campus matches that lack movement credentials.

[0053] In this embodiment, one or more field lists are pre-configured, and these fields are defined by business rules as credentials indicating entity movement across campuses. For example, when processing pairs of records to be matched, specific fields (student status change number or joint training program number) of each record are checked to determine whether these marker fields exist. Another implementation is to semantically annotate fields including cross-campus movement information during the data access and metadata appending stages, and the entity parsing module identifies them based on these semantic annotations during matching.

[0054] The cross-campus entity movement marker fields include student status change numbers or joint training program numbers. These are specific business credentials used to clearly indicate the legitimate movement of entities (such as students) between different campuses. For example, a student status change number is typically generated when a student transfers from one campus to another, while a joint training program number may identify joint training activities undertaken by a student across different campuses or institutions. The introduction of these fields allows the system to determine the nature of campus identification differences based on explicit business rules. In practical applications, the names and meanings of these fields are configured and extended according to the specific school administration management system to adapt to different business scenarios.

[0055] If at least one record contains a cross-campus entity movement marker field with identical values, the campus identifier difference is deemed invalid, and its contribution to the weighted similarity score is set to zero. This mechanism ensures that when there is a clear cross-campus movement credential, even if two records have different campus identifiers, their similarity scores will not be reduced. For example, when two records (possibly from different campuses) both include the same student registration change number, it indicates that they point to the same entity that moved across campuses due to a transfer. In this case, when calculating the weighted similarity score, the weight of the campus identifier feature is dynamically adjusted to zero, thus avoiding erroneous splitting due to campus identifier differences and ensuring that entities that should be merged are correctly identified.

[0056] If neither record has a cross-campus entity movement marker field, or the field values ​​are inconsistent, the campus identifier difference is treated as a binary penalty feature with a negative penalty weight. This causes the weighted similarity score of the pair of records to be matched to be reduced by a preset penalty value, thus suppressing mismatches across campuses lacking movement credentials. This means that in the absence of valid movement credentials, a difference in campus identifiers will be considered a strong negative signal. For example, if two records have different campus identifiers but neither has a student status change number or a joint training program number, or if these numbers are inconsistent, a preset penalty value will be deducted from their weighted similarity score. This penalty mechanism effectively reduces the risk of mismatches due to campus identifier differences, preventing the erroneous merging of entities from different campuses lacking associated credentials into the same merged master data entity.

[0057] The penalty value is determined as follows: the penalty value is set to 15% of the full similarity score. That is, if the similarity score adopts a 0-1 normalization interval, the penalty value is 0.15. This value is determined by statistically analyzing the similarity score distribution of cross-campus mismatched samples, taking the difference between the mean scores of mismatched samples and positive matching samples as the penalty benchmark, and optimizing it through multiple rounds of experiments, so as to effectively suppress mismatches without significantly reducing the positive matching recall rate across campuses.

[0058] By adopting the above technical solution, the issue of campus identifier differences in a multi-campus environment is specifically addressed when constructing similarity features. When the campus identifiers of the records to be matched are different, the system automatically identifies whether there are cross-campus entity movement markers such as student status change numbers or joint training program numbers. If valid and consistent movement markers exist, the campus identifier differences are determined to be reasonable movement, eliminating their negative impact on similarity calculation. If there are no valid movement credentials, the campus identifier differences are used as a binary penalty feature, applying a negative weight to reduce the similarity score. This ensures correct matching of cross-campus moving entities while effectively suppressing unfounded cross-campus mismatches.

[0059] In one embodiment of this application, based on the cross-business domain association fields retained in the cleaned data, an inter-entity association network is constructed using the merged master data entity as a node, including: Parse the predefined semantic tags carried by cross-business domain related fields to determine the set of relationship types corresponding to each related field; For any two merged master data entities connected by any associated field, obtain the set of relation types and the character matching degree of the associated field value; Based on the business domain to which the connected entities belong, query the business coupling tightness coefficient of the business domain pair formed by the two business domains from the preset business coupling tightness matrix. Based on the entity hierarchy of the two merged master data entities, the corresponding entity hierarchy weight is queried from the preset entity hierarchy weight table; The association strength between the two merged master data entities is calculated by multiplying the character matching degree, the business coupling tightness coefficient, and the entity hierarchy weight. The relationship strength between two merged master data entities is used as the weight of the edge, and the highest priority relation type selected from the set of relation types is used as the edge label to construct the relationship network between entities.

[0060] In this embodiment, predefined semantic tags refer to metadata or annotations embedded in or associated with cross-business domain related fields, aiming to clarify the business meaning represented by the field and the relationship type between entities. This embodiment extracts the inherent semantic information from the original related fields, transforming simple data connections into relationship types with clear business meanings, laying the foundation for subsequently building a semantically rich relationship network. For example, by configuring a rule engine, semantic tags can be identified and parsed based on field names, field value patterns, or external metadata dictionaries; alternatively, Natural Language Processing (NLP) technology can be used to analyze field descriptions or annotations, automatically identifying and mapping them to predefined relationship type ontologies.

[0061] Character matching degree refers to the degree of textual similarity between the values ​​of a certain associated field in the records of two entities when they are connected by that field. This embodiment quantifies the direct reliability of the association between two entities at the data level through a specific field; a high character matching degree generally implies stronger evidence of a direct association. Character matching degree can be calculated using string similarity algorithms, such as Jaccard similarity, which measures the textual consistency of associated field values; or it can be obtained using fine fuzzy matching (threshold matching based on edit distance) and normalized to a value between 0 and 1.

[0062] The business coupling tightness matrix is ​​a predefined data structure used to store the degree of logical association between different business domains. The business coupling tightness coefficient is a value in this matrix, representing the strength of the business association between specific business domain pairs. For example, the values ​​of each coefficient in the business coupling tightness matrix are calculated based on a combination of the co-occurrence frequency of cross-business domain associated records and the upstream and downstream dependencies of business flows. First, the total number of associated records generated between each business domain through associated fields (such as student ID, employee ID, course number) is counted in the past full academic year. The association frequency between business domains i and j is recorded, and the normalized co-occurrence frequency is calculated. Second, according to the school's business process manual, the IT department scores the upstream and downstream dependency strength between business domains (in the range of 0-1) to obtain the dependency degree. Finally, the coupling tightness coefficient = 0.6 × co-occurrence frequency + 0.4 × dependency degree, with the coefficient value truncated to the range [0.1, 0.9] to avoid a zero value causing the association strength to reach zero. Typical values: the coupling coefficient between academic affairs and student affairs is 0.85, between academic affairs and finance is 0.55, and between logistics and library is 0.30. This matrix is ​​incrementally updated at the end of each semester based on newly added related data.

[0063] Entity hierarchy refers to the importance or degree of abstraction of a master data entity within the school administration data model, while the entity hierarchy weight table stores the weight values ​​corresponding to different entity hierarchies. In distinguishing the status and influence of entities at different levels within the network of relationships, the association of core entities (such as students and teachers) is generally more globally significant than that of peripheral entities (such as a specific activity). The entity hierarchy weight table is determined based on the coreity and reusability of entities in the school administration data model. Coreness refers to the frequency with which an entity is referenced in school administration business processes, while reusability refers to the breadth of an entity's cross-business domain associations. Entities are divided into three levels: the core level (students, teachers, courses), with a weight set at 1.0; the business level (classes, colleges, projects, equipment), with a weight set at 0.7; and the transaction level (course selection records, transcripts, repair requests, activity records), with a weight set at 0.4. The hierarchical division and weight values ​​were determined by cross-referencing the data dictionaries of the 10 major business systems across the university; the number of times each entity table was referenced by foreign keys in other business system tables was counted, and the top 20% of the references were assigned to the core layer, the middle 30% to the business layer, and the bottom 50% to the transaction layer; the weight values ​​were taken as the normalized ratio of the average number of references of entities at each level (the core layer was normalized to 1.0, and the other levels were proportionally converted).

[0064] Association strength is a comprehensive numerical indicator that quantifies the reliability, business importance, and core status of the relationship between two merged master data entities. This embodiment organically combines direct evidence at the data level, rationality at the business logic level, and entity importance to generate a single indicator that can comprehensively characterize the quality of the association between entities. For example, the comprehensive association strength value can be obtained by multiplying the three factors.

[0065] The inter-entity association network is a graph structure, where the fused master data entities are nodes, the relationships between them are edges, the edge weights are the association strengths calculated in the previous step, and the edge labels are text or codes describing the relationship type. This embodiment integrates the multi-dimensional information calculated earlier into the graph structure. For example, a graph database (such as Neo4j or JanusGraph) can be used to store and manage the inter-entity association network with weights and labels; alternatively, the network structure can be stored in a relational database, represented as an adjacency list, with additional weight and label fields stored for each edge.

[0066] The preset priority of relation types is based on two dimensions: semantic specificity and business uniqueness. Semantic specificity refers to the clarity of the business meaning expressed by the relation type (e.g., "teaching" is more specific than "association"), and business uniqueness refers to whether the relation type may have multiple semantic meanings simultaneously between the same entity pairs. The priority ranking rule is as follows: relation types with clear business semantics and one-to-one mapping (e.g., student affiliation, course lecturer) have the highest priority, denoted as P1; relation types with clear semantics but may have multiple relationships (e.g., project participation, club member) are denoted as P2; and general association relationships (e.g., related, associated) are denoted as P3. When multiple relation types belong to the same priority level, they are selected in descending order of the frequency of the fields appearing in the source business system. The above priority sequence is configured by business experts during system initialization and is fixed in the relation type metadata table.

[0067] By adopting the above technical solution, when constructing the inter-entity association network, the semantic labels of cross-business domain association fields are first parsed to determine the set of relationship types. Then, the direct matching degree of the association is quantified by combining the character matching of the association field values. A business coupling tightness coefficient is introduced to characterize the inherent reliability of the association between different business domains; and the importance of the association between entities at different levels is distinguished by combining entity hierarchy weights. The association strength is calculated by multiplying the three factors, and the relationship type with the highest priority is selected as the edge label. The constructed association network can accurately represent the true strength and type of the association between entities, avoiding the association distortion caused by single character matching degree, and improving the accuracy of the association network.

[0068] In one embodiment of this application, after constructing the inter-entity association network, the method further includes: Traverse the network of relationships between entities to identify multi-hop paths consisting of at least two directly connected edges with the middle entity being a bridging entity. Read the relation types marked on each directly associated edge on the multi-hop path, and match the sequence of relation types of each directly associated edge on the multi-hop path with the preset relation transitivity rule base; When a multi-hop path satisfies any combination in the relation transitivity rule base, and the total number of hops in the multi-hop path is less than or equal to a preset path length threshold, a direct implicit association edge is generated for the fused master data entities at both ends of the multi-hop path, and the new relation type after transmission corresponding to the combination satisfied in the relation transitivity rule base is used as the edge label of the direct implicit association edge. Calculate the confidence score of directly implicitly associated edges, which is the product of the weights of all directly associated edges on the path and the decay factor. The direct implicit association edges, their confidence levels, and derivation path information are added to the inter-entity association network, and the inter-entity association network with the added implicit association edges is used as part of the school administration data base to participate in multi-level data quality verification.

[0069] In this embodiment, traversing the inter-entity association network aims to discover indirect paths connected by intermediate entities, which contain important implicit associations. Bridging entities are intermediate nodes connecting different parts of a multi-hop path. Their characteristic of having both in-degree and out-degree of 1 ensures the linear transitivity of the path and avoids interference from branches or loops in the derivation of implicit associations.

[0070] In practice, a depth-first search (DFS) algorithm is used to traverse the network of relationships between entities. During the traversal, visited nodes and edges are recorded, and multi-hop paths that meet the conditions are identified based on the path length and the definition of bridging entities (both in-degree and out-degree are 1, and they are not the start or end point).

[0071] Directly related edges on multi-hop paths are labeled with relation types, and these labels together form a sequence of relation types. The relation transitivity rule base predefines which relation type sequences can derive new implicit relations. Matching ensures that the derived implicit associations have logical validity and business semantics. The relation transitivity rule base is stored as structured data (such as JSON, XML files, or database tables), including a mapping between the preceding relation sequences and the derived new relation types. During matching, the identified relation type sequences on multi-hop paths are compared with the preceding sequences in the rule base using strings or lists. Furthermore, the rule base can also be constructed using expert systems or ontology, utilizing a logical reasoning engine for matching. For example, defining a rule that A is B's mentor and B is C's mentor derives that A is C's ancestor mentor; the reasoning engine will automatically identify and apply this rule.

[0072] When a multi-hop path satisfies the rule base conditions and its length is within the path length threshold, it indicates a logically deducible implicit association between the entities at both ends of the path. A direct implicit association edge is generated and assigned a new relation type as a label, making this implicit association explicit and facilitating subsequent data querying and quality verification. In the graph data structure, a new edge is directly added between the merged master data entities at both ends of the path, and its attributes are set (e.g., the edge label is the new relation type). The path length threshold is determined as follows: the path length threshold is set to 3, meaning a maximum of three-hop paths are allowed to deduce implicit associations. Paths exceeding three hops have their confidence decayed to below 0.1 (with an average edge weight of 0.5 and a decay constant of 0.7). 3 ×0.7 2 =0.06125), which is no longer of practical reference value, therefore no implicitly related edges are generated. Simultaneously, the confidence score of the directly implicitly related edges is calculated. This confidence score is the product of the weights of all directly related edges on the path and the decay factor; the decay factor is... α is a preset attenuation constant greater than 0 and less than 1, and n is the total number of hops in the multi-hop path. The attenuation constant α is determined as follows: α is set to 0.7, which is determined based on empirical analysis of typical multi-hop paths in the school administration data; 200 manually labeled effective three-hop transmission paths are statistically analyzed to optimize the value of α by maximizing the Spearman correlation coefficient between the confidence ranking and the manually labeled confidence ranking. Finally, the optimal correlation result is obtained for α in the range of 0.65-0.75, and the median value of 0.7 is taken.

[0073] The derivation of implicit associations is not 100% certain; its confidence level decreases as the path length increases. Calculating confidence levels quantifies this uncertainty, providing a reference for subsequent data quality verification and application, and avoiding over-reliance on derived associations. (Decrease factor) This demonstrates the rationale that the longer the path, the lower the confidence level. When generating implicitly related edges, the weights of each directly related edge on the path (e.g., calculated from the association strength) are multiplied together and then multiplied by a decay factor.

[0074] The derived implicit association edges, their confidence levels, and derivation path information are integrated into the entity relationship network, enabling the school administration data foundation to include more comprehensive entity relationship information. These implicit association edges then participate in multi-level data quality verification, thereby discovering inconsistencies based on implicit associations and improving the depth and breadth of data quality verification. The newly generated implicit association edges are stored as part of the graph data structure, along with the original explicit association edges. When performing multi-level data quality verification, the verification algorithm considers both explicit and implicit associations simultaneously.

[0075] By employing the above technical solution, after constructing a direct association network, multi-hop paths conforming to relation transitivity rules are further traversed and identified to uncover implicit entity associations not directly reflected in the data. Direct implicit association edges are generated for the entities at both ends of eligible multi-hop paths. The confidence level is calculated by multiplying the product of the weights of each edge on the path by a hop count decay factor, quantifying the reliability of the implicit associations. The implicit association edges, their confidence levels, and derived paths are then added to the association network and incorporated into multi-level data quality checks. This approach enriches the association dimensions of the school administration data base while ensuring the accuracy and traceability of newly added implicit associations.

[0076] In one embodiment of this application, adjusting data cleaning parameters based on verification results includes: Extract the merged master data entities involved in the violation and their conflicting attribute fields from the consistency violation events detected by the post-consistency check; Backtrack the cleaning operators and original parameter values ​​used in the data cleaning steps for conflicting attribute fields; Based on the violation frequency and deviation magnitude of the conflict attribute field, the parameter correction amount for the cleaning operator is calculated, and the parameter correction amount is positively correlated with the violation frequency; The parameter correction amount is applied to the corresponding cleaning operator in the data cleaning parameters to obtain the adjusted data cleaning parameters, so as to prioritize the elimination of similar violations when cleaning again after version rollback.

[0077] In this embodiment, post-consistency verification is a quality check performed on the data after data fusion and foundation construction, aiming to detect data inconsistencies caused by entity merging or data integration. For example, when two records from different business domains are merged into a single merged master data entity, a consistency violation will be triggered if they contradict each other on certain key attributes. A consistency violation event is detailed information recorded when post-consistency verification detects data inconsistencies, including the violation type, violating entity identifier, conflicting attribute value, and detection time. The merged master data entity is a unified data representation formed by merging records of the same real-world entity (such as a student or a course) from different source data after cross-business domain entity resolution. The conflicting attribute field is the specific data field that exhibits inconsistency in the consistency violation event. Extracting this information is to accurately pinpoint the problem, rather than generally assuming that the entire entity or all attributes are problematic.

[0078] After locating the conflicting attribute field, the cleaning operators and original parameter values ​​applied to that conflicting attribute field during the data cleaning steps are traced back. Tracing back refers to tracking the data processing process, looking backward from the current state to its historical source and processing logic. Here, it involves tracing the conflicting attribute field back to the processing it underwent during the data cleaning phase. The data cleaning step refers to the stage after data access, where operations such as standardization, deduplication, format conversion, and null value handling are performed on the source data. A cleaning operator is a logical unit or algorithm that performs a specific cleaning task during the data cleaning process; for example, one cleaning operator is responsible for unifying all date formats, while another is responsible for unifying synonyms. Original parameter values ​​refer to the specific configuration parameters used when the cleaning operator is invoked during the data cleaning steps. The purpose of tracing back is to find the cleaning logic that caused the conflict. This can be achieved by recording the data lineage—that is, recording each step of the data processing process, the operators used, and their parameters in detail, forming a traceable chain; or by storing the mapping relationship between cleaning operators and data fields and their parameters through a metadata management system.

[0079] Violation frequency refers to the number of times a consistency violation occurs within a certain timeframe or across multiple iterations for a specific conflicting attribute field or a field processed by a specific cleansing operator. Deviation magnitude refers to the degree of difference between the actual value and the expected value (or the value from other consistent data sources) of a conflicting attribute field. Parameter adjustment amount refers to the amount of time the parameters of the cleansing operator causing the violation need to be adjusted to resolve the consistency violation. Parameter adjustment amount is positively correlated with violation frequency, meaning that the higher the violation frequency, the larger the calculated parameter adjustment amount, and thus the greater the adjustment required to the cleansing operator's parameters.

[0080] The specific calculation method for parameter correction is as follows: Let the current parameter value of the cleaning operator be p0, the violation frequency be f, and the deviation magnitude be d (normalized to the 0-1 interval). Then, the parameter correction Δ = p0 × λ × f × d, where λ is the preset base adjustment coefficient (λ = 0.1). If the operator is triggered for adjustment in three consecutive iterations, λ is reduced to 0.05 to decrease the single adjustment magnitude and avoid over-correction. If the operator is not triggered for adjustment in two consecutive iterations, λ is gradually restored to 0.1 (increasing by 0.025 each time, up to a maximum of 0.1). The deviation magnitude is defined as the absolute value of the difference between the conflict attribute value and the expected value (or the majority of consistent values) of that attribute, divided by the maximum allowable difference of that attribute (or standard deviation multiplied by 3), truncated to the [0,1] interval. The adjusted parameter value pnew = p0 + Δ or pnew = p0 - Δ. The specific direction is determined by the violation characteristics. For example, if the null value rate is too high, the filling threshold is increased; if there is a format conflict, the format constraints are relaxed.

[0081] Applying parameter corrections to the corresponding cleaning operators within the data cleaning parameters to obtain adjusted data cleaning parameters means applying the calculated parameter corrections to the existing parameters of the target cleaning operator. The adjusted data cleaning parameters are the new configuration parameters adopted by the cleaning operator after the parameter corrections have been applied. Version rollback refers to restoring the data base to a previous stable or known state, such as a previous version snapshot. Re-cleaning refers to performing cleaning operations on the relevant data again after a version rollback, using the adjusted data cleaning parameters. Prioritizing the resolution of similar violations means that through this parameter adjustment, it is expected that in the next iteration, consistency violations of the same type or with the same cause that led to this adjustment can be effectively resolved.

[0082] By employing the above technical solution, the relevant fused master data entities and conflicting attribute fields are accurately extracted from the violations detected by the post-consistency check. The cleaning operators and original parameter values ​​corresponding to the conflicting fields are traced back along the data processing flow. Parameter correction amounts are calculated based on the frequency and deviation of the violations; the more frequent the violations and the greater the deviation, the larger the correction amount, allowing for targeted adjustments to the parameters of the corresponding cleaning operators. This achieves automatic closed-loop optimization of data cleaning parameters, enabling the cleaning strategy to dynamically adjust based on the actual fusion effect, prioritizing the resolution of high-frequency violations and continuously improving the effectiveness of data cleaning.

[0083] In one embodiment of this application, before applying the parameter correction amount to the corresponding cleaning operator in the data cleaning parameters, the method further includes: Obtain the adjustment direction and adjustment amount of the cleaning operator in the most recent adjustment before the current iteration; If the adjustment direction of the parameter correction amount calculated this time is opposite to the adjustment direction of the most recent adjustment, and the ratio of the violation frequency in this time to the violation frequency in the most recent adjustment falls within the preset oscillation discrimination range, then the parameter correction amount is multiplied by the preset damping coefficient to obtain the suppression correction amount, and the suppression correction amount is applied to the cleaning operator.

[0084] In this embodiment, the adjustment direction and amount of the most recent adjustment of the data cleaning operator before the current iteration are obtained, aiming to establish the ability to perceive the historical adjustment behavior of data cleaning parameters. During the iterative process of data governance, the parameters of the cleaning operator are not static but dynamically adjusted based on the data quality verification results. To avoid disorderly fluctuations in parameters, it is necessary to record key information for each adjustment. For example, after each parameter adjustment, the identifier of the cleaning operator, the timestamp of the adjustment, the parameter values ​​before and after the adjustment, and the derived adjustment direction (e.g., increase, decrease) and adjustment amount (e.g., specific numerical change) can be stored in a historical adjustment log or configuration version management system.

[0085] If the direction of the parameter correction calculated this time is opposite to the direction of the most recent adjustment, and the ratio of the violation frequency in this iteration to the violation frequency in the most recent adjustment falls within the preset oscillation discrimination interval, this step is the judgment logic for identifying parameter oscillation phenomena. When the cleaning parameter changes in opposite directions in two consecutive adjustments, it indicates that the system may be oscillating ineffectively around a local optimum. Simultaneously, by combining the change ratio of the violation frequency, it is determined whether this reverse adjustment is oscillating behavior rather than a normal optimization process. For example, compare the adjustment direction indicated by the parameter correction calculated this time (e.g., positive values ​​indicate increase, negative values ​​indicate decrease) with the most recent adjustment direction obtained from the historical record. Also, calculate the ratio of the violation frequency detected in this iteration to the violation frequency that caused the parameter adjustment in the previous iteration, and compare it with the preset oscillation discrimination interval. Alternatively, define an enumeration type for parameter adjustment directions (e.g., INCREASE, DECREASE, NO_CHANGE). After each correction is calculated, determine its direction. Then, obtain the previous adjustment direction from the historical state of the cleaning operator. If the two are opposite, the violation frequency ratio is further calculated. The oscillation discrimination interval is a pre-configured numerical range used to determine whether the violation frequency fluctuates within a certain range, thereby confirming oscillation.

[0086] The method for determining the oscillation discrimination interval is as follows: the oscillation discrimination interval is set to [0.8, 1.25], that is, when the ratio of the current violation frequency to the previous violation frequency is within this interval, it is judged as an oscillation state. The value of this interval is based on the following considerations: if the ratio is lower than 0.8, it means that the violation has converged, and the current directional change is a normal optimization rather than an oscillation; if the ratio is higher than 1.25, it means that the violation is still aggravating, and the directional change is a response to deterioration rather than an ineffective swing; the interval [0.8, 1.25] covers the small fluctuation situation where the violation frequency does not improve or worsen significantly, effectively distinguishing between ineffective oscillation and effective adjustment.

[0087] This embodiment multiplies the parameter correction by a preset damping coefficient to obtain a suppressed correction, which is then applied to the cleaning operator. This step is a control mechanism to address parameter oscillations, aiming to smooth the step size of parameter adjustments and prevent over-correction. The damping coefficient is a value between 0 and 1, used to reduce the amplitude of the correction, thereby making the parameter adjustment more stable and gradual. For example, when the oscillation discrimination condition is met, the original parameter correction calculated in the above steps is multiplied by a preset damping coefficient to obtain a smaller suppressed correction. Subsequently, this suppressed correction is applied to the parameters of the cleaning operator. For example, if the original correction is +10 and the damping coefficient is 0.5, the actual adjustment becomes +5. For example, the damping coefficient is set to 0.5, which means that the reverse correction is suppressed by 50%. This value was determined through simulation experiments on typical oscillation scenarios (simulating 100 continuous oscillation adjustments on 5 representative business domain pairs), and is chosen to minimize the number of iterations required for the parameters to converge to a stable value (average 4.2 times) without triggering new violations.

[0088] By adopting the above technical solution, before applying the calculated parameter correction amount to the cleaning operator, the most recent adjustment direction and amount of the cleaning operator are obtained. When the current correction direction is opposite to the most recent one, and the ratio of the violation frequency of the current correction to the previous one falls within the preset oscillation discrimination range, it is determined that there is a risk of over-correction of parameters, and the parameter correction amount is multiplied by a damping coefficient to suppress it. This effectively avoids the problem of cleaning parameters oscillating back and forth between two extreme values, ensures the stability of the parameter adjustment process, prevents large fluctuations in data cleaning quality caused by repeated parameter adjustments, and improves the robustness of the cleaning strategy.

[0089] In one embodiment of this application, a unified standard fusion governance modeling method for multi-campus and multi-business domain school affairs data further includes: During multiple iterations, monitor the direction of parameter correction for the same cleaning operator. When it is detected that the direction of the parameter correction of the cleaning operator changes alternately in P consecutive iterations, and the fluctuation of the data quality score is consistently lower than the preset oscillation detection threshold, the current parameter value of the cleaning operator is frozen, and a cross-domain rule conflict report is generated. The conflict report includes the frozen operator identifier, at least two business domains involved, conflict attribute fields, and the sequence of correction changes in the most recent P iterations. In subsequent iterations, the automatic parameter adjustment of frozen cleaning operators will no longer be performed. Instead, the violation will be eliminated by adjusting the parameters of other unfrozen cleaning operators or by strengthening the matching constraints in the master data management rules. Strengthening the matching constraints in the master data management rules includes increasing the dynamic matching threshold or increasing the negative penalty weight.

[0090] In this embodiment, monitoring the adjustment direction of the parameter correction amount for the same cleaning operator aims to identify the trend of cleaning operator parameter adjustment and determine whether there is repeated adjustment or failure to converge. Specifically, the sign (positive or negative) of the parameter correction amount of a specific cleaning operator in each iteration is recorded and stored in a history sequence; or, by comparing the parameter correction amount of the current iteration with the parameter correction amount of the previous iteration, if the signs are opposite, it is recorded as alternating direction.

[0091] When parameters are repeatedly adjusted (alternating directions) but data quality improvement is not significant (low fluctuation range), it indicates that the operator is trapped in a local optimum or has deep conflicts. In this case, automatic adjustment should be stopped and a diagnosis should be performed. For example, record the direction of parameter correction for a certain cleaning operator in the most recent P iterations; if the direction alternates between positive and negative within the window, and the maximum fluctuation value of the data quality score (such as F1-score, accuracy, etc.) in the P iterations does not exceed the preset threshold, then a freeze is triggered. After freezing, the identifier of the cleaning operator, the business domain involved, the conflict attribute fields, and the sequence of changes in the most recent P corrections are packaged into a report for manual analysis or reference for subsequent strategy adjustments.

[0092] The number of consecutive alternations P is set to 5, which means that the freeze judgment is triggered when the parameter correction direction changes alternately (+ / - / + / - / + or - / + / - / + / -) in 5 consecutive iterations. This value is determined based on statistical analysis. The maximum number of natural occurrences of direction alternation in the scenario of effective parameter convergence is statistically analyzed, and the 95th percentile (about 4 times) is taken and rounded up so that P=5 can both exclude accidental alternations in the normal optimization process and capture abnormal oscillations in time.

[0093] The oscillation detection threshold is set to 2% of the full quality score. That is, if the quality score is out of 100, freezing is triggered when the fluctuation range remains below 2 points. If a 0-1 normalized score is used, the threshold is 0.02. This value is calculated by statistically analyzing the natural fluctuation range of the data quality score under stable conditions (taking three times the standard deviation σ, i.e., 3σ), to cover 99.7% of normal fluctuation scenarios. This ensures that the freezing mechanism is triggered only during abnormal stable oscillations, without affecting parameter fine-tuning during normal iterations.

[0094] In this embodiment, before each parameter adjustment, it is checked whether the current operator is in the frozen operator list. If it is, its automatic adjustment logic is skipped. Simultaneously, the parameters of other unfrozen cleaning operators are considered for adjustment first. For example, if a formatting operator is frozen, the parameters of the deduplication or normalization operator are adjusted. Furthermore, when a cleaning operator is frozen, the problem is addressed by modifying the master data management rules. Enhancing the matching constraints in the master data management rules includes increasing the dynamic matching threshold or increasing the negative penalty weight. For example, increasing the dynamic matching threshold in the entity parsing step ensures that only records with higher similarity are identified as the same entity, thereby reducing consistency violations caused by erroneous merging. Alternatively, for features such as differences in campus identification that lead to mismatches, their negative penalty weight is increased to exert a greater inhibitory effect in similarity calculation, thereby avoiding cross-campus mismatches due to a lack of movement credentials.

[0095] By employing the above technical solution, the changes in the parameter correction direction and fluctuations in the data quality score of the same cleaning operator are continuously monitored. When the parameter correction direction is detected to change alternately P times consecutively, and the fluctuation range of the data quality score remains below the threshold, it is determined that the cleaning operator has fallen into invalid oscillations caused by cross-domain rule conflicts. Its current parameter value is immediately frozen to avoid invalid iterations; at the same time, a cross-domain rule conflict report including conflict details is generated to guide manual intervention. Instead, the violation is resolved by adjusting the parameters of other unfrozen operators or strengthening the master data matching constraints, thus solving the cross-domain rule conflict problem that automatic parameter adjustment cannot handle.

[0096] In one embodiment of this application, a version rollback is triggered based on a corresponding version snapshot, and the iteration is re-executed from the data cleaning or entity parsing steps, including: The record-level lineage graph is obtained from the operation traceability information of the version snapshot. The record-level lineage graph records the original record from which each cleaned data comes and the cleansing operator applied. Based on the conflict attribute fields detected by the post-consistency check, trace back along the record-level lineage graph to locate the original set of records that constitute the conflict-related fused master data entity, and use the conflict-related fused master data entity as the affected entity; In the inter-entity relationship network, the affected entity and its 1-hop neighbor entities with direct related edges are jointly defined as the governance hot zone; After the version rollback, data cleaning and / or entity parsing will only be re-executed for all original records involved in the governance hot zone. Merged master data entities and their relationships outside the governance hot zone will be reused and will not participate in this reprocessing.

[0097] In this embodiment, the record-level lineage graph is a metadata structure used to track the origin and transformation history of individual data records. Its purpose is to provide a detailed audit trail, clearly showing which original records contributed to specific cleaned data and which cleaning operators were applied. In practice, during data ingestion and cleaning, each transformation step (e.g., parsing, standardization, deduplication) is recorded, input records are associated with output records and the specific cleaning operators used, and this information is stored in a dedicated metadata repository or graph database. Alternatively, lineage information can be directly embedded in the data record itself, for example, as an additional field or unique identifier to link back to its predecessor and transformation steps.

[0098] This embodiment, by using detected conflicts, can trace back to the specific original record of the merged master data entity that caused the problem after processing, thereby narrowing down the scope of the problem. For example, once a conflicting attribute field is identified in the merged master data entity, a reverse traversal query can be performed on the record-level lineage graph, tracing back from the problematic merged master data entity node through the cleansing operator node to the specific cleaned data record that caused the conflicting attribute field, and further tracing back to the original record. Another approach is, if the lineage information is stored in an index database, to directly query all original records that were processed by a specific cleansing operator and resulted in the identified conflicting attribute fields in the affected entities.

[0099] In the inter-entity relationship network, the governance hot zone is defined by the affected entity and its 1-hop neighbors with directly related edges. This aims to define local areas of concern within a broader data context. By including not only directly affected entities but also their immediate neighbors, it ensures that any cascading effects of the initial conflict or dependencies disrupted by fixing the primary entity are considered and resolved within a manageable scope. Specifically, after identifying the affected entity, a graph query is performed on the inter-entity relationship network to find all entities directly connected to the affected entity (i.e., entities connected by an edge). The affected entity and these 1-hop neighbors together constitute the governance hot zone.

[0100] After a version rollback, data cleaning and / or entity resolution are only re-executed on all original records within the governance hotspot. Merged master data entities and their relationships outside the governance hotspot are reused and do not participate in this reprocessing. By limiting reprocessing to records and entities within the governance hotspot, computational load and processing time are reduced compared to a full system rollback. For example, the data processing pipeline (data cleaning and entity resolution) is configured to accept filtering conditions. When a rollback is triggered, this filter will be set to process only original records identified as belonging to the governance hotspot.

[0101] By adopting the above technical solution, when a version rollback is triggered, the record-level lineage graph in the version snapshot is used to accurately trace the original set of records constituting the conflicting entities. Then, the governance hot zone is defined by the affected entities and their 1-hop neighbor entities. Data cleaning and entity parsing are only re-performed on the original records within the hot zone, while all data outside the hot zone is reused. This significantly reduces the amount of data that needs to be reprocessed during iterative governance, improving iteration efficiency. At the same time, it avoids unnecessary disturbance to data that is not affected by the conflict, ensuring the overall stability and continuity of the school's data base.

[0102] Corresponding to the unified standard fusion governance modeling method for multi-campus and multi-business domain school affairs data in the above embodiment, Figure 2 This is a structural block diagram of a unified standard fusion governance modeling system for multi-campus, multi-business domain school affairs data provided in one embodiment of this application. For ease of explanation, only the parts relevant to this embodiment are shown. References Figure 2 The unified standard integration governance modeling system 20 for multi-campus and multi-business domain school affairs data includes: a data access and cleaning module 21, an entity parsing module 22, an association network construction module 23, a base construction and quality verification module 24, and an iterative governance module 25.

[0103] Among them, the data access and cleaning module 21 is used to obtain source data of school affairs data from multiple campuses and multiple business domains, and after adding metadata including campus identifiers and business domain tags through a unified access standard, it performs data cleaning based on preset data cleaning parameters and outputs cleaned data. Entity parsing module 22 is used to perform cross-business domain entity parsing on the cleaned data based on preset master data management rules, and generate fused master data entities; The association network construction module 23 is used to construct an inter-entity association network based on the cross-business domain association fields retained in the cleaned data, with the merged master data entities as nodes; The base construction and quality verification module 24 is used to aggregate the integrated master data entities and the relationship network between entities to form the school affairs data base, and to perform multi-level data quality verification on the school affairs data base iteratively. The multi-level data quality verification includes integrity verification and consistency verification. The consistency verification includes post-consistency verification. After each iteration of the base update, a version snapshot with timestamp and operation traceability is generated, and the data quality score of each business domain is output. The iterative governance module 25 is used to adjust the data cleaning parameters of the data access and cleaning module according to the verification results when the data quality score fails to meet the preset quality conditions or the post-consistency verification detects consistency violations caused by entity merging. It also triggers version rollback based on the corresponding version snapshot and controls the data access and cleaning module and / or entity parsing module to re-execute the iteration from the data cleaning step or entity parsing step until the data quality score meets the preset quality conditions and there are no consistency violations, and finally outputs a unified data view.

[0104] See Figure 3 , Figure 3 This is a schematic block diagram of an electronic device provided according to an embodiment of this application. Figure 3 The electronic device 300 in this embodiment may include one or more processors 301, one or more input devices 302, one or more output devices 303, and one or more memories 304. The processors 301, input devices 302, output devices 303, and memories 304 communicate with each other via a communication bus 305. The memories 304 store computer programs, including program instructions. The processors 301 execute the program instructions stored in the memories 304. Specifically, the processors 301 are configured to invoke the program instructions to perform the functions of the modules in the aforementioned device embodiments, for example... Figure 2 The functions of the data access and cleaning module 21, entity parsing module 22, association network construction module 23, base construction and quality verification module 24, and iterative governance module 25 are shown.

[0105] It should be understood that, in the embodiments of this application, the processor 301 may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0106] Input device 302 may include a touchpad, a fingerprint sensor (for collecting the user's fingerprint information and fingerprint orientation information), a microphone, etc., and output device 303 may include a display (LCD, etc.), a speaker, etc.

[0107] The memory 304 may include read-only memory and random access memory, and provides instructions and data to the processor 301. A portion of the memory 304 may also include non-volatile random access memory. For example, the memory 304 may also store device type information.

[0108] In specific implementations, the processor 301, input device 302, and output device 303 described in the embodiments of this application can execute the implementation methods described in any embodiment of the unified standard fusion governance modeling method for multi-campus and multi-business domain school affairs data provided in the embodiments of this application, or they can execute the implementation methods of the electronic devices described in the embodiments of this application, which will not be repeated here.

[0109] In another embodiment of this application, a computer-readable storage medium is provided. This computer-readable storage medium stores a computer program, which includes program instructions. When executed by a processor, the program instructions implement all or part of the processes in the methods described above. Alternatively, the computer program can instruct related hardware to complete the process. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include any entity or device capable of carrying computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc.

[0110] The computer-readable storage medium can be an internal storage unit of the electronic device in any of the foregoing embodiments, such as a hard disk or memory of the electronic device. The computer-readable storage medium can also be an external storage device of the electronic device, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, etc., equipped on the electronic device. Furthermore, the computer-readable storage medium can include both internal and external storage units of the electronic device. The computer-readable storage medium is used to store computer programs and other programs and data required by the electronic device. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0111] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0112] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the electronic devices and units described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0113] In the several embodiments provided in this application, it should be understood that the disclosed electronic devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces or units, or it may be an electrical, mechanical, or other form of connection.

[0114] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments of this application, depending on actual needs.

[0115] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0116] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A unified standard fusion governance modeling method for multi-campus, multi-business domain school affairs data, characterized in that, include: The source data of school affairs data from multiple campuses and business domains is obtained, and after adding metadata including campus identifiers and business domain tags through a unified access standard, the data is cleaned based on preset data cleaning parameters, and the cleaned data is output. Based on preset master data management rules, cross-business domain entity parsing is performed on the cleaned data to generate a fused master data entity. Based on the cross-business domain association fields retained in the cleaned data, an inter-entity association network is constructed with the fused master data entity as the node; The fused master data entity and the network of relationships between the entities are aggregated to form a school affairs data base. The school affairs data base is iteratively subjected to multi-level data quality checks, including integrity checks and consistency checks. The consistency checks include post-consistency checks. After each iteration of the base is updated, a version snapshot with timestamps and operation traceability is generated, and the data quality scores of each business domain are output. When the data quality score fails to meet the preset quality conditions, or when the post-consistency check detects a consistency violation caused by entity merging, the data cleaning parameters are adjusted according to the check results, a version rollback is triggered based on the corresponding version snapshot, and the iteration is re-executed from the data cleaning or entity parsing steps until the data quality score meets the preset quality conditions and there are no consistency violations, and finally a unified data view is output.

2. The unified standard fusion governance modeling method for multi-campus, multi-business domain school affairs data according to claim 1, characterized in that, The process, based on preset master data management rules, involves performing cross-business domain entity parsing on the cleaned data to generate a merged master data entity, including: Based on the globally unique code preset in the master data management rules, deterministic matching is performed on the records in the cleaned data, and records with the same globally unique code are associated with the same entity, resulting in a set of deterministically matched entity records and a set of remaining records that did not pass the deterministic matching. Extract the campus identifier and other entity attributes carried by each record in the remaining record set to form similarity features; for the pair of records to be matched in the remaining record set, determine the business domain pair combination composed of the source business domains of the two records according to the source business domains indicated by the business domain tags of the two records in the pair of records to be matched. Based on the business domain pair combination, obtain the confidence coefficient corresponding to the business domain pair combination, and use the confidence coefficient to adjust the preset initial matching threshold to obtain the dynamic matching threshold; Based on the preset feature weights corresponding to the entity attributes in each of the similarity features, the weighted similarity score of the record pairs to be matched is calculated. Record pairs with weighted similarity scores greater than the dynamic matching threshold are determined to be the same entity and merged to generate a similarity matching entity record set. The deterministic matching entity record set and all records in the similarity matching entity record set that are identified as the same entity are merged to generate the fused master data entity.

3. The unified standard fusion governance modeling method for multi-campus, multi-business domain school affairs data according to claim 2, characterized in that, The calibration method for the credibility coefficient corresponding to the combination of business domains includes: Obtain the similarity matching entity record set generated by the combination of the business domain pairs in the previous iteration, and the consistency violation records of the similarity matching entity record set detected by the post-consistency check in the multi-level data quality check; Calculate the percentage of the consistency violation record in the total number of records in the similarity-matching entity record set; When the percentage exceeds the preset violation tolerance threshold for K consecutive iterations, the credibility coefficient corresponding to the business domain pair combination is reduced based on the preset decay step size, and the dynamic matching threshold is readjusted based on the reduced credibility coefficient in the entity parsing of subsequent iterations. When the proportion falls below the violation tolerance threshold for M consecutive iterations in subsequent iterations, the credibility coefficient corresponding to the business domain pair combination is gradually restored based on the preset recovery step size until it is less than or equal to the initial value of the credibility coefficient, and the credibility coefficient is always greater than or equal to the preset lower limit value of the credibility coefficient.

4. The unified standard fusion governance modeling method for multi-campus, multi-business domain school affairs data according to claim 2, characterized in that, Extracting the campus identifier and other entity attributes carried by each record in the remaining record set to form similarity features, and also including: When the campus identifiers of the two records to be matched are different, identify whether the two records carry a predefined cross-campus entity movement marker field, which includes the student status change number or the joint training program number. If at least one record has the cross-campus entity movement marker field and the field value is the same, the campus identifier difference is determined to be invalid, and the contribution of the campus identifier difference to the weighted similarity score calculation is set to zero. If neither of the two records has the cross-campus entity movement marker field, or the field values ​​are inconsistent, then the campus identifier difference is used as a binary penalty feature and given a negative penalty weight, so that the weighted similarity score of the pair of records to be matched is reduced by the preset penalty value.

5. The unified standard fusion governance modeling method for multi-campus, multi-business domain school affairs data according to claim 1, characterized in that, The step of constructing an inter-entity association network based on the cross-business domain association fields retained in the cleaned data, with the fused master data entity as the node, includes: Parse the predefined semantic tags carried by the cross-business domain related fields to determine the set of relationship types corresponding to each related field; For any two merged master data entities connected by any associated field, obtain the set of relationship types and the character matching degree of the associated field value; Based on the business domain to which the connected entities belong, query the business coupling tightness coefficient of the business domain pair formed by the two business domains from the preset business coupling tightness matrix. Based on the entity hierarchy of the two fused master data entities, the corresponding entity hierarchy weight is queried from the preset entity hierarchy weight table; The association strength between the two fused master data entities is calculated by multiplying the character matching degree, the business coupling tightness coefficient, and the entity hierarchy weight. The relationship strength between the two fused master data entities is used as the weight of the edge, and the highest priority relation type selected from the relation type set is used as the edge label to construct the entity association network.

6. The unified standard fusion governance modeling method for multi-campus, multi-business domain school affairs data according to claim 1, characterized in that, After constructing the network of relationships between entities, the following is also included: Traverse the network of relationships between entities to identify multi-hop paths consisting of at least two directly related edges that are connected end to end and whose intermediate entities are bridging entities. Read the relation types marked on each directly associated edge of the multi-hop path, and match the sequence of relation types of each directly associated edge of the multi-hop path with a preset relation transitivity rule base; When the multi-hop path satisfies any combination in the relation transitivity rule base, and the total number of hops of the multi-hop path is less than or equal to a preset path length threshold, a direct implicit association edge is generated for the fused master data entities at both ends of the multi-hop path, and the new relation type after transmission corresponding to the satisfied combination in the relation transitivity rule base is used as the edge label of the direct implicit association edge. Calculate the confidence score of the directly implicitly associated edges, which is the product of the weights of each directly associated edge on the path and the decay factor. The direct implicit association edges, their confidence levels, and derivation path information are added to the inter-entity association network.

7. The unified standard fusion governance modeling method for multi-campus, multi-business domain school affairs data according to claim 1, characterized in that, The step of adjusting the data cleaning parameters based on the verification results includes: From the consistency violation events detected by the post-consistency check, extract the fused master data entities involved in the violation and their conflict attribute fields; The cleaning operators and original parameter values ​​used in the data cleaning steps for the conflicting attribute fields were traced back. Based on the violation frequency and deviation magnitude of the conflict attribute field, the parameter correction amount for the cleaning operator is calculated, and the parameter correction amount is positively correlated with the violation frequency; The parameter correction amount is applied to the corresponding cleaning operator in the data cleaning parameters to obtain the adjusted data cleaning parameters.

8. A unified standard fusion governance modeling system for multi-campus, multi-business domain school affairs data, characterized in that, include: The data access and cleaning module is used to acquire source data of school affairs data from multiple campuses and business domains. After adding metadata including campus identifiers and business domain tags through a unified access standard, the data is cleaned based on preset data cleaning parameters and the cleaned data is output. The entity parsing module is used to perform cross-business domain entity parsing on the cleaned data based on preset master data management rules, and generate fused master data entities; The association network construction module is used to construct an inter-entity association network based on the cross-business domain association fields retained in the cleaned data, with the fused master data entity as the node; The base construction and quality verification module is used to aggregate the fused master data entity and the network of relationships between the entities to form a school affairs data base, and to iteratively perform multi-level data quality verification on the school affairs data base. The multi-level data quality verification includes integrity verification and consistency verification. The consistency verification includes post-consistency verification. After each iteration of the base update, a version snapshot with timestamp and operation traceability is generated, and the data quality score of each business domain is output. The iterative governance module is used to adjust the data cleaning parameters of the data access and cleaning module according to the verification results when the data quality score fails to meet the preset quality conditions or the post-consistency verification detects a consistency violation caused by entity merging. It also triggers version rollback based on the corresponding version snapshot and controls the data access and cleaning module and / or the entity parsing module to re-execute the iteration from the data cleaning step or the entity parsing step until the data quality score meets the preset quality conditions and there is no consistency violation, and finally outputs a unified data view.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 7.

Images