Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
informations sur DATA MINING
Bonsoir tout le monde,
je suis à la recherche d'un document sur le data mining ciblant la définition du data mining avec des exemples, les pré-requis techniques et les pré-requis en terme de base de données, autrement dit une personne ayant à faire du data mining qu'est ce qu'il doit avoir comme architecture technique pour aborder le sujet DATA MINING?
j'ai fait des recherches sur le web mais les informations sont tellement éparpiées que je ne suis pas arriver à m'y retrouver.
merci d'avance
Le Data Mining est en fait un terme générique englobant toute une famille d'outils facilitant l'analyse des données contenues au sein d'une base décisionnelle de type Data Warehouse ou DataMart.
Certains considèrent cette technique comme "l'art" voire même la "science" de l'extraction d'informations significatives de grandes quantités de données.
En peu de mots, le Data Mining présente l'avantage de trouver des corrélations informelles entre les données.
Il permet de mieux comprendre les liens entre des phénomènes en apparence distincts et d'anticiper des tendances encore peu discernables.
Bonne journée
voir mon blog et liens qui regroupent les infos
http://noel-bi.blogspot.com/
j'ai jetté un oeuil sur ton blog mais apparemment il n'y a pas d'infos sur le data mining, non?
sinon pour mettre en oeuvre un tel projet faut il avoir une ou des machines spéciales ou un simple serveur?
dois-je obligatoirement passer par un datawarehouse ou peux-je utiliser ma base de production directement?
enfin j'ai plusieurs questions sur le sujet, je les poserai a fure et à mesure.
le lien http://www.piloter.org/business-inte...datamining.htm n'est pas très explicatif...
m'ci
Attention, ceci est une définition perso :
Le Datamining est un anglicisme pompeux de plus qui désigne les outils de requêtage graphique (souvent foireux) et le fait de les utiliser en ayant l'impression (fausse évidemment) de maîtriser la bête alors qu'on ne connaît pas le SQL.
En ce sens, un utilisateur comme pnoel-bi semble s'inscrire complètement dans le moule : en 5 lignes, il a casé "Data Mining", "Data Warehouse", "Data Mart", "décisionnelle", "corrélations informelles", ... mais même en lisant 3 fois, le novice n'est pas plus avancé (voire encore plus perdu) car ces belles phrases sont creuses.
pnoel-bi, je n'en fais pas une attaque perso, mais j'ai horreur des gens qui font du vent et qui arrivent à le vendre grâce à l'incompétence de nombreux responsables informatiques côté client. Un simple coup d'oeil sur ton blog, à lire à chaque ligne l'autosatisfaction puante quand tu te présentes et on a compris (commercial avant d'être bon technicien...)
Apprenez le SQL, et vous ferez du Data Mining dans un Data Warehouse ou un Data Mart sans même vous en apercevoir !
Jaub si tu-as des questions pas de problème mais mieux vaut passer par une autre voie
Désolé tu as posé une question trop générale.
>dgi77 : attention aux termes que tu utilises dans tes réponses, particulièrement quand tu t'en prends de manière personnelle aux membres, et encore plus à des membres débutants sur le forum, qui ne sont peut-être pas des débutants dans leur vie professionnelle.
Sinon je trouve la réponse de pnoel-bi plutôt satisfaisante. Il répond, en donnant SON avis, à :
qu'est-ce que le DATA MINING ?l'avantage de trouver des corrélations informelles entre les données.
Il permet de mieux comprendre les liens entre des phénomènes en apparence distincts et d'anticiper des tendances encore peu discernables.une personne ayant à faire du data mining qu'est ce qu'il doit avoir comme architecture technique pour aborder le sujet DATA MINING?Et donne aussi plusieurs mots techniques (Datawarehouse, datamart) qui permettront à JauB de retrouver sur Internet plus d'informations sur le sujet.une base décisionnelle
Pour aller plus loin JauB, je dirais que le data mining c'est juste la recherche d'informations cachées dans des données. On "creuse" pour trouver des informations qui sont dans les données mais qui ne sont pas évidentes. Du genre "ah le client a acheté des tampons et du rouge à lèvres donc c'est probablement une femme (à 95% de fiabilité). Et comme on a son numéro de carte fidélité, on peut dire à 95% que ce client est une femme et donc on peut lui adresser des offres promotionnelles pour femmes". Evidemment ce genre de "déductions" est inutile si à la souscription de sa carte fidélité le client a précisé son sexe.
Ce qui est important à comprendre, et c'est sûrement la raison pour laquelle dgi77 s'est énervé inutilement, c'est que le data mining on en fait tous les jours, parfois même sans ordinateur. Le moindre film policier c'est du data mining, on analyse, on imagine, on fait des corrélations. Pas besoin de bases décisionnelles, de gros serveurs, de Business Objects, etc. Un simple fichier Excel dans lequel on colle le résultat d'une requête SQL sur le serveur de production et on peut démarrer l'analyse.
Après les besoins en terme de volume et de performance peuvent être tels que
1) le responsable des bases de production t'interdit de requêter sur la base de production
2) tu as trop de lignes pour tenir sur Excel / Acces
3) tu as trop de temps de calcul pour Excel / Access
et dans ce cas tu mets en place une architecture décisionnelle. Cette architecture sera soit une simple copie de la base de production (rafraichie régulièrement) soit une base spécialement designée pour faciliter l'analyse et donc sera différente de celle de production. Ce qui énerve les DBA dans le decisionnel (et c'est sûrement le cas de dgi77) c'est que
1) les bases décisionnelles ne ressemblent pas aux bases de production et souvent ne respectent pas les formes normales (on appelle ça "dénormaliser")
2) un utilisateur basique qui ne connaît RIEN au SQL est capable d'obtenir de bons résultats en requêtage grâce à des outils tels que Business Objets qui construisent des requêtes juste avec des clics de souris, shuntant le DBA qui avant était le seul à savoir faire les extractions
3) ces fameuses requêtes d'extractions sont souvent moins optimisées que celles écrites par les DBA, ce qui peut augmenter la charge sur le serveur, et c'est pour ça qu'on évite de faire du data mining sur un serveur de production
4) c'est "de la bidouille"
Donc pour ta demande initiale, je dirais que ton cerveau est l'outil minimal pour faire du data mining. Tout outil supplémentaire doit être justifié par des contraintes de :
- temps d'analyse
- volume de données à analyser
- présentation des résultats
merci à vous tous,
tes informations nuke_y sont très utiles pour une personne débutante comme moi.
sinon est ce que vous avez déjà mener des projets de ce type?sous quelle plateforme?
nuke_y, merci pour la leçon, mais effectivement, je ne suis pas du genre à carresser dans le sens du poil pour mieux tracer ma route. C'est tellement plus facile d'être consensuel et de ne jamais se dire la vérité, mais à long terme, c'est ce qui nous perd.
Au début de ma carrière, j'ai été souvent impressioné par des gars en costume qui tenaient des beaux discours dont je ne comprenais rien, mais dont j'ai compris plus tard qu'ils étaient tous droits sortis de PC Experts (les discours !). Quand tu débutes, ce genre de personnes te font mal, car tu fais un complexe d'infériorité et tu te remets énormément en question, alors qu'en fait ils n'y comprennent pas grand chose non plus, mais par contre ils savent bien tchatcher. Sauf que c'est pas de tchatcher qui fait avancer le chmilblic...
Je suis désolé, mais quand tu lis l'intervention de notre ami, c'est la caricature même du tchatcheur, on n'est pas plus avancé. Essaie d'imaginer que tu n'as encore jamais entendu parler du Data Mining, qu'est-ce que tu vas comprendre de plus. Donc, sachant moi-même ce qui se cache derrière ce terme pompeux, et par ailleurs connaissant le SQL (ce qui n'est peut-être pas le cas de tous ceux qui expliquent le Data Mining aux autres...), je considère que je dois intervenir pour ne pas que des "imposteurs" (prenez-le comme vous voulez) démoralisent des débutants.
Même si nous sommes dans l'ère du paraître, il y a des façons beaucoup plus simples et concrètes pour expliquer ce qu'est le "Data Mining" (au passage, le Data Mining n'a rien inventé...)
Maintenant, ton intervention est un peu plus claire et a le mérité d'une certaine objectivité, en ce sens notamment que tu précises que les performances des requêteurs sont moins bonnes que celles de bonnes vieilles requêtes SQL.
Mais il faut dire que les performances ne sont pas juste un peu moins bonnes, elles sont souvent désastreuses, et c'est bien ce qui me gêne (rassure-toi, ce n'est pas de ne pas avoir la main sur ces requêtes, oh non !). Il faut quand même signaler que ces outils ont de gros problèmes pour générer un code SQL un minimum "propre" (problèmes inadmissibles au vu du prix des licenses), que les requêtes générées mettent régulièrement les serveurs à genou, qu'elles ne sont pas cancellées sur le serveur lorsque l'utilisateur impatient kille son usine à gaz toutes les 5 minutes sur son poste client, et relance (5 fois, 10 fois, .... avec 15 utilisateurs, c'est le bonheur). Sans compter le joie à la fin quand les utilisateurs te disent que l'informatique ça ne marche pas, ou quand ils considèrent que les bases de données c'est facile (va ensuite leur annoncer une charge de travail pour faire un boulot propre et optimisé...)
Pour moi le data mining, c'est t'as des données à droites, tu veux un résultat à gauche (n'importe quoi), donc au milieu tu fais des choses.
Et quand je dis données, je suis large. Je fait souvent du data mining dans des images.
J'en mène tous les jours, enfin façon de parler vu qu'une grosse partie du travail consiste à mettre à disposition des gens du métier (les contrôleurs de gestion, les analystes financiers, les responsables RH) les outils informatiques qui vont leur permettre à EUX de mener l'analyse.Envoyé par JauB
Plateforme : Oracle en BDD, Genio en ETL pour les alimentations de données (entre la base de production et le datawarehouse par exemple) et les transformations, et en restitution SQL*Plus/SQLDevelopper pour moi et Business Objects 5/XI (on est en cours de migration) pour les utilisateurs.
@Jester : c'est vrai que le data mining dans des images est possible, dans n'importe quel type de données en fait. Pour info tu fais quoi dans les images comme data mining ?
@dgi77 : moi aussi je n'aime pas les tchatcheurs et dans la vie de tous les jours j'ai plutôt la même attitude que toi, essayant de balayer les termes pompeux pour découvrir ce qui se cache concrètement derrière. Par contre je n'ai jamais été impressionné par les costards cravate, préférant un bon jean et un t-shirt qui s'usent pas sur une chaise, mais ça ne m'empêche pas de devoir mettre un costard cravate quand je rencontre un chef.
Pour en revenir à l'intervention de pnoel-bi, il est vrai que sa réponse n'est pas une explication qu'on pourrait donner à un gamin de 5 ans mais elle est juste et plutôt complète. Si l'interlocuteur ne comprend pas la réponse, il est en droit de demander plus d'explications, c'est l'utilité d'un forum. Tu dénonces le raccourci dangereux qui consiste à penser que le data mining se résume aux outils de requêtage mais tu n'expliques pas plus ce que c'est. Et surtout, les métiers du data mining et du décisionnel sont des métiers avec un vocabulaire particulier (et très anglais) et je trouve que c'est plutôt bien de très vite habituer les débutants au vocabulaire du métier, pour qu'ils ne se sentent pas perdus plus tard.
Pour les requêtes mal conçues (j'appelle ça des "requêtes foireuses") je rappelle d'abord qu'il y a souvent un univers qui doit être designé pour construire les requêtes. C'est au Designer de monter l'univers de concert avec le DBA pour que les requêtes foireuses n'arrivent pas. Après si ça ne se passe pas comme ça, ça vient de l'équipe, pas de l'outil. Les requêtes foireuses ça existe aussi dans SQL*Plus, encore plus je dirais car il est plus simple d'oublier une jointure dans SQL*Plus que dans Business Objects.
Par contre pour les attitudes irrespectueuses des utilisateurs face au serveur ou aux informaticiens, je ne peux que t'appuyer(encore que j'ai des utilisateurs très gentils et reconnaissants).
enfin je rencontre qui travaille sur le sujetJ'en mène tous les jours, enfin façon de parler vu qu'une grosse partie du travail consiste à mettre à disposition des gens du métier (les contrôleurs de gestion, les analystes financiers, les responsables RH) les outils informatiques qui vont leur permettre à EUX de mener l'analyse.
Plateforme : Oracle en BDD, Genio en ETL pour les alimentations de données (entre la base de production et le datawarehouse par exemple) et les transformations, et en restitution SQL*Plus/SQLDevelopper pour moi et Business Objects 5/XI (on est en cours de migration) pour les utilisateurs.
@Jester : c'est vrai que le data mining dans des images est possible, dans n'importe quel type de données en fait. Pour info tu fais quoi dans les images comme data mining ?
@dgi77 : moi aussi je n'aime pas les tchatcheurs et dans la vie de tous les jours j'ai plutôt la même attitude que toi, essayant de balayer les termes pompeux pour découvrir ce qui se cache concrètement derrière. Par contre je n'ai jamais été impressionné par les costards cravate, préférant un bon jean et un t-shirt qui s'usent pas sur une chaise, mais ça ne m'empêche pas de devoir mettre un costard cravate quand je rencontre un chef.
Pour en revenir à l'intervention de pnoel-bi, il est vrai que sa réponse n'est pas une explication qu'on pourrait donner à un gamin de 5 ans mais elle est juste et plutôt complète. Si l'interlocuteur ne comprend pas la réponse, il est en droit de demander plus d'explications, c'est l'utilité d'un forum. Tu dénonces le raccourci dangereux qui consiste à penser que le data mining se résume aux outils de requêtage mais tu n'expliques pas plus ce que c'est. Et surtout, les métiers du data mining et du décisionnel sont des métiers avec un vocabulaire particulier (et très anglais) et je trouve que c'est plutôt bien de très vite habituer les débutants au vocabulaire du métier, pour qu'ils ne se sentent pas perdus plus tard.
Pour les requêtes mal conçues (j'appelle ça des "requêtes foireuses") je rappelle d'abord qu'il y a souvent un univers qui doit être designé pour construire les requêtes. C'est au Designer de monter l'univers de concert avec le DBA pour que les requêtes foireuses n'arrivent pas. Après si ça ne se passe pas comme ça, ça vient de l'équipe, pas de l'outil. Les requêtes foireuses ça existe aussi dans SQL*Plus, encore plus je dirais car il est plus simple d'oublier une jointure dans SQL*Plus que dans Business Objects.
Par contre pour les attitudes irrespectueuses des utilisateurs face au serveur ou aux informaticiens, je ne peux que t'appuyer
est ce que tu peux nous donner un document expliquant les différentes étapes pour la mise en place d'un tel projet.
sur le web , y a plein de documents, mais pas beacoup de pratique!
sinon pour moi j'essaie de cherche un outil pratique libre.
ma base de données contient plus ke 800 000 clients actifs, peut être qu'un outil libre ne pourra pas supporter une telle taille, non?
Alors te donner un document déjà non, parce que je n'ai que des docs écrits par et pour ma boîte.
Maintenant on peut imaginer écrire ce document tous ensembles sur ton besoin spécifique. Et si tu nous expliquait ton projet ? Qui tu es, ce que tu fais, tes besoins, tes ressources, tes compétences, tes délais, etc.
Sur ce sujet ou sur un autre (je ne sais pas si c'est très adapté de partir sur un cas spécifique après avoir discuté d'une question de fond, mais bon je ne suis pas modérateur).
Mon sujet se présente comme suit:
A partir d'une base de production on alimente un datawarehouse (JPIVOT) sauf que je ne suis pas connaisseur de cette étape, je suis amené à faire du DATA MINING à partir de ce datawarehouse déjà conçus par d'autres.
pour démmarrer le projet, on a décidé faire un test sur nos clients à risque.
premièrement cette condition n'est pas à priori exprimée d'une façon directe sur notre datawarehouse, mais qu'on peut extraire par une requête avec des conditions (du genre , un client à risque est un client qui a dexu impayés successifs ...). Dans cette optique, suis-je amené à créer une autre base ou une table qui contiendra le champ 'Risqe ou pas ' qui stoquera l'information si le cleint est à risque ou pas?
si je crée une telle base ou telle table, est ce que je dois la créer hors mon datawarehouse oui qu'elle doit faire partie de ce dernier (dans les régles de l'art ou dois-je la créer?).
sinon est ce que mon logiciel du DATA MINING (le choix n'est pas encore fait) pourra supporter les requêtes explicitant la condition sur les clients à risque sans passer par l'étape de création d'une table qui contient l'information explicite à savoir client à risque ou pas?
j'ai lu qu'il y a deux techniques pour le DATA MINING: 1- modèle descriptif 2-modèle prédictif. est ce que les logiciels du DATA MINING supportent à la fois les deux modèles?est ce que c'est à moi de choisir le modèle à utiliser?et comment faire ce choix?
sinon pour le modèle prédictif, pour savoir si un nouveau client sera à risque ou pas, est ce que je serai amené à entrer des paramètres sur le logciel et c'est lui qui me dira si oui ou non.
est ce que j'aurai accès à l'arbre de décision qu'il crée ou que ça fait partie de ses secrets?
est ce que j'ai la main sur le choix d'un tel ou tel algorithme pour la construction de l'arbre de décision?
j'ai lu aussi que les noeuds de cette arbre et ces feuilles sont créés à partir d'un certain calcul (le gain, l'entropie...), est ce que ces calculs se font par le logiciel sans que je ne connaisse comment ça se passe?
voilà des questions dont les réponses restent encore floues pour moi.
si vous avez des remarques et des réponses sur le sujet je vous serai très reconnaisant.
sinon à la fin je rédigerai un document qui pourra servir à tout le monde sur ce sujet.
merci pour votre lecture
Ok, voila des précisions intéressantes. Alors personnellement, je n'ai jamais utilisé un logiciel spécialisé dans le data mining. Tout est fait à la mimine. Pour débuter, et pour faire simple, je dirais (à chaud, comme ça, sans trop réfléchir) que tu as 2 solutions :
1) tu peux rajouter une colonne Risque à ta table des clients qui contiendra un chiffre à virgule représentant un % de risque
2) tu créées une table Risque ainsi : CLIENT_ID NUMBER, DATE_EVALUATION DATE, RISQUE NUMBER(0,2)
Dans la solution 1) tu vas extraire ce qu'il faut pour calculer un risque de chaque client, puis tu vas écrire le % de risque comme un attribut du client (comme son nom, sa ville et sa date de création quoi). Le problème c'est que le risque d'un client change en permanence, donc un client pas à risque peut devenir à risque le lendemain et inversement.
Dans la solution 2) tu vas extraire ce qu'il faut pour calculer un risque de chaque client, puis tu vas écrire l'id du client, la date du calcul et le % de risque dans une table à part (que je te suggère DANS le datawarehouse). Tu pourras ainsi évaluer l'évolution d'un client dans le temps, visualiser la variation des risques, etc.
Tu peux aussi faire un mix de la 1) et la 2).
Maintenant, ce qui t'intéresse : comment ? Ben ça je sais pas, on va attendre les conseils des autres. Personnellement moi je fais ça avec Genio, un ETL (un outil spécialisé dans l'extraction de données, la transformation et la ré-injection) mais sans Genio je ferais ça avec Java, avec du PL/SQL avec de simples requêtes SQL batchées, avec un ETL gratuit comme celui de Talend, avec du Visual Basic, etc. Enfin ce que tu veux du moment que tu es capable d'extraire des données, de les transformer et d'écrire le résultat en base.
Voila si tu as d'autres questions, je suis dispo. Mais je suis sûr que d'autres vont te donner des conseils, peut-être même à l'opposé des miens
@Jester : Pour info tu fais quoi dans les images comme data mining ?
Là c'est des images satellites très hautes résolutions, donc trouver des objets dedans. Ca peut sembler simple, mais des gens mettent du macadam sur le toit des immeubles, y a même des toits bleu, c'est du grand n'importe quoi. Puis y a des voitures qui sont pas dans des garages, des ombres partout ...
> j'ai lu qu'il y a deux techniques pour le DATA MINING: 1- modèle descriptif 2-modèle prédictif. est ce que les logiciels du DATA MINING supportent à la fois les deux modèles?est ce que c'est à moi de choisir le modèle à utiliser?
C'est le modèle qui choisit, quand tu segmente tes clients sans a priori c'est du descriptif, quand tu prédit un truc ... bah ... c'est prédictif.
Weka, par exemple, supporte les trois (il y a aussi les modèles associatifs, mais bon c'est une branche du descriptif disons).
> sinon pour le modèle prédictif, pour savoir si un nouveau client sera à risque ou pas, est ce que je serai amené à entrer des paramètres sur le logciel et c'est lui qui me dira si oui ou non.
Il peut le dire. Il peut aussi se tromper.
> est ce que j'aurai accès à l'arbre de décision qu'il crée ou que ça fait partie de ses secrets?
Si c'est un arbre de décision qui est créé c'est possible, sinon non. Il n'y a pas que les arbre de décisions dans la vie, c'est plus à la mode depuis ... au moins 15 ans (mais ça marche quand même très bien).
> est ce que j'ai la main sur le choix d'un tel ou tel algorithme pour la construction de l'arbre de décision?
A priori non, il n'y a en général qu'un algo pour faire des arbres de décisions par logiciel. Mais il y a d'autres algorithmes : réseaux de neurones, k plus proches voisins, support vector machines, ... et des meta méthodes pour compliquer le tout (bagging, boosting, one against all, ...).
> j'ai lu aussi que les noeuds de cette arbre et ces feuilles sont créés à partir d'un certain calcul (le gain, l'entropie...), est ce que ces calculs se font par le logiciel sans que je ne connaisse comment ça se passe?
Oui, pas besoin de connaître la magie derrière. Enfin si le problème est simple on peut utiliser un peu n'importe quoi, n'importe comment. Si ça ne marche pas avec la méthode simple là, il faut des gens compétents.
Ne pas oublier aussi que c'est pas de la magie, il lui faudra des exemples (cas concret de clients qu'on lui dise s'ils sont à risque ou non). Si on a ça, c'est qu'on a quelqu'un qui sait quand un client est à risque ou pas. On peut alors lui faire cracher l'arbre de décision. Ça nécessite de la torture des fois, mais les résultats sont pas mauvais. Mieux en général que du data mining mal fait. ET si ça suffit, que c'est moins cher, c'est que c'est la bonne solution.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager