SGBD distribué - Environnements de base de données

Dans cette partie du didacticiel, nous étudierons les différents aspects qui aident à concevoir des environnements de bases de données distribuées. Ce chapitre commence par les types de bases de données distribuées. Les bases de données distribuées peuvent être classées en bases de données homogènes et hétérogènes ayant des divisions supplémentaires. La section suivante de ce chapitre traite des architectures distribuées à savoir client-serveur, peer-to-peer et multi-SGBD. Enfin, les différentes alternatives de conception comme la réplication et la fragmentation sont introduites.

Types de bases de données distribuées

Les bases de données distribuées peuvent être globalement classées en environnements de bases de données distribuées homogènes et hétérogènes, chacun avec des sous-divisions supplémentaires, comme indiqué dans l'illustration suivante.

Bases de données distribuées homogènes

Dans une base de données distribuée homogène, tous les sites utilisent des SGBD et des systèmes d'exploitation identiques. Ses propriétés sont -

  • Les sites utilisent des logiciels très similaires.

  • Les sites utilisent des SGBD ou des SGBD identiques du même fournisseur.

  • Chaque site connaît tous les autres sites et coopère avec d'autres sites pour traiter les demandes des utilisateurs.

  • La base de données est accessible via une interface unique comme s'il s'agissait d'une seule base de données.

Types de base de données distribuée homogène

Il existe deux types de base de données distribuée homogène -

  • Autonomous- Chaque base de données est indépendante et fonctionne seule. Ils sont intégrés par une application de contrôle et utilisent la transmission de messages pour partager les mises à jour des données.

  • Non-autonomous - Les données sont réparties sur les nœuds homogènes et un SGBD central ou maître coordonne les mises à jour des données sur les sites.

Bases de données distribuées hétérogènes

Dans une base de données distribuée hétérogène, différents sites ont différents systèmes d'exploitation, produits SGBD et modèles de données. Ses propriétés sont -

  • Différents sites utilisent des schémas et des logiciels différents.

  • Le système peut être composé d'une variété de SGBD tels que relationnel, réseau, hiérarchique ou orienté objet.

  • Le traitement des requêtes est complexe en raison de schémas différents.

  • Le traitement des transactions est complexe en raison de logiciels différents.

  • Un site peut ne pas être au courant d'autres sites et il y a donc une coopération limitée dans le traitement des demandes des utilisateurs.

Types de bases de données distribuées hétérogènes

  • Federated - Les systèmes de bases de données hétérogènes sont de nature indépendante et intégrés entre eux de sorte qu'ils fonctionnent comme un système de base de données unique.

  • Un-federated - Les systèmes de bases de données utilisent un module de coordination central par lequel les bases de données sont accessibles.

Architectures de SGBD distribuées

Les architectures DDBMS sont généralement développées en fonction de trois paramètres -

  • Distribution - Il indique la répartition physique des données sur les différents sites.

  • Autonomy - Il indique la répartition du contrôle du système de base de données et le degré auquel chaque SGBD constituant peut fonctionner indépendamment.

  • Heterogeneity - Il fait référence à l'uniformité ou à la dissemblance des modèles de données, des composants du système et des bases de données.

Modèles architecturaux

Certains des modèles architecturaux courants sont -

  • Client - Architecture serveur pour DDBMS
  • Architecture peer-to-peer pour DDBMS
  • Architecture multi-SGBD

Client - Architecture serveur pour DDBMS

Il s'agit d'une architecture à deux niveaux où la fonctionnalité est divisée en serveurs et clients. Les fonctions du serveur englobent principalement la gestion des données, le traitement des requêtes, l'optimisation et la gestion des transactions. Les fonctions client incluent principalement l'interface utilisateur. Cependant, ils ont certaines fonctions comme la vérification de la cohérence et la gestion des transactions.

Les deux différentes architectures client-serveur sont -

  • Client multiple de serveur unique
  • Multiple Server Multiple Client (illustré dans le diagramme suivant)

Architecture peer-to-peer pour DDBMS

Dans ces systèmes, chaque pair agit à la fois en tant que client et serveur pour transmettre des services de base de données. Les pairs partagent leurs ressources avec d'autres pairs et coordonnent leurs activités.

Cette architecture comporte généralement quatre niveaux de schémas -

  • Global Conceptual Schema - Représente la vue logique globale des données.

  • Local Conceptual Schema - Représente l'organisation logique des données sur chaque site.

  • Local Internal Schema - Représente l'organisation physique des données sur chaque site.

  • External Schema - Représente la vue utilisateur des données.

Architectures multi-SGBD

Il s'agit d'un système de base de données intégré formé par une collection de deux ou plusieurs systèmes de base de données autonomes.

Le multi-SGBD peut être exprimé à travers six niveaux de schémas -

  • Multi-database View Level - Représente plusieurs vues utilisateur comprenant des sous-ensembles de la base de données distribuée intégrée.

  • Multi-database Conceptual Level - Représente une multi-base de données intégrée qui comprend des définitions de structure de multi-base de données logique globale.

  • Multi-database Internal Level - Représente la distribution des données sur différents sites et multi-base de données vers le mappage de données locales.

  • Local database View Level - Représente la vue publique des données locales.

  • Local database Conceptual Level - Représente l'organisation locale des données sur chaque site.

  • Local database Internal Level - Représente l'organisation physique des données sur chaque site.

Il existe deux alternatives de conception pour le multi-SGBD -

  • Modèle avec niveau conceptuel multi-bases de données.
  • Modèle sans niveau conceptuel multi-bases de données.

Alternatives de conception

Les alternatives de conception de distribution pour les tables dans un DDBMS sont les suivantes:

  • Non répliqué et non fragmenté
  • Entièrement répliqué
  • Partiellement répliqué
  • Fragmented
  • Mixed

Non répliqué et non fragmenté

Dans cette alternative de conception, différentes tables sont placées sur différents sites. Les données sont placées de manière à être à proximité immédiate du site où elles sont le plus utilisées. Il convient le mieux aux systèmes de base de données où le pourcentage de requêtes nécessaires pour joindre des informations dans des tables placées sur différents sites est faible. Si une stratégie de distribution appropriée est adoptée, cette alternative de conception permet de réduire le coût de communication pendant le traitement des données.

Entièrement répliqué

Dans cette variante de conception, sur chaque site, une copie de toutes les tables de la base de données est stockée. Étant donné que chaque site possède sa propre copie de l'ensemble de la base de données, les requêtes sont très rapides nécessitant un coût de communication négligeable. Au contraire, la redondance massive des données nécessite un coût énorme lors des opérations de mise à jour. Par conséquent, cela convient aux systèmes où un grand nombre de requêtes doit être traité alors que le nombre de mises à jour de la base de données est faible.

Partiellement répliqué

Des copies de tables ou de parties de tables sont stockées sur différents sites. La distribution des tableaux se fait en fonction de la fréquence d'accès. Cela tient compte du fait que la fréquence d'accès aux tableaux varie considérablement d'un site à l'autre. Le nombre de copies des tables (ou portions) dépend de la fréquence d'exécution des requêtes d'accès et du site qui génère les requêtes d'accès.

Fragmenté

Dans cette conception, une table est divisée en deux ou plusieurs éléments appelés fragments ou partitions, et chaque fragment peut être stocké sur différents sites. Cela tient compte du fait qu'il arrive rarement que toutes les données stockées dans une table soient requises sur un site donné. De plus, la fragmentation augmente le parallélisme et offre une meilleure reprise après sinistre. Ici, il n'y a qu'une seule copie de chaque fragment dans le système, c'est-à-dire pas de données redondantes.

Les trois techniques de fragmentation sont -

  • Fragmentation verticale
  • Fragmentation horizontale
  • Fragmentation hybride

Distribution mixte

Il s'agit d'une combinaison de fragmentation et de réplications partielles. Ici, les tableaux sont initialement fragmentés sous n'importe quelle forme (horizontale ou verticale), puis ces fragments sont partiellement répliqués sur les différents sites en fonction de la fréquence d'accès aux fragments.