FileMaker: Recherche rapide

Trouvez une fiche en un rien de temps, sans recherche, sans cliquer:
de l'utilité d'une base de données relationnelle à... un seul fichier.

Ce que nous allons vous présenter dans cette première partie (à télécharger pour Mac et pour PC, au format FileMaker 5, avec le PDF de cet article) n'est pas sorcier techniquement, mais représente surtout un effort conceptuel lié à la représentation que l'on se fait d'un fichier FileMaker, quelque part à mi-chemin de la simple liste à la base de données relationnelle partagée en réseau. Autant vous mettre en garde tout de suite: nous allons mettre à mal quelques notions profondément ancrées chez les habitués: l'affichage sous forme de liste, la souris et les boutons, et le Mode Recherche, notamment.

La liste et la recherche vont perdre de l'importance au profit de la table externe et du lien sur un index, respectivement, la souris va être délaissée pour laisser s'exprimer le clavier, les touches Tab et Enter.

L'idée de départ est la suivante, et elle peut s'appliquer strictement à n'importe lequel de vos fichiers FileMaker: nous allons utiliser un modèle, un masque, une présentation, une vue, une zone, appelez cela comme vous voulez (via une simple table externe) affichant une liste restreinte des propres fiches du fichier, dépendantes d'un indice que l'on changera à volonté. Cet indice peut parfaitement être un champ de saisie libre, mais aussi, pourquoi pas, un ou plusieurs menus prédéfinis.

Autrement dit: pour retrouver une fiche donnée, au lieu d'utiliser

• le Mode Recherche
• plusieurs champs (autant que nécessaire)
• l'Affichage sous forme de liste pour afficher les résultats.

nous allons utiliser:

• un seul champ d'indice
• un index calculé pour chaque fiche
• une table externe liant les deux.

Ce qui nous permettra, au prix d'un peu de programmation, d'éviter des centaines de clics et de raccourcis-clavier quotidiens à chaque utilisateur de la base de donnée concernée. Ce qui peut représenter, sur le long terme, un gain conséquent d'efficacité, et de grosses économies.

NB: cette table externe est si l'on veut bien une table interne, puisqu'elle affiche les fiches du même fichier: rien n'interdisant un fichier d'être lié à soi-même, ce qu'on appelle aussi une "self-relationship". C'est ainsi qu'on lie une fiche aux autres fiches avec qui elle coexiste au sein du même fichier (ce qui est précieux par exemple lorsque l'on recherche des doublons).

Explication plus sensorielle: une Recherche traditionnelle se déroule un peu à l'aveugle: on passe en recherche (tous les champs se vident, en quelque sorte on "décolle" du fichier), on met les critères (des fois on ne sait plus bien où va quoi), on clique, ça mouline, et paf! le résultat est là, brutalement. Si ce n'est pas exactement ce que l'on désire, on recommence. Et on redécolle. Il est possible, et souhaitable, de rester plus proche du fichier et de ses précieuses données.

Notre approche a l'énorme avantage de toujours vous laisser les yeux ouverts: vous rentrez un critère, et vous voyez le résultat avant de basculer dans la ou les fiches (via le lien de la table externe). L'avantage est de ne jamais perdre les données de vue, un peu comme un skieur a un meilleur contrôle en restant en contact avec la neige en réduisant les sauts au minimum, ce qui lui fait gagner des fragments d'instant...

Explication plus technique: là où FileMaker se démarque profondément de bien d'autres bases de données, c'est qu'il admet qu'un champ contienne plusieurs valeurs. C'est qui se traduit par:

• les rubriques multivaluées (valeurs séparées par un caractère ASCII spécifique) ou
• un champ contenant plusieurs valeurs séparées par des retours chariots (ou return)

C'est simple à dire, mais il reste difficile d'en visualiser les effets concrets et d'en saisir a priori toutes les implications. Attendez la troisième partie de notre article pour saisir pleinement ce que nous voulons dire, nous détaillerons la puissance que l'on peut tirer de l'association astucieuse de ces deux types de valeurs multiples au sein d'un seul champ.

