Bases de données

OBJECTIFS DES SGBD

Le principal objectif d’un SGBD est d’assurer l’indépendance des programmes aux données, c’est-à-dire la possibilité de modifier les schémas conceptuel et interne des données sans modifier les programmes d’applications, et donc les schémas externes vus par ces programmes. Cet objectif est justifié afin d’éviter une maintenance coûteuse des programmes lors des modifications des structures logiques (le découpage en champs et articles) et physiques (le mode de stockage) des données. Plus précisément, on distingue l’indépendance physique qui permet de changer les schémas internes sans changer les programmes d’applications, et l’indépendance logique qui permet de modifier les schémas conceptuels (par exemple, ajouter un type d’objet) sans changer les programmes d’applications. Afin d’assurer encore une meilleure indépendance des programmes aux données est rapidement apparue la nécessité de manipuler (c’est-à-dire d’interroger et de mettre à jour) les données par des langages de haut niveau spécifiant celles que l’on veut traiter (le quoi) et non pas comment y accéder. Ainsi, les procédures d’accès aux données restent invisibles aux programmes d’application qui utilisent donc des langages non procéduraux. Ces langages référencent des descriptions logiques des données (les schémas externes) stockées dans le dictionnaire de données. Les descriptions de données, qui existent à plusieurs niveaux introduits ci-dessus, sont établies par les administrateurs de données. Un SGBD se doit donc de faciliter l’administration (c’est-à-dire la création et la modification de la description) des données. En résumé, voici les objectifs premiers d’un SGBD : – Indépendance physique des programmes aux données – Indépendance logique des programmes aux données – Manipulation des données par des langages non procéduraux – Administration facilitée des données. Les SGBD conduisent à mettre en commun les données d’une entreprise, ou au moins d’une application dans une base de données décrite par un dictionnaire de données. Cette mise en commun ne va pas sans problèmes d’efficacité: de nombreux utilisateurs accèdent simultanément aux données souvent situées sur un même disque. La base de données devient ainsi un goulot d’étranglement. Il faut assurer globalement l’efficacité des accès. Il faut aussi garantir les utilisateurs contre les mises à jour concurrentes, et donc assurer le partage des données. L’environnement multi-usager nécessite de protéger la base de données contre les mises à jour erronées ou non autorisées: il faut assurer la cohérence des données. Notamment, des données redondantes doivent rester égales. Enfin, en cas de panne système, ou plus simplement d’erreurs de programmes, il faut assurer la sécurité des données, en permettant par exemple de repartir sur des versions correctes. En résumé, voici les objectifs additionnels des SGBD, qui sont en fait des conséquences des objectifs premiers :
–Efficacité des accès aux données – Partage des données – Cohérence des données – Redondance contrôlée des données – Sécurité des données. Dans la pratique, ces objectifs ne sont que très partiellement atteints. Ci-dessous nous analysons plus précisément chacun d’eux.

INDÉPENDANCE PHYSIQUE

Bien souvent, les données élémentaires du monde réel sont assemblées pour décrire les objets et les associations entre objets directement perceptibles dans le monde réel. Bien que souvent deux groupes de travail assemblent différemment des données élémentaires, il est possible au sein d’une entreprise bien organisée de définir une structure canonique des données, c’est-à-dire un partitionnement en ensembles et sous ensembles ayant des propriétés bien définies et cohérentes avec les vues particulières. Cet assemblage peut être considéré comme l’intégration des vues particulières de chaque groupe de travail. Il obéit à des règles qui traduisent l’essentiel des propriétés des données élémentaires dans le monde réel. Il correspond au schéma conceptuel d’une base de données. Par opposition, la structure de stockage des données appartient au monde des informaticiens et n’a donc un sens que dans l’univers du système informatique. Le schéma interne décrit un assemblage physique des données en articles, fichiers, chemins d’accès (organisation et méthode d’accès des fichiers, modes de placement des articles dans les fichiers, critères de tri, chaînages…) sur des mémoires secondaires. Cet assemblage propre au monde informatique doit être basé sur des considérations de performances et de souplesse d’accès. Un des objectifs essentiels des SGBD est donc de permettre de réaliser l’indépendance des structures de stockage aux structures de données du monde réel [Stonebraker74], c’est-à-dire entre le schéma interne et le schéma conceptuel. Bien sûr, ces deux schémas décrivent les mêmes données, mais à des niveaux différents. Il s’agit donc de pouvoir modifier le schéma interne sans avoir à modifier le schéma conceptuel, en tenant compte seulement des critères de performance et de flexibilité d’accès. On pourra par exemple ajouter un index, regrouper deux fichiers en un, changer l’ordre ou le codage des données dans un article, sans mettre en cause les entités et associations définies au niveau conceptuel. Les avantages de l’indépendance physique peuvent être facilement compris si l’on considère les inconvénients de la non-indépendance physique. Celle-ci impliquerait que la manière dont les données sont organisées sur mémoire secondaire soit directement l’image de l’organisation canonique de données dans le monde réel. Pour permettre de conserver les possibilités d’optimisation de performances vitales aux systèmes informatiques, les notions de méthodes d’accès, modes de placement, critères de tri, chaînages et codages de données devraient directement apparaître dans le monde réel et donc dans les applications. Tout changement informatique devrait alors être répercuté dans la vie d’une entreprise et par conséquent impliquerait une reconstruction des applications. Cela est bien sûr impraticable, d’où la nécessité d’indépendance des structures de stockages aux données du monde réel.

