Structure of transformations

Vue d'ensemble (Overview)

L'illustration suivante montre les étapes de transformation des modèles d'application Process Mining .

Le dossier models\ est organisé selon la structure des étapes de transformation.

1. Entrée

L’étape d’entrée est utilisée pour charger les données brutes. Les opérations suivantes sont généralement effectuées pour préparer les données en vue des étapes de transformation suivantes :

• Sélectionnez les champs avec les macros facultatives et obligatoires. Il n'est pas nécessaire qu'un champ soit présent dans les données brutes lorsque la macro facultative est utilisée.
• Saisissez les champs de conversion vers les types de données appropriés.

• Filtrez les tables pour réduire la taille des données au début des transformations.

Remarque : il est recommandé de réduire la taille des données déjà présentes dans l'extraction dans la mesure du possible.

Conventions d'affectation de noms

Si vous vous attendez à des conflits de noms avec les noms de table lors des prochaines étapes de transformation, il est recommandé d'ajouter le suffixe _input aux tables d'entrée.

2. Entités

Dans l'étape Entités, les tables d'entrée sont transformées en tables d'entité. Chaque entité requise pour les événements attendus doit obtenir sa propre table. Reportez-vous à Conception d'un journal des événements. En outre, les entités support peuvent également être définies ici.

Dans l'exemple suivant, 3 tables d'entrée Invoices_input, Invoice_types_input et Customers_input sont jointes pour créer la table d'entité Factures (Invoices).

Directives

Suivez ces directives lors de la création d'une table d'entité.

• Il existe un champ ID d'entité, qui est unique pour chaque enregistrement de données.
• Tous les champs d'entité nécessaires à l'analyse des données sont présents.
• Tous les champs d'entité ont des noms faciles à comprendre.

Le cas échéant, la table d'entité est liée à une autre entité via un champ d'ID. Dans l'exemple suivant, les lignes de facture sont liées à l'entité de facture via le champ Invoice_ID .

Additional transformations

Toutes les tables d'entrée ne sont pas transformées en tables d'entités. En outre, d'autres tables d'entrée peuvent contenir des informations pertinentes, telles que la table Customers dans l'exemple. Il peut être pratique de les définir à l'étape des entités en tant que tables distinctes afin qu'elles puissent être réutilisées dans les transformations de données.

Conventions d'affectation de noms

Si les noms des tables d'entités devaient entraîner des conflits de noms ultérieurement, ajoutez le suffixe _base aux tables.

3. Événements

Remarque : l'entrée des modèles d' application TemplateOne-SingleFile et TemplateOne-MultiFiles est déjà un journal d'événements bien défini pour Process Mining. Il n'est pas nécessaire de transformer les données du système source en événements pour Process Mining ici. Cela signifie que 3. events n'est pas présent dans les transformations des applications de processus TemplateOne-SingleFile et TemplateOne-MultiFiles .

Lors de cette étape de transformation, des tables d'événements sont créées pour chaque entité. Voir Conception d'un journal des événements. Chaque enregistrement d'une table d'événements représente un événement qui s'est produit. Il existe deux scénarios sur la façon dont les données sont structurées :

• Champs d'horodatage: champs d'une table d'entité avec un horodatage pour un événement. Par exemple, le champ Invoice_created dans une table Invoices .
• Journal des transactions: une liste d'événements.

En fonction de la structure des données, les transformations permettant de créer les tables d'événements sont différentes.

Timestamp fields

Dans ce scénario, les valeurs d'un champ d'horodatage doivent être transformées en enregistrements distincts dans une table d'événements. L'exemple suivant est une table de factures qui contient trois champs d'horodatage.

Chaque champ d'horodatage est utilisé pour créer une table d'événements distincte. Pour chaque enregistrement pour lequel le champ timestamp contient une valeur, créez une table avec l'ID de facture, le nom de l'événement (activité) et l'horodatage auquel l'événement a eu lieu (fin de l'événement).

Le Invoices_input table est divisé en Invoice_events_Create_invoice , Invoice_events_Delete_invoice et Invoices_events_Change_invoice_price .

Les tables d'événements distinctes peuvent ensuite être fusionnées en une seule table d'événements par entité, par exemple Invoices_events .

Journal de transactions

Si les événements sont stockés dans un journal des transactions, les événements pertinents par entité doivent être identifiés. Créez une table par entité et stockez l'ID d'entité correspondant, le nom de l'événement (activité) et l'horodatage de l'événement (fin de l'événement).

Dans l'exemple suivant, le journal de transactions contient des événements pour les entités Bon de commande (Purchase Order) et Facture (Invoice) .

