A business logic driven database change awareness and documentation synchronization method

Abstract

The application provides a business logic driving-oriented database change awareness and documentation synchronization method, relates to the technical field of database management, and comprises the following steps: based on Binlog technology, full-amount data changes of a hearing aid core business entity are listened to and captured in real time, and the changed full-amount data is recorded as a corresponding standard change message; a business logic mapping algorithm is formulated, standard change messages are subjected to rule matching, and a corresponding business event type is obtained; a cross-table context is constructed, event chain attribution judgment is performed on the corresponding business event type, and a corresponding hearing aid core business entity is obtained; an event derivation engine is constructed, business logic derivation is performed on the hearing aid core business entity, and then a business semantic structure event document is generated; and based on message queue technology, data synchronization processing is performed on the business semantic structure event document, data synchronization of a hearing aid multi-terminal system is realized, and the intelligent degree and operation efficiency of the system are improved.

Description

Technical Field

[0001] This invention relates to the field of database management technology, specifically a database change awareness and documentation synchronization method driven by business logic. Background Technology

[0002] In the digital operation of the hearing aid industry, core business data is distributed across multiple systems and needs to be synchronized in real time. Existing database change detection methods are mostly general data capture techniques, lacking targeted processing that incorporates the professional business semantics of the hearing aid industry. This makes it difficult to transform raw database changes into event types that conform to industry business logic. Furthermore, current technologies for analyzing the relationships between core business entities in the hearing aid industry only reach the level of simple table relationships, failing to achieve chain-like attribution judgments of core business entities based on industry business logic. Consequently, the business logic behind data changes cannot be effectively uncovered.

[0003] Traditional multi-terminal data synchronization methods are mostly coupled direct transmissions. The synchronization process lacks a reliable message management mechanism, which easily leads to problems such as data synchronization delays, loss, or inconsistencies. Furthermore, after data changes, standardized business semantic documents cannot be generated, making it difficult to achieve traceability of business events. This not only reduces the operating efficiency of hearing aid multi-terminal systems but also fails to meet the professional and intelligent needs of the hearing aid industry for business data processing, thus hindering the development of digital operations in the industry.

[0004] Therefore, a database change awareness and documentation synchronization method driven by business logic is provided. Summary of the Invention

[0005] To address the aforementioned technical problems, the present invention aims to provide a database change awareness and documentation synchronization method driven by business logic.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a database change awareness and documentation synchronization method driven by business logic, the method comprising: Based on Binlog technology, it monitors and captures all data changes of core business entities in the hearing aid industry in real time, and records all the changed data as the corresponding standard change message. Develop a business logic mapping algorithm; perform rule matching on standard change messages according to the business logic mapping algorithm to obtain the corresponding business event types; Construct a cross-table context model; based on the cross-table context model, perform event chain attribution judgment on the corresponding business event types to obtain the core business entities of the hearing aid industry scenario with related relationships; Construct an event inference engine; based on the event inference engine, perform business logic inference on the core business entities of the corresponding hearing aid industry scenario, and then generate the corresponding business semantic structure event document; Data synchronization of the business semantic structure event documents is performed based on message queue technology, thereby realizing data synchronization of hearing aid multi-terminal systems and improving the system's intelligence and operating efficiency.

[0007] Furthermore, based on Binlog technology, changes in the core business entities of the hearing aid industry scenario are captured and corresponding data is recorded. The core business entities of the hearing aid industry scenario include user files and medical history, audiograms, fitting plans, hearing aid industry scenario parameter sets, and real-time acoustic sampling datasets.

[0008] Furthermore, the process of developing a business logic mapping algorithm includes: The data tables corresponding to the core business entities in the hearing aid industry scenario are marked as trigger tables, and corresponding trigger conditions are set for each trigger table. If the standard change message obtained in real time meets the corresponding trigger conditions, the business logic is mapped. Business event types are set for the corresponding trigger tables, and the required context and context extraction rules are matched according to the business event types. The associated trigger tables, trigger conditions, business event types, required contexts, and context extraction rules are used as fields in the business logic mapping rule base.

