通知を受け取る

UiPath Process Mining

UiPath Process Mining ガイド

変換の構造

概要

UiPath Process Mining アプリ テンプレートの変換手順の概要は以下のとおりです。

580

models\ フォルダーは、変換手順の構造に従って編成されます。

307

1. 入力

入力手順を使用して生データを読み込みます。通常は、次の操作を行って、データを次の変換手順用に準備します。

  • フィールドを適切なデータ型に型キャストします。
  • テーブルをフィルター処理し、変換の早い段階でデータ サイズを減らします。

📘

注:

可能な場合は、抽出時までにデータ サイズを減らしておくことをお勧めします。

For performance reasons, it is advised to use the pm_utils.create_index(input_table) method as a pre_hook when defining the input models. For more information, see the official dbt documentation on pre-hook & post-hook.

命名規則

次の変換手順でテーブル名の競合が予想される場合のベスト プラクティスは、入力テーブルにサフィックス「 _input」を追加することです。

2. エンティティ

In the entities step, input tables are transformed to entity tables. Each entity required for the expected events should get its own table. See Designing an event log. Additionally, supporting entities can also be defined here.

In the below example 3 input tables Invoices_input, Invoice_types_input, and Customers_input are joined together to create the entity table Invoices.

621

ガイドライン

エンティティ テーブルを作成する際は、以下のガイドラインに従ってください。

  • エンティティ ID フィールドが 1 つあり、各データ レコードで一意である。
  • データ分析に必要なすべてのエンティティ フィールドが存在する。
  • すべてのエンティティ フィールドに分かりやすい名前が付いている。

これに該当する場合、エンティティ テーブルは ID フィールドを介して別のエンティティに関連しています。以下の例をご覧ください。請求書明細 (invoice_lines) は、Invoice_ID フィールドを介して請求書エンティティに関連しています。

525

その他の変換

すべての入力テーブルがエンティティ テーブルに変換されるわけではありません。また、他の入力テーブルに関連情報が含まれる場合もあります (この例では Customers テーブル)。エンティティの手順でそれらを別個のテーブルとして定義し、データ変換で再利用できるようにしておくと便利です。

命名規則

エンティティ テーブルの名前が後で競合する場合は、テーブルにサフィックス「_base」を追加します。

3. イベント

📘

注:

The input for TemplateOne-SingleFile and TemplateOne-MultiFiles app templates is already a well defined event log for Process Mining. There is no need to transform the data from the source system into the events for Process Mining here. This means that the 3. events is not present in the transformations for TemplateOne-SingleFile and TemplateOne-MultiFiles process apps.

In this transformation step, event tables are created for each entity. See Designing an event log. Each record in an event table represents one event that took place. There are two scenarios on how the data is structured:

  • タイムスタンプ フィールド: イベントのタイムスタンプが付いたエンティティ テーブルのフィールドです。たとえば、Invoices テーブルの Invoice_created フィールドです。
  • トランザクション ログ: イベントのリストです。

データがどのように構造化されているかによって、イベント テーブルを作成するための変換は異なります。

タイムスタンプ フィールド

このシナリオでは、タイムスタンプ フィールドの値をイベント テーブルの別個のレコードに変換する必要があります。以下の例は、3 つのタイムスタンプ フィールドを含む Invoices テーブルです。

452

各タイムスタンプ フィールドを使用して、別個のイベント テーブルを作成します。タイムスタンプ フィールドに値が含まれるすべてのレコードに対して、請求書 ID (Invoice ID)、イベントの名前 (Activity)、イベントが発生したタイムスタンプ (Event end) が含まれるテーブルを作成します。

413

Invoices_input table は、Invoice_events_Create_invoiceInvoice_events_Delete_invoice、および Invoices_events_Change_invoice_price に分割されます。

その後、別個のイベント テーブルをエンティティごとに 1 つのイベント テーブルにマージできます (例: Invoices_events)。

トランザクション ログ

イベントがトランザクション ログに保存されている場合は、エンティティごとの関連イベントを特定する必要があります。エンティティごとのテーブルを作成し、対応するエンティティ ID、イベントの名前 (Activity)、イベントが発生したタイムスタンプ (Event end) を格納します。

以下の例では、トランザクション ログに Purchase Order エンティティと Invoice エンティティのイベントが含まれています。

590

以下のフィールドは、イベント テーブルで必須です。イベント テーブルのすべてのレコードに、これらのフィールドに対応する値が含まれる必要があります。

FieldDescription
Entity IDID of the entity for which the event happens. For example, the Invoice ID.
ActivityThe activity describes which action took place on the entity.
Event endThe event end field indicates when the specific event was finished. Ideally, this should be a datetime field, rather than a date.

命名規則

テーブルの名前は、[エンティティ] + _events の構造に従います (例: Purchase_order_eventsInvoice_events)。

4. イベント ログ

単一のエンティティ プロセス

プロセスに含まれるエンティティが 1 つである場合、このステップでさらに変換を行う必要はありません。単一のエンティティ テーブルと複数のイベント テーブルで既に正しい形式になっています。

複数のエンティティ プロセス

When multiple entities are involved in a process, the events of all entities need to be linked to the main entity that is considered the “Case” in the process. See Designing an event log. The below steps describe how to relate all events to the main entity, and how to combine them a single event log.

