> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/analytics/fr/iot-query/schema-overview/transformation-layer/transformation-builder.md). # Transformation Builder Créez des transformations IoT Query personnalisées avec un éditeur visuel de workflow. Configurez les nœuds SQL, prévisualisez les résultats, validez les workflows et planifiez les exécutions {% hint style="info" %} #### Bientôt disponible ! Transformation Builder est actuellement en développement. La description de la fonctionnalité sur cette page reflète la fonctionnalité prévue. Les détails de mise en œuvre peuvent évoluer avant la version finale. Si vous êtes intéressé par un accès anticipé ou si vous avez des questions, contactez . {% endhint %} ## Ce qu'est Transformation Builder **Transformation Builder** est un outil visuel permettant de concevoir des workflows de transformation de données sans avoir à développer et maintenir des pipelines de données complexes. Vous assemblez la logique de traitement sous forme de graphe où chaque étape est représentée par un bloc distinct (Nœud), et l'outil compile votre graphe en SQL exécutable. Transformation Builder est conçu pour les analystes, les spécialistes BI et toute personne ayant des connaissances de base en SQL qui souhaite contrôler indépendamment la logique de préparation des données. Il vous aide à répondre aux questions clés de la préparation des données : d'où viennent les données, comment elles sont jointes, quels filtres et transformations sont appliqués, comment les séries temporelles sont agrégées et sous quelle forme les données doivent apparaître dans la [Couche de transformation](/docs/analytics/fr/iot-query/schema-overview/transformation-layer.md). Transformation Builder n'est pas un orchestrateur ETL complet ni une plateforme de données. C'est un concepteur de workflows ciblé qui compile votre graphe de Nœud en une requête SQL et une fonction de base de données planifiée. Des modèles de workflows préétablis pour les transformations courantes de Navixy sont disponibles sur la [Modèles](/docs/analytics/fr/iot-query/schema-overview/transformation-layer/transformation-builder/templates.md) page. ## Comment cela fonctionne Un workflow dans Transformation Builder est un graphe dirigé de Nœud organisé de Source de données vers la sortie :
workflow graph example showing sources, transformations, and output

Source de données brutes → Nœuds de transformation → Sortie

