Copyright © 2000-2011 Yves MARCOUX; dernière modification de cette page: 2011-10-05
Cette création est mise à disposition sous un contrat Creative Commons

Les SGBD textuels

Yves MARCOUX - EBSI - Université de Montréal

Résumé

Ce texte présente les principales caractéristiques des Systèmes de gestion de bases de données textuels (SGBD textuels ou SGBDT), en les comparant avec les fonctions de recherche de fichiers (FRF) des systèmes d’exploitation courants. Un exemple de telle fonction est l’outil Windows Search, intégré au système d’exploitation Windows 7. Ces fonctions permettent la recherche tant dans les métadonnées des fichiers que dans leur texte intégral (si applicable). Le lecteur est supposé familier avec ce genre de fonctions.

Une certaine familiarité, moins grande, avec les logiciels de recherche en texte intégral (LRTI), comme NatQuest Pro, est aussi présupposée. Une démonstration d’un logiciel de ce type est suffisante pour atteindre le niveau de familiarité requis.

Retour sur les FRF et les LRTI

Les FRF permettent d’effectuer des recherches dans divers ensembles de fichiers. Ces fichiers peuvent être, entre autres, des fichiers texte, des documents de logiciels de traitement de texte, d’autres documents de bureautique, mais aussi des photos, des fichiers sonores ou des vidéos. Avec ces outils, la recherche s’effectue en soumettant au logiciel des requêtes, pouvant comporter différents opérateurs comme la troncature, la recherche d’expression ("…" dans Windows Search) et les opérateurs booléens ET, OU et SAUF (AND, OR et NOT dans Windows Search). La recherche peut porter tant sur le texte intégral des fichiers (pour les types de fichiers qui comportent du texte intégral) que sur les métadonnées.

Il est important de réaliser que ces outils sont d’abord et avant tout pensés pour faire des recherches dans des documents déjà saisis ou, en tout cas, déjà existants. Cela veut dire que les fichiers sur lesquels porte la recherche ne sont pas créés dans le but spécifique de faciliter la recherche ou de bien s’intégrer dans un outil de recherche, mais dans un but autre, le plus souvent de communication. Par exemple, un document de traitement de texte comme un procès-verbal est créé et saisi pour remplir au sein d’une collectivité une fonction de communication qui dépasse de beaucoup la recherche d’information. De même, une photo ou une vidéo est créée avec la finalité première de communiquer un message, et non d’être facile à repérer. La recherche d’information constitue une exploitation secondaire de ces documents.

Même si les LRTI offrent des fonctionnalités de recherche passablement plus puissantes que les FRF, il demeure que leur principe de fonctionnement est largement similaire et qu’ils sont fondamentalement pensés eux aussi pour faire des recherches dans des ensembles de documents déjà saisis.

Aperçu général des SGBD textuels

Prise en charge de la saisie de l’information

Une des différences entre les SGBD textuels d’une part et les FRF et les LRTI d’autre part, est que les SGBD textuels prennent en charge la saisie de l’information. C’est pourquoi on retrouve toujours un « module de saisie » ou une « interface de saisie » dans un SGBDT.

Il s’agit là d’une différence fondamentale. En effet, comme le SGBD textuel est impliqué dans la saisie de l’information, il peut d’une part (i) intégrer des fonctions destinées à faciliter la saisie et/ou à réduire les erreurs à la saisie (par exemple, montrer à l’écran des exemples à suivre). Il peut d’autre part (ii) valider l’information saisie en fonction de règles prédéfinies (par exemple, pour s’assurer qu’une date saisie est bel et bien valide, ou qu’une information obligatoire est bel et bien fournie). Finalement, il peut (iii) s’assurer que l’information saisie est structurée de façon à faciliter la recherche d’information et sa présentation (à l’écran ou sur papier) sous les formes les plus diverses (par exemple, en demandant de saisir un nom et un prénom séparément, plutôt qu’ensemble).

