Überblick

Below is an overview of the transformation steps of the UiPath Process Mining app templates.

Der Ordner models\ ist entsprechend der Struktur der Transformationsschritte organisiert.

1. Eingabe

Der Eingabeschritt wird verwendet, um die Rohdaten zu laden. Die folgenden Vorgänge werden in der Regel ausgeführt, um die Daten für die nächsten Transformationsschritte vorzubereiten:

• Type cast fields to the appropriate data types.
• Filter tables to reduce data size early in the transformations.

📘

Hinweis:

It is recommended to reduce data size already in the extraction where possible.

Benennungskonvention

Wenn Sie in den nächsten Transformationsschritten Namenskonflikte mit Tabellennamen erwarten, empfiehlt es sich, den Eingabetabellen das Suffix _input hinzuzufügen.

2. Entitäten

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.

Im folgenden Beispiel werden 3 Eingabetabellen Invoices_input , Invoice_types_input und Customers_input miteinander verbunden, um die Entitätstabelle „Rechnungen“ zu erstellen.

Richtlinien

Befolgen Sie diese Richtlinie, wenn Sie eine Entitätstabelle erstellen.

• Es gibt ein Entitäts-ID-Feld, das für jeden Datensatz eindeutig ist.
• Alle Entitätsfelder, die für die Datenanalyse erforderlich sind, sind vorhanden.
• Alle Entitätsfelder haben leicht verständliche Namen.

Gegebenenfalls bezieht sich die Entitätstabelle über ein ID-Feld auf eine andere Entität. Siehe das folgende Beispiel, in dem die Rechnungszeilen über das Feld Invoice_ID mit der Rechnungsentität verknüpft sind.

Additional transformations

Nicht alle Eingabetabellen werden in Entitätstabellen umgewandelt. Auch andere Eingabetabellen können relevante Informationen enthalten, z. B. die Customers-Tabelle im Beispiel. Es kann praktisch sein, sie im Entitätenschritt als separate Tabellen zu definieren, damit sie in den Datenumwandlungen wiederverwendet werden können.

Benennungskonvention

Wenn die Namen der Entitätstabellen später zu Namenskonflikten führen würden, fügen Sie den Tabellen das Suffix _base hinzu.

3. Ereignisse

📘

Hinweis:

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:

• Timestamp fields: Fields on an entity table with a timestamp for an event. For example, the Invoice_created field in an Invoices table.
• Transaction log: A list of events.

Je nach Struktur der Daten unterscheiden sich die Transformationen zum Erstellen der Ereignistabellen.

Timestamp fields

In diesem Szenario müssen die Werte eines Zeitstempelfelds in separate Datensätze in einer Ereignistabelle umgewandelt werden. Das folgende Beispiel ist eine Rechnungstabelle, die drei Zeitstempelfelder enthält.

Jedes Zeitstempelfeld wird verwendet, um eine separate Ereignistabelle zu erstellen. Erstellen Sie für jeden Datensatz, bei dem das Zeitstempelfeld einen Wert enthält, eine Tabelle mit der Rechnungs-ID, dem Namen des Ereignisses (Aktivität) und dem Zeitstempel, in dem das Ereignis stattgefunden hat (Ereignisende).

Die Invoices_input table ist aufgeteilt in Invoice_events_Create_invoice , Invoice_events_Delete_invoice und Invoices_events_Change_invoice_price .

Die separaten Ereignistabellen können dann zu einer einzelnen Ereignistabelle pro Entität zusammengeführt werden, z. B. Invoices_events .

Transaktionsprotokoll

Wenn Ereignisse in einem Transaktionsprotokoll gespeichert werden, sollten die relevanten Ereignisse pro Entität identifiziert werden. Erstellen Sie eine Tabelle pro Entität und speichern Sie die entsprechende Entitäts-ID, den Namen des Ereignisses (Aktivität) und den Zeitstempel, in dem das Ereignis stattgefunden hat (Ereignisende).

In the below example, the transaction log contains events for the Purchase Order and Invoice entities.

Die folgenden Felder sind in einer Ereignistabelle obligatorisch. Alle Datensätze in den Ereignistabellen sollten einen Wert für diese Felder enthalten.

Benennungskonvention

Name the tables according to the structure [Entity] + _events. For example, Purchase_order_events and Invoice_events.

4. Ereignisprotokolle

Prozess mit einer einzelnen Entität

Wenn der Prozess eine Entität enthält, sind in diesem Schritt keine zusätzlichen Transformationen erforderlich. Die Tabelle mit einer einzelnen Entität und die Ereignistabellen haben bereits das richtige Format.

