A multi-level group ecological environment assessment subsystem and an assessment method

Abstract

The application discloses a kind of multi-level group ecological environment examination subsystem and examination method, it is related to ecological environment processing technical field. Including: an evidence graph construction unit is used to establish organization unit table, organization path table and index rule table in the relational database of same platform, and according to database view output generates evidence node and evidence relationship to form examination evidence graph;A fusion and calculation unit is used to generate hierarchical consistent score fragment set based on examination evidence graph;A flow unit is used to automatically generate reference score according to hierarchical consistent score fragment set, and flows according to the order of self-score, two-level audit and group audit.This application effectively solves the problems of low data processing efficiency, rigid weight configuration, difficult to trace results and insufficient system scalability in the prior art, and provides efficient, fair and practical technical support for the ecological environment management examination of multi-level groups.

Description

A multi-level group ecological environment assessment subsystem and assessment method Technical Field

[0001] This invention relates to the field of ecological environment treatment technology, and in particular to a multi-level group ecological environment assessment subsystem and assessment method. Background Technology

[0002] As environmental protection requirements continue to rise, the environmental management assessment of large group enterprises has gradually evolved from single-indicator evaluation to a comprehensive assessment system encompassing multiple dimensions and levels. Currently, the most common practice is to rely on traditional assessment information systems or spreadsheet tools (such as Excel) for data collection and statistics. This approach has a certain application foundation in multi-level structures of group companies, second-tier enterprises, and third-tier units, and can achieve basic environmental indicator aggregation and scoring. However, with the rapid increase in enterprise scale and data complexity, existing technologies are gradually revealing numerous problems.

[0003] Firstly, regarding data acquisition and processing, most commonly used systems currently rely on manual data entry and integration. Each unit needs to fill out various reports during the assessment period, and managers then manually summarize these reports. Although some systems support importing data from multiple sources, the lack of a unified organizational hierarchy and data standards often leads to inconsistencies in unit levels, different indicator definitions, and data loss or duplication. This manual processing method is inefficient, has a high error rate, and fails to meet the group's requirements for real-time performance and accuracy.

[0004] Secondly, in terms of weighting and calculation logic, most existing technologies employ fixed or empirical weighting methods, meaning that management pre-determines the percentage of each indicator's score. This approach is too rigid and cannot dynamically reflect the differences in the company's key tasks throughout the year. For example, in some years, pollutant emissions are a priority, so the weight of related indicators should be increased accordingly, while in other years, risk event prevention and control are more important, so the assessment ratio should be adjusted. Existing technologies fail to provide an effective dynamic weighting calculation mechanism, resulting in assessment results that do not truly reflect the company's actual performance under different environmental circumstances.

[0005] Secondly, regarding data traceability and reliability, existing systems typically only store final scores and some original tables, lacking fine-grained evidence records and relationship tracing mechanisms. In the event of a performance evaluation dispute, managers often need to manually search and compare multiple source documents, which is time-consuming, labor-intensive, and makes it difficult to guarantee that the data has not been tampered with. Especially in a multi-tiered group structure, the division of responsibilities across units is difficult to track and audit technically through existing performance evaluation systems. Summary of the Invention

[0006] In view of this, the present invention provides a multi-level group ecological environment assessment subsystem and method. Within a relational database on the same platform, relying on organizational unit tables, organizational path tables, indicator rule tables, evidence node tables, and evidence relationship tables, a standardized registration of organizational levels and indicator rules is achieved through an evidence graph construction unit. A fusion and calculation unit completes evidence fingerprint deduplication, window summary generation, conflict fingerprint grouping, and shadow node completion, forming a set of hierarchically consistent score fragments. In the circulation unit, a closed-loop circulation process is executed sequentially, including reference score generation, self-assessment, secondary review, and group approval, ultimately outputting a traceable final result. This technical solution significantly improves the automation and accuracy of assessment data processing, ensures consistency and integrity in inter-level transmission, provides full-process traceability and tamper resistance, and possesses good scalability and portability. Therefore, it effectively solves the problems of low data processing efficiency, rigid weight configuration, difficulty in result traceability, and insufficient system scalability in existing technologies, providing efficient, fair, and implementable technical support for the ecological environment management assessment of multi-level groups.

[0007] The technical solution adopted in this invention is as follows:

[0008] A multi-level group ecological environment assessment subsystem includes:

[0009] An evidence graph construction unit is used to create an organizational unit table, an organizational path table, and an indicator rule table in a relational database on the same platform, compile the indicator rules into a database view, traverse the records in the organizational unit table and recursively go from bottom to top to the root node according to the parent code, write the ordered code from root to leaf into the root code field, second-level code field, third-level code field, and complete path field of the organizational path table, and generate evidence nodes and evidence relationships based on the database view output to form an assessment evidence graph.

[0010] A fusion and computation unit is used to standardize and deduplicate the database view output based on the assessment evidence graph and evidence fingerprints to obtain standardized results. The standardized results are compressed into continuous segments based on organizational paths, and upward pass-through windows and downward look-back windows are established within each segment to generate upstream and downstream corresponding database views, and window summaries are recorded. When contradictory evidence for the same indicator appears at the same node, conflict fingerprints are generated based on the source, generation order, and coverage area, and the contradictory evidence is grouped. Stable evidence is then selected all at once, and the unselected evidence is registered with conflict fingerprints. Shadow nodes are generated for continuous gaps between stable evidence, and the shadow nodes record the gap start and end, nearest neighbor summary, and rollback flag. The standardized results, window summaries, conflict fingerprints, and shadow nodes are written back to the preset evidence node table and preset evidence relationship table in their original positions to generate a hierarchically consistent score segment set.

[0011] A workflow unit is used to automatically generate reference scores based on a set of hierarchical consistent score segments, and to flow through the system in the order of self-assessment, secondary review, and group approval.

[0012] Furthermore, the Organization Unit table includes fields for Unit Code, Unit Name, Parent Code, Hierarchical Identifier, Activation Flag, Creation Time, and Update Time. The Unit Code is the primary key, and the Parent Code references the Unit Code in the Organization Unit table to form a foreign key constraint. The Hierarchical Identifier is limited to Group Level, Second-Level Level, and Third-Level Level. The Organization Path table includes fields for Unit Code, Root Code, Second-Level Code, Third-Level Code, Full Path, Path Version, Generation Time, and Generation Description. The Unit Code is the primary key. The Indicator Rule table includes fields for Rule Number, Rule Name, Associated Indicator Code, Source Table Name, Filter Condition Expression, Time Field Name, Affiliated Unit Field Name, Aggregation Method, Output Field Name, View Name, Rule Status, and Last Compilation Time. The Rule Number is the primary key.

[0013] Furthermore, the evidence node table includes fields for evidence number, evidence fingerprint, source view name, view record primary key, evidence time, evidence unit code, evidence type, evidence load, registration time, and registration description. Among these, the evidence number is the primary key, and the evidence unit code references the unit code in the organization unit table. The evidence relationship table includes fields for relationship number, master node number, slave node number, relationship type, relationship time, source view name, relationship description, and registration time. Among these, the relationship number is the primary key, and the master node number and slave node number reference the evidence number in the evidence node table.