Ainsi, avec un SGBD textuel, l’information est saisie entre autres dans le but d’être facilement repérable. La recherche d’information est donc une préoccupation première, et non secondaire.

Notons que dans certaines circonstances, un SGBDT peut être appelé à travailler avec de l’information déjà saisie préalablement, notamment par le truchement de fonctions d’importation du SGBDT, qui permettent par exemple de migrer des données d’un système existant vers une base de données. Même dans ces cas, cependant, les mêmes contraintes sur les données entrantes s’appliquent que si l’information était saisie dans le SGBDT lui-même, et la situation est fort différente des FRF et des LRTI, qui doivent s’accommoder de l’information telle que saisie, ne peuvent compter sur aucune structuration particulière de l’information et n’ont aucune possibilité de valider et éventuellement rejeter certaines données.

En résumé, un SGBDT est d’abord et avant tout pensé pour prendre en charge la saisie de l’information qui entre dans une base de données, même si d’autres scénarios d’entrée de données sont possibles.

Unité de base repérable : la fiche

Une autre différence importante est l’unité de base repérable. Avec les FRF (et souvent aussi avec les LRTI), l’unité de base repérable est le fichier; c’est-à-dire qu’une requête de recherche retourne, ou donne comme résultat, un certain nombre de fichiers. (La recherche en système d’exploitation peut en général retourner aussi des dossiers).

Avec un SGBD textuel, l’unité de base repérable est la fiche ou l’enregistrement (en anglais « record »). Dans un SGBDT, une base de données (BD) n’est en fait rien d’autre qu’un ensemble de fiches regroupées ensemble. Une base de données porte un nom, qui lui est assigné au moment de sa création, et lorsqu’on démarre le SGBD, on spécifie sur quelle BD on veut travailler. Au cours d’une séance de travail sur une BD, on peut y ajouter des fiches, en retrancher et/ou en modifier. Et on peut bien sûr formuler des requêtes, dont le résultat sera toujours un sous-ensemble des fiches de la BD. Tout comme une requête représentait un critère de sélection des fichiers dans une FRF, une requête dans un SGBDT représente un critère de sélection des fiches de la BD.

On appelle base de données textuelle une BD créée avec un SGBD textuel.

Bien qu’une base de données soit stockée concrètement sous forme de fichiers, il n’y a aucune correspondance directe entre les fiches contenues dans la BD et les fichiers qui servent physiquement à entreposer celle-ci. À preuve : la plupart du temps, le nombre de fichiers servant à entreposer une BD est complètement indépendant du nombre de fiches dans la BD. La notion de fiche est donc un concept abstrait qui n’a pas de correspondant physique direct en termes de fichiers.

Structuration d’une fiche : les champs

Comme son nom le suggère, une fiche est un ensemble d’éléments d’information qui se rapportent à un même objet. Ces éléments d’information s’appellent les champs de la fiche. Tous les champs d’une même fiche se rapportent au même objet. Cet objet est en général un objet du monde réel (concret ou abstrait) dont on désire enregistrer et manipuler certaines caractéristiques. Ce pourrait être par exemple un spécimen de papillon recueilli lors d’une expédition. Dans ce cas, les différents champs de la fiche seraient des choses comme le nom de la région où le spécimen a été capturé, ses dimensions, le nom de l’espèce, la date de capture, etc. Si l’objet est une ressource d’information, alors les champs seraient plutôt le nom de l’auteur, le titre, la date de parution, etc.

Chaque champ porte un nom, qui doit être indicatif de l’élément d’information auquel il correspond (par exemple « région où capturé », « auteur » ou « date de parution »). L’ensemble des champs d’une fiche définit ce qu’on appelle la structure de la fiche.

Avec un SGBDT, toutes les fiches dans une même BD ont la même structure, c’est-à-dire qu’elles possèdent toutes les mêmes champs. Toutes les fiches d’une BD se rapportent donc à des objets du même type (par exemple, toutes à des spécimens de papillon ou toutes à des ressources d’information). Le concept de BD correspond donc tout naturellement à celui de collection d’objets d’un certain type.

