Náttúrufræðistofnun Íslands
(Institut d'Histoire Naturelle d'Islande)

LE PROJET LAUPUR
TRAVAIL DU 7 AVRIL 1999 AU 29 JUILLET 2000

Base de Données
Et
Interface Homme-Machine

Sommaire

I. Présentation

II. L'Institut d'Histoire Naturelle d'Islande

A. L'Islande...

B. Présentation de l'Institut

C. Mon statut au sein de l'entreprise

III. Le projet Laupur

A. Présentation

B. Les outils utilisés
    1. Computer Associates Ingres
    2. Microsoft Visual Basic
    3. Microsoft Data Access Components

C. Les composantes du projet
    1. La base de données
    2. L'interface

D. Bilan

IV. Autres travaux

A. Insect Statistic

B. Tímmaskráning

C. Divers

V. Conclusion

VI. Netographie
    1. Internet
    2. Groupes de discussions

VII. Glossaire

I. Présentation

    Ce travail a été effectué d'avril 1999 à juillet 2000. Il s'est déroulé à l'Institut d'Histoire Naturelle à Reykjavik en Islande. Cet institut dépend de l'Etat islandais, il a pour vocation la recherche sur la faune, la flore, la géologie de l'Islande (constitution de banques de données, de cartes...) et a aussi un rôle consultatif pour ce qui est des décisions pouvant toucher à l'environnement (nouvelles constructions, sites touristiques...)
    L'utilisation de l'outil informatique a permis de grandes avancées dans le domaine du stockage d'informations, de la création de cartes... L'Institut a commencé son informatisation bien avant mon arrivée. Ainsi il existait plusieurs bases de données regroupant des informations diverses sur les insectes, les oiseaux bagués, les lieux de nidification, la répartition des plantes... L'intérêt est maintenant de pouvoir recouper toutes ces informations pour pouvoir mettre en évidence par exemple certains phénomènes recherchés d'un écosystème comme les liaisons qu'une abeille peut avoir avec certaines fleurs... Cependant du fait de la nature différente des bases de données utilisées ainsi que de la vétusté de certaines, il fut décidé de regrouper toutes ces informations en une base de données, c'est le projet Laupur. Tel fut mon travail. Celui-ci n'est d'ailleurs pas encore terminé et évoluera encore. L'Etat islandais désire établir une base de données au niveau national réunissant les informations d'instituts comme celui d'Histoire Naturelle, Maritime, Météorologique... Ceci sera la prochaine étape.
    Ce projet, Laupur, ne fut pas mon unique travail dans l'Institut. Etant le seul informaticien "de métier", je me suis attelé à bien d'autres tâches. J'ai secondé l'administrateur système, Arnór Þórir Sigfusson ornithologue de formation, et Haukur Jóhanesson qui s'occupe également du parc informatique et qui est quant à lui géologue. Ce fut le cas lors de l'attaque très médiatisée du virus ILOVEYOU.
    De plus, d'autres petits projets me furent assignés, comme la gestion des heures de travail et des petits programmes répondant à certains besoins de chercheurs. Mais commençons tout d'abord par une rapide présentation des lieux.

II. L'Institut d'Histoire Naturelle d'Islande

A. L'Islande…

    L'Islande est un pays de l'hémisphère nord à cheval sur les plaques eurasiatiques et américaines. Cette île, aux abords du soixante-sixième parallèle (le cercle polaire), fut peuplée par des vikings venus de Norvège par drakkar vers 870. L'un d'eux est le célèbre Eric le Rouge dont le fils, Leifur Eriksson, découvrit probablement l'Amérique. Leur langue, l'islandais, appartient à la famille scandinave (danois, suédois et norvégiens) et a peu évolué dans le temps.
    L'Islande vit toujours principalement de la pêche même si sa part dans l'économie nationale a fortement diminué. Cette nation a voulu se diversifier et s'est orientée vers les nouvelles technologies. Aujourd'hui la plupart des Islandais sont connectés sur la Toile (le plus fort taux de concentration au monde).

