Power transaction dispatch data management method, electronic device, medium and system

Abstract

The application relates to the computer technical field and provides a power transaction scheduling data management method, an electronic device, a medium and a system. The management method and the system can be adapted to a power transaction market with multiple regions, a large number of account numbers and large-scale timing scheduling characteristics, provide a management closed loop from power transaction scheduling data collection to relational configuration management to application adaptation, decouple the relationship between the original data provider and the specific application demand side through business isolation, improve the power transaction scheduling data collection, warehousing and management efficiency on the basis of retaining the individual characteristics of the region, and can also meet the data request of various external applications.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, electronic device, medium and system for managing power trading and dispatching data. Background Technology

[0002] In the power trading and dispatch market, each region (such as provincial-level or municipal-level administrative divisions) typically manages its own power trading and dispatch documents and related configurations independently. These documents include the region's power trading accounts, fields, tasks, and other information. Each region may follow different formats and semantic standards when creating and managing its own power trading and dispatch documents. They may also adopt different power trading market access and disclosure rules, as well as personalized implementation details. For example, some regions may define timely dispatch as being within four days of the target date, while others may define it as being one day ahead or behind. Furthermore, different regions may employ inconsistent styles in their dispatch strategies and the maintenance of specific tables and documents. Therefore, from the perspective of the overall management and analysis of large-scale power trading and dispatch data, there are characteristics such as multiple regions, numerous accounts, and large-scale scheduled dispatches. At the same time, each region maintains a strong regional personalization style in managing and maintaining its own power trading and dispatch data, thus posing challenges to the collection and backend application of power trading and dispatch data. If the power trading and scheduling documents of various regions are uniformly converted into the same standardized document structure, such as JSON or Nacos equivalent structured documents, this can ensure the consistency of structured data and knowledge entity relationships, but it also destroys the unique characteristics that each region may have. In particular, the mandatory requirement to convert the personalized expressions of each region into the general expressions specified by the standardized document structure is particularly problematic.

[0003] To this end, this application proposes a management method, electronic device, medium, and system for power trading and dispatching data. It can be adapted to power trading markets with characteristics such as multiple regions, a large number of accounts, and large-scale timed dispatching. It provides a closed-loop management system from the collection of power trading and dispatching data to relational configuration management and application adaptation. By decoupling the relationship between the original data provider and the specific application demander through business isolation, it improves the efficiency of power trading and dispatching data collection, storage, and management while retaining the personalized characteristics of the region. It can also meet the data requests of various external applications. Summary of the Invention

[0004] Firstly, this application provides a method for managing power transaction scheduling data. The method includes: receiving raw data from power transaction scheduling documents for multiple regions, wherein the power transaction scheduling documents for each of the multiple regions respectively conform to the respective business semantic specifications, account task constraints, and regional personalized rules of the multiple regions; Based on fixed mapping rules, the raw data of the power transaction scheduling documents for each of the multiple regions are split into top-level fields and semantically transformed from task fields to generate entity records to be written. These entity records undergo global constraint verification, regional personalized constraint verification, and scheduling strategy semantic consistency verification. After passing the verification, they are persistently written to a relational database according to preset association rules. The relational database is configured with seven types of relational entities, and the preset association rules define scheduling strategy reference relationships based on business natural keys. These scheduling strategy reference relationships indicate associated tasks, association list definitions, association list items, and association pre-defined items. The seven types of relational entities are defined based on the power trading and dispatching business scenario. In response to data requests from external applications, fields associated with the data request are read from the relational database. Based on the data request or target output format of the external application, corresponding data assembly rules are invoked to perform table joins on the read fields associated with the data request, thereby generating output data that conforms to the semantic specifications and disclosure requirements of the standardized structure document associated with the data request. The output data includes runtime configuration and documented results for operation and maintenance collaboration. The configuration management interface of the relational database is used to read or modify the corresponding configuration data.

[0005] The first aspect of this application can be adapted to power trading markets with characteristics such as multiple regions, a large number of accounts, and large-scale timed scheduling. It provides a closed-loop management system from the collection of power trading scheduling data to relational configuration management and application adaptation. By decoupling the relationship between the original data provider and the specific application demander through business isolation, it improves the efficiency of power trading scheduling data collection, storage, and management while retaining the personalized characteristics of the region. It can also meet the data requests of various external applications.

[0006] In one possible implementation of the first aspect of this application, the business semantic specifications of each of the multiple regions adopt a tree-like nested structure. Configuration items in the tree-like nested structure are located based on the hierarchical path of the configuration item. The seven types of relational entities in the scheduling strategy reference relationship each have a corresponding business natural key and can be independently located and edited based on the business natural key. Furthermore, the seven types of relational entities include a region registration relational entity, a region account relational entity, a date range preset relational entity, a timed expression preset relational entity, a timed list definition relational entity, a timed list entry relational entity, and a task scheduling entry relational entity. The data in the relational database is configured to be arranged according to business natural key items and can be edited according to business natural key items. Each of the seven types of relational entities has a corresponding primary key or composite primary key. The composite primary key of the task scheduling entry relational entity includes a region name key item corresponding to the region registration relational entity, a task name key item corresponding to the task scheduling entry relational entity, a list reference key item corresponding to the timed list definition relational entity, and a task category.

[0007] In one possible implementation of the first aspect of this application, the regional personalization rules for each of the multiple regions include a default date offset range and a date difference equivalence rule. The fixed mapping rule is used to convert the default date offset range and write it into a date range preset relational entity. When performing task field semantic conversion or date range verification, the date range is normalized or equivalence is judged according to the date difference equivalence rule of the corresponding region. Furthermore, the regional personalization rules for each of the multiple regions also include a date splitting method. The fixed mapping rule indicates that when performing task field semantic conversion, the regional date preset configuration is read.

[0008] In one possible implementation of the first aspect of this application, the global constraint verification includes ensuring that the entity record to be written meets the account range enumeration requirements, date range type requirements, list reference integrity requirements, task activation binding requirements, and the requirement that new accounts do not participate in public task timed scheduling by default. Furthermore, the regional personalization constraint verification includes performing regional personalization constraint verification according to the regional name key items included in the primary key, so as to ensure that the entity record to be written meets the account task constraint relationship and regional personalization rules of the multiple regions respectively.

[0009] In one possible implementation of the first aspect of this application, the scheduling strategy semantic consistency verification includes ensuring that the entity record to be written satisfies referential integrity, account validity, and date consistency. The referential integrity verification includes: when the entity record to be written is a task scheduling entry entity record, verifying whether the corresponding timed list definition entity exists and corresponds to the same region name key as the task scheduling entry entity record based on the list reference key of the task scheduling entry entity record; and verifying whether the timed expression preset entity referenced by the timed list entry entity belonging to the timed list definition entity exists and corresponds to the same region name key.

[0010] In one possible implementation of the first aspect of this application, the standardized structure document associated with the data request is adapted to various application outputs, including JSON-based applications.

[0011] In one possible implementation of the first aspect of this application, the management method further includes: performing a configuration drift check on the actual scheduling configuration of the external application and the standard configuration assembled according to the relational database, including performing regional normalization processing on the task name and comparing the timing expression and date range corresponding to the normalized task to obtain missing items, redundant items and configuration inconsistencies, thereby outputting a discrepancy list, wherein the discrepancy list is used to identify the drift of the actual scheduling configuration relative to the standard configuration.

[0012] In one possible implementation of the first aspect of this application, the management method further includes: performing configuration management and visual control, including providing a fine-grained configuration management interface for adding, deleting, and modifying task fields, preset timed fields, timed field lists, or regional accounts; and for transactional storage, triggering reference protection when deleting a referenced preset record; and for write operations carrying an operator identifier for auditing.

[0013] In one possible implementation of the first aspect of this application, the management method further includes linking configuration persistence with runtime registration, including: after the configuration is verified and persistently saved, in response to a registration trigger command, reading the assembled runtime configuration, registering periodic tasks in batches and idempotently based on preset task identifiers, and not changing the existing periodic tasks in the message queue before registration is triggered.

[0014] Secondly, embodiments of this application also provide an electronic device, the electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement a method according to any of the above-mentioned implementations.

[0015] Thirdly, embodiments of this application also provide a computer-readable storage medium storing computer instructions that, when executed on an electronic device, cause the electronic device to perform a method according to any of the above-described implementations.

[0016] Fourthly, embodiments of this application also provide a computer program product, the computer program product including instructions stored on a computer-readable storage medium, which, when executed on an electronic device, cause the electronic device to perform a method according to any of the above-described aspects.

[0017] Fifthly, this application provides a management system for power transaction scheduling data. The management system includes: a receiving layer configured to receive raw data from power transaction scheduling documents of multiple regions; a parsing, splitting, and database conversion layer configured to: perform top-level field splitting and task field semantic transformation on the raw data of the power transaction scheduling documents of the multiple regions based on fixed mapping rules, thereby generating entity records to be written, wherein the power transaction scheduling documents of the multiple regions respectively conform to the business semantic specifications, account task constraints, and regional personalized rules of the multiple regions; a global constraint and regional personalized constraint layer configured to perform global constraint verification and regional personalized constraint verification on the entity records to be written; a semantic verification layer configured to perform scheduling strategy semantic consistency verification on the entity records to be written; and a hierarchical storage layer configured to: persistently write the data to a relational database according to preset association rules after successful verification, wherein the relational database uses seven types of relational databases. The entities form a unified configuration. The preset association rules define the scheduling strategy reference relationship based on the business natural key items. The scheduling strategy reference relationship indicates the associated task, the association list definition, the association list item, and the association preset expression. The seven types of relational entities are determined based on the power trading scheduling business scenario. The configuration assembly layer is configured to: respond to data requests from external applications, read the fields associated with the data request from the relational database, and, based on the data request or target output format of the external application, call the corresponding data assembly rules to perform table join assembly on the read fields associated with the data request, thereby generating output data that conforms to the semantic specifications and disclosure requirements of the standardized structure document associated with the data request. The output data includes runtime configuration and documented results for operation and maintenance collaboration. The configuration management interface of the relational database is used to read or modify the corresponding configuration data.

[0018] The fifth aspect of this application can be adapted to power trading markets with characteristics such as multiple regions, a large number of accounts, and large-scale timed scheduling. It provides a closed-loop management system from the collection of power trading scheduling data to relational configuration management and application adaptation. By decoupling the relationship between the original data provider and the specific application demander through business isolation, it improves the efficiency of power trading scheduling data collection, storage, and management while retaining the personalized characteristics of the region. It can also meet the data requests of various external applications. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 A flowchart illustrating a method for managing power trading and dispatching data, provided as an embodiment of this application; Figure 2 A schematic diagram illustrating a structured scheduling configuration entity relationship provided in an embodiment of this application; Figure 3 A schematic diagram illustrating a method for parsing, splitting, storing, and configuring assembly provided in an embodiment of this application; Figure 4 A schematic diagram illustrating a global and regional dual-layer constraint and a visual control mapping provided for an embodiment of this application; Figure 5 This is a schematic diagram illustrating the linkage between configuration modification, registration, verification, and drift checking in an embodiment of this application. Figure 6 A schematic diagram of a power trading and dispatching data management system provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0021] The embodiments of this application will now be described in further detail with reference to the accompanying drawings.

[0022] It should be understood that in the description of this application, "at least one" means one or more, and "multiple" means two or more. In addition, the words "first," "second," etc., unless otherwise stated, are used only for the purpose of distinguishing descriptions and should not be construed as indicating or implying relative importance or order.

[0023] Figure 1This is a flowchart illustrating a method for managing power trading and dispatching data, provided as an embodiment of this application. Figure 1 As shown, the management method includes the following steps.

[0024] Step S110: Receive the raw data of the power trading scheduling documents of each of the multiple regions, wherein the power trading scheduling documents of each of the multiple regions respectively conform to the business semantic specifications, account task constraint relationships and regional personalized rules of the multiple regions.

[0025] Step S120: Based on fixed mapping rules, perform top-level field splitting and task field semantic transformation on the original data of the power transaction scheduling documents of the multiple regions to generate entity records to be written.

[0026] Step S130: Perform global constraint verification, regional personalized constraint verification, and scheduling strategy semantic consistency verification on the entity record to be written. Then, after the verification passes, persist the record to the relational database according to the preset association rules. The relational database is configured with seven types of relational entities. The preset association rules define the scheduling strategy reference relationship based on the business natural key item. The scheduling strategy reference relationship indicates the associated task, the association list definition, the association list item, and the association preset expression. The seven types of relational entities are determined based on the power trading and scheduling business scenario.

[0027] Step S140: In response to a data request from an external application, read the fields associated with the data request from the relational database, and, based on the data request or target output format of the external application, invoke the corresponding data assembly rules to perform table join assembly on the read fields associated with the data request, thereby generating output data that conforms to the semantic specifications and disclosure requirements of the standardized structure document associated with the data request. The output data includes runtime configuration and documented results for operation and maintenance collaboration. The configuration management interface of the relational database is used to read or modify the corresponding configuration data.