[0009] Furthermore, the process of building a cross-table context model includes: Set prior benchmark conditions, match core business entities in the hearing aid industry scenario that are related to the prior benchmark conditions, and then define the context dimension; Within the aforementioned context dimension, a chain-like filtering is performed on the core business entities of the hearing aid industry scenario that are related, thereby obtaining the core business entities of the hearing aid industry scenario with a chain relationship. The core business entities in the corresponding hearing aid industry scenario are used as nodes, and the chain relationships between the core business entities in the hearing aid industry scenario are used as edges, thus forming a cross-table context model.

[0010] Furthermore, the process of chain-style screening of core business entities in the related hearing aid industry scenarios includes: The trigger table corresponding to the target business event type is used as the chain reference position, and the data table corresponding to the core business entity of the hearing aid industry scenario adjacent to the chain reference position is used as the secondary chain position. If there are multiple sub-chain positions, and there is an association between two or more sub-chain positions, then the corresponding sub-chain position and the chain reference position are recorded as having a chain relationship. If the data table corresponding to the core business entity in the hearing aid industry scenario that is related to the secondary chain position is taken as the ordinary chain position, then the corresponding secondary chain position and ordinary chain position are recorded as having a chain relationship. Based on the chain relationship between the chain base position, the secondary chain position, and the ordinary chain position, the core business entities of the hearing aid industry scenario with chain relationship are obtained.

[0011] Furthermore, the process of building an event inference engine includes: Using the business logic of the hearing aid industry scenario as the basis for event deduction, we define standardized deduction rules that match the core business entities of the hearing aid industry scenario that have a chain relationship. Based on the standardized derivation rules, the core execution framework of the event derivation engine is built to adapt to the automatic triggering mechanism of data changes; and derivation exception handling and rule iteration mechanisms are set for the standardized derivation rules. Execute business logic deduction and generate standardized business semantic structure event documents.

[0012] Furthermore, the process of synchronizing the business semantic structure event documents based on message queue technology includes: Perform preprocessing on the semantic business event documents, and set the topic and queue configuration of the message queue; It enables asynchronous queuing and reliable storage of semantic business events, and realizes distributed message consumption, execution consumption confirmation and message lifecycle management for multi-terminal systems. It also builds multi-terminal synchronous status monitoring and anomaly fallback.

[0013] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of the above-described business logic-driven database change awareness and document synchronization method.

[0014] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of the above-described business logic-driven database change awareness and documentation synchronization method.

[0015] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described business logic-driven database change awareness and document synchronization method.

[0016] Compared with the prior art, the beneficial effects of the present invention are: 1. By deeply integrating Binlog technology with the hearing aid industry scenario, it has achieved accurate and real-time perception of all data changes of the core business entities in the industry, breaking through the problem of the disconnect between general data capture technology and industry business scenario.

[0017] 2. By developing a business logic mapping algorithm tailored to the hearing aid industry, changes to the original database data can be transformed into business event types that conform to the industry's business semantics, thus achieving a precise correlation between data changes and business events.

[0018] 3. The construction of the cross-table context model, based on the business logic of the hearing aid industry, completed the chain-like attribution judgment of the core business entities, realized the context completion and relationship mining of the core business entities, and laid a solid foundation for the entity association for business logic deduction.

[0019] 4. The event inference engine takes the business logic of the hearing aid industry as its core, realizes in-depth business logic inference of related core business entities, and generates standardized business semantic structure event documents, so that database data changes have clear business semantics and business events are traceable.

[0020] 5. Based on message queue technology, multi-terminal synchronous processing of business semantic structure event documents was completed, realizing decoupled data synchronization of hearing aid multi-terminal systems, ensuring the reliability and consistency of data synchronization, improving the intelligence level of multi-terminal system operation, making the digital data processing of the hearing aid industry more in line with the industry's professional needs, realizing the full-process business logic driven from data change perception to business semantic mining, and then to multi-terminal data intelligent synchronization, fully adapting to the digital operation needs of the hearing aid industry. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0022] Figure 1 This is a step diagram of a business logic-driven database change awareness and documentation synchronization method.

[0023] Figure 2 A schematic diagram illustrating the steps involved in building a cross-table context model.

[0024] Figure 3 This diagram illustrates the steps involved in chain-style screening of core business entities within the hearing aid industry.

[0025] Figure 4 A schematic diagram illustrating the steps involved in building an event inference engine.

[0026] Figure 5 This is a schematic diagram illustrating the steps of data synchronization processing for the business semantic structure event document based on message queue technology.

[0027] Figure 6 The renderings and reports generated for the system front-end. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be described in detail below. Obviously, the described embodiments are merely some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other implementation methods obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0029] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0030] See Figure 1 As shown, a database change awareness and documentation synchronization method driven by business logic is proposed, the method comprising the following steps: Step S1: Based on Binlog technology, monitor and capture all data changes of core business entities in the hearing aid industry scenario in real time, and record the changed data as the corresponding standard change message.

[0031] It's important to note that Binlog technology is a log file in a MySQL database used to record all data change operations. It is stored in binary format and records detailed information about operations such as inserts, updates, and deletions.

[0032] In this embodiment, the core business entities in the hearing aid industry scenario are data recorded based on the user's hearing aid fitting process, including but not limited to user profiles and medical history, audiograms, fitting plans, hearing aid industry scenario parameter sets, and real-time acoustic sampling datasets. Binlog technology is used to capture and record changes in the data of the core business entities in the hearing aid industry scenario, and the data showing changes to the corresponding entities is used as matching conditions for business logic mapping.

[0033] To further clarify, the changed data captured based on Binlog technology includes, but is not limited to, field values ​​before / after the change, table name, primary key, operation type, event timestamp, transaction ID, and whether they belong to the same transaction flow.

[0034] Step S2: Develop a business logic mapping algorithm; perform rule matching on standard change messages according to the business logic mapping algorithm to obtain the corresponding business event type.

[0035] It should be noted that the business logic mapping algorithm refers to constructing a configurable business logic mapping rule library centered on the business semantics of the hearing aid industry scenario. The rule library contains all the core business entities of the hearing aid industry scenario, and each rule contains field descriptions corresponding to the core business entities of the hearing aid industry scenario. According to the business logic mapping algorithm, the professional knowledge of the hearing aid industry scenario can be encoded into a computable and extensible rule system.

[0036] In this embodiment, the data tables corresponding to the core business entities in the hearing aid industry scenario are marked as trigger tables, and corresponding trigger conditions are set for each trigger table. If the standard change message obtained in real time meets the corresponding trigger conditions, business logic mapping is performed. Business event types are set for the corresponding trigger tables, and the required context and context extraction rules are matched according to the business event types. The associated trigger tables, trigger conditions, business event types, required contexts, and context extraction rules are used as fields in the business logic mapping rule base.

[0037] To further explain, the meaning of the trigger table is which table's change will trigger a business change; the meaning of the trigger condition is which field in the trigger table and how it changes will be identified as a business event; the business event type is set based on the identification result of the trigger condition; the meaning of the required context is the data resources corresponding to other core hearing aid business entities that need to be matched to this business event type; and the meaning of the context extraction rule is how to extract the required target data from the data resources corresponding to other core hearing aid business entities.

[0038] In one example, the business logic mapping rule base of this embodiment is shown in Table 1; Table 1:

[0039] It should be noted that the cross-table aggregation, time series comparison, dynamic matching, and sampling window aggregation in Table 1 are based on the corresponding extraction rules adopted according to the required context.

[0040] Step S3: Construct a cross-table context model; based on the cross-table context model, perform event chain attribution judgment on the corresponding business event types to obtain the core business entities of the hearing aid industry scenario with chain relationships.

[0041] It should be noted that the cross-table context model is a further implementation of the context required in the business logic mapping algorithm fields. Essentially, it is a chain graph structure. Through the corresponding chain graph structure, when the triggering table and triggering conditions in the business logic mapping algorithm fields change, the system can automatically confirm whether other related tables or parameters are affected, thereby achieving context completion of core business entities and quickly finding core business entities in the hearing aid industry scenario that correspond to the business event type and have a relationship.

[0042] In this embodiment, the specific steps for constructing the cross-table context model are as follows: Step S31: Set prior benchmark conditions, match the core business entities of the hearing aid industry scenario that are related to the prior benchmark conditions, and then define the context dimension.

[0043] Step S32: Within the context dimension, perform chain filtering on the core business entities of the hearing aid industry scenario that are related, and then obtain the core business entities of the hearing aid industry scenario that have chain relationships.

