Structure of transformations

概述

以下是Process Mining应用程序模板的转换步骤概述。

models\文件夹是根据转换步骤的结构进行组织的。

1. 输入

输入步骤用于加载原始数据。 通常会执行以下操作，为下一个转换步骤准备数据：

• 选择具有可选宏和必选宏的字段。 使用可选宏时，原始数据中不需要存在字段。
• 将字段类型 转换为适当的数据类型。

• 在转换的早期筛选 表以减少数据大小。

注意： 建议尽可能减少提取中已存在的数据大小。

命名约定

如果您预计名称会在接下来的转换步骤中与表格名称冲突，最佳实践是为输入表添加后缀_input 。

可选字段

连接器的输入包含必填数据和可选数据。 对于可选字段，应使用 pm-utils 包中的 optional 宏。 这可确保字段在源数据中不可用时获取值 null 。 这样，所有转换都将正常运行。

• 如果整个表格都是可选的，请使用 optional_table() 宏。

2. 实体

在实体步骤中，输入表将转换为实体表。 预期事件所需的每个实体应具有自己的表格。 请参阅设计事件日志。 此外，支持实体也可以在此处定义。

在下面的示例中，将 3 个输入表Invoices_input 、 Invoice_types_input和Customers_input联接在一起以创建实体表 Invoices。

准则

创建实体表时，请遵循以下准则。

• 有一个实体 ID 字段，该字段对于每个数据记录都是唯一的。
• 数据分析所需的所有实体字段均已存在。
• 所有实体字段都具有易于理解的名称。

如果适用，实体表将通过 ID 字段与另一个实体相关联。 请参阅下面的示例，其中发票行通过Invoice_ID字段与发票实体相关联。

Additional transformations

并非所有输入表都转换为实体表。 此外，其他输入表可能包含相关信息，例如示例中的“客户”表。 在实体步骤中将它们定义为单独的表格可能会很方便，以便可以在数据转换中重用它们。

命名约定

如果实体表名称日后会导致名称冲突，请在表中添加后缀 _base。

3. 事件

注意：事件日志和自定义流程应用程序模板的输入已经是 Process Mining 定义良好的事件日志。 无需在此处将源系统中的数据转换为 Process Mining 的事件。 这意味着事件日志应用程序和自定义流程应用程序的转换中不存在3. events 。

在此转换步骤中，将为每个实体创建事件表。 请参阅设计事件日志。 事件表中的每条记录代表发生的一个事件。 关于数据的结构化方式，有两种情况：

• 时间戳字段: 实体表上具有事件时间戳的字段。 例如， Invoices表中的Invoice_created字段。
• 事务日志：事件列表。

根据数据的结构，用于创建事件表的转换会有所不同。

Timestamp fields

在这种情况下，时间戳字段的值必须转换为事件表中的单独记录。 以下示例是包含三个时间戳字段的发票表格。

每个时间戳字段用于创建单独的事件表。 对于时间戳字段包含值的每条记录，请创建一个表格，其中包含发票 ID、事件名称（活动）和事件发生的时间戳（事件结束）。

Invoices_input table分为Invoice_events_Create_invoice 、 Invoice_events_Delete_invoice和Invoices_events_Change_invoice_price 。

然后，可以将单独的事件表合并到每个实体的单个事件表中，例如Invoices_events 。

事务日志

如果事件存储在事务日志中，则应标识每个实体的相关事件。 为每个实体创建一个表，并存储相应的实体 ID、事件名称 (Activity) 以及事件发生的时间戳 (Event end)。

在以下示例中，事务日志包含 采购订单 和 发票 实体的事件。

在事件表中，以下字段为必填字段。 事件表中的所有记录都应包含这些字段的值。

字段	描述
实体 ID	发生事件的实体的 ID。 例如， 发票 ID。
活动	该活动描述了对实体执行的操作。
Event end	“事件结束”字段指示特定事件的完成时间。 理想情况下，这应该是日期时间字段，而不是日期。

命名约定

根据 [Entity] + _events结构命名表。 例如 Purchase_order_events和Invoice_events 。

4. 事件日志

单个实体流程

当流程包含一个实体时，此步骤不需要其他转换。 单个实体表和事件表的格式已正确。

多实体流程

当一个流程涉及多个实体时，所有实体的事件都需要链接到流程中被视为“案例”的主要实体。 请参阅定义事件日志。 以下步骤描述了如何将所有事件与主要实体相关联，以及如何将它们合并到单个事件日志中。

Entity relations

创建“实体关系”表以集中所有实体之间的关系。 此实体关系表将包含相关实体的 ID 字段。

要创建实体关系表，请根据 ID 字段联接所有实体表：

• 从主要实体开始
• 使用左联接将相关实体联接到主实体。
• 如果实体与主实体不直接相关，则将实体左联接到已联接到主实体的相关实体。

在以下示例中，存在三个实体： 采购订单、发票行和 发票。 采购订单 被视为流程中的主要实体。 发票行 直接链接到 采购订单 ， 发票 通过 发票行间接链接。

以下是生成的实体关系表。

Relation tables

使用实体关系表中的组合信息，将主实体和每个其他实体之间的单个关系存储在单独的表中。

事件日志

下一步是使用这些关系向每个事件表添加相应的“案例 ID”。 “案例 ID”是通过关系表获取的，其中事件信息是从事件表中获取的。 要创建完整的事件日志，请合并每个实体的事件表。

命名约定

如果事件日志表名称可能导致日后出现名称冲突，请在事件日志表的名称中添加后缀_base 。

5. 业务逻辑

在最后一个转换步骤中，根据需要添加业务逻辑以进行数据分析。 可以在此处将其他派生字段添加到现有表格中。 例如，在仪表板的 KPI 中使用的特定吞吐量时间或布尔值字段。

在 Process Mining中，此转换步骤中定义了两个额外的标准表： Tags和Due dates 。

标签

标签是案例的属性，表示某些业务规则。 通常添加标签是为了便于分析这些业务规则。 例如：

• 由同一人支付和批准的发票。
• 发票审批时间超过 10 天。
• 已跳过检查发票活动。

标签表中的每条记录都代表特定案例的数据中出现的一个标签。 此表格的必填字段为“案例 ID”和“标签”。 并非所有案例都有标签，有些案例可能有多个标签。 以下是“标签”表格示例。

到期日期

截止日期表示流程中的截止日期。 这些活动将添加到数据中，以分析活动是否在这些截止日期按时执行。

到期日期表中的每条记录代表特定事件的一个到期日期。到期日期示例如下：

• 付款事件的付款截止日期。
• 批准事件的批准截止日期。

此表的必填字段为 Event ID、Due date、Actual date 和 Expected date。

并非所有活动都有截止日期，有些活动可能有多个截止日期。