[0014] Furthermore, the process of determining continuous segments by the fusion and computation unit includes: reading the organization path table, parsing the root encoding field, secondary encoding field and tertiary encoding field for each record, and forming an ordered encoding path from root to leaf in the order of ancestor first and offspring last; recording each ordered encoding path as a continuous segment, and the unique identifier of the continuous segment is obtained by concatenating the root encoding field, secondary encoding field and tertiary encoding field.

[0015] Furthermore, the process by which the fusion and computation unit establishes upward pass-through windows and downward look-back windows within each segment includes: for each continuous segment and each type of evidence, moving the window from the leaf node to the root node in chronological order of evidence time; retaining only the evidence record belonging to the leaf node unit code of the continuous segment in the standardized results corresponding to the current evidence time within the window, and binding the evidence record with the parent node unit code when advancing to the parent node to form an upward snapshot; for each window advancement, generating an upward window corresponding database view containing only four columns—unit code, evidence time, evidence type, and evidence load—within the session using a common table expression; for the same continuous segment and the same type of evidence, moving the window from the root node to the leaf node in chronological order of evidence time; retaining only the evidence record belonging to the root node unit code of the continuous segment in the standardized results corresponding to the current evidence time within the window, and binding the evidence record with the child node unit code when advancing to the child node to form a downward snapshot; for each window advancement, generating a downward window corresponding database view containing only four columns—unit code, evidence time, evidence type, and evidence load—within the session using a common table expression.

[0016] Furthermore, the process of determining contradictory evidence by the fusion and calculation unit includes: if there are two or more evidence records, uplink snapshots or downlink snapshots within the same unit code, the same evidence time and the same evidence type, and their evidence load field content is inconsistent, then they are determined to be contradictory evidence; the process of generating conflict fingerprints and grouping includes: for each group of contradictory evidence, generating a conflict fingerprint by concatenating the unit code, evidence time, evidence type and source view name; grouping the evidence records using the conflict fingerprints as keys, with each group containing the evidence fingerprints of all candidate records and related metadata.

[0017] Furthermore, the process of selecting stable evidence in one go is as follows: Within each group, a unique stable evidence is selected in one go in the following order: priority is given to the candidate record with the smallest lexicographical order of the source view name; if there are multiple candidate records with the same source view name, priority is given to the candidate record with the latest primary key in natural order; if all candidate records come from the same source view name and the primary keys of the view records are indistinguishable, the length of the coverage interval of the candidate records is compared, and the one with the longer coverage interval is given priority; the coverage interval is determined by the evidence time granularity expressed by the candidate record in the database view. If the granularity is the same and the length is equal, the one with the smallest lexicographical order of the evidence fingerprint is selected; the candidate records that are not selected are registered in the evidence relationship table with conflict replacement as the relationship type, and the conflict fingerprint and the summary of the reason for replacement are written in the relationship description; and they are marked as conflict not selected in the evidence node table with a registration description.

[0018] Furthermore, the process of generating shadow nodes for continuous gaps between stable evidence by the fusion and computation unit includes: within the same unit encoding and the same evidence type range, stable evidence is sorted by evidence time; if there is a preset time unit interval between the evidence times of two adjacent stable pieces of evidence, it is identified as a continuous gap; for each continuous gap, a shadow node is inserted into the evidence node table, the evidence type of the shadow node is the same as that of the adjacent stable evidence, the evidence time is recorded as a text description of the gap start and end range, the evidence load is recorded as a nearest neighbor summary, the nearest neighbor summary is the combined text of the evidence fingerprint of the stable evidence closest to the gap at both ends of the gap and the evidence load, and the rollback flag is set to yes; in the evidence relationship table, with completion generation as the relationship type, a subordinate relationship is established between the shadow node and its two nearest neighbor stable pieces of evidence, and the gap start and end range and the rollback flag are written in the relationship description.

[0019] A method for implementing a multi-level group ecological environment assessment subsystem, the method comprising:

[0020] Step 1: Create an organizational unit table, an organizational path table, and an indicator rule table in a relational database on the same platform, and compile the indicator rules into a database view; traverse the records in the organizational unit table and recursively go up to the root node according to the parent code, and write the ordered code from root to leaf into the root code field, second-level code field, third-level code field, and complete path field of the organizational path table; and generate evidence nodes and evidence relationships based on the database view output to form an assessment evidence graph;

[0021] Step 2: Based on the assessment evidence map, standardize and deduplicate the database view output according to the evidence fingerprint to obtain the standardized result; compress the standardized result into continuous segments based on the organizational path table, and establish an upward pass-through window and a downward look-back window in each segment to generate upstream and downstream corresponding database views, and record the window summary; when contradictory evidence appears at the same node for the same indicator, generate conflict fingerprints according to the source, generation order and coverage interval, and group the contradictory evidence, then select stable evidence at once, and register the unselected evidence with conflict fingerprints; generate shadow nodes for continuous gaps between stable evidence, and record the gap start and end, nearest neighbor summary and rollback mark of the shadow nodes; write the standardized result, window summary, conflict fingerprint and shadow nodes back to the preset evidence node table and preset evidence relationship table in their original positions to generate a set of hierarchically consistent score segments;

[0022] Step 3: Automatically generate reference scores based on the set of score segments consistent with the hierarchical level, and process them in the order of self-assessment, secondary review, and group approval.

[0023] By adopting the above technical solutions, this invention achieves the following beneficial effects: By constructing organizational unit tables, organizational path tables, indicator rule tables, evidence node tables, and evidence relationship tables within a relational database on the same platform, a fully traceable assessment evidence map is formed. This map is then used sequentially through the evidence map construction unit, fusion and calculation unit, and circulation unit to realize the entire process of multi-level group ecological environment assessment, resulting in significant benefits. First, this invention avoids the inefficient manual aggregation of external multi-source data in traditional systems. It directly generates standardized results at the database view level and uses evidence fingerprints for deduplication and unique registration, thereby automating the data processing chain and reducing human error. Second, this invention introduces window summaries, conflict fingerprint grouping, and shadow node mechanisms in the fusion and calculation stages. This enables the upstream and downstream transmission of evidence within multi-level organizational paths, the one-time selection of contradictory evidence, and the technical completion of continuous gaps. This mechanism ensures the consistency and integrity of assessment data during hierarchical transmission, solving the problems of data silos and difficulty in tracing in existing technologies. Meanwhile, this invention constructs a sequential workflow within the transfer unit, based on a hierarchically consistent set of score segments, involving reference score generation and self-assessment, secondary review, and group approval. This ensures the objectivity of the result calculation and forms a closed-loop assessment process with full-chain traceability, effectively improving the transparency and fairness of the assessment. Through hierarchical writing of the evidence node table and evidence relationship table, and standardized storage of traceability relationships, this invention ensures that every final result can be traced back to the initial database view record, significantly enhancing data credibility and tamper resistance. Attached Figure Description

[0024] Figure 1 is a schematic diagram of a multi-level group ecological environment assessment subsystem and the system structure of the assessment subsystem in an embodiment of the present invention.

[0025] Figure 2 is a schematic diagram of the compilation performance curve of the index rules in an embodiment of the present invention;

[0026] Figure 3 is a schematic diagram of the continuous segment compression effect in an embodiment of the present invention. Detailed Implementation

[0027] All features disclosed in this specification, or all steps in all disclosed methods or processes, may be combined in any way, except for mutually exclusive features and / or steps.

[0028] Any feature disclosed in this specification, unless otherwise stated, may be replaced by other equivalent or similar features. That is, unless otherwise stated, each feature is merely one example of a series of equivalent or similar features.

[0029] Referring to Figure 1, a multi-level group ecological environment assessment subsystem includes: an evidence map construction unit, a fusion and calculation unit, and a circulation unit.

[0030] In the specific implementation process, the evidence graph construction unit selects the records to be compiled according to the rule status in the indicator rule table. For each record, it verifies that the rule number, rule name, associated indicator code, source table name, filter condition expression, time field name, belonging unit field name, aggregation method, output field name, and view name are all non-empty. It also verifies that the source table name already exists in the relational database of the same platform, that the time field name and belonging unit field name are indeed existing fields of the source table name, and that the output field name does not conflict with existing fields in the source table name. The output semantics of the database view are determined based on the aggregation method field. The value of the aggregation method field indicates that one of the following operations is performed on the records in the source table name: counting, summation, minimum value, maximum value, or average value, and the records are grouped and summarized according to the belonging unit field name and time field name. If the aggregation method field indicates counting, the database view outputs the number of records for each combination of belonging unit field name and time field name; if the aggregation method field indicates summation, minimum value, maximum value, or average value, the output field name corresponds to a numeric field in the source table name, and the aggregation result is output after grouping according to the belonging unit field name and time field name.

[0031] Using the rule number as a unique key, a Structured Query Language (SMQ) view creation statement is generated for each record. This statement uses the source table name as the data source, selects the affiliated unit field name and time field name as grouping keys based on the filter condition expression, outputs the associated indicator code as a constant column, applies the aggregation method to the corresponding data columns and names the result columns as output field names, and outputs the rule number as a constant column. The database view name uses the value of the view name field, and a name duplication check is performed before creation; if a duplicate name is found, a replacement creation strategy is executed. The creation statements are executed sequentially. Upon successful creation, the last compilation time field of the corresponding record in the indicator rule table is written back to the current time, and the rule status field is updated to "compiled". If execution fails, the creation of the current view is rolled back within the same transaction, and a failure description is appended to the rule name field in the indicator rule table, while the original rule status is preserved for subsequent processing. Perform a sampling query on the newly created database view to verify that each output record contains all four types of columns: associated indicator code, unit of origin field name, time field name, and output field name. Also, ensure that the value ranges of the unit of origin field name and time field name are consistent with the corresponding fields in the source table. Only after passing the check can the view creation proceed to the next record; if the check fails, roll back the current transaction and write a failure description.

[0032] Lock the organization unit table and organization path table. Read the unit code, unit name, parent code, hierarchy identifier, activation flag, creation time, and update time fields from the organization unit table to ensure that the unit code is unique and the parent code references the unit code in the organization unit table. Mark records with empty parent codes as root node candidates. Starting from the unit code and using the parent code as a pointer, perform a depth-first traversal. If a visited unit code is encountered again during the traversal, a cycle is determined to exist, the current generation is terminated, and an error message is returned. If a record's parent code does not have a corresponding unit code in the organization unit table, it is determined to be an orphan node, the current generation is terminated, and an error message is returned. Proceed to the next step only if there are no cycles and no orphan nodes.

[0033] Records are processed in ascending order of hierarchical identifier. For a record with a hierarchical identifier of level three, the corresponding level two record is found using its parent code, and then the corresponding group level record is found using the parent code of that level two record. For a record with a hierarchical identifier of level two, the corresponding group level record is found using its parent code. For a record with a hierarchical identifier of group level, its parent code is empty. The recursion terminates when a group level record with an empty parent code is reached.

[0034] The process of determining the ordered code from root to leaf includes: for records with a hierarchical identifier of group level, the unit code of that record is used as the unique element of the ordered code from root to leaf; for records with a hierarchical identifier of second level, the unit code of the group level record is used as the first element, and the unit code of the second level record is used as the last element, forming the ordered code from root to leaf in the order of ancestor first and descendant last; for records with a hierarchical identifier of third level, the unit code of the group level record is used as the first element, the unit code of the second level record is used as the middle element, and the unit code of the third level record is used as the last element, forming the ordered code from root to leaf in the order of ancestor first and descendant last.

[0035] The rules for writing to the organization path table are as follows: For each record with a determined root-to-leaf ordered code, insert or update is performed in the organization path table using the unit code as the primary key. The root code field writes the first unit code of the root-to-leaf ordered code; the second-level code field writes the second unit code of the root-to-leaf ordered code if a second-level hierarchy exists, and writes a null value if no second-level hierarchy exists; the third-level code field writes the third unit code of the root-to-leaf ordered code if a third-level hierarchy exists, and writes a null value if no third-level hierarchy exists; the complete path field writes a string obtained by concatenating the root-to-leaf ordered codes in ancestor-first, descendant-last order using the character ' / '; the path version field is set to 1 when the unit code is first written, and incremented by 1 when the same unit code is written again; the generation time field writes the current time; the generation description field writes text automatically generated by the evidence graph construction unit.

[0036] After all records have been written, a sampling verification is performed on the organization path table to check whether the combination of the root code field, second-level code field, third-level code field, and complete path field is consistent with the hierarchical identifier in the organization unit table. If the hierarchical identifier is a group level, the second-level code field and the third-level code field should be null, and the complete path field should contain only one unit code; if the hierarchical identifier is a second level, the third-level code field should be null, and the complete path field should contain only two unit codes; if the hierarchical identifier is a third level, the complete path field should contain three unit codes. If the verification passes, the transaction is committed; if the verification fails, the transaction is rolled back, and an inconsistency statement is returned.

[0037] The fusion and computation unit standardizes and deduplicates the database view output based on the evidence fingerprint. The process of obtaining the standardization result includes: sequentially reading each database view compiled from the indicator rule table, and confirming the existence of the following for each output record: the associated indicator code column, the belonging unit field name column, the time field name column, and the output field name column; where the associated indicator code column and the database view name jointly identify the source of evidence, the belonging unit field name column corresponds to the unit code in the organization unit table, the time field name column is the evidence time, and the output field name column is the evidence load. If any column is missing, the processing of that database view is stopped and a failure description is recorded. Each output record is rearranged into the following key-value pair set according to a unified field order: source view name, view record primary key, evidence belonging unit code, evidence time, evidence type, evidence load, registration time, and registration description; where the source view name is the name of the database view, the view record primary key is the primary key of the database view or a combination key that uniquely identifies the row, the evidence type is the value of the associated indicator code column, the registration time is the current time, and the registration description is the text generated by the fusion and computation unit through standardization.

[0038] The source view name, view record primary key, evidence unit code, evidence time, evidence type, and evidence load are concatenated into a single line of text in a fixed order. An irreversible digest is calculated to obtain the evidence fingerprint. The evidence fingerprint serves as a unique key for deduplication and association within the current transaction. Within the same database view, when two or more output records have the same evidence fingerprint, the record with the newest registration time is retained as the master record, and other records are marked as duplicate records and not proceeded to subsequent processing. Between different database views, when the evidence unit code, evidence time, and evidence type are all the same, and the evidence load text is consistent, the record with the smaller lexicographical order of the evidence fingerprint is used as the master record, and the remaining records are recorded as same-source records and registered in subsequent write-backs using the same-source relation type aggregation. The retained master records are sorted by evidence unit code and evidence time to form a temporary result set within the session, which serves as a standardized result for direct reference in subsequent steps.

