Chapitre 1 : objectifs des
bases de données
Les Bases de Données occupent
aujourd'hui une place de plus en plus importante dans les systèmes informatiques.
Les Systèmes de Gestion de Bases de Données (SGBD)
remplacent les anciennes organisations où les données, regroupées
en fichiers, restaient liées à une application particulière.
Ils assurent le partage, la cohérence, la sécurité d'informations
qui, de plus en plus, constituent le noyeau de l'entreprise. Des premiers modèles
hiérarchique et réseau au modèle relationnel, du mainframe
au micro, du centralisé au réparti, les ambitions des SGBD
augmentent d'année en année. Mais à quoi peuvent bien ressembler
ces logiciels de plusieurs dizaines de milliers de lignes de code qui gèrent
avec une relative facilité quelques milliards d'octets d'information
?
I.1. Le principe d'un modèle
de données
Dès 1965 apparaît l'idée
de distinguer les données de leurs traitements. Cela exige une description
préalable des données qui doit être fournie par les utilisateurs.
Pour bien comprendre cela, observons
le travail que devait réaliser le programmeur et que le système
doit maintenant prendre en charge : le programmeur devait transformer en structures
informatiques une certaine vision de la réalité (par exemple une
personne est stockée sous la forme d'un enregistrement composé
d'un champ "numéro de sécurité sociale", d'un champ "nom",
d'un champ "prénom" et d'un champ "date de naissance"). C'est à
présent le SGBD qui va effectuer ce travail : il
recevra en entrée une description abstraite des données.
Disposant de règles déclarées par l'administrateur, il
choisira la façon de les stocker et de gérer les accès.
Les outils offerts par le SGBD
pour décrire les données qu'il aura à stocker repose sur
un ensemble de règles et de concepts permettant de décrire le
monde réel (en fait une toute petite partie du monde réel : celle
sur laquelle portent les traitements). Ces règles et concepts constituent
un modèle de données. Le modèle entité-association
peut ici être donné à titre d'exemple.
I.2. Pourquoi des bases de données
?
Comme c'est le cas pour de nombreuses
innovations technologiques, une importante pression des besoins est à l'origine
de l'émergence des Systèmes de Gestion de Bases de Données.
Dans l'environnement informatique traditionnel des gros systèmes d'exploitation,
le seul mode de gestion de données reste le gestionnaire de fichiers. Les
données traitées par une application (gestion de la paie, des stocks,
de la comptabilité, des locaux…) demeurent spécifiques à
cette application.
L'organisation des données
en fichiers telle qu'elle est traditionnellement conçue répond
à des besoins précis : les services utilisent des informations
le plus souvent distinctes pour des traitements différents. Pour cette
raison, chaque équipe de l'entreprise dispose de ses propres fichiers
de données où ne figurent que les informations la concernant.
La forme sous laquelle cette information est stockée dépend de
facteurs nombreux et variés : matériel disponible, bonne volonté
et harmonisation des équipes de développement (choix du langage
de programmation, choix de la structure de stockage…) ; surtout, les accès
à l'information déterminent le plus souvent l'organisation choisie
pour les données : le choix des informations regroupées dans un
même fichier, le choix de l'organisation du fichier (séquentiel,
aléatoire…).
Dans ce contexte, on constate l'apparition
de nombreuses difficultés :
Redondance des données
La répétition en
différents endroits de données identiques pose de difficiles
problèmes lors des mises à jour ; chaque modification doit être
répercutée sur toutes les occurrences de l'objet concerné.
Par exemple, le changement de nom d'un employé (c'est fréquemment
le cas lors des mariages) doit être effectué aussi bien au service
du personnel qu'à la comptabilité, etc.
Difficulté d'accès
aux données
L'accès aux données
nécessite l'intervention d'un informaticien (nécessité
de connaître la machine où résident les informations,
les structures utilisées pour stocker ces informations, les chemins
d'accès disponibles…). La seule manipulation possible d'informations
stockées sur fichiers est une manipulation "programmée" ; les
informations sont en effet décrites de façon très physique
et ne permettent pas un niveau d'abstraction suffisant pour envisager une
interrogation directe et interactive par un utilisateur final non spécialiste.
Problèmes de partage des
données
Le problème est bien connu
des concepteurs de systèmes d'exploitation : comment réagir
à plusieurs ouvertures simultanées d'un même fichier.
Des problèmes identiques se posent dès que plusieurs utilisateurs
désirent effectuer des modifications sur les mêmes données.
De surcroît, l'existence de plusieurs occurrences d'une même donnée
en plusieurs endroits (plusieurs fichiers différents) provoque une
complexité accrue si le système doit garantir la cohérence
pour des utilisateurs manipulant la même information au même moment.
Risques d'incohérence
Des liens sémantiques
existent très souvent entre les données : le poste d'un employé,
figurant dans le fichier du service du personnel, n'est pas sans rapport avec
le salaire qui lui est versé par la comptabilité. Pourtant la
modification de l'un n'entraîne pas automatiquement celle de l'autre.
De telles situations nécessitent souvent force courrier et coups de
téléphone ; des incohérences apparaissent trop fréquemment
du fait de la difficulté et du coût qu'implique le contrôle
de "contraintes d'intégrité" liant les données entre
elles.
Problèmes de sécurité
Garantir de la sécurité
physique de l'information est une des tâches de base d'un système
informatique. Qu'arrive-t-il si une panne interrompt un programme augmentant
tous les salaires de 3% ? Combien de modifications ont été prises
en compte ; où reprendre le travail ? La présence de la même
information en plusieurs exemplaires n'est évidemment pas de nature
à faciliter la tâche du SGBD et des programmes de reprise après
panne. De même, la confidentialité de l'information est plus
facile à assurer avec une seule occurrence de l'information à
protéger.
Manque de portabilité des
applications
Que se passe-t-il lorsque l'on
change de système d'exploitation ou de support de stockage ? Dans la
plupart des cas, les applications développées sont si fortement
liées aux possibilités propres du système et du gestionnaire
de fichiers qu'il est parfois aussi difficile de les actualiser que de les
réécrire entièrement. Si la normalisation des langages
de programmation est de plus en plus fréquente, les accès aux
fichiers dépendent la plupart du temps de la machine ; le manque de
séparation entre le code de l'interface et celui du traitement des
données interdit de faire une simple modification du code.
Problèmes de maintenance
Enfin, quand la modification
de la structure des données manipulées devient nécessaire,
il faut assurer le passage des données depuis les anciennes vers les
nouvelles structures choisies et presque toujours réécrire complètement
les programmes d'application dont la plupart réalisent pourtant la
même opération qu'auparavant.
Au total, les organisations traditionnelles
des données sous la forme de fichiers liés aux applications présentent
de sérieux inconvénients dès qu'un ensemble de programmes
manipulent et partagent des informations qui ne sont pas complètement indépendantes.
Le défaut de base des organisations traditionnelles provient du fait que
les données et les traitements ne sont pas explicitement séparés.
L'ancienne vision du monde faisait en effet tourner les données autour
des traitements. Aujourd'hui, on sait que le centre du monde est constitué
par l'information manipulée (les données dont elle est constituée)
: le centre c'est le système d'information de l'entreprise !
Une bonne solution à ces problèmes
passe par le regroupement et l'unicité des données, ainsi que
par la centralisation des moyens de gestion de ces données. L'administration
unique et centralisée des données à l'échelle de
l'entreprise garantit la cohérence de l'information et permet l'indépendance
des programmes et des données . Elle est mise en pratique par un
Système de Gestion de Bases de Données (SGBD).
L'ensemble de toutes les données
peut être regroupé sous l'appellation de base de données.
Cette base de données représente l'information de l'entreprise.
Elle existe indépendamment de l'usage qu'en font les programmes d'application
ou les utilisateurs finals. L'information doit donc pouvoir être décrite
indépendamment de l'usage qui en est fait. Cette description nécessite
un modèle de données, c'est à dire un ensemble de
concepts et de règles assez généraux et riches de sémantique
pour pouvoir donner de façon formelle un schèma de la structure
permanente de cette information.
Le système logiciel qui met
en œuvre le modèle de données (qui stocke les données,
gère les accès, les droits des utilisateurs, et plus généralement
traite au mieux l'ensemble des problèmes que nous venons d'évoquer)
forme véritablement le SGBD.
I.2.1. Le modèle entité-association
Ce modèle de données correspond
à une modélisation assez naturelle du monde réel. Le modèle
se compose de trois concepts élémentaires : l'entité, l'association
et les contraintes portant sur ces associations.
Une entité peut être
:
- un objet du monde réel
;
- des données composées ;
- un ensemble d'entités.
Une association peut être :
- un lien entre entités
;
- un ensemble d'associations.
Une contrainte peut être :
- une propriété
précisant le nombre d'entités qu'une association peut unir.
On parle alors de cardinalité d'association qui peut être de
type 1-1, 1-N, ou N-M ;
- une propriété propre à l'association et sans rapport
avec les entités rapprochées par ces associations.
Ce modèle est mis en œuvre par
un langage de description. Ce langage est ici graphique :
Exprimons avec ce modèle la
réalité suivante : des nageurs, dont les caractéristiques
sont un nom, un prénom et une qualité, prennent des bains d'une
certaine durée à une certaine date, sur certaines plages dont
les caractéristiques sont le nom le la plage, la région et la
pollution :
Le schéma entité/association
est le suivant :
Les contraintes à définir
(dont les cardinalités d'association) posent, par exemple, les problèmes
suivants :
- un baigneur peut-il prendre
plusieurs bains? sur des plages différentes?
- une ou plusieurs personnes
peuvent-elles se baigner sur une plage très polluée ?
- autorise-t-on les mauvais nageurs
à se baigner sur une plage des Landes ?
I.2.2. Modèles, langages
et schémas
Plus généralement, nous
dirons que le modèle de données est un mode de formalisation du
monde réel. Il doit permettre la description et la représentation
:
- des entités et des données
qui les constituent ;
- des liens (association, relations, correspondances) qui les relient ;
- de certaines assertions (propriétés ou contraintes d'intégrité)
que doivent vérifier les données de la base.
Définition : modèle
de données
un modèle de données
est l'ensemble des concepts et des règles de composition qui permettent
de décrire les données.
Définition : langage de
description
un langage de description est
un langage supportant un modèle de données et permettant de
définir ces données.
Définition : schéma
Un schéma est la description
au moyen d'un langage déterminé d'un ensemble particulier de
données.
Un Système de Gestion de Bases
de Données est donc un système logiciel qui met en œuvre un modèle
de données particulier et qui offre des outils de définition et
de manipulation de données à des utilisateurs possédant des
connaissances plus ou moins approfondies sur le modèle et sur le logiciel
: administrateur, développeurs d'applications ou utilisateurs finals non
spécialistes.
Les principaux modèles de
données sur lesquels s'appuient les SGBD sont le
modèle hiérarchique, le modèle réseau, et le modèle
relationnel que nous examinerons ultérieurement.
I.3. Précisions sur les
niveaux de description
La description des données peut
s'effectuer à plusieurs niveaux d'abstraction qu'on appelle niveaux de
description et de schémas.
Le premier niveau concerne la réalité
informatique. C'est l'administrateur de la base de données qui effectue
ce travail. Les objets décrits sont ici l'environnement matériel
et système (organisation et partitionnement du disque, système
d'exploitation…), les fichiers (nom, taille, organisation…), les articles (nom,
longueur, placement…), les champs (nom, format, localisation…), les chemins
d'accès (clé, lien, type…).
Le second permet la description conceptuelle.
La réalité au niveau de toute l'entreprise y est décrite.
L'administrateur ou l'utilisateur donne une vue canonique des données
: c'est de ce schéma, unique, que seront dérivées différentes
vues externes. Les objets décrits restent ici abstraits : entité
(nom, attributs…), association (nom, cardinalité…), contrainte (objet,
assertion…), etc.
Enfin le niveau externe permet de
décrire plusieurs visions différentes d'une même réalité
(le schéma conceptuel); chacune de ces visions correspondra à
une application ou à un groupe particulier d'utilisateurs (service du
personnel, service de comptabilité, comité d'entreprise…). Le
niveau d'abstraction de la description est ici le même que celui du niveau
conceptuel.
Des règles de correspondance
sont utilisées pour transformer les données d'un niveau de schéma
dans un autre. Ces règles sont en général fixées
par l'administrateur et permettent de libérer l'utilisateur des contraintes
liées à "l'informatique profonde".
Historiquement, c'est en 1971, qu'une
recommandation du DBTG-CODASYL (DB Task Group) isolait
un niveau interne (spécialisé dans le stockage et l'accès
aux informations) et un niveau externe, proche de l'utilisateur, qui gère
les rapports avec les programmes d'application. La recommandation de trois niveaux
(interne, conceptuel et externe) date de 1979.
Dans cette introduction, nous ne
nous préoccupons que peu du niveau interne (voir cependant le chapitre
7 qui présente différentes possibilités d'implantation
physique des données dans un SGBD), mais nous pouvons profiter de ce
paragraphe pour en dire quelques mots.
Précisons en effet qu'un SGBD
gère des milliards d'octets de données et que, pour ce faire,
il n'utilise pas les structures de données offertes par les langages
de programmation (tels l'article en Pascal ou la structure en C). Il n'utilise
pas non plus, en général, les fichiers offerts par les systèmes
d'exploitation pour stocker les informations sur disque ; il préfère
utiliser ses propres techniques de stockage. Un SGBD réserve une partie
du disque et de la mémoire, y manipule des pages mémoire (chargement,
déchargement, lecture, écriture) grâce aux primitives de
bas niveau offertes par le système d'exploitation. Sur ces pages mémoire,
l'information est vue comme une suite d'octets dont l'organisation est connue
du système qui sait ainsi lire les informations stockées.
Dans l'avenir nous n'aborderons plus
les détails de structure de cette couche interne, mais il faut garder
à l'esprit qu'un SGBD, à son plus bas niveau, ne fait que lire
ou écrire des pages mémoire. Il a de telles quantités de
données à manipuler qu'il doit mettre en œuvre le maximum de techniques
pour diminuer le nombre d'entrées/sorties nécessaires. Ces méthodes,
que nous nous bornerons à présenter rapidement dans ces chapitres,
s'appellent optimisation de requêtes, méthodes de stockage, etc.
I.4. Les objectifs des SGBD
De façon plus formalisée,
voici reprise et complétée la liste des objectifs des SGBD.
I.4.1. Offrir différents
niveaux d'abstraction
Niveau physique :
Ce niveau appelé aussi
niveau interne, gère le stockage et l'accès aux données.
Il n'y a qu'un seul niveau physique par SGBD.
Niveau conceptuel :
C'est à ce niveau, également
appelé le niveau logique, que l'on parle de modèle (conceptuel)
de données. Ce modèle décrit l'ensemble des données
de l'entreprise. La description conceptuelle d'une base de données
- BD - est unique.
Niveau vue :
C'est le plus haut niveau d'abstraction
de la base de données. Il est aussi appelé niveau externe et
est propre à un utilisateur ou à un groupe d'utilisateurs et
ne lui présente qu'une vue partielle de la réalité :
celle qui intéresse son service. Il y a bien entendu plusieurs vues
d'une même BD.
I.4.2. Assurer l'indépendance
physique des données
Le but est ici de permettre à
l'utilisateur du niveau conceptuel d'ignorer la structure du niveau physique.
Cela nécessite une transformation entre niveau logique et physique, mais
présente deux avantages considérables :
- les programmes d'applications
sont plus simples à écrire, du fait de ne pas avoir à
manipuler des entités complexes (structures d'enregistrement, méthodes
d'accès…) ;
- dans le cas d'une modification
des caractéristiques du niveau physique, les applications n'ont pas
à être modifiées.
I.4.3. Assurer l'indépendance
logique des données
Le but est ici de permettre à
l'utilisateur du niveau vue (typiquement les programmeurs d'application ou les
utilisateurs finals) d'ignorer la structure du niveau conceptuel. Cela nécessite
une transformation entre niveau externe et conceptuel, mais offre là encore
deux avantages de poids :
- les programmes d'applications
du niveau externe n'ont pas à avoir la vision globale de toute l'entreprise.
Ils agissent à partir des vues ;
- les applications du niveau
externe, en cas d'une modification du schéma au niveau conceptuel,
ne sont à réécrire que si cette modification entraîne
celle de la vue, ce qui est rarement le cas.
I.4.4. Contrôler la
redondance des données
Un des objectifs de base des SGBD,
la suppression de la redondance des données, vise à garantir la
cohérence de l'information et à simplifier les mises à jour.
Cependant, la redondance est parfois nécessaire pour garantir la fiabilité
et les performances, ou pour la répartition des données.
Les données sont réparties
quand plusieurs SGBD situés sur des sites distincts
reliés par un réseau partagent les informations dont ils disposent.
Posséder certaines informations sur tous les sites est alors parfois
indispensable (par exemple la description des données présentes
sur les différents sites pour savoir où, comment, et dans quel
ordre aller les chercher en cas de besoin).
En conséquence, la redondance
anarchique des données doit être éliminée et la redondance
existante doit être contrôlée en propageant la mise à
jour d'une donnée redondante.
I.4.5. Permettre à
tout type d'utilisateur de manipuler des données
Le but est d'offrir aux différents
types d'utilisateurs des moyens d'accès à la base adaptés
à leurs besoins et à leurs connaissances. Nous devrons ainsi distinguer
:
- un ou plusieurs administrateur
de la base qui doivent pouvoir décrire les données aux niveaux
physique (administrateur BD et ingénieur système)
et conceptuel (administrateur BD et concepteur) ;
- un ou plusieurs développeur
d'applications qui écrivent, à partir du niveau conceptuel
ou des niveaux externes, des programmes d'application pour eux-mêmes
ou pour les utilisateurs finals ;
- un ou plusieurs utilisateur
final ont besoin d'un langage simple (si possible proche du langage naturel)
pour manipuler les données de manière interactive ou à
partir de programmes d'application.
I.4.6. Assurer l'intégrité
des données
L'intégrité logique de
l'information est souvent vérifiée par les programmes d'applications
dans les organisations traditionnelles à bases de fichiers. Dans une approche
base de données, elle fait partie de la description de la réalité
conceptuelle du système d'information. La vérification de l'intégrité
est une composante du modèle de données et une tâche du SGBD
qui le met en œuvre. L'intégrité sémantique correspond à
des règles explicitant des contraintes du monde réel.
Nous pouvons donner comme exemple
:
- il est interdit et impossible
de se baigner sur une plage très polluée ;
- un baigneur ne peut pas se baigner sur une plage non recensée ;
- un baigneur ne peut pas se baigner à Binic en mars.
Toute requête de mise à
jour des données (insertion, modification ou suppression) ne respectant
pas l'ensemble des contraintes d'intégrité doit être rejetée
par le SGBD.
I.4.7. Assurer le partage
des données
Composant transactionnel d'un système
informatique, un SGBD doit permettre le partage des données entre différents
utilisateurs et applications. Un utilisateur n'a pas à se demander si quelqu'un
d'autre travaille sur les mêmes informations au même moment et doit
pouvoir accéder aux données en consultation ou en mise à
jour comme s'il était seul : le système doit gérer les conflits,
en refusant ou en retardant éventuellement un ou plusieurs accès.
I.4.8. Assurer la sécurité
des données
Cela consiste à protéger
les données contre les pannes et à refuser les accès aux
personnes non autorisées. Le système doit présenter un mécanisme
de vérification des droits d'accès aux objets de la base. Il doit
garantir des reprises après panne en restaurant la base de données
dans le dernier état cohérent avant la panne. La fiabilité
est traditionnellement sur les gros systèmes mise en œuvre des techniques
très sophistiquées. La qualité de l'implantation de ces techniques
a d'importantes conséquences sur les performances en cas d'utilisation
intensive.
I.4.9. Optimiser l'accès
aux données
En permettant aux utilisateurs d'ignorer
les structures physiques et les chemins d'accès à l'information,
le SGBD prend à sa charge un lourd travail d'optimisation.
En utilisant les meilleurs chemins d'accès, mais aussi le parallélisme
ou des algorithmes de recherche sophistiqués, il permettra de minimiser
le volume des données accédées et le temps d'exécution
des questions.
I.5. Conclusions
Cette introduction nous a permis de
présenter les motivations et les buts des Systèmes de Gestion de
Bases de Données. Placés ici sur un pied d'égalité,
les différents objectifs sont atteints à des degrés divers
: les aspects transactionnels (concurrence, sécurité physique,…)
sont bien implantés et assurent aujourd'hui une efficacité très
importante aux systèmes utilisés en production et destinés
à écouler un nombre important de transactions par seconde ; les
indépendances physique - conceptuel / interne - et logique - externe /
conceptuel - sont bien assurées par les systèmes relationnels, mais
mal ou pas du tout dans les produits s'appuyant sur les modèles réseau
ou hiérarchique ; la détermination par les systèmes des meilleurs
algorithmes et chemins d'accès aux données ont fait faire des progrès
considérables aux méthodes d'accès des systèmes informatiques
modernes ; la vérification automatique des contraintes d'intégrité
générales est, en revanche, encore peu implantée dans les
produits.
I.6. Références
[ANSI 75]
ANSI/X3/SPARC Study Group On Data Management Systems "Interim
Report" ACM SIGMOD bulletin 7, N°2, 1975.
[Chen 76] CHEN P. P.
: "The Entity-Relationship Model-Toward a Unified View of Data",
ACM Transactions on Data Base Systems, V1, N°11,
March 1976.
Chapitre 2