Prozess mit mehreren Entitäten

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

Erstellen Sie eine „Entity-Relations“-Tabelle, um die Beziehungen zwischen allen Entitäten zu zentralisieren. Diese Entitätsbeziehungstabelle enthält die ID-Felder der zugehörigen Entitäten.

Um die Entitätsbeziehungstabelle zu erstellen, verknüpfen Sie alle Entitätstabellen basierend auf ihren ID-Feldern:

• Beginnen Sie mit der Hauptentität
• Verbinden Sie verwandte Entitäten mit der Hauptentität mit einer linken Verknüpfung.
• Wenn Entitäten sich nicht direkt auf die Hauptentität beziehen, verknüpfen Sie sie mit den verknüpften Entitäten, die bereits mit der Hauptentität verknüpft sind.

In the below example, there are three entities: Purchase order, Invoice line, and Invoice. The Purchase order is considered the main entity in the process. The Invoice line is directly linked to the Purchase order and the Invoice is linked indirectly via the Invoice line.

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

Unten sehen Sie die resultierende Entitätsbeziehungstabelle.

Relation tables

Die einzelnen Beziehungen zwischen der Hauptentität und jeder anderen Entität werden in separaten Tabellen gespeichert, wobei die kombinierten Informationen aus der Tabelle der Entitätsbeziehungen verwendet werden.

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

Relation_invoices as ( 
    select 
        Entity_relations.”Purchase_order_ID” 
        Entity_relations.”Invoice_ID” 
    from Entity_relations 
    group by “Purchase_order_ID”, “Invoice_ID” 
)

Ereignisprotokoll

Der nächste Schritt besteht darin, diese Beziehungen zu verwenden, um jeder Ereignistabelle die entsprechende „Fall-ID“ hinzuzufügen. Die „Fall-ID“ wird über die Beziehungstabelle abgerufen, in der die Ereignisinformationen aus der Ereignistabelle abgerufen werden. Um das vollständige Ereignisprotokoll zu erstellen, werden die Ereignistabellen für jede Entität vereinigt.

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

Benennungskonvention

Wenn der Name der Ereignisprotokolltabelle zu einem späteren Zeitpunkt zu Namenskonflikten führen kann, fügen Sie dem Namen der Ereignisprotokolltabellen das Suffix _base hinzu.

5. Geschäftslogik

Im letzten Transformationsschritt wird die Geschäftslogik nach Bedarf für die Datenanalyse hinzugefügt. Hier können zusätzliche abgeleitete Felder zu vorhandenen Tabellen hinzugefügt werden. Zum Beispiel bestimmte Durchlaufzeiten oder boolesche Felder, die in KPIs in Dashboards verwendet werden.

In Process Mining, there are two additional standard tables defined in this transformation step: Tags and Due dates.

Tags

Tags sind Eigenschaften von Fällen, die bestimmte Geschäftsregeln bezeichnen. Tags werden normalerweise hinzugefügt, um die Analyse dieser Geschäftsregeln zu vereinfachen. Zum Beispiel:

• Rechnung wurde von derselben Person bezahlt und genehmigt.
• Die Rechnungsgenehmigung hat mehr als 10 Tage gedauert.
• Aktivität „Rechnung überprüfen“ übersprungen.

Jeder Datensatz in der Tag-Tabelle stellt ein Tag dar, das in den Daten für einen bestimmten Fall vorgekommen ist. Die Pflichtfelder für diese Tabelle sind die „Fall-ID“ und das „Tag“. Nicht alle Fälle haben ein Tag und einige Fälle können mehrere Tags haben. Unten sehen Sie ein Beispiel für eine Tags-Tabelle.

Fälligkeitsdaten

Fälligkeitsdaten stellen Fristen im Prozess dar. Diese werden den Daten hinzugefügt, um zu analysieren, ob Aktivitäten zu diesen Fälligkeitsdaten pünktlich ausgeführt werden oder nicht.

Jeder Datensatz in der Tabelle „Fälligkeitsdaten“ stellt ein Fälligkeitsdatum für ein bestimmtes Ereignis dar. Beispiele für Fälligkeitsdaten sind:

• eine Zahlungsfrist für ein Zahlungsereignis.
• eine Genehmigungsfrist für einen Genehmigungstermin.

Die Pflichtfelder für diese Tabelle sind Event ID, Due date, Actual date und Expected date.

Nicht alle Ereignisse haben ein Fälligkeitsdatum und einige Ereignisse können mehrere Fälligkeitsdaten haben.