WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Mise en oeuvre d'un système distribué pour l'identification et le suivi du casier judiciaire

( Télécharger le fichier original )
par Juslin TSHIAMUA MUDIKOLELE
Université pédagogique nationale - Licence 2016
  

précédent sommaire suivant

II.7.4.2. SGBDR homogène

Toutes les BD suivent un même schéma et utilisent la même technologie (ex: Oracle). L'accès aux données ainsi quela gestion des transactions réparties sont souvent faits de manière centralisée. En plus, cette architecture présente une plus grande fiabilité et performance dû à un meilleur couplage entre les sites.

Figure 16: Architecture répartie avec SGBD répartis homogènes

II.7.4.3. Multi-SGBD réparti

Dans cette architecture, chaque site est autonome et peut avoir un SGBD de type différent. Ce qui conduit à l'utilisation des interfaces (ex: schéma conceptuel) différentes et cela peut devenir très complexe à gérer.

Le Multi-Système de gestion de bases de données peut être exprimé par six niveaux des schémas :

§ Niveau De Vue Multi-base de données : Dépeint des vues multiples d'utilisateur comportant des sous-ensembles de la base de données répartie intégrée.

§ Niveau Conceptuel Multi-base de données :Dépeint la multi-base de données intégrée qui comporte des définitions logiques globales de structure de multi-base de données.

§ Niveau Interne Multi-base de données :Dépeint la distribution de données à travers différents emplacements et la multi-base de données aux données locales traçant.

§ Niveau local de vue de base de données :Dépeint la vue publique des données locales.

§ Niveau conceptuel de base de données locale :Dépeint l'organisation locale de données à chaque emplacement.

§ Niveau interne de base de données locale :Dépeint l'organisation physique de données à chaque emplacement.

Figure 17: Architecture répartie avec multi-SGBD

II.7.4.4. SGBD Fédérés

L'architecture fédérée intègre plusieurs SGBD autonomes et potentiellement hétérogènes en une seule BD virtuelle dont l'interface d'accès commun doit être implémentée pour masquer l'hétérogénéité des BD et la répartition des données.

L'inconvénient de cette architecture reste l'intégration du schéma, la réécriture des requêtes complexes ainsi que les performances limitées.

Figure 18: Architecture répartie avec SGBD fédérés

II.7.5. Objectifs du SGBDR

Les objectifs d'un SGBDR se résument en ces aspects suivants :

II.7.5.1. Multi client-serveur

Dans le contexte du client serveur, un client peut demander l'exécution d'une requête à un serveur. La requête, appelée requête distante peut par exemple être exprimée en SQL. Pour assurer l'objectif multi clients, le SGBDR doit fournir des mécanismes de contrôle de concurrence adapté, garantissant que l'effet de l'exécution simultanée des transactions est le même que celui d'une exécution séquentielle : cette propriété est appelée la sérialisabilité des transactions.

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy