process-mining
latest
false
重要 :
このコンテンツの一部は機械翻訳によって処理されており、完全な翻訳を保証するものではありません。 新しいコンテンツの翻訳は、およそ 1 ~ 2 週間で公開されます。
UiPath logo, featuring letters U and I in white

Process Mining

最終更新日時 2025年2月18日

変換の構造

概要

次の図に、Process Mining アプリ テンプレートの変換手順を示します。


データ変換「変換 」セクションの フォルダーは、変換ステップの構造に従って編成されています。models\

1. 入力

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

  • 任意および必須のマクロが含まれるフィールドを選択します。任意のマクロが使用される場合、フィールドを生データに含める必要はありません。
  • フィールドを適切なデータ型に型キャストします。
  • テーブルをフィルター処理し、変換の早い段階でデータ サイズを減らします。

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

命名規則

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

任意のフィールド

コネクタの入力は必須のデータと任意のデータからなります。任意のフィールドの場合は、pm-utils パッケージの任意のマクロを使用する必要があります。これにより、ソース データに値がない場合、フィールドが確実に値 null を取得するようにします。こうすることで、すべての変換が正しく実行されます。
  • テーブル全体が任意の場合は optional_table() マクロを使用します。

2. オブジェクト

オブジェクト ステップでは、入力テーブルを objec テーブルに変換します。 予期されるイベントに必要なオブジェクトごとに専用のテーブルを用意する必要があります。 「 イベント ログを定義する」をご覧ください。 さらに、サポート オブジェクトもここで定義できます。

次の例では、 、 Invoices_inputInvoice_types_inputCustomers_input の 3 つの入力テーブルを結合してオブジェクト テーブル Invoices を作成しています。


ガイドライン

オブジェクト テーブルを作成するときは、次のガイドラインに従ってください。

  • オブジェクト ID 項目は 1 つあり、これは各データレコードに固有です。
  • データ分析に必要なすべてのオブジェクト項目が存在すること。
  • すべてのオブジェクト項目には、わかりやすい名前が付けられています。
該当する場合、オブジェクト テーブルは ID フィールドを介して別のオブジェクトに関連付けられます。 次の例では、請求書品目は Invoice_ID フィールドを介して請求書オブジェクトに関連付けられています。


その他の変換

すべての入力テーブルがオブジェクト テーブルに変換されるわけではありません。 また、この例の Customers テーブルのように、他の入力テーブルにも関連する情報が含まれている場合があります。 これらを個別のテーブルとして定義し、データ変換で再利用できるようにすると便利です。

命名規則

オブジェクト テーブル名が後で名前の競合につながる場合は、テーブルにサフィックス _baseを追加します。

3. イベント

注: イベント ログカスタム プロセスのアプリ テンプレートの入力データは、既に Process Mining 用に適切に定義されたイベント ログです。ソース システムのデータを Process Mining のイベントにこの段階で変換する必要はありません。つまり、イベント ログカスタム プロセスのアプリの変換には 3. events は存在しません。

この変換手順では、各オブジェクトに対してイベント テーブルを作成します。 「 イベント ログを定義する」をご覧ください。 イベント テーブルの各レコードは、実行される 1 つのイベントを表します。 データを構造化する方法には次の 2 つのシナリオがあります。

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

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

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

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



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



Invoices_input table は、Invoice_events_Create_invoiceInvoice_events_Delete_invoice、および Invoices_events_Change_invoice_price に分割されます。
その後、別個のイベント テーブルを、オブジェクトごとに 1 つのイベント テーブルにマージできます (例: Invoices_events)。

トランザクション ログ

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

次の例では、トランザクション ログに Purchase Order オブジェクトと Invoice オブジェクトのイベントが含まれています。
トランザクション ログとイベント テーブル

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

フィールド

説明

オブジェクト ID

イベントが発生するオブジェクトの ID。 (例: 請求書 ID)。

アクティビティ

このアクティビティは、オブジェクトに対して実行されたアクションを記述します。

Event end

