Structure of transformations

Visão geral

A ilustração a seguir mostra as etapas de transformação dos modelos de aplicativos do Process Mining .

A pasta models\ na seção Transformações de Transformações de dados é organizada de acordo com a estrutura das etapas de transformação.

1. Entrada

A etapa de entrada é usada para carregar os dados brutos. As seguintes operações são normalmente feitas para preparar os dados para as próximas etapas de transformação:

• Selecione campos com a macro opcional e obrigatória. Um campo não precisa estar presente nos dados brutos quando a macro opcional é usada.
• Digite campos de conversão para os tipos de dados apropriados.

• Filtre as tabelas para reduzir o tamanho dos dados no início das transformações.

Nota: Recomenda-se reduzir o tamanho dos dados já na extração sempre que possível.

Convenção de nomenclatura

Se você espera que os nomes entrem em conflito com os nomes de tabelas nas próximas etapas de transformação, uma prática recomendada é adicionar o sufixo _input às tabelas de entrada.

Campos opcionais

A entrada de um conector consiste em dados obrigatórios e opcionais. Para campos opcionais, a macro optional do pacote pm-utils deve ser usada. Isso garante que um campo obtenha o valor null caso não esteja disponível nos dados de origem. Dessa forma, todas as transformações serão executadas corretamente.

• Use a macro optional_table() se toda a tabela for opcional.

2. Objetos

Na etapa Objeto, as tabelas de entrada são transformadas em tabelas de objeto. Cada objeto necessário para os eventos esperados deve ter sua própria tabela. Consulte Criação de um log de evento. Além disso, o objeto de suporte também pode ser definido aqui.

No exemplo a seguir, três tabelas de entrada Invoices_input, Invoice_types_input e Customers_input são unidas para criar a tabela de objeto Faturas.

Diretrizes

Siga estas diretrizes ao criar uma tabela de objetos.

• Há um campo de ID do objeto, que é exclusivo para cada registro de dados.
• Todos os campos do objeto necessários para a análise de dados estão presentes.
• Todos os campos do objeto têm nomes que são fáceis de entender.

Quando aplicável, a tabela de objeto se relaciona com outro objeto por meio de um campo de ID. No exemplo a seguir, as linhas da fatura estão relacionadas ao objeto Fatura por meio do campo Invoice_ID .

Additional transformations

Nem todas as tabelas de entrada são transformadas em tabelas de objeto. Além disso, outras tabelas de entrada podem conter informações relevantes, como a tabela Customers, no exemplo. Pode ser conveniente defini-los na etapa Objetos como tabelas separadas, para que eles possam ser reutilizados nas transformações de dados.

Convenção de nomenclatura

Se os nomes das tabelas do objeto causarem conflito de nomes posteriormente, adicione o sufixo _base às tabelas.

3. Eventos

Observação: a entrada para modelos de aplicativos Log de evento e Processo personalizado já é um log de evento bem definido para o Process Mining. Não há necessidade de transformar os dados do sistema de origem nos eventos para o Process Mining aqui. Isso significa que o 3. events não está presente nas transformações para aplicativos Log de evento e Processo personalizado.

Nesta etapa de transformação, as tabelas de eventos são criadas para cada objeto. Confira Criando um log de evento. Cada registro em uma tabela de evento representa um evento que ocorreu. Há dois cenários sobre como os dados são estruturados:

• Campos de carimbo de data/hora: campos em uma tabela de objeto com um carimbo de data/hora de um evento. Por exemplo, o campo Invoice_created em uma tabela Invoices .
• Log de transações: uma lista de eventos.

Com base em como os dados são estruturados, as transformações para criar as tabelas de eventos são diferentes.

Timestamp fields

Nesse cenário, os valores de um campo de carimbo de data/hora devem ser transformados em registros separados em uma tabela de eventos. O exemplo a seguir é uma tabela de faturas que contém três campos de carimbo de data/hora.

Cada campo de carimbo de data/hora é usado para criar uma tabela de eventos separada. Para cada registro que o campo carimbo de data/hora contém um valor, crie uma tabela com o ID da Nota Fiscal, o nome do evento (Atividade) e o carimbo de data/hora em que o evento ocorreu (Fim do evento).

O Invoices_input table é dividido em Invoice_events_Create_invoice, Invoice_events_Delete_invoicee Invoices_events_Change_invoice_price.

As tabelas de eventos separadas podem ser mescladas em uma única tabela de eventos por objeto, por exemplo, Invoices_events.

Log de transação

Se os eventos forem armazenados em um log de transações, os eventos relevantes por objeto devem ser identificados. Crie uma tabela por objeto e armazene o ID do objeto correspondente, o nome do evento (Atividade) e o carimbo de data/hora em que o evento ocorreu (Fim do evento).

