- Notas relacionadas
- Antes de empezar
- Primeros pasos
- Integraciones
- Trabajar con apps de proceso
- Trabajar con paneles y diagramas
- Trabajar con diagramas de proceso
- Trabajar con modelos de proceso Descubrir e Importar modelos BPMN
- Showing or hiding the menu
- Información del contexto
- Exportar
- Filtros
- Envío de ideas de automatización a UiPath® Automation Hub
- Etiquetas
- Fechas límite
- Comparar
- Comprobación de conformidad
- Análisis de causa raíz
- Simular el potencial de automatización
- Iniciar un proyecto de Task Mining desde Process Mining
- Triggering an automation from a process app
- Ver datos del proceso
- Creación de aplicaciones
- Cargar datos
- Personalizar apps de proceso
- Introducción a los paneles
- Crear paneles
- Paneles
- Gestor de automatización
- Input data
- Definición de nuevas tablas de entrada
- Añadir campos
- Añadir tablas
- Requisitos del modelo de datos
- Ver y editar el modelo de datos
- Exportar e importar transformaciones
- Ver los registros de transformaciones
- Editar y probar transformaciones de datos
- Structure of transformations
- Combinar registros de eventos
- Tips for writing SQL
- Gestor de procesos
- Publicar aplicaciones de proceso
- Plantillas de la aplicación
- Recursos adicionales
Process Mining
Tips for writing SQL
- En las uniones, los nombres y el orden de los campos deben coincidir exactamente. Puede que sea necesario crear campos vacíos en partes de la unión para alinear todos los campos con la instrucción
select
null as "Field_X"
. - Al escribir dbt para SQL Server, todas las declaraciones de Jinja se compilan en código SQL, independientemente de si están dentro de comentarios SQL o no. Por ejemplo, en el siguiente
-- {{ ref('Table1') }}
, el Jinja se compilará en código SQL. - No redondee los números, esto puede dar lugar a inconsistencias. La plataforma lo hará automáticamente siempre que un valor de visualización lo requiera.
En SQL, no todas las transformaciones pueden calcularse en la misma tabla. Esto puede deberse a agregados o propiedades que no pueden expresarse en una sola sentencia de selección. Para ello se pueden crear tablas de apoyo. Crear una tabla de apoyo en la base de datos permite utilizar el modelo en múltiples transformaciones. Si no es necesario reutilizar el modelo, la transformación de apoyo también puede añadirse como consulta de preprocesamiento en la tabla existente.
Para hacer una distinción entre las transformaciones compatibles y las otras transformaciones, puedes agruparlas en un subdirectorio independiente.
Para hacer que la ejecución de su consulta sea más rápida:
-
Evite
select distinct
donde también es posible crear un agregado y solo tomar un registro con una cláusulawhere
. - Utilice
union all
en lugar deunion
. Usandounion all
, los registros de las tablas se concatenan, mientras queunion
elimina los duplicados. - Si trabajas en un gran conjunto de datos, puedes limitar los datos con los que trabajas durante el desarrollo.
-
Todos los modelos (excepto los modelos en el directorio
1_input
) se materializan como una tabla por dbt. Esta es la configuración predeterminada para todos los conectores de Process Mining. Para obtener más información, consulta la documentación de dbt sobre Materializaciones. - Al generar un campo de ID, utiliza la macro
id()
disponible en pm-utils. Se pueden encontrar ejemplos en devkit-connector.
La siguiente guía de estilo se utilizó para desarrollar las plantillas de la aplicación Process Mining . Se recomienda seguir estas directrices para mantener la coherencia y la legibilidad.
- Escribir comandos y funciones SQL en minúsculas.
-
Utiliza el mismo nivel de sangría para
select
from
,where
,join
, etc., para comprender más fácilmente la estructura del modelo.- Utiliza sangría para el uso de funciones si esto mejora la legibilidad. Por ejemplo, utiliza la sangría para cada sentencia de una función
case
.
- Utiliza sangría para el uso de funciones si esto mejora la legibilidad. Por ejemplo, utiliza la sangría para cada sentencia de una función
-
Utiliza convenciones de nomenclatura coherentes para tablas y campos para evitar errores de SQL que indiquen que las tablas o los campos no existen en la base de datos. Siga las siguientes pautas:
- Las tablas y los campos comienzan con mayúscula.
- Utiliza un guion bajo
_
entre palabras separadas en tablas y campos. - Todos los campos tienen comillas.
- Las tablas no tienen comillas. Esto mejora la legibilidad en combinación con los campos que tienen comillas.
- Todos los campos tienen el prefijo de la tabla en la que se originan, para facilitar la comprensión y la ampliación del modelo.
- Las comas utilizadas para la separación de campos se colocan al final de la línea.
- Use comentarios en línea cuando necesite explicar ciertas construcciones. Una vez hecho esto, asegúrese de que el comentario agregue valor.
- Para facilitar la lectura y el mantenimiento, usa instrucciones seleccionar explícitas en la parte de transformación de la consulta y no uses
select *
. Especialmente para las uniones, el uso deselect *
puede producir errores.