[0039] Then, the fusion and calculation unit reads the organization path table, parses the root encoding field, secondary encoding field, and tertiary encoding field for each record, and assembles an ordered encoding from root to leaf in the order of ancestor first and descendant last. Each ordered encoding is recorded as a continuous segment, and the unique identifier of the continuous segment is obtained by concatenating the root encoding field, secondary encoding field, and tertiary encoding field using the character / .

[0040] For each continuous segment and each type of evidence, the window is moved from leaf to root in chronological order of evidence time. Within the window, only the master record belonging to the leaf node unit code of the current evidence time in the standardized results is retained. As the process moves towards the parent node, this master record is bound to the parent node's unit code, forming an upward snapshot. For each window movement, a database view corresponding to the upward window is generated within the session using a common table expression, containing only four columns: unit code, evidence time, evidence type, and evidence load.

[0041] The process of creating a downward lookback window includes: for the same continuous segment and the same type of evidence, moving the window from root to leaf in chronological order of evidence time. The window retains only the master record belonging to the root node unit code of the continuous segment from the standardized results corresponding to the current evidence time. As the window moves towards child nodes, this master record is bound to the child node unit code, forming a downward snapshot. For each window movement, a database view corresponding to the downward window is generated within the session using a common table expression, containing only four columns: unit code, evidence time, evidence type, and evidence load.

[0042] For each window advance, a window summary is generated. The window summary includes a unique identifier for the continuous segment, the window direction, the unit code of the current node in the window, the evidence time, the evidence type, and the set of evidence fingerprints from either an uplink or downlink snapshot, along with the generation time. The window summary is used only within this transaction and is registered as a relation-type window summary during the write-back phase. When conflicting evidence for the same indicator appears at the same node, conflict fingerprint groups are generated based on the source, generation order, and coverage area. Stable evidence is selected all at once, and the unselected evidence is registered in the conflict summary.

[0043] The rules for determining contradictory evidence are as follows: If two or more master records, upstream snapshots, or downstream snapshots exist within the same unit code, the same evidence time, and the same evidence type, and their evidence load text is inconsistent, then they are determined to be contradictory evidence. The conflict fingerprint generation and grouping process is as follows: For each group of contradictory evidence, a conflict fingerprint is generated by concatenating the unit code, evidence time, evidence type, and source view name. Grouping is performed using the conflict fingerprint as the key, and each group contains the evidence fingerprints of all candidate records and necessary metadata. The stable evidence selection rules include: Within each group, unique stable evidence is selected in the following order: Prioritize the candidate record with the smallest lexicographical order of the source view name; if multiple candidate records have the same source view name, prioritize the candidate record with the newest primary key in natural order; if all candidate records come from the same source view name and the view record primary keys are indistinguishable, compare the length of the candidate record's coverage interval, prioritizing the one with the longer coverage interval; the coverage interval is determined by the evidence time granularity expressed by the candidate record in the database view. If the granularity is the same and the length is equal, select the one with the smallest lexicographical order of the evidence fingerprint.

[0044] Conflict summary registration: Candidate records that are not selected are registered in the evidence relationship table as conflict replacement records of relationship type, and the relationship description is written into the conflict fingerprint and the summary of the reason for replacement; and the conflict is not selected in the evidence node table with the registration description.

[0045] The fusion and computation unit generates shadow nodes for continuous gaps between stable evidence, recording the gap start and end, nearest neighbor summary, and rollback flag. This process includes: within the same unit encoding and the same evidence type, stable evidence is sorted by evidence time. If the evidence times of two adjacent stable pieces of evidence are discontinuous, it is identified as a continuous gap. The shadow node generation process includes: for each continuous gap, a shadow node is inserted into the evidence node table. The evidence type of the shadow node is the same as that of the adjacent stable evidence. The evidence time is recorded as a text description of the gap start and end. The evidence load is recorded as a nearest neighbor summary. The nearest neighbor summary is the combined text of the evidence fingerprint and evidence load of the stable evidence closest to the gap at both ends. The rollback flag is set to "yes". The shadow association process includes: in the evidence relationship table, a subordinate relationship is established between the shadow node and its two nearest neighbor stable pieces of evidence using relationship type completion. The relationship description is written into the gap start and end and the rollback flag.

[0046] The process by which the fusion and calculation unit writes the standardized results, window summaries, conflict summaries, and shadow nodes back to the preset evidence node table and preset evidence relationship table in their original positions includes: for each master record in the standardized results, writing it back to the evidence node table in the manner of inserting if the evidence number primary key does not exist and updating if it exists; taking a new serial number or a reversible code of the evidence fingerprint for the evidence number; and writing standardized values ​​into the fields of evidence fingerprint, source view name, view record primary key, evidence time, evidence unit code, evidence type, evidence load, registration time, and registration description; and inserting shadow nodes into the evidence node table according to the shadow node generation process. For records from the same source, write the relation type "Same Source Aggregation," with the master node number pointing to the retained master record's evidence number and the slave node number pointing to the same source record's evidence number. For window summaries, write the relation type "Window Summary," with the master node number pointing to the evidence number corresponding to the current node's unit code and the slave node number pointing to the evidence number corresponding to the upstream or downstream snapshot. The relation description is written to the window summary text. For conflicting records not selected, write the relation type "Conflict Replacement," with the master node number pointing to the evidence number of stable evidence and the slave node number pointing to the evidence number of unselected evidence. The relation description includes the conflict fingerprint and the reason for replacement. For shadow associations, write the relation type completion generation according to the shadow association process. During write-back, always use the evidence's unit code and evidence time as the location key, without changing the evidence's unit code and evidence time, and without writing across units or time slices to ensure consistency with the standardized result position.

[0047] The process by which the fusion and computation unit ultimately obtains a hierarchically consistent set of score fragments includes: within the same unit code, the same evidence time, and the same evidence type, merging stable evidence and shadow nodes into a fragment candidate set; recording the number of records in the fragment candidate set as the fragment value, the evidence time as the fragment time, the evidence type as the fragment type, and the unit code as the fragment unit to form a score fragment. Based on the definition of continuous segments in the organizational path table, from leaf to root, within the same evidence time and the same evidence type, accumulating the score fragment values ​​of child units to the parent unit, including the parent unit's own score fragment value, and forming a corresponding score fragment at each level node after accumulation. For score fragments with the same unit code, the same evidence time, and the same evidence type, only one record is retained as a hierarchically consistent score fragment. The evidence node of this record, with the evidence type value as a text score fragment, is written into the evidence node table, and the evidence payload is written into the merged text of the fragment value and fragment description; and the node is grouped into a relationship type fragment and established with its source stable evidence and shadow nodes, with the relationship description written into the source quantity and accumulation rule description.

[0048] The workflow unit first retrieves records of text score fragments from the evidence node table, grouping them by the unit code and time of the evidence to obtain a hierarchically consistent score fragment set. The evidence payload is parsed into fragment values ​​and fragment descriptions, with the fragment values ​​appearing as numbers at the beginning of the payload until the first non-numeric character is encountered. Records that fail to be parsed are removed within the transaction, and the registration description field is updated to "Text score fragment parsing failed." The unit code of the evidence in the hierarchically consistent score fragment set is then checked against the organization path table by unit code. If no matching path is found, the fragment is removed, and the registration description field is updated to "No path found." Only fragments that pass the check proceed to the next step.

