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
… d'une application d'exploration sur un serveur d'entrepôt de données
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;
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;
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.
La liste des opérateurs disponibles est beaucoup plus longue que celle des opérateurs que nous avons exploités dans ces exercices :