Comme toutes les fiches d’une BD ont la même structure, on appelle cette structure « la structure de la BD ». Il s’agit de l’ensemble des champs que toutes les fiches dans la BD possèdent.

La notion de structure d’une fiche est très proche de celle de « blanc de formulaire », où figurent certains intitulés (les noms de champ) suivis chacun d’une zone où peut être inscrite l’information relative à un objet spécifique. Ainsi, le début de la structure de fiche évoquée ci-dessus pour les spécimens de papillon pourrait être représenté comme suit :

Spécimen de papillon

Région où capturé :
Espèce :
Longueur :
Largeur :
Date de capture :
…

Cinq champs sont montrés dans l’exemple, appelés respectivement « Région où capturé », « Espèce », « Longueur », « Largeur » et « Date de capture ». Il pourrait évidemment y avoir beaucoup d’autres champs, par exemple un numéro d’identification unique du spécimen, le nom de la personne l’ayant recueilli, etc. Dans chaque fiche individuelle, chaque champ sera rempli (ou « renseigné ») avec l’information pertinente pour un spécimen spécifique.

Pour quelqu’un familier avec la notion de métadonnée dans le contexte de la recherche de fichiers, l’analogie entre champ dans une BD et métadonnée est directe : un champ de BD, tout comme une métadonnée, possède un nom, et correspond à un élément d’information à propos d’un objet ou d’une ressource. Une structure de fiche peut donc être vue comme un ensemble de « métadonnées » utilisées pour décrire un objet ou une ressource d’un certain type.

Les différentes responsabilités liées à une BD

En supposant qu’on ait une collection de spécimens de papillon et que l’on veuille gérer cette collection à l’aide d’une BD textuelle, les étapes à effectuer seraient :

1. déterminer une structure de BD (esquissée ci-dessus) adéquate pour les besoins à satisfaire, puis créer avec un SGBDT une nouvelle BD ayant cette structure ;
2. créer dans cette BD, avec le module ou l’interface de saisie du SGBDT, une nouvelle fiche pour chaque spécimen de la collection.

Une fois ces étapes franchies, il serait possible d’effectuer des recherches sur la BD et de produire des listes imprimées, par exemple, le « catalogue » complet de la collection (on dit listes « imprimées », mais elles ne sont pas nécessairement imprimées sur papier).

Ces différentes opérations ne reviennent pas nécessairement toutes à la même personne. Il s’avère utile de distinguer trois rôles, ou ensembles de responsabilités, liées à une BD :

1. La gestion ou administration de la BD.
2. La saisie d’information dans la BD, incluant ajouts, retraits et corrections.
3. La recherche d’information dans la BD, incluant la production de listes imprimées.

On qualifie ces trois rôles de rôles d’intervention. Selon la taille du projet, ils peuvent être tenus par une ou plusieurs personnes. Un bibliothécaire ou spécialiste de l’information documentaire peut être appelé à jouer chacun de ces rôles et possède les compétences nécessaires.

Déterminer la structure adéquate pour une BD en fonction des besoins à satisfaire relève (comme beaucoup d’autres responsabilités) du rôle de gestion de la BD. C’est donc une compétence que doit maîtriser le bibliothécaire ou spécialiste de l’information documentaire.

Les utilisateurs finaux de la BD, c’est-à-dire les membres de la collectivité pour laquelle la BD a été mise sur pied, n’assument en général pas de rôle d’intervention, sauf peut-être la recherche et la production de liste, lorsqu’ils ont la possibilité d’interroger directement la BD, sans passer par un intermédiaire (qui traduit leurs besoins d’information en requêtes de recherche). La saisie de certaines informations (en général, dans certains champs spécifiques seulement) peut aussi être du ressort des utilisateurs finaux, ce qui permet de donner à la BD un certain comportement « 2.0 », chaque utilisateur pouvant aussi agir comme « auteur ».

