Structure of transformations

Visão geral

Abaixo está uma visão geral das etapas de transformação dos modelos de aplicativos do Process Mining .

A pasta models\ é 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. Entidades

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

No exemplo abaixo, 3 tabelas de entrada Invoices_input, Invoice_types_inpute Customers_input são unidas para criar a tabela de entidades Faturas.

Diretrizes

Siga estas diretrizes ao criar uma tabela de entidades.

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

Quando aplicável, a tabela de entidade se relaciona com outra entidade por meio de um campo de ID. Consulte o exemplo abaixo, onde as linhas da fatura estão relacionadas à entidade da fatura por meio do campo Invoice_ID .

Additional transformations

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

Convenção de nomenclatura

Se os nomes das tabelas de entidades levarem a conflitos 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, tabelas de evento são criadas para cada entidade. Consulte Criação de 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 entidade com um carimbo de data/hora para 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

Neste cenário, os valores de um campo timestamp devem ser transformados em registros separados em uma tabela de eventos. O exemplo abaixo é uma tabela de faturas que contém três campos de registro de data e 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 entidade, por exemplo Invoices_events.

Log de transação

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

No exemplo abaixo, o log de transações contém eventos para as entidades Pedido 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 da entidade	ID da entidade para a qual o evento acontece. Por exemplo, o ID da fatura.
Atividade	A atividade descreve qual ação ocorreu na entidade.
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 a estrutura [Entity] + _events. Por exemplo, Purchase_order_events e Invoice_events.

4. Logs de evento

Processo de entidade única

Quando o processo contém uma entidade, nenhuma transformação adicional é necessária nesta etapa. A tabela de entidade única e as tabelas de eventos já estão no formato correto.

Processo de entidade múltipla

Quando várias entidades estão envolvidas em um processo, os eventos de todas as entidades precisam estar vinculados à entidade principal, que é considerada o "Caso" no processo. Consulte Definir o log de evento para obter detalhes. As etapas abaixo descrevem como relatar todos os eventos à entidade principal e como combiná-los em um único log de evento.

Entity relations

Crie uma tabela de “relações de entidades” para centralizar os relacionamentos entre todas as entidades. Essa tabela de relações de entidade conterá os campos de ID das entidades relacionadas.

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

• Comece com a entidade principal
• Una entidades relacionadas à entidade principal com uma junção à esquerda.
• Se as entidades não se relacionam diretamente com a entidade principal, deixe uni-las às entidades relacionadas que já estão associadas à entidade principal.

No exemplo abaixo, existem três entidades: Ordem de compra,Linha da faturae Fatura. A Ordem de Compra é considerada a principal entidade do processo. A linha da Fatura está diretamente vinculada ao Pedido de Compra e a Fatura está vinculada indiretamente por meio da linha da Fatura.

Abaixo está a tabela de relações de entidade resultante.

Relation tables

As relações individuais entre a entidade principal e cada outra entidade são armazenadas em tabelas separadas, usando as informações combinadas da tabela de relações entre entidades.

Log de Evento

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

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

Tags são propriedades de casos, que significam certas regras de negócios. Normalmente, as tags 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 desta tabela são o "Case ID" e o "Tag". Nem todos os casos terão uma tag e alguns casos podem ter várias tags. Abaixo está um exemplo de tabela de Tags.

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 vencimento representa uma data de vencimento para um determinado evento. Exemplos de datas de vencimento são:

• um prazo de pagamento para um evento de pagamento.
• um prazo de aprovação para um evento de aprovação.

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

Nem todos os eventos terão uma data de vencimento e alguns eventos podem ter várias datas de vencimento.