INDÉPENDANCE LOGIQUE

Nous avons admis ci-dessus l’existence d’un schéma conceptuel modélisant les objets et associations entre objets dans le monde réel. Ce schéma résulte d’une synthèse des vues particulières de chaque groupe de travail utilisant la base de données, c’est-à-dire d’une intégration de schémas externes. En conséquence, chaque groupe de travail réalisant une application doit pouvoir assembler différemment les données pour former par exemple les entités et les associations de son schéma externe, ou plus simplement des tables qu’il souhaite visualiser. Ainsi, chacun doit pouvoir se concentrer sur les éléments constituant son centre d’intérêt, c’est-à-dire qu’un utilisateur doit pouvoir ne connaître qu’une partie des données de la base au travers de son schéma externe, encore appelé vue. Il est donc souhaitable de permettre une certaine indépendance des données vues par les applications à la structure canonique des données de l’entreprise décrite dans le schéma conceptuel. L’indépendance logique est donc la possibilité de modifier un schéma externe sans modifier le schéma conceptuel. Elle assure aussi l’indépendance entre les différents utilisateurs, chacun percevant une partie de la base via son schéma externe, selon une structuration voire un modèle particulier. Les avantages de l’indépendance logique [Date71] sont les suivants : – permettre à chaque groupe de travail de voir les données comme il le souhaite ; – permettre l’évolution de la vue d’un groupe de travail (d’un schéma externe) sans remettre en cause, au moins dans une certaine mesure, le schéma conceptuel de l’entreprise ; – permettre l’évolution d’un schéma externe sans remettre en cause les autres schémas externes. En résumé, il doit être possible d’ajouter des attributs, d’en supprimer d’autres, d’ajouter et de supprimer des associations, d’ajouter ou de supprimer des entités, etc., dans des schémas externes mais aussi dans le schéma conceptuel sans modifier la plus grande partie des applications.

MANIPULATION DES DONNÉES PAR DES LANGAGES NON PROCÉDURAUX

Les utilisateurs, parfois non professionnels de l’informatique, doivent pouvoir manipuler simplement les données, c’est-à-dire les interroger et les mettre à jour sans préciser les algorithmes d’accès. Plus généralement, si les objectifs d’indépendance sont atteints, les utilisateurs voient les données indépendamment de leur implantation en machine. De ce fait, ils doivent pouvoir manipuler les données au moyen de langages non procéduraux, c’est-à-dire en décrivant les données qu’ils souhaitent retrouver (ou mettre à jour) sans décrire la manière de les retrouver (ou de les mettre à jour) qui est propre à la machine. Les langages non procéduraux sont basés sur des assertions de logique du premier ordre. Ils permettent de définir les objets désirés au moyen de relations entre objets et de propriétés de ces objets. Deux sortes d’utilisateurs manipulent en fait les bases de données : les utilisateurs interactifs et les programmeurs. Les utilisateurs interactifs peuvent interroger voire mettre à jour la base de données. Ils sont parfois non informaticiens et réclament des langages simples. De tels langages peuvent être formels (logique du premier ordre) ou informels (menus). Une large variété de langages interactifs doivent être supportés par un SGBD, depuis les langages de commandes semi-formels jusqu’aux langages graphiques, en passant par l’interrogation par menus ou par formes. La limite supérieure de tels langages est le langage naturel, qui reste cependant en général trop complexe et lourd pour interroger les bases de données. Les programmeurs écrivent des programmes en utilisant des langages traditionnels dits de 3e génération (C, COBOL, PL1, etc.), des langages plus récents orientés objet tels C++ ou Java ou des langages de 4e génération (VB, PL/SQL, FORTÉ, etc.). Ces derniers regroupent des instructions de programmation structurée (WHILE, IF, CASE, etc.), des expressions arithmétiques, des commandes d’accès à la base de données et des commandes d’édition et entrée de messages (menus déroulants, gestion de fenêtres, rapports imprimés, etc.). Ils sont de plus en plus souvent orientés objets. Dans tous les cas, il est important que le SGBD fournisse les commandes nécessaires de recherche et mise à jour de données pour pouvoir accéder aux bases. Une intégration harmonieuse avec le langage de programmation, qui traite en général un objet à la fois, est souhaitable.