Avantages et inconvénients des SGBD

Les gestionnaires de base de données de type hiérarchique sont apparus à la fin des années 1960 (comme DL/1, IMS ou Système 2000).

Ces gestionnaires permettent de traiter de façon élégante et efficace une situation très fréquemment rencontrée dans la pratique : la dépendance

Mono-dimensionnelle. Un exemple type est le problème CLIENT-COMMANDE : chaque client est "propriétaire" d’un certain nombres de commandes qu’il a passées.

Pourtant, si on ajoute un étage à cette construction, on atteint les limites du hiérarchique.

En effet, chaque commande se décompose en "ligne de commande" qui référencent un produit et une quantité commandée pour ce produit. Le schéma hiérarchique ne permet d’établir un lien fonctionnel entre la ligne commande et le produit commandé qu’à travers une redondance de donnée (le code "produit" figure dans la liste des items de l‘enregistrement LIGNE).

On retombe dans la même ornière qu’avec un gestionnaire de fichiers.

Pourquoi ? Essentiellement parce que le hiérarchique ne peut traiter que des situations de décomposition mono-dimensionnelle alors que nous sommes en présence d’un problème à deux dimensions : la quantité dépend à la fois de la commande dans laquelle elle existe et aussi du produit qui est référencé. Or, un gestionnaire hiérarchique interdit à un enregistrement d’avoir plusieurs parents : c’est une limitation fonctionnelle, dont nous voyons ici les conséquences pratiques

Client

Structure hiérarchique

	Ligne 1Cde1			Ligne Cde 1		Ligne Cde 1

 

C'est pour lever ce genre de restrictions qu’un nouveau type de gestionnaire de base de données a été défini en 1971, avec la publication, par un groupe de travail réunissant fabricants d’ordinateurs et utilisateurs, du rapport connu sous le nom de "Codasyl Data Base Task Group Report".

Ce rapport reprenait, en les développant, des idées qui venaient d’être mises en œuvre par Charles Bachman dans la conception du SGBD IDS sur le matériel Honeywell. Ce rapport eut un retentissement suffisant pour que, peu après, deviennent disponibles des SGBD de types réseau, "aux normes Codasyl" aussi célèbres maintenant que: IDMS (de Cullinane), IDS II (sur Honeywell), DMS 1100 (Univac), DSMS (Data General) et DBMS (Prime).

Dans cette nouvelle génération de SGBD, on parle désormais de : type d’enregistrement et de relation (set) ; toute relation a (au moins) un propriétaire et un membre, qui sont des types d’enregistrement ; et les types d'enregistrement peuvent être à la fois membre et propriétaire de relations, sans limitation fonctionnelle.

Il faut noter que, dans les deux modèles de base déjà étudiés (hiérarchique et réseaux), la souplesse apparente due à la possibilité de faire créer par le système tous les pointeurs désirés est en fait limitée par la nécessité de définir, au moment de la création de la base, l’ensemble des pointeurs et chemins d’accès voulus. Toute modification ultérieure impliquant généralement une refonte de la base et des programmes d’exploitation.

Structure réseau

 

D’autre part, il existe, en plus des problèmes techniques, une "composante humaine" fort importante. En effet, si la compréhension d’un système de gestion de base de données (SGBD), est à la portée de tous ceux qui ont une culture informatique normale, il n’en demeure pas moins que la mise en œuvre de ce système est complexe, laborieuse et, à tout le moins, riche en embûches de toutes sortes et en problèmes de dernière minute, même si l’analyse a été bien menée.

On peut distinguer deux types de difficultés : d’une part, celles qui ont trait à la conception et à la mise sur pied de la base ; d’autre part, celles qui sont liées à son utilisation et à son évolution.

Dans le premier cas, l’utilisateur est confronté au double problème de la définition de son application et de la compréhension du SGBD choisi.

Il suffit de voir la taille de la documentation technique fournie avec certains produits, IMS d’IBM par exemple, pour se rendre compte de la complexité d’un logiciel de base de données.

L’utilisateur va devoir assimiler le langage de commande de son SGBD pour pouvoir définir sa base et les chemins d’accès. Pas toujours simple !

Dans le second cas, il va s’agir des ennuis habituels rencontrés lors de la mise en route d’une application informatique, quelle qu’elle soit. Toutefois, ils vont revêtir souvent un caractère de gravité car, contrairement aux applications classiques, celles qui utilisent des bases de données seront généralement dans un contexte "temps réel" avec de nombreux utilisateurs en ligne.

Dans ce cas la mise au point est délicate, car toute modification de la structure de la base entraîne automatiquement un "arrêt" temporaire de l’activité de la base en question.

Il est, en effet, impensable qu’un utilisateur puisse travailler sur une base que l'on est train de transformer.

Une des raisons pour lesquelles ces problèmes existent est sans aucun doute l’existence de liens physiques qui doivent être spécifiés au moment de la construction de la base et dont la modification ultérieure n’est pas permise par le SGBD sans reconstruction de la base.

C’est en effet le système qui va constituer la base de données en stockant les informations que l’on va lui fournir dans un ordre lié à la structure qui aura été définie. Les index vont être construits et stockés également d'une façon liée à l’organisation hiérarchique.

On a donc imaginé une autre organisation de base de données dans laquelle ces contraintes n’existeraient plus. Pour cela, une notion nouvelle doit se faire jour, celle de base de données "relationnelle". Terme à la mode, sans doute un peu ésotérique pour beaucoup, mais qui finalement va se comprendre sans trop de difficultés pour la bonne raison qu’il est beaucoup plus proche du raisonnement humain, que le terme hiérarchique ou arborescent.

Prenons donc un exempte calqué sur le raisonnement humain. Un adulte normalement cultivé possède "en mémoire" des millions d’informations rangées dans le cerveau, selon des mécanismes qui, pour la plupart, nous échappent encore totalement.

Ces informations peuvent être de nature différentes : mots, sensations, odeurs, bruits et sons, notions abstraites, etc.

Lorsque l’on nous pose une question ou que la discussion implique une recherche, il va de soi que nous n’allons pas consulter la totalité de notre mémoire, ni même toutes les informations que nous possédons sur le sujet donné, avant de donner notre réponse.

Premièrement, nous en serions bien incapables et ensuite il nous faudrait un temps rédhibitoire.

La raison en est fort simple : le cerveau humain n’est absolument pas construit selon les concepts de l’informatique actuelle. Sa structure n’est pas celle d’un disque magnétique et sa mémoire n’est pas "adressable". Chose curieuse d’ailleurs puisqu’il est quand même possible de retrouver instantanément une information ! Pour l’homme, c’est le contenu de la question qui va servir pour déduire la réponse. Il y a un processus déductif qui est à l’opposé du processus inductif utilisé dans la recherche sur une base de données hiérarchisée.

Lorsqu’on nous demande quelle est notre profession, il est évident que nous n’avons pas besoin de passer mentalement en revue tous les métiers que nous connaissons pour trouver le nôtre. Nous le trouvons immédiatement parce que la question est posée de telle façon que les mots "profession" et "nôtre" réduisent le champ de recherche à son strict minimum.

Notons encore qu’il est possible de poser la même question sous une bonne centaine de formes différentes quant à l’ordre des mots, leur nombre, ou bien la langue employée.

Les bases de données relationnelles fonctionnent donc selon ce principe : c’est le contenu de la question qui va déterminer quels sont les chemins d’accès à utiliser, les liens à établir.

Ces liens, ou pointeurs, ne seront plus fixés une fois pour toutes dans le SGBD mais ils seront fabriqués dynamiquement selon les besoins.

Mais cela n’est pas suffisant car il faudra que le langage d’interrogation du système soit capable de comprendre correctement une question. Pour cela, une seule possibilité : l’utilisation des opérateurs logiques de la théorie des ensembles (autre formulation l’algèbre relationnelle).

Le SGBD agira "par déduction" à partir de l’analyse de la question. Telle question implique la consultation des fichiers W et X, telle autre implique la consultation des fichiers Y et Z. Bien entendu, il y aura des liens entre question et fichiers mais ils existeront non comme pointeurs mais comme éléments d’un tableau géré par le SGBD. Que trouverons-nous dans ce tableau ? Tout simplement les associations entre les divers "champs" ou données élémentaires, et les fichiers correspondants.

Il sera possible à tout moment d’ajouter ou de supprimer des fichiers dans la base de données. Les associations seront faites lors des interrogations de la base, en fonction des noms de données spécifiés.

Par exemple, la donnée appelée "MATRICULE" se trouve dans les fichiers "PAIE", "HISTORIQUE" et "PERSONNEL". Dans ce cas, toute question faisant intervenir le mot "MATRICULE" quel que soit le contexte, déclenchera le chaînage logique des fichiers désignés. Grâce à son tableau de relations le SGBD va associer tous les fichiers contenant un ou plusieurs champs spécifiés dans la question de l’utilisateur.