Fonctionnalités de base de DB/TextWorks

Le reste de ce texte est consacré à la présentation de deux caractéristiques des SGBDT qui se justifient par les possibilités additionnelles de recherche qu’elles amènent. Pour pouvoir expliquer ces possibilités additionnelles, nous devons avoir une référence. Cette référence sera un sous-ensemble de fonctionnalités d’un SGBDT spécifique : DB/TextWorks, produit par la société Inmagic Inc. (sous-ensemble qui correspond en fait à peu près aux capacités de recherche des FRF).

Nous commençons donc par un sous-ensemble des fonctionnalités de DB/TextWorks, que nous enrichirons graduellement. Nous illustrerons ainsi certaines caractéristiques essentielles de DB/TextWorks, mais aussi de tout SGBDT, puisque DB/TextWorks est représentatif de cette classe de logiciels. Notez que nous n’introduirons pas l’entièreté des possibilités de DB/TextWorks, mais seulement celles qui permettent de justifier les deux caractéristiques qui nous préoccupent : les champs à occurrences multiples et la recherche exacte d’occurrence. En particulier, nous ne parlerons pas du tout des capacités de validation de l’information à la saisie, pourtant fondamentales dans les SGBDT.

Structure d’une BD

Dans notre version « de base » de DB/TextWorks, la structure d’une BD se résume à la liste des noms de champs. Une BD peut comporter autant de champs que l’on veut. Il y a très peu de restrictions sur les noms de champ, mais nous n’utiliserons dans nos exemples que des noms d’un seul mot, comme « auteurs » et « numero ».

L’information que l’on inscrit dans un champ est une chaîne de caractères dont la longueur n’est pas limitée (mais qui peut être vide). Autrement dit, dans n’importe quel champ de n’importe quelle fiche, on peut inscrire une chaîne de caractères aussi longue que l’on veut.

Langage d’interrogation

Une fois la BD créée et un certain nombre de fiches enregistrées dans celle-ci, on peut formuler des requêtes de recherche, dont le résultat est toujours un certain sous-ensemble des fiches de la BD. Le langage d’interrogation de base avec lequel nous commençons est comme suit (il s’agit en fait d’un sous-ensemble du langage d’interrogation en mode commande de DB/TextWorks; il existe aussi un mode d’interrogation par bordereau).

Forme générale d’une requête

La forme générale d’une requête est :

<nom-de-champ> CT <mot-ou-expression>

La partie <nom-de-champ> doit être remplacée par le nom d’un des champs de la BD. On appelle ce champ le champ recherché. Le mot-clé CT est l’abréviation de « contains », soit « contient » en anglais. La partie <mot-ou-expression> doit être remplacée par une suite d’un mot ou plus.

Voici deux exemples de requêtes syntaxiquement valides :

titre CT hiver

auteurs CT pierre edouard lerouel

Commençons par le cas où un seul mot est inscrit après CT. Comme dans Windows Search, la recherche effectuée est une recherche de mot entier, et non de chaîne de caractères. La casse des lettres est ignorée, tout comme les signes diacritiques (comme dans Windows Search, ceci est paramétrable, mais le réglage par défaut est d’ignorer les diacritiques et tous nos exemples supposent le réglage par défaut).

La requête :

titre CT feta

repérera les fiches qui contiennent le mot « feta » (ou « Feta », ou « fêta », etc.) quelque part dans le champ appelé « titre ».

Troncature

Contrairement à Windows Search, il n’y a pas de troncature par défaut. Si désiré, on l’inscrit explicitement, à la fin du mot seulement, sous la forme d’un astérisque « * ». Ainsi :

titre CT cheva*

retrouvera « cheval », « chevaux », « chevalin », etc.

Recherche d’expression

Dans le cas ou plusieurs mots sont inscrits l’un à la suite de l’autre après le CT, une recherche d’expression (en anglais, phrase searching) est effectuée. La suite exacte de mots inscrits est recherchée, dans le même ordre. Ainsi :

