LIBO 4.0.4.2. XP Pro. Croisement table et requêtes sur BASE.

fr-users
#1

Bonjour,

Soit une table comportant environ 6000 enregistrements. Soit une trentaine
de requêtages sur mots clefs à partir de cette seule table.

Chaque enregistrement a une clef primaire et cette clef unique est reprise
dans chacune des requêtes. J'ai donc au moins ce point commun entre chaque
réponse d'une requête et un enregistrement unique de la table.

Est-il possible (et comment) d'extraire de la table tous les enregistrements
qui n'ont pas été requêtés au moins une fois ? Question subsidiaire, comment
éviter les doublons ? Je m'explique, si je fais une requête sur le mot «
cantine » puis une requête sur le mot « impayé », j'aurai deux fois le même
enregistrement si le champ requêté est « impayé cantine ».

J'aurais la solution de réunir toutes mes requêtes au sein d'une seule table
puis de comparer cette table avec la première mais ce n'est pas très
satisfaisant.

Je vous remercie et vous souhaite une bonne journée,

Dominique

#2

Bonjour Dominique,

Bonjour,

Soit une table comportant environ 6000 enregistrements. Soit une trentaine
de requêtages sur mots clefs à partir de cette seule table.

Qu'entends-tu exactement par "requêtages" ?

Chaque enregistrement a une clef primaire et cette clef unique est reprise
dans chacune des requêtes. J'ai donc au moins ce point commun entre chaque
réponse d'une requête et un enregistrement unique de la table.

Est-il possible (et comment) d'extraire de la table tous les enregistrements
qui n'ont pas été requêtés au moins une fois ?

Quand j'aurais compris le sens du mot "requêtage", je pourrais peut-être
aider...ni la table en elle-même, ni la base de données ne tient compte
du nombre de fois que l'on l'interroge, ou n'ai-je rien compris à ton
histoire ?

Veux-tu dire "comment extraire les enregistrements qui n'ont pas été
renvoyés par l'une quelconque des requêtes précédemment exécutées sur la
table ?"
Il me semble que tes questions sont plutôt relatives à la construction
d'une requête SQL qu'à propos de la fonctionnalité LO Base, non ?

Question subsidiaire, comment
éviter les doublons ? Je m'explique, si je fais une requête sur le mot «
cantine » puis une requête sur le mot « impayé », j'aurai deux fois le même
enregistrement si le champ requêté est « impayé cantine ».

Il y a plusieurs façons d'arriver à ce résultat :
- une jointure interne sur la table ;
- l'utilisation du mot clé EXCEPT (si celui-ci est accepté par le moteur
de bdd) ;
- l'utilisation du mot clé DISTINCT ;
- l'utilisation de "AND NOT..." et j'en passe

mais pour l'instant, sans exemple concret de tes données, on va naviguer
dans le brouillard...

De ce que tu décris, il me semble que tes données ne soient pas
organisées de manière optimale si tu dois effectuer 30 recherches
différentes sur un champ texte, mais il nous manque peut-être des infos
complémentaires.

Alex

#3

Bonjour,

Je vois que je n'ai pas été très clair. Désolé. je vais essayer de me
rattraper. Et tu as raison, ma question est beaucoup plus dans le champs de
MySQL que des fonctionnalités de LIBO.

J'extrais de mon application informatique nationale Hélios (je suis
comptable public) un seul gros fichier recensant toutes les personnes qui, à
un titre quelconque, doivent de l'argent à une commune. Ce fichier (6000
lignes) est inexploitable sans retraitement. Il faut notamment distinguer
les types de dettes dues par ces personnes afin de spécialiser mon
recouvrement. Je ne vais pas agir de la même manière avec une cantine à 30 €
et des loyers à 1 000 €.

Voilà donc ces requêtes : extraire d'un champs unique « Objet du titre » un
ou des mots clefs qui me permettent de caractériser la recette (loyers,
droits de voirie, cantines, restaurant administratif, centres de loisirs,
voyages scolaires etc).

J'ai donc une table avec 6000 enregistrements distingués par une clef unique
ID. J'ai une trentaine de requêtes qui me permettent d'extraire une
trentaine de types de recettes, chaque enregistrement restitué par une
requête comporte un champs avec la clef unique ID de l'enregistrement
d'origine dans la table.

Mes requêtes ont leurs limites car les employés communaux font preuve d'une
certaine imagination pour remplir le champs « objet du titre » qui, pour des
centres de loisir, peut être « centre de loisir », «centre loisir », «
c.loisir (avec ou sans espace), « clsh (avec ou sans point et/ou espace
entre chaque lettre) » etc. Une requête sur le mot « centre » me retournera
indifféremment le centre culturel, médical, musical et autres.
Accessoirement, Hélios se charge de modifier les libellés pour m'occuper un
peu plus : « cen tre », « impay es »ce qui me permet d'obtenir quelques «
c.loi sir » par exemple... etc.

Au final, mes requêtes ne couvrent pas 100% des enregistrements de ma table.
Je voudrais justement, à partir de ces requêtes, extraire de ma table tous
les enregistrements qui, précisément, n'ont pas été identifiés par une
requête.

À la brutale, j'ai réuni hier dans une même feuille de Calc chaque requête
depuis Base (copie requête, collage dans Calc) afin de créer une nouvelle
table que j'ai placée dans base. J'ai pu alors sans difficulté comparer
(avec les champs ID) ma table d'origine et extraire les enregistrements qui
ne se trouvaient pas dans ma seconde table mais cette méthode est très
lourde.

Est-il possible, objet de ma question, de faire ce travail de tri
directement depuis les requêtes et Base sans passer par la réalisation de
cette seconde table dans Calc ?

LIBO règle sans difficulté la question des doublons. Ce n'est donc plus un
problème.

Compte-tenu de la nature même de mon fichier qui est un rien confidentiel,
(noms et adresses de personnes débitrices d'une grosse commune), tu
comprendras qu'il m'est difficile de le mettre en ligne :slight_smile:

Je te remercie pour ton aide et te souhaite une bonne journée,

Dominique

#4

Bonjour Dominique,

J'extrais de mon application informatique nationale Hélios (je suis
comptable public) un seul gros fichier recensant toutes les personnes qui, à
un titre quelconque, doivent de l'argent à une commune. Ce fichier (6000
lignes) est inexploitable sans retraitement. Il faut notamment distinguer
les types de dettes dues par ces personnes afin de spécialiser mon
recouvrement. Je ne vais pas agir de la même manière avec une cantine à 30 €
et des loyers à 1 000 €.

Je ne peux que constater avec une certaine ironie que le Trésor Public
demande de l'aide (qui plus est bénévole) à ces citoyens pour l'assister
à récupérer les sommes qui lui sont dues :wink:

Plus sérieusement, je pense qu'avant tout, il te faut normaliser au
maximum les données contenues dans le champ "Objet du titre", sinon je
ne vois pas comment tu peux espérer à long terme faire un travail
correct sans y passer des heures/journées et/ou à côté de ce que tu
cherches à accomplir. Je suis aussi un peu étonné que tu n'aies pas
d'accès à un service informatique qui te permettrait de mettre ces
données dans une forme exploitable avant de pouvoir faire tes requêtes.
Je suis aussi étonné que chaque commune soit libre de choisir le libellé
qu'elle veut lors de la saisie des créances !!

J'imagine que le fichier que tu télécharges est sous forme texte, genre
CSV ou TXT ? Dans ce cas, un script de retraitement (en Perl, ou Bash,
voire même WSH, par exemple) serait l'idéal, avec lequel tu pourrais
normaliser les données avant de les charger dans Base. Par "normaliser",
j'entends que les libellés soient uniques et homogènes pour chaque type
de créance. A défaut de ça, avoir la possibilité d'ajouter un champ
d'indexation pour chaque type de créance, et de ne faire qu'une seule
requête paramétrée avec laquelle tu n'aurais qu'à rentrer le numéro
d'index à chaque fois. Ici encore, si le fichier sources est sous forme
de texte, cela devrait être possible par le biais d'un script de
manipulation. Evidemment, cela suppose de faire appel à quelqu'un ou à
un service informatique ayant les compétences nécessaires (ce n'est pas
mon cas, ne maîtrisant pas encore sed/awk :wink: ).

