Data model construction, multi-level process mining method and device based on event log

Abstract

The present disclosure discloses a data model construction method, relates to the technical field of process mining, and has the specific implementation scheme that: a plurality of event log information is acquired; activities in the event log information are divided into multiple levels to obtain a plurality of level log tables; the level log table is marked with an event level to obtain a level marking result; and a data model is generated according to the level marking result. Therefore, the disordered event log can be converted into a structured data model that can be used for analysis and decision support.

Description

Technical Field

[0001] This invention belongs to the field of process mining technology, and specifically relates to a data model construction method and apparatus, a multi-level process mining method and apparatus based on event logs, an electronic device, and a computer-readable storage medium. Background Technology

[0002] Traditional process mining is a technique that uses two-dimensional event logs, with cases as the dimension and the chronological order of events, for analysis. However, if a task event has multiple sub-tasks, existing process mining techniques have the following two drawbacks:

[0003] 1) Aligning the events of subtasks with those of the parent task for analysis will lead to an explosion in the number of events and activities, resulting in chaotic data and difficult analysis.

[0004] 2) Modeling and analyzing the events of subtasks separately will result in separation from the parent data, making data comparison impossible.

[0005] The information disclosed in this background section is intended only to enhance the understanding of the overall background of the invention and should not be construed as an admission or in any way implying that the information constitutes prior art known to those skilled in the art. Summary of the Invention

[0006] The purpose of this disclosure is to solve the technical problems of the current proliferation of event activities, chaotic data and difficulty in analysis, and the inability to compare data due to the separation of parent and child data. It provides a data model construction method and apparatus, a multi-level process mining method and apparatus based on event logs, an electronic device, and a computer-readable storage medium.

[0007] The first aspect of this disclosure provides a data model construction method, which includes: acquiring multiple event log information; dividing the activities in the event log information into multiple levels to obtain multiple level log tables; marking the level log tables by event level to obtain level marking results; and generating a data model based on the level marking results.

[0008] In one embodiment of this disclosure, dividing the activities in the event log information into multiple levels to obtain multiple hierarchical log tables includes: dividing the activities in the event log information into multiple levels of nodes; obtaining activity data for each activity in each level node from the event log information; and filling the activity data of the activity into the table corresponding to the level node according to the level node corresponding to the activity, thereby obtaining multiple hierarchical log tables.

[0009] In one embodiment of this disclosure, activities in event log information are divided into multiple levels to obtain multiple level log tables, including: clustering different types of activities in event log information to obtain clustering results; determining the level to which each activity in the event log information belongs based on the clustering results; obtaining activity data of activities at each level; and filling the activity data of activities at each level into the table corresponding to each level to obtain multiple level log tables.

[0010] In one embodiment of this disclosure, the clustering result includes: project type and at least one project stage. Based on the clustering result, determining the level to which each activity in the event log information belongs includes: filtering activity data of activities belonging to the project type in the event log information; for at least one project stage, detecting the project stage to which the activity data of each activity belongs, and classifying each activity into the corresponding project stage; identifying the corresponding level for at least one project stage, and determining the level to which each activity in the event log information belongs.

[0011] In one embodiment of this disclosure, the above-mentioned event level marking of multiple level log tables to obtain level marking results includes: using the level of event level of different level activities to mark the level of each level log table in the multiple level log tables, thereby obtaining level marking results.

[0012] In one embodiment of this disclosure, generating a data model based on the hierarchical labeling results includes: associating multiple hierarchical log tables according to the order of hierarchical representations in the hierarchical labeling results, and constructing a data model based on the associated hierarchical log tables.

[0013] The second aspect of this disclosure provides a multi-level process mining method based on event logs. The method includes: obtaining process query requests from event logs; determining process data to be queried based on the process query requests; and obtaining multi-level process mining results from a data model based on the process data to be queried. The data model is constructed using the data model construction method of the first aspect of this disclosure.

[0014] A third aspect of this disclosure provides a data model building apparatus, comprising: an acquisition unit configured to acquire multiple event log information; a obtaining unit configured to perform multi-level division of activities in the event log information to obtain multiple hierarchical log tables; a marking unit configured to perform event hierarchical marking on the hierarchical log tables to obtain hierarchical marking results; and a generation unit configured to generate a data model based on the hierarchical marking results.

[0015] The fourth aspect of this disclosure provides a multi-level process mining apparatus based on event logs. The apparatus includes: a request unit configured to obtain a process query request from an event log; a determination unit configured to determine process data to be queried based on the process query request; and a result unit configured to obtain multi-level process mining results from a data model based on the process data to be queried. The data model is constructed using a data model construction apparatus described in any implementation of the third aspect of this disclosure.

[0016] A fifth aspect of this disclosure provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor, wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform a method as described in any implementation of the first aspect or a method as described in any implementation of the second aspect.

[0017] A sixth aspect of this disclosure provides a computer-readable storage medium for storing computer instructions for causing a computer to perform a method as described in any implementation of the first aspect or a method as described in any implementation of the second aspect.