Il est évident qu’une base de données relationnelle présente des avantages tels que :

- L’indépendance des utilisateurs vis à vis de la structure logique, la structure physique, la stratégie d’accès aux données;

- La puissance de représentation grâce à conception rigoureuse du schéma (approche méthodologique);

- La rapidité d’écriture du code

- La manipulation par des non informaticiens pour des cas simples sinon la connaissance de la structure de la base de données et de la maîtrise de l’algèbre relationnelle sont nécessaires.

- L’approche non procédurale permettant un traitement uniforme de la définition, de la manipulation et du contrôle des données

- L’évolutivité

- La prise en compte des contraintes d’intégrité

Différences entre les bases de données et les systèmes traditionnels de gestion des fichiers

Les caractéristiques principales d’une base de données sont :

— l’indépendance de la structure des données par rapport aux programmes de traitement (cette structure de données est prévue une fois pour toutes, pour tous les programmes : une base de données peut et doit évoluer mais doit vivre des périodes stables assez longues de 6 mois à un an) ;

— la prise en compte des relations entre les différentes données (chaînages) ;

— la non-redondance des données (en principe !) ;

— le partage simultané des données entre les programmes d’applications ;

— l’entité élémentaire que l’on peut lire dans une base de données est beaucoup plus petite qu’un enregistrement de fichier : elle correspond à un segment ou record.

Compte tenu de ces caractéristiques, il est évident que l'approche des systèmes traditionnels de fichiers diffère considérablement du concept de base de données

Qu’est-ce qu’une base de données?

Le premier problème auquel on se trouve confronté est de déterminer précisément ce que recouvrent les termes "base de données" et "système de gestion de bases de données" (SGBD). Un usage non-averti de ces termes peut se référer en fait à toute une collection de données accessible par l’intermédiaire d’un ordinateur.

Une base de données a trois caractéristiques essentielles. C’est d’abord un ensemble organisé et intégré de données. Elle correspond ensuite à une représentation fidèle des données et de leur structure, avec le minimum possible de contraintes imposées par le matériel. On doit enfin pouvoir l’utiliser pour toutes les applications pratiques désirées sans duplication de données.

Il existe trois types de bases de données : hiérarchiques, réseaux, relationnelles. Les caractéristiques liées à chacun de ces types sont développées plus loin.

Le Système de Gestion de Base de Données est le logiciel qui supporte une telle organisation des données. On peut le définir plus précisément comme, un ensemble de logiciels fournissant l'environnement pour décrire, mémoriser, manipuler et traiter des ensembles de données tout en assurant pour celle-ci la sécurité, la confidentialité et l’intégrité (la notion d'intégrité est proche de celle d’exactitude de cohérence), sachant qu’un grand nombre d’utilisateurs ayant des besoins variés interagit avec ces ensembles de données.

Les définitions sont cependant de peu d’intérêt pour déterminer si un système est vraiment un SGBD ou s'il s’agit simplement d’un système d’information classique ou d’un système de fichiers. Il faut mieux définir le SGBD en précisant certaines des fonctions qu’il doit remplir :

— l’intégration des données afin d’éviter l’incohérence d’éventuelles données dupliquées (tout est intégré dans un seul ensemble cohérent) ;

— la séparation entre les moyens de stockage physique des données et la logique des applications ;

— un contrôle unique de toutes les données afin de permettre l’utilisation simultanée par plusieurs utilisateurs ;

— la possibilité d’utiliser des structures de fichiers et des méthodes d’accès complexes, de façon à ce que les relations correctes entre les données puissent être exprimées et les données utilisées le plus efficacement dans un grand nombre d’applications ;

— des facilités pour le stockage, la modification, le réorganisation, l’analyse et la consultation des données, sans que le système impose des restrictions à l’utilisateur ;

— des contrôles de sécurité afin d’empêcher l’accès illégal à certaines données ;

— des contrôles d’intégrité pour prévenir une modification indue des données (exemple: contrôle d’exactitude, de validité) ;

— la compatibilité avec les principaux langages de programmation, les programmes-sources existants, et les données extérieures à la base.

Les SGBD les plus évolués actuellement disponibles disposent de la plupart de ces fonctions, mais pas toutes. Il en résulte des différences significatives entre leurs caractéristiques, leur fonctionnement et leurs usages possibles.

