Structure of transformations

Überblick

Die folgende Abbildung zeigt die Transformationsschritte der Process Mining- App-Vorlagen.

Der Ordner models\ im Abschnitt Transformationen der Datentransformationen ist gemäß der Struktur der Transformationsschritte organisiert.

1. Eingabe

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

• Wählen Sie Felder mit dem optionalen und obligatorischen Makro aus. Ein Feld muss nicht in den Rohdaten vorhanden sein, wenn das optionale Makro verwendet wird.
• Geben Sie Umwandlungsfelder in die entsprechenden Datentypen ein.

• Filtern Sie Tabellen, um die Datengröße zu Beginn der Transformationen zu reduzieren.

Hinweis: Es wird empfohlen, die Datengröße nach Möglichkeit bereits bei der Extraktion zu reduzieren.

Benennungskonvention

Wenn Sie erwarten, dass Namenskonflikte mit Tabellennamen in den nächsten Transformationsschritten auftreten, ist es sinnvoll, den Eingabetabellen das Suffix _input hinzuzufügen.

Optionale Felder

Die Eingabe eines Connectors besteht aus obligatorischen und optionalen Daten. Für optionale Felder sollte das optional -Makro aus dem pm-utils -Paket verwendet werden. Dadurch wird sichergestellt, dass ein Feld den Wert null erhält, wenn es in den Quelldaten nicht verfügbar ist. So werden alle Transformationen korrekt ausgeführt.

• Verwenden Sie das optional_table()- Makro, wenn die gesamte Tabelle optional ist.

2. Objekte

Im Schritt Object werden Eingabetabellen in Objekttabellen umgewandelt. Jedes Objekt, das für die erwarteten Ereignisse erforderlich ist, sollte eine eigene Tabelle erhalten. Weitere Informationen finden Sie unter Entwerfen eines Ereignisprotokolls. Darüber hinaus kann hier auch das unterstützende Objekt definiert werden.

Im folgenden Beispiel werden die drei Eingabetabellen Invoices_input, Invoice_types_input und Customers_input miteinander verbunden, um die Objekttabelle Rechnungen zu erstellen.

Richtlinien

Befolgen Sie diese Richtlinie beim Erstellen einer Objekttabelle.

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

Falls zutreffend, verweist die Objekttabelle über ein ID-Feld auf ein anderes Objekt. Im folgenden Beispiel beziehen sich die Rechnungszeilen auf das Rechnungsobjekt über das Feld Invoice_ID .

Additional transformations

Nicht alle Eingabetabellen werden in Objekttabellen umgewandelt. Auch andere Eingabetabellen können relevante Informationen enthalten, wie z. B. die Tabelle Customers im Beispiel. Es kann hilfreich sein, sie im Schritt Objekte als separate Tabellen zu definieren, sodass sie in den Datentransformationen wiederverwendet werden können.

Benennungskonvention

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

3. Ereignisse

Hinweis: Die Eingabe für Ereignisprotokolle und benutzerdefinierte Prozess -App-Vorlagen ist bereits ein genau definiertes Ereignisprotokoll für Process Mining. Hier müssen die Daten aus dem Quellsystem nicht in die Ereignisse für Process Mining umgewandelt werden. Dies bedeutet, dass 3. events in den Transformationen für Ereignisprotokoll- und benutzerdefinierte Prozess -Apps nicht vorhanden ist.

In diesem Transformationsschritt werden für jedes Objekt Ereignistabellen erstellt. Informieren Sie sich über Entwerfen eines Ereignisprotokolls. Jeder Datensatz in einer Ereignistabelle stellt ein Ereignis dar, das stattgefunden hat. Es gibt zwei Szenarien für die Struktur der Daten:

• Zeitstempelfelder: Felder in einer Objekttabelle mit einem Zeitstempel für ein Ereignis. Zum Beispiel das Feld Invoice_created in einer Invoices -Tabelle.
• Transaktionsprotokoll: Eine Liste von Ereignissen.

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 enthält 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 in eine einzelne Ereignistabelle pro Objekt zusammengeführt werden, z. B. Invoices_events.

Transaktionsprotokoll

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

Im folgenden Beispiel enthält das Transaktionsprotokoll Ereignisse für die Objekte Bestellung und Rechnung .

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