[0018] The process data simulation method and apparatus provided in the embodiments of this disclosure first acquire multiple event log information; second, divide the activities in the event log information into multiple levels to obtain multiple hierarchical log tables; then, mark the event levels in the hierarchical log tables to obtain hierarchical marking results; finally, generate a data model based on the hierarchical marking results. Thus, by generating hierarchical log tables based on the hierarchy of activities in the event log information, and constructing a data model using these hierarchical log tables, messy event logs can be transformed into a structured data model that can be used for analysis and decision support. This makes the hierarchical relationship of event activities in the data model more explicit, reduces the bloat of activity data, and improves data analysis efficiency. Attached Figure Description

[0019] Figure 1 This is a flowchart of one embodiment of the data model construction method according to this disclosure;

[0020] Figure 2 This is a flowchart of an embodiment of the multi-level process mining method based on event logs according to this disclosure;

[0021] Figure 3 This is a schematic diagram of the structure of an embodiment of the data model construction apparatus according to the present disclosure;

[0022] Figure 4 This is a schematic diagram of a structure of an embodiment of the multi-level process mining apparatus based on event logs according to the present disclosure;

[0023] Figure 5 This is a block diagram of an electronic device used to implement the data model construction method of the embodiments of this disclosure. Detailed Implementation

[0024] Unless otherwise expressly stated, throughout the specification and claims, the term "comprising" or its variations such as "including" or "comprises" shall be understood to include the stated elements or components without excluding other elements or other components.

[0025] The technical solution of the present invention is illustrated below through specific embodiments. It should be understood that the one or more steps mentioned in the present invention do not preclude the existence of other methods and steps before or after the combined steps, or that other methods and steps may be inserted between these explicitly mentioned steps. It should also be understood that these examples are for illustrative purposes only and are not intended to limit the scope of the present invention. Unless otherwise stated, the numbering of each method step is only for the purpose of identifying each method step, and not for limiting the order of each method or limiting the scope of the present invention. Changes or adjustments to their relative relationships, without substantial changes to the technical content, can also be considered as within the scope of the present invention.

[0026] The raw materials and instruments used in the examples are not subject to any specific restrictions on their source; they can be purchased from the market or prepared according to conventional methods known to those skilled in the art.

[0027] To address the shortcomings of existing technologies, this disclosure provides a data model construction method. By analyzing event log information and dividing the activities in the log information into multiple levels according to the hierarchical relationship of the event logs, the data can be hierarchically prioritized before using log information to construct the data model, thereby improving the data model construction efficiency. Figure 1 A flow 100 illustrating an embodiment of a data model construction method is shown, which includes the following steps:

[0028] Step 101: Obtain multiple event log information.

[0029] An event log contains activity log information about the event handling process. It typically includes the event's operation log, such as the instance ID, event name, time, parent event primary key, and primary key. The log information should preserve the data as accurately as possible at the time of the event. Logs can be stored in the system's log files or in a log table.

[0030] In this embodiment, event log information can be obtained through various means. For example, the system's log monitoring system can use an interceptor to save logs to a log file according to the system-configured log format when processing events, and then read the event log file to obtain the event log information.

[0031] In this embodiment, event log information can also be obtained by reading records from the log table in the database. For example, when the system processes an event, it saves the logs to the log table according to the log format configured by the system. By reading the records from the log table of the event log, the event log information can be obtained.

[0032] Step 102: Divide the activities in the event log information into multiple levels to obtain multiple level log tables.

[0033] In this embodiment, the event log information stores the primary keys of the parent nodes of each activity. Based on the hierarchical relationship of the primary keys of different activity nodes, the event log information is traversed to form one (corresponding to the same project) or multiple (corresponding to multiple projects) tree-structured hierarchical data. Since activities in a project have corresponding event stages (e.g., Project 1 has a first stage and a second stage, where the first stage includes Activity 1 and Activity 2, and the second stage includes Activity 3, Activity 4, and Activity 5), the various levels of the tree-structured data are traversed again, and activity nodes with the same event stage are assigned to the corresponding level of activity hierarchy data. This achieves the hierarchical division of the event log information. Based on the activity hierarchy data, a hierarchical log table is created, with each event stage corresponding to a hierarchical log table. The hierarchical log table is filled with activity hierarchy data. For example, the root node corresponds to the first-level hierarchical log table, and the table name of the corresponding hierarchical log table is log_1. Step 103: Event hierarchy marking is performed on the hierarchical log table to obtain the hierarchical marking results.

[0034] In this embodiment, the hierarchical log table obtained above can be marked with event levels according to the order of each event stage during project implementation. Event stages can be distinguished through overall project planning. For example, Project 1 has multiple event stages such as the initiation stage, implementation stage, and acceptance stage. The hierarchy of each event stage is determined based on its chronological order within the project implementation, starting from level 0 and marked as 0, 1, 2, 3..., incrementing by 1 sequentially. The hierarchical log table is a database table storing log records. Each event stage corresponds to one hierarchical log table. Each record in the hierarchical log table is marked with its corresponding level, resulting in a hierarchical marking result. This result can include each hierarchical log table and the corresponding level. In this embodiment, the hierarchy of the hierarchical log table is determined simultaneously with its formation and stored separately. For example, hierarchical log table 1 corresponds to level 0, and hierarchical log table 2 corresponds to level 1.

[0035] Step 104: Generate a data model based on the hierarchical labeling results.

[0036] In this embodiment, the data model is the core foundation of the database system. Its essence is the abstraction and simulation of the characteristics of real-world data. By defining the structure, operation and constraints of the data, it provides a standardized framework for database design.

[0037] In this embodiment, the data model is a data model based on hierarchical labeling results. Compared with traditional data models, this data model has corresponding data hierarchical labels, which can provide more detailed hierarchical identification for database design.

[0038] In this embodiment, the data structure, data operation methods, and data constraint rules are determined based on the hierarchical labeling results and event log information. These data operation methods and constraint rules are then added to the data results to ultimately generate a data model. For example, event log information includes record ID, instance ID, activity name, parent node ID, operator ID, operation time, department, etc. The generated data structure needs to include corresponding data attributes. Data operation methods generally include operations such as adding, querying, and modifying data. Data constraint rules are rules governing the modification permissions of the data model. For example, a data constraint rule might be: only personnel in the finance department have the permission to add or modify data; personnel in other departments only have the permission to query their own data. Based on the above, the final generated data model includes the following data attributes: record ID, instance ID, activity name, parent node ID, operator ID, operation time, department, and sub-event data. Data operation methods include: adding, querying, and modifying data. Data constraint rules include: personnel in the finance department can add and modify data; other personnel can query their own data.

[0039] The data model construction method disclosed herein first obtains multiple event log information; second, it divides the activities in the event log information into multiple levels, resulting in multiple hierarchical log tables; then, it marks the event levels in the hierarchical log tables, obtaining the hierarchical marking results; finally, it generates a data model based on the hierarchical marking results. Thus, by generating hierarchical log tables based on the hierarchy of activities in the event log information, and constructing a data model using these hierarchical log tables, messy event logs can be transformed into a structured data model that can be used for analysis and decision support. This makes the hierarchical relationships of event activities in the data model more explicit, reduces the bloat of activity data, and improves data analysis efficiency.

[0040] In some optional implementations of this disclosure, dividing the activities in the event log information into multiple levels to obtain multiple level log tables includes: dividing the activities in the event log information into multiple level nodes; for each level node, obtaining the activity data of the activity from the event log information; and according to the level node corresponding to the activity, filling the activity data of the activity into the table corresponding to that level node to obtain multiple level log tables.

[0041] In this optional implementation, the multi-level node division of activities in the event log information includes: using a semantic recognition model to identify the project type to which the event log information belongs, such as a construction project or a teaching project; determining the project stage of the event log information based on the project type; extracting activities of different levels in the event log; and dividing the activities of different levels into the corresponding project stages. Each project stage corresponds to a level of hierarchical node. Each project stage can have one or more level nodes, thus realizing the multi-level node division of activities.

[0042] In this optional implementation, the activity data is the data describing the activity in the event log information, such as the activity ID, activity name, instance ID, primary key, activity time, etc. Each activity has corresponding activity data in the event log information. After the activity node is determined, the activity data of the activity node is used as a record to fill the corresponding hierarchical node.

[0043] In this optional implementation, the hierarchical log table is a table that records the activity data of each hierarchical node. The number of hierarchical log tables is determined by the hierarchical level of the hierarchical node, and one hierarchical log table corresponds to one project phase. The activity data recorded in each hierarchical log table belongs to the activity data of the activity node at the same level.

[0044] This optional implementation provides a method for obtaining multiple-level log tables by dividing the activities in the event log information into multi-level nodes; for each activity in each level node, the activity data of that activity is obtained from the event log information; according to the level node corresponding to the activity, the activity data of that activity is filled into the table corresponding to that level node, thus obtaining multiple-level log tables, providing a reliable implementation method for obtaining level log tables.

[0045] In some optional implementations disclosed herein, activities in the event log information are divided into multiple levels to obtain multiple level log tables, including: clustering different types of activities in the event log information to obtain clustering results; determining the level to which each activity in the event log information belongs based on the clustering results; obtaining activity data for activities at each level; and filling the activity data for activities at each level into the corresponding table for each level to obtain multiple level log tables.

[0046] In this optional implementation, the clustering result includes: clusters of different clustering types, each cluster including at least one activity, and the activities in each cluster are of different types from the above-mentioned clustering event log information. The clustering result is obtained by: extracting activities from the event log information, clustering activities using a clustering algorithm, detecting whether activities between any two different clustering types have a hierarchical relationship, and in response to the hierarchical relationship between activities between any two different clustering types, assigning the activities with the hierarchical relationship to the same cluster to obtain the clustering result.