Il convient de signaler également que les bases de données sont plus qu’une nouvelle technique de stockage et de manipulation des données. Elles impliquent une nouvelle approche de la conception et de l’utilisation des systèmes d’information et peuvent avoir des conséquences organisationnelles qui sortent largement du cadre du service informatique. Elles obligent les utilisateurs à considérer les données comme une ressource de l'entreprise qui doit être gérée comme le sont les ressources traditionnelles (personnel, locaux, moyens de production, capitaux) pour être accessible à un grand nombre d’utilisateurs.

Les bases de données : PRESENTATION

Pourquoi une base de données ?

Une entreprise doit conserver la trace d’un volume élevé d’informations. Ces dernières peuvent être, par exemple, les noms et salaires des employés, les adresses des fournisseurs, le montant des stocks ou le montant des produits de l’exercice.

Traditionnellement, différentes parties de ces informations sont conservées par différents départements et/ou différents individus, chacun ayant la charge des données qu’il utilise le plus souvent. Pour obtenir une information, il faut d’abord déterminer où elle est stockée, puis s’adresser au département ou à la personne concernée.

Les comptables utilisent très fréquemment un grand nombre de données concernant l’entreprise. Quand il prépare les bilans ou un relevé financier, le comptable dispose habituellement de la plupart des informations nécessaires, qui sont le plus souvent contenues dans les grands livres ou les journaux. Cependant, certaines données supplémentaires (en particulier lors de la préparation des budgets), telles que les coûts standards et unitaires, peuvent ne pas apparaître dans ces documents financiers et comptables. Il faut consulter d’autres départements pour obtenir des précisions ou des renseignements supplémentaires.

Les entreprises qui ont informatisé une grande part de leurs fonctions de gestion ont souvent de nombreux programmes d’application différents, chacun ayant un but différent, comme la préparation des bulletins de salaire, la gestion des stocks, la facturation etc. Chacun de ces programmes utilisera vraisemblablement ses propres fichiers contenant les données nécessaires.

Les systèmes manuels ou informatisés en partie ou en totalité que nous venons d’évoquer ont plusieurs défauts majeurs. Dans tous ces systèmes, il peut être nécessaire de s adresser à plusieurs départements avant de trouver celui qui peut effectivement fournir les données. D’autre part, les informations utilisées par plusieurs départements peuvent être conservées en plusieurs endroits, ce qui entraîne une redondance de stockage, Ceci entraîne un gaspillage au niveau du volume des fichiers et des coûts supplémentaires souvent élevés.

En outre, s’il y a redondance dans les données, toute modification doit être faite plusieurs fois, afin de maintenir la cohérence entre les différents fichiers. S’il se produit une erreur, des incohérences peuvent apparaître. Par exemple, le directeur de la production et le directeur des ventes peuvent conserver tous les deux une trace du stock courant d’un article. Au moment de la vente, les deux enregistrements doivent être mis à jour, pour refléter la baisse du stock. Si un des enregistrements indique un stock inférieur ou supérieur à la réalité, il peut en résulter une sous ou surproduction, ou une vente peut être perdue, avec chaque fois un coût supplémentaire pour l’entreprise.

D’autres soucis concernent la sécurité des données et les accès non autorisés à des informations confidentielles. Accéder à l’information est simple s’il suffit pour cela d’ouvrir un tiroir de bureau; cependant, les données stockées dans une application informatisée sont disponibles chaque fois que cette application est utilisée.

Les programmes d'application tendent aussi à utiliser des méthodes de stockage des données assez complexes et l'utilisateur doit souvent se préoccuper de savoir quel format utiliser pour ses données.

Pour ces raisons une tendance s’est développée pour combiner toutes les informations importantes de l’entreprise dans une base de données intégrée. Dans une base de données, le stockage des données est entièrement centralisé. Dans l’idéal, il n’existe qu’un exemplaire de chaque élément de données. Les mises à jour ne sont donc exécutées qu’une seul fois et les problèmes d’incohérence sont limités.

Chaque utilisateur peut ensuite avoir accès aux données spécifiques dont il a besoin. On inclut des mesures de protection pour éviter que quelqu’un puisse accéder à des informations qu’il n’est pas autorisé à connaître (par exemple, les salaires des employés), et pour rendre immédiatement disponibles les données voulues. Chaque département dispose d’un ou plusieurs programmes d’application, pour lire les données, traiter les transactions et effectuer les mises à jour. Les complexités du stockage ne sont pas apparentes pour l’utilisateur, qui n’a connaissance que des données dont il a besoin.