Illustra en test

Table des matières

• Introduction
• Travailler sans base de données
• Les SGBD relationnels
• Les SGBD objets
• Les SGBD relationnels-objets
• Conclusion

---

Introduction

Le SGBD (Système de Gestion de Base de Données) relationnel-objet Illustra est depuis peu en test au laboratoire de bases de données (LBD) du DI et au SIC. En attendant de pouvoir tirer un premier bilan de cette expérience, cet article se propose de faire un rapide tour d'horizon de ce domaine, qui devrait permettre de situer Illustra dans un contexte global.

Travailler sans base de données

Dans bien des cas, les informations produites par une application sont peu nombreuses et/ou ne sont destinées qu'à un traitement simple.

Ainsi, l'édition de fichiers de texte avec un outil tel que Word ne requiert que deux actions majeures de la part du système: charger le fichier et sauver les modifications. Tous les autres traitements sont effectués par l'utilisateur lui-même. Il n'y a donc pas, en dehors d'une recherche de mots occasionnelle, de requête à proprement parler.

On ne parle pas ici d'outils sophistiqués qui permettraient le traitement de documents partagés par une équipe d'écrivains ou la gestion d'une bibliothèque, qui se chargent de conserver, retrouver, voire partager les documents selon un mode de fonctionnement qui leur est propre et qui n'est pas directement accessible à l'utilisateur.

Un autre exemple peut être le traitement des résultats d'une simulation numérique. La quantité de données produite est généralement importante, mais le but est souvent d'en tirer des valeurs macroscopiques pertinentes, ou d'observer un comportement global qui comprend chaque valeur ponctuelle comme faisant partie d'un tout.