[0028] See Figure 1 To adapt to the characteristics of the power trading market, which has multiple regions, a large number of accounts, and large-scale timed scheduling, and to adapt to the different formats and semantic specifications that different regions may follow in creating and managing their own power trading scheduling documents, Figure 1The power trading and scheduling data management method described does not directly convert power trading and scheduling documents from various regions into a unified standardized document structure, such as JSON or Nacos equivalent structured documents. Instead, it uses a relational database with seven types of relational entities as an intermediate step. Firstly, before the original data of the power trading and scheduling documents from each region is entered into the database, based on fixed mapping rules, top-level field splitting and task field semantic transformation are performed on the original data of the power trading and scheduling documents from each region. Then, it is written into the relational database with seven types of relational entities according to preset association rules. Here, the seven types of relational entities are determined based on the power trading and scheduling business scenario, and the preset association rules limit the scheduling strategy reference relationship based on business natural keys. Thus, the format, semantic specifications, and structured document format used by the power trading and scheduling documents from each region may not be directly editable item by item according to business natural keys. For example, the common structured document JSON format uses a nested tree structure, nesting grouping, categories, timing fields (CRON), preset lists, and preset date ranges into a specific data structure. This makes it impossible to directly process the data according to natural business logic after parsing, splitting, and storing it in the database. For instance, in the power trading market, facing multiple regions, numerous accounts, and large-scale scheduled dispatching, the natural business processing logic is to use region plus task name plus list reference. Therefore, before the original data is stored in the database (including initial data storage and data migration), top-level field splitting and task field semantic transformation are performed based on fixed mapping rules. Then, relational configuration management is performed according to preset association rules. This achieves preset association rules that conform to natural business logic, limiting the scheduling strategy reference relationship based on natural business keys. Furthermore, the scheduling strategy reference relationships indicate associated tasks, associated list definitions, associated list items, and associated preset expressions. This means that the processed data, after being entered into the database, is organized and arranged in the relational database with reference to the scheduling strategy reference relationships. Therefore, it can be edited and organized according to the natural business logic, that is, associated tasks plus associated list definitions plus associated list items plus associated preset expressions. By converting the raw data of the power trading scheduling documents of multiple regions and writing them into a relational database with seven types of relational entities, the format and arrangement of the data keys in the relational database conform to the business habits of power trading and are adapted to the power trading scheduling business scenario.Furthermore, because it is based on fixed mapping rules, the original data of the power trading scheduling documents for each of the multiple regions undergoes top-level field splitting and task field semantic transformation. This helps to meet the requirements of data standardization and consistency in the database. In particular, for the extraction and parsing of key information carried by top-level fields and key fields, it can achieve overall rule uniformity and stable columnar storage, thus improving data quality and database operating efficiency. In addition, unlike uniformly converting power trading scheduling documents from various regions into a single standardized document structure, this only involves top-level field splitting and task field semantic transformation. Therefore, it only performs targeted mapping from fields to tables. Overall, the original data of the power trading scheduling documents is split into seven types of relational entities, using natural keys as the association basis to form reusable scheduling strategy reference relationships. This involves associated tasks, association list definitions, association list items, and pre-defined association expressions. This means that the unique characteristics of each region are preserved, such as different power trading market access and disclosure rules and personalized implementation details. Furthermore, it allows for domain-specific splitting and retains the foreign key structure required for subsequent semantic verification and registration linkage.

[0029] Continue reading Figure 1 An exemplary top-level field splitting rule is shown in Table 1 below: Table 1

[0030] Continue reading Figure 1 An exemplary task field semantic transformation rule may include, for example, runtime read region preset, array splitting, enumeration of account range semantics, comma separation, Boolean column, and restoration during assembly after comma separation.

[0031] Continue reading Figure 1After the raw data of power transaction scheduling documents from multiple regions are stored in the database, when faced with data requests from external applications, such as when the data processing engine starts or refreshes, a relational database is used for table partitioning and joins. This transforms seven types of relational entities into runtime objects that conform to the field semantic specifications of the data request. Specifically, the fields associated with the data request are read from the relational database, and based on the standardized structure document associated with the data request, the read fields associated with the data request are joined and assembled to generate output data that conforms to the semantic specifications and disclosure requirements of the standardized structure document associated with the data request. Considering that external applications may have different standard structured document specifications, such as referencing the data format of external databases, and meeting the document collaboration and operation and maintenance requirements of external programs, if the data is directly transferred from the original data provider to the specific application requester, problems such as requirement mismatch and requirement drift will arise. For example, changes in policies or disclosure windows may lead to inconsistencies between the data format of the original data provider and the external documents provided by the specific application requester. This document provides a closed-loop management system encompassing power trading and dispatch data collection, relational configuration management, and application adaptation. It processes raw data and writes it into a relational database with seven types of relational entities. Furthermore, it performs joins on fields read from this relational database, decoupling the relationship between the raw data provider and the specific application requester through business isolation. Because a relational database tailored to the power trading and dispatch business scenario serves as the intermediary, the raw data provider does not need to consider the adaptation requirements of specific applications, and the specific application requester does not need to be aware of changes in policies or disclosure windows related to power trading and dispatch data collection. This allows the raw data provider to manage and maintain the raw data of power trading and dispatch documents according to their respective regional characteristics, and also allows the specific application requester to read and organize fields in the relational database according to the semantic and structural requirements of external applications, thus supporting the collection of power trading and dispatch data and backend applications. In addition, there are regional differences and regional characteristics. For example, each region may follow different formats and semantic specifications when creating and managing its own power trading scheduling documents. They may also adopt different power trading market access and disclosure rules and personalized implementation details. These can be reflected in the seven types of relational entities through preset association rules, such as task-level exclusion rules and date offset preset rules.

[0032] In short, Figure 1The power trading and dispatching data management method described herein establishes a complete processing procedure. After configuration changes, global constraints, regional constraints, and dispatching strategy semantic verification are first performed. Upon successful verification, the data is persistently written to a relational database. Subsequently, runtime configuration is assembled and periodic task registration is triggered. This approach is adaptable to power trading markets characterized by multiple regions, numerous accounts, and large-scale scheduled dispatching. It provides a closed-loop management system from power trading and dispatching data collection to relational configuration management and application adaptation. By decoupling the relationship between the original data provider and specific application requirements through business isolation, it improves the efficiency of power trading and dispatching data collection, storage, and management while preserving the unique characteristics of each region. It can also meet the data requests of various external applications.

