Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Bachtarzi.C Cours : bases de données avancées Filière SITW Niveau : Master 1 1

Bachtarzi.C Cours : bases de données avancées Filière SITW Niveau : Master 1 1 Chapitre II Concepts de bases de données Distribuées I- Introduction : Les systèmes de gestion des bases données distribuées ont été inventés à la fin des années 70 afin d’intégrer les bases de données et les réseaux. Définition : Une base de données distribuée est un ensemble de bases stockées sur plusieurs machines dans le but de se comporter vis-à-vis des applications comme une base de données unique. D’une façon plus générale, lorsque le déroulement d’une transaction, invoque plus d’un serveur, on parle de BD distribuée. II- Objectifs des systèmes distribués : II-1 Indépendance à la localisation : Le but est de permettre à l’utilisateur d’écrire ses programmes sans se soucier de l’emplacement des données de façon à rendre les programmes indépendants du stockage physique des données. Les vues utilisateur sont simplifiées ainsi que l’écriture des requêtes. II-2 Indépendance à la fragmentation : Une relation peut être fragmentée en plusieurs parties chacune dans un site différent et là aussi, l’écriture des requêtes ne doit pas dépendre de cette fragmentation. II-3- Indépendance aux SGBD : Chaque base de données est gérée par son propre SGBD (Oracle, Ingres …) et ceci ne doit pas se répercuter sur les programmes utilisateurs. Ceci exige un mécanisme de traduction du modèle de données et du langage de requêtes de chaque base de données. II-4 Autonomie des sites : Chaque serveur participant dans la base de données distribuée doit contrôler et gérer ses propres données de manière locale (gestion des schémas, contrôle des transactions, les reprises après panne,…) indépendamment des autres sites. Un SGBD distribué permet de gérer une BD distribuée en faisant appel à des SGBD locaux. Pour cela, il a à sa disposition : - dictionnaire de données réparties - traitement des requêtes réparties - gestion des transactions réparties - communication de données inter-sites - gestion de cohérence et de sécurité III- Concepts de base des SGBD distribués : III-1- Schéma local : chaque base de données locale met à la disposition des autres sites son propre schéma. III-2- Schéma global : Il définit la structure de la BDD indépendamment des concepts d’implémentation. Bachtarzi.C Cours : bases de données avancées Filière SITW Niveau : Master 1 2 III-3- Niveaux de couplage : Il existe plusieurs niveaux de couplage dans un système distribué. Premier cas : la base n’est accessible que par le schéma global. - La base Master ne contient que les méta-données - Les accès aux sites locaux sont interdits. - Couplage fort Deuxième cas : Le site maître peut aussi contenir des données. - autonomie des sites locaux - couplage moyen Troisième cas : Système faiblement couplé. - Pas de schéma global. IV- Conception d’une base de données distribuée : On distingue deux approches différentes. IV-1- Conception descendante : utilisée lors de la constitution de nouvelles BD. - On part du schéma global pour construire les schémas locaux. - Facile à construire. Etapes : - Conception du schéma conceptuel global - Distribution pour obtenir des schémas conceptuels locaux - Fragmentation - Affectation aux sites – Allocation Bachtarzi.C Cours : bases de données avancées Filière SITW Niveau : Master 1 3 IV-2- Conception ascendante : Intégration de BD existantes en une base distribuée. - Le schéma global est construit à partir de schémas locaux. - Nécessité d’une réconciliation sémantique due à l’hétérogénéité des données Conception descendante Conception ascendante BD- Repartie BD- Repartie BD locale1 BD local2 BDlocale3 BD locale1 BD locale2 BD locale3 La distribution des données peut se faire de différentes manières : - Distribution par fragmentation - Distribution par réplication. V- Fragmentation : Consiste à distribuer sur différents sites des parties appelées fragments d’une table globale. Pourquoi fragmenter ? - De meilleures performances - Réduire le trafic sur le réseau, donc une meilleure utilisation de ses possibilités - répartir l'impact sur les processeurs et sur leurs entrées/sorties. - L'utilisation de petits fragments permet de faire tourner plus de processus simultanément V-1- Fragmentation verticale : Découpage d’une table en relations par projection permettant de sélectionner les colonnes composant chaque fragment. La table initiale doit pouvoir être recomposée par jointure des fragments. V-2- Fragmentation horizontale : Découpage d’une table en relations par utilisation de prédicats permettant de sélectionner les lignes appartenant à chaque fragment. - Adapté à la régionalisation d’une entreprise. V-3- Fragmentation mixte : Application successives d’opérations de fragmentation horizontale et verticale sur une relation globale. VI- Schéma de répartition : Chaque fragment est placé sur un site. Un schéma doit être élaboré afin de déterminer la localisation de chaque fragment et sa position dans le schéma global. Lors de l’exécution d’une requête distribuée, le SGBDR doit décomposer sa requête globale en plusieurs requêtes locales en utilisant son schéma de répartition. Bachtarzi.C Cours : bases de données avancées Filière SITW Niveau : Master 1 4 Requête répartie en lecture : Fragmentation Schéma de fragmentation SELECT nom FROM client Where numéro = 234 SELECT nom FROM client1 WHERE numéro = 234 UNION SELECT nom FROM client2 WHERE numéro = 234 Optimisation SELECT nom FROM client1@site1 WHERE numéro = 234 UNION SELECT nom FROM client2@site2 WHERE numéro = 234 Schéma D’allocation Requête répartie en Lecture Bachtarzi.C Cours : bases de données avancées Filière SITW Niveau : Master 1 5 VII- Outils de distribution : VII-1- Data base link : Les bases de données doivent se connaître via leurs meta-données. Ces liens logiques sont appelés database links. C’est un chemin de communication unidirectionnel d’une BD à une autre. Il est contenu dans les meta-données de la BD. Le chemin inverse n’est pas possible. BD1 BD2 BD2 connaît BD1 mais l’inverse n’est pas vrai. Si les deux BD doivent se connaître mutuellement, il faut créer deux database link. BD1 BD2 Lien de BD1 sur BD2 est contenu dans BD1. Lien de BD2 sur BD1 est contenu dans BD2. Syntaxe de définition : (sous ORACLE) CREATE [PUBLIC] DATABASE LINK dblink [CONNECT TO user IDENTIFIED BY password] [USING connect_string]; Types de database link: Public database link: tous les utilisateurs PL/SQL de la base pourront utiliser ce lien pour accéder aux données et aux objets de la BD distante correspondante. Private database link: appartient à un schéma. Seul le propriétaire du lien pourra l’utiliser afin d’accéder aux données de la BD distant. VII-2- Transparence à la localisation des données : Les programmes d’application ne doivent pas connaître la localisation physique des données. Les noms des objets doivent être indépendants de leur localisation. Le concept d’indépendance à la localisation peut être traité avec des synonymes. CREATE [PUBLIC] SYNONYM synonyme FOR objet [@dblink] ; Bachtarzi.C Cours : bases de données avancées Filière SITW Niveau : Master 1 6 Exemple : CREATE SYNONYM ma-table FOR mon-fragment@mondblink; Le fragment peut alors être utilisé sans connaître sa localisation. VII-3- Lecture de données distribuées : Cas d’une fragmentation horizontale : -- Création des db_link : CREATE DATABASE LINK bd1.world CONNECT TO mon-user IDENTIFIED BY mon-password USING ‘bd1’; CREATE DATABASE LINK bd2.world CONNECT TO mon-user IDENTIFIED BY mon-password USING ‘bd2’; -- Independence à la localisation: CREATE SYNONYM d_tab2 FOR d_tab2@bd2; CREATE SYNONYM d_tab1 FOR d_tab1@bd1; CREATE OR REPLACE VIEW d-tab_fh AS SELECT code, libelle FROM d_tab1 UNION SELECT code, libelle FROM d_tab2; Cas d’une fragmentation verticale : CREATE SYNONYM d_tab3 FOR d_tab3@bd3; CREATE OR REPLACE VIEW d-tab_fv AS SELECT t1.code, libelle, libelle2 FROM d_tab1 t1 d_tab3 t3 WHERE T1.code = t3.code ; VII-4- Mise à jour de données distantes et distribuées : Le protocole RPC (Remote Process Call) est un protocole de mise à jour. C’est l’appel d’un processus sur un système distant. Dans le cas des BDD, il s’agit d’appeler une procédure stockée dans une autre BD. L’appel se fait comme suit : EXECUTE map-roc@mon-alias; mon-alias : alias de database link. Le protocole se déroule comme suit :( pour INSERT, UPDATE, DELETE) Bachtarzi.C Cours : bases de données avancées Filière SITW Niveau : Master 1 7 - Le client émet la requête - Il valide la transaction - Il récupère un éventuel message d’erreur, mais n’attend pas de valeurs en retour -- Mise à jour d’un fragment distant : UPDATE ma-table@mon-alias SET col = value WHERE condition; Distribution des mises à jour : La mise à jour dans une BD distribuée, nécessite que la base maître transforme une requêtes en sous requêtes sur les fragments. Il faut donc connaître la localisation des fragments. Si la localisation des fragments est stockée dans les méta-données, la distribution de la requête de mise à jour peut être réalisée. Cas particulier : ORACLE. - Oracle ne dispose pas de méta-données de localisation des fragments. - La solution apportée par ORACLE est l’utilisation des triggers (déclencheurs). - Le programmeur devra écrire un trigger qui se déclenchera à la place de l’instruction de mise à jour. Il permet de diviser la requête en sous- requêtes sur les fragments. Triggers INSTEAD OF : Possibilité de modification des vues qui ne peut avoie lieu avec les commandes SQL. • Le trigger devra implémenter la règle de distribution. uploads/Philosophie/ bases-de-donn-es-distribu-es.pdf