Indépendamment de la complexité du modèle étudié, les types de données manipulées dans des applications scientifiques restent généralement simples, ce qui a permis de les manipuler avec des langages tels que le fortran dont les variables étaient (avant l'arrivée du fortran 90) confinées essentiellement aux types de bases, entiers, réels ou complexes.

L'avantage de ce mode de fonctionnement tient bien sûr dans ses performances d'accès qu'aucun système de gestion de base de données (SGBD) ne parviendra jamais à concurrencer.

Les SGBD relationnels

A partir du moment où la masse de données s'amplifie et que les recherches qu'on désire effectuer sur celles-ci se multiplient, il devient de plus en plus difficile de garder le contrôle de toutes les opérations tout en assurant l'intégrité des données. Le fait que plusieurs utilisateurs partagent depuis des sites distants les mêmes données complique encore le problème. L'émergence des réseaux va dans le sens d'une répartition des données sur des serveurs distincts, ce qui ne va évidemment pas simplifier l'affaire. Gérer ce genre de situations dépasse largement le cadre des applications qui manipulent les données et constitue un domaine en soi: les bases de données. Le monde des SGBD est actuellement complètement dominé par le modèle relationnel, dont l'apparition remonte au début des années 70.

D'un point de vue théorique, les SGBD relationnels offrent un coté très séduisant dans la mesure où l'on peut en faire une description mathématique cohérente et complète.

Dans la pratique, cela se traduit par une indépendance des données vis-à-vis de leur support physique qui permet à l'utilisateur de s'attacher à la question qu'est-ce que je cherche? plutôt que où se trouve ce que je cherche?. Cette logique mathématique a permis de développer un langage de requête simple et puissant (SQL) et de faciliter la sécurité des informations notamment quant à leur confidentialité et à leur récupération en cas de panne du système.

A l'opposé des simulations numériques qui exigent des opérations complexes sur des type de données simples, les applications de gestion n'exigent la plupart du temps pas de calculs compliqués, mais agissent sur des données complexes. Les informations concernant des employés, par exemple, portent sur leur nom, éventuellement nom de jeune fille, prénom, sexe, date de naissance, salaire, etc. On voit là que chacun des attributs d'un employé est de type élémentaire. Quand on parle de données complexes, c'est donc de l'assemblage de ces attributs en un type Employé qu'il s'agit.

Toutes ces informations ne sont pas ou peu destinées à une utilisation globale (on n'imagine pas le service du personnel demander l'impression de toutes les informations connues sur chaque employé), mais on peut avoir besoin de les consulter fréquemment de manière individuelle (augmenter le montant de votre salaire), ce qui nécessite un mode de recherche efficace qui permette de localiser facilement la donnée qui nous intéresse.

Les bases de données relationnelles conviennent parfaitement à une large palette d'applications dites classiques, qui couvrent notamment le domaine de l'administration au sens large d'une entreprise (gestion du personnel, des commandes, des stocks, etc).

Par contre, assez rapidement, il est devenu clair qu'en n'offrant que la palette des types élémentaires pour chaque attribut, les SGBD relationnels n'étaient pas du tout adaptés à des types d'applications plus pointues comme la CAO, par exemple, dont les éléments de base eux-même sont des structures complexes. Plusieurs axes de recherche se sont dessinés pour palier à cette faiblesse: l'utilisation de langages de programmation persistants, la mise en place de nouveaux modèles de bases de données ou l'extension du modèle relationnel.

Nous ne nous étendrons pas sur les premiers, qui n'apportent pas de solution au problème de la gestion des données (sécurité, intégrité, partage, etc.) telle que décrite au début de cette section. L'exemple du fortran 90, qui inclut la possibilité d'étendre les structures de données au-delà des types élémentaires, montre cependant que les difficultés qu'engendrent cette restriction ne sont pas l'apanage des bases de données.

Les SGBD objets

Les SGBD objets sont une des réponses possibles au problème de l'attribution du type des données. Sans entrer dans les détails de la technologie objet, il est peut-être bon d'en rappeler ses piliers: une classe est une structure de données, qui inclut les différents éléments dont elle est constituée ET les fonctions (appelées méthodes) qui permettent de manipuler ces éléments à l'exclusion de toute autre. Un objet est une réalisation d'une telle classe.

Ainsi, une fonction extérieure ne peut pas, sauf transgression autorisée par le système, modifier le contenu d'un objet sans passer par une des méthodes définies par la classe. Cette technique, appelée encapsulation, a le grand avantage de faire des objets des entités autonomes qu'on peut utiliser comme des boîtes noires. D'une certaine manière, la technologie objet a rendu la manipulation des données indépendante des détails d'implémentation comme l'arrivée des SGBD relationnels avait dissocié la recherche d'une information de sa localisation physique.
Outre les notions de classe et d'encapsulation, la technologie objet comprend quelques concepts-clés dont nous ne parlerons pas ici, tels que l'héritage et le polymorphisme.

Dans les SGBD objets, chaque objet se voit doté d'un attribut supplémentaire, l'OID (Object IDentificator) qui assure son unicité.

La technologie objet détient ainsi un pouvoir d'expression beaucoup plus élevé que le modèle relationnel, qui peut être vu comme un sous-ensemble du modèle objet. De plus elle permet un rapprochement du monde des bases de données et de celui des langages de programmations orientés objet. Mais on est en droit d'attendre plus d'un SGBD que de faire office de gestionnaire d'objets persistants où viendraient puiser les applications écrites en Smalltalk ou C++. Une des motivations pour l'utilisation des bases de données reste tout de même la possibilité de manipuler, via un langage de requête performant, des grandes quantités de données.

Et de fait, la diversité offerte par l'approche objet est aussi son talon d'Achille dans la mesure où elle pose de nombreux problèmes qui sont autant de sujets de recherche actuels. Ainsi, justement, les langages de requêtes et le contrôle des accès sont des sujets délicats qui ne trouvent pas de réponse aussi simple que pour des SGBD relationnels. Du côté de son utilisation, on peut s'attendre à ce que la maîtrise de tels outils exige, au moins au début, des compétences d'autant plus élevées que le modèle est devenu complexe. Les premières difficultés intervenant au moment du choix du SGBD!

Une autre difficulté que rencontrent les SGBD objets tient au fait que le marché est essentiellement dominé par le relationnel ($8Mia/an contre $80Mio/an). Il est rare qu'on parte aujourd'hui d'un terrain vierge. Des structures ont déjà été mises en place qui reflètent celles de l'entreprise elle-même. Passer du relationnel à l'objet, si tant est que ce soit nécessaire, n'est pas un petit investissement. Il s'agit d'une approche fondamentalement nouvelle dont l'impact dépasse le seul domaine des bases de données. Toutefois, on peut imaginer, à des fins de prospection ou de migration, la création d'une classe table-relationnelle, munie de méthodes adéquates, qui ferait l'interface entre les SGBD relationnels et objets et permettrait de travailler de front avec les deux systèmes.

Les SGBD relationnels-objets

Une autre manière de palier à la faiblesse d'expression du modèle relationnel consiste à l'étendre. Et là encore, une réponse possible vient du monde objet. Pourquoi, en effet, ne pas garder le concept de tables et étendre celui d'attribut à des types de données complexes? Une des forces d'un tel point de vue, que les responsables marketing s'empressent de reprendre, veut qu'on tire ainsi le meilleur des deux mondes: la puissance de son langage de requête pour le relationnel, et, pour l'objet, la possibilité de dépasser les restrictions de l'attribution de types et de définir par des méthodes une interface qui en protège l'accès.
On pourrait envisager d'utiliser des SGBD relationnels-objets pour un traitement purement relationnel, mais des questions de performance font que ce choix n'est actuellement pas approprié. Néanmoins, SQL3, le prochain standard, inclut des éléments qui tiennent compte de l'évolution des SGBD relationnels traditionnels vers des systèmes qui incluent des types de données complexes. On peut donc s'attendre à ce que tous les fournisseurs de bases de données relationnelles proposent à relativement court terme des extensions plus ou moins réussies en direction du monde objet.

Les SGBD relationnels-objets ne sont cependant pas la panacée à tous les problèmes de systèmes d'information. Leur créneau se situe pour le moment au niveau des applications, probablement de plus en plus nombreuses, qui nécessitent à la fois des types de données complexes et de nombreuses requêtes. On pense par exemple à des bases de données multimédia où le son, l'image ou la vidéo ne seraient plus considérés comme des 'BLOBs' (Binary Large OBjects), mais comme des données sur lesquelles on peut effectuer des transactions.

Prenons par exemple une requête du type retrouver les images qui contiennent une voiture rouge, en imaginant qu'étant donné une image, on sache dire si oui ou non elle répond à notre critère de sélection (NB: il s'agit là d'un problème de traitement d'images et non plus de bases de données). Alors que retrouver les bons objets risque de mettre un SGBD objet en difficulté, c'est sur l'application de la méthode de recherche que butera le SGBD relationnel. Les SGBD relationnel-objets, eux, devraient être en mesure de répondre de manière satisfaisante à une telle demande.

