> Data > Gestion des données manquantes dans un projet décisionnel (2/2)

Gestion des données manquantes dans un projet décisionnel (2/2)

Data - Par Pierre Riehl - Publié le 24 juin 2010
email

Que l’on souhaite analyser des ventes pour doper un service commercial, étudier sa production pour réduire les coûts de ses chaînes de fabrication ou surveiller ses stocks pour travailler en flux tendu, il n’y a pas de meilleur moyen que d’analyser ses données sous toutes les coutures, en profondeur.

Un projet décisionnel – i.e. de Business Intelligence – est la voie privilégiée pour analyser les données de son système d’information. Symbolisé principalement par les cubes mis en place et les tableaux croisés dynamiques que l’on met à disposition des utilisateurs, un projet décisionnel est évidemment bien plus complexe et nécessite des compétences particulières. Ce type de projet est d’abord structurant pour une entreprise.

Gestion des données manquantes dans un projet décisionnel (2/2)

C’est une fonctionnalité native des cubes d’Analysis Services. Elle est aussi présente dans le langage de requêtage MDX. Elle permet d’identifier l’absence de valeur comme un membre à part entière d’une dimension. Le concept derrière est d’interpréter l’absence de jointure entre un fait et une dimension.

Je rappelais que NULL est une valeur significative en base de données. Nous allons donc nous appuyer sur celleci pour symboliser la donnée manquante. Ainsi, la première étape est de placer des valeurs NULL dans la table de faits Techniquement, cela se traduit dans la conception de notre DataWarehouse par une colonne NULLABLE comme clé étrangère vers notre dimension Produits. Voir figure 2.

CREATE TABLE [dbo].[FaitsVentes]( [VenteId] [int] NOT NULL, [VenteBusinessKey] [varchar](20) NOT NULL, [MagasinId] [int] NOT NULL, [DateId] [date] NOT NULL, [ProduitId] [int] NULL, [Montant] [decimal](18, 0) NOT NULL, [Quantite] [int] NOT NULL)

A l’intégration des données, il faut donc ne pas insérer de valeur. Ici, dans notre package d’intégration, on copie tel quel les données, sans se soucier des valeurs NULL. Voir figure 3. Mais dans la réalité, on fait rarement de simples copies de valeurs. On confronte les données en entrée avec nos dimensions pour faire une translation de clé (on parle de clés Business et de clés Surrogate). Pour cela, on fait une opération de Lookup dans la dimension (composant Recherche de Integration Services). Voir figure 4.

Comme on peut le voir dans l’exécution ci-dessus, ce composant génère par défaut une erreur quand il ne trouve pas le membre correspondant. C’est le comportement par défaut de l’ETL car ne pas trouver la valeur dans la dimension est considéré comme une anomalie des données. Pour permettre la transmission de l’absence d’un membre équivalent dans la dimension et donc le passage de la valeur NULL, il suffit de configurer le composant pour lui dire d’ignorer l’erreur. Voir figure 5.

A cette étape, notre DataWarehouse con – tient des faits avec des clés étrangères à NULL vers la dimension Produit. C’est là qu’intervient le concept de membre inconnu (Unknown Member). Cela nous permet d’ajouter un membre factice dans la dimension qui va correspondre à la valeur manquante. Par défaut, Analysis Services va détecter les colonnes NULLABLE et configurer les dimensions et la table de faits concernées.

Cependant, il est important de savoir effectuer cette configuration manuellement, surtout si l’on doit ajouter le critère NULLABLE à posteriori. Pour configurer ce membre inconnu, on peut intervenir à différents niveaux. Par contre il est impératif de le configurer sur la dimension et dans le cube.

Téléchargez cette ressource

Préparer l’entreprise aux technologies interconnectées

Préparer l’entreprise aux technologies interconnectées

Avec la « quatrième révolution industrielle », les environnements hyperconnectés entraînent de nouveaux risques en matière de sécurité. Découvrez, dans ce guide Kaspersky, comment faire face à cette nouvelle ère de vulnérabilité.

Data - Par Pierre Riehl - Publié le 24 juin 2010