Salut,
Au début de mon cours sur les data warehouse on m'a parlé du problème des couches et des bières (ici pour ceux qui connaissent pas). Selon l'histoire, un magasin aurait remarqué par une analyse de son data warehouse que de façon inattendue les couches étaient souvent achetées en même temps que des bières le dimanche, et que ça venait du fait que ce jour là les papa étaient chargés d'aller acheter des couches et qu'ils en profitait pour prendre des bières pour regarder le match de foot du dimanche. Le magasin a ensuite pu tirer parti de cette connaissance pour mettre les bières à côté des langes et les bénéfices auraient étés gigantesques. On nous a donc parlé de cet exemple et ensuite le cours a continué sans jamais revenir sur ce problème.
Les problèmes que j'ai eu à modéliser en exercice concernaient des calculs de moyennes, et de ventes totale par jour, mois, année dans un schéma en étoile/galaxie.
La question
Pour le problème des bières et des couches, ce n'est plus une moyenne pour chaque jour et chaque produit qu'il faut stocker mais un tableau qui associe un coefficient de co-occurence d'achat entre chaque produit. Donc un espace de stockage en O(N²) au lieu de O(N), multiplié par le nombre de dimensions.
Je n'ai pas eu à modéliser un tel problème dans mes exercices, est-ce vraiment comme ça qu'on fait ?
# Un détail de l'histoire
Posté par cellophane . Évalué à 2.
Malheureusement, aucune idée pour ta question. Mais j'ai aussi entendu cette même anecdote en cours il y a bien longtemps ! Puis j'ai trouvé plus tard quelques avis plus "nuancés"
http://fr.wikipedia.org/wiki/Liste_de_l%C3%A9gendes_contemporaines#Exploration_de_donn.C3.A9es
http://web.onetel.net.uk/~hibou/Beer%20and%20Nappies.html
[^] # Re: Un détail de l'histoire
Posté par j_m . Évalué à 2.
En parlant de résultats gigantesques, j'ai volontairement forcé le trait pour atténuer un peu la vraissemblance de cette histoire dont tout l'Internet semble dire qu'elle est fausse :-)
# 150000 références
Posté par Kerro . Évalué à 3.
En général l'examen des données se fait à la mimine.
On affiche de jolis graphiques (c'est plus efficace pour l'esprit que des tableaux) et on se paluche les hypothèses. Cela ne permet que de détecter les choses « évidentes ». Ce qui reste est bien souvent tellement marginal par rapport aux autres pistes de progrès (améliorer la com, améliorer le processus d'achat, etc) qu'il est parfaitement inutile de se pencher dessus.
Une hypothèse telle que « certains produits sont achetés en fonction de l'achat de certains autres » ne peut se faire manuellement (sauf gros cas évident qui n'a pas besoin de l'ordinateur). Dans ce cas il faut faire des statistiques sur les tickets de caisse comme tu le décris.
Un gros hypermarché a moins de 200000 références actives dans la base de données (exploitation sur une année). Ça fait 40 milliards de combinaisons si on se limite à l'analyse des produits 2 par 2. La table et les index résultants doivent faire dans les 1 Tio au total. Cela ne me semble pas démesuré pour du bon gros brassage de données.
Si le calcul doit être fait régulièrement il faut optimiser avec un stockage de l'information fait sur mesure (chaque emplacement est calculé et la donnée est écrite directement sur le disque, et non recherché par un SGBD).
[^] # Re: 150000 références
Posté par j_m . Évalué à 1.
D'abord merci beaucoup. C'est parfaitement le type de réponse que j'attendais.
Dans cette histoire on a l'impression que l'analyse de l'entrepôt de donnée fait ressortir des relations insoupçonnées mais ça ne correspond pas du tout à la démarche classique, en fait. Si j'ai bien compris on n'aurait classiquement jamais récolté toutes ces données, sauf si on avait une hypothèse à tester au départ. Et donc les résultats n'auraient été qu'une demi surprise. Et ce n'est peut-être pas à tester dans le data warehouse avec les autres données décisionnelles, mais dans un truc à part prévu à cet effet.
Elles concernent quel problème ces 150000 références ? La façon d'optimiser le stockage d'information hors d'un SGBD ?
[^] # Re: 150000 références
Posté par Kerro . Évalué à 3.
Je ne saisi pas la question.
150000 lignes dans une table ne posent pas de problème.
Par contre ce nombre élevé au carré (pour stocker la corrélation entre les articles 2 par 2), ça commence à tirer sur les temps d'accès disque lorsqu'on fait des requêtes dessus. En gros ça fait 22 milliards d'écritures sur disque. À 5 ms par écriture en étant optimiste ça donne plus de 3 ans. Y'a comme un problème.
Il faut donc découper le problème en ne remplissant qu'une partie de la table à chaque fois, de manière à faire tenir les données dans la mémoire.
[^] # Re: 150000 références
Posté par j_m . Évalué à 1.
Ah oui, j'avais juste pas compris ton titre. Par référence j'ai cru que tu disais que le problème avait déjà été étudié ailleurs et que je pouvais m'y référer.
Au temps pour moi.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.