auteurs CT pierre edouard lerouel

repérera les fiches contenant les mots « pierre », « edouard » et « lerouel » consécutifs, dans cet ordre, quelque part dans le champ « auteurs ».

N.B.: Quand nous définirons les champs à occurrences multiples tout à l’heure, nous verrons que la recherche d’expression a un comportement particulier dans ce type de champ.

Comme dans Windows Search, toute ponctuation est ignorée, tant dans les fiches que dans la requête. Ainsi :

resume CT Jean Bernard

repérerait une fiche où le passage :

Paul s’acheta un jean.  Bernard n’acheta rien.

se retrouverait dans le champ « resume ».

On peut utiliser la troncature à la fin de n’importe quel mot dans l’expression; elle ne s’applique qu’à ce mot spécifique (ceci est différent d’avec Windows Search). Ainsi :

titre CT cheva* de troie

retrouvera (au moins) « cheval de troie » et « chevaux de troie ».

Opérateurs booléens

Les trois opérateurs booléens sont disponibles. Comme dans Windows Search, ils sont représentés comme suit (rappelez-vous que le langage d’interrogation présenté ici est un sous-ensemble du langage d’interrogation en mode commande de DB/TextWorks; en mode bordereau, les opérateurs booléens sont représentés différemment) :

Les opérations sont exécutées de gauche à droite, sauf si des parenthèses sont utilisées pour forcer un ordre d’exécution différent. La requête suivante :

titre CT acces NOT (resume CT gestion AND resume CT bibliotheque)

repérera les fiches dont le titre contient acces, à l’exception de celles dont le resume contient à la fois les mots gestion et bibliotheque.

N.B.: Dans le langage d’interrogation complet de DB/TextWorks, les requêtes avec opérateurs booléens peuvent parfois être rédigées dans une forme compacte qui utilise d’autres symboles pour les opérateurs booléens (/ pour le OU, & pour le ET, et ! pour le SAUF). Nous ne présentons pas cette forme compacte ici.

Champs à occurrences multiples et recherche d’expression

Le problème

Supposons que l’on veuille créer une BD pour gérer des documents. On compte définir un champ « auteurs » pour y inscrire le nom des auteurs des documents. Comme chaque document peut avoir plusieurs auteurs, on décide dans un premier temps d’adopter la convention de séparer les auteurs successifs par un point-virgule. (Par ailleurs, on adopte aussi la forme « Nom, Prénom », qui est habituelle, mais cela ne change rien au problème que nous décrirons ci-dessous.) Supposons aussi que l’on soit susceptible de rencontrer les trois auteurs suivants dans nos documents :

• Jacques Bernard
• Isabelle Jacques
• Bernard Forget

Supposons encore que l’on ait dans notre base les trois fiches suivantes :

Nous avons attribué un numéro aux documents simplement pour référence.

Dans DB/TextWorks, notre BD aurait donc deux champs: numero et auteurs, et comporterait trois fiches.

Supposons que l’on désire trouver les documents dont « Jacques Bernard » est un auteur (soit, les documents 72 et 126, mais pas le document 39). Quelle requête (ou question) de recherche pouvons-nous formuler dans DB/TextWorks pour satisfaire ce besoin d’information?

La requête qui vient d’abord à l’esprit est celle-ci :

auteurs CT bernard jacques

Le problème, avec cette requête, c’est qu’elle repêchera non seulement les documents 72 et 126, mais également le document 39... Pourquoi? Simplement parce que, dans ce document, les mots « bernard » et « jacques » sont adjacents, tout comme dans les documents 72 et 126. En effet, pour DB/TextWorks, le point-virgule n’a aucune signification particulière. Il est traité exactement comme n’importe quel autre signe de ponctuation, c’est-à-dire simplement comme indiquant la fin d’un mot.

Y a-t-il moyen de modifier la requête pour éliminer le document qui ne nous intéresse pas? On pourrait être tenté d’éliminer, avec le SAUF booléen, un ou plusieurs des auteurs dont le nom cause une confusion avec celui de « Jacques Bernard », soit « Isabelle Jacques » et « Bernard Forget ». Ainsi, on pourrait penser formuler la requête:

auteurs CT bernard jacques NOT (auteurs CT forget bernard)

ou encore:

auteurs CT bernard jacques NOT (auteurs CT forget bernard OR auteurs CT jacques isabelle)

Ces nouvelles requêtes font bien une partie de ce qu’on veut, à savoir éliminer le document 39. Malheureusement, elles éliminent aussi un des documents que l’on veut avoir: le document 126... Pourquoi? Parce que, dans ce document, « Jacques Bernard », « Isabelle Jacques » et « Bernard Forget » sont coauteurs !

Avec ce que nous avons présenté de DB/TextWorks jusqu’ici, il n’y a donc aucun moyen de formuler une requête qui retourne toujours exactement et seulement les documents que l’on veut avoir ! Cette constatation peut être étonnante, mais elle n’en demeure pas moins la vérité !

Exercice: Trouvez un exemple de situation où le même genre de problème que celui que nous venons de décrire se pose, mais qui ne fait pas intervenir des noms de personne.

La réponse des SGBD textuels

Les SGBD textuels offrent une possibilité de structuration des données qui permet de régler notre problème. Il s’agit des champs à occurrences multiples. La forme exacte dans laquelle se manifestent les champs à occurrences multiples dans les SGBD textuels varie un peu d’un logiciel à l’autre, mais le principe est toujours le même. Comme prévu, nous utilisons la forme que l’on retrouve dans DB/TextWorks.

Qu’est-ce donc qu’un « champ à occurrences multiples »? Intuitivement, c’est un champ qui, au sein d’une même fiche, peut être divisé en un certain nombre de cases, indépendantes les unes des autres. Chacune des cases est appelée une occurrence du champ en question dans la fiche. Une même fiche peut donc avoir plusieurs occurrences du même champ.

C’est à la création de la BD que l’on indique quels champs sont à occurrences multiples. Lorsqu’un champ est défini à occurrences multiples, il n’y a pas de limite sur le nombre d’occurrences de ce champ qu’on peut mettre dans une même fiche.

Illustrons nos propos en montrant de quoi auraient l’air les trois fiches de tout à l’heure si on définissait le champ « auteurs » comme un champ à occurrences multiples :

Les noms des coauteurs ne sont plus simplement l’un à côté de l’autre séparés par un point-virgule, ils sont carrément dans des cases différentes. (Si vous vous demandez comment on peut saisir de la sorte des choses dans des « cases » différentes, la question est complètement légitime; pour le moment, disons simplement que la saisie, dans DB/TextWorks, s’effectue en mode graphique à l’aide d’un bordereau, et qu’il existe une fonction permettant d’ajouter autant de cases que l’on veut dans ce bordereau.)

Comme nous l’avons laissé entendre, l’intérêt des champs à occurrences multiples pour solutionner notre problème, c’est que les différentes occurrences d’un même champ dans une même fiche peuvent être considérées comme complètement indépendantes, ou cloisonnées, et non pas adjacentes l’une à l’autre. De fait, la recherche d’expression (déjà présentée ci-dessus) considère les différentes occurrences d’un même champ dans une même fiche comme complètement cloisonnées les unes des autres.

Rappelons que la recherche d’expression correspond au cas où le mot-clé CT est suivi de deux mots ou plus. Voici un exemple de requête de recherche d’expression:

auteurs CT bernard jacques

Incidemment, cette requête nous retournera exactement ce que l’on veut, à savoir, les fiches 72 et 126, sans la fiche 39. Afin de comprendre pourquoi, décortiquons-la et voyons comment le logiciel l’interprète.

Le mot auteurs identifie le champ dans lequel on veut que la recherche s’effectue. C’est la présence de l’opérateur CT suivi de deux mots ou plus consécutifs qui indique au logiciel qu’il s’agit d’une « recherche d’expression ». Comment le logiciel interprète-t-il une telle requête? Il retourne les fiches dont le champ recherché contient tous les mots de l’expression recherchée, adjacents l’un à l’autre, dans le même ordre que dans la requête, et dans la même occurrence !

C’est ce dernier détail, à savoir que les mots doivent se retrouver dans la même occurrence, qui fait que notre requête ci-dessus nous retourne ce qu’on veut. Sans cette dernière condition, nous aurions le même problème que sans champ à occurrences multiples, et la fiche 39 serait aussi repêchée. Une autre façon de formuler cette dernière condition est de dire que, lors d’une recherche d’expression, le dernier mot d’une occurrence du champ n’est pas considéré comme adjacent au premier mot de l’occurrence suivante.

Il est à noter que DB/TextWorks permet aussi des recherches qui ne sont pas des recherches d’expression, comme par exemple la recherche de mots adjacents ou séparés par au plus n mots. Ces recherches ne considèrent pas les différentes occurrences d’un champ comme indépendantes ou cloisonnées les unes des autres. Ainsi, la requête :

auteurs CT bernard P1 jacques

recherche simplement les mots « bernard » et « jacques » adjacents l’un à l’autre, dans cet ordre, n’importe où dans le champ auteurs, sans considérer les occurrences comme cloisonnées; elle retournerait donc la fiche 39, en plus des fiches 72 et 126. Ce n’est donc pas tous les types de recherche dans DB/TextWorks qui considèrent les différentes occurrences d’un champ comme cloisonnées les unes des autres. (Dans la dernière requête, la présence de l’opérateur P1 indique qu’il ne s’agit pas d’une recherche d’expression. Incidemment, P1 signifie « précède d’au plus une position » et exprime donc l’adjacence dans l’ordre.)

Il est important de réaliser que c’est la combinaison d’un champ à occurrences multiples et de la recherche d’expression qui nous permet de formuler une requête de recherche qui répond à notre besoin d’information. L’un sans l’autre ne nous permettrait pas de solutionner le problème précis que nous avons décrit.

La recherche exacte d’occurrence

Le problème

Corsons un peu l’exemple précédent. Supposons que nous avons maintenant un quatrième auteur possible, dont le nom est « Jacques-Yvan Bernard » et que nous ajoutons à notre base deux nouvelles fiches: une où « Jacques-Yvan Bernard » est l’unique auteur et une autre où « Jacques Bernard » et « Jacques-Yvan Bernard » sont coauteurs. Notez que nous ne voulons pas retomber dans le problème précédent et que nous conservons donc l’approche du champ « auteurs » à occurrences multiples. Notre base a donc maintenant l’allure suivante :

Supposons qu’encore une fois, notre besoin d’information est de retrouver toutes les fiches où « Jacques Bernard » est un auteur (soit, les fiches 72, 126 et 247, mais pas la fiche 39 ni la 208). Peut-on, avec ce que nous connaissons de DB/TextWorks, formuler une requête de recherche qui satisfasse ce besoin? Essayons!

Évidemment, on pourrait commencer avec la même recherche d’expression que tout à l’heure :

auteurs CT bernard jacques

Le problème avec cette requête, c’est qu’elle retournera, en plus des fiches voulues, la fiche 208. Pourquoi? Simplement parce que dans le champ « auteurs » de cette fiche, on retrouve les mots « bernard » et « jacques » adjacents, dans cet ordre et dans la même occurrence ! On pourrait alors être tenté d’essayer d’éliminer la fiche 208 en utilisant le SAUF booléen; par exemple, on pourrait essayer la requête suivante :

auteurs CT bernard jacques NOT auteurs CT yvan

Mais cette requête ne répond toujours pas à notre besoin, puisqu’elle élimine non seulement la fiche 208, mais aussi le 247, que l’on veut repêcher. En fait, on se rend vite compte que, peu importe comment on utilise le SAUF, on n’arrivera jamais à éliminer la fiche 208 sans éliminer aussi la 247.