<digression> Cette caractéristique de FileMaker divise profondément les développeurs (en suscitant le mépris unanime des non-connaisseurs de FileMaker, dont François, pour quantité d'autres raisons): même parmi les pro-FileMaker, il y a les pro- et les anti-multivaluées. Elles sont pourtant très utiles lorsqu'il n'est pas nécessaire d'utiliser un fichier lié, mais qu'on a simplement besoin de valeurs liées entre elles. Par exemple lorsque le nombre des valeurs à mémoriser est prévisible, et que plusieurs champs différents doivent suivre le même schéma (plusieurs multivaluées étant liées entre elles par leur "profondeur"). On peut donner l'analogie suivante: si les fiches étaient les lignes dans un tableur Excel (axe des X) et les rubriques les colonnes (axe des Y), les rubriques multivaluées seraient alors des valeurs en relief (axe des Z). Certains les utilisent avec délectation, d'autres ne conçoivent de vraies bases de données que réduites à deux dimensions (en aplatissant deux valeurs dans deux fiches distinctes plutôt que de les empiler dans le même champ). François et 4D aiment la 2D (étonnant, pour 4D, justement!), mes fichiers FileMaker ont du relief, eux. Mais revenons à nos moutons. </digression>

Nous allons commencer par exploiter pleinement cette seconde spécificité, en jouant sur les valeurs multiples séparées par autant de return que nécessaire. Et ceci non seulement au bout d'un lien (c'est le cas ici, pour notre index), mais aussi à sa source (dans le troisième volet de notre article).

Maintenant que tout le monde a compris le principe, allons-y: les conséquences vont être importantes. Accrochez vos ceintures, FileMaker ne sera plus tout à fait le même après ce voyage au pays des indices, des index et des liens many-to-many. François, tu nous suis? François? Il n'a pas supporté...

Pour illustrer notre propos, considérons un fichier très commun: un fichier de Personnes (Adresses, Clients, Fournisseurs, Patients, bref, des personnes, morales ou physiques, mais on pourrait tout aussi bien appliquer notre concept à des objets, des livres, des articles, du matériel). Dans un tel fichier central, avec lequel on travaille tous les jours pendant plusieurs années, un besoin reste constant: accéder rapidement à une fiche, puis à une autre, sans jamais les confondre ni créer des doublons. La "recherche" est donc de toute première importance. Il vaut la peine d'y consacrer un peu de temps de développement. Même beaucoup.

Parfois, l'utilisateur-développeur met en place un modèle spécifique pour la Recherche, voire des scripts: de même, avec notre approche, on peut imaginer mettre en place un masque d'accueil servant à trouver des fiches destiné à l'affichage de notre table externe affichant certaines fiches correspondant à un indice donné (comprenez-le comme une sorte de modèle d'entrée dans le fichier, accueillant l'utilisateur en disant "Bonjour, dans quelle fiche voulez-vous vous rendre?", permettant d'atteindre n'importe quelle fiche, comme si le Mode Recherche précédait le Mode Utilisation, contrairement à ce qu'indique l'ordre des menus de FileMaker.)

Nous nous efforçons de dire trouver une fiche, plutôt que de la rechercher, un peu comme dans un livre on trouve un mot par l'index plutôt qu'en parcourant tout le texte. On trouve une fiche sans la rechercher, en fait.

Pour ceux qui ont déjà saisi le principe: on peut aller plus loin, et choisir d'incorporer cette table externe, cette liste, en regard de la fiche détaillée d'une Personne, un peu comme on garde le doigt entre deux pages de la table des matières en cherchant un passage d'un livre. Ainsi, c'est plus coulé; on est dans une fiche, mais on est déjà un peu dans la prochaine, celle où l'on va atterrir. On voit plusieurs fiches à la fois, une en détail, et n'importe quelles autres à côté. La grosse différence, c'est qu'on voit une fiche et une liste de fiches dans la même fenêtre (deux modes à la fois, le beurre et l'argent du beurre). D'une certaine manière, on voit déjà le futur, le prochain clic. Cette prémonition sera d'autant plus utile que souvent, on cherchera à faire le mouvement inverse, revenir à la fiche précédente (objet de notre second volet). Comprenez cela comme le feu orange entre le vert et le rouge, et entre le rouge et le vert. Vous souvenez-vous, il y a quelques années, lorsque le feu orange était absent de nos règles de circulation? Combien d'inutiles coups de klaxon rageurs pour faire démarrer le conducteur distrait, planté devant vous?

Mais rentrons dans le vif du sujet. Téléchargez, si ce n'est pas encore fait, le fichier de démonstration pour Mac et pour PC. François?

Exemple niveau 0: nom et prénom

On tape quelques lettres (ici "be"), et les fiches contenant "be" sont affichées. Rien de bien folichon, une simple Recherche dans un champ donnerait presque la même chose. N'oubliez pas que nous ne sommes encore qu'au degré zéro de la puissance de notre index. On ne va pas non plus vous assommer tout de suite.

On voit des "Besson", mais aussi déjà des "Bernard", puisque notre Indice pointe vers un Index contenant opportunément les valeurs des champs sur lesquels se font les recherches les plus courantes:

• le numéro de la fiche
• des fragments du champ de nom
• des fragments du champ de prénom.

NB: Le prénom est utile bien souvent, premièrement pour différencier deux fiches portant le même nom, deuxièmement pour retrouver une fiche dont le nom aurait changé (un prénom ne change quasiment jamais).

Remarque: vous pouvez bien entendu rajouter à cet index calculé tous les champs qui vous sembleront pertinents. Attention cependant à ne pas vouloir trop en faire (en rajoutant le NPA, la ville, le numéro de bureau ou d'étage, la date de naissance, etc.). En effet, l'index de Recherche Rapide ne peut pas être un fourre-tout, encombré par des critères de recherche moins fréquents, qui eux nécessiteront un passage occasionnel en mode Recherche. Ce n'est pas tant une question de performance que de pertinence (FileMaker c'est comme la confiture: il apprécie les index, surtout lorsqu'ils sont gros, mais l'important reste de fourrer ses doigts dans le bon pot). A vous de trouver le juste milieu: les identifiants y ont nécessairement leur place, et quelques autres champs choisis soigneusement. Il ne faut pas mélanger des champs de types similaires (les NPA sont des chiffres, les identifiants aussi, par exemple, un index où ils se retrouveraient mélangés ne serait pas très utile, l'identifiant doit impérativement le rester).

Exemple niveau 1: noms et prénoms

Indice: "du"

Indice: "vo"

Indice: "li"

Ça devient plus intéressant: on trouve les noms de quelques personnes dont le second nom ou le second prénom contient l'indice. En effet, notre index magique recense plusieurs mots pour chaque champ:

• quatre mots figurant dans le champ du nom.
• deux mots figurant dans le prénom.

NB: quatre mots pour le nom suffisent pour trouver les noms composés à particule, même portugais à rallonge. Deux mots suffisent en général pour tous les prénoms composés. Ce raffinement se révèle utile lorsque l'on travaille sur un fichier dont les Personnes évoluent: les gens se marient, ou se font appeler par un prénom qui n'est pas toujours l'officiel.

Exemple niveau 2: noms d'alliance

Ça devient plus surprenant encore: notre index magique répertorie aussi des mots dans des champs non apparents:

• deux mots supplémentaires figurant dans le nom précédent.

NB: Les gens se marient, mais aussi se séparent. Dans les deux cas, deux impératifs s'opposent:

1. pour les utilisateurs du fichier, il faut conserver un certain temps le nom antérieur, car chacun ne peut pas être instantanément au courant de tous les changements, il faut se ménager un certain temps pour faire la transition en douceur, garder un certain écho
2. en revanche, pour la personne en question, il faut respecter scrupuleusement et immédiatement le nouveau nom qu'elle aura indiqué (spécialement en cas de divorce, transition plus abrupte que le mariage, il faut cesser l'utilisation publique du nom précédent).

C'est pour ces deux raisons qu'un champ supplémentaire est utilisé. Il est aussi incorporé à notre index, mais n'apparaîtra jamais sur une liste ou une étiquette, ce qui risquerait d'irriter la personne concernée.

Exemple niveau 3: ponctuation

Indice: "del"

Indice: "le"

Indice: "en"

A ce stade, on constate deux choses encore: les éventuels caractères de ponctuation rentrés par l'utilisateur sont ignorés (espaces, apostrophes, traits d'union), et le tri se fait uniquement sur les lettres de l'alphabet: la ponctuation est ignorée dans l'index, mais aussi pour le tri des fiches liées, ce qui est plus correct que le tri alphabétique mécanique proposé par les ordinateurs, qui classent les chiffres, les espaces et les apostrophes systématiquement avant les lettres (car ils figurent avant dans la table ASCII). C'est bien la preuve que les ordinateurs sont très bêtes, et préfèrent les nombres et les séparateurs aux lettres.

• on nettoie donc l'indice de tout caractère parasite avant d'en faire la source du lien.
• on trie la table externe sur des champs de nom et de prénom dont la ponctuation a été retirée.

Exemple niveau 4: lettres cachées

Le risque existe de ne pas trouver une fiche si son nom est orthographié différemment qu'on le présume. En général, un second essai, avec moins de lettres, permet de s'en sortir. Mais il y a aussi des lettres farceuses: les Laetitia, les Descoeudres, (qui devraient s'écrire Lætitia et Descúudres, mais est-ce que ces caractères passent en HTML?), mais surtout, plus fréquents, les caractères allemands ä, ö et ü, comme dans le patronyme Müller, qui pour certaines personnes s'écrit officiellement Mueller. Mais comment le savoir à l'avance? Eh bien, il vaut mieux ne pas le savoir!

Indice: "mu"

Indice: "mü" (ou "mue")

Indice: "kä" (ou "kae")

On arrive dans ce cas de figure à isoler encore quelques fiches qui nous auraient autrement échappé.

NB: on substitue ici "ue" à "ü", mais il serait faux de faire l'inverse! En effet, les "...gue..." ou "cue...", entre autres, contiennent des paires de caractères fréquents et parfaitement corrects dans la langue française, et doivent s'écrire exclusivement de cette manière. Dans tous les cas, en cas de doute, il vaut mieux utiliser le caractère avec umlaut, de manière à laisser l'index pointer tout seul vers les deux orthographes potentielles.

Exemple niveau 5: presque identifiant, et vrai identifiant

On n'a jusqu'ici indiqué que des portions de nom ou de prénom séparément. Cela restera toujours les attributs les plus faciles à mémoriser pour retrouver la fiche d'une personne ("Bonjour, M. P8734, comment allez-vous?", c'est de l'Asimov, pas du Proust). En conséquence, l'index nous permet aussi d'utiliser une combinaison courte du nom et du prénom (trois lettres de chaque, et inversement) pour donner un semblant d'identifiant, très compact (six lettres) tout en restant très discriminant.

Indice: "matbes", ça marche

Indice: "marlau", ça foire

Indice: "204", là, c'est univoque

On voit ici que si la plupart du temps, on atteint une seule fiche (avec par exemple "matbes" comme indice), on n'y arrive pas systématiquement (comme le montre l'indice "marlau"). Or les fichiers ont souvent plusieurs milliers de fiches, et notre exemple n'en contient que 400: une combinaison de 3+3 lettres ou toute autre astuce ne seront pas suffisamment puissants pour restreindre complètement les fiches apparaissant dans la table externe.

Dès lors, le seul vrai, rapide et efficace moyen de pointer une seule fiche parmi toutes, c'est par son identifiant, rien d'étonnant (troisième exemple). Retenez bien cela pour la prochaine fois. L'index inclut forcément aussi ce paramètre, c'est même le tout premier champ à y figurer (l'identifiant, c'est le Mohican de la phrase bien connue).

Je vous laisse tester par vous-même l'efficacité d'un champ d'indice associé à un index pour chaque fiche. Le fichier de démonstration (pour Mac et pour PC) peut d'ailleurs être vidé, afin de vous permettre d'importer, au format tabulé, les champs Nom et Prénom que vous voudrez. Ainsi, vous percevrez mieux l'utilité que pourrait avoir cette routine de Recherche Rapide prête à l'emploi dans votre situation.

N'hésitez pas à m'écrire pour me faire part de vos commentaires, ou pour me demander de vous envoyer le mot de passe administrateur de Recherche Rapide pour inclure cette routine à vos développement personnels. Elle n'est pas gratuite, mais elle pourra vous faire gagner beaucoup, beaucoup de temps à l'utilisation.

La prochaine fois, nous verrons comment naviguer de fiche en fiche en avant et en arrière, comme dans le Finder de Mac OS X ou dans tout bon navigateur qui se respecte. François, tu te remets?

23 février 2003, Mathieu Besson