COMMENT EXPRIMER ?

Le travail de conception devient de plus en plus technique ; il s’agit à présent d’exprimer le schéma logique dans une formulation telle qu’elle soit acceptée par un logiciel SGBD spécifique (dBASE III d’Ashton Tate en l’occurence). J’insiste sur le mot exprimer : il ne s’agit plus de modifier la structure de la base mais seulement de la traduire dans un langage déterminé. Cette étape est donc aussi essentiellement « mécanique ». Pour guider l’apprenant dans son travail, il est souhaitable de distinguer ici aussi quelques phases clés.

Déclarer la structure des fichiers

Il s’agit tout simplement de créer un fichier dBASE pour chaque table en traduisant chaque colonne par un champ du fichier. Les caractéristiques techniques des champs (type et dimension) seront déduites des « règles de fonctionnement » établies lors de l’élaboration du schéma conceptuel.

Elaborer des masques de saisie en installant des mécanismes de contrôle des contraintes d’intégrité

Ici, dBASE ne nous offre que peu d’outils pour traduire les C.I. ; seules les clauses RANGE et PICTURE permettent un contrôle de quelques contraintes de valeurs (par ex: la date de naissance doit être inférieure à la date de jour) ou de forme (par ex: le code postal doit être composé de chiffres uniquement). Pour un contrôle vraiment efficace des C.I., il faut généralement recourir à la programmation. Notons cependant que l’énoncé même des CI constituent une excellente base (c’est le « Quoi faire ? ») pour la rédaction de ces programmes de vérification.

Déclaration des index « indispensables »

Le choix des index est dicté en dBASE par deux types de considérations : d’abord la classique quête de rapidité lors des recherches les plus courantes mais aussi la nécessité de disposer d’un index lors des « mise en relation »(13) de deux fichiers.

Mise en place de « vues » multifichiers pour permettre la consultation, sans (trop de) risques, à une large classe d’utilisateurs

Les possesseurs de dBASE III Plus sont ici plus choyés que les autres car ils disposent d’un peu plus d’outils pour créer des vues réutilisables par d’autres utilisateurs. Pour ceux qui ne disposent que de dBASE III, quelques (très) courts programmes ouvrant fichiers, index et masques et installant un filtre rendront déjà de fiers services.

Remarques – Cette dernière étape de la démarche de conception est profondément influencée par les caractéristiques du logiciel qui servira à gérer la base de données. Elle devra donc être adaptée en conséquence si l’on désire employer un autre SGBD que dBASE III. Les phases de travail seront dans l’ensemble similaire. Les plus grandes différences se situant au niveau des possibilités d’implémentation des contraintes d’intégrité ainsi que de la création des vues. (13) Je n’expliquerai pas ici l’inévitable confusion introduite par le mécanisme de « set relation » dans la théorie relationnelle ni sur les indispensables mises en garde quant à l’utilisation de ce mécanisme à la place de la « vraie » jointure : ce n’est pas l’objet de cet article. Il conviendra cependant de faire clairement le point sur ces sujets avec les apprenants.
– Je ne développe que fort peu la notion de vue (liée à celle de schéma externe) car elle ne trouve sa vraie justification que dans un contexte multiutilisateur. Or celui-ci n’est, aujourd’hui et avec les logiciels actuels, que fort partiellement disponible. C’est néanmoins une des directions dans laquelle la démarche présentée ici devra être étoffée d’ici peu. – Du point de vue méthodologique, cette dernière étape doit nécessairement s’accompagner d’une mise en oeuvre réelle, sur machine de la base de données. Il est alors très intéressant de prévoir un ensemble de données à introduire de façon à vérifier, tant les mécanismes de saisies et de validation, que ceux d’extraction des données.