Bases de Données  - Méthodologie

Introduction

- Des principes bien connus relatifs aux bases de données sont résumés ici dans le contexte des interfaces utilisateurs émergentes, en s’appuyant sur l’ expérience de nombre de réalisations, au cours des vingt dernières années.

- L’objectif n’est pas de définir ce que doit comporter une base de données, en termes de fonctionnalités, mais les aspects que le concepteur et décideur doivent prendre en compte dans la mise en œuvre d’une base de données.

1-Importance de la modélisation des données

La modélisation de l’organisation actuelle et future, sa représentation sous forme de processus, la modélisation des données, la modélisation des traitements (découpage en module, procédures, et en particulier modélisation de l’interface utilisateur) sont des aspects essentiels dans la maîtrise et la mise en place de bases de données.

• On ne peut concevoir ni comprendre sans représentation et modélisation. La phase de conception consistera à construire un modèle qui permettra de représenter correctement une réalité actuelle ou envisagée. La base de donnée est un élément central de l'environnement de développement (appelé également "Framework" ou "AGL" (atelier de génie logiciel).

• L’interaction entre une organisation d’entreprise et l’organisation de ses données est importante.

• Un modèle décrivant une réalité, n’est jamais indépendant des objectifs de celui qui réalise le modèle. Au travers du modèle, vont apparaître les choix, les objectifs, en ce qui concerne l’organisation. Une organisation pouvant comporter des contradictions et même des objectifs antagonistes, il est souhaitable que les objectifs réels soient formulés clairement. Si ce n’était pas le cas, on risquerait de construire un modèle qui poserait ensuite des problèmes avec certains traitements.

• Se pose très vite le choix d’un modèle de représentation conceptuelle, adapté au modèle de base de données mis en œuvre hiérarchique, réseau, relationnel, objet. Citons les approches entité-association, synthétique, analytique. Pour chaque type de modèle, on utilisera un certain nombre de concepts, et un vocabulaire, qu’il est préférable de maîtriser pour les utiliser de façon pertinente. (Par exemple dans le modèle relationnel les concepts d’entités, relations et attributs, les termes d’algèbre relationnelle sélection, projection,union, intersection, jointure, auto-jointure, ...).

• A partir d’un modèle on peut envisager des automatismes entre la définition conceptuelle des données et la construction physique des tables (dans le cas d’une base de données relationnelle), des index, et des contraintes relatives aux données, et même envisager la génération des applications.

• L’objectif de génération automatique des applications à partir de modèles est limité par la complexité à décrire de façon exhaustive des traitements nombreux, la difficulté de description des interfaces utilisateurs et la certitude que si l’on crée une application trop complexes, les utilisateurs seront "rétifs" à son utilisation.  

• Avec le développement de logiciels à grande diffusion véritablement conviviaux, il devient de plus en difficile d’obliger les utilisateurs à se servir d’applications dépassées ou mal conçues. Dès la conception d’une application, on doit se poser la question "Ce que nous sommes en train de concevoir, les utilisateurs pourront et voudront-ils vraiment s’en servir ?" . Il est souvent pertinent d’associer utilisateurs et futurs utilisateurs à certaines phases de la mise en place d’une base de données, et ce dès la conception.

• Programme = Données + Algorithmes + Interfaces Utilisateur (saisie, consultation, requêtes, états).

• La modélisation des données doit rester simple. Il faut éviter systématiquement les systèmes d'aide à la conception générant des documents de plusieurs dizaines ou même centaines de pages dont le résultat est de masquer l'essentiel dans une foule de détails. Une seule page doit permettre de décrire, de façon synthétique, les principales "tables" d'une base de données quelle qu'elle soit.  En particulier, il est utile de ne pas mélanger dans un dossier de description les trois types de "tables" suivants :

        - Les tables de données (représentant 90% ou 95%) du volume des données. Leur contenu est en général alimenté par les "utilisateurs finaux" de l'application. Par exemple, les tables de Clients, Factures, Produits.
        - Les tables de catégories fonctionnelles ou de paramètres ajustables. Leur contenu est en général alimenté par les "gestionnaires de l'application". Par exemple, les codes TVA, les catégories de clients, les zones géographiques, les types de dépenses.
        - Et enfin les tables liées à la programmation, que seul un développeur peut être amené à modifier et alimenter.

