Structure of transformations

Información general

A continuación se muestra un resumen de los pasos de transformación de las plantillas de la aplicación Process Mining .

La carpeta models\ está organizada según la estructura de los pasos de transformación.

1. Entrada

El paso de entrada se utiliza para cargar los datos sin procesar. Las siguientes operaciones se suelen realizar para preparar los datos para los siguientes pasos de transformación:

• Selecciona campos con la macro opcional y obligatoria. No es necesario que un campo esté presente en los datos sin procesar cuando se utiliza la macro opcional.
• Escriba los campos de conversión a los tipos de datos adecuados.

• Filtrar tablas para reducir el tamaño de los datos al principio de las transformaciones.

Nota: se recomienda reducir el tamaño de los datos que ya están en la extracción siempre que sea posible.

Convencion de nombres

Si esperas que los nombres coincidan con los nombres de las tablas en los siguientes pasos de transformación, se recomienda añadir el sufijo _input a las tablas de entrada.

Campos opcionales

La entrada de un conector consta de datos obligatorios y opcionales. Para los campos opcionales, se debe utilizar la macro optional del paquete pm-utils . Esto garantiza que un campo obtenga el valor null si no está disponible en los datos de origen. De esa forma, todas las transformaciones se ejecutarán correctamente.

• Use la macro opcional_tabla () si toda la tabla es opcional.

2. Entidades

En el paso de entidades, las tablas de entrada se transforman en tablas de entidades. Cada entidad requerida para los eventos esperados debe tener su propia tabla. Consulta Diseñar un registro de eventos. Además, las entidades de apoyo también se pueden definir aquí.

En el siguiente ejemplo, 3 tablas de entrada Invoices_input, Invoice_types_inputy Customers_input se unen para crear la tabla de entidades Facturas.

Directrices

Siga estas pautas al crear una tabla de entidades.

• Hay un campo de ID de entidad, que es único para cada registro de datos.
• Están presentes todos los campos de entidad necesarios para el análisis de datos.
• Todos los campos de entidad tienen nombres fáciles de entender.

Cuando corresponda, la tabla de entidades se relaciona con otra entidad a través de un campo de ID. Consulta el siguiente ejemplo, donde las líneas de factura están relacionadas con la entidad de factura a través del campo Invoice_ID .

Additional transformations

No todas las tablas de entrada se transforman en tablas de entidades. Además, otras tablas de entrada pueden contener información relevante, como la tabla Clientes en el ejemplo. Puede ser conveniente definirlos en el paso de entidades como tablas separadas que puedan reutilizarse en las transformaciones de datos.

Convencion de nombres

Si los nombres de la tabla de entidades provocan conflictos de nombres más adelante, añade el sufijo _base a las tablas.

3. Eventos

Nota: La entrada para las plantillas de aplicación del Registro de eventos y el Proceso personalizado ya es un Registro de eventos bien definido para Process Mining. No es necesario transformar los datos del sistema de origen en los eventos para Process Mining aquí. Esto significa que 3. events no está presente en las transformaciones para las aplicaciones de Registro de eventos y de Proceso personalizado.

En este paso de transformación, se crean tablas de eventos para cada entidad. Consulta Diseñar un registro de eventos. Cada registro de una tabla de eventos representa un evento que tuvo lugar. Hay dos escenarios sobre cómo se estructuran los datos:

• Camposde marca de tiempo: campos en una tabla de entidad con una marca de tiempo para un evento. Por ejemplo, el campo Invoice_created en una tabla Invoices .
• Registro de transacciones: una lista de eventos.

Según cómo estén estructurados los datos, las transformaciones para crear las tablas de eventos son diferentes.

Timestamp fields

En este escenario, los valores de un campo de marca de tiempo deben transformarse en registros independientes en una tabla de eventos. El siguiente ejemplo es una tabla de facturas que contiene tres campos de marca de tiempo.

Cada campo de marca de tiempo se usa para crear una tabla de eventos independiente. Por cada registro en el que el campo de marca de tiempo contenga un valor, crea una tabla con el ID de factura, el nombre del evento (Actividad) y la marca de tiempo en la que tuvo lugar el evento (Final del evento).

El Invoices_input table se divide en Invoice_events_Create_invoice, Invoice_events_Delete_invoicey Invoices_events_Change_invoice_price.

Las tablas de eventos independientes se pueden combinar en una sola tabla de eventos por entidad, por ejemplo, Invoices_events.

Registro de transacción

Si los eventos se almacenan en un registro de transacciones, se deben identificar los eventos relevantes por entidad. Crea una tabla por entidad y almacena el ID de entidad correspondiente, el nombre del evento (Actividad) y la marca de tiempo en la que tuvo lugar (Evento final).

