Estructura de las transformaciones

Información general

La siguiente ilustración muestra los pasos de transformación de las plantillas de aplicación de 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.
• Type cast fields to the appropriate data types.
• Filter tables to reduce data size early in the transformations.

Nota:

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

Convencion de nombres

If you expect name clashes with table names in next transformation steps, it is best practice to add the suffix _input to the input tables.

2. Entidades

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

En el siguiente ejemplo, se unen 3 tablas de entrada Invoices_input, Invoice_types_input y Customers_input para crear la tabla de entidad 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. En el siguiente ejemplo, las líneas de factura están relacionadas con la entidad de factura a través del campo Invoice_ID .

Transformaciones adicionales

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 las tablas de entidades van a dar lugar a 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 TemplateOne-SingleFile y TemplateOne-MultiFiles 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 proceso TemplateOne-SingleFile y TemplateOne-MultiFiles .

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:

• Timestamp fields: Fields on an entity table with a timestamp for an event. For example, the Invoice_created field in an Invoices table.
• 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.

Campos de marca de tiempo

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 of the entity for which the event happens. For example, the Invoice ID.
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

Nombra las tablas según la estructura [Entity] + _events. 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: Orden de compra,Línea de factura y Factura. La orden de compra se considera la entidad principal del proceso. La línea de la factura está directamente vinculada a la orden de compra y la factura está vinculada indirectamente a través de la línea de la factura.

La siguiente ilustración 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 provocar conflictos de nombres en una etapa 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 "ID de caso" y la "Etiqueta". No todos los casos tendrán una etiqueta y algunos casos pueden tener varias etiquetas. La siguiente ilustración muestra un ejemplo de tabla Etiquetas.

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:

• una fecha límite de pago para un pago.
• una fecha límite de aprobación para una orden de compra.

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.