[0047] In this optional implementation, the above-mentioned determination of the level to which each activity belongs in the event log information based on the clustering results includes: taking the number of clusters as a level, determining the hierarchical relationship of all clusters based on the characteristics of each cluster, and determining the level to which the activities in each cluster belong.

[0048] In this optional implementation, the activity data is the data describing the activity in the event log information, such as the activity ID, activity name, instance ID, primary key, activity time, etc. Each activity has corresponding activity data in the event log information. After the activity node is determined, the activity data of the activity node is used as a record to fill the corresponding table at the corresponding level.

[0049] In this optional implementation, the hierarchical log table is a table that records the activity data of each hierarchical node. The number of hierarchical log tables is determined by the hierarchy of the clusters mentioned above, and one hierarchical log table corresponds to one cluster. The activity data recorded in each hierarchical log table belongs to the activity data of the same level.

[0050] This optional implementation provides a method for obtaining multiple-level log tables by clustering different types of activities in the event log information to obtain clustering results; determining the level to which each activity in the event log information belongs based on the clustering results; obtaining activity data for each level of activities; and filling the activity data of each level of activities into the corresponding table of each level to obtain multiple-level log tables, thus providing another reliable implementation method for obtaining hierarchical log tables.

[0051] In some optional implementations of this disclosure, the clustering results include: project type and at least one project stage. Based on the clustering results, determining the level to which each activity in the event log information belongs includes: filtering activity data belonging to the project type in the event log information; for at least one project stage, detecting the project stage to which the activity data of each activity belongs, and classifying each activity into the corresponding project stage; identifying the corresponding level for at least one project stage, and determining the level to which each activity in the event log information belongs.

[0052] In this optional implementation, the clustering results can include at least one project type, and at least one project stage can be a stage of each project type. The activity data for activities belonging to a project type in the aforementioned event log information filtering includes: extracting the semantics of activities from the event log information, determining the project type to which the semantics belong by querying the internet or a pre-defined table; and extracting activity data for each activity from the event log information.

[0053] In this optional implementation, the item type in the clustering result is determined by the clustering type and clustering activity. For example, after using a clustering algorithm to cluster different types of activities in the event log information, the clusters of the cluster types are determined; the features of the activities in the clusters are extracted, and it is detected whether the features belong to one of the preset multiple item types. In response to the detection that it belongs to one of the preset multiple item types, the item type is identified for the cluster.

[0054] In this optional implementation, the project stages in the clustering results are determined after obtaining a project type, identifying the various stages corresponding to that project type, and using each stage as a project stage. For example, under the construction project type, project stages include: project initiation stage, implementation stage, acceptance stage, etc.

[0055] In this optional implementation, identifying the corresponding level for at least one project phase and determining the level to which each activity belongs in the event log information includes: based on at least one project phase under the same project type, determining the sequential order of each project phase according to the order of implementation or realization of the project phases; using the order of each project phase as the level of the project type, after determining the project phases of each project type, classifying the activities into the corresponding project phases, and using the level of the project phase as the level of the activities in the project phase.

[0056] This optional implementation provides a method for determining the level to which an activity belongs, which involves filtering activity data belonging to the project type in the event log information; for at least one project phase, detecting the project phase to which the activity data of each activity belongs, and classifying each activity into the corresponding project phase; identifying the corresponding level for at least one project phase, and determining the level to which each activity belongs in the event log information, thus providing a reliable implementation method for classifying the level to which an activity belongs.

[0057] In some optional implementations of this disclosure, event level marking is performed on multiple level log tables to obtain the level marking result. This includes: using the event level of different level activities to mark the level of each level log table in the multiple level log tables, thus obtaining the level marking result.

[0058] In this optional implementation, the event hierarchy is the priority order of events corresponding to the event log information in different implementation stages or the order in which events occur in different implementation stages. The level is used to characterize the priority or order of occurrence of the time hierarchy, such as the first level, the second level, etc. After obtaining multiple hierarchical log tables, the level of each hierarchical log table can be determined according to the implementation stage priority or order of occurrence shown by the activity data in the hierarchical log tables. The level is used to mark each hierarchical log table in the multiple hierarchical log tables to obtain the hierarchical marking result.

[0059] In this optional implementation, the hierarchical labeling result includes: multiple hierarchical log tables and the level identified for each hierarchical log table.

[0060] The optional implementation provides a method for obtaining hierarchical marking results by using the event level of different hierarchical activities to mark the level of each hierarchical log table in multiple hierarchical log tables, thereby obtaining hierarchical marking results and improving the reliability of obtaining hierarchical marking results.

[0061] Optionally, for a filling order of multiple hierarchical log tables, the above-mentioned event hierarchical marking of multiple hierarchical log tables to obtain the hierarchical marking result includes: determining the filling order number of each hierarchical log table to be filled in sequence, determining the level of the active event level in each hierarchical log table according to the filling order number, and using each level to mark the level of the corresponding hierarchical log table to obtain the hierarchical marking result.