2-Indépendance entre les données et les traitements

• Le dictionnaire des données est un outil essentiel pour l’indépendance entre données et traitements. On peut définir des traitements les plus génériques possible, s’adaptant au dictionnaire des données.

• On décide de stocker une donnée afin de pouvoir effectuer des traitements sur cette donnée. La recherche des données ne donnant lieu à aucun traitement permettra de détecter d’éventuelles incohérences, de même que la recherche des traitements manipulant "sans raison" ni résultat des données.

• Les données peuvent exister sans traitements. Les traitements sont la plupart du temps dépendants des données. Si les traitements peuvent être indépendants "entre eux",il sera plus aisé d’ajouter ou de supprimer certains traitements.

•Dans une approche de programmation "Objet", un traitement consiste essentiellement à créer et supprimer des objets, et changer certaines propriétés de certains objets. Une "méthode"sera en général liée à un type d’objet ou plusieurs types d’ objets.

• Dans une base de données documentaire, les liens de "navigation" sont construits dans le but de permettre à l’utilisateur des accès dans un ordre non-déterminé à l’avance. Ils doivent être conçus de façon à ne pas entrer en conflit avec la mise à jour des informations, ni la validation des informations. De plus les données ont une durée de vie longue, alors que les interfaces utilisateurs évoluent souvent plus rapidement. L’objectif est donc de disposer d’une indépendance entre la représentation dans la base de données des liens de navigation et les outils de navigation.
 

3-Non redondance des données

• La non redondance de données doit prendre en compte les aspects de bases de données réparties, et la mise en œuvre de systèmes mobiles capable de stocker temporairement, en attendant la prochaine connexion, certaines informations.

• Les mécanismes de verrouillage des données pendant les phases de mises à jour en accès concurrents vont permettre d’éviter que la même donnée puisse pendant quelque instants posséder des valeurs différentes.

• Cela conduit à des questions dès la phase de conception. 

4-Contrôle des accès et des droits vis à vis des données, intégrité des données

• La réalisation d’un inventaire des types de traitement autorisés par utilisateur et par donnée, va permettre de définir des "profils" d’utilisateurs.

• On définira les droits , pour chaque profil d’utilisateur, relatifs aux différentes actions logiques Ajout, modification, suppression de données, aspects de confidentialité.

• Les mécanismes d’ intégrité entre données permettront de placer au niveau application ou au niveau de la base de données elle même, des contraintes.

• Il peut être important de mémoriser les actions effectuées sur les données. Quel utilisateur, à quelle date, a le dernier effectué telle modification ? Comment gérer alors les suppressions de données ? Souhaite-t-on conserver les anciennes versions ?

• On peut dissocier les "compétences " de mise à jour.

• Un contrôle des accès doit rester gérable, et simple de mise en œuvre.

5-Mécanismes de sauvegarde et restauration des données

• Selon les mécanismes de sauvegarde, on pourra effectuer une réimplantation de la base de données initiale, ou une réimplantation des la base de données au jour J et à l’heure H. La plupart des bases de données proposent de réaliser des sauvegardes physiques et certaines une journalisation des mises à jour, se traduisant par la création de fichiers comportant l'état des données individuelles juste avant les mises à jour.

• Un objectif important est la cohérence dans la sauvegarde des données. L’impact des mises à jour "concurrentes" sur les mécanismes de sauvegarde doit être pris en compte. Nécessité de restaurer également les index, vues, procédures cataloguées liées aux données (déclencheurs) ou aux traitements (appels depuis certains modules de procédures cataloguées).

• Le problème n’est pas de sauvegarder mais de restaurer correctement ! On rencontre, dans certains organismes, des bases de données qui sont scrupuleusement sauvegardées, mais sans que l'on ait jamais vraiment testé la réinstallation des données après incident.

• Un mécanisme de sauvegarde/restauration doit toujours être validé , si possible dans les conditions les plus défavorables !

6-Modes d’accès variés

