Discussion :

[grunt2000]

Bonjour,


Mon entreprise a, avec le temps, énuméré plusieurs indicateurs pour repérer ses clients.
Des choses telles que: "Celui qui a acheté plus de trois articles l'an dernier", "Celui qui nous paie toujours avec un crédit renouvelable", "Celui qui répond à plus de deux offres promotionnelles que l'on fait par an.", etc.

Ces indicateurs correspondent à des conditions de requêtes SQL dont on connait le sens: par exemple, "Paie toujours avec un crédit renouvelable" sera: "NB_PAIEMENTS_CREDIT_REVOLVING / NB_COMMANDES > 0.8".

Par la suite, d'autres indicateurs ont été créés qui découlaient d'eux: si tel client est ceci et cela en même temps, mais n'a pas telle propriété, alors on peut aussi le repérer d'une indication supplémentaire, qui est utile aux études.

Des indicateurs comme ceux-ci, je vais les appeler des faits, j'en ai une bonne trois-centaine...

1) Qui se redéfinissent parfois (alors qu'ils ne devraient pas).

2) Qui se mordent la queue (tel fait ne se rend pas compte qu'il emploie tel autre fait qui entraine une définition circulaire).

3) Les faits composés d'autres faits sont parfois invalides: d'autres compositions reprenant partiellement leur définition - pour établir d'autres faits - peuvent donner une règle contradictoire.

Pour relever un grand nombre de ces incohérences, il m'a semblé que Prolog était tout indiqué.


Ai-je raison de le penser?


En vous remerciant,

Grunt.

[Trap D]

Le problème est intéressant mais je ne sais pas si Prolog est le plus pratique pour ça. Il existe des liaisons Prolog SQL, pour Windows et SWI-Prolog : http://www.swi-prolog.org/pldoc/package/odbc.html
A vous de voir.
Sous quel format sont définis les différents critères ?

[grunt2000]

Mon problème évoque des fragments de requêtes SQL, mais je me propose de simplifier mon problème en établissant directement les faits:
acheteTroisArticlesAnDernier.
acheteAvecCreditRenouvelable.
repondAplusDeDeuxOffresPromoParAn.

sans prendre la peine de détailler la condition SQL qu'il y a réellement derrière. Car ce qu'elle est concrètement n'est pas ce qui m'intéresse le plus.
Éventuellement, je la noterai en tant que commentaire et si dans mon une condition SQL prétend définir un fait déjà existant, je m'assurerait de visu qu'il ne jure pas avec ce que j'en connais déjà.

Ce que je souhaite repérer, c'est surtout si des règles composées de ces faits:
clientPrivilegie: acheteTroisArticlesAnDernier, repondsAplusDeDeuxOffresPromoParAn.

clientPrivilegie: acheteAvecCreditRenouvelable, repondsAplusDeDeuxOffresPromoParAn.

ne sont pas définies de manière qu'elles:
- sont incohérentes les unes avec les autres.
- provoquent un cycle dans leur résolution.


Et je pensais que Prolog pourrait peut être m'aider, ayant alors un grand nombre de règles composées établies.

Grunt.