B. Présentation de l'Institut

    L'Institut d'Histoire Naturelle, de son vrai nom Náttúrufræðistofnun Íslands est divisé en deux bâtiments. L'un est à Reykjavik, capitale de l'Islande, située dans le Sud-Est du pays où la plupart du personnel est regroupé (voir figure 1). L'autre est situé dans le Nord à Akureyri. Le Directeur de l'Institut à Reykjavik est Ævar Petersen, le Directeur d'Akureyri est Kristinn J. Albertsson, le Directeur Général du Náttúrufræðistofnun Íslands est Jón Gunnar Ottósson.

Figure 1 : Emplacement des Instituts

    L'Institut a été fondé en 1889 par Hið Íslenzka Náttúrufræðifélag (La Société Islandaise d'Histoire Naturelle) et dirigé par cette dernière jusqu'en 1947, date à laquelle il fut acheté par l'Etat. Ceci explique son statut d'Institut public.
    Le but de cet Institut est de conduire des recherches sur la nature islandaise pour ce qui concerne la botanique, la géologie et la zoologie, de conserver une collection de spécimens scientifiques, maintenir des banques de données, rassembler des ouvrages d'histoire naturelle sur l'Islande, s'occuper des baguages des oiseaux, créer des cartes sur la répartition des espèces, sur la géologie, évaluer les impacts sur l'environnement de l'utilisation des ressources naturelles et des terres ainsi que sur la conservation des espèces, des habitats (aussi d'actualité en France avec les mesures européennes "Natura 2000") et des écosystèmes.
    Il y a en tout 50 personnes travaillant en permanence dans l'Institut. Ils sont 30 chercheurs plus les assistants, informaticiens, spécialistes GIS (Geographical Information System), taxidermistes, employés de bureau, financiers…

C. Mon statut au sein de l'entreprise

    Dans cet institut, ma mission consistait en la prise en charge de l'administration et de la maintenance des bases de données. J'ai été d'ailleurs la seule personne qualifiée dans ce domaine ce qui m'obligea à ne me tourner que vers mes propres ressources lorsqu'un problème survenait. J'ai aussi conduit le projet Laupur à tous les niveaux : analyse, management, programmation, testeur... Mais comme je l'ai souligné précédemment, cela n'a pas été ma seule tâche et j'ai donc rempli occasionnellement différentes opérations relevant du programmeur, de l'administrateur système ou du simple technicien.

III. Le projet Laupur

A. Présentation

    Laupur est un projet de grande ampleur, son but est le rassemblement de toutes les données de l'Institut d'Histoire Naturelle en une seule base de données commune. Laupur signifie en islandais "le nid du Grand Corbeau". Le Grand Corbeau collecte en effet dans la nature différents éléments pour ses petits et les place dans son nid. Le travail des chercheurs constitue un acte similaire : la collecte d'échantillons et l'enregistrement dans un "nid" - base de données. Cette dernière s'appelle donc Laupur.
    Ce projet avait déjà été initié par Julia Dubois mon prédécesseur à l'Institut. Elle avait créé une base de données, appelée Sarpur, pour les chercheurs travaillant sur les insectes. Celle-ci avait été conçue de façon générique, c'est-à-dire réutilisable par d'autres chercheurs dans d'autres domaines. Laupur devait se baser sur la structure de cette base tout en améliorant certains points et en exportant les informations d'Access vers Ingres.
    Le projet consistait également à faire une interface pour les gens de l'Institut avec Ingres, la base de données. Cette dernière est dépourvue d'interface du style Access. Elle dispose de form en mode texte et n'est pas très aisée à manipuler. Il a donc été décidé de construire un logiciel permettant de faire tout ce que l'utilisateur souhaite et ce le plus simplement du monde.
    Vous pouvez consulter ici un article de journal sur ce projet :