[0062] In some optional implementations of this disclosure, generating a data model based on the hierarchical labeling results includes: associating multiple hierarchical log tables according to the order of hierarchical representations in the hierarchical labeling results, and constructing a data model based on the associated hierarchical log tables.

[0063] In this optional implementation, the data model is typically divided into three layers, with each layer refined in its specific design: Conceptual Model (e.g., ER model): Addresses business requirements, describing entities and relationships without delving into technical details. Logical Model (e.g., relational model, hierarchical model): Based on the DBMS, it implements the requirements, defining table structures, key constraints, etc. Physical Model: Provides the specific implementation scheme, optimizing storage performance (e.g., index design).

[0064] In this optional implementation, a separate table can be used to store the relationships between all hierarchical log tables. The data model constructed based on the associated hierarchical log tables includes: First, determining the conceptual model. Based on business requirements analysis and goal definition, clarifying business requirements and model goals. For example, business requirements analysis includes: What business problems need to be solved? (e.g., sales analysis, user behavior tracking) What data needs to be stored? How will it be queried or analyzed? What is the data update frequency? (real-time / batch)? Then, filtering the list of business entities (e.g., users, orders, products) related to business requirements and model goals from the associated hierarchical log tables. Entity Relationship Diagram (ERD) is used to describe the business logic. Specifically, using an ERD to describe the business logic includes: identifying entities and attributes in the business entity list. Entities: such as the customer table and order table; attributes: such as customer ID and order date. Based on the entities and attributes in the business entity list, defining relationships: One-to-one (1:1): such as user and ID card information. One-to-many (1:N): such as customer and order. Many-to-many (N:M): such as orders and products (requires an intermediate table of order details), resulting in a conceptual model.

[0065] The second step is to transform the conceptual model into a concrete table structure based on database design paradigms, adhering to these paradigms. First Normal Form (1NF): Ensures each column is indivisible (e.g., address split into province, city, and street). Second Normal Form (2NF): Eliminates partial dependencies (e.g., product names should not be directly stored in the order table; they should be associated through product IDs). Third Normal Form (3NF): Eliminates transitive dependencies (e.g., department phone numbers should not be stored in the employee table; they should be associated through department IDs). Denormalization trade-offs: Allows appropriate redundancy based on query performance requirements (e.g., redundant customer names in the order table to speed up queries).

[0066] The third step is to adapt the table structure to the specific database system. Define the data types in the table structure, such as: text: VARCHAR(50), TEXT; numeric: INT, DECIMAL(10,2); time: DATE, TIMESTAMP; set constraints: primary key: PRIMARY KEY; foreign key: FOREIGN KEY REFERENCES table_name(column_name); NOT NULL: NOT NULL. Index optimization: create indexes for frequently queried fields (such as order date, customer ID).

[0067] The fourth step is data population and validation to ensure the model supports real-world data. Data cleaning: handling missing values ​​and duplicate data. Inserting test data: validating foreign key constraints and business logic. Query validation: executing typical business queries (such as "count the total number of orders for a certain customer").

[0068] The fifth step is iterative optimization and documentation. Adjust indexes or table structures based on query performance, and add new fields or tables according to business needs (e.g., add a promotional activity table). Visualize the data model's output, including a data dictionary describing the meaning and data type of each table and column, and an ER diagram visualizing table relationships.

[0069] The method for generating a data model provided by this optional implementation, based on the hierarchical labeling results, includes: associating multiple hierarchical log tables according to the order of hierarchical representation in the hierarchical labeling results; constructing a data model based on the associated hierarchical log tables; and improving the comprehensiveness and reliability of the obtained data model by constructing a data model with associated hierarchical log tables.

[0070] Optionally, the above-mentioned generation of a data model based on the hierarchical labeling results further includes: when adapting the table structure corresponding to the associated hierarchical log table to a specific database system, obtaining historical query fields and detecting whether the historical query fields can form a process with multiple project stages; in response to detecting that the historical query fields can form a process with multiple project stages, creating multiple indexes based on the multiple project stages; wherein, creating multiple indexes based on the multiple project stages includes: for each project stage in the multiple project stages, determining the activities of each project stage, extracting an index combining any one activity of each project stage, until all activities in the multiple project stages are combined.

[0071] Figure 2 Process 200 illustrates an embodiment of a multi-level process mining method based on event logs. This method includes the following steps:

[0072] Step 201: Obtain the process query request for the event log.

[0073] In this embodiment, a process query request is a request to query a process within a data model. The process query request includes: keywords for the fields of the process to be queried, and the target data model to be queried. The process to be queried refers to a collection of interrelated and sequential activities or tasks that work together to achieve a specific goal or produce a specific result. It is not merely a simple list of activities, but a logical and purposeful combination.

[0074] In process mining systems, process query requests to obtain event logs are a key entry point for triggering multi-level analysis. Query requests can take various forms, such as structured input, natural language interaction, and visual interaction generation. Semantic parsing techniques for these requests are diverse, including context-aware parsing that can resolve ambiguities using domain knowledge graphs or dynamically loading enterprise-specific process terminology. Multi-level query deconstruction can break down high-level requests into executable atomic operations.

