Création de règles de qualité de données SQL

Vous pouvez créer des règles de qualité de données SQL pour évaluer la qualité des données de votre projet. Utilisez ces règles pour mesurer les erreurs plutôt que pour évaluer la conformité à des critères de qualité spécifiques.

Pour qu'une règle de qualité des données basée sur SQL contribue aux scores de qualité des données d'un actif ou d'une colonne, ajoutez cet actif ou cette colonne en tant qu'élément associé à la règle correspondante. Utilisez l'option Valide la qualité de données du type de relation . Le même score et les mêmes problèmes sont signalés pour tous les actifs et les colonnes liés à ce type de relation.

Pour créer une règle de qualité de données basée sur SQL:

1. Ouvrez un projet, cliquez sur Nouvel actif > Mesurer et surveiller la qualité des données .

2. Définissez les détails :

   • Indiquez un nom pour la règle de qualité de données.

   • Facultatif : fournissez une description.

   • Facultatif: Sélectionnez une dimension de qualité de données pour décrire la métrique de qualité de données principale pour la logique de règle de cet actif. La dimension sélectionnée peut être utilisée comme catégorie de rapport, pour le filtrage ou pour la visualisation des données sélectionnées.

     Lorsque vous créez votre règle à partir d'une définition de qualité de données, une dimension de qualité de données peut déjà être définie. Vous pouvez le conserver, supprimer le paramètre de dimension ou sélectionner une autre dimension.

3. Activez l'option Utiliser les instructions SQL .

4. Indiquez la source des données à vérifier en sélectionnant une connexion existante ou en en créant une nouvelle. Pour connaître les sources de données prises en charge, voir Sources de données prises en charge pour la conservation et la qualité des données.

   Si vous sélectionnez une connexion existante et que cette connexion a été créée avec des données d'identification personnelles, vous devrez déverrouiller la connexion.

5. Entrez vos instructions SQL.

   Lorsque vous écrivez la requête, assurez-vous que l'instruction SELECT remplit les conditions suivantes:

   • L'instruction ne renvoie que des colonnes avec des noms uniques. Les colonnes avec des noms en double provoqueront des erreurs de validation.
   • L'instruction renvoie le nombre d'enregistrements qui ne remplissent pas votre condition de qualité de données. Les règles SQL fonctionnent différemment des règles créées à partir de définitions de qualité de données. Ils renvoient les enregistrements renvoyés par l'instruction SELECT sous la forme failed ou Not met. De plus, le nombre total d'enregistrements signalés est égal au nombre d'enregistrements renvoyés et non au nombre d'enregistrements vérifiés.

   Par exemple, si vous disposez d'une table db2admin.credit_card avec 31 lignes et que vous souhaitez vérifier le nombre d'enregistrements avec le type de carte AMEX dans la table, la différence est la suivante:

   Règle de qualité de données à partir d'une définition de qualité de données
   Vous recherchez les enregistrements dont le type de carte est AMEX.
   Expression dans la définition de qualité de données: Col = 'AMEX'
   Expression liée dans la règle de qualité de données: credit_card.card_type = 'AMEX'
   Exemple de résultat: Total: 31 | Met: 4 (12.9%) Not met: 27 (87.1%)

   Règle de qualité de données basée sur SQL
   Vous recherchez les enregistrements dont le type de carte n'est pas AMEX.
   Instruction SELECT: select card_type from db2admin.credit_card where card_type <> 'AMEX'
   Exemple de résultat: Total: 27 | Met: 0 (0%) Not met: 27 (100%)

   Vérifiez également l'ensemble d' exemples d'instructions SQL pour les règles de qualité de données. Ces exemples montrent comment écrire des règles SQL pour renvoyer des enregistrements qui ne répondent pas à vos critères de qualité. Vous pouvez copier les instructions fournies dans vos propres règles de qualité de données et les ajuster si nécessaire.

   • Tenez compte des conventions suivantes pour spécifier les noms de colonne, de table et de schéma dans votre instruction SELECT:

     • Les noms de table et de schéma dans les sources de données PostgreSQL sont sensibles à la casse. Vous devrez peut-être placer les noms entre guillemets, comme dans l'exemple suivant: "schema". "table_name"
     • Essayez d'éviter les requêtes SELECT * . De telles requêtes peuvent entraîner des erreurs de validation lorsque les noms de colonne changent. Réduisez la sélection de colonne.
     • Si le nom de colonne ne commence pas par un caractère alphabétique ou contient des caractères autres que des caractères alphabétiques, des caractères numériques ou des traits de soulignement, utilisez un alias pour le nom de colonne.

   A tout moment, vous pouvez tester les instructions SQL. Notez que le test renvoie uniquement les noms des colonnes sélectionnées par votre requête. Aucun traitement réel n'est effectué. Une vérification de validité est effectuée lorsque vous cliquez sur Suivant. Vous ne pouvez pas continuer tant que votre requête n'a pas réussi cette vérification.

6. Configurez les paramètres de sortie et le contenu.

   Indiquez si vous souhaitez que la sortie de règle soit écrite dans une base de données. Si ce n'est pas le cas, seules quelques informations statistiques sont fournies dans l'historique d'exécution de la règle. Pour plus d'informations, voir Configuration des paramètres de sortie pour les règles de qualité des données.

7. Vérifiez votre configuration. Pour vous assurer que votre règle est correctement configurée, vous pouvez la tester avant de l'enregistrer dans le projet. La sortie du test de règle est directement affichée et correspond à ce que vous avez configuré dans les paramètres de sortie.

   Pour modifier la configuration, cliquez sur l'icône Modifier sur la tuile et mettez à jour les paramètres. Lorsque votre examen est terminé, cliquez sur Créer. La règle et son flux DataStage sont ajoutés au projet. Le nom par défaut du flux DataStage est DataStage flow of data rule <rulename>.

Si votre règle est configurée correctement sans aucune information manquante, son statut est Prêt. Ce statut signifie que la règle peut être exécutée. Le statut de règle Non prêt indique que la règle ne peut pas être exécutée en raison d'erreurs de syntaxe SQL, de dépendances modifiées ou d'autres problèmes de définition de règle. Par exemple, le mot de passe permettant d'accéder à la source de données a été modifié. Ce statut est plus susceptible d'apparaître pour les règles de qualité des données qui ont été créées à l'aide de l' API IBM Knowledge Catalog : Créer une règle de qualité des données. Lorsque vous créez des règles de qualité de données à l'aide de l'API, veillez à tester et à valider également la règle.

Pour confirmer qu'une règle est toujours valide avant de l'exécuter manuellement, vous pouvez vérifier son statut en sélectionnant Valider dans le menu déroulant dynamique.