[0033] See Figure 1 In one possible implementation, the business semantic specifications of the multiple regions each adopt a tree-nested structure. Configuration items in the tree-nested structure are located based on the hierarchical path of the configuration item. The seven types of relational entities in the scheduling strategy reference relationship each have a corresponding business natural key and can be independently located and edited based on the business natural key. Furthermore, the seven types of relational entities include a region registration relational entity, a region account relational entity, a date range preset relational entity, a timed expression preset relational entity, a timed list definition relational entity, a timed list entry relational entity, and a task scheduling entry relational entity. The data in the relational database is configured to be arranged according to business natural key items and can be edited according to business natural key items. Each of the seven types of relational entities has a corresponding primary key or composite primary key. The composite primary key of the task scheduling entry relational entity includes a region name key item corresponding to the region registration relational entity, a task name key item corresponding to the task scheduling entry relational entity, a list reference key item corresponding to the timed list definition relational entity, and a task category.

[0034] Therefore, the formats, semantic specifications, and structured document formats used in power trading and dispatching documents across different regions may not allow for direct, individual editing based on natural business keys. For example, the common JSON structured document format employs a nested tree structure, nesting grouping, categories, timing fields (CRON), preset lists, and preset date ranges into a specific data structure. This makes it impossible to directly process the data according to natural business logic after parsing, splitting, and storing it in the database. For instance, in the power trading market, given the characteristics of multiple regions, numerous accounts, and large-scale scheduled dispatching, the natural business processing logic is to use region plus task name plus list reference. Therefore, before the original data is stored in the database (including initial data storage and data migration), top-level field splitting and task field semantic transformation are performed based on fixed mapping rules. Then, relational configuration management is performed according to preset association rules. This achieves preset association rules that conform to natural business logic, thus limiting the dispatching strategy reference relationship based on natural business keys. Furthermore, the scheduling strategy reference relationships indicate associated tasks, associated list definitions, associated list items, and associated preset expressions. This means that the processed data, after being entered into the database, is organized and arranged in the relational database with reference to the scheduling strategy reference relationships. Therefore, it can be edited and organized according to the natural business logic, that is, associated tasks plus associated list definitions plus associated list items plus associated preset expressions. By converting the raw data of the power trading scheduling documents of multiple regions and writing them into a relational database with seven types of relational entities, the format and arrangement of the data keys in the relational database conform to the business habits of power trading and are adapted to the power trading scheduling business scenario.

[0035] In some examples, the account task constraints of the multiple regions include power trading market access and disclosure rules, which are not compatible with the semantic specifications and disclosure requirements of the standardized structured documents associated with the data request. Thus, given the characteristics of the power trading market—namely, the mandatory power trading market access and disclosure rules—and the fact that the semantic specifications and disclosure requirements of the original standardized structured documents may no longer meet the latest policies and disclosure rules as policies and disclosure rules change, a direct flow from the original data provider to the specific application requester faces problems such as requirement mismatch and requirement drift. For example, changes in policies or disclosure windows may lead to inconsistencies between the data format of the original data provider and the external documents provided by the specific application requester. Therefore, a closed-loop management system is provided, encompassing the collection of power trading scheduling data, relational configuration management, and application adaptation. This system processes the original data and writes it into a relational database with seven types of relational entities. Furthermore, it performs table joins on the fields read from the relational database. This decouples the relationship between the original data provider and the specific application requester through business isolation. Because a relational database tailored to the characteristics of power trading and dispatching business scenarios is used as an intermediary, the original data provider does not need to consider the adaptability requirements of specific applications, and the specific application requesters do not need to be aware of changes in policies or disclosure windows regarding power trading and dispatching data collection. This is beneficial for the original data provider to manage and maintain the original data of power trading and dispatching documents according to their respective regional characteristics, and also for the specific application requesters to read and organize the fields in the relational database according to the semantic and structural requirements of external applications, thus supporting the collection of power trading and dispatching data and backend applications.

[0036] Continue reading Figure 1 The seven types of relational entities include regional registration relational entities, regional account relational entities, date range preset relational entities, timed expression preset relational entities, timed list definition relational entities, timed list entry relational entities, and task scheduling entry relational entities. These seven types of relational entities are determined based on the power trading and scheduling business scenario, and therefore conform to the characteristics of the power trading market. As described above, by processing the raw data and writing it into a relational database with these seven types of relational entities, and by performing table joins on the fields read from the relational database, the relationship between the raw data provider and the specific application requirement is decoupled through business isolation, and this helps to adapt to the power trading market's unique access and disclosure rules. The seven types of relational entities can be referenced in Table 2 below: Table 2

[0037] Continue reading Figure 1 The data in the relational database is configured to be arranged and editable according to business natural keys. Each of the seven types of relational entities has a corresponding primary key or composite primary key. The composite primary key of the task scheduling entry relational entity includes the region name key corresponding to the region registration relational entity, the task name key corresponding to the task scheduling entry relational entity, the list reference key corresponding to the timed list definition relational entity, and the task category. It should be understood that the seven types of relational entities each have their own primary key or composite primary key, and do not share a single unified primary key. Specifically, the task scheduling entry entity uses the region name key, task category, task name key, and list reference key to form a composite primary key; the list reference key is also used to reference the timed list definition entity in the same region. Furthermore, compared to the composite primary key of the task scheduling entry entity, other entities do not need to list primary keys individually, but should retain the unique identifier of each entity through the corresponding business natural key, as well as the technical relationship between entities established according to region and reference key. In this way, a single modification can make multiple tasks in the list take effect simultaneously, improving the management and processing efficiency of the relational database. By setting a unique primary key data format for tasks, table lookup efficiency is improved.

[0038] See Figure 1In one possible implementation, the regional personalization rules for each of the multiple regions include a default date offset range and a date difference equivalence rule. The fixed mapping rule is used to convert the default date offset range and write it into a preset date range relational entity. When performing task field semantic conversion or date range verification, the date range is normalized or judged for equivalence according to the corresponding region's date difference equivalence rule. Furthermore, the regional personalization rules for each of the multiple regions also include a date splitting method. The fixed mapping rule indicates that when performing task field semantic conversion, the region's preset date configuration is read. Thus, the power trading market is characterized by multiple regions, a large number of accounts, and large-scale timed scheduling. Each region may follow different formats, semantic specifications, and may adopt different power trading market access and disclosure rules, as well as personalized implementation details, in creating and managing its own power trading scheduling documents. For example, some regions may stipulate that a delay of up to four days from the target date is considered timely scheduling, while others may stipulate that a delay of one day or earlier is considered timely scheduling. For another example, some regions use timed field equivalence rules indicating that 4 AM, 5 AM, and 6 AM are equivalent. For example, different regions may use different date splitting methods. Because it is based on fixed mapping rules, the original data of the power transaction scheduling documents of the multiple regions are split into top-level fields and semantically transformed for task fields. This helps to meet the requirements of standardization and consistency between data in the database. In particular, for the extraction and parsing of key information carried by top-level fields and key fields, it can achieve the uniformity of the overall rules and the storage of data in a stable columnar format, thereby improving the data quality and database operating efficiency.