• Les bases de données permettent une grande latitude en termes de modes d’accès accès en modes texte ou mode graphique, en mode terminal, ou depuis un Micro-Ordinateur, en mode local, client-serveur ou poste de type Internet.

• Le mode client-serveur décrit un mode d'accès aux données, qui s'est largement développé dans les années 1990. Le mode client-serveur suppose un poste de travail capable de stocker des données temporaires et d'effectuer, "en local", des traitements. Par exemple, une application de saisie comptable en mode client serveur, va stocker dans des structures de mémoire vive, le plan comptable. La recherche, sur critères, d'un compte précis pourra ainsi, au cours de la saisie, être effectuée sans accès à la base de données "centrale".

    A l'inverse, une prise de commande, sous forme d'interface HTML (sur Internet), ne fonctionne pas en général en mode "client serveur", mais en mode "terminal" / "ordinateur central". L'aspect graphique et convivial de la fenêtre du navigateur HTML n'empêche pas celui-ci de n'être "qu'un terminal" vis à vis de l'ordinateur "central" ou du serveur.

• Des accès interactifs ou en traitement par lots, immédiat ou différés (cas des "mobiles") doivent être possibles ;

• Plusieurs langages doivent permettre d’accéder aux mêmes données, ainsi que plusieurs technologies adaptées aux différents profils d’utilisateurs.

• Des outils différents sont à mettre en œuvre selon le temps dont dispose un utilisateur pour accéder aux données.

• Ce qui est complexe ce sont les structures de données et non pas le langage SQL! La conception de la question est plus complexe que sa formulation. Ce qui est graphique n'est pas nécessairement simple.

• Il est utile de fournir le choix entre des accès aux structures de base (physique) ou à travers des représentations de plus haut niveau (Vues éliminant la notion de jointure, ou approche infocentre).

• Les traitements doivent pouvoir être répartis traitements centralisés dans la base de données (ex procédures cataloguées) ou effectués sur le poste de travail ( suites de requêtes SQL de lecture, traitement en local, puis ordres SQL d’écriture), ou sur le serveur (lancement à telle heure d’un traitement traitement par lots).

• Il est important que la la base de données puisse être utilisée par des techniques de programmation différentes approche algorithmique et procédurale, approche non procédurale (SQL, déclencheurs), approche objet (OLE 2 Automation-Active X, AppleScript , XML)

7- Outils variés d’interface utilisateur

• Parmi les interfaces utilisateur, citons générateurs d’écran (en mode texte), générateurs d’écrans graphiques, outils génériques de réalisation d’interfaces graphiques, tableurs et logiciels bureautiques, interfaces en "langage naturel".

• La modélisation de l’interface utilisateur est un objectif important. On décrit successivement n interfaces, auxquelles on affecte des noms. La description de l’interface utilisateur d’une application complexe revient alors à décrire l’enchaînement de certains modèles pour traiter certaines données.

• On note l’ importance croissante de la notion de prototypage et des outils de développement rapide (RAD) L’interface utilisateur peut alors être décrite de la façon suivante

Interface du logiciel = Interface du Prototype + Liste de modifications (décrites en langage naturel).

• On devrait aller vers une définition plus sérieuse de l’ergonomie.

- Graphique ne signifie pas obligatoirement ergonomique. Le multi-fenêtrage trop systématique peut également être un obstacle à la lisibilité.

- La multiplicité des icones et choix possibles, les cascades de menus et sous-menus nuisent à l’ergonomie.

- L’interface utilisateur doit être pensée en fonction de la fréquence d’utilisation. 

- Il faut trouver un juste milieu entre un nombre réduit d’écrans surchargés et des centaines d’écrans posant des problèmes de navigation ("Je sais qu’il existe un écran permettant de faire cela, mais comment l’obtenir ? ").

- L’utilisation de la "nouvelle interface" HTML+Formulaires+Java modifie les habitudes Taille d’écran non limitée, Indépendance vis à vis du système du poste client, mélange des commandes et des aides en ligne, ...