[0049] Next, the circulation unit executes the fragment merging and sorting list generation process, including: using the unit code and evidence time as keys, accumulating the fragment values ​​under the same key to obtain a fragment summary list at the unit time granularity; generating a sorting list for all units within the same evidence time according to the fragment values ​​in the summary list from smallest to largest, and recording the position number of each unit within that evidence time. After completion, the reference score mapping rule is executed: performing an integer equally spaced mapping on the sorting list within the same evidence time to generate reference scores. Specifically: the unit with the smallest position number has a reference score of 0; the unit with the largest position number has a reference score of 100; the remaining units are evenly distributed between 0 and 100 according to the order of their position numbers, with the preceding position not lower than the following position. When the same fragment value appears, it is assigned the same reference score, and the used integer value is skipped in subsequent positions until the allocation is complete.

[0050] The process of writing reference score nodes and tracing relationships includes: generating a record of text reference score for each unit and evidence time and writing it into the evidence node table; writing the unit code to which the evidence belongs into the unit code; writing the evidence time into the evidence time; writing the evidence load into the combined text of the reference score number and fragment description; writing the registration description field into the text generated by the hierarchical consistent score fragment set mapping; and simultaneously writing the relationship generated by text reference score into the evidence relationship table, with the master node number pointing to the evidence number of the reference score record, the slave node numbers pointing sequentially to the evidence numbers of all score fragment records used to generate the reference score, and the relationship description field writing the number of units used for generation and the mapping caliber description.

[0051] For each unit and evidence time, the workflow unit generates a record of evidence type "text self-assessment request" and writes it to the evidence node table. The unit code and evidence time of the evidence are consistent with the corresponding reference score. The evidence payload is written as "pending submission," and the registration description field is written as "text self-assessment stage started." A relation of relationship type "text self-assessment reference" is written to the evidence relationship table. The master node number points to the evidence number of the reference score record, and the slave node number points to the evidence number of the self-assessment request record. When the operator submits the self-assessment value during the self-assessment stage, the system receives the numerical self-assessment value and text description using a relational database session variable on the same platform and performs the following checks: The self-assessment value must be an integer between 0 and 100. The submission must find a unique reference score record and self-assessment request record in the evidence node table, and their unit code and evidence time must be completely consistent. If a record of evidence type "text self-assessment" already exists for the same unit and the same evidence time, the duplicate submission is rejected and an error message is returned.

[0052] After successful verification, a record with the evidence type of "text self-assessment" is inserted into the evidence node table. The evidence payload contains the combined text of the self-assessment value and the submission description, and the registration description field displays "text self-assessment has been submitted." Simultaneously, a relationship with the relationship type of "text self-assessment submission" is entered into the evidence relationship table, with the master node number pointing to the evidence number of the reference score record and the slave node numbers pointing to the evidence number of the self-assessment record. If no submission is made at the end of the self-assessment stage, the system inserts a record with the evidence type of "text self-assessment" into the evidence node table. The evidence payload directly contains the reference score value, and the registration description field displays "text self-assessment" (defaulting to the reference score).

[0053] The process of initiating and generating the Level 2 audit checklist: Based on the organizational path table, units identified as Level 2 are designated as audit nodes. For each Level 2 unit, all self-assessment records of the unit itself and its Level 3 sub-units under the same evidence time are summarized, generating an audit checklist and writing it into the evidence relationship table as a text-based Level 2 audit reference. The master node number points to the evidence number of the reference score record of the Level 2 unit under the same evidence time, and the slave node numbers point to the evidence numbers of the self-assessment records in the audit checklist one by one. The relationship description field is filled with "Pending Audit". The process of Level 2 audit decision and write-back: Auditors make a decision to approve or reject each self-assessment record in the audit checklist. If approved, the following process is executed: A record of text-based Level 2 audit record is inserted into the evidence node table. The evidence load is written as a combined text of the self-assessment value in numerical form and "Agreed". The registration description field is filled with "Level 2 audit passed". The relationship of text-based Level 2 audit passed is written into the evidence relationship table. The master node number points to the evidence number of the reference score record of the Level 2 unit under the same evidence time, and the slave node number points to the evidence number of the corresponding self-assessment record. When a request is rejected, the following process is executed: A record of text-based Level 2 review record is inserted into the evidence node table. The evidence payload is a combined text of the self-assessment value in numerical form and the text of the rejection. The reason for rejection is entered into the registration description field. A relationship of text-based Level 2 review rejection is entered into the evidence relationship table. The master node number points to the evidence number of the reference score record for this Level 2 unit at this evidence time, and the slave node number points to the evidence number of the corresponding self-assessment record. Simultaneously, the system re-inserts a record of text-based self-assessment request into the evidence node table for this unit and this evidence time. The registration description field is filled with "Text-based Level 2 Review Resubmission," and the verification mechanism is maintained until approval is granted.

[0054] Based on the organizational path table, units identified as group-level are designated as review nodes. For each group-level unit, under the same evidence time, self-assessment records of the unit itself and its second- and third-level sub-units that have passed the second-level review, as well as existing self-assessment records that have not yet entered the second-level review, are summarized to generate a review list. The relationship type is written as "text group review reference" in the evidence relationship table, with the master node number pointing to the evidence number of the reference sub-record of the group-level unit under the evidence time, and the slave node numbers pointing to the evidence numbers of the self-assessment records or second-level review records in the list. The relationship description field is written as "pending review". Group Approval Decision and Final Write-back: The group approval process makes a decision to approve or reject each item on the list. The approval process includes: inserting a record of text-based group approval record into the evidence node table; writing the approved numerical score and the combined text of "approved" into the evidence payload; and writing "text group approval approved" into the registration description field. Simultaneously, a relationship of text-based group approval is written into the evidence relationship table, with the master node number pointing to the evidence number of the reference score record for that group-level unit at that evidence time, and the slave node number pointing to the evidence number of the approved record. The rejection process includes: inserting a record of text-based group approval record into the evidence node table; writing the current record score and the combined text of "rejected" into the evidence payload; and writing the rejection reason into the registration description field. A relationship of text-based group approval rejection is written into the evidence relationship table, with the master node number pointing to the evidence number of the reference score record for that group-level unit at that evidence time, and the slave node number pointing to the evidence number of the rejected record. The system also simultaneously inserts a record of text-based self-assessment request for the rejected unit and evidence time for resubmission and secondary review.

[0055] For the same entity and the same evidence time, if there exists a record of text-based group approval record with a registration description field indicating that the text-based group approval has been passed, then the numerical score of that record will be used as the final result for that entity and that evidence time. If not, the score of the self-assessment record that has passed secondary review will be used as the final result. If still not, the score of the reference score record will be used as the final result. Once the final result is determined, a record of text-based final result will be inserted into the evidence node table for that entity and that evidence time. The evidence load will be written as a combined text of the final result score and the final description, and the registration description field will be locked in the text circulation unit. A relationship of text-based result tracing will be written into the evidence relationship table, with the master node number pointing to the evidence number of the final result record, and the slave node numbers pointing sequentially to the evidence numbers of the group approval record, secondary review record, self-assessment score, or reference score used to form the final result. For all writes involving the same unit and the same evidence time, including reference scores, self-scoring scores, secondary audit records, group approval records, and final results, a range lock based on unit code and evidence time is uniformly applied to the evidence node table and evidence relationship table within the same transaction, prohibiting writes across units or time granularities.

