Structure of transformations

Información general

La siguiente ilustración muestra los pasos de transformación de las plantillas de la aplicación Process Mining .

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

Nota:

Las plantillas de aplicación Registro de eventos y Proceso personalizado tienen una estructura de transformaciones de datos simplificada. Las aplicaciones de proceso creadas con estas plantillas de aplicación no tienen esta estructura de carpetas.

1. Objetos

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

En el siguiente ejemplo, se unen 3 tablas de entrada Invoices_input, Invoice_types_input y Customers_input para crear la tabla de objetos Facturas.

Directrices

Sigue estas directrices al crear una tabla de objetos.

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

Cuando corresponda, la tabla de objetos se relaciona con otro objeto a través de un campo de ID. En el siguiente ejemplo, las líneas de factura están relacionadas con el objeto de factura a través del campo Invoice_ID .

Additional transformations

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

Convencion de nombres

Si los nombres de las tablas de objetos dan lugar a conflictos de nombres más adelante, añade el sufijo _base a las tablas.

2. Eventos

Nota: La entrada para las plantillas de aplicación Registro de eventos y 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.

En este paso de transformación, se crean tablas de eventos para cada objeto. 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:

• Campos de marca de tiempo: campos en una tabla de objetos 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 pueden fusionarse en una sola tabla de eventos por objeto, por ejemplo Invoices_events.

Registro de transacción

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

En el siguiente ejemplo, el registro de transacciones contiene eventos para los objetos 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
IdDeObjeto	ID del objeto para el que ocurre el evento. Por ejemplo, el ID de la factura.
Actividades	La actividad describe qué acción tuvo lugar en el objeto.
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 [Activity] + _events para crear un archivo de eventos por actividad, o [Object] + _events para crear un archivo de eventos por objeto. Por ejemplo, Purchase_order_created_events, Purchase_order_approved_events o un archivo con todas las actividades de orden de compra combinadas Purchase_order_events.

3. Business logic

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 objetos, que significan ciertas reglas empresariales. Las etiquetas se suelen añadir 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  Object ID y  Tag. No todos los objetos tendrán una etiqueta y algunos objetos pueden tener varias etiquetas. La siguiente ilustración muestra un ejemplo de tabla de etiquetas.

Nota:

Similar to Events, multiple Tags tables can be present in the data model.

Convencion de nombres

Name the tables according to the structure [Tag] + _tags to create one file per tag, or [Object] + _tags to create one file per object. For example Invoice_approved_and_paid_by_same_person_tags, Invoice_approval_too_late_tags, or one file with all invoice tags combined Invoice_tags.

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 de vencimiento representa una fecha de vencimiento para un objeto determinado. Ejemplos de fechas de vencimiento 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 Object ID, Due date, Actual datey Expected date.

Nota:

Similar to Events, multiple Due dates tables can be present in the data model.

Convenciones de nombres

Name the tables according to the structure [Due date] + _due_dates to create one file per due date, or [Object] + _due_dates to create one file per object. For example Payment_deadline_due_dates, Payment_deadline_with_discount_due_dates, or one file with all invoice due dates combined Payment_due_dates.