Generation and visualization of object-centered data model graphs
The method generates a hierarchical graph layout for object-centered data models, addressing the complexity of large-scale object relationships by minimizing overlaps and facilitating efficient exploration and analysis.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- セロニス ソシエタス ヨーロッパ
- Filing Date
- 2024-05-23
- Publication Date
- 2026-06-30
AI Technical Summary
Existing object-centered data models in process mining are difficult to manage due to the large number of objects and events, making it challenging to maintain an overview and evaluate relationships between them effectively.
A method for generating a graph layout that represents an object-centered data model, where each object type is a node and relationships are edges, arranged hierarchically to minimize overlaps and allow for efficient exploration and editing.
The method provides a compact and resource-efficient representation of the process landscape, enabling users to easily navigate and analyze complex data models by minimizing edge and node overlaps, supporting detailed views and exploratory searches.
Smart Images

Figure 2026521345000001_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of process mining, and in particular to generating and visualizing a graph layout for representing an object-centered data model of process data.
Background Art
[0002] Processes are executed everywhere and at any time. A process includes several process steps, and by executing these process steps, a process instance, also called a case, is generated. Today, many processes are monitored, and process steps are usually recorded together with some properties.
[0003] By introducing an object-centered data model, the recorded process data can be transformed into a configuration that accurately maps the concept of actual process execution, and thus can be easily perceived especially by users who are not database engineers. Therefore, the object-centered data model facilitates the discovery of an appropriate process model.
[0004] The object-centered data model can be achieved by mapping the recorded process data to the objects involved in the execution of the process steps and the events occurring to these objects. This notation allows one object to be related to multiple events and / or to further objects.
[0005] In real-world processes, it can be manufacturing of products, cooking of dishes, teaching of courses, ordering of items, air traffic control, etc., but usually a large number of objects are involved in the process and thus constitute part of the data model. Therefore, in practice, it is very difficult to hold an overview over the entire process landscape recorded in the data model and evaluate the relationships between objects as well as between objects and events.
[0006] For example, when manufacturing an automobile, the objects in the data model may represent the parts of the automobile being manufactured and the tools used for them, while the events in the data model may represent the steps performed for each part or using each tool. It may be possible to separate the data model for each (major) part of the car into several smaller data models, but such separation lacks consistency / relationships between these parts, even though these parts are strongly dependent on each other during the manufacture of the car. Therefore, it should also be possible for the user to interact with a data model that contains the process data for the manufacture of the entire automobile, but such a data model would contain a large number of objects and events, ranging from hundreds to thousands of objects. [Overview of the project]
[0007] Therefore, an object of the present invention is to provide a method for representing an object-centered data model so that users can evaluate and extend the data model as efficiently as possible. [Means for solving the problem]
[0008] This objective is addressed by the computer implementation method described in independent claim 1. Advantageous embodiments and variations are described in their respective dependent claims.
[0009] Therefore, a method is provided for generating a graph layout for a data model of process data. The data model is object-centric and includes several object types, each of which is a set of object instances involved in the execution of several process steps recorded in the process data, each of which includes many inter-object relationships that connect two of each respective object type.
[0010] This delicious, - For each object type, query the data model for a list of identifiers and inter-object relationships, - Representing each object type as a node on the visualization device's canvas, which brings up several nodes, -On the canvas, each relationship between objects is represented as an edge connecting two nodes that represent the object type of each relationship, - To generate a hierarchy containing a predetermined number of levels distributed along a first direction of the canvas, -Generating several node positions for each level, where the node positions are distributed along a second direction of the canvas, - Assigning each node to a node position at a level of the hierarchy, according to the order of nodes determined based on how the nodes connected to each node are assigned, - This includes generating a graph layout by arranging nodes on the canvas according to the order of nodes at each level of the hierarchy, such that the overlap between edges connected to each node and further edges and further nodes is minimized.
[0011] In an object-centered data model, an object is a digital representation of someone or something that exists in the real world and is connected to an executed process. For example, a customer, a company, an order, a tool, or an invoice. For each object, individual object instances are involved during the execution of the recorded process.
[0012] Each object instance is characterized by several properties, which are defined by a standardized definition called an "object type." For example, the object type "invoice" may have the property "currency," or the object type "drill" may have the properties "diameter" and "current." Thus, an object type contains definitions that each object instance must satisfy in order to be assigned to that object type. In some cases, no object instances may be assigned to an object type, resulting in an empty collection. In a data model, each object type can be represented as a relational table that stores the associated object instances in its rows.
[0013] Object types are stored in a data model, and their identifiers may be queried from there in accordance with the present invention to generate a graph layout. Similarly, relationships between object types are stored in the data model and can be directly derived from the data model. When a query is made, the data based on the construction of the graph may be stored in a data structure in the server's volatile memory, for example, in cache memory. This data structure may include a first attribute where each identifier is stored, a second attribute where the relationships between objects, including each object type, can be stored, and further attributes where tags assigned to each object type, properties of each object type, and further information can be stored.
[0014] An object type identifier may be a unique name. The properties of an object type include several attributes or fields that specify an object instance. In other words, the properties of an object type define which object instances can be assigned to that object type. For example, an object instance with attributes different from those required by the properties of a particular object type cannot be assigned to that particular object type.
[0015] This method has the advantage of representing all object types in a data model in a single graph layout, thereby representing a digital twin of the process landscape. Nodes in the graph are connected by edges, with overlap between edges and between edges and nodes kept as low as possible. While the generated graph may appear informational at first glance, considering the usual large number of object types, this particular arrangement of nodes allows the user to evaluate the graph at any desired detail while always maintaining the overall location of nodes of interest within the generated graph layout. The user can, for example, zoom to different areas of the graph layout.
[0016] The order of nodes within each level of the hierarchy can be chosen to minimize the number of edge intersections / overlaps. The number of edge intersections can be determined by a brute-force computation that samples all possible orderings of nodes within each level. In some examples, especially for a large number of nodes, the problem of minimizing the number of edge intersections can be mapped to an optimization problem that can be solved approximately. In these examples, it is not necessary to sample all possible combinations of node orderings, but only the number of combinations required for the optimization method to converge.
[0017] The hierarchy can be aligned from top to bottom along the first direction of the canvas.
[0018] An essential advantage of the method according to the present invention is that nodes connected to one another tend to be placed in close proximity to one another. As a result, the user can focus on different consecutive sections of the entire graph layout. This advantage generally arises from a combination of hierarchical arrangement of nodes under the constraints of low edge-to-edge overlap and low edge-to-node overlap, as the number of overlaps can be minimized by minimizing the length of edges in the graph layout.
[0019] The graph layout is generated once based on the queried object types and the relationships between those objects, and can then be explored without needing to recalculate the graph data. As a result, analysis of the generated graph is highly resource-efficient, as no further queries to the data model or additional calculations of the graph layout are required.
[0020] The generated graph layout can then be rendered on the canvas of a visualization device.
[0021] Preferably, the first direction is the first principal direction of the canvas, particularly the vertical direction, and the second direction is the second principal direction of the canvas, particularly the horizontal direction.
[0022] Aligning the nodes of a graph along the two vertical axes of the canvas, each characterized by its respective principal direction, has the advantage of achieving a hierarchical grid-like graph structure. As a result, the nodes can be distributed more evenly across the canvas, so that the complete graph as a whole can be represented on the canvas of a visualization device.
[0023] The number of hierarchical levels and the number of node positions on each level can be determined according to predetermined parameters that define at least one of the compactness and / or width of the graph layout. Compactness defines how far and how densely the levels are distributed along a first direction, particularly the vertical direction. Width defines how far the node positions extend along each level, i.e., in a second direction, particularly the horizontal direction.
[0024] Preferably, the method - for each object type, querying a tag, where the tag represents a cluster of object types in the data model, querying the tag, - editing the tag, and - storing the edited tag of the object type in the data model.
[0025] By interacting with the graph, the user can also edit the object type, and the edited object type is inserted into the data model. Each value stored in the attributes of the data structure of the queried object type can be edited, for example, like a tag. Further, the relationships between objects and the properties of object types can be edited. This feature enables the user to adapt the object types of the graph structure.
[0026] When an object type is edited, the graph layout may need to be recalculated and regenerated.
[0027] Preferably, the method - providing filter conditions for filtering object types, particularly on tags, - for each object type, performing a test regarding the filter conditions using its previously queried data, - in the generated graph layout, disabling all nodes representing object types that failed the test and the edges connected thereto, and - This further includes generating an updated graph layout by arranging the remaining nodes on the canvas according to the hierarchy.
[0028] Filter conditions have the advantage of allowing the graph size to be reduced according to user needs. In this case, setting the filter conditions changes the number of nodes and edges, requiring the graph layout to be redrawn and recalculated. However, the object type data does not need to be queried again from the data model and can be accessed directly from the data structure in the server's volatile memory. Filter conditions may represent the names of process model types, such as "Order to cash" or "Accounts receivable," or they may be based on tags that can distinguish between custom object types and standardized object types.
[0029] Preferably, this method - For each object type, query properties that include several attributes that characterize the object type, - Editing properties, and - This further includes storing edited properties of object types in the data model.
[0030] Object type properties provide search criteria for identifying corresponding object instances within recorded process data. By editing properties, even new object types can be generated and stored in the data model. Object type properties also include transformations applied to convert raw data stored in the source system into defined object types.
[0031] More preferably, this method - Use search terms to search for at least one specific object type, - Identifying at least one node representing at least one specific object type that has been searched, and all further nodes representing object types that are directly connected to one of the specific object types that has been searched via their respective inter-object relationships, and -Further includes highlighting the identified node and its inter-object relationships relative to all other nodes, thereby ensuring that the highlighted subgraph appears within a continuous section of the generated graph layout.
[0032] Highlighting identified nodes may involve zooming and / or panning the graph layout to the identified nodes and their edges. This search function can be performed on the generated graph layout without requiring any rearrangement of the graph layout. For a given object type in the data model, the graph is generated such that clusters of nodes appear that occupy consecutive sections of the graph layout. When a particular object type is searched, nodes representing that object type and all of its related nodes linked by inter-object relationships are highlighted, resulting in highlighted clusters within encapsulated consecutive sections of the graph. Highlighting may also involve darkening all irrelevant nodes and edges.
[0033] Preferably, this method - Generate a list of search results that include all object types that match the search term, with at least one parameter matching the search term. - To represent a list of search results within the generated graph layout, and - Further includes identifying at least one node by selecting a specific search result.
[0034] This feature enables exploratory searching of object types in the generated graph layout. The list of search results may include object types whose names at least partially match the search string / term, object types associated with tags that match the search term, and inter-object relationships where the name of at least one object type at least partially matches the search term. Thus, the list of search results can actually be quite long. By representing the list of search results alongside the generated graph, the list can be used as a handle for exploratory iteration of the graph.
[0035] Preferably, at least one parameter is - Identifier and, - Tags and, -Properties, and -It is at least one of the groups consisting of those combinations and .
[0036] Preferably, this method - Creating custom object types by specifying or editing a list of identifiers and / or tags and / or properties and / or inter-object relationships, and - Further includes storing a list of specified or edited identifiers and / or tags and / or properties and / or inter-object relationships in the data model.
[0037] Preferably, the graph layout is - Essentially represented by a rectangle and labels placed on the first side of the rectangle, where the labels represent the names of each object type, for each node, and -Generated by displaying each edge, which is essentially represented by lines that start and end orthogonally on the edges of each node, excluding the first edge of each node.
[0038] More preferably, the graph layout is generated by arranging each line representing each edge in a way that avoids irrelevant nodes and any labels.
[0039] The constraint that each line representing an edge must start and end orthogonally on the edge of each node, excluding the edge where the node label is placed, along with the constraint that each line avoids irrelevant nodes and arbitrary labels, results in a clear and easy-to-read graph layout.
[0040] In some embodiments, the data model is preferably, -Several event types, where each event type is a collection of event instances that are part of several process steps recorded in the process data, -Includes several event-object relationships that unidirectionally link each event type to its respective object type, Furthermore, this method includes querying a list of tags, properties, and event-object relationships for each event type.
[0041] An event is a digital representation of a real-world occurrence that occurred at a single point in time for one or more objects connected to a process landscape. For example, an invoice is paid, a user places a purchase order for a vendor's product, a customer places an order, an order is shipped, vegetables are cut in the cooking process, or holes are punched in the manufacturing process. Each event, also called a process step, creates or adds something to an object, or changes one or more properties of the object included in the event. Thus, events can be identified and created based on the object's timestamp and several change meta-objects linked to them. Changes to an object can be stored in a separate table in the data model, also called a change meta-object. For example, the event "Price Change" may be determined from the attributes / fields "NewValue" = 19.99 and "OldValue" = 14.99 of the associated change meta-object.
[0042] In this context, each event instance is characterized by several properties, which are defined by a standardized definition called an "event type."
[0043] Each event type is associated with one or more object types, represented by so-called event-object relationships. When event types and their relationships are queried, the event-object relationships may be stored as further attributes of the underlying data structure of the object types in the graph. Thus, event types become accessible as search parameters, particularly through event-object relationships.
[0044] Preferably, the labels include a count of the event types associated with each object type.
[0045] This feature has the advantage of allowing users to identify at a glance how many event types an object type is associated with. The more event types an object type is associated with, the more critical the object is in terms of process throughput time. Therefore, the event type count can provide promising directions for subsequent analysis of process data. Furthermore, since the more event types an object type is associated with, the greater the impact of changes in the properties of that object type, the event type count can serve as an important risk indicator for data engineering.
[0046] Preferably, this method - Search for at least one object type through event types and / or event-object relationships, - Identifying at least one node representing at least one specific object type that was searched, and - This further includes highlighting identified nodes in relation to all object relationships and all other nodes within the generated graph layout.
[0047] Preferably, this method - Create custom event types by specifying or editing a list of identifiers and / or property tags and / or event-object relationships, and - Further includes storing a list of specified or edited identifiers and / or tags and / or properties and / or event-object relationships in the data model.
[0048] As a result of these features, the data model can be explored in a similar way to object types, and event types can be extended with custom and / or edited event types, which allows for maximum flexibility in working with the data model. [Brief explanation of the drawing]
[0049] Exemplary embodiments of the method according to the present invention, as well as several aspects of the present invention, will be described in detail below in conjunction with the drawings. [Figure 1] Figure 1 is a graph layout of the overall process landscape generated according to the present invention. [Figure 2a] Figure 2a is a snapshot captured while searching the graph layout of Figure 1 for a first specific object type. (Option 2) [Figure 2b] Figure 2b shows a snapshot captured while searching the graph layout in Figure 1 for a second specific object type. [Figure 3] Figure 3 shows zoomed-in and panned views of the network of identified nodes in Figure 2b. [Figure 4] Figure 4 shows zoomed-in and panned views of nodes identified by searching for a specific event type. [Figure 5]Figure 5 shows a graph layout generated after filtering a custom object type according to one aspect of the present invention. [Figure 6] Figure 6 is a flowchart of one embodiment of the method according to the present invention. [Modes for carrying out the invention]
[0050] Real-world processes are often very complex because they involve the interaction of several object instances, each assigned to an object type. Object types may be related in one-to-many and / or many-to-many connections, resulting in a process landscape that can be overwhelming and difficult to understand.
[0051] Therefore, process landscapes are typically divided into different parts before they are represented and analyzed.
[0052] In contrast, according to the present invention, all object types in an object-centered data model can be queried and cached in a data structure. By representing object types as nodes and inter-object relationships as edges connecting the nodes, a very compact representation of the business process landscape becomes possible. Event types, which describe changes applied to instances of object types, are rather held behind the scenes of the graph layout, but it should be noted that this means that event types are not explicitly represented in the graph layout. Event types are stored by event-object relationships in the cached data structure of each object type and can be represented in an aggregated manner by an event type count associated with each object type.
[0053] Despite prioritizing the representation of object types over event types, the resulting graph layout for the real-world process landscape consists of so many nodes and edges that the overall view is more like a bird's-eye view where details can easily be missed.
[0054] Figure 1 shows a graph layout generated according to the present invention for the overall process landscape.
[0055] The graph in Figure 1 summarizes the complete data model of a business into a single graph. Similarly, the complete data model of a product, such as an automobile, can be summarized and represented in a similar graph according to the method of the present invention.
[0056] Node 11 may be represented by a rounded square, and edge 12 may be represented by a line with an arrow. The size of the square may be predetermined and taken into consideration when generating node positions, as a larger node size means fewer nodes can be placed at each level of the hierarchy.
[0057] Graph layout 1 is structured with several levels 21 of a hierarchy 20 stacked on top of each other in the vertical direction V of canvas 10. In the example in Figure 1, the hierarchy includes eight levels, as indicated by the horizontal line on the right. Furthermore, the nodes 11 assigned to each level 21 are ordered such that the number of overlaps / intersections between edges 12 is minimized. Due to the constraint that each line representing an edge 12 must end and begin at a right angle on each node 11, overlaps of edges 12 with nodes 11 are completely avoided.
[0058] The arrows on each edge 12 represent the direction of the relationship between the objects. In the example in Figure 1, all object relationships are bidirectional. This example includes one-to-one, one-to-many, and many-to-many object relationships. Thus, the resulting graph is quite complex to read and understand, but it summarizes the complete process landscape of the business and is therefore sometimes called a digital twin of the business. Similarly, a digital twin of the process landscape of a factory can be generated as a graph according to one aspect of the present invention.
[0059] The central idea of this invention will become clear by elucidating the exploratory search capabilities of graph layout 1.
[0060] Figure 2a is a snapshot captured while searching the graph layout in Figure 1 for a specific object type, "SalesOrder".
[0061] Figure 2b is a snapshot captured while searching the graph layout in Figure 1 for a specific object type, "PurchaseOrder".
[0062] In all cases, the graph layout 1, i.e., the arrangement of edges 11 and nodes 12, is the same as graph layout 1 in Figure 1, but the specific object type 30 found is highlighted. Along with the specific object type 30 found, the inter-object relationships connected to each specific object type 30, and the object types connected to each specific object type through the inter-object relationships are also highlighted.
[0063] The highlighting of search results in the examples of Figures 2a and 2b is achieved by dimming all edges 12 and nodes 11 that are not related to the specific object type 30 being searched. Dimming nodes 11 and edges 12 is highly efficient because it requires modifying essentially only one parameter of the appearance of each node 11. In all other embodiments, the entire graph layout 1 can be preserved.
[0064] Two examples of the specific object type 30 that were searched highlight the functional features of the generated graph layout 1 for later analysis. Each node 11 representing an object type is positioned so that its directly related nodes 11 are located in close proximity. Thus, highlighting the searched nodes together with their related nodes always results in a contiguous section of graph layout 1. In other words, the highlighted nodes are not scattered throughout graph layout 1, but are initially positioned so that each search can focus on a specific section of the graph or subgraph, i.e., a part of the data model.
[0065] In Figure 2a, the highlighted consecutive sections appear in the lower left of Graph Layout 2. In contrast, in Figure 2b, the highlighted consecutive sections appear in the lower right of Graph Layout 2 and are even more compact than the individual sections highlighted in Figure 2a.
[0066] Figure 3 shows zoomed-in and panned views of the network of identified nodes in Figure 2b.
[0067] Highlighting specific object types found within Graph Layout 1 can also involve zooming and panning to each section of the graph. Note that Graph Layout 1 itself remains unchanged; only the view is rearranged to better focus on the identified nodes along with their associated nodes.
[0068] The search term 13 may be entered into an input field which may be placed on the canvas. The search term 13 can be matched with names of object types, tags, event types, inter-object relationships, and event-object relationships to generate a list of search results 14. The list of search results 14 may be displayed as a pop-down menu in the search input field and may remain open for exploratory searching of the graph until the user actively closes the search results 14.
[0069] The user can further select individual nodes 11 in the graph. In the example in Figure 3, node 11 representing the searched object type "PurchaseOrder" is selected, resulting in a pop-up window displaying detailed information about the object type. The pop-up window for the object type "PurchaseOrder" is located at the right edge of the canvas in the example in Figure 3, and it delves into the object type details of the searched object type.
[0070] The popup window may represent values stored in the data structure of each object type. In the example in Figure 3, the popup window includes tags 16 such as "AccountSWeetable", "OrderToCash", or "PurchaseToPay". Furthermore, the popup window may include a list of object transformations 17 which are properties of the object type. In the example in Figure 3, the list of object transformations is empty. Furthermore, the popup window may include a list of associated events and / or objects and a list of object type properties 17. In the example in Figure 3, the object type "PurchaseOrder" is associated with 27 event types, resulting in a long list of associated events, of which only the top section is shown in Figure 3.
[0071] By selecting and clicking on a specific related event type, a further pop-up window will open, allowing you to delve deeper into the event type details of the selected event type.
[0072] The pop-up window allows the user to fully explore the connections to each object type in detail.
[0073] Each node 11 can be represented by a label 18 of its respective object type and a count 19 of the event type associated with that object type.
[0074] Figure 4 shows zoomed-in and panned views of nodes identified by searching for a specific event type.
[0075] The search function can also find specific event types within Graph Layout 2. The searched event type can be identified by highlighting all nodes representing the object types associated with that event type. Therefore, users can quickly identify which object types are affected by the specific event type they found.
[0076] In the example in Figure 4, the specific event type searched for is "ChangePurchaseOrderItem," which is related to only two object types in the full graph, "PurchaseOrder" and "PurchaseOrderItem." Therefore, only the two nodes representing these two object types are highlighted relative to the other nodes and edges.
[0077] Preferably, the user can exit the highlighted view after a single-click search on the canvas.
[0078] Figure 5 shows a graph layout generated after filtering a custom object type according to one aspect of the present invention.
[0079] The example graph in Figure 5 illustrates the status of a school's process throughout the day. While the overall process is highly complex and difficult to grasp, this example focuses on the filtering functionality of graph layout 1. The filter condition 15 is set to a namespace of custom object types, significantly reducing the number of nodes 11 and edges 12 placed in the resulting graph. During filtering, the graph displays only the object types and relationships between objects that apply to the filter. Furthermore, the graph is rearranged for easier navigation.
[0080] Nodes 11 that are not subject to the filter can be disabled, for example, by changing the parameter that controls the existence of node 11. Since the graph data is never queried again and the cached data structures of the object types are never updated, the filter conditions can be applied as efficiently as possible.
[0081] According to one aspect of the present invention, custom object types and event types can be generated and stored in a data model. Therefore, custom object types are not queried from the data model first, but rather added to the data model in progress.
[0082] Further filter conditions 15 may be, for example, tags 16 or object type names.
[0083] Figure 6 shows a flowchart of one embodiment of the method according to the present invention.
[0084] The first step involves querying several object types from the data model. In a typical process landscape, an object-centric data model may contain hundreds or even thousands of object types.
[0085] Each object type includes an identifier and a list of inter-object relationships. In some embodiments, each object type further includes a list of event-object relationships. The query results for each object type may be stored, in particular, cached, in a data structure for fast lookups during exploratory searches and drill-downs into details of a particular object type.
[0086] In the second step, each object type is represented as a node and the relationships between each object as edges on the visualization device's canvas.
[0087] The third step generates a hierarchy containing a predetermined number of levels distributed along the first direction of the canvas.
[0088] In the fourth step, several node positions are generated for each level, and these node positions are distributed along a second direction on the canvas.
[0089] Therefore, the hierarchy levels and node positions provide a kind of two-dimensional grid on which nodes can be placed.
[0090] In the fifth step, each node is assigned to a node position at a level of the hierarchy, according to the node order determined based on how each node is connected to other nodes.
[0091] Nodes are iteratively assigned to node locations at different levels of the hierarchy. A node is assigned to a specific node location within a particular level, depending on the level to which the previous node connected to it is assigned.
[0092] In the sixth step, a graph layout is generated by arranging the nodes on the canvas according to the order of the nodes at each level of the hierarchy, such that the overlap between the edges connected to each node and further edges and further nodes is minimized.
[0093] Furthermore, the generated graph layout can be rendered / drawn onto the canvas of a visualization device.
[0094] Reference sign: 1. Graph layout 10 canvases 11 nodes 12 Edge 13 Search Terms 14 search results 15 Filter Conditions 16 tags 17 Properties 18 Labels 19 Event Type Count 20 layers 21 levels 22 Level Node Locations 30 Specific object types V Canvas's first orientation H Canvas's second orientation
Claims
1. A method for generating a graph layout for a data model of process data, wherein the data model is object-centered, - Several object types, where each object type is a collection of object instances involved in the execution of several process steps recorded in the process data, - Includes several inter-object relationships that connect the two respective object types, The method described above is - For each object type, query the data model for a list of identifiers and inter-object relationships, - Representing each object type as a node on the visualization device's canvas, which brings up several nodes, - On the canvas, each object relationship is represented as an edge connecting two nodes that represent the object type of each object relationship, - To generate a hierarchy including a predetermined number of levels distributed along the first direction of the canvas, - To generate several node positions for each level, wherein the node positions are distributed along a second direction of the canvas. - Assigning each node to a node position at the level of the hierarchy according to the node order determined based on how the nodes connected to each of the aforementioned nodes are assigned, A method comprising: generating a graph layout by arranging the nodes on the canvas according to the order of the nodes at each level of the hierarchy, such that the overlap between the edges connected to each node and further edges and further nodes is minimized.
2. The method according to claim 1, wherein the first direction is a first principal direction of the canvas, particularly the vertical direction, and the second direction is a second principal direction of the canvas, particularly the horizontal direction.
3. The method described above is - Querying tags for each object type, wherein the tags represent clusters of object types within the data model. - Editing the aforementioned tags, and The method according to claim 1, further comprising storing the edited tags of the object type in the data model.
4. - Providing filter conditions for filtering object types, particularly on the aforementioned tags, - For each object type, perform tests on the filter conditions using the previously queried data, - In the generated graph layout, disable all nodes and connected edges that represent object types that failed the test, and The method according to claim 3, further comprising: generating an updated graph layout by arranging the remaining nodes on the canvas according to the hierarchy.
5. The method described above is - For each object type, query the properties that include several attributes that characterize the object type, - Editing the aforementioned properties, and The method according to claim 1, further comprising storing the edited properties of the object type in the data model.
6. - Use search terms to search for at least one specific object type, - Identifying at least one node representing the at least one searched specific object type, and all further nodes representing object types that are directly connected to one of the at least one searched specific object types via the respective inter-object relationships, and The method according to any one of claims 1 to 5, further comprising: highlighting the identified node and the respective inter-object relationships with respect to all other nodes, so that the highlighted subgraph appears in a section adjacent to the generated graph layout.
7. - Generate a list of search results that include all object types in which at least one parameter matches the search term, - To represent the list of search results in the generated graph layout, and The method according to claim 6, further comprising: identifying the at least one node by selecting a specific search result.
8. The aforementioned at least one parameter is - The identifier mentioned above, - The aforementioned tags, - The aforementioned properties, and - The method according to claim 7, wherein the combination is at least one of the group consisting of the following:
9. - Creating a custom object type by specifying or editing the aforementioned identifier and / or the aforementioned tag and / or the aforementioned property and / or the aforementioned list of inter-object relationships, and The method according to any one of claims 1 to 8, further comprising storing the designated or edited list of identifiers and / or tags and / or properties and / or inter-object relationships in the data model.
10. below, -Essentially represented by a rectangle and a label placed on the first side of the rectangle, the label representing the name of each of the respective object types, each node, The method according to claim 1, wherein the graph layout is generated by representing each edge, which is essentially represented by lines that start and end orthogonally on the edges of each node, excluding each of the first edges.
11. The method according to claim 9, wherein the graph layout is generated by arranging each line representing each edge so as to avoid irrelevant nodes and arbitrary labels.
12. The aforementioned data model, - Several event types, where each event type is a collection of event instances that are part of the several process steps recorded in the process data, - Includes several event-object relationships that unidirectionally connect each event type to its respective object type, The method according to any one of claims 1 to 11, further comprising querying a list of tags, properties, and event-object relationships for each event type.
13. The method according to claim 11, wherein the label includes a count of event types associated with each of the object types.
14. - Searching for at least one object type through the event type and / or the event-object relationship, - Identifying the at least one node representing the at least one specific object type that was searched, and The method according to claim 11, further comprising highlighting the identified node with respect to all inter-object relationships and all other nodes in the generated graph layout.
15. - Creating a custom event type by specifying or editing the identifier and / or the tags of the property and / or the list of event-object relationships, and The method according to claim 11, further comprising storing in the data model a list of inter-object relationships between the designated or edited identifier and / or tag and / or property and / or event.