En el siguiente ejemplo, el registro de transacciones contiene eventos para las entidades Orden de compra y Factura .

Los siguientes campos son obligatorios en una tabla de eventos. Todos los registros de las tablas de eventos deben contener un valor para estos campos.

Campo	Descripción
ID de entidad	ID de la entidad para la que ocurre el evento. Por ejemplo, el ID de la factura.
Actividades	La actividad describe qué acción se ha llevado a cabo en la entidad.
Event end	El campo de finalización del evento indica cuándo finalizó el evento específico. Idealmente, este debería ser un campo de fecha y hora, en lugar de una fecha.

Convencion de nombres

Nombre las tablas según la estructura [Entidad] + _eventos. Por ejemplo, Purchase_order_events y Invoice_events.

4. Registros de eventos

Proceso de entidad única

Cuando el proceso contiene una entidad, no se necesitan transformaciones adicionales en este paso. La tabla de entidad única y las tablas de eventos ya están en el formato correcto.

Proceso de entidades múltiples

Cuando hay varias entidades involucradas en un proceso, los eventos de todas las entidades deben vincularse a la entidad principal que se considera el "Caso" en el proceso. Consulta Definir el registro de eventos para obtener más información. Los siguientes pasos describen cómo relacionar todos los eventos con la entidad principal y cómo combinarlos en un único registro de eventos.

Entity relations

Cree una tabla de "relaciones de entidad" para centralizar las relaciones entre todas las entidades. Esta tabla de relaciones de entidades contendrá los campos de ID de las entidades relacionadas.

Para crear la tabla de relaciones de entidades, una todas las tablas de entidades según sus campos de ID:

• Comenzar con la entidad principal
• Unir entidades relacionadas a la entidad principal con una unión a la izquierda.
• Si las entidades no están relacionadas directamente con la entidad principal, a la izquierda únelas a las entidades relacionadas que ya están unidas a la entidad principal.

En el siguiente ejemplo, hay tres entidades: pedido de compra,líneade factura y factura. La orden de compra se considera la entidad principal en el proceso. La línea Factura está directamente vinculada al pedido y la Factura está vinculada indirectamente a través de la línea Factura.

A continuación se muestra la tabla resultante de relaciones entre entidades.

Relation tables

Las relaciones individuales entre la entidad principal y cada entidad se almacenan en tablas separadas, utilizando la información combinada de la tabla de relaciones de entidad.

Registro de evento

El siguiente paso es usar estas relaciones para agregar el "ID de caso" correspondiente a cada tabla de eventos. El "ID de caso" se obtiene a través de la tabla de relaciones, donde la información de eventos se obtiene de la tabla de eventos. Para crear el registro de eventos completo, se unen las tablas de eventos para cada entidad.

Convencion de nombres

Si el nombre de la tabla de registro de eventos puede dar lugar a conflictos de nombres en una fase posterior, añade el sufijo  _base al nombre de las tablas de registro de eventos.

5. Lógica de negocios

En el último paso de transformación, se agrega lógica empresarial según sea necesario para el análisis de datos. Aquí se pueden añadir campos derivados adicionales a las tablas existentes. Por ejemplo, tiempos de procesamiento específicos o campos booleanos que se usan en KPI en paneles.

En Process Mining, hay dos tablas estándar adicionales definidas en este paso de transformación: Tags y Due dates.

Etiquetas

Las etiquetas son propiedades de los casos, que indican ciertas reglas empresariales. Normalmente se añaden etiquetas para facilitar el análisis de estas reglas empresariales. Por ejemplo:

• Factura pagada y aprobada por la misma persona.
• La aprobación de la factura tardó más de 10 días.
• Compruebe que se ha omitido la actividad de la factura.

Cada registro de la tabla de etiquetas representa una etiqueta que se produjo en los datos para un caso específico. Los campos obligatorios para esta tabla son el "ID de caso" y la "Etiqueta". No todos los casos tendrán una etiqueta y algunos casos pueden tener varias etiquetas. A continuación se muestra una tabla de Etiquetas de ejemplo.

Fechas límite

Las fechas límite representan plazos en el proceso. Estos se agregan a los datos para analizar si las actividades se realizan a tiempo para estas fechas límite.

Cada registro de la tabla de fechas límite representa una fecha límite para un evento determinado. Las fechas límite de ejemplo son:

• un plazo de pago para un evento de pago.
• una fecha límite de aprobación para un evento de aprobación.

Los campos obligatorios para esta tabla son Event ID, Due date, Actual datey Expected date.

No todos los eventos tendrán una fecha límite y algunos eventos pueden tener varias fechas límite.