[0075] Step 202: Based on the process query request, determine the process data to be queried.

[0076] In this embodiment, the database query statement or the process query interface is called to return basic process information (such as ID, status, node) or extended related data (such as form content, approval comments). The query results are then formatted and output (such as JSON nested structure, field mapping).

[0077] Step 203: Based on the process data to be queried, obtain multi-level process mining results from the data model.

[0078] In this embodiment, the data model can be a model constructed using the data model construction method described in the above embodiments.

[0079] In this embodiment, the multi-level process mining result is a result obtained after querying the process data to be queried in the data model. For example, the multi-level process mining result includes: the data query result of the process data to be queried, the hierarchical level involved in the data query result in the data model, the data segment of the original event log information corresponding to the process data to be queried, etc. Through recursive or graph traversal algorithms, based on the parent-child relationship between the data model and the process data to be queried, all sub-processes are mined downwards, and finally the multi-level process mining result is obtained.

[0080] Optionally, the process data to be queried is matched with multiple pre-set indexes. In response to the detection that the process data to be queried is successfully matched with multiple pre-set indexes, the data model is retrieved using the successfully matched indexes to obtain multi-level process mining results.

[0081] The multi-level process mining method based on event logs disclosed herein first obtains process query requests from event logs; then, based on the process query requests, determines the process data to be queried; and finally, based on the process data to be queried, obtains multi-level process mining results from the data model. Thus, this method provides a complete solution for the field of process mining, from data preparation to knowledge extraction, and is particularly suitable for complex business scenarios requiring multi-level process insights.

[0082] In some embodiments of this disclosure, the method further includes: displaying the multi-level process mining results using at least one of a variety of display methods.

[0083] In this embodiment, various visualization methods can be used to display the results of multi-level process mining. Depending on different analysis objectives, user roles, and scenarios, a suitable display format can be selected, for example:

[0084] Hierarchical Graph; Applicable Scenarios: Visually displays the nesting relationships and dependency paths of parent and child processes. Technical Implementation: Uses force-directed graphs or tree diagrams. Supports interactive operations: click on a parent process node to expand / collapse a child process.

[0085] Gantt chart; using scenarios to analyze the time span, parallelism, and critical path of multi-level processes. Technical implementation: based on a timeline-based Gantt chart. Colors distinguish different levels (parent / child) or states (success / failure / timeout).

[0086] Sankey diagrams; using scenarios to illustrate the flow of resources / data between processes (such as approval rates and exception transmission).

[0087] Hybrid dashboard; suitable for scenarios involving comprehensive monitoring of the health status of multi-level processes. It combines various components, such as a combined topology diagram (global malicious relationships), Gantt chart (time analysis), and indicator cards (e.g., timeout rate, completion rate). Adding dynamic interactive features during display enhances the user experience, supporting the following interactions: Drill-down: Click on the parent process to view details of its sub-processes. Filtering: Dynamically update the view by time range, status, or level. Anomaly marking: Automatically highlight timeout / failure process nodes in red.

[0088] Further reference Figure 3 As an implementation of the methods shown in the above figures, this disclosure provides an embodiment of a data model construction apparatus, which is similar to... Figure 1 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0089] like Figure 3 As shown, the data model construction apparatus 300 provided in this embodiment includes: an acquisition unit 301, a obtaining unit 302, a marking unit 303, and a generation unit 304. The acquisition unit 301 can be configured to acquire multiple event log information. The obtaining unit 302 can be configured to perform multi-level division of activities in the event log information to obtain multiple hierarchical log tables. The marking unit 303 can be configured to perform event hierarchical marking on the hierarchical log tables to obtain hierarchical marking results. The generation unit 304 can be configured to generate a data model based on the hierarchical marking results.

[0090] In this embodiment, the specific processing of the data model construction device 300, including the acquisition unit 301, the obtaining unit 302, the marking unit 303, and the generation unit 304, and their resulting technical effects, can be found in reference to [reference needed]. Figure 1 The relevant descriptions of steps 101, 102, 103, and 104 in the corresponding embodiments will not be repeated here.

[0091] In one embodiment of this disclosure, the aforementioned obtaining unit 302 is further configured to: divide the activities in the event log information into multi-level nodes; for each activity in each level node, obtain the activity data of the activity from the event log information; and fill the activity data of the activity into the table corresponding to the level node according to the level node corresponding to the activity, thereby obtaining multiple level log tables.

[0092] In one embodiment of this disclosure, the aforementioned obtaining unit 302 is further configured to: cluster different types of activities in the event log information to obtain clustering results; determine the level to which each activity in the event log information belongs based on the clustering results; obtain activity data of activities at each level; and fill the activity data of activities at each level into the table corresponding to each level to obtain multiple level log tables.