Chaque Nœud correspond à une étape logique de traitement. Vous pouvez combiner plusieurs sources dans un seul Nœud de transformation, et le résultat d'un Nœud peut alimenter plusieurs Nœuds en aval. Le graphe vous offre une représentation visuelle claire de l'ensemble du flux de données, des tables sources jusqu'à l'entité analytique cible. Le Builder compile votre graphe en une seule requête SQL à l'aide d'expressions de table communes (CTE). Chaque Nœud devient un CTE dans la requête finale. Cette approche de compilation signifie que le Builder n'écrit pas directement les données dans la base de données. À la place, il génère une configuration qui exécute le traitement réel des données selon un calendrier. {% hint style="warning" %} Les données du graphe doivent circuler dans une seule direction. Les cycles ne sont pas autorisés. Si le Builder détecte un cycle, il renvoie une erreur de validation. {% endhint %} ### Connexion à la base de données Avant de commencer à créer un workflow, vous devez vous connecter à votre base de données PostgreSQL. Sans connexion active, l'aperçu des données et la découverte des tables ne sont pas disponibles. Le panneau de connexion vous permet de spécifier votre [URL de connexion](/docs/analytics/fr/iot-query/connection-setup.md#connection-string-format), de vous connecter ou de vous déconnecter, et de voir le nombre de tables trouvées dans chaque catégorie. Le Builder utilise deux schémas dans votre base de données : * `raw_telematics_data` pour la télématique et les Données du capteur de l'appareil * `raw_business_data` pour les données de référence métier (Véhicules, employés, géofences et entités similaires) Une fois connecté, le Builder détecte automatiquement les tables et colonnes disponibles, que vous pouvez ensuite sélectionner lors de la configuration des Nœuds de Source de données.
connection panel showing URL input and discovered table counts
### Nœuds de Source de données Les Nœuds de Source de données définissent d'où votre workflow lit les données. Chaque Nœud source correspond à une table de la couche Données brutes.
Données brutes : Télématique Ce Nœud charge des données de séries temporelles depuis le `raw_telematics_data` schéma. | Paramètre | Description | | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | **Nom de la table** | Sélectionnez dans la liste des tables découvertes lorsque vous vous êtes connecté à la base de données. | | **Colonne de temps** | La colonne d'horodatage utilisée pour le tri et les filtres basés sur le temps. Valeur par défaut : `device_time`. | | **Colonnes** | Liste des colonnes spécifiques à inclure, ou `*` pour sélectionner toutes les colonnes. | | **Condition de filtre** | SQL facultatif `WHERE` condition appliquée directement à la requête source. | | **Minutes de fenêtre temporelle** | Limite de temps facultative (en minutes) pour restreindre la fenêtre de données en SQL. Laissez vide pour aucune limite. | Chaque Nœud Données brutes : Télématique lit exactement une table. Pour utiliser des données provenant de plusieurs tables, ajoutez un Nœud distinct pour chaque table.
Données brutes : Business Ce nœud charge les données de référence depuis le `raw_business_data` schéma. Les tables typiques comprennent `objets`, `véhicules`, `appareils`, et `description_du_capteur`. | Paramètre | Description | | ------------------- | --------------------------------------------------------------------------------------- | | **Nom de la table** | Sélectionnez dans la liste des tables métiers découvertes. | | **Colonne clé** | La colonne clé de cette table (par exemple, `id_objet` ou `identifiant_capteur`). | | **Colonnes** | Liste des colonnes spécifiques à inclure, ou `*` pour sélectionner toutes les colonnes. | Données brutes : les nœuds métier sont principalement utilisés comme deuxième entrée pour le nœud SQL Transform, ce qui vous permet de joindre des données de référence avec des séries temporelles télématiques.
### Nœuds de transformation Les nœuds de transformation définissent ce qui se passe à vos données après leur chargement depuis les sources. Chaque type de transformation gère un modèle de traitement spécifique.
Transformation SQL Combine les données provenant de exactement deux nœuds source à l’aide de SQL `JOIN` opération. | Paramètre | Description | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Type de jointure** | Le type de jointure : `INTERNE`, `GAUCHE`, `DROITE`, ou `COMPLÈTE` (jointure externe complète). | | **Condition de jointure** | La condition pour faire correspondre les lignes entre les deux entrées (par exemple, correspondance sur `ID de l'appareil`). | | **Sélectionner des colonnes** | Liste des colonnes à inclure dans la sortie. Prend en charge une notation de préfixe telle que `source.*` pour sélectionner toutes les colonnes d'une entrée spécifique. | La transformation SQL nécessite exactement deux entrées. Les entrées peuvent être n'importe quelle combinaison de nœuds Source de données ou de sorties d'autres nœuds de transformation.
Filtre Filtre les données selon une plage temporelle et des conditions personnalisées. Toutes les conditions sont exécutées dans la base de données dans le cadre de la `WHERE` clause (filtrage poussé). | Paramètre | Description | | -------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | **Colonne de temps** | La colonne d'horodatage à utiliser pour le filtrage temporel. Par défaut, à `device_time`. | | **Début / fin de la plage temporelle** | Bornes de début et de fin pour le filtre temporel. | | **Conditions dynamiques** | Une liste de conditions SQL combinées avec `AND`. Utilisez-les pour un filtrage supplémentaire au-delà de l'intervalle de temps. |
Rééchantillonnage Agrège les données de séries chronologiques en intervalles de temps fixes. C'est utile pour convertir des points de données à haute fréquence en statistiques récapitulatives sur des périodes régulières. | Paramètre | Description | | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Colonne de temps** | La colonne d'horodatage à utiliser pour le regroupement par intervalle. La valeur par défaut est `device_time`. | | **Intervalle** | L’intervalle d’agrégation : `1 min`, `5 min`, `15 min`, `1 heure`, ou `1 jour`. | | **Grouper par** | Colonnes supplémentaires à regrouper (en plus de l’intervalle de temps). | | **Agrégations** | Une liste de paires colonne-méthode définissant la manière dont chaque colonne est agrégée. Méthodes disponibles : `moy`, `somme`, `min`, `max`, `premier`, `dernier`, `compte`. |
Arithmétique Ajoute ou remplace des colonnes à l’aide d’expressions SQL. Utilisez ce Nœud pour créer des colonnes calculées à partir de données existantes. | Paramètre | Description | | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | **Expressions** | Une liste de définitions d’expressions. Chaque entrée comprend une colonne source facultative, une expression SQL et un alias de sortie obligatoire. | Par exemple, pour convertir une valeur de vitesse, vous pouvez définir la colonne source sur `speed`, l’expression sur `vitesse * 1.2`, et l’alias sur `vitesse_ajustée`. L’alias est obligatoire pour chaque expression.
SQL personnalisé Fournit une entrée SQL libre pour une logique complexe que les autres types de Nœud ne peuvent pas exprimer. Utilisez-la lorsque vous avez besoin d’un contrôle total sur la requête. | Paramètre | Description | | -------------------- | ----------------------------------------------------------------------------------------------- | | **SQL personnalisé** | A `Sélectionner` requête dans laquelle les Nœuds en amont sont accessibles par leurs alias CTE. | Les alias des Nœuds sources suivent le modèle `a_` (par exemple, `a_nœud_1`, `a_filtre_1`). Les identifiants de Nœud sont normalisés en identifiants SQL valides, les espaces et les caractères spéciaux étant remplacés par des traits de soulignement. Les Nœuds SQL personnalisés acceptent une ou deux entrées. Votre requête peut référencer les CTE correspondantes par leurs alias.
### Configuration de sortie
Sortie Le **Sortie** Nœud définit la manière dont les résultats de votre transformation doivent être écrits dans la couche Transformation. Il spécifie les métadonnées de la table cible que l’environnement d’exécution externe utilise pour stocker les données traitées. | Paramètre | Description | | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Nom de la table** | Le nom de la table cible dans `données_personnalisées_traitées` schéma. | | **Colonne de temps** | La colonne d’horodatage dans les données de sortie (par exemple, `device_time`). | | **Partitionner par** | Une expression de partitionnement pour organiser les données stockées (par exemple, `DATE(heure_appareil)`). | | **Clé primaire** | Une liste de colonnes qui identifient de manière unique chaque ligne (par exemple, `[device_id, device_time]`). | | **Mode d'écriture** | Comment les données sont écrites dans la table cible : `ajout` (ajouter de nouvelles lignes), `écrasement` (remplacer les données existantes), ou `upsert` (mettre à jour les lignes existantes, en insérer de nouvelles). |
## Construire un workflow Un workflow type suit ces étapes : {% stepper %} {% step %} **Ouvrez le Builder de transformation** Lancez l'interface du Builder de transformation. {% endstep %} {% step %} **Connectez-vous à votre base de données** Saisissez votre URL de connexion PostgreSQL et établissez la connexion. Le Builder détecte automatiquement les tables et colonnes disponibles. {% endstep %} {% step %} **Ajoutez des nœuds Source de données** Ajoutez un [**Données brutes : Télématique**](#raw-data-telematics) nœud et sélectionnez la table et les colonnes avec lesquelles vous souhaitez travailler. Si vous avez besoin de données de référence (par exemple, des détails sur les véhicules ou des descriptions de capteurs), ajoutez aussi un [**Données brutes : Business**](#raw-data-business) nœud. {% endstep %} {% step %} **Ajoutez des nœuds de transformation** Insérez les nœuds de transformation requis par votre workflow : * [**Transformation SQL**](#sql-transform) pour joindre les données * [**Filtre**](#filter) pour restreindre les résultats * [**Rééchantillonnage**](#resampling) pour agréger des séries temporelles * [**Arithmétique**](#arithmetic) pour ajouter des colonnes calculées * [**SQL personnalisé**](#custom-sql) pour une logique complexe. {% endstep %} {% step %} **Configurez le nœud de sortie** Ajoutez [Sortie](#output) un nœud et définissez le nom de la table cible, les colonnes de clé primaire et le mode d'écriture pour votre entité analytique. {% endstep %} {% step %} **Connectez les nœuds** Tracez des arêtes entre les nœuds pour définir le flux de données. Connectez les nœuds sources aux nœuds de transformation, et les nœuds de transformation au nœud de sortie. Le flux de données va de gauche à droite, des sources vers la sortie. {% endstep %} {% step %} **Vérifiez et corrigez les erreurs** Consultez les indications de validation pour tout problème de configuration. Corrigez les erreurs dans les paramètres des nœuds ou dans la structure du graphe, si nécessaire. {% endstep %} {% step %} **Aperçu des résultats** Cliquez **Exécuter** pour lancer un aperçu de votre workflow. Le Builder compile le graphe en SQL et l'exécute sur votre base de données, en renvoyant jusqu'à 100 lignes afin que vous puissiez vérifier le résultat. {% hint style="info" %} **Exporter** Vous pouvez exporter votre workflow terminé sous forme de fichier YAML pour une exécution au moment de l'exécution ou pour le partager avec des collègues. Voir [Référence du YAML du workflow](/docs/analytics/fr/iot-query/schema-overview/transformation-layer/transformation-builder/workflow-yaml-reference.md) pour les détails du format. {% endhint %} {% endstep %} {% step %} #### Planifier l'exécution Cliquez **Planifier** pour ouvrir la boîte de dialogue de configuration, où vous pouvez définir l'heure exacte et la fréquence d'exécution du workflow. À l'heure définie, une fonction de la base de données déclenchera le workflow et enregistrera son résultat dans la couche de transformation. {% endstep %} {% endstepper %}
completed workflow graph with all node types connected

Exemple complet de flux de transformation

### Aperçu des résultats Après avoir cliqué sur **Exécuter** dans la barre d'outils, le Builder compile le graphe de votre workflow en une seule requête SQL avec des CTE et l'exécute sur la base de données PostgreSQL connectée. Les résultats apparaissent dans le panneau inférieur. **En cas d’exécution réussie**, le panneau affiche : * Un tableau de résultats affichant jusqu’à 100 lignes de données de sortie * La requête SQL exécutée (la requête CTE complète générée par le compilateur) * Le nombre de lignes, le nombre de colonnes et le temps d’exécution * Option d’exportation du résultat au format CSV **En cas d’erreur d’exécution**, le panneau affiche : * Un message d’erreur décrivant ce qui s’est mal passé * La requête SQL exécutée (si la compilation a réussi) * Détails de l’erreur de base de données (si l’erreur s’est produite pendant l’exécution de la requête) {% hint style="warning" %} L’aperçu des résultats nécessite une connexion PostgreSQL active. Sans connexion, l’aperçu renvoie un résultat vide sans exécuter de SQL. L’aperçu utilise toujours les vraies données de votre base de données, et non des données simulées. {% endhint %}
Results preview panel showing successful execution with result table and SQL

Résultat du flux exécuté

## Validation et compilation Le Builder valide votre workflow à deux niveaux. 1. **Validation du graphe** vérifie la structure globale de votre workflow. Le graphe doit être un graphe orienté acyclique valide (DAG), ce qui signifie que les données circulent dans une seule direction, sans cycles. Si le Builder détecte un cycle, il renvoie une erreur et met en évidence les nœuds concernés. 2. **Validation du Nœud** vérifie individuellement la configuration de chaque Nœud. Le Builder vérifie que les champs requis sont renseignés, que les colonnes référencées existent dans la sortie du Nœud amont, et que les paramètres du Nœud sont cohérents avec son type (par exemple, SQL Transform doit avoir exactement deux entrées). Lors de la compilation, le Builder convertit votre graphe en une seule requête SQL. Chaque Nœud devient une CTE avec l’alias `a_`. Les nœuds sont organisés dans l’ordre topologique afin que chaque CTE puisse référencer les sorties de ses nœuds prédécesseurs. Si la compilation échoue en raison d’une erreur de configuration ou d’une structure de graphe invalide, le Builder renvoie les détails de l’erreur ainsi que tout SQL partiel qu’il a pu générer. ## Exportation ### Export et import YAML Vous pouvez exporter un workflow terminé sous forme de fichier YAML à l’aide du **Exporter** bouton de la barre d’outils. Le fichier exporté contient la définition complète du workflow au format version 2, y compris toutes les configurations des nœuds, les arêtes du graphe et les positions de disposition. Pour charger un workflow précédemment enregistré, utilisez la **Import** fonction et sélectionnez un `.yaml` ou `.yml` fichier. Pour la documentation complète du format, consultez le [Référence du YAML du workflow](/docs/analytics/fr/iot-query/schema-overview/transformation-layer/transformation-builder/workflow-yaml-reference.md). ## Limites actuelles Transformation Builder en est actuellement à sa version initiale, et plusieurs contraintes s’appliquent : * **L’aperçu nécessite une connexion PostgreSQL active.** Sans connexion, vous ne pouvez pas prévisualiser les résultats. L’aperçu est limité à 100 lignes. * **Le graphe doit être sans cycle.** Les données circulent dans une seule direction, des sources vers la sortie. * **Aucun moteur d’exécution intégré.** Le Builder génère la configuration et le SQL pour une exécution dans un runtime externe. Il ne traite ni ne stocke lui-même les données. * **Traitement par lots uniquement.** Le traitement des données en continu n’est pas pris en charge. ## Étapes suivantes * [**Modèles**](/docs/analytics/fr/iot-query/schema-overview/transformation-layer/transformation-builder/templates.md): Configurations de workflow prédéfinies que vous pouvez importer et adapter dans Transformation Builder. * [**Couche de transformation**](/docs/analytics/fr/iot-query/schema-overview/transformation-layer.md): Découvrez comment la couche Transformation organise les données traitées en schémas et comment les interroger. * [**Référence du YAML du workflow**](/docs/analytics/fr/iot-query/schema-overview/transformation-layer/transformation-builder/workflow-yaml-reference.md): Consultez la Spécification complète du format d’export et d’import YAML. * [**Couche de Données brutes**](/docs/analytics/fr/iot-query/schema-overview/bronze-layer.md): Explorez les schémas source (`raw_telematics_data` et `raw_business_data`) qui fournissent les données d’entrée pour vos workflows. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://navixy.com/docs/analytics/fr/iot-query/schema-overview/transformation-layer/transformation-builder.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.