[0044] Step S33: Take the core business entities of the corresponding hearing aid industry scenario as nodes, and the chain relationship between the core business entities of the hearing aid industry scenario as edges, and then form a cross-table context model.

[0045] In one example, if the gain_4kHz value in the trigger table fitting_plan changes, and the audiogram and the trigger table fitting_plan are core business entities in the hearing aid industry with a chain relationship, then fitting recommendations that correspond to the change in gain_4kHz will be automatically generated based on the changes in the audiogram.

[0046] In step S32, the specific steps for chain-style screening of core business entities in the related hearing aid industry scenarios are as follows: Step S321: Take the trigger table of the business event type corresponding to the target as the chain reference position, and take the data table corresponding to the core business entity of the hearing aid industry scenario adjacent to the chain reference position as the secondary chain position. Step S322: If there are multiple sub-chain positions and there is an association between two or more sub-chain positions, then the corresponding sub-chain position and the chain reference position are recorded as having a chain relationship; Step S323: Take the data table corresponding to the core business entity of the hearing aid industry scenario that is related to the secondary chain position (excluding the chain reference position) as the ordinary chain position, and then record the corresponding secondary chain position and ordinary chain position as having a chain relationship. It should be noted that the ordinary chain position refers to the data table corresponding to the core business entities in the hearing aid industry scenario that are related to other chain positions, excluding the secondary chain position and the chain base position. It is worth noting that there can be multiple ordinary chain positions, and ordinary chain positions can be related to secondary chain positions, or they can be related to each other or not.

[0047] Step S324: Based on the chain relationship between the chain reference position, the secondary chain position and the ordinary chain position, obtain the core business entity of the hearing aid industry scenario with chain relationship.

[0048] It should be noted that there may be one or more chain relationships. If there is only one, the core business entity of the corresponding hearing aid industry scenario will be obtained. If there are multiple, the core business entity of the hearing aid industry scenario corresponding to each chain relationship will be obtained, and the length of the corresponding chain relationship will be used as one of the importance evaluation criteria.

[0049] Step S4: Construct an event inference engine; based on the event inference engine, perform business logic inference on the core business entities of the corresponding hearing aid industry scenario, and then generate the corresponding business semantic structure event document.

[0050] It's important to note that the event inference engine analyzes the business logic relationships between core business entities in the hearing aid industry that have a chain-like relationship. It doesn't analyze the chain-like relationships between core business entities in the hearing aid industry, but rather the actual business logic relationships between them. It's also worth noting that once the event inference engine is set up, it will automatically execute when all data related to the core business entities in the hearing aid industry in the database changes. No manual invocation is required. Users can choose to optimize or delete the event inference engine based on their needs.

[0051] In this embodiment, the specific steps for building the event inference engine are as follows: Step S41: Using the business logic of the hearing aid industry scenario as the basis for event deduction, define standardized deduction rules that match the core business entities of the hearing aid industry scenario that have a chain relationship.

[0052] It should be noted that, combining the business logic of the hearing aid industry scenario and based on the core business entities with chained relationships output by the cross-table context model, the actual business derivation logic corresponding to each business event type is sorted out, thereby obtaining the preconditions, judgment basis, and derivation conclusions of the corresponding business derivation logic; the actual business derivation logic is transformed into standardized derivation rules, in which the attributes, relationships, and business semantics of the corresponding chained core business entities are associated, and each actual business derivation logic is assigned a unique identifier, forming an association mapping with the business logic mapping rule library and the cross-table context model, ensuring that the derivation rules can accurately match the corresponding business event types and chained core business entities.

[0053] Step S42: Based on the standardized derivation rules, build the core execution framework of the event derivation engine and adapt it to the automatic triggering mechanism for data changes, specifically as follows: Based on the data change characteristics of corresponding core business entities, a core execution framework is built, comprising a rule matching module, a logic deduction module, and a result integration module. The rule matching module interfaces with the cross-table context model, automatically extracting chained core business entity information and matching it with corresponding standardized deduction rules. The logic deduction module performs layer-by-layer deduction based on the actual business logic relationships of core business entities according to standardized deduction rules, moving beyond simple chain-like superficial associations to uncover logical relationships such as business causality, timing, and conditions between entities. The result integration module structurally aggregates the deduction process and results, and links the core execution framework with the Binlog data change monitoring mechanism. This allows for the setting of automatic engine execution trigger rules, ensuring that when core business entity data in the database changes, the deduction process is automatically initiated without manual intervention.