Les champs suivants sont obligatoires dans une table d'événements. Tous les enregistrements des tables d'événements doivent contenir une valeur pour ces champs.

Champ	Description
Identifiant de l’entité	ID de l'entité pour laquelle l'événement se produit. Par exemple, l ' ID de facture.
Activité	L'activité décrit l'action qui a eu lieu sur l'entité.
Event end	Le champ de fin d'événement indique quand l'événement spécifique a été terminé. Idéalement, il doit s'agir d'un champ datetime plutôt que d'une date.

Conventions d'affectation de noms

Nommez les tables en fonction de la structure [Entity] + _events. Par exemple,  Purchase_order_events et Invoice_events .

4. Journaux des événements

Processus d'entité unique

Lorsque le processus contient une entité, aucune transformation supplémentaire n'est nécessaire dans cette étape. La table d'entité unique et les tables d'événements sont déjà au format correct.

Processus à entités multiples

Lorsque plusieurs entités sont impliquées dans un processus, les événements de toutes les entités doivent être liés à l'entité principale considérée comme « incident » dans le processus. Reportez-vous à Définir le journal des événements pour plus de détails. Les étapes suivantes expliquent comment lier tous les événements à l'entité principale et comment les combiner dans un seul journal des événements.

Entity relations

Créez une table « Entity-Relations » pour centraliser les relations entre toutes les entités. Cette table de relations d'entités contiendra les champs d'ID des entités associées.

Pour créer la table des relations d'entités (Entity-Relations), joignez toutes les tables d'entités en fonction de leurs champs d'ID :

• Commencer par l'entité principale
• Joindre les entités associées à l'entité principale avec une jointure à gauche.
• Si les entités ne sont pas directement liées à l'entité principale, joignez-les aux entités liées qui sont déjà liées à l'entité principale.

Dans l'exemple suivant, il existe trois entités : Bon de commande (Purchase Order),Ligne de facture (Invoice line) et Facture (Invoice). Le bon de commande est considéré comme l'entité principale du processus. La ligne Facture (Invoice) est directement liée au Bon de commande (Purchase Purchase ) et la Facture (Invoice) est liée indirectement via la ligne Facture (Invoice).

L'illustration suivante montre la table des relations d'entités obtenue.

Relation tables

Les relations individuelles entre l'entité principale et chaque autre entité sont stockées dans des tables distinctes, en utilisant les informations combinées de la table des relations d'entité.

Journal des événements

L'étape suivante consiste à utiliser ces relations pour ajouter l'« ID de cas » correspondant à chaque table d'événements. L'« ID de cas » est obtenu via la table de relations, où les informations d'événement sont obtenues à partir de la table d'événements. Pour créer le journal des événements complet, les tables d'événements de chaque entité sont réunies.

Conventions d'affectation de noms

Si le nom de la table du journal des événements peut entraîner des conflits de noms à une étape ultérieure, ajoutez le suffixe _base au nom des tables du journal des événements.

5. Logique métier

Dans la dernière étape de la transformation, la logique métier est ajoutée selon les besoins pour l'analyse des données. Des champs dérivés supplémentaires peuvent être ajoutés aux tables existantes ici. Par exemple, des délais de traitement spécifiques ou des champs booléens utilisés dans les ICP des tableaux de bord.

Dans Process Mining, deux tables standard supplémentaires sont définies dans cette étape de transformation : Tags et Due dates .

Balises

Les balises sont des propriétés des cas, qui signifient certaines règles métier. Les balises sont généralement ajoutées pour faciliter l'analyse de ces règles métier. Par exemple :

• Facture payée et approuvée par la même personne.
• L’approbation de la facture a pris plus de 10 jours.
• Vérifier l’activité de facturation ignorée.

Chaque enregistrement de la table des balises représente une balise qui s'est produite dans les données pour un incident spécifique. Les champs obligatoires de cette table sont les champs « ID de cas » et « Balise ». Tous les incidents n'auront pas tous une balise, et certains incidents pourront avoir plusieurs balises. L'illustration suivante montre un exemple de table Balises (Tags).

Dates d’échéance

Les dates d’échéance représentent les échéances du processus. Celles-ci sont ajoutées aux données pour analyser si les activités sont effectuées à temps ou non pour ces dates d’échéance.

Chaque enregistrement de la table du journal des échéances représente une échéance pour un certain évènement. Exemples de dates d'échéance :

• une échéance de paiement pour un paiement.
• un délai d’approbation pour un bon de commande.

Les champs obligatoires de cette table sont les champs Event ID, Due date, Actual date et Expected date.

Tous les événements n'auront pas tous une date d'échéance, et certains événements pourront avoir plusieurs dates d'échéance.