No exemplo a seguir, o log de transações contém eventos para os objetos Ordem de Compra e Fatura .

Os seguintes campos são obrigatórios em uma tabela de eventos. Todos os registros nas tabelas de eventos devem conter um valor para esses campos.

Campo	Description
ID do Objeto	ID do objeto para o qual o evento acontece. Por exemplo, o ID da fatura.
Atividade	A atividade descreve qual ação ocorreu no objeto.
Event end	O campo de término do evento indica quando o evento específico foi concluído. Idealmente, este deve ser um campo de data e hora, em vez de uma data.

Convenção de nomenclatura

Nomeie as tabelas de acordo com o [Activity] + _events para criar um arquivo de evento por atividade ou [Object] + _events para criar um arquivo de evento por objeto. Por exemplo, Purchase_order_created_events, Purchase_order_approved_events ou um arquivo com todas as atividades de ordem de compra combinadas Purchase_order_events.

4. Logs de evento

Processo de objeto único

Quando o processo contém um objeto, nenhuma transformação adicional é necessária nesta etapa. As tabelas de objeto único e de eventos já estão no formato correto.

Processo de vários objetos

Quando vários objetos estão envolvidos em um processo, os eventos de todos os objetos precisam estar vinculados ao objeto principal, que é considerado o "Caso" no processo. Consulte Definir o log de evento para obter detalhes. As etapas a seguir descrevem como relacionar todos os eventos ao objeto principal e como combiná-los em um único log de evento.

Relacionamentos de objeto

Crie uma tabela "relações de objeto" para centralizar as relações entre todos os objetos. Essa tabela de relações de objetos conterá os campos de ID dos objetos relacionados.

Para criar a tabela de relações de objetos, associe todas as tabelas de objetos com base em seus campos de ID:

• Comece com o objeto principal
• Una objetos relacionados ao objeto principal com um left join.
• Se os objetos não estiverem relacionados diretamente ao objeto principal, à esquerda, vincule-os aos objetos relacionados que já estão associados ao objeto principal.

No exemplo a seguir, há três objetos: Ordem de compra,Linha da fatura e Fatura. A Ordem de compra é considerada o objeto principal no processo. A linha de fatura está diretamente vinculada à ordem de compra e a fatura está vinculada indiretamente por meio da linha da fatura.

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
)

A ilustração a seguir mostra a tabela de relações de objetos resultante.

Relation tables

As relações individuais entre o objeto principal e cada outro objeto são armazenadas em tabelas separadas, usando as informações combinadas da tabela de relações entre 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"
)

Log de Evento

O próximo passo é usar essas relações para adicionar o “ID do caso” correspondente a cada tabela de evento. O "ID do caso" é obtido através da tabela de relação, onde as informações de evento são obtidas da tabela de evento. Para criar o log de evento completo, as tabelas de evento para cada objeto são unidas.

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

Convenção de nomenclatura

Se o nome da tabela de log de eventos puder levar a conflitos de nomes em um estágio posterior, adicione o sufixo  _base ao nome das tabelas de log de eventos.

5. Lógica de negócios

Na última etapa de transformação, a lógica de negócios é adicionada conforme necessário para a análise de dados. Campos derivados adicionais podem ser adicionados a tabelas existentes aqui. Por exemplo, tempos de rendimento específicos ou campos booleanos usados em KPIs em painéis.

No Process Mining, há duas tabelas padrão adicionais definidas nesta etapa de transformação: Tags e Due dates.

Tags

As tags são propriedades de objetos, que significam certas regras de negócios. As tags normalmente são adicionadas para facilitar a análise dessas regras de negócios. Por exemplo:

• Fatura paga e aprovada pela mesma pessoa.
• A aprovação da fatura demorou mais de 10 dias.
• Verifique a atividade da fatura ignorada.

Cada registro na tabela de tags representa uma tag que ocorreu nos dados para um caso específico. Os campos obrigatórios para essa tabela são o  Object ID e o  Tag. Nem todos os objetos terão uma tag e alguns objetos podem ter várias tags. A ilustração a seguir mostra um exemplo de uma tabela de Tags.

Observação:

Apenas uma tabela de Tags é permitida no modelo de dados.

Datas de conclusão

As datas de vencimento representam prazos no processo. Estes são adicionados aos dados para analisar se as atividades são executadas a tempo para essas datas de vencimento ou não.

Cada registro na tabela de datas de conclusão representa uma data de conclusão para um determinado objeto. Alguns exemplos de datas de conclusão são:

• um prazo de pagamento para um pagamento.
• um prazo de aprovação para uma ordem de compra.

Os campos obrigatórios para esta tabela são Object ID, Due date, Actual datee Expected date.

Observação:

Apenas uma tabela de Datas de vencimento é permitida no modelo de dados.