Tutoriel d'exploration de données

Module 1 : modèle d'association

Recherche de relations dans vos données à l'aide d'un modèle d'association

Un modèle d'association recherche des schémas dans vos données en décernant des associations entre des articles. Un modèle d'association recherche ces schémas en appliquant la formule “Les clients qui achètent le produit A achètent aussi le produit B.”

L'exercice consiste, dans un premier temps, à préparer une source de données adéquate et de le brancher sur un analyseur d'associations. Dans un deuxième temps, on rajoute des hiérarchies de libellés pour rendre le résultat plus lisible.

Il y a deux paramètres à fixer (ou laisser) dans l'analyseur : longueur de règle et support minimale.

Zone Valeur Explication
Longueur de règle maximale 3 Si vous faites passer la longueur de règle maximale à 3, votre modèle peut comprendre des règles portant sur 3 articles, par exemple “Les clients ayant acheté des tentes et des sacs de couchage ont aussi acheté des sacs à dos”.

Il est dommage de ne pas savoir plus sur la logique, les formules appliquées dans cette analyse. Plus loin, en cliquant sur “En savoir plus sur les mesures de qualité (support, fiabilité et valeur lift)” on explique un peu, mais pas vraiment l'algorithme :

Le support d'une règle d'association est
le terme qui désigne le pourcentage de transactions de vos données pour lequel la règle s'avère vraie, par rapport au nombre total de transactions de vos données. Par exemple, si vos données comportent 1000 transactions, dont 300 se composent de matériel d'alpinisme et de lunettes, la règle “Les clients qui ont acheté du matériel d'alpinisme ont aussi acheté des lunettes” a un support de 30%.
La fiabilité d'une règle d'association est
un terme qui désigne le pourcentage de transactions de vos données pour lequel la règle s'avère vraie, par rapport au nombre de transactions de vos données contenant la tête de la règle. Dans l'exemple précédent, si 600 transactions sur 1000 comprennent du matériel d'alpinisme, alors la règle “Les clients qui ont acheté du matériel d'alpinisme ont aussi acheté des lunettes” a une fiabilité de 300/600, soit de 50%.
La valeur lift d'une règle d'association est
le terme qui désigne le rapport entre la fiabilité d'une règle et le support relatif de la tête de la règle. Imaginons que la règle “Les clients qui ont acheté des cartes routières ont aussi acheté du carburant” ait une fiabilité élevée de 90%. Sans vous référer à la valeur lift de la règle, vous pouvez considérer que l'achat d'une carte est un indicateur fort de l'intérêt du client pour l'achat de carburant. Néanmoins, tenez compte du fait que quasiment tous les clients d'une station-essence s'y rendent en général surtout pour y acheter du carburant. Supposons que 90% des clients achètent du carburant. Le facteur de valeur lift de la règle n'est alors que de 1, ou 90%/90%, c'est-à-dire que l'achat d'une carte routière n'a pas de lien évident avec l'achat de carburant.

On a un modèle d'associations. On le branche sur un extracteur d'associations, qui est prévu pour générer un certain nombre de tables à partir des règles qu'il résume en huit colonnes. On en dérive

  • du port corpsrègle, une table avec trois colonnes –BodyId, Itemname, Item– permettant de détailler et mieux identifier les plusieurs produits (dans ce cas) qu'une règle peut comporter.
  • du port règle, les colonnes BodyId, Head, HeadName, Length, BodyText, Support, Confidence, Lift.

Module 2 : Déploiement

… d'une application d'exploration sur un serveur d'entrepôt de données

  • Ajout d'étapes permettant d'extraire le modèle d'exploration du flux d'exploration
  • Conception d'un flux de contrôle simple exécutant votre flux d'exploration
    • C'est vraiment très simple : on branche un démarreur (“opérateur Démarrer”) sur l'entrée d'un opérateur Flux d'exploration, celui-ci paramétré avec le nom de notre flux : “analyse_panier_achats”.
  • Préparation d'une application d'entrepôt de données pour le déploiement
    • On clique sur “créer une application…”, donne un nom et un emplacement (répertoire) pour le stocker. Bref, on “sauvegarde sous…” en fichier zippé.
  • Déploiement avec la console d'administration
    • On se connecte au console d'administration du serveur d'application.
    • On importe/copie “l'application” zippé vers le serveur d'applications,
    • on l'associe à notre base de données (GSDB)
    • et on programme le Démarreur : fréquence, jour de la semaine, répétitions jusqu'à.

Exemple de code SQL pour trouver des produits à proposer à un client ayant commandé articles 44, 45, et 48, où GOSALESCT.PRODUCT_AFFINITY est la table contenant les règles résultantes de notre analyse d'associations :

SELECT DISTINCT HEAD AS ITEM ,HEADNAME AS ITEMNAME
FROM GOSALESCT.PRODUCT_AFFINITY
  WHERE
    BODYID IN (
      SELECT DISTINCT BODYID 
      FROM GOSALESCT.PRODUCT_AFFINITY 
      WHERE 
          BODYID NOT IN (
          SELECT BODYID FROM GOSALESCT.PRODUCT_AFFINITY 
          WHERE ITEM NOT IN (44,45,48)
          )
     )
