- Notas de versão
- Antes de começar
- Introdução
- Integrações
- Como trabalhar com aplicativos de processo
- Como trabalhar com painéis e gráficos
- Como trabalhar com gráficos de processo
- Trabalhando com Descubra modelos de processo e Importar modelos BPMN
- Showing or hiding the menu
- Informações de contexto
- Exportar
- Filtros
- Envio de ideias de automação ao UiPath® Automation Hub
- Tags
- Datas de conclusão
- Comparar
- Verificação de conformidade
- Análise de causa raiz
- Simulação de Potencial de Automação
- Iniciar um projeto do Task Mining a partir do Process Mining
- Triggering an automation from a process app
- Exibição de dados do processo
- Criação de aplicativos
- Carregamento de dados
- Personalização de aplicativos de processo
- Introdução aos painéis
- Criação de painéis
- Painéis
- Gerenciador de automação
- Input data
- Definição de novas tabelas de entrada
- Adicionando campos
- Adição de tabelas
- Requisitos do modelo de dados
- Exibição e edição do modelo de dados
- Exportando e importando transformações
- Visualização dos logs de transformações
- Edição e teste de transformações de dados
- Structure of transformations
- Mesclando logs de evento
- Tips for writing SQL
- Gerenciador de processos
- Publicação de aplicativos de processos
- Modelos de apps
- Recursos adicionais
Process Mining
Tips for writing SQL
- Em uniões, os nomes e a ordem dos campos devem corresponder exatamente. Pode ser necessário criar campos vazios em partes da união para obter todos os campos alinhados, com a instrução
select
null as "Field_X"
. - Ao escrever dbt para SQL Server, todas as instruções Jinja são compiladas em código SQL, independentemente de estarem dentro de comentários SQL ou não. Por exemplo, no seguinte
-- {{ ref('Table1') }}
, o Jinja será compilado no código SQL. - Não arredonde os números, isso pode levar a inconsistências. A plataforma fará isso automaticamente sempre que um valor de exibição exigir isso.
Em SQL, nem todas as transformações podem ser calculadas na mesma tabela. A razão para isso pode ser agregados ou propriedades que não podem ser expressas em uma única declaração SELECT. Crie tabelas auxiliares para esse fim. A criação de uma tabela auxiliar no banco de dados permite usar o modelo em várias transformações. Se não for necessário reutilizar o modelo, a transformação auxiliar também pode ser adicionada como uma consulta de pré-processamento na tabela existente.
Para fazer uma distinção entre as transformações de suporte e as outras transformações, você pode agrupá-las em um subdiretório separado.
Para tornar a execução da consulta mais rápida:
-
Evite
select distinct
onde também é possível construir um agregado e apenas obter um registro usando uma cláusulawhere
. - Use
union all
em vez deunion
. Usandounion all
, os registros das tabelas são concatenados, enquantounion
remove duplicatas. - Se você estiver trabalhando em um grande conjunto de dados, poderá limitar os dados com os quais está trabalhando durante o desenvolvimento.
-
Todos os modelos (exceto os modelos no diretório
1_input
) são materializados como uma tabela por dbt. Esta é a configuração padrão para todos os Conectores do Process Mining. Para obter mais informações, consulte a documentação do dbt em Materializações. - Ao gerar um campo id, use a macro
id()
disponível em pm-utils. Exemplos podem ser encontrados no devkit-connector.
O seguinte guia de estilo foi usado para desenvolver os modelos de aplicativos do Process Mining . Recomendamos seguir estas diretrizes para obter consistência e legibilidade.
- Escreva comandos e funções SQL em letras minúsculas.
-
Use o mesmo nível de recuo para
select
,from
,where
,join
, etc., para entender a estrutura do modelo com mais facilidade.- Use o recuo para o uso de funções se melhorar a legibilidade. Por exemplo, use o recuo para cada instrução em uma função
case
.
- Use o recuo para o uso de funções se melhorar a legibilidade. Por exemplo, use o recuo para cada instrução em uma função
-
Use convenções de nomenclatura consistentes para tabelas e campos para evitar erros de SQL indicando que tabelas ou campos não existem no banco de dados. Siga as seguintes orientações:
- Tabelas e campos começam com maiúscula.
- Use um sublinhado
_
entre palavras separadas em tabelas e campos. - Todos os campos têm aspas.
- As tabelas não possuem aspas. Isso melhora a legibilidade em combinação com campos com aspas.
- Todos os campos são prefixados com a tabela de origem, para facilitar a compreensão e extensão do modelo.
- As vírgulas utilizadas para a separação dos campos são colocadas no final da linha.
- Use comentários embutidos quando certas construções precisam ser explicadas. Quando isso for feito, verifique se o comentário agrega valor.
- Para legibilidade e manutenção, use instruções de seleção explícitas na parte de transformação da consulta e não use
select *
. Especialmente para uniões, usar oselect *
pode gerar erros.