[0093] In one embodiment of this disclosure, the apparatus further includes a clustering unit configured to: filter activity data belonging to a project type in event log information; for at least one project stage, detect the project stage to which the activity data of each activity belongs, and classify each activity into the corresponding project stage; identify a corresponding level for at least one project stage, and determine the level to which each activity in the event log information belongs.

[0094] In one embodiment of this disclosure, the marking unit 303 is further configured to: mark the level of each level log table in multiple level log tables using the event level of different level activities, and obtain the level marking result.

[0095] In one embodiment of this disclosure, the generation unit 304 is further configured to: associate multiple hierarchical log tables according to the order of hierarchical representation in the hierarchical labeling results, and construct a data model based on the associated hierarchical log tables.

[0096] In this embodiment of the data model building apparatus provided by the present disclosure, firstly, the acquisition unit 301 acquires multiple event log information; secondly, the obtaining unit 302 divides the activities in the event log information into multiple levels to obtain multiple level log tables; then, the marking unit 303 marks the level log tables by event level to obtain level marking results; finally, the generation unit 304 generates a data model based on the level marking results.

[0097] Further reference Figure 4 As an implementation of the methods shown in the above figures, this disclosure provides an embodiment of a multi-level process mining device based on event logs. This device embodiment is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0098] like Figure 4As shown, the multi-level process mining device 400 based on event logs provided in this embodiment includes: a request unit 401, a determination unit 402, and a result unit 403. The request unit 401 is configured to obtain a process query request from the event log. The determination unit 402 is configured to determine the process data to be queried based on the process query request. The result unit 403 is configured to obtain multi-level process mining results from a data model based on the process data to be queried, wherein the data model is constructed using the data model construction method of the first aspect of this disclosure.

[0099] In this embodiment, the specific processing of the request unit 401, the determination unit 402, and the result unit 403 in the data model construction apparatus 400, and the resulting technical effects, can be referred to respectively. Figure 2 The relevant descriptions of steps 201, 202, and 203 in the corresponding embodiments will not be repeated here.

[0100] In one embodiment of this disclosure, the apparatus further includes a display unit configured to display multi-level process mining results using at least one of a variety of display methods.

[0101] In this embodiment of the multi-level process mining apparatus based on event logs provided by the present disclosure, firstly, a request unit 401 obtains a process query request from the event log; a determination unit 402 determines the process data to be queried based on the process query request; and a result unit 403 obtains the multi-level process mining results from the data model based on the process data to be queried, wherein the data model is constructed using the data model construction method of the first aspect of the present disclosure. Therefore, this method provides a complete solution for the field of process mining, from data preparation to knowledge extraction, and is particularly suitable for complex business scenarios requiring multi-level process insights.

[0102] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0103] Figure 5 A schematic block diagram of an example electronic device 500 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their patterns are merely examples and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0104] like Figure 5 As shown, device 500 includes a computing unit 501, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 502 or a computer program loaded into random access memory (RAM) 503 from storage unit 508. RAM 503 may also store various programs and data required for the operation of device 500. The computing unit 501, ROM 502, and RAM 503 are interconnected via bus 504. Input / output (I / O) interface 505 is also connected to bus 504.

[0105] Multiple components in device 500 are connected to I / O interface 505, including: input unit 506, such as keyboard, mouse, etc.; output unit 507, such as various types of monitors, speakers, etc.; storage unit 508, such as disk, optical disk, etc.; and communication unit 509, such as network card, modem, wireless transceiver, etc. Communication unit 509 allows device 500 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0106] The computing unit 501 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 501 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 501 performs the various methods and processes described above, such as the data model building method. For example, in some embodiments, the data model building method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 508. In some embodiments, part or all of the computer program may be loaded and / or installed on device 500 via ROM 502 and / or communication unit 509. When the computer program is loaded into RAM 503 and executed by the computing unit 501, one or more steps of the data model building method described above may be performed. Alternatively, in other embodiments, the computing unit 501 may be configured to perform the data model building method by any other suitable means (e.g., by means of firmware).

[0107] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0108] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to the processor or controller of a general-purpose computer, special-purpose computer, or other programmable data modeling apparatus, such that when executed by the processor or controller, the program code causes the patterns / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0109] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0110] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0111] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0112] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0113] The foregoing description of specific exemplary embodiments of the invention is for illustrative and explanatory purposes. These descriptions are not intended to limit the invention to the precise forms disclosed, and it will be apparent that many changes and variations can be made in accordance with the foregoing teachings. The exemplary embodiments were chosen and described in order to explain the specific principles of the invention and its practical application, thereby enabling those skilled in the art to implement and utilize various different exemplary embodiments of the invention, as well as various different choices and variations. The scope of the invention is intended to be defined by the claims and their equivalents.

Claims

