Supposez que vous travaillez avec un processus Sélection configuré pour sélectionner des identifiants en fonction d’un champ dérivé, connecté à un processus Extraction qui extrait les enregistrements contenant ce champ dérivé. Si vous rendez ce champ permanent, la valeur calculée par lui passe du processus Sélection au processus Extraction.
Les champs dérivés de type agrégat (par exemple AVG ou GROUPBY) constituent un autre cas d’utilisation de champs dérivés permanents. Les champs agrégés sont calculés à partir de plusieurs lignes de données de la cible en cours. Aussi leur valeur change-t-elle en fonction des changements dans la cible. En les rendant permanents, vous décidez de conserver la valeur calculée initialement, que vous passez ensuite à d’autres processus. À l’inverse, si vous décidez de recalculer le champ dérivé, vous obtiendrez une valeur sur la base des enregistrements restants de la cible courante.
Lorsqu’un processus comporte de multiples processus en entrée, comme par exemple un processus Extraction construit à partir de deux processus Sélection, tous les champs dérivés permanents deviennent disponibles dans les processus suivants.
Lorsqu’un champ dérivé permanent n’est pas disponible dans tous les processus Sélection entrants et qu’il est inclus comme élément généré dans un processus Extraction, ce dernier affiche une valeur NULL pour le champ dérivé dans toutes les lignes générées par les processus Sélection ne disposant pas du champ dérivé.
Si un champ dérivé permanent n’est pas disponible dans tous les processus Sélection entrants et si vous l’utilisez pour définir un processus Segmentation, le processus Segmentation comporte des segments vides pour les processus Sélection ne disposant pas du champ dérivé permanent.
Le processus Segmentation restera indéfini si vous tentez de définir un segment avec une expression utilisant plusieurs champs dérivés permanents non disponibles dans tous les processus Sélection.
Les consignes suivantes s’appliquent aux champs dérivés permanents (CDP) :
Les champs dérivés permanents ne gardent qu’une seule valeur par identifiant du référentiel, sélectionnée de manière aléatoire parmi les valeurs disponibles. En d’autres termes, lorsque vous travaillez sur des données non normalisées, vous devez faire appel à la fonction macro GROUPBY pour obtenir le comportement souhaité.
Supposons que vous souhaitiez trouver dans la table des transactions le montant de la transaction la plus élevée effectuée par un client et l’enregistrer sous forme de champ dérivé permanent pour un traitement en aval. Vous pouvez créer un champ dérivé (et ensuite en faire un champ dérivé permanent) comme suit :
Ce qui donnerait les calculs suivants à partir des transactions d'achat non normalisées illustrées ci-après :
Lorsque le champ dérivé est rendu permanent, il choisit au hasard une valeur (toutes sont égales à 300 $) et rend cette valeur de 300 $ permanente pour le client A.
Un second exemple moins évident peut consister à sélectionner un score de modèle prédictif dans une table de scoring pour un modèle X donné. Dans ce cas le champ dérivé peut être semblable à ceci :
Et les données se présenteront comme suit :
En rendant permanent le champ dérivé, ModelX_Score, vous obtenez la valeur de score de 80, qui correspond au résultat voulu. Il est incorrect de créer un champ dérivé :
Ceci produit le résultat suivant :
Ensuite, lorsque vous rendez permanent le champ dérivé Bad_ModelX_score, la valeur permanente peut être NULL ou 80. Si vous travaillez sur des données non normalisées et si les valeurs de champs dérivés ne sont pas toutes identiques, le fait de rendre permanent ce champ dérivé peut entraîner le renvoi de n’importe quelle valeur. Par exemple, le fait de définir Derived_field_Score = SCORE et de le rendre permanent pourrait renvoyer la valeur 57, 72 ou 80 pour le client A. Pour garantir le comportement voulu, vous devez utiliser la macro GROUPBY sur l’identifiant client et vous assurer que la valeur du champ dérivé est identique pour toutes les données concernant ce client.