[Event end] フィールドは、特定のイベントが完了したタイミングを示します。日付フィールドではなく日時フィールドであるのが理想的です。

命名規則

アクティビティごとに 1 つのイベント ファイルを作成するか、オブジェクトごとに 1 つのイベント ファイルを作成するには[Object] + _events[Activity] + _eventsに従って、テーブルに名前を付けます。たとえば、 、 Purchase_order_approved_eventsPurchase_order_created_events、またはすべての発注アクティビティを Purchase_order_events組み合わせた 1 つのファイルなどです。

4. イベント ログ

単一オブジェクトのプロセス

プロセスに含まれるオブジェクトが 1 つの場合は、この手順で追加の変換を行う必要はありません。 単一オブジェクト テーブルとイベント テーブルは、既に正しい形式になっています。

複数オブジェクトの処理

プロセスに複数のオブジェクトが含まれる場合、すべてのオブジェクトのイベントを、プロセスの「ケース」と見なされるメインオブジェクトにリンクする必要があります。 詳細については 、「イベント ログを定義する 」をご覧ください。 次の手順では、すべてのイベントをメイン オブジェクトに関連付ける方法と、それらを 1 つのイベント ログに結合する方法について説明します。

オブジェクトの関係

「オブジェクト関係」テーブルを作成して、すべてのオブジェクト間の関係を一元化します。 このオブジェクトリレーションテーブルには、関連オブジェクトの ID フィールドが含まれます。

objects-relations テーブルを作成するには、すべてのオブジェクトテーブルを ID フィールドに基づいて結合します。

  • メインオブジェクトから始める
  • 左結合で関連オブジェクトをメインオブジェクトに結合します。
  • オブジェクトがメインオブジェクトに直接関連していない場合は、メインオブジェクトにすでに結合されている関連オブジェクトに左結合します。

次の例には、 発注書請求書明細行請求書の 3 つのオブジェクトがあります。 発注は、プロセスの主要オブジェクトと見なされます。請求書ライン発注書に直接リンクされ、請求書ラインは請求書ラインを介して間接的にリンクされます。





Object_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
)Object_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
)

次の図は、結果のオブジェクト関係テーブルを示しています。



リレーション テーブル

メインオブジェクトと他のオブジェクトオブジェクト間の個々の関係オブジェクトは、オブジェクト関係テーブルから結合された情報を使用して、別々のテーブルに格納されます。

Relation_invoice_lines as (
	select
		Object_relations."Purchase_order_ID"
		Object_relations."Invoice_line_ID"
	from Object_relations
	group by "Purchase_order_ID", "Invoice_line_ID"
)Relation_invoice_lines as (
	select
		Object_relations."Purchase_order_ID"
		Object_relations."Invoice_line_ID"
	from Object_relations
	group by "Purchase_order_ID", "Invoice_line_ID"
)


Relation_invoices as (
	select
		Object_relations."Purchase_order_ID"
		Object_relations."Invoice_ID"
	from Object_relations
	group by "Purchase_order_ID", "Invoice_ID"
)Relation_invoices as (
	select
		Object_relations."Purchase_order_ID"
		Object_relations."Invoice_ID"
	from Object_relations
	group by "Purchase_order_ID", "Invoice_ID"
)


イベント ログ

次の手順では、これらのリレーションを使用して、対応する「ケース 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"
)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 つのタグを表します。 このテーブルの必須フィールドは、 Object IDTagです。 すべてのオブジェクトにタグがあるわけではなく、一部のオブジェクトには複数のタグがある場合があります。 次の図は、タグ テーブルの例を示しています。


注:

データ モデルでは、1 つのタグ テーブルのみが許可されます。

期限日

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

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

  • 支払の支払期限です。
  • 発注書の承認期限。
このテーブルの必須フィールドは、Object IDDue dateActual dateExpected date です。


注:

データ モデルで使用できる期限日テーブルは 1 つだけです。

このページは役に立ちましたか?

サポートを受ける
RPA について学ぶ - オートメーション コース
UiPath コミュニティ フォーラム
Uipath Logo White