[0054] It should be noted that the core execution framework and the Binlog data change monitoring mechanism are linked through a data synchronization mechanism.

[0055] Step S43: Set up derivation exception handling and rule iteration mechanisms for the standardized derivation rules to improve the stability and adaptability of the event derivation engine, specifically as follows: Define various abnormal scenarios for the event inference engine during the inference process, including but not limited to missing core business entity information in a chain, no matching items in the inference rules, business logic inference conflicts, and abnormal data fields. Develop corresponding exception handling strategies for different abnormal scenarios, such as triggering a context completion request when core business entity information is missing, logging and terminating the inference when no matching items are found in the inference rules, and executing rules according to business priority when business logic inference conflicts occur. Develop an iterative management mechanism for the standardized inference rules, including but not limited to adding, modifying, disabling, and deleting standardized inference rules, and recording version change information of standardized inference rules to ensure that standardized inference rules can be dynamically adjusted as hearing aid business logic is updated to adapt to business development needs.

[0056] Step S44: Execute business logic derivation and generate standardized business semantic structure event documents.

[0057] It should be noted that the standardized business semantic structure event document is in JOSN format, which has the advantages of self-description, displaying the complete business chain, traceability, and a data structure tailored to hearing aid scenarios. This is beneficial for subsequent intelligent development and application of systems based on this format.

[0058] In one example, taking the GAIN_PROFILE_ADJUSTED business event type triggered by the gain_4kHz change in the fitting_plan table in Table 1 as an example, the core business entities in the chain output by the cross-table context model are: fitting_plan (fitting plan), audiogram (audiogram), and device_param (hearing aid parameter set), where fitting_plan is the chain baseline position, audiogram is the secondary chain position, and device_param is the normal chain position.

[0059] When the gain_4kHz field in the trigger table fitting_plan changes, the core business deduction logic unfolds based on the rationality verification, adaptability deduction, and parameter synchronization of the gain adjustment, clarifying the preconditions, judgment basis, and deduction conclusions, as follows: Table 2:

[0060] Each of the above actual business derivation logics is assigned a unique identifier, such as R-GPA-001, corresponding to the business event type GAIN_PROFILE_ADJUSTED. The rules clearly define the attributes, relationships, and business semantics of the core business entities in the related chain, and form an association mapping with the business logic mapping rule base and the cross-table context model. The standardized derivation rules are specifically expressed as follows: Table 3:

[0061] To further explain the execution process of the standardized derivation rules: If the gain_4kHz in the fitting_plan table is a valid change and the threshold_4kHz in the audiogram is a valid value, calculate the ratio of gain_4kHz / threshold_4kHz. If the result is in the range of 1 / 2 to 2 / 3, it is determined to meet the industry fitting standard; otherwise, it is not. Match the gain_4kHz_max corresponding to device_model in device_param (hearing aid parameter set). If gain_4kHz ≤ gain_4kHz_max in fitting_plan (fitting plan), it is determined to be a match within the hardware support range of the device; otherwise, it is a mismatch. Based on the level of nr_mode (noise reduction mode) in device_param (hearing aid parameter set), verify its compatibility with the adjusted gain_4kHz, and output the adaptation level, such as excellent, good or poor. Based on the above judgment results, output a conclusion on whether it is necessary to synchronously update relevant_acoustic_param (4kHz gain-related acoustic parameter) in device_param (hearing aid parameter set).

[0062] Step S5: Based on message queue technology, perform data synchronization processing on the business semantic structure event document to realize data synchronization of multiple systems in the hearing aid industry scenario, thereby improving the system's intelligence and operating efficiency.

[0063] It's important to note that message queue technology is a first-in, first-out (FIFO) queue-type data structure primarily used for transmitting messages between different processes or systems. By storing messages in a queue, message queues allow sending and receiving processes to process operations asynchronously and decouple operations, thereby achieving efficient data synchronization and improving system performance and reliability.

[0064] In this embodiment, the specific steps for data synchronization processing of the business semantic structure event document based on message queue technology are as follows:

[0065] Step S51: Perform pre-processing for enqueuing business semantic structure event documents. Specifically, the standardized business semantic structure event documents generated by the event inference engine are normalized in format, each document is assigned a globally unique document identifier, and the documents are classified and labeled according to the hearing aid business scenario, such as audiogram change category, fitting scheme adjustment category, etc., to form a standardized synchronous message body that can be recognized by the message queue.

[0066] Step S52: Set the message queue topic and queue configuration. Specifically, based on the business function division and data synchronization requirements of the hearing aid multi-terminal system, build a hierarchical architecture of business topic-dedicated queue in the message queue: create first-level business topics according to business event types, such as HEARING_MAP_UPDATED topic, GAIN_PROFILE_ADJUSTED topic, and NOISE_REDUCTION_MODE_SWITCHED topic; create dedicated consumption queues for the fitting end, user end, device management end, back-end operation end, and other multi-terminal systems, and bind each consumption queue to the corresponding business topic. At the same time, configure the message filtering rules of the queue to ensure that each end system only consumes the event document synchronization messages required by its own business and avoids invalid data transmission.

[0067] Step S53: Asynchronous queuing and reliable storage of business semantic structure events. Specifically, the preprocessed standardized synchronous message body is pushed to the message producer of the corresponding business topic in the message queue. The message queue performs persistent storage of the message and sets up message duplicate delivery and loss retry mechanism: if the message push fails, the preset re-push strategy is triggered (re-push a limited number of times at fixed time intervals); if the message delivery is successful, the message queue will mark the message status as "to be consumed" and record the message queuing time and producer identifier to achieve full-link traceability of event document synchronous messages.

[0068] Step S54: Implement distributed message consumption across multiple systems. Specifically, each system acts as a consumer of the message queue, implementing distributed asynchronous consumption based on its own business rhythm. The consumer listens to the message status of the bound queue through a long connection. When a "to be consumed" message is detected, it pulls the synchronous message body according to the first-in-first-out principle. After pulling, the message body is validated for legality, such as verifying the unique document identifier, data signature, and integrity of core related information. If the validation passes, the business semantic structure event document is parsed, and the core data and business deduction conclusions in the document are synchronized to the local database and business display module of each system to achieve data synchronization. If the validation fails, the message is marked as an "abnormal message" and pushed to the exception handling queue of the message queue for manual review.

[0069] Step S55: Perform consumption confirmation and message lifecycle management. Specifically, after each system completes the parsing and synchronization of the event document, it returns a confirmation instruction for successful consumption to the message queue. Upon receiving the confirmation instruction, the message queue marks the corresponding message as "consumed" and cleans it up or archives it according to a preset strategy. If the consumer does not return a confirmation instruction within a preset time, the message queue determines that the consumption has timed out and pushes the message back to the corresponding consumption queue to avoid data synchronization omissions in multiple systems. At the same time, a message lifecycle threshold is set to automatically clean up invalid messages that have not been consumed after exceeding the threshold, releasing message queue storage resources.

[0070] Step S56: Construct multi-terminal synchronization status monitoring and anomaly fallback mechanism. Specifically, this involves building a multi-terminal synchronization status monitoring module for message queues to monitor key indicators such as message production rate of each business topic, consumption rate of each consumption queue, message backlog, and consumption failure rate in real time. If anomalies such as message backlog, excessively high consumption failure rate, or synchronization interruption of a certain system occur, the monitoring module will immediately trigger an alarm and activate the fallback synchronization mechanism: by using the message backtracking function of the message queue to re-push unsynchronized event documents, or by using the unified data interface of the multi-terminal system to complete the synchronization, ensuring that the business data of each hearing aid system is always consistent with the business semantic structure event documents, and achieving efficient and reliable synchronization of multi-terminal data.

[0071] Optionally, in this embodiment, those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0072] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0073] If the integrated units in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause one or more electronic devices to execute all or part of the steps of the methods described in the various embodiments of this application.

[0074] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

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

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

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

