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\ dans la section Transformations des Transformations de données est organisé selon la structure des étapes de transformation.

Remarque :

Les modèles d'application Journal des événements et Processus personnalisé ont une structure de transformation de données simplifiée. Les applications de processus créées avec ces modèles d'application n'ont pas cette structure de dossiers.

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.
• Type cast fields to the appropriate data types.
  Remarque :

  It is recommended to reduce data size already in the extraction where 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. Objets

Lors de l'étape Objets, les tables d'entrée sont transformées en tables d'objet. Chaque objet requis pour les événements attendus doit obtenir sa propre table. Reportez-vous à la section Créer un journal des événements. En outre, l'objet de prise en charge peut également être défini 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'objet Factures.

Directives

Suivez ces instructions lors de la création d'une table d'objets.

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

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

Additional transformations

Toutes les tables d'entrée ne sont pas transformées en tables d'objet. En outre, d'autres tables d'entrée peuvent contenir des informations pertinentes, telles que la table Clients (Customers) dans l'exemple. Il peut être pratique de les définir à l'étape Objets 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 de table d'objet entraînaient des plantages de nom plus tard, ajoutez le suffixe _base aux tables.

3. Événements

Remarque :

L'entrée pour le Journal des événements et les Modèles d'application de processus personnalisés 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.

Au cours de cette étape de transformation, des tables d'événements sont créées pour chaque objet. Consultez la section Créer 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'objets avec un horodatage pour un événement. Par exemple, le champ Invoice_created d'une table Invoices .
• Transaction log: A list of events.

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 objet, par exemple Invoices_events.

Journal de transactions

Si les événements sont stockés dans un journal de transaction, les événements pertinents par objet doivent être identifiés. Créez une table par objet et stockez l’ID de l’objet 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 des transactions contient des événements pour les objets Bon de commande et Facture .

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

Champ	Description
ID d'objet	ID de l'objet pour lequel l'événement se produit. Par exemple, l' ID de facture.
Activité	L'activité décrit quelle action a eu lieu sur l'objet.
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 du [Activity] + _events pour créer un fichier d'événement par activité, ou [Object] + _events pour créer un fichier d'événement par objet. Par exemple Purchase_order_created_events, Purchase_order_approved_events, ou un fichier avec toutes les activités de commande d'achat combinées Purchase_order_events.

4. Journaux des événements

Processus d'objet unique

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

Processus d’objets multiples

Lorsque plusieurs objets sont impliqués dans un processus, les événements de tous les objets doivent être liés à l'objet principal qui est considéré comme « l'incident » dans le processus. Consultez la section Définir le journal des événements pour plus de détails. Les étapes suivantes décrivent comment lier tous les événements à l'objet principal et comment les combiner sous un seul journal d'événements.

Relation d'objet

Créez une table « relations-objets » pour centraliser les relations entre tous les objets. Cette table de relations d'objets contiendra les champs d'ID des objets liés.

Pour créer la table de relations d'objets, joignez toutes les tables d'objets en fonction de leurs champs d'ID :

• Commencer par l'objet principal
• Joignez les objets connexes à l'objet principal avec une jointure gauche.
• Si les objets ne sont pas directement liés à l'objet principal, joignez-les aux objets associés qui sont déjà joints à l'objet principal.

Dans l'exemple suivant, il y a trois objets : Bon de commande,Ligne de facture, et Facture. Le bon de commande est considéré comme l'objet principal du processus. La ligne Facture est directement liée au bon de commande et la ligne Facture est liée indirectement via la ligne Facture.

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
)

L'illustration suivante montre le tableau des relations d'objets obtenu.

Relation tables

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

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

Journal des événements

L'étape suivante consiste à utiliser ces relations pour ajouter l'« ID de cas » correspondant à chaque table d'événement. L'« ID de cas » est obtenu via la table de relation, 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 objet sont unifiées.

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

Conventions d'affectation de noms

Si le nom de la table du journal d'événements peut entraîner des changements de nom à une étape ultérieure, ajoutez le suffixe _base au nom des tables du journal d'é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.

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

Balises

Les balises sont des propriétés des objets, qui indiquent 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 Object ID et le Tag. Tous les objets n'auront pas tous une balise, et certains objets pourront avoir plusieurs balises. L'illustration suivante montre un exemple de table Balises.

Remarque :

Une seule table Balises est autorisée dans le modèle de données.

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 objet. 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 Object ID, Due date, Actual date et Expected date.

Remarque :

Une seule table de dates d'échéance est autorisée dans le modèle de données.