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.

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. 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.

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 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.

4. Registros de eventos

Proceso de objeto único

Cuando el proceso contiene un objeto, no se necesitan transformaciones adicionales en este paso. La tabla de un solo objeto y las tablas de eventos ya están en el formato correcto.

Proceso de varios objetos

Cuando hay varios objetos involucrados en un proceso, los eventos de todos los objetos deben vincularse al objeto principal que se considera el "Caso" en el proceso. Consulta Definir el registro de eventos para obtener más detalles. Los siguientes pasos describen cómo relacionar todos los eventos con el objeto principal y cómo combinarlos en un único registro de eventos.

Relaciones de objetos

Crea una tabla de "relaciones de objetos" para centralizar las relaciones entre todos los objetos. Esta tabla de relaciones de objetos contendrá los campos de ID de los objetos relacionados.

Para crear la tabla de relaciones de objetos, une todas las tablas de objetos en función de sus campos de ID:

• Comenzar con el objeto principal
• Unir objetos relacionados al objeto principal con una combinación izquierda.
• Si los objetos no se relacionan directamente con el objeto principal, únelos a los objetos relacionados que ya están unidos al objeto principal.

En el siguiente ejemplo, hay tres objetos: orden de compra,línea de factura y factura. La orden de compra se considera el objeto principal del proceso. La línea Factura está directamente vinculada a la Orden de compra y la Factura está vinculada indirectamente a través de la línea Factura.

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
)

La siguiente ilustración muestra la tabla de relaciones de objetos resultante.

Relation tables

Las relaciones individuales entre el objeto principal y cada uno de los objetos se almacenan en tablas separadas, utilizando la información combinada de la tabla de relaciones de objetos.

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

Registro de evento

El siguiente paso es utilizar estas relaciones para añadir 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 del evento se obtiene de la tabla de eventos. Para crear el registro de eventos completo, se unen las tablas de eventos de cada objeto.

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

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 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:

Solo se permite una tabla de etiquetas en el modelo de datos.

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:

Solo se permite una tabla de Fechas de vencimiento en el modelo de datos.