La qualité des données dans l'entrepôt est une condition préalable importante pour obtenir des informations précieuses. Une mauvaise qualité entraîne une réaction en chaîne négative à long terme.
Premièrement, la confiance dans les informations fournies est perdue. Les gens commencent à moins utiliser les applications de Business Intelligence ; le potentiel des applications reste inexploité.
En conséquence, la poursuite des investissements dans le projet analytique est remise en question.
Responsabilité de la qualité des données
L'aspect lié à l'amélioration de la qualité des données est très important dans les projets BI. Cependant, ce n’est pas l’apanage des seuls spécialistes techniques.
La qualité des données est également influencée par des aspects tels que
Culture d'entreprise
- Les travailleurs eux-mêmes sont-ils intéressés à produire de la bonne qualité ?
- Si non, pourquoi pas ? Il peut y avoir un conflit d'intérêts.
- Peut-être existe-t-il des règles d’entreprise qui déterminent qui est responsable de la qualité ?
Processus
- Quelles données sont créées à la fin de ces chaînes ?
- Peut-être que les systèmes d'exploitation sont configurés de telle manière qu'il faut « tordre » pour refléter telle ou telle situation dans la réalité.
- Les systèmes d’exploitation effectuent-ils eux-mêmes la vérification et le rapprochement des données ?
Tout le monde dans l’organisation est responsable de la qualité des données dans les systèmes de reporting.
Définition et signification
La qualité est la satisfaction avérée des attentes des clients.
Mais la qualité des données ne contient pas de définition. Il reflète toujours le contexte d’utilisation. L'entrepôt de données et le système BI servent des objectifs différents de ceux du système d'exploitation d'où proviennent les données.
Par exemple, sur un système d'exploitation, l'attribut client peut être un champ facultatif. Dans le référentiel, cet attribut peut être utilisé comme dimension et son remplissage est obligatoire. Ce qui, à son tour, introduit la nécessité de renseigner les valeurs par défaut.
Les exigences en matière de stockage de données évoluent constamment et sont généralement plus élevées que celles des systèmes d'exploitation. Mais cela peut aussi être l'inverse, lorsqu'il n'est pas nécessaire de stocker des informations détaillées du système d'exploitation dans le stockage.
Pour rendre la qualité des données mesurable, ses normes doivent être décrites. Les personnes qui utilisent des informations et des chiffres pour leur travail doivent être impliquées dans le processus de description. Le résultat de cette implication peut être une règle, à la suite de laquelle on peut savoir d'un coup d'œil au tableau s'il y a une erreur ou non. Cette règle doit être formatée sous forme de script/code pour une vérification ultérieure.
Améliorer la qualité des données
Il est impossible de nettoyer et de corriger toutes les erreurs hypothétiques lors du processus de chargement des données dans l'entrepôt. Une bonne qualité des données ne peut être obtenue que grâce à une collaboration étroite entre tous les participants. Les personnes qui saisissent des données dans les systèmes d’exploitation doivent savoir quelles actions conduisent à des erreurs.
La qualité des données est un processus. Malheureusement, de nombreuses organisations ne disposent pas de stratégie d’amélioration continue. Beaucoup se limitent au stockage de données et n’utilisent pas tout le potentiel des systèmes analytiques. En règle générale, lors du développement d'entrepôts de données, 70 à 80 % du budget est consacré à la mise en œuvre de l'intégration des données. Le processus de suivi et d’amélioration reste incomplet, voire inexistant.
Outils
L'utilisation d'outils logiciels peut faciliter le processus d'automatisation de l'amélioration et du suivi de la qualité des données. Ils peuvent par exemple entièrement automatiser la vérification technique des structures de stockage : format des champs, présence de valeurs par défaut, respect des noms de champs des tables.
Il peut être plus difficile de vérifier le contenu. À mesure que les exigences de stockage évoluent, l’interprétation des données peut également changer. L’outil lui-même peut devenir un projet énorme qui nécessite un accompagnement.
Conseil
Les bases de données relationnelles, dans lesquelles les magasins sont généralement conçus, ont la remarquable capacité de créer des vues. Ils peuvent être utilisés pour vérifier rapidement les données si vous connaissez les spécificités du contenu. Chaque cas de découverte d'une erreur ou d'un problème dans les données peut être enregistré sous la forme d'une requête dans la base de données.
De cette façon, une base de connaissances sur le contenu sera constituée. Bien entendu, ces demandes doivent être rapides. La maintenance des vues nécessite généralement moins de temps humain que les outils basés sur des tables. La vue est toujours prête à afficher le résultat du test.
Dans le cas de rapports importants, la vue peut contenir une colonne avec le destinataire. Il est logique d'utiliser les mêmes outils BI pour rendre compte de l'état de la qualité des données dans l'entrepôt.
Exemple
La requête a été écrite pour la base de données Oracle. Dans cet exemple, les tests renvoient une valeur numérique qui peut être interprétée comme souhaité. Les valeurs T_MIN et T_MAX peuvent être utilisées pour ajuster le niveau d'alarme. Le champ REPORT était autrefois utilisé comme message dans un produit ETL commercial qui ne savait pas comment envoyer correctement des e-mails, rpad est donc une « béquille ».
Dans le cas d'un grand tableau, vous pouvez ajouter par exemple AND ROWNUM <= 10, soit s'il y a 10 erreurs, cela suffit à déclencher l'alarme.
CREATE OR REPLACE VIEW V_QC_DIM_PRODUCT_01 AS
SELECT
CASE WHEN OUTPUT>=T_MIN AND OUTPUT<=T_MAX
THEN 'OK' ELSE 'ERROR' END AS RESULT,
DESCRIPTION,
TABLE_NAME,
OUTPUT,
T_MIN,
T_MAX,
rpad(DESCRIPTION,60,' ') || rpad(OUTPUT,8,' ') || rpad(T_MIN,8,' ') || rpad(T_MAX,8,' ') AS REPORT
FROM (-- Test itself
SELECT
'DIM_PRODUCT' AS TABLE_NAME,
'Count of blanks' AS DESCRIPTION,
COUNT(*) AS OUTPUT,
0 AS T_MIN,
10 AS T_MAX
FROM DIM_PRODUCT
WHERE DIM_PRODUCT_ID != -1 -- not default value
AND ATTRIBUTE IS NULL ); -- count blanks
La publication utilise des éléments du livre
Ronald Bachmann, Dr. Guido Kemper
Raus aus der BI-Fall
Wie Business Intelligence zum Erfolg wird
Source: habr.com