- Notes de publication
- Avant de commencer
- Démarrage
- Intégrations
- Travailler avec des applications de processus
- Travailler avec des tableaux de bord et des graphiques
- Travailler avec des graphiques de processus
- Travailler avec des modèles de processus Découvrir et importer des modèles BPMN
- Showing or hiding the menu
- Informations contextuelles
- Exporter (Export)
- Filtres
- Envoi d’idées d’automatisation au Automation Hub d’UiPath®
- Balises
- Dates d’échéance
- Comparer
- Vérification de la conformité
- Analyse des causes profondes
- Simulation du potentiel d’automatisation
- Triggering an automation from a process app
- Afficher les données de processus
- Création d'applications
- Chargement des données
- Personnaliser les applications de processus
- Introduction aux tableaux de bord
- Créer des tableaux de bord
- Tableaux de bord
- Gestionnaire de l’automatisation
- Input data
- Définition de nouvelles tables d'entrée
- Ajout de champs
- Ajouter des tables
- Configuration requise pour le modèle de données
- Affichage et modification du modèle de données
- Exportation et importation de transformations
- Modification et test des transformations de données
- Structure of transformations
- Fusion des journaux d'événements
- Tips for writing SQL
- Gestionnaire de processus
- Publication des tableaux de bord
- Modèles d'applications
- Ressources supplémentaires
Tips for writing SQL
- Dans les unions, les noms et l'ordre des champs doivent correspondre exactement. Il peut être nécessaire de créer des champs vides sur des parties de l'union pour aligner tous les champs, avec l'instruction {
select
null as "Field_X"
. - Lors de l'écriture de dbt pour SQL Server, toutes les instructions Jinja sont compilées en code SQL, qu'elles se trouvent ou non dans des commentaires SQL. Par exemple, dans le
-- {{ ref('Table1') }}
suivant, le Jinja sera compilé en code SQL. - N’arrondissez pas les nombres, cela peut entraîner des incohérences. La plate-forme le fera automatiquement chaque fois qu'une valeur d'affichage l'exigera.
Dans SQL, il est possible que toutes les transformations ne soient pas être calculées dans une même table. Cela peut être causé par des agrégats ou des propriétés qui ne peuvent pas être exprimés dans une seule instruction select. Vous pouvez créer des tables support à cette fin. La création d'une table support dans la base de données vous permet d'utiliser le modèle dans plusieurs transformations. S'il n'est pas nécessaire de réutiliser le modèle, la transformation support peut également être ajoutée en tant que requête de prétraitement dans la table existante.
Pour faire la distinction entre les transformations de prise en charge et les autres transformations, vous pouvez les regrouper dans un sous-répertoire distinct.
Pour accélérer l'exécution de votre requête :
-
Évitez
select distinct
où il est également possible de créer un agrégat et de ne prendre qu’un seul enregistrement à l’aide d’une clausewhere
. - Utilisez
union all
au lieu deunion
. À l'aide deunion all
, les enregistrements des tables sont concaténés, tandis queunion
supprime les doublons. - Si vous travaillez sur un ensemble de données volumineux, vous pouvez limiter les données avec lesquelles vous travaillez pendant le développement.
-
Tous les modèles (à l'exception des modèles du répertoire
1_input
) sont matérialisés sous forme de table par dbt. Ce sont les paramètres par défaut de tous les connecteurs Process Mining. Pour plus d'informations, consultez la documentation dbt sur les matérialisations. - Lors de la génération d'un champ id, utilisez la macro
id()
disponible dans pm-utils. Des exemples peuvent être trouvés dans le devkit-connector.
Le guide de style suivant a été utilisé pour développer les modèles d'application Process Mining . Il est recommandé de suivre ces directives pour une cohérence et une lisibilité.
- Écrivez les commandes et les fonctions SQL en minuscules.
-
Utilisez le même niveau de retrait pour
select
,from
,where
,join
, etc., afin de comprendre plus facilement la structure du modèle.- Utilisez l'indentation pour l'utilisation des fonctions si cela améliore la lisibilité. Par exemple, utilisez le retrait pour chaque instruction dans une fonction
case
.
- Utilisez l'indentation pour l'utilisation des fonctions si cela améliore la lisibilité. Par exemple, utilisez le retrait pour chaque instruction dans une fonction
-
Utilisez des conventions de dénomination cohérentes pour les tables et les champs afin d'éviter les erreurs SQL indiquant que les tables ou les champs n'existent pas dans la base de données. Respectez les directives suivantes :
- Les tables et les champs commencent par une majuscule.
- Utilisez un trait de soulignement
_
entre des mots distincts dans les tables et les champs. - Tous les champs comportent des guillemets.
- Les tableaux ne contiennent pas de guillemets. Cela améliore la lisibilité en combinaison avec des champs comportant des guillemets.
- Tous les champs sont précédés de la table dont ils proviennent, pour rendre le modèle plus facile à comprendre et à étendre.
- Les virgules utilisées pour la séparation des champs sont placées à la fin de la ligne.
- Utilisez des commentaires en ligne lorsque certaines constructions doivent être expliquées. Lorsque cela est fait, assurez-vous que le commentaire ajoute de la valeur.
- Pour plus de lisibilité et de facilité de maintenance, utilisez des instructions de sélection explicites dans la partie transformation de la requête et n'utilisez pas
select *
. En particulier pour les syndicats, l'utilisation deselect *
peut générer des erreurs.