Nous presentons deux types de SGBD accueillant des documents structures: la premiere structure d'accueil est etablie sur un SGBD relationnel [BCK+94] alors que la seconde est etablie sur un SGBD a objets [Chr96]. Nous distinguons donc les deux types traditionnels de SGBD, ceux bases sur le modele relationnel [Mac81, Cra81, SSL+83, Bla98, BCK+94] et ceux bases sur le modele a objets [YA94, CPC94, Zha95, VBA95, FFE96, VAB96, Chr96, ACC+97]. Accueil sur un SGBD relationnel
La principale lacune des SGBD relationnels pour la gestion et la recherche de documents structures reside dans leur manque de souplesse pour de nir des types abstraits. Il n'est pas facile de rendre delement la structure d'un document a travers des relations, et lorsque cela est rendu possible [BCK+94], les requ^etes SQL sont rendues complexes de m^eme que le schema de la base. En e et le passage d'une hierarchie decrivant la structure du document a un ensemble de relations la representant est un processus assez lourd dont le resultat d'une des implantations possibles est la suivante:
TEXT NODES(nodeid, genid, content): un triplet correspond a un noeud de l'ar-borescence structurelle et il est decrit par un identi ant unique (nodeid), un type de noeud (genid) et le contenu de ce noeud.
TEXT ATTRIBUTES(nodeid,attr,value): un triplet correspond a la valuation d'un attribut SGML d'un element de structure. Pour un noeud de l'arborescence struc-turelle (nodeid), l'attribut identi e parattrprend la valeurvalue.
TEXT STRUCTURE(a nodeid,d nodeid): un doublet correspond a la relation de composition. Le noeud identi e para nodeidde l'arborescence structurelle est le pere du noeud identi e pard nodeid.
Cette representation des documents structures, c'est-a-dire des elements structurels, de la relation de composition et des attributs des elements structurels, presente l'avantage d'au-toriser la consultation de tels documents avec le langage SQL associe a des operateurs de comparaison de cha^nes de caracteres. Toutefois la lourdeur de la modelisation ainsi que la complexite des relations qui en resultent degradent singulierement les performances des sys-temes.
D'autres exemples de systemes documentaires implantes sur des SGBD relationnels [Mac81, Cra81, SSL+83, Bla98] montrent la diculte de cette t^ache en raison de l'inadequation du modele relationnel pour representer des documents structures. La plupart de ces tra-vaux s'orientent donc vers les modeles objets [YA94, Zha95, VBA95, FFE96, VAB96, Chr96, ACC+97]. Ces modeles presentent l'avantage de s'apparenter fortement aux modeles de do-cuments structures par certaines de leurs caracteristiques:
{ les modeles objets fournissent des constructeurs de type que ne possedent pas les modeles relationnels.
{ les modeles objets integrent des proprietes telles que l'agregation qui existent aussi dans les documents structures.
{ les modeles objets proposent la de nition de types atomiques d'une plus grande diversite que les modeles relationnels.
Il est donc preferable d'accueillir des documents structures sur un systeme a objet [CPC94]. Si les avantages de ces systeme sont indeniables vis a vis des systemes relationnels, les fonction-nalites de recherche documentaire restent a de nir et a implanter. S'il reste encore beaucoup a faire pour accueillir de maniere generique des documents structures sur un SGBD, le cou-plage SGBD-SRI que nous presentions en introduction prend ici toute sa valeur quand nous evoquons les fonctionnalites de recherche.
En e et, actuellement ces fonctionnalites se limitent a des recherches de donnees qui proviennent des SGBD-OO traditionnels et donc des langages de requ^etes declaratifs qui leurs sont associes tels que OQL (Object Query Language) [ODM93]. Pour des systemes documentaires, il est par exemple necessaire de pouvoir \naviguer" dans les documents, de pouvoir consulter de maniere synthetique leur contenu de m^eme qu'il est souhaitable de fournir des acces directs aux documents repondant a un besoin particulier de l'utilisateur. La mise en place de ce dernier type d'acces necessite l'implantation de fonctionnalites de recherche que les SGBD-OO traditionnels ne possedent pas et qui relevent de la recherche d'informations. Nous tenons a preciser que nous ne tenons pas a opposer deux types de systemes, SGBD et SRI, ayant leurs proprietes propres mais nous voulons montrer leurs aspects complementaires dans le cadre de fonds documentaires constitues de documents structures.
Accueil sur un SGBD a objets
Le langage POQL [Chr96] propose en aval d'un protocole de chargement de documents SGML dans une base de donnees a objet, en l'occurrence le systeme O2, introduit quelques-unes de ces nouvelles fonctionnalites. Nous presentons cette approche et particulierement la traduction d'un document SGML vers la base d'objets. Dans cette application, les documents se conforment a une DTD et le protocole de traduction a necessite l'implantation de nouveaux
types permettant par exemple de representer les alternatives dans la structure (\une illustra-tion est composee d'une image ou d'un texte"). Pour representer des documents SGML sur le SGBD O2, il a fallu repondre a deux questions elementaires : \comment representer une de nition de type de document (DTD) sous la forme d'un schema O2?"et \comment traduire les balises SGML vers des objets et des valeurs dans une base du SGBD?".
La traduction d'une DTD vers un schema O2s'etablit a l'aide d'une grammaire non contex-tuelle annotee de programmes qui speci ent l'association entre les symboles de la grammaire et leur representation dans la base. D'autre part, la traduction des balises SGML vers des elements de la base peut se faire selon deux approches: une representation faiblement typee dans laquelle chaque noeud de l'arbre syntaxique SGML est un objet dont un attribut indique le type du noeud et une representation fortement typee dans laquelle une correspondance est etablie entre la DTD et un schema d'une base: a chaque type de noeud correspond une classe d'objets. Cette seconde approche, plus riche semantiquement, a ete adoptee par Christophides et elle necessite une extension des primitives de modelisation: ajout des unions de types pour representer l'alternative dans la structure et des n-uplets ordonnes pour representer la notion d'ordre sur les elements SGML.
En fournissant ces extensions sur les primitives de modelisation du SGBD O2, il devient possible d'avoir un passage automatique d'un document SGML conforme a une DTD vers un ensemble d'objets appartenant a un schema dele a la DTD. Chaque connecteur present dans une DTD pour de nir les types d'elements SGML correspond a un constructeur de type du SGBD O2 (voir gure 2.2). Par ailleurs, les attributs presents dans les documents SGML et attaches aux types d'elements dans la DTD sont representes par des attributs classiques dans les classes d'objets. En n, le contenu des elements SGML prend la forme d'un attribut dont le type depend du contenu SGML. La encore une table de correspondance est etablie.
Connecteur
SGML Sens du connecteur Constructeur detype O2
a , b a suivi de b tuple ordonne tuple(a: ClasseA, b: ClasseB)
constraint: a!= nil, b!=nil
ajb a ou b union marquee union(a: ClasseA, b: ClasseB)
constraint: a!= nilj b!=nil
a* occurrences de a liste tuple(a: list(ClasseA))
a+ occurrences de a,
au moins une liste tuple(a: list(ClasseA))constraint: a!= list()
Figure 2.2.
Correspondance entre les connecteurs SGML et les constructeurs de type O2 Nous avons dit que les systemes du monde objet semblent plus aptes a accueillir des documents structures que les systemes relationnels, toutefois nous constatons que ce travail de traduction de documents SGML vers un SGBD a objets n'est pas elementaire. Si les approches di erent pour de nir ce que doit ^etre la structure d'accueil d'un document SGML sur un SGBD a objets, l'objectif est toujours de faciliter a terme l'acces a ces documents et donc leur interrogation. Pour cela, l'approche adoptee par Christophides basee sur une representation fortement typee permet de conserver au niveau du schema de la base la semantique de la structure et facilite ainsi l'interrogation. De plus, il devient possible via cette approche deseparer totalement la structure du document du contenu de ce document puisque seule la structure peut ^etre chargee dans la base et le contenu peut ^etre conserve sous la forme de chiers.
Ce dernier point nous permet d'aborder le dicile probleme du mode de stockage du document dans la base: faut-il conserver une entite document indivisible ou l'eclater en autant de composants structurels? Une discussion sur ce probleme necessite la prise en compte de l'usage qui est fait des documents. Comparot-Poussier et Chrisment discutent de ce probleme dans [CPC94] en prenant en compte la reutilisation des parties des documents mais aussi de la gestion de ses versions. Dans un environnement complet de gestion de documents electroniques tout ses aspects doivent ^etre pris en compte pour etablir un choix. Dans notre cadre plus particulier, la recherche sur de tels documents, il s'agit surtout de savoir si nous autorisons ou non des vues multiples d'un m^eme document.
La de nition de vues multiples d'un m^eme document signi e qu'il devient possible de voir le document selon les di erentes sortes de structures qui peuvent lui ^etre attachees : structure logique, structure physique, structure de presentation, etc. Nous voyons un travail mene par Navarro sur le theme particulier de l'interrogation des documents structures textuels admettant di erentes structures.