[0078] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A business logic driven database change awareness and documentation synchronization method, characterized in that, The method includes: Based on Binlog technology, it monitors and captures all data changes of core business entities in the hearing aid industry in real time, and records all the changed data as the corresponding standard change message. Develop a business logic mapping algorithm; perform rule matching on standard change messages according to the business logic mapping algorithm to obtain the corresponding business event types; Construct a cross-table context model; based on the cross-table context model, perform event chain attribution judgment on the corresponding business event types to obtain the core business entities of the hearing aid industry scenario with related relationships; Construct an event inference engine; based on the event inference engine, perform business logic inference on the core business entities of the corresponding hearing aid industry scenario, and then generate the corresponding business semantic structure event document; Based on message queue technology, the business semantic structure event document is processed for data synchronization, realizing data synchronization of hearing aid multi-terminal systems, improving the system's intelligence and operating efficiency. The process of building a cross-table context model includes: Set prior benchmark conditions, match core business entities in the hearing aid industry scenario that are related to the prior benchmark conditions, and then define the context dimension; Within the aforementioned context dimension, a chain-like filtering is performed on the core business entities of the hearing aid industry scenario that are related, thereby obtaining the core business entities of the hearing aid industry scenario with a chain relationship. The core business entities in the corresponding hearing aid industry scenario are used as nodes, and the chain relationships between the core business entities in the hearing aid industry scenario are used as edges, thus forming a cross-table context model. The process of chain-linking core business entities in related hearing aid industry scenarios includes: The trigger table corresponding to the target business event type is used as the chain reference position, and the data table corresponding to the core business entity of the hearing aid industry scenario adjacent to the chain reference position is used as the secondary chain position. If there are multiple sub-chain positions and there is an association between the multiple sub-chain positions, then the corresponding sub-chain position and the chain reference position are recorded as having a chain relationship; If the data table corresponding to the core business entity in the hearing aid industry scenario that is related to the secondary chain position is taken as the ordinary chain position, then the corresponding secondary chain position and ordinary chain position are recorded as having a chain relationship. Based on the chain relationship between the chain-based base position, the secondary chain position, and the ordinary chain position, the core business entities of the hearing aid industry scenario with chain relationships are obtained.

2. The business logic driven database change awareness and documentation synchronization method of claim 1, wherein, Based on Binlog technology, the changes in the core business entities of the hearing aid industry scenario are captured and the corresponding data is recorded. The core business entities of the hearing aid industry scenario include user files and medical history, audiograms, fitting plans, hearing aid industry scenario parameter sets, and real-time acoustic sampling datasets.

3. The database change awareness and documentation synchronization method driven by business logic according to claim 2, characterized in that, The process of developing a business logic mapping algorithm includes: The data tables corresponding to the core business entities in the hearing aid industry scenario are marked as trigger tables, and corresponding trigger conditions are set for each trigger table. If the standard change message obtained in real time meets the corresponding trigger conditions, the business logic is mapped. Business event types are set for the corresponding trigger tables, and the required context and context extraction rules are matched according to the business event types. The associated trigger tables, trigger conditions, business event types, required contexts, and context extraction rules are used as fields in the business logic mapping rule base.

4. The database change awareness and documentation synchronization method driven by business logic according to claim 3, characterized in that, The process of building an event inference engine includes: Using the business logic of the hearing aid industry scenario as the basis for event deduction, we define standardized deduction rules that match the core business entities of the hearing aid industry scenario that have a chain relationship. Based on the standardized derivation rules, the core execution framework of the event derivation engine is built to adapt to the automatic triggering mechanism of data changes; and derivation exception handling and rule iteration mechanisms are set for the standardized derivation rules. Perform business logic deduction and generate standardized business semantic structure event documents.

5. A database change awareness and documentation synchronization method driven by business logic as described in claim 4, characterized in that, The process of synchronizing data for the business semantic structured event documents based on message queue technology includes: Perform preprocessing on the semantic business event documents, and set the topic and queue configuration of the message queue; It enables asynchronous queuing and reliable storage of semantic business events, and realizes distributed message consumption, execution consumption confirmation and message lifecycle management for multi-terminal systems. It also builds multi-terminal synchronous status monitoring and anomaly fallback.

6. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of a business logic-driven database change awareness and documentation synchronization method as described in any one of claims 1 to 5 when executing the computer program.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of the business logic-driven database change awareness and documentation synchronization method as described in any one of claims 1 to 5.

8. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the database change awareness and documentation synchronization method as described in any one of claims 1 to 5.

Images