1. A data model construction method, characterized in that, The method includes: Obtain multiple event log information; the event log information includes at least one of the following: activity identifier, parent activity primary key, and child activity primary key; Based on the hierarchical relationship between the parent activity primary key and the child activity primary key, the event log information is traversed to form a tree-structured hierarchical data. Then, the data at each level of the tree-structured hierarchical data is traversed again, and activity nodes of the same event stage are assigned to the corresponding level of activity hierarchy data, resulting in multiple hierarchical log tables. Each hierarchical log table corresponds to a project stage, which includes at least one of the following: project initiation stage, implementation stage, and acceptance stage. A semantic recognition model is used to identify the project type to which the event log information belongs, and the project stage of the event log information is determined based on the project type. Event hierarchy marking is performed on the multiple hierarchical log tables to obtain hierarchical marking results, which include the mapping relationship between hierarchical log tables and hierarchical identifiers; The data model generation based on the hierarchical labeling results includes: associating the multiple hierarchical log tables according to the order of hierarchical representation in the hierarchical labeling results; constructing a data model based on the associated hierarchical log tables; when adapting the table structure corresponding to the associated hierarchical log tables to a specific database system, obtaining historical query fields and detecting whether the historical query fields can form a process with multiple project stages; in response to detecting that the historical query fields can form a process with multiple project stages, creating multiple indexes based on the multiple project stages; wherein, creating multiple indexes based on the multiple project stages includes: for each project stage in the multiple project stages, determining the activities of each project stage, extracting an index combining any one activity of each project stage, until all activities in the multiple project stages are combined.

2. The method according to claim 1, characterized in that, The process of dividing the activities in the event log information into multiple levels to obtain multiple hierarchical log tables includes: The activities in the event log information are divided into multi-level nodes; For each activity in each level node, the activity data of that activity is obtained from the event log information; Based on the hierarchical node corresponding to the activity, the activity data of the activity is populated into the table corresponding to that hierarchical node, resulting in multiple hierarchical log tables.

3. The method according to claim 1, characterized in that, The process of dividing the activities in the event log information into multiple levels to obtain multiple hierarchical log tables includes: Clustering different types of activities in the event log information yields clustering results; Based on the clustering results, the level to which each activity in the event log information belongs is determined; Obtain activity data for activities at each level; The activity data of each level is populated into the corresponding table of each level to obtain multiple level log tables.

4. The method according to claim 3, characterized in that, The clustering results include: project type and at least one project phase. Determining the hierarchy of each activity in the event log information based on the clustering results includes: Filter the event log information for event data belonging to the project type; For at least one project phase, detect the project phase to which the activity data of each activity belongs, and classify each activity into the corresponding project phase; Identify the corresponding level for the at least one project phase and determine the level to which each activity in the event log information belongs.

5. The method according to claim 1, characterized in that, The process of performing event hierarchy marking on the multiple hierarchical log tables to obtain the hierarchy marking results includes: By using the event level of different activity levels, the level of each log table in the multiple level log tables is marked, and the level marking result is obtained.

6. A multi-level process mining method based on event logs, the method comprising: The process of retrieving event logs is a query request; Based on the process query request, determine the process data to be queried; Based on the process data to be queried, multi-level process mining results are obtained from the data model, wherein the data model is constructed using the data model construction method described in any one of claims 1-5.

7. A data model construction apparatus, characterized in that, The device includes: The acquisition unit is configured to acquire multiple event log information; the event log information includes at least one of activity identifier, parent activity primary key, and child activity primary key. The unit is configured to traverse the event log information based on the hierarchical relationship between the parent activity primary key and the child activity primary key, forming a tree-structured hierarchical data; it then traverses each level of the tree-structured hierarchical data again, assigning activity nodes of the same event stage to the corresponding level of activity hierarchy data, resulting in multiple hierarchical log tables. Each hierarchical log table corresponds to a project stage, which includes at least one of the following: project initiation stage, implementation stage, and acceptance stage; wherein, a semantic recognition model is used to identify the project type to which the event log information belongs, and the project stage of the event log information is determined based on the project type. The tagging unit is configured to perform event-level tagging on the multiple hierarchical log tables to obtain hierarchical tagging results, the hierarchical tagging results including the mapping relationship between hierarchical log tables and hierarchical identifiers; The generation unit is configured to generate a data model based on the hierarchical labeling results; the generation unit is further configured to: associate the multiple hierarchical log tables according to the order of hierarchical representation in the hierarchical labeling results, construct a data model based on the associated hierarchical log tables, and when adapting the table structure corresponding to the associated hierarchical log tables to a specific database system, obtain historical query fields and detect whether the historical query fields can form a process with multiple project stages; in response to detecting that the historical query fields can form a process with multiple project stages, create multiple indexes based on the multiple project stages; wherein, creating multiple indexes based on the multiple project stages includes: for each project stage in the multiple project stages, determining the activities of each project stage, extracting any one activity combination index of each project stage, until all activities in the multiple project stages are combined.

8. A multi-level process mining device based on event logs, characterized in that, The device includes: The request unit is configured as a process query request to retrieve event logs; The determining unit is configured to determine the process data to be queried based on the process query request; The result unit is configured to obtain multi-level process mining results from the data model based on the process data to be queried, wherein the data model is constructed using the data model construction apparatus of claim 7.

9. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-6.

10. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-6.

Images