AND SUPPORT > 0.001
AND CONFIDENCE > 0.3
AND LIFT > 5;

D'abord, on trouve les règles qui ne débouchent pas sur l'un des produits commandés, puis on cherche les règles qui ne font partie de ce premier lot:

      BODYID NOT IN (
          SELECT BODYID FROM GOSALESCT.PRODUCT_AFFINITY 
          WHERE ITEM NOT IN (44,45,48)
          )

Ensuite, on sélectionne les règles parmi celles dans ce deuxième groupe qui satisfont aussi des critères de qualité (de règle):

SELECT DISTINCT HEAD AS ITEM ,HEADNAME AS ITEMNAME
FROM GOSALESCT.PRODUCT_AFFINITY
  WHERE
    BODYID IN ( règles pertinentes )
    AND SUPPORT > 0.001
    AND CONFIDENCE > 0.3
    AND LIFT > 5;

Evaluation des données en temps réel à l'aide de l'API SQL

FROM
IDMMX.RULEMODELS,
  TABLE (
    IDMMX.DM_applyRuleModel (
      MODEL
      , XMLSERIALIZE (
          CONTENT XMLELEMENT (
            NAME "itemset"
            , XMLCONCAT( 
               XMLELEMENT(NAME "item", '102')
               , XMLELEMENT(NAME "item", '105')
             )
           ) AS CLOB (512000)
        )
    ) 
) as "MATCHINGRULES"
WHERE MODELNAME = 'Warehouse Mining Tutorial.PROD_AFFINITIES' and "MATCHHEAD"=0;

Module 3 : Prédiction

Estimation des valeurs inconnues à l'aide d'un modèle d'estimation et de l'évaluation par lots

L'objet est le suivant : prévoir le risque de retours de marchandise à partir de l'historique de retours produits.

Pour cela, nous constituons l'historique à partir des trois tables ORDER_HEADER, ORDER_DETAIL, et RETURNED_ITEM. Puisque la table RETURNED_ITEM n'a des lignes que pour les retours (donc, à priori, moins de lignes que ORDER_DETAIL) nous utilisons une jointure “normale” pour les deux premières tables et une jointure externe gauche pour lier ce résultat à la table RETURNED_ITEM, ce qui fait que le résultat aura autant de lignes que ORDER_DETAIL avec des valeurs null (ou remplies par une valeur de notre choix) dans la (ou les) colonnes provenant de RETURNED_ITEM.

Ensuite, nous préparons un jeu de données d'apprentissage à partir de ce résultat, prenant un quart des lignes, dont la moitié avec retours et la moitié sans retours (ce qui suppose que un produit sur huit est retourné!). Puis nous lançons un apprentissage de classification supervisé, avec la méthode “Arborescence” (arbre de décision, et ni Naïve Bayes ni régression logistique), et évaluons le résultat avec le reste des données (les 3/4 qu'on n'a pas pris lors du partage aléatoire).

Enfin, nous entrons de nouvelles données, branchons cette table et notre modèle de prédiction sur un opérateur d'évaluation pour prévoir le retours sur ces nouvelles lignes de commande.

Annexe : La Palette

La liste des opérateurs disponibles est beaucoup plus longue que celle des opérateurs que nous avons exploités dans ces exercices :

  • Sources et cibles
    • source table
    • source de modèles
    • cible table
    • visualiseur
  • Transformations
    • Condition WHERE
    • Liste de séléction
    • Regroupement
    • Jointure de table
    • Trier par
    • Union
  • Transformations avancées
    • Discrétisation
    • Echantillonneur
    • Fractionnement
    • Partage aléatoire
    • Regroupeur d'éléments
    • Instructions SQL personnalisées
    • Station de données
    • Distinction
    • Recherche par clé
    • PIVOT
    • UNPIVOT
    • Fonction de table DB2
  • Exploration de données Création d'un modèle
    • Associations
    • Séquences
    • Générateur de cluster
    • Fonction prédictive
    • Série temporelle
  • Exploration de données - Création d'une vue
    • Rechercher les règles
    • Rechercher les écarts
    • Table de clusters
    • Prédire les colonnes
  • Introspection de modèle
    • Extracteur d'associations
    • Extracteur de séquences
    • Extracteur de clusters
    • Extracteur de gains
    • Extracteur de données de qualité
    • Extracteur de zones
    • Extracteur de corrélations
    • Extracteur de règles arborescences
    • Extracteur de séries temporelles
    • Filtre de règles
  • Test et application
    • Fonction d'évaluation
    • Fonction de test
  • Analyse de texte
    • Recherche dans le dictionnaire
    • Recherche d'expression régulière
    • Analyseur de texte
 
m1ilc/edid_td_3.txt · Dernière modification: 2009/12/29 13:33 par suitable
 
Sauf mention contraire, le contenu de ce wiki est placé sous la licence suivante :CC Attribution-Noncommercial-Share Alike 3.0 Unported
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki