4. Les composants de l'architecture d'un système de bases de données
145
dans le journal de transaction qui détermine pour chaque objet son
état le plus récent.
Importance de la
prévention des
sinistres
L'expert en bases de données est chargé de mettre en œuvre un
plan de reprise après sinistre qui définit clairement des procédures en
vue de garantir la sécurité des bases de données. En principe, il faut
maintenir un certain degré de redondance en créant plusieurs
générations de copies de sauvegarde physiquement séparées. La
disponibilité des copies d'archive et l'élimination des versions
obsolètes doivent être journalisées de manière systématique. En cas
de panne ou lors des simulations de sinistre, cela permet de restaurer
l’ensemble des données courantes dans un délai convenable à partir
des copies de sauvegarde d'une part, et des modifications archivées de
la base de données d'autre part.
4.6 Architecture détaillée du système
Nécessaire
indépendance des
différentes couches
du système
Le principe de localité des modifications et des extensions
futures est fondamental à l'architecture interne des systèmes de bases
de données. Comme dans l'implantation des systèmes d'exploitation
ou d'autres composants logiciels, les systèmes de bases de données
relationnelles sont conçus d'après une architecture en plusieurs
couches indépendantes qui communiquent entre elles au travers
d'interfaces prédéfinies.
La figure 4-15 donne une vue d'ensemble de l'architecture du
système, décomposée en cinq niveaux. Nous énumérons ci-après les
fonctions essentielles de chaque couche, qui ont été traitées dans les
sections précédentes.
Couche de
traduction et
d’optimisation des
requêtes
Couche 1 : Interface orientée ensemble
La première couche gère la définition des structures de données,
la mise au point des opérations sur les ensembles, la spécification des
conditions d'accès et la vérification des contraintes de cohérence (voir
4.2). La correction syntaxique, la résolution des noms et la
détermination des chemins d'accès doivent s'effectuer, soit par
anticipation lors de la traduction et de la génération des modules
145
dans le journal de transaction qui détermine pour chaque objet son
état le plus récent.
Importance de la
prévention des
sinistres
L'expert en bases de données est chargé de mettre en œuvre un
plan de reprise après sinistre qui définit clairement des procédures en
vue de garantir la sécurité des bases de données. En principe, il faut
maintenir un certain degré de redondance en créant plusieurs
générations de copies de sauvegarde physiquement séparées. La
disponibilité des copies d'archive et l'élimination des versions
obsolètes doivent être journalisées de manière systématique. En cas
de panne ou lors des simulations de sinistre, cela permet de restaurer
l’ensemble des données courantes dans un délai convenable à partir
des copies de sauvegarde d'une part, et des modifications archivées de
la base de données d'autre part.
4.6 Architecture détaillée du système
Nécessaire
indépendance des
différentes couches
du système
Le principe de localité des modifications et des extensions
futures est fondamental à l'architecture interne des systèmes de bases
de données. Comme dans l'implantation des systèmes d'exploitation
ou d'autres composants logiciels, les systèmes de bases de données
relationnelles sont conçus d'après une architecture en plusieurs
couches indépendantes qui communiquent entre elles au travers
d'interfaces prédéfinies.
La figure 4-15 donne une vue d'ensemble de l'architecture du
système, décomposée en cinq niveaux. Nous énumérons ci-après les
fonctions essentielles de chaque couche, qui ont été traitées dans les
sections précédentes.
Couche de
traduction et
d’optimisation des
requêtes
Couche 1 : Interface orientée ensemble
La première couche gère la définition des structures de données,
la mise au point des opérations sur les ensembles, la spécification des
conditions d'accès et la vérification des contraintes de cohérence (voir
4.2). La correction syntaxique, la résolution des noms et la
détermination des chemins d'accès doivent s'effectuer, soit par
anticipation lors de la traduction et de la génération des modules