Feld	Beschreibung
Objekt-ID	ID des Objekts, für das das Ereignis passiert. Zum Beispiel die Rechnungs-ID.
Aktivität	Die Aktivität beschreibt, welche Aktion für das Objekt stattgefunden hat.
Event end	Das Feld Ereignisende gibt an, wann das bestimmte Ereignis beendet wurde. Im Idealfall sollte dies ein datetime-Feld und kein Datum sein.

Benennungskonvention

Benennen Sie die Tabellen nach [Activity] + _events um eine Ereignisdatei pro Aktivität zu erstellen, oder [Object] + _events um eine Ereignisdatei pro Objekt zu erstellen. Zum Beispiel Purchase_order_created_events, Purchase_order_approved_events oder eine Datei mit allen Bestellaktivitäten kombiniert Purchase_order_events.

4. Ereignisprotokolle

Einzelobjektprozess

Wenn der Prozess ein Objekt enthält, sind in diesem Schritt keine zusätzlichen Transformationen erforderlich. Die Einzelobjekttabelle und die Ereignistabellen haben bereits das richtige Format.

Prozess mit mehreren Objekten

Wenn mehrere Objekte an einem Prozess beteiligt sind, müssen die Ereignisse aller Objekte mit dem Hauptobjekt verknüpft werden, das im Prozess als „Fall“ betrachtet wird. Weitere Informationen finden Sie unter Definieren des Ereignisprotokolls . In den folgenden Schritten wird beschrieben, wie alle Ereignisse auf das Hauptobjekt bezogen werden und wie sie in einem einzigen Ereignisprotokoll kombiniert werden.

Objektbeziehungen

Erstellen Sie eine „Objektbeziehungen“-Tabelle, um die Beziehungen zwischen allen Objekten zu zentralisieren. Diese Tabelle der Objektbeziehungen enthält die ID-Felder der zugehörigen Objekte.

Um die Tabelle „Objektbeziehungen“ zu erstellen, verbinden Sie alle Objekttabellen basierend auf ihren ID-Feldern:

• Beginnen Sie mit dem Hauptobjekt
• Verbinden Sie verknüpfte Objekte mit dem Hauptobjekt durch eine linke Verknüpfung.
• Wenn Objekte sich nicht direkt auf das Hauptobjekt beziehen, verbinden Sie sie links mit den zugehörigen Objekten, die bereits mit dem Hauptobjekt verbunden sind.

Im folgenden Beispiel gibt es drei Objekte: Bestellung,Rechnungszeile und Rechnung. Die Bestellung gilt als das Hauptobjekt im Prozess. Die Zeile Rechnung ist direkt mit der Bestellung und die Rechnung indirekt über die Zeile Rechnung verknüpft.

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
)

Die folgende Abbildung zeigt die resultierende Tabelle der Objektbeziehungen.

Relation tables

Die einzelnen Beziehungen zwischen dem Hauptobjekt und jedem anderen Objektobjekt werden in separaten Tabellen gespeichert, wobei die kombinierten Informationen aus der Tabelle der Objektbeziehungen verwendet werden.

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

Ereignisprotokoll

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

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 Miningsind in diesem Transformationsschritt zwei zusätzliche Standardtabellen definiert: Tags und Due dates .

Tags

Tags sind Eigenschaften von Objekten, die für bestimmte Geschäftsregeln stehen. Tags werden in der Regel 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 Tags-Tabelle steht für ein Tag, das in den Daten für einen bestimmten Fall aufgetreten ist. Die Pflichtfelder für diese Tabelle sind die  Object ID und das  Tag. Nicht alle Objekte haben ein Tag und einige Objekte können mehrere Tags haben. Die folgende Abbildung zeigt ein Beispiel für die Tags-Tabelle.

Hinweis:

Im Datenmodell ist nur eine Tags-Tabelle zulässig.

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 Objekt dar. Beispiele für Fälligkeitsdaten sind:

• eine Zahlungsfrist für eine Zahlung.
• eine Genehmigungsfrist für eine Bestellung.

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

Hinweis:

Im Datenmodell ist nur eine Fälligkeitsdatentabelle zulässig.