[0039] See Figure 1In one possible implementation, the global constraint verification includes ensuring that the entity record to be written conforms to account range enumeration requirements, date range type requirements, list reference integrity requirements, task activation binding requirements, and the requirement that new accounts do not participate in public task scheduling by default. Furthermore, the regional personalization constraint verification includes performing regional personalization constraint verification based on the regional name key items included in the primary key, to ensure that the entity record to be written conforms to the account task constraint relationships and regional personalization rules of each of the multiple regions. Thus, during data writing and migration, the constraints ensure that the assembled output conforms to the global constraint requirements, contributing to structural equivalence and allowing downstream applications, such as periodic registration and queuing modules, to be unaware of rule version changes. Specifically, taking the global constraints on cross-province unified enumeration and semantics as an example, the account range enumeration requirement can set default first range, second range, and specified range, etc.; the date range type requirement can set the reference area preset and task-level offset; the list reference integrity requirement can set the preset timed field to be prohibited from being deleted when referenced, thus avoiding reference errors; the task activation binding requirement can be set to prevent the timed field from being deleted after binding; and the requirement that new accounts do not participate in the public task timed scheduling by default can be set to prevent newly created accounts from participating in the public task timed scheduling by default, thus helping to meet the requirements of large-scale scheduling. In addition, during data writing and data migration, the dual constraint effect ensures that the assembled output meets both the global constraint requirements and the regional personalized constraint requirements. Specifically, taking cross-provincial unified enumeration and semantics as an example, according to the basic principle of regional isolation, regional personalized constraints can be set as follows: (1) Date offset preset: the same key name can have different start and end dates in different regions, thus reflecting the differences in disclosure windows of each province; (2) Regional account table extended column: the exclusion expression is used to indicate that the account does not participate in a certain type of data task, and the new account expression is used to indicate that only manual supplementation is required; (3) Task-level exclusion: the specified account is removed from the task dispatch account pool; (4) Province comparison rules (drift verification): for example, the timing field of one province is equivalent to 4:00 / 6:00 and 5:00, the timing field of another province is combined with the date range for joint judgment, and the real-time / daily report line comparison is used in another province. Here, the regional equivalence rules can be configured in the comparison script of each province, rather than being fixed in the standardized document.

[0040] See Figure 1In one possible implementation, the scheduling strategy semantic consistency verification includes ensuring that the entity record to be written satisfies referential integrity, account validity, and date consistency. The referential integrity verification includes: when the entity record to be written is a task scheduling entry entity record, verifying the existence of the corresponding timed list definition entity and its corresponding region name key based on the list reference key of the task scheduling entry entity record; and verifying the existence of the timed expression preset entity referenced by the timed list entry entity belonging to the timed list definition entity and its corresponding region name key. Thus, to improve data quality and standardization, scheduling strategy semantic consistency verification is performed before persistence. This differs from syntax verification in standardized structure documents and, considering the characteristics of the power trading market, can specifically identify situations that may lead to errors in subsequent power trading scheduling data collection and tasks. An exemplary scheduling strategy semantic consistency verification rule can be found in Table 3 below: Table 3

[0041] See Figure 1In one possible implementation, the standardized structured document associated with the data request is adapted to various application outputs, including applications based on JSON documents. Thus, it supports equivalent structured documents such as JSON or Nacos. Considering that external applications may have different standard structured document specifications, such as referencing external database data formats, and meeting the document collaboration and operation and maintenance needs of external programs, directly from the original data provider to the specific application requester faces problems such as requirement mismatch and requirement drift. For example, changes in policies or disclosure windows may lead to inconsistencies between the data format of the original data provider and the external documents provided by the specific application requester. Here, a closed-loop management system is provided, from the collection of power trading and dispatch data to relational configuration management and application adaptation. This is achieved by processing the original data and writing it into a relational database with seven types of relational entities, and by performing table joins on the fields read from the relational database. This decouples the relationship between the original data provider and the specific application requester through business isolation. Because a relational database tailored to the characteristics of power trading and dispatching business scenarios is used as an intermediary, the original data provider does not need to consider the adaptability requirements of specific applications, and the specific application requesters do not need to be aware of changes in policies or disclosure windows regarding power trading and dispatching data collection. This is beneficial for the original data provider to manage and maintain the original data of power trading and dispatching documents according to their respective regional characteristics, and also for the specific application requesters to read and organize the fields in the relational database according to the semantic and structural requirements of external applications, thus supporting the collection of power trading and dispatching data and backend applications.

[0042] See Figure 1In one possible implementation, the management method further includes: performing a configuration drift check on the actual scheduling configuration of the external application and the standard configuration assembled from the relational database. This includes performing regional normalization on task names and comparing the timing expressions and date ranges corresponding to the normalized tasks to obtain missing items, redundant items, and configuration inconsistencies, thereby outputting a discrepancy list. The discrepancy list is used to identify the drift of the actual scheduling configuration relative to the standard configuration. The actual processing chain for configuration drift check is as follows: comparing the actual scheduling configuration of the external application with the standard configuration assembled from the relational database, outputting a list of missing items, redundant items, and configuration inconsistencies; and having maintenance personnel correct the hub configuration in the relational database based on the discrepancy list, then reassembling the runtime configuration and triggering periodic task registration. Thus, to address the potential drift issue between relational databases and the scheduling multidimensional tables / collaborative documents of specific applications, a province-specific comparison process (non-real-time blocking write) is provided at the operations and maintenance layer: (1) Export the application's scheduling records (task name, runtime segment, data range, etc.); (2) Read the database assembly results or snapshots; (3) Normalize the task names according to province rules (remove path prefixes, unify brackets, map aliases); (4) Perform a strict two-dimensional comparison between the timing field and the date range (prohibit judging overall consistency based solely on the consistency of the timing field); (5) Output a list of missing, redundant, and inconsistent data for operations and maintenance to perform registration linkage after correcting the relational database. In this way, by verifying the drift of row configurations, the personalized governance of "one demand table per province, one configuration database per province" in power transactions is reflected.