• On note une tendance à l’utilisation de plus en plus grande du graphisme, y compris pour les tâches d’administration -> remplacement des commandes SQL par des fonctions graphiques (Icones, Drag and Drop, présentation sous forme d’objets, ..). Avantages en termes d’ergonomie, Inconvénients en termes de "Mémorisation de ce qui a réellement été fait, et que l’on souhaite refaire". Obstacle de la complexité où une phrase SQL, même longue, est plus compréhensible qu’une suite de manipulations graphiques, difficiles à reproduire.

8 - Généralisation de la notion d’ État

• On conserve bien évidemment les listings en mode texte uniquement, mais de plus en souvent enrichis d’éléments graphiques, tirant parti de la généralisation des imprimantes laser et jet d’encre.

• L’interfaçage entre les bases de données et les outils bureautiques (en particulier les tableurs) permettent à l’utilisateur final de continuer à se servir de son outil bureautique quotidien.

• On réalise à partir des bases de données de la génération automatique de mise en page dans un format visualisable, modifiable et imprimable (par ex PDF, PostScript, Document Excel, ...)

• Lorsque le besoin de performances est élevé (grand nombre de pages, utilisation maximale des performances des imprimantes), des méthodes de génération automatique de mise en page non modifiable (ex PDF ou PostScript) sont employées.

• Enfin les documents générés peuvent être conçus sous forme de documents interactifs, non destinés à être imprimés, amis surtout à être consultés par Internet/Intranet : génération automatique de pages interactives, avec index, liens actifs, outils de recherche intégrés.

9 - Capacité de la base de données à évoluer

• Il faut en particulier pourvoir réorganiser les données en cas de changement de structure

• Les accès à la base de données doivent pouvoir être améliorés, par exemple en créant de nouveau index, de nouvelles vues, ou en utilisant une approche objets, même si la base de données est relationnelle.

• L’identification des traitements à modifier et la maintenance des traitements doivent être pensés dès le départ, l’impact de l’évolution des données sur les traitements étant souvent non négligeable.

10 - Nécessité d’outils de validation et documentation de la base de données

• L’ensemble du processus de conception et de mise en œuvre d’une base de données, devrait pouvoir répondre à des objectifs et norme de "qualité". De plus en plus de SSII recherchent la certification ISO 9000.

• Dictionnaire des données, dossiers détaillés des traitements, historique des modifications, tableaux croisés données/traitements sont des outils indispensables.

• Il faudrait mettre en place et tenir à jour une documentation actualisée des différentes étapes, de la conception à la mise en production d’une base de données.

• Dans un but d’évolution on peut également mettre en place une gestion des évolutions

- Gestion de la liste des dysfonctionnements connus

- Gestion de la liste des améliorations suggérées ou envisagées

- Gestion de la liste des nouveaux modules en cours de réalisation

Conclusion

Le développement des systèmes de gestion de bases de données offre de remarquables outils permettant la construction de systèmes performants et cohérents.

La discipline d’une méthodologie et le souci permanent des utilisateurs sont à la base de la réussite dans la mise en œuvre de bases de données.

Extrait de bibliographie

- Bases de données et SGBD, de la conception à la mise en œuvre, Démarche pratique F.Kramarz, O.Perrault, Masson Paris 1986, ISBN 2-225-80849-X

- Merise - Vol 2- Etudes et exercices, A.Collongues, Dunod Informatique, 1989, ISBN 2-04-018601-8

- Guide rapide SQL, Patrick Pons, Uriel Chouchena, P.S.I. 1989, ISBN 2-266-03525-8

- Guide du langage SQL, John Viescas, Microsoft Press, 1989, ISBN 2-7124-0496-3

- Oracle par la pratique, James T. Perry - Joseph G. Lateer, Sybex, 1990, EAN 9-782736-106447

- Codd’s new commandments, Consultants’ conspectus, June 1995, pp 18-20.

- Does your DBMS run by the rules ? , E.F. Codd, ComputerWorlds, Oct 1985

- Le livre de SQL, Suzy Pasleau, PSI 1989, ISBN 2-86595-537-0

- SQL, Christian Marée, Guy Ledant, Armand Colin, Paris 1989, ISBN 2-200-42000-5

- Using Oracle Web Application Server 3, Rick Greenwald, QUE , ISBN 0-7897-0822-1

Pour nous contacter...

- RCI Informatique SA