エンティティのリレーション

「entity-relations」テーブルを作成して、すべてのエンティティ間の関係を一元管理します。この entity-relations テーブルに、関連するエンティティの ID フィールドを格納します。

entity-relations テーブルを作成するには、すべてのエンティティ テーブルを ID フィールドに基づいて結合します。

  • メイン エンティティから開始します。
  • 関連するエンティティを左結合でメイン エンティティに結合します。
  • エンティティがメイン エンティティに直接関連していない場合は、それらのエンティティを、既にメイン エンティティに結合されている関連エンティティに左結合します。

以下の例では、Purchase orderInvoice lineInvoice の 3 つのエンティティがあります。Purchase order はプロセスのメイン エンティティと見なされます。Invoice linePurchase order に直接リンクされ、InvoiceInvoice line を介して間接的にリンクされます。

412 457
Entity_relations as ( 
    select 
        Purchase_orders.”Purchase_order_ID” 
        Invoice_lines.”Invoice_line_ID” 
        Invoices.”Invoice_ID” 
    from Purchase_orders 
    left join Invoice_lines 
        on Purchase_orders.“Purchase_order_ID” = Invoice_lines.”Purchase_order_ID” 
    left join Invoices 
        on Invoice_lines.”Invoice_ID” = Invoices.”Invoice_ID”        
)

生成される entity-relations テーブルは以下のとおりです。

391

リレーション テーブル

メイン エンティティと他の各エンティティ間の個々のリレーションは、エンティティ リレーション テーブルの情報を結合して、別個のテーブルに保存されます。

Relation_invoice_lines as ( 
    select 
        Entity_relations.”Purchase_order_ID” 
        Entity_relations.”Invoice_line_ID” 
    from Entity_relations 
    group by “Purchase_order_ID”, “Invoice_line_ID” 
)
297
Relation_invoices as ( 
    select 
        Entity_relations.”Purchase_order_ID” 
        Entity_relations.”Invoice_ID” 
    from Entity_relations 
    group by “Purchase_order_ID”, “Invoice_ID” 
)
293

イベント ログ

次の手順では、これらのリレーションを使用して、対応する「ケース ID」を各イベント テーブルに追加します。「ケース ID」はリレーション テーブルを介して取得し、イベント情報はイベント テーブルから取得します。完全なイベント ログを作成するために、各エンティティのイベント テーブルを和集合にします。

Purchase_order_event_log as ( 
    select 
        Purchase_order_events.”Purchase_order_ID”, 
        Purchase_order_events.”Activity”, 
        Purchase_order_events.”Event_end” 
    from Purchase_order_events 
    union all 
    select 
        Relation_invoice_lines.”Purchase_order_ID” 
        Invoice_line_events.”Activity” 
        Invoice_line_events.”Event_end” 
    from Invoice_line_events 
    inner join Relation_invoice_lines 
        on Invoice_line_events.”Invoice_line_ID” = Relation_invoice_lines.”Invoice_line_ID” 
    union all 
    select 
        Relation_invoices.”Purchase_order_ID” 
        Invoice_events.”Activity” 
        Invoice_events.”Event_end” 
    from Invoice_events 
    inner join Relation_invoices 
        on Invoice_events.”Invoice_line_ID” = Relation_invoices.”Invoice_line_ID” 
)

命名規則

イベント ログ テーブルの名前が後で競合する可能性がある場合は、イベント ログ テーブルの名前にサフィックス _base を追加します。

5. ビジネス ロジック

最後の変換手順では、データ分析に必要なビジネス ロジックが追加されます。ここでは、追加の派生フィールドを既存のテーブルに追加できます。たとえば、ダッシュボードの KPI で使用する特定のスループット時間フィールドや Boolean フィールドです。

Process Miningでは、この変換手順で定義される標準的な 2 つの追加テーブルとして、TagsDue dates があります。

タグ

タグはケースのプロパティで、特定のビジネス ルールを表します。通常は、ビジネス ルールを簡単に分析できるようにするために追加します。以下に例を示します。

  • 請求書の支払と承認が同じユーザーによって行われている。
  • 請求書の承認時間が 10 日を超えている。
  • 請求書を確認するアクティビティがスキップされている。

タグ テーブルの各レコードは、特定のケースのデータで発生した 1 つのタグを表します。このテーブルの必須フィールドは、「Case ID」と「Tag」です。すべてのケースにタグが付くわけではありません。一部のケースには複数のタグが付く可能性もあります。以下は、Tags テーブルの例です。

332

期限日

期限日はプロセスの期限を表します。期限日をデータに追加して、アクティビティが期限内に実行されているかどうかを分析します。

期限日テーブルの各レコードは、特定のイベントの 1 つの期限日を表します。期限日の例は次のとおりです。

  • 支払イベントの支払期限。
  • 承認イベントの承認期限。

このテーブルの必須フィールドは、Event IDDue dateActual dateExpected date です。

551

すべてのイベントに期限日が設定されているわけではありません。また、複数の期限日が設定されているイベントもあります。

23 日前に更新

変換の構造


改善の提案は、API リファレンスのページでは制限されています

改善を提案できるのは Markdown の本文コンテンツのみであり、API 仕様に行うことはできません。