[0043] See Figure 1 In one possible implementation, the management method further includes: configuration management and visual control, including providing a fine-grained configuration management interface for adding, deleting, and modifying task fields, preset timer fields, timer field lists, or regional accounts; and for transactional storage, triggering reference protection when deleting a referenced preset record; and for write operations carrying an operator identifier for auditing. Thus, the deletion operation targets a preset record or preset entity for a timer expression; if the preset is still referenced by the timer list, the system refuses to delete it and returns a corresponding error, rather than deleting the preset table in the database.

[0044] See Figure 1In one possible implementation, the management method further includes linking configuration persistence with runtime registration, including: after the configuration is verified and persistently saved, in response to a registration trigger command, reading the assembled runtime configuration, registering periodic tasks in batches and idempotently based on preset task identifiers, and not changing existing periodic tasks in the message queue before registration is triggered. Furthermore, the specific mechanism for "idempotently registering or updating periodic tasks" is determined by whether it avoids duplicate registrations using the same task identifier, clears old registrations before re-establishing them, or updates the corresponding periodic task registration information through difference verification. This allows for limitation based on the actual mechanism used, avoiding the generalization of batch re-registration as automatic incremental updates.

[0045] Figure 2 This is a schematic diagram illustrating a structured scheduling configuration entity relationship provided in an embodiment of this application. For example... Figure 2 As shown, under the Region Configuration (Region Comparison), there are Region-Account, Preset Date Range (Region, Preset Key-Value), Preset Scheduled Fields (Region, Preset Key-Value), Preset Scheduled Fields List (Region, List Key-Value), and Scheduled Fields List Items (List Key-Value to Preset Key-Value). Finally, the execution task comparison shows: Region, Category, Name, Scheduled Fields List Key-Value. This demonstrates the primary and foreign key reference relationships between Region, Account, Scheduled Presets, Scheduled List, and Task Items.

[0046] Figure 3 This is a schematic diagram illustrating a method for parsing, splitting, storing, and configuring assembly provided in an embodiment of this application. For example... Figure 3 As shown, the method for parsing, splitting, storing, and assembling configurations includes the following steps.

[0047] Step S310: Receive the individual configuration file of the receiving area.

[0048] Step S320: Parse and split to obtain the account, preset date range, preset time field, preset time field list, and group (category).

[0049] Step S330: Write the seven types of relational entities, using the format of business natural keys plus foreign keys in the application chain.

[0050] Step S340: Join table assembly, outputting a configuration that is semantically equivalent to a standard structured document such as JSON.

[0051] Step S350: The consumer can register and enqueue periodic tasks without any changes.

[0052] This demonstrates the entire process from the monolithic configuration file, to the field splitting and writing into seven types of relational entities, to the assembly of joined tables into equivalent objects, and finally the periodic registration and queuing.

[0053] Figure 4 This is a schematic diagram illustrating a global and regional dual-layer constraint and visual control mapping provided for an embodiment of this application. For example... Figure 4 As shown, global constraint 410 includes requirements for account range enumeration, date range type, list reference integrity, task activation and binding, and the requirement that new accounts are excluded from public task scheduling by default. Regional personalized constraint 420 includes preset date offsets, extended columns in the regional account table, task-level exclusion, and province comparison rules. Scheduling management 430 includes tasks, preset scheduling fields, a list of scheduling fields, resettable regional accounts, and a configurable management interface (persistent after semantic validation). This demonstrates the relationship between global enumeration constraints, regional personalized columns, equivalent rules, and the corresponding control and configuration management interfaces.

[0054] Figure 5 This is a schematic diagram illustrating the linkage between configuration modification, registration, verification, and drift checking, as provided in an embodiment of this application. Figure 5 As shown, the process of modifying the configuration, registering, verifying, and checking for drift can be divided into the following steps.

[0055] Step S510: Save changes on the control page.

[0056] Step S520: Semantic validation and database persistence.

[0057] Step S530: Register repetitive tasks in batches by category at the operation entry point.

[0058] Step S540: Queue and scheduling health checks take effect.

[0059] Finally, daily changes are made through the main path 560, or the drift check is performed through the branch path 570 for export, two-dimensional comparison (timed field plus date range), and registration is triggered after correction.

[0060] Thus, this demonstrates the process from saving verification to registering periodic tasks and then to health verification, and performs the application plus database drift comparison branch in parallel.

[0061] Figure 6 This is a schematic diagram of a power trading and dispatching data management system provided in an embodiment of this application. Figure 6 As shown, the management system 600 includes the following components and their respective configurations.

[0062] receiver layer (not in) Figure 6 As shown in the figure, it is configured to receive raw data from power trading scheduling documents for multiple regions. The parsing, splitting, and data entry conversion layer 610 is configured to: based on fixed mapping rules, perform top-level field splitting and task field semantic conversion on the original data of the power transaction scheduling documents of the multiple regions, thereby generating entity records to be written. The power transaction scheduling documents of the multiple regions respectively conform to the business semantic specifications, account task constraint relationships, and regional personalized rules of the multiple regions.

[0063] The global constraint and regional personalized constraint layer 620 is configured to perform global constraint verification and regional personalized constraint verification on the entity record to be written.

[0064] The semantic verification layer 630 is configured to perform scheduling strategy semantic consistency verification on the entity record to be written.

[0065] The layered storage layer 640 is configured to: after verification, persist the data to a relational database according to preset association rules. The relational database is configured with seven types of relational entities. The preset association rules define the scheduling strategy reference relationship based on business natural keys. The scheduling strategy reference relationship indicates the associated task, the association list definition, the association list item, and the association preset expression. The seven types of relational entities are determined based on the power trading and scheduling business scenario.

[0066] The configuration assembly layer 650 is configured to: respond to a data request from an external application, read the fields associated with the data request from the relational database, and, based on the data request or target output format of the external application, invoke the corresponding data assembly rules to perform join assembly on the read fields associated with the data request, thereby generating output data that conforms to the semantic specifications and disclosure requirements of the standardized structure document associated with the data request. The output data includes runtime configuration and documented results for operation and maintenance collaboration. The configuration management interface of the relational database is used to read or modify the corresponding configuration data.