Nous voici donc à nouveau devant un constat d’échec : avec ce que nous connaissons en ce moment de DB/TextWorks, il n’y a aucun moyen de formuler une requête (sur le champ « auteurs ») qui réponde toujours à notre besoin d’information, à savoir trouver exactement les fiches où « Jacques Bernard » est un auteur !

Exercice: Trouvez un exemple de situation où le même genre de problème que celui que nous venons de décrire se pose, mais qui ne fait pas intervenir des noms de personne.

La réponse des SGBD textuels

S’il y avait un moyen de formuler une requête qui dise « je cherche les fiches où une occurrence de « auteurs » contient les mots « bernard » et « jacques », dans cet ordre, et rien d’autre », notre problème serait réglé. Eh bien, c’est exactement ce que permet de faire la recherche exacte d’occurrence. Voici une requête de recherche exacte d’occurrence (en anglais, exact match) qui répond à notre besoin d’information :

auteurs = bernard jacques

Comme vous pouvez voir, par rapport à notre requête de recherche d’expression de tout à l’heure, nous avons simplement troqué le CT pour le symbole « = », qui indique au logiciel que l’on veut faire une recherche exacte d’occurrence. Voici comment cette requête est interprétée : le logiciel retourne les fiches où une des occurrences du champ recherché (auteurs) est constituée des mots « bernard » et « jacques », dans cet ordre, et rien d’autre (évidemment, comme d’habitude, la casse des lettres et la ponctuation sont ignorées). Ainsi donc, l’unique occurrence de « auteurs » de la fiche 208, étant constituée de trois mots (« bernard », « jacques » et « yvan »), ne satisfait pas au critère et la fiche 208 n’est donc pas repêchée. La seconde occurrence de la fiche 247 est dans le même cas, mais puisque la première occurrence satisfait au critère, alors la fiche 247 est repêchée. Il suffit qu’une des occurrences du champ recherché satisfasse au critère pour qu’une fiche soit repêchée.

Recherche d’expression versus recherche exacte d’occurrence

Clairement, dans le contexte hypothétique précis que nous avons décrit, la recherche exacte d’occurrence est supérieure à la recherche d’expression. En effet, non seulement permet-elle d’éliminer la confusion résultant de noms pouvant aussi servir de prénom (ce que permet aussi la recherche d’expression), mais elle permet également d’éliminer la confusion résultant d’un nom « inclus » dans un autre (comme « bernard jacques » et « bernard jacques yvan »).

Il ne faut cependant pas pour autant conclure que la recherche exacte d’occurrence peut toujours remplacer la recherche d’expression. Chaque type de recherche a son utilité. Certains besoins d’information sont très faciles à combler avec des recherches d’expression, mais très difficiles, voire même impossibles, à combler avec des recherches exactes d’occurrence. À l’inverse, comme nous venons de démontrer, certains besoins d’information sont impossibles à combler avec une recherche d’expression mais sont très faciles à combler avec une recherche exacte d’occurrence.

Il est aussi important de réaliser que la recherche exacte d’occurrence n’aurait réglé aucun des problèmes ci-dessus sans l’utilisation d’un champ à occurrences multiples. En effet, considérez la base utilisée plus haut comme exemple de base sans occurrences multiples :

Même avec la recherche exacte d’occurrence, il est toujours impossible de formuler une requête qui repêche toujours exactement les fiches où « Jacques Bernard » est un auteur.

Exercice: Essayez de formuler une requête qui repêche exactement les fiches où « Jacques Bernard » est auteur dans la BD ci-dessus (soit les fiches 72 et 126). Essayez tant des recherches d’expression que des recherches exactes d’occurrence.

Les trois caractéristiques que sont les champs à occurrences multiples, la recherche d’expression et la recherche exacte d’occurrence contribuent donc chacune à la grande capacité des SGBD textuels de répondre aux besoins d’information les plus divers et complexes.