[0056] After all the above writes are successful, the transaction is committed; if any write fails, the transaction is rolled back, and the text "transaction rollback" is written in the registration description field corresponding to the failure record. After the transaction is successfully committed, all traceability relationships between the hierarchical consistency score fragment set, reference score, self-score, second-level audit record, group approval record, and final result can be fully reconstructed in the evidence relationship table.

[0057] The following is an example of implementing this invention within a relational database on the same platform:

[0058] I. Prerequisites and Inputs:

[0059] The organizational unit table contains 5 enabled records: the group level with unit code G100, whose parent code is empty; the second-level level with unit codes S110 and S120, whose parent codes are G100 respectively; the unit codes T111 and T112 belonging to S110; and the unit code T121 belonging to S120.

[0060] The organizational path table has been generated as described above: the complete path for G100 is G100; the complete path for S110 is G100 / S110; the complete path for S120 is G100 / S120; the complete path for T111 is G100 / S110 / T111; the complete path for T112 is G100 / S110 / T112; and the complete path for T121 is G100 / S120 / T121. All path versions are 1.

[0061] Only one rule is enabled in the indicator rule table: rule number is R001, associated indicator code is IND_EVT_A, source table name is SRC_A, filter condition expression is flag='A', time field name is event_date, affiliated unit field name is unit_code, aggregation method is count, output field name is cnt, view name is VW_IND_EVT_A, and rule status is compiled.

[0062] The source table SRC_A already exists in the relational database on the same platform. The example data covers two months, January 2025 and March 2025, with no records in February 2025. This data is used to trigger shadow nodes: T111 has 2 events in January 2025; T112 has 1 event in January 2025; T121 has 3 events in January 2025; G100 has 1 event in January 2025; and only T112 has 2 events in March 2025. Each original row has a monotonically increasing primary key id and flag='A'. The metric rules are compiled into the database view VW_IND_EVT_A, whose output columns include: the associated metric code column IND_EVT_A, the unit field name column unit_code, the time field name column period (monthly normalized date), the output field name column cnt, and the rule number constant column R001. The organizational unit table is processed recursively from bottom to top. The organizational path table has already been completed as previously described, so it will not be repeated here.

[0063] II. Instantiation of the Fusion and Computation Units and the Data Generated

[0064] The output from the database view VW_IND_EVT_A for evidence time 2025-01 is as follows: CNT=2 for T111; CNT=1 for T112; CNT=3 for T121; CNT=0 for S110 (no direct event); CNT=0 for S120 (no direct event); CNT=1 for G100. Evidence fingerprints are generated for each view row in a fixed order. For easy comparison, this example uses 12-bit irreversible decimal digest sample values: the evidence fingerprint for T111@2025-01 is 202501000701; the evidence fingerprint for T112@2025-01 is 202501000501; the evidence fingerprint for T121@2025-01 is 202501000901; and the evidence fingerprint for G100@2025-01 is 202501000201. When writing to the evidence node table, all evidence types are registered as IND_EVT_A, and the evidence payload is written with the corresponding cnt number and a brief description. Continuous segments are defined using the organization path table: G100 / S110 / T111, G100 / S110 / T112, G100 / S120 / T121. For each continuous segment, an upward pass-through window and a downward look-back window are created for the evidence type IND_EVT_A, generating a window summary. Example: In the continuous segment G100 / S110 / T111, when the evidence time is 2025-01, the upward pass-through window binds the master record snapshot of T111 to S110, and then to G100; the downward look-back window binds the master record snapshot of G100 to S110, and then to T111. The corresponding window summaries are registered in the evidence relationship table, with the relationship type being window summary.

[0065] For T111@2025-01, the snapshot value from the upward pass-through window is 2 (from the master record of T111), and the snapshot value from the downward look-back window is 1 (from the master record of G100, downstream bound to T111). Both belong to the same evidence type IND_EVT_A, have the same evidence time, and the same unit code, constituting contradictory evidence. A conflict fingerprint CF_T111_202501_IND_EVT_A_0001 (example value) is generated. After grouping, stable evidence is selected all at once according to the rules: if the source view names are the same, the primary keys of the view records are compared, and the one with the newer natural order is T111@2025-01, and value 2 is selected as stable evidence; the unselected downstream snapshots are registered as conflict summaries of relation type conflict replacement.

[0066] T112 had no record on 2025-02, but a record reappeared on 2025-03. The system generates a shadow node for T112 on 2025-02, with the evidence type still being IND_EVT_A. The evidence payload is written with the nearest neighbor digest referencing the nearest neighbor value of 1 from 2025-01, and a rollback flag is set. The system then generates associated shadow nodes and stable evidence with adjacent nodes, complete with relation type. For the evidence time 2025-01, this example only performs hierarchical summarization of event class counts. Define and calculate: Let... Represents the set of all units; let Indicates single evidence date 2025-01; Order To indicate a unit; to command Units The set of subunits; let Units In time The count of this level; let Units In time The hierarchical consistency count result. The hierarchical consistency rule is... ;in, It is defined as a set of sub-relations from the organization path table at its first occurrence.

[0067] Calculate using the above formula:

[0068] T111: .

[0069] T112: .

[0070] T121: .

[0071] S110: .

[0072] S120: .

[0073] G100: .

[0074] The above 6 units will be in 2025-01 The values ​​are written into the evidence node table as evidence type score fragments, and the stable evidence and shadow nodes (if any) from the corresponding sources are merged and connected by relation type fragments.

[0075] III. Instantiation of the Flow Unit and the Data Generated

[0076] In January 2025, the score fragment values ​​of all units were collected to form a set. Define and calculate the reference score: Let This represents the set of unique values ​​after deduplication and sorting by ascending order of score segments at the same evidence time. Let represent the number of distinct values ​​in the set; Units In time The score segments correspond to the set The subscript position in the middle; let Units In time The reference score. The integer equal-interval mapping rule is as follows: ;in, It is defined as a floor operation at the first occurrence.

[0077] In this example, , Therefore, we obtain the unit with a value of 1 (T112). Units with a value of 2 (T111) Units with a value of 3 (S110, S120, T121) Units with a value of 7 (G100) The six reference scores are written into the evidence node table as evidence type reference scores, and the relationship type reference scores are used to generate the score fragments that are used for calculation.

[0078] A self-assessment request is generated for each unit on January 2025, and then the self-assessments are collected: T111 submits a self-assessment score of 35; T112 does not submit a self-assessment score, but the system writes the score and sets the value to the reference score of 0; T121 submits a self-assessment score of 70; S110 submits a self-assessment score of 68; S120 submits a self-assessment score of 66; G100 submits a self-assessment score of 100. All self-assessments are written to the evidence node table and linked to their respective reference scores as relation type self-assessment submissions. Secondary review stage.

[0079] The review of second-level units includes: S110 reviewing the self-assessment scores of itself and its sub-units T111 and T112. The decisions are as follows: T111's score of 35 is approved; T112's score of 0 is rejected once, the system regenerates a self-assessment request, T112 fails to submit a new score, and S110 ultimately registers T112's score of 0 as approved. S120 reviews the self-assessment scores of itself and its sub-unit T121. The decisions are as follows: T121's score of 70 is approved; S120's score of 66 is approved. Both the approvals and rejections are recorded in the evidence node table as second-level review records, and the second-level review approval or rejection is registered in the evidence relationship table.