[0067] Figure 6The management system shown establishes a complete set of processing procedures. After a configuration change, it first performs semantic verification of global constraints, regional constraints, and scheduling strategies; after successful verification, the data is persistently written to a relational database; subsequently, the runtime configuration is assembled and periodic task registration is triggered. In this way, it can adapt to the power trading market, which has multiple regions, a large number of accounts, and large-scale scheduled scheduling. It provides a closed-loop management system from power trading scheduling data collection to relational configuration management and application adaptation. By decoupling the relationship between the original data provider and the specific application demanders through business isolation, it improves the efficiency of power trading scheduling data collection, storage, and management while preserving the personalized characteristics of each region, and can also meet the data requests of various external applications.

[0068] Figure 7 This is a schematic diagram of an electronic device 700 provided in an embodiment of this application. The electronic device 700 includes one or more processors 710, a communication interface 720, and a memory 730. The processors 710, communication interface 720, and memory 730 are interconnected via a bus 740. Optionally, the electronic device 700 may further include an input / output interface 750, which is connected to an input / output device for receiving user-set parameters, etc. The electronic device 700 can be used to implement some or all of the functions of the device embodiment or system embodiment described above in this application; the processor 710 can also be used to implement some or all of the operation steps of the method embodiment described above in this application. For example, the specific implementation of various operations performed by the electronic device 700 can be referred to the specific details in the above embodiments, such as the processor 710 being used to execute some or all of the steps or operations in the above method embodiments. For example, in the embodiments of this application, the electronic device 700 can be used to implement some or all of the functions of one or more components in the above-described device embodiments. In addition, the communication interface 720 can be used specifically for communication functions necessary to implement the functions of these devices and components, and the processor 710 can be used specifically for processing functions necessary to implement the functions of these devices and components.

[0069] It should be understood that, Figure 7 The electronic device 700 may include one or more processors 710, and the multiple processors 710 may collaboratively provide processing capabilities in a parallel connection manner, a serial connection manner, a serial-parallel connection manner, or an arbitrary connection manner; or the multiple processors 710 may form a processor sequence or a processor array; or the multiple processors 710 may be divided into a main processor and an auxiliary processor; or the multiple processors 710 may have different architectures, such as adopting a heterogeneous computing architecture. Furthermore, Figure 7The structural and functional descriptions of the electronic device 700 shown are exemplary and non-limiting. In some exemplary embodiments, the electronic device 700 may include... Figure 7 The diagram shows more or fewer components, or combinations of some components, or splitting of some components, or different arrangements of components.

[0070] The processor 710 can have various specific implementations. For example, it may include one or more combinations of a central processing unit (CPU), a graphics processing unit (GPU), a neural network processing unit (NPU), a tensor processing unit (TPU), or a data processing unit (DPU). This application does not impose specific limitations on these embodiments. The processor 710 can also be a single-core or multi-core processor. The processor 710 can be a combination of a CPU and hardware chips. These hardware chips can be application-specific integrated circuits (ASICs), programmable logic devices (PLDs), or combinations thereof. The PLDs can be complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), generic array logic (GALs), or any combination thereof. The processor 710 can also be implemented using logic devices with built-in processing logic, such as FPGAs or digital signal processors (DSPs). The communication interface 720 can be a wired interface or a wireless interface, used to communicate with other modules or devices. The wired interface can be an Ethernet interface, a local interconnect network (LIN), etc., and the wireless interface can be a cellular network interface or a wireless LAN interface, etc.

[0071] Memory 730 may be non-volatile memory, such as read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Memory 730 may also be volatile memory, which may be random access memory (RAM) used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM). The memory 730 can also be used to store program code and data, so that the processor 710 can call the program code stored in the memory 730 to execute some or all of the operation steps in the above method embodiments, or to execute the corresponding functions in the above device embodiments. Furthermore, the electronic device 700 may include, compared to... Figure 7 The number of components displayed may be more or less, or there may be different component configurations.

[0072] The 740 bus can be a Peripheral Component Interconnect Express (PCIe) bus, or an Extended Industry Standard Architecture (EISA) bus, a Unified Bus (Ubus or UB), a Compute Express Link (CXL) bus, a Cache Coherent Interconnect for Accelerators (CCIX) bus, etc. The 740 bus can be divided into an address bus, a data bus, and a control bus. In addition to the data bus, the 740 bus can also include a power bus, a control bus, and a status signal bus. However, for clarity, Figure 7 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0073] The methods and devices provided in this application are based on the same inventive concept. Since the principles by which the methods and devices solve problems are similar, the embodiments, implementation methods, examples, or methods of implementation of the methods and devices can be referred to each other, and repeated details will not be repeated. This application also provides a system comprising multiple electronic devices, the structure of which can refer to the structure of the electronic devices described above. The functions or operations achievable by this system can refer to the specific implementation steps in the above method embodiments and / or the specific functions described in the above device embodiments, and will not be repeated here.

[0074] This application also provides a computer-readable storage medium storing computer instructions. When these computer instructions are executed on an electronic device (such as one or more processors), they can implement the method steps described in the above method embodiments. The specific implementation of the above method steps by the processor of the computer-readable storage medium can refer to the specific operations described in the above method embodiments and / or the specific functions described in the above device embodiments, and will not be repeated here.

[0075] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. This application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Embodiments of this application can be implemented wholly or partially by software, hardware, firmware, or any other combination. When implemented in software, the above embodiments can be implemented wholly or partially as a computer program product. This application can take the form of a computer program product embodied on one or more computer-usable storage media containing computer-usable program code. The computer program product includes one or more computer instructions. When the computer program instructions are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless network communication, microwave, etc.) means. Computer-readable storage media can be any available medium that a computer can access, or a data storage device such as a server or data center that contains one or more sets of available media. Available media can be magnetic media (such as floppy disks, hard disks, and magnetic tapes), optical media, or semiconductor media. Semiconductor media can be solid-state drives, random access memory, flash memory, read-only memory, erasable programmable read-only memory, electrically erasable programmable read-only memory, registers, or any other suitable form of storage medium.

[0076] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. Each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0077] In the above embodiments, the descriptions of each embodiment have their own emphasis. Parts not described in detail in a certain embodiment can be referred to in the relevant descriptions of other embodiments. Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of the embodiments of this application. The steps in the methods of the embodiments of this application can be adjusted in order, combined, or deleted according to actual needs; the modules in the systems of the embodiments of this application can be divided, combined, or deleted according to actual needs. If these modifications and variations of the embodiments of this application fall within the scope of the claims of this application and their equivalents, then this application also intends to include these modifications and variations.

Claims