Faire ce travail en amont va te faire gagner des heures par la suite,
c'est donc un investissement "rentable" à mon sens. Autrement, je ne
vois pas comment tu t'en sortiras, sauf à y passer des heures, ou à
faire des requêtes compliquées, comme cela semble être le cas actuellement.

Saches que si tu ne peux vraiment pas faire autrement que passer par des
requêtes sur des données non-normalisées, alors dans ce cas, il va
falloir que tu lises la documentation sur les requêtes SQL mettant en
oeuvre des mots clés comme "UNION", "CREATE TEMPORARY TABLE", "SELECT
INTO", ou "CREATE VIEW <viewname>[(<viewcolumn>,..) AS SELECT ... FROM"
(commande pour créer une vue avec hsqldb)

Alex

#5

Bonjour Dominique,

Bonjour,
[...]
Au final, mes requêtes ne couvrent pas 100% des enregistrements de ma table.
Je voudrais justement, à partir de ces requêtes, extraire de ma table tous
les enregistrements qui, précisément, n'ont pas été identifiés par une
requête.

Une suggestion peut-être naïve : ne serait-il possible d'ajouter une
colonne à la table et chaque fois qu'un enregistrement est attrapé par
une requête de lui ajouter un attribut avec par exemple le numéro de la
requête gagnante ou un simple booléen ? Ensuite il suffit de filtrer la
table pour extraire les enregistrements pour lesquels la colonne
supplémentaire est vide.

Bonne journée
JBF

#6

Bonjour,

Le Trésor Public n'existe plus. Il est remplacé par la DGFiP :slight_smile:

Accessoirement, la presque totalité des recettes des collectivités locales
concernent des services rendus. Difficile d'en contester la légitimité «
morale ».

Le champs « Objet du titre » est en saisie libre à l'initiative des
collectivités locales. Tous les comptables publics tentent bien d'en
normaliser la graphie mais le poids des habitudes reprend vite le dessus.
Dit autrement, à part sensibiliser les mairies (et autres collectivités), je
n'ai pas la main sur cette partie de leur travail. Il ne me reste pas
d'autre alternative que de faire des requêtes complexes.

En l'occurrence, je suis comptable d'une grosse commune avec, en face de
moi, une dizaine de personnes susceptibles d'émettre des titres, chacune
ayant ses habitudes qui sont, par essence, meilleures que celles de ses
collègues. Pour autant, je retrouve une certaine stabilité dans la rédaction
de ce champs « objet du titre » et, au fil du temps, mes requêtes s'affinent
et se stabilisent. J'ai mis 3 ou 4 jours pour réaliser mon premier tableau
de bord. Maintenant, je recycle mes requêtes et mon travail est tombé à
environ une heure/mois. C'est acceptable.

Je vais approfondir les termes SQL que tu me conseilles.

Merci et bonne journée,

Dominique

#7

Bonjour,

Ton idée est séduisante. Connais-tu une solution pour automatiser le service
de ce champs booléen dans la table ?

Je te remercie et te souhaite une bonne journée,

Dominique

#8

Bonsoir,

Bonjour,

Ton idée est séduisante. Connais-tu une solution pour automatiser le service
de ce champs booléen dans la table ?

Aucune idée, je ne connais rien au langage de requête, mais j'ai supposé
qu'il permettait de faire un truc de ce genre.

Bonne soirée
JBF

#9

Bonjour,
Pour les requêtes, tu trouveras le Guide HSQLDB ici :
http://wiki.openoffice.org/wiki/FR/Documentation/HSQLDB_Guide/ch09#SELECT

"Valeurs par défaut permises dans les définitions de colonnes :

     Pour les colonnes de type BOOLEAN, les littéraux FALSE, TRUE, NULL. "

J.M

#10

Bonsoir Dominique,

Je pensais à une fonction spécifique mysql, puisque tu as apparemment accès
au serveur.

Si les tables interrogées utilisent le moteur myisam, il est possible
d'indexer le champ texte et puis utiliser la fonction MATCH sur le champ
avec une liste de chaînes de caractères à rechercher dans une seule requête
(par exemple tes variantes de centre, cdr, etc. Peut-être une piste à
explorer ?

Alex