[0080] The group approval process includes: Group-level unit G100 reviews all self-assessments that have passed the secondary audit. In this example, all are approved: T111's 35, T112's 0, T121's 70, S110's 68, S120's 66, and G100's 100 are approved. The corresponding group approval records are written into the evidence node table one by one, and a relationship is established between the group approval approval record and the source secondary audit record or self-assessment score, using the relationship type "group approval approved".

[0081] make Units In time The group approved the division; Units In time The second-level review was approved; Units In time Self-assessment; Units In time The final score. The rules for determining the value are as follows:

[0082] ;

[0083] Therefore, in January 2025, we obtained: T111's T112 T121 S110 S120 G100 Write the above 6 final results into the evidence node table, and trace them by relationship type to the corresponding group approval record (if it exists), or secondary audit record, or self-assessment score or reference score.

[0084] The definition of an evidentiary fingerprint is: [The text abruptly ends here, likely due to an incomplete sentence or a formatting error.] Indicates text An irreversible summary function; let Indicates the source view name; let Indicates the primary key of the view record; let Indicate the unit code to which the evidence belongs; Indicate the time of evidence; let Indicate the type of evidence; let This represents the text carrying the evidence. Therefore, the evidence fingerprint is defined as follows: ;in This represents the string concatenation operation. The values ​​mentioned above have been explained upon their first appearance. The decimal digest values ​​202501000701 in the examples are all returned by this function.

[0085] Conflict fingerprints are defined as: Indicate unit code; let Indicate the time of evidence; let Indicate the type of evidence; let Indicates the source view name; defines the conflict fingerprint as... In this example, the conflict grouping key CF_T111_202501_IND_EVT_A_0001 for T111@2025-01 should correspond to an example value defined.

[0086] Referring to Figure 2, the multi-level group ecological environment assessment subsystem of this invention exhibits significant performance optimization characteristics during the compilation of indicator rules. This graph, with the number of rules on the horizontal axis and compilation time on the vertical axis, systematically demonstrates the changing pattern of compilation performance as the number of rules increases. During the system initialization phase, when the number of rules is small (1-15), the compilation time shows a linear growth trend, and the compilation time curve and the view generation rate curve basically overlap, indicating that the system has not yet activated the optimization mechanism. When the number of rules reaches approximately 15, the system triggers the first compilation node. At this time, the compilation engine begins loading the SQL parser and related optimization components, and the compilation time experiences a brief fluctuation. As the number of rules further increases to 25, the system enters the optimization initiation phase. At this node, the compilation engine initiates O2-level optimization and simultaneously activates the parallel compilation mechanism, utilizing four concurrent threads to handle the compilation tasks of multiple rules simultaneously. The slope of the compilation time curve decreases significantly, indicating that the average compilation time per rule begins to shorten. The view generation rate curve shows a clear separation from the compilation time curve at this stage, demonstrating the system's technical advantage in improving the view cache hit rate. When the number of rules reaches 35, the system enters the caching activation phase, which is a critical inflection point in the performance curve. At this point, the view cache hit rate reaches 85%, and many duplicate or similar metric rules can directly reuse the already compiled database views, avoiding the overhead of repeated compilation. The compilation time curve flattens out, indicating that the system has good scalability. The rule status marker line and the cache activation marker line are shown in the figure with different dashed line styles, using dotted lines and long dashed lines respectively, clearly marking the time nodes of system state transitions. In the stable state phase, that is, after the number of rules exceeds 45, the compilation time is basically stable at around 285 milliseconds, and the compilation success rate remains at a high level of 98%. At this point, the system has fully adapted to the processing needs of large-scale rule sets, and the compilation performance has reached its optimal state. The key nodes in the figure are marked with solid black dots, accurately locating the critical values ​​of each performance transition phase, providing important reference data for system tuning and capacity planning.

[0087] Referring to Figure 3, it details the technical effect of the path merging algorithm used in this invention to compress organizational hierarchical data. The figure uses the original data volume as the horizontal axis and the compressed data volume as the vertical axis, quantitatively demonstrating the optimization effect of continuous segment compression technology by comparing the changes in data volume before and after compression. The data volume curve before compression is represented by a black dashed line, showing an accelerating upward trend with the increase of the original data volume. When the original data volume increases from 50MB to 500MB, the space occupied by the unprocessed data increases sharply from 10MB to 100MB, a tenfold increase. This non-linear growth mainly stems from the complexity of the organizational hierarchy, especially when the number of records in the organizational unit table increases, the corresponding organizational path table and related index structure generate exponential storage overhead. The data volume curve after compression is represented by a black solid line, showing a significantly different growth pattern. Under the same original data volume conditions, the data volume growth after continuous segment compression is more gradual, eventually stabilizing at approximately 46MB, saving 54MB of storage space compared to the unprocessed data, achieving a compression ratio of 65%. This effect is achieved primarily through the following technical means: First, the system generates unique segment identifiers according to the concatenation rules of the root encoding field, secondary encoding field, and tertiary encoding field; second, each ordered encoding path is recorded as a continuous segment, realizing logical grouping of data; finally, memory mapping technology is used to load data segment by segment, avoiding duplicate storage of the entire dataset. The four continuous segment markers in the diagram correspond to different scales of data processing stages. Segment 1 begins at 100MB of the original data, marking the start of the continuous segment identification mechanism; Segment 2 begins at 200MB, where the compression effect begins to appear; Segment 3 begins at 300MB, where the compression algorithm enters a stable operating state; Segment 4 begins at 400MB, where the system achieves optimal compression. Each continuous segment has an upward pass-through window and a downward look-back window, and window summaries are automatically generated using CTEs (Common Table Expressions), further optimizing data access efficiency. The space-saving area is represented by light gray fill, visually demonstrating the storage optimization effect brought by the compression technology. The compression effect line is marked with a vertical dashed line, quantifying the 65% saving. This compression effect not only reduces storage costs but also significantly improves the performance of data querying and processing, providing reliable technical support for ecological environment assessment in large-scale group environments.

[0088] This invention is not limited to the specific embodiments described above. The invention extends to any new feature or combination disclosed in this specification, as well as any new method or process step or combination disclosed herein.

Claims

1. A multi-level group ecological environment assessment subsystem, characterized in that, include: An evidence graph construction unit is used to create an organizational unit table, an organizational path table, and an indicator rule table in a relational database on the same platform, compile the indicator rules into a database view, traverse the records in the organizational unit table and recursively go from bottom to top to the root node according to the parent code, write the ordered code from root to leaf into the root code field, second-level code field, third-level code field, and complete path field of the organizational path table, and generate evidence nodes and evidence relationships based on the database view output to form an assessment evidence graph. A fusion and computation unit is used to standardize and deduplicate the database view output based on the assessment evidence graph and evidence fingerprint to obtain the standardized result; The standardized results are compressed into continuous segments based on the organizational path table. Within each segment, upward pass-through windows and downward look-back windows are created to generate upstream and downstream corresponding database views, and window summaries are recorded. When contradictory evidence for the same indicator appears at the same node, conflict fingerprints are generated based on the source, generation order, and coverage area. The contradictory evidence is then grouped, and stable evidence is selected all at once, while the unselected evidence is registered with conflict fingerprints. Shadow nodes are generated for continuous gaps between stable evidence, recording the gap start and end, nearest neighbor summary, and rollback flag. The standardized results, window summaries, conflict fingerprints, and shadow nodes are written back to the preset evidence node table and preset evidence relationship table in their original positions to generate a hierarchically consistent score segment set. A circulation unit is used to automatically generate reference scores based on the hierarchically consistent score segment set and circulates them in the order of self-assessment, secondary review, and group approval.