L'explosion des informations disponibles via le Web apporte elle aussi de l'eau au moulin des bases de données relationnels-objets. En effet, la plupart des pages actuellement disponibles sur le réseau sont statiques, suivent une structure hiérarchisée et correspondent à l'approche sans base de données. Produire des pages de cette manière ne pose pas de problème (remplir des disques ne pose jamais de problème!). Mais on voit bien à quelles difficultés sont confrontés les auteurs lorsqu'il s'agit pour eux non seulement de maintenir les textes à jour, mais aussi les liens vers d'autres pages, sachant que les URL sont passablement volatiles. Qui ne connaît pas, en effet, la fameuse phrase: The requested URL could not be retrieved?

En ce sens, l'histoire des bases de données est probablement annonciatrice de celle du Web. Nous l'avons dit, les premières se sont affranchies de la dépendance entre l'information -qui nous intéresse- et sa localisation physique, qu'on se serait bien passé d'avoir à connaître. On voit bien l'intérêt qu'auraient les sites Web à suivre une évolution semblable.

Moyennant une batterie de scripts qui s'occupent de la formulation des requêtes, on peut envisager l'utilisation d'un SGBD relationnel pour des textes. Et encore ne faut-il pas vouloir faire une recherche sur le contenu dudit texte, mais s'en tenir aux attributs qui le caractérisent (titre, auteur, mots-clé, etc). Comme, par ailleurs, on s'attend à devoir manipuler des données de type complexe (des liens vers d'autres sources, mais aussi des éléments multimédias), on voit rapidement qu'un SGBD relationnel ne pourra pas faire l'affaire.

Enfin, le fait que les pages soient statiques n'est pas une fatalité. Imaginons qu'on veuille produire un catalogue. Jusqu'à présent, on avait le choix entre la création d'une page par objet à montrer (une sorte de catalogue papier dont le support aurait changé), ou l'écriture d'un script qui produise la page désirée en y insérant les données prises dans une base de données quelconque. On se prend à rêver d'une base où il suffira d'inclure dans une page-type des tags qui contiennent la requête SQL appropriée. Vous allez rire, c'est exactement le genre de possibilités qu'offre le module Web d'Illustra!

L'exemple illustré dans l'encadré ci-après montre l'insertion d'une telle requête dans une page HTML.

ID      Nom de la page    Contenu de la page 

FI0001  Index_FI          <HTML>
                          <HEAD>
                          <TITLE>Test Illustra</TITLE> 
                          <HEAD> 
                          <BODY> 
                          <H1>Index des Flash Informatique</H1>
                          <TABLE BORDER> 
                          <TR><TH>No<TH>Auteur<TH>Titre
                 <?MISQL SQL=² 
                 select ID,Titre,NomMail(Auteur),Ref from FI
                 order by Ref asc;²>
                 <TR><TH>$1<TH>$(REPLACE,$3,NULL,)<TH>
                 <A HREF=²Webdriver?MItab=FI&MIval=$4²>$2</A> 
                 <?/MISQL>
                          </TABLE><P>
                          </BODY></HTML>

Même si cet exemple n'est pas d'un intérêt fou, il est tout de même suffisant pour illustrer la souplesse d'utilisation d'une telle approche: un tag <?MISQL> dans lequel on insère une requête conventionnelle, dont le résultat s'exprime sous la forme de variables $1, $2,... Le module Web contient en outre de quoi traiter des variables, des conditions, des boutons, des listes, etc.

On remarquera d'autre part, l'utilisation d'une fonction NomMail, qui, recevant la référence de l'auteur en paramètre, va retourner le texte <A HREF="mailto:e-mail">nom</A> où e-mail et nom sont issus d'une requête SQL sur la table des auteurs:

Le fait que le traitement des pages HTML (et leurs requêtes) fasse partie intégrante du SGBD permet d'envisager une optimisation plus poussée de la part de ce dernier. On évite ainsi le passage coûteux par les jusque-là inévitables cgi-bin. Actuellement, Francis Lapique est en train de faire migrer la présentation de la fondation Berger du SGBD Oracle à Illustra, tandis que le soussigné est en charge de mettre en place un petit serveur audio. Du côté du LBD, Martin Huber se concentre sur l'utilisation d'Illustra dans le cadre des Systèmes d'Informations Géographiques (SIG).
Mais outre le fait d'améliorer ce qui peut être laborieusement obtenu par des méthodes conventionnelles, on peut pousser le raisonnement plus loin. Certains fournisseurs de meubles, par exemple, nous envoient régulièrement leur catalogue avec des images et des listes d'éléments séparés. Rien n'empêche d'imaginer une méthode de montage, elle-même, intégrée à la base de données, qui permette au client de construire en ligne sa propre configuration. Et avec un coup de baguette Java (tirée du chapeau Illustra, par exemple), la construction se fera directement chez le client.

Conclusion

Comme on pouvait s'y attendre, les bases de données, pas plus que les autres domaines (informatiques), n'offrent de solution universelle. A la question comment puis-je résoudre mon problème? fait toujours écho la même réponse ça dépend de vos besoins. Pour résumer ce qui a été dit plus haut, on peut dégager quatre tendances:

Ce découpage est certes grossier, mais permet de se faire une première idée du genre de domaine couvert par chaque type de SGBD. Il est certain que l'arrivée d'un gestionnaire de bases de données comme Illustra qui s'affiche comme étant la synthèse des forces des concepts relationnels et objets, sans en avoir les défauts, est prometteur à plus d'un titre. D'une part, il se pose comme une alternative aux restrictions des SGBD traditionnels et oblige, si besoin était, leurs concepteurs à remettre en question la suprématie dont ils jouissaient jusque là. D'autre part, il ouvre aux utilisateurs la porte vers nombre d'applications dont la mise en oeuvre se révélait laborieuse, voire simplement impossible. Reste à savoir si Illustra sera à la hauteur des espoirs qu'il fait naître. Réponse dans quelques mois.