1. A method for managing power trading and dispatch data, characterized in that, The management method includes: Receive raw data from power trading and scheduling documents of multiple regions, wherein the power trading and scheduling documents of each of the multiple regions respectively conform to the business semantic specifications, account task constraints and regional personalized rules of the multiple regions; Based on fixed mapping rules, the original data of the power transaction scheduling documents of the multiple regions are split into top-level fields and semantically transformed into task fields to generate entity records to be written. The entity records to be written are subjected to global constraint verification, regional personalized constraint verification, and scheduling strategy semantic consistency verification. Then, after the verification passes, they are persistently written to the relational database according to the preset association rules. The relational database is configured with seven types of relational entities. The preset association rules limit the scheduling strategy reference relationship based on the business natural key item. The scheduling strategy reference relationship indicates the associated task, the association list definition, the association list item, and the association preset expression. The seven types of relational entities are determined based on the power trading scheduling business scenario. In response to a data request from an external application, the system reads the fields associated with the data request from the relational database. Based on the data request or target output format of the external application, the system invokes the corresponding data assembly rules to perform table joins on the read fields associated with the data request, thereby generating output data that conforms to the semantic specifications and disclosure requirements of the standardized structure document associated with the data request. The output data includes runtime configuration and documented results for operation and maintenance collaboration. The configuration management interface of the relational database is used to read or modify the corresponding configuration data.

2. The management method according to claim 1, characterized in that, The business semantic specifications of each of the multiple regions adopt a tree-like nested structure. Configuration items in this tree-like nested structure are located based on their hierarchical path. The seven types of relational entities in the scheduling strategy reference relationship each have a corresponding business natural key and can be independently located and edited based on that business natural key. These seven types of relational entities include region registration relational entities, region account relational entities, date range preset relational entities, timed expression preset relational entities, timed list definition relational entities, timed list entry relational entities, and task scheduling entry relational entities. Furthermore, the data in the relational database is configured to be arranged according to business natural key items and can be edited according to these business natural key items. Each of the seven types of relational entities has a corresponding primary key or composite primary key. The composite primary key of the task scheduling entry relational entity includes a region name key item corresponding to the region registration relational entity, a task name key item corresponding to the task scheduling entry relational entity, a list reference key item corresponding to the timed list definition relational entity, and a task category.

3. The management method according to claim 1, characterized in that, The regional personalization rules for each of the multiple regions include a default date offset range and a date difference equivalence rule. The fixed mapping rule is used to convert the default date offset range and write it into a date range preset relational entity. When performing task field semantic conversion or date range verification, the date range is normalized or equivalence is judged according to the date difference equivalence rule of the corresponding region. In addition, the regional personalization rules for each of the multiple regions also include a date splitting method. The fixed mapping rule indicates that when performing task field semantic conversion, the regional date preset configuration is read.

4. The management method according to claim 1, characterized in that, The global constraint verification includes ensuring that the entity record to be written meets the requirements of account range enumeration, date range type, list reference integrity, task activation binding, and the requirement that new accounts do not participate in public task timed scheduling by default. In addition, the regional personalization constraint verification includes performing regional personalization constraint verification according to the regional name key items included in the primary key, so as to ensure that the entity record to be written meets the account task constraint relationship and regional personalization rules of the multiple regions.

5. The management method according to claim 1, characterized in that, The semantic consistency verification of the scheduling strategy includes ensuring that the entity record to be written satisfies referential integrity, account validity, and date consistency. The referential integrity verification includes: when the entity record to be written is a task scheduling entry entity record, verifying whether the corresponding timed list definition entity exists and has the same region name key as the task scheduling entry entity record based on the list reference key of the task scheduling entry entity record; and verifying whether the timed expression preset entity referenced by the timed list entry entity belonging to the timed list definition entity exists and has the same region name key.

6. The management method according to claim 1, characterized in that, The standardized structured document associated with the data request is adapted to various application outputs, including applications based on JSON documents.

7. The management method according to claim 1, characterized in that, The management method also includes: The actual scheduling configuration of the external application is compared with the standard configuration assembled from the relational database to check for configuration drift. This includes performing regional normalization on the task names and comparing the timing expressions and date ranges corresponding to the normalized tasks to obtain missing items, redundant items, and configuration inconsistencies, thereby outputting a discrepancy list. The discrepancy list is used to identify the drift of the actual scheduling configuration relative to the standard configuration.

8. The management method according to claim 1, characterized in that, The management method also includes: Configuration management and visual control are implemented, including providing a fine-grained configuration management interface for adding, deleting, and modifying task fields, preset timed fields, timed field lists, or regional accounts. It also enables transactional saving, triggering reference protection when deleting a referenced preset record, and carrying an operator identifier for auditing during write operations.

9. The management method according to claim 1, characterized in that, The management method also includes configuration persistence and runtime registration linkage, including: after the configuration is verified and persistently saved, in response to the registration trigger command, reading the assembled runtime configuration, registering periodic tasks in batches and idempotently based on preset task identifiers, and not changing the existing periodic tasks in the message queue before the registration is triggered.

10. A management system for power trading and dispatch data, characterized in that, The management system includes: The receiving layer is configured to receive raw data from power trading and scheduling documents for multiple regions. The parsing, splitting, and database conversion layer is configured to: based on fixed mapping rules, perform top-level field splitting and task field semantic transformation on the original data of the power transaction scheduling documents of the multiple regions, thereby generating entity records to be written. The power transaction scheduling documents of the multiple regions respectively conform to the business semantic specifications, account task constraint relationships, and regional personalized rules of the multiple regions. The global constraint and regional personalized constraint layer is configured to perform global constraint verification and regional personalized constraint verification on the entity record to be written. A semantic verification layer is configured to perform scheduling strategy semantic consistency verification on the entity record to be written. The storage layer is configured to: after verification, persist the data to a relational database according to preset association rules. The relational database is configured with seven types of relational entities. The preset association rules define the scheduling strategy reference relationship based on the business natural key item. The scheduling strategy reference relationship indicates the associated task, the association list definition, the association list item, and the association preset expression. The seven types of relational entities are determined based on the power trading scheduling business scenario. The configuration assembly layer is configured to: respond to data requests from external applications, read fields associated with the data request from the relational database, and, based on the data request or target output format of the external application, invoke corresponding data assembly rules to perform join assembly on the read fields associated with the data request, thereby generating output data that conforms to the semantic specifications and disclosure requirements of the standardized structure document associated with the data request. The output data includes runtime configuration and documented results for operation and maintenance collaboration. The configuration management interface of the relational database is used to read or modify the corresponding configuration data.

11. An electronic device, characterized in that, The electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the management method according to any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed on an electronic device, cause the electronic device to perform the management method according to any one of claims 1 to 9.

Images