2. The multi-level group ecological environment assessment subsystem as described in claim 1, characterized in that, The organization unit table contains fields such as unit code, unit name, parent code, hierarchy identifier, activation flag, creation time, and update time. The unit code is the primary key, the parent code references the unit code in the organization unit table to form a foreign key constraint, and the hierarchy identifier is limited to group level, second level, and third level. The organization path table includes fields for unit code, root code, second-level code, third-level code, full path, path version, generation time, and generation description, with the unit code being the primary key. The indicator rule table includes fields for rule number, rule name, associated indicator code, source table name, filter condition expression, time field name, affiliated unit field name, aggregation method, output field name, view name, rule status, and last compilation time, with the rule number being the primary key.

3. The multi-level group ecological environment assessment subsystem as described in claim 2, characterized in that, The Evidence Node table contains fields for Evidence Number, Evidence Fingerprint, Source View Name, View Record Primary Key, Evidence Time, Evidence Tolerant Code, Evidence Type, Evidence Load, Registration Time, and Registration Description. The Evidence Number is the primary key, and the Evidence Tolerant Code references the unit code in the Organization Unit table. The Evidence Relationship table contains fields for Relationship Number, Master Node Number, Slave Node Number, Relationship Type, Relationship Time, Source View Name, Relationship Description, and Registration Time. The Relationship Number is the primary key, and the Master Node Number and Slave Node Number reference the Evidence Number in the Evidence Node table.

4. The multi-level group ecological environment assessment subsystem as described in claim 3, characterized in that, The process of determining continuous segments by the fusion and computation unit includes: reading the organization path table, parsing the root coding field, secondary coding field and tertiary coding field for each record, and forming an ordered coding path from root to leaf in the order of ancestor first and offspring last; recording each ordered coding path as a continuous segment, and the unique identifier of the continuous segment is obtained by concatenating the root coding field, secondary coding field and tertiary coding field.

5. The multi-level group ecological environment assessment subsystem as described in claim 4, characterized in that, The process by which the fusion and computation unit establishes upward pass-through windows and downward look-back windows within each segment includes: for each continuous segment and each type of evidence, moving the window from the leaf node to the root node in chronological order of evidence time; retaining only the evidence record belonging to the leaf node unit code of the continuous segment in the standardized results corresponding to the current evidence time within the window, and binding the evidence record with the parent node unit code when advancing to the parent node to form an upward snapshot; for each window advancement, generating an upward window corresponding database view containing only four columns—unit code, evidence time, evidence type, and evidence load—within the session using a common table expression; for the same continuous segment and the same type of evidence, moving the window from the root node to the leaf node in chronological order of evidence time; retaining only the evidence record belonging to the root node unit code of the continuous segment in the standardized results corresponding to the current evidence time within the window, and binding the evidence record with the child node unit code when advancing to the child node to form a downward snapshot; for each window advancement, generating a downward window corresponding database view containing only four columns—unit code, evidence time, evidence type, and evidence load—within the session using a common table expression.

6. The multi-level group ecological environment assessment subsystem as described in claim 4, characterized in that, The process of determining contradictory evidence by the fusion and calculation unit includes: if there are two or more evidence records, upstream snapshots or downstream snapshots within the same unit code, the same evidence time and the same evidence type, and their evidence load field content is inconsistent, then they are determined to be contradictory evidence; the process of generating conflict fingerprints and grouping includes: for each group of contradictory evidence, generating a conflict fingerprint by concatenating the unit code, evidence time, evidence type and source view name; grouping by using the conflict fingerprint as the key, with each group containing the evidence fingerprints of all candidate records and related metadata.

7. The multi-level group ecological environment assessment subsystem as described in claim 4, characterized in that, in, The process of selecting stable evidence in one go is as follows: Within each group, a unique stable evidence is selected in one go in the following order: First, the candidate record with the smallest lexicographical order of the source view name is selected; if there are multiple candidate records with the same source view name, the candidate record with the latest primary key in natural order is selected; if all candidate records come from the same source view name and the primary keys of the view records are indistinguishable, the length of the coverage interval of the candidate records is compared, and the one with the longer coverage interval is selected; the coverage interval is determined by the evidence time granularity expressed by the candidate record in the database view. If the granularity is the same and the length is equal, the one with the smallest lexicographical order of the evidence fingerprint is selected; the candidate records that are not selected are registered in the evidence relationship table with conflict replacement as the relationship type, and the conflict fingerprint and the summary of the reason for replacement are written in the relationship description; and they are marked as conflict not selected in the evidence node table with a registration description.

8. The multi-level group ecological environment assessment subsystem as described in claim 7, characterized in that, The process of generating shadow nodes for continuous gaps between stable evidence by the fusion and computation unit includes: within the same unit encoding and the same evidence type range, stable evidence is sorted by evidence time; if there is a preset time unit interval between the evidence times of two adjacent stable evidences, it is identified as a continuous gap; for each continuous gap, a shadow node is inserted into the evidence node table. The evidence type of the shadow node is the same as that of the adjacent stable evidence, the evidence time is recorded as a text description of the gap start and end range, and the evidence load is recorded as a nearest neighbor summary. The nearest neighbor summary is the combined text of the evidence fingerprint of the stable evidence closest to the gap at both ends and the evidence load. The rollback flag is set to yes; in the evidence relationship table, completion generation is used as the relationship type, and a subordinate relationship is established between the shadow node and its two nearest neighbor stable evidences. The gap start and end range and the rollback flag are written in the relationship description.

9. A method for implementing the multi-level group ecological environment assessment subsystem as described in any one of claims 1 to 8, characterized in that, The method includes: Step 1: Establishing an organizational unit table, an organizational path table, and an indicator rule table in a relational database on the same platform, and compiling the indicator rules into a database view; traversing the records in the organizational unit table and recursively going up to the root node according to the parent code, and writing the ordered code from root to leaf into the root code field, second-level code field, third-level code field, and complete path field of the organizational path table; and generating evidence nodes and evidence relationships based on the database view output to form an assessment evidence graph; Step 2: Based on the assessment evidence graph, standardizing and deduplicating the database view output according to the evidence fingerprint to obtain the standardization result; compressing the standardization result into continuous segments based on the organizational path table, and establishing an upward pass-through window and a downward pass-through window in each segment. The process involves: viewing the window to generate upstream and downstream corresponding database views and recording the window summary; when contradictory evidence appears at the same node for the same indicator, generating conflict fingerprints based on the source, generation order, and coverage range, grouping the contradictory evidence, selecting stable evidence at once, and registering the unselected evidence with conflict fingerprints; generating shadow nodes for continuous gaps between stable evidence, with shadow nodes recording the gap start and end, nearest neighbor summary, and rollback flag; writing the standardized results, window summary, conflict fingerprints, and shadow nodes back to the preset evidence node table and preset evidence relationship table in their original positions to generate a hierarchical consistent score fragment set; step 3: automatically generating reference scores based on the hierarchical consistent score fragment set, and circulating them in the order of self-assessment, secondary review, and group approval.

Images