Extrait tiré de Daily news from Iceland, un site internet traduisant en anglais les principaux événements survenus en Islande. Vous pouvez consulter le site à l'adresse suivante : http://www.icenews.is/daily1.html
Dayly news from Iceland 3rd of may 2000
(http://www.icenews.is/03may00.html)

“Database on Icelandic nature
The Icelandic Museum of Natural History has taken a new 550 square metre
premises into use in Akureyri. The premises will be used to house samples
for scientific research. The information gathered will be transferred into a
database, accessible to the public via the Internet.
Kristinn J. Albertsson, director of the Akureyri Institute, says this is the
most ambitious project the Icelandic Museum of Natural History has ever
undertaken. He predicts that the creation of such a database will take from
two to five years, with two to four people working on it.
The Akureyri Institute specialises in research into grasses, plants and
fungi. It also monitors micro-organisms found in hot springs. The institute
has recently employed a specialist conducting research into birch plants, to
see how much grazing they can withstand, a project funded by the European
Economic Area.”

“Base de données sur la nature islandaise
Le Musée d'Histoire Naturelle d'Islande a obtenu un nouveau local de 550 mètres carrés à Akureyri. Ce nouveau local sera utilisé pour héberger des échantillons à des fins de recherche scientifique. Les informations rassemblées seront transférées dans une base de données accessible par l'internet au public.
Kristinn J. Albertsson, le directeur de l'Institut d'Akureyri, déclare que c'est le projet le plus ambitieux que le Musée d'Histoire Naturelle d'Islande ait jamais entreprit. Il prévoit que la création d'une telle base de données prendra de deux à cinq ans avec deux à quatre personnes travaillant dessus.
L'Institut d'Akureyri est spécialisé dans la recherche des herbes, plantes et champignons. Il surveille également les micro-organismes trouvés dans les sources d'eau chaude. L'institut a récemment employé un spécialiste conduisant ses recherches sur les boulots pour tester la résistance de ceux-ci aux écorchures, un projet financé par l'A.E.E. (Aire Economique Européenne).”

Ci-après suit le texte complet, en islandais, tiré du quotidien national islandais Morgunblaðið :

“Stefnt að samhæfðum gagnagrunni um íslenska náttúru
Akureyrarsetur Náttúrufræðistofnunar Íslands og Orkustofnun hafa tekið á leigu 650 fermetra geymsluhúsnæði á Akureyri undir borkjarna víðsvegar að af landinu. Þessar stofnanir hafa það hlutverk samkvæmt lögum að varðveita sýni sem aflað er í vísindalegu skyni eftir að rannsókn þeirra er lokið.
Kristinn J. Albertsson, forstöðumaður Akureyrarseturs Náttúrufræðistofnunar, sagði að í geymsluhúsnæðinu yrðu geymdir borkjarnar sem fluttir verða til Akureyrar víða af landinu. Nú þegar eru fimm stórir flutningabílsfarmar komnir í hús á Akureyri og eru þeir ættaðir úr geymslum Orkustofnunar og koma m.a. frá Gelgjutanga í Reykjavík og frá Laugum í Súgandafirði. Kristinn sagði að það væri því þegar orðið þröngt í húsnæðinu, þótt aðeins væri um þriðjungur af kjörnum kominn norður.
"Við erum að vona að þetta verði ekki bara geymsla þar sem kjarnarnir munu rykfalla í sínum kössum og það er ráðgert að upplýsingum um þessa kjarna verði safnað saman, þeir skráðir upp á nýtt og grisjaðir. Upplýsingunum verði komið fyrir á tölvutæku formi og settur upp gagnagrunnur, sem áform eru um að verði aðgengilegur hverjum þeim sem vill hafa úr honum upplýsingar í gegnum Netið."
Umsvif Akureyrarseturs Náttúrufræðistofnunar Íslands hafa aukist jafnt og þétt á undanförnum árum, eða frá því að umhverfisráðuneytið, fyrir hönd ríkisins, yfirtók rekstur Náttúrufræðistofnunar Norðurlands í byrjun tíunda áratugarins og sameinaði Náttúrufræðistofnun Íslands. Þá voru starfsmenn fjórir en þeir verða orðnir tíu í ár. Að auki hefur stofnunin beðið um stöðugildi dýrafræðings í nokkuð mörg ár. Sá dýrafræðingur gæti einnig nýst bæði Náttúrufræðistofnun og Veiðistjóraembættinu, sem einnig er staðsett á Akureyri.
Kristinn sagði að eitt metnaðarfyllsta verkefni Náttúrufræðistofnunar Íslands væri að byggja altækan gagnagrunn um náttúru Íslands og hafa hann opinn almenningi á Netinu. Til að sá grunnur geti orðið til þarf að koma miklu af upplýsingum og gögnum sem eru í fórum stofnunarinnar bæði á Akureyri og Reykjavík á tölvutækt form. Kristinn sagði að áhugi væri á því innan stofnunarinnar að koma vinnu við þá skráningu fyrir á Akureyri en að hún gæti tekið 2-5 ár fyrir 2-4 manneskjur. Þessi hugmynd hefur verið kynnt bæjaryfirvöldum á Akureyri, þar sem henni var vel tekið, að sögn Kristins.

Eftirlit með hveraörverum

Akureyrarsetrið heldur úti rannsóknum í grasafræði háplantna og heldur utan um útbreiðslukort þeirra og er með sérhæfðan gagnagrunn, sem almenningi gefst kostur á að kynna sér í dag. Einnig er hefð fyrir því að rannsóknir séu stundaðar í grasafærði á Akureyri, þar með talið á fléttuflóru sem og á sveppaflóru landsins.
Þá var stofnuninni falið, með lögum frá 1998, að hafa eftirlit með hveraörverum, þ.e. sýnatöku og skráningu allra örvera í samstarfi við líftæknifyrirtæki sem starfa á því sviði hérlendis. Kristinn sagði þó nokkrar líkur á að þetta hlutverk yrði fært yfir á Akureyrarsetur stofnunarinnar.
Stofnunin hefur bætt við sig starfsmanni sem sinna mun rannsóknum á beitarþoli birkis, hvort heldur er af völdum grasbíta eða skordýra. Kristinn sagði að hér væri um að ræða fjölþjóðlegt rannsóknarverkefni, sem tugur rannsóknastofnana frá 7-8 þjóðlöndum tekur þátt í. "Verkefnið, sem mun stunda yfir í að minnsta kosti þrjú ár, er styrkt af Evrópusambandinu. Okkur þykir ekki ónýtt að vera komin með litla fingurinn inn í salarkynni evrópska styrkjasamfélagsins og vonum að þessi mjói vísir verði til mikils síðar."”

B. Les outils utilisés

1. Computer Associates Ingres

    Ingres est un SGBD/R ce qui signifie Système de Gestion de Base de Données Relationnelles. Ingres, dans sa version II actuelle, est une base de données assez proche de Oracle. Elle permet le stockage d'information digitalisée de manière logique. Ingres est un produit de Computer Associates, une industrie leader mondiale dans le domaine des logiciels d'entreprise.
    Le serveur Ingres, hébergeant la base de données, est sur une machine SUN Solaris. Le parc des clients est constitué de PC sous Windows 9x et Windows NT 4/2000.
    Si vous désirez plus d'information concernant le produit CA IngresII, vous pouvez vous rendre sur leur site web (http://www.cai.com/products/ingres.htm). Pour toute information concernant Computer Associates, leur site web se trouve à l'adresse suivante : www.cai.com.

2. Microsoft Visual Basic

    Visual Basic est un outil RAD, Rapid Application Development. Il permet de créer des applications fonctionnant sous Microsoft Windows et ce rapidement. Il a été choisi pour sa rapidité et sa simplicité, et également parce qu'il est le seul logiciel de développement disponible à l'Institut. Visual Basic est un langage assez évolué qui permet la création de fenêtres Windows, de composants réutilisables, de bibliothèques de fonctions, de classes… Nous avons donc développé l'interface de notre projet avec cet outil dans sa dernière version, Visual Basic 6 Professionnal.

Note : Visual Basic est livré avec le Package & Deployment Wizard qui permet de créer un programme d'installation du logiciel et de ses composants. Après différents tests, il s'est avéré être peu fiable. Nous avons donc préféré le tout nouveau Windows Installer (utilisé avec Office 2000 et Windows 2000, adresse : http://msdn.microsoft.com/vstudio/downloads/vsi/).

3. Microsoft Data Access Component

    Pour faire communiquer l'interface avec la base de données Ingres, il a fallu trouver une solution. Deux s'imposaient, la première aurait été d'utiliser la bibliothèque de fonctions (API) de Computer Associates pour accéder à la base de données. La deuxième était de tirer parti d'ODBC (Open DataBase Connectivity) pour communiquer avec le serveur. ODBC est un standard permettant l'accès à différents SGBD. CA offre un driver ODBC qui utilise en sur-couche leur API. Nous avons opté pour la deuxième solution, plus simple à mettre en place, d'autant que le driver ODBC offre des performances satisfaisantes.
    ODBC dispose d'une bibliothèque de fonctions (API) de Microsoft. Visual Basic ne se prête pas aisément à leur manipulation, de plus il dispose d'une classe nommée DAO (Data Access Object) qui permet l'accès à une base de données via ODBC entre autre. Cependant après plusieurs tests, il s'est avéré que ces composants, en plus d'être bogués, n'offrent que peu de possibilités.
    C'est pour cela que nous avons choisi MDAC (Microsoft Data Access Component). MDAC est la nouvelle technologie de Microsoft pour l'accès aux bases de données et à l'information. MDAC contient la bibliothèque ActiveX Data Object (ADO) qui permet d'utiliser ODBC via leur jeu de composants. ADO est amené à remplacer DAO (livré avec Visual Basic), il est d'ailleurs en standard dans la dernière version de VB. Pour plus d'information concernant MDAC, veuillez vous référer au site officiel (http://www.microsoft.com/data/).

C. Les composantes du projet

1. La base de données

                        a. Structure fondamentale
    Mon prédécesseur avait, en son temps, créé une base de données, Sarpur, pour les chercheurs en entomologie. Cette base fut conçue de façon à pouvoir intégrer dans le futur les recherches de chercheurs en d'autres domaines. Il s'est avéré qu'à l'utilisation, cette banque d'informations contenait quelques erreurs et aussi montrait ses limites et lacunes. Laupur a donc été créé en réutilisant l'expérience acquise sur Sarpur. La structure principale de la base change peu. Nous y avons gardé les trois tables principales que sont Sýni, Tegundir Sýni et Tegunda Nafn. Ceci donne réciproquement Echantillons, Données de l'échantillon et Espèces. Ces tables ont été conçues à l'image des travaux effectués par les chercheurs, et dont voici l'explication.
    Les chercheurs effectuent leurs travaux de la façon suivante. La première étape est la collecte d'échantillons, pour cela ils vont sur le terrain, c'est-à-dire qu'ils choisissent un lieu en Islande. Arrivés sur place, certains chercheurs relèveront les différentes plantes que l'on peut trouver, d'autres poseront des pièges afin de voir quels types d'insectes se trouvent dans la région... Une fois l'échantillon prélevé, il faut l'analyser, c'est la deuxième étape. En effet, il faut vérifier l'identité des êtres vivants trouvés et les rattacher à une famille, une espèce...
    La base de données reflète cette logique. Dans notre table Echantillon, nous enregistrerons les informations concernant la location, la date, l'environnement... Pour chacun de ces enregistrements, on aura un à plusieurs enregistrements correspondant dans notre table Données de l'échantillon. Nous y référencerons une ou plusieurs espèce(s) trouvée(s) (autant d'enregistrements que d'espèces différentes) ainsi que quelques informations complémentaires comme le nom de la personne ayant procédé à l'identification, la technique de conservation du spécimen, le nombre de spécimens mâles, femelles ou autres trouvés, etc. Les informations génériques à une espèce (hiérarchie, nom latin...) ne sont pas enregistrées dans cette table, une troisième table, Espèces, gère ces données. Ces trois tables ne sont pas les seuls éléments de la base Laupur. Nous avons appelé les autres tables “constantes” car elles ont un rôle pour la plupart consistant à alléger la surcharge des tables principales (éviter d'avoir les mêmes informations enregistrées plusieurs fois).

                        b. Gestion multi-utilisateurs
    La gestion multi-utilisateurs de la base de données pose un certain nombre de problèmes à résoudre, certains d'ordre programmationnel (comme la gestion des conflits si deux utilisateurs modifient le même champ en même temps) et d'autres d'ordre conceptuel (comme la hiérarchisation des accès aux données…). Nous évoquerons donc ces derniers, les premiers ne concernant que la réalisation.
    Ingres propose une gestion des groupes et utilisateurs assez poussée en permettant de définir précisément les droits pour chaque objet de la base. La contrepartie de cette gestion est un maniement assez lourd et peu flexible. J'ai donc choisi de laisser une partie de la gestion à Ingres et l'autre partie à l'interface. J'ai donc hiérarchisé les utilisateurs en trois catégories :

• Administrateur : a un accès absolu à toutes les données et peut modifier les groupes, utilisateurs… (acompte et mot de passe requis)
• Utilisateur : a un accès en lecture pour toutes les données de la base mais ne peut ajouter ou modifier des données que pour son propre groupe. (acompte requis et mot de passe facultatif)
• Anonyme : possède juste un accès en lecture à la base. (acompte et mot de passe facultatifs)

    Ces trois types d'accès sont définis sous Ingres en trois groupes, chacun ayant ses propres droits comme indiqué ci-dessus. Ensuite, deux tables on été ajoutées à la base de données, une contenant la liste des groupes des utilisateurs (“insecte”, “mollusque”…) avec les droits d'accès pour chacun d'entre eux et l'autre contenant la liste des comptes utilisateurs avec leur mot de passe plus diverses autres informations. Voici la structure de ces deux tables :

• Grouptbl (table contenant la liste des groupes) : seul un Administrateur peut modifier les données de cette table.
    gid : Long Integer : contient l'identifiant unique du groupe
    gname : VarChar : contient le nom du groupe
    gperm : Small Integer : contient un numéro référençant le niveau de permission.
   
• Usertbl (table contenant la liste des utilisateurs) : toute personne peut modifier son mot de passe, mais seul un Administrateur est à même d'effectuer d'autres modifications.
    uid : Long Integer : contient l'identifiant unique de l'utilisateur
    uname : VarChar : contient le login de l'utilisateur
    upasswd : VarChar : contient le mot de passe de l'utilisateur
    gid : Long Integer : référence l'appartenance à un groupe
    connected : Boolean : permet de savoir si l'utilisateur est actuellement connecté
    last_conn : Long Date : date de la dernière connexion
    info : Long Integer : référence différentes informations supplémentaires sur l'utilisateur.

    Dans chacune des tables communes à tous les utilisateurs mais dont les informations sont spécifiques à chaque groupe, il y a une référence au groupe au moyen d'un champ "gid". Ainsi lors de chaque opération, l'interface vérifiera si l'utilisateur est bien qualifié pour l'opération demandée. De même, ce champ est utilisé pour une autre opération qui ressemble à une réplication de base. Dues aux lenteurs du réseau et aux connexions simultanées sur le serveur, la lecture de données est assez lente. C'est pourquoi il m'a été demandé de faire un module permettant de répliquer partiellement la base sur une machine locale. Pour effectuer cette opération il ne faut récupérer que les données du groupe de travail d'où l'utilité de ce champ.

2. L'interface

    L'interface est le logiciel permettant aux utilisateurs de l'Institut de se connecter à la base de données et de travailler de manière intuitive. Cette interface se dénomme Laupur - Manager et son nom de code est LPMGR (utilisé pour le fichier log...). La version actuelle est 0.21.1978.

                        a. Ergonomie
    Les chercheurs de l'Institut n'étant pas informaticiens de formation, nous avons donc décidé de créer une interface la plus ergonomique possible. Mais comment rendre les choses simples avec un projet aussi complexe. Il faut en effet permettre l'ajout de données d'une manière intuitive, pouvoir établir une connexion à la base de données pour échanger les informations, manipuler les données... Autant d'opérations complexes et difficiles parfois à réaliser.
    Pour résoudre ce problème, nous avons utilisé ce que l'on appelle les Wizards (magicien en anglais). Ce sont en fait des petits bouts de programme offrant à l'utilisateur un grand nombre de possibilités avec une grande facilité. Un Wizard procède par petites étapes successives où il interroge l'utilisateur sur quelques problèmes à la fois (2 à 3 pas plus) en expliquant les tenants et les aboutissants. Une fois les informations collectées, il peut créer ce pourquoi il a été fabriqué.
    Pour créer un Wizard, il s'est avéré très important de bénéficier de panneaux, comme l'objet panel standard de Visual Basic, mais avec quelques améliorations. En effet, avant chaque étape, le Wizard doit préparer les questions et les réponses possibles et ce le plus souvent dynamiquement. Et également après réponse de l'utilisateur, il fallait vérifier que celle-ci pouvait être plausible. Nous avons donc créé un composant OCX (tout comme les objets standards de Visual Basic) répondant à ce besoin. L'avantage d'un tel composant est qu'il peut être réutilisé, nous bénéficierons donc des avantages de cet objet dans tout le projet mais aussi dans de futurs projets.
    Notre premier Wizard fut pour établissement d'une connexion entre le client et le serveur. Nous utilisons ODBC et un certain nombre de paramètres sont nécessaires pour la création de l'objet connexion. Nous avons donc établi un Wizard (voir figure 2) adapté à différents utilisateurs et permettant la création du lien vers la base de données. Le Wizard va d'abord demander à l'utilisateur s'il veut créer la connexion par lui-même ou non. Il y a quatre choix prévus à cet effet. Le premier, celui recommandé, est entiérement automatique, le Wizard va essayer de créer la connexion en recherchant les paramètres nécessaires, l'utilisateur n'intervient donc pas dans ce mécanisme et ne requiert donc pas de connaissance préalable de sa part.

Figure 2 : Wizard pour la création d'une connexion.

    Le deuxième choix, quant à lui, offre la possibilité à l'utilisateur de contrôler les paramètres de la connexion. Ce choix est similaire au premier si l'utilisateur ne change pas les valeurs proposées par le Wizard. En effet pour chaque étape le Wizard va rechercher toutes les valeurs possibles pour un paramètre et les placer dans une liste déroulante (objet combobox), il va ensuite sélectionner par défaut la valeur qu'il pense être juste (voir figure 3) tout comme en mode automatique. La différence avec le premier choix est qu'à chaque instant l'utilisateur peut modifier un paramètre et lui attribuer une autre valeur.

Figure 3 : Choix du driver. Le Wizard propose Ingres par défaut.

    Le troisième choix offre plus de possibilités pour la création de la connexion. En effet dans les deux premiers cas, le Wizard construira une chaîne de connexion à partir de quelques paramètres qui sont principalement le nom du driver ODBC, le nom du serveur (VNode dans le cas d'Ingres) et le nom de la base de données. Dans ce troisième cas, il est possible de créer des DSN (voir figure 4), de paramétrer plus précisément la connexion, de configurer soi-même le VNode... Ce niveau est indiqué “pour utilisateur avancé” car il utilise des termes techniques mais reste aisé car le Wizard aide l'utilisateur dans ses choix.

Figure 4 : Création d'un DSN (composant ODBC).

    Le quatrième choix offre la possibilité de récupérer la dernière connexion effectuée. Après l'installation de Laupur - Manager, le programme vous demandera d'établir la connexion avec la base de données. Lors du prochain lancement, LPMGR relira les paramètres enregistrés précédemment et se connectera automatiquement au serveur. LPMGR effectue aussi différentes tâches automatiques et transparentes pour l'utilisateur telles que lancer Ingres au démarrage. Ingres est effectivement peu “user-friendly” et requiert que l'on installe sur l'ordinateur du client outre leur driver mais aussi Ingres Net. C'est cet Ingres Net qu'il faut lancer au démarrage sinon la connexion sera impossible. Aucun composant n'est livré par Computer Associates pour effectuer cette tâche, il faut donc trouver d'autres moyens qui ont été l'utilisation d'OLE, Microsoft Windows Script Host (http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/pointers/scripting_5y94.htm) et d'une classe Visual Basic créée par Saskatchewan Energy and Mines (http://www.gov.sk.ca/govt/enermine/).
    Malgré cette aide apporté par le Wizard, ce dernier n'est pas infaillible et une erreur peut toujours survenir. C'est pourquoi nous avons conçu un autre module appelé “Connection Problem Solver” ou plus simplement CPS. En cas d'erreur lors de la connexion, CPS est automatiquement lancé, recherche les causes possibles et les solutions. Il présente ensuite à l'utilisateur le problème avec sa description et aussi comment résoudre celui-ci. Nous avons construit un exemple interactif vous permettant de voir son fonctionnement. Nous avons créé une connexion manuellement mais avons donné des informations incorrectes pour le VNode. Le driver ODBC de Computer Associates renvoie l'erreur “L'opération a été annulée par le serveur”. Le driver retourne cette erreur lorsque la connexion s'est mal effectuée, indépendamment de l'erreur renvoyée par le serveur, ce qui n'est pas pour simplifier notre tâche. Mais la cause la plus souvent récurrente de cette erreur est lorsque le VNode est mal configuré. CPS propose donc à l'utilisateur la création d'un nouveau VNode. Une fois celui-ci créé, CPS met à jour la chaîne de connexion (ce qui implique de mettre à jour les DSN si utilisés) et demande à l'utilisateur s'il souhaite essayer la nouvelle configuration. CPS monitorera la nouvelle tentative et réagira en cas de nouvelles erreurs.
    L'ajout de nouvelles valeurs dans la base de données se fait elle aussi par l'intermédaire de Wizard. Ceci permet à l'utilisateur d'enregistrer de façon aisée et sûre ses informations. En effet, le Wizard ira proposer des listes de choix à l'utilisateur afin d'éviter par exemple des erreurs de frappe. Le Wizard propose aussi quelques aides qui facilitent la tâche de l'utilisateur tout en apportant plus de sécurité quant à la validité des données. Vous pouvez consulter ici deux exemples de ce type d'aide.

                        b. Réplication
    Une des demandes faites pour les spécifications du projet fut la possibilité de disposer pour chaque chercheur d'une copie de ses propres données localement (c'est-à-dire sur son ordinateur) et sous Access. Ceci lui offre l'avantage de pouvoir consulter ses données en utilisant Access et les outils déjà développés pour, tout en ayant une rapidité bien supérieure à ODBC et au transfert de données par le réseau. C'est aussi un moyen plus sûr et rassurant pour lui de savoir qu'il peut manipuler ses données sans risque de pertes. En cas d'effacement ou autre, l'utilisateur a juste à télécharger une nouvelle copie de ses données. Nous avons donc créé un module (voir figure 5) permettant cette opération, il autorise l'exportation des données Ingres d'un utilisateur vers Access 95, 97 ou 2000. De plus, il suffit d'appliquer un petit patch pour autoriser de nouvelles versions d'Access. En effet, nous avons conçu une base de données, “setup.cfg” livrée avec le programme, que le programme consulte pour y trouver diverses informations, configurations... C'est dans cette base que sont enregistrés les paramètres pour les différentes versions d'Access. Par simple mise à jour d'une table (une requête SQL), nous pouvons ajouter de nouvelles versions d'Access. L'utilisateur n'a plus qu'à sélectionner dans le menu “Préférence” la version souhaitée.

Figure 5 : Module de réplication.

    L'utilisateur peut soit recréer une nouvelle réplication ce qui implique un téléchargement de toutes les informations le concernant, soit de mettre à jour la réplication actuelle de la base, le module ne téléchargera alors que les enregistrements ou table ajoutés ou mis à jour et il effacera les enregistrements ou table effacés. Ceci est bien évidement moins lourd et si les mises à jour sont fréquentes, l'utilisateur disposera de ses données en très peu de temps.
    Pour optimiser la procédure, nous avons mis en place un système permettant de sélectionner plus précisément les données à répliquer. Ce système se configure dans le menu option du logiciel (voir figure 6). Par défaut, seul les tables qui seront mises à jour périodiquement par les utilisateurs sont répliquées. Les autres, servant généralement de références, sont petites en tailles, nous avons donc décider d'utiliser la possibilité d'Access pour créer une table liée. En d'autres termes, ces tables apparaîtront sous Access mais ce dernier ne conserve en mémoire que la connexion ODBC et la requête SQL. Cette technique allège le processus de répliquation. Le menu option offre la possibilité à l'utilisateur de sélectionner certaines table de références dans le processus de réplication et d'ignorer certaines tables principales. Certains chercheurs n'utilisent que peut ou beaucoup certaines informations. Par cette technique, il peut répliquer seulement celles qu'il utilise tous les jours, d'où un gain de rapidité certain.

Figure 6 : Option - Optimisation de la répliquation.