1
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 1
heg Haute école de gestionde Neuchâtel
Base de données IIModule 1
Bases de données réparties
University of Applied Sciences of Western SwitzerlandSchool of Business Administration Neuchâtel
Fachhochschule WestschweizHochschule für Wirtschaft Neuenburg
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 2
heg Haute école de gestionde Neuchâtel
Plan du module 1
• Introduction aux bases de données réparties• Concepts des base de données réparties• Le médiateur et son paramétrage• Outils de distribution• Lecture de données réparties• Mise à jour de données distantes et réparties• Transactions réparties• Bases de données réparties hétérogènes
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 3
heg Haute école de gestionde Neuchâtel
Les bases de données réparties
• Les système de gestion de bases de données réparties (SGBDRep) ont été inventés à la fin des années 70 afin d ’intégrer les bases de données et les réseaux.
• Les prototype comme Ingres/star et R*d ’IBM ont abouti à des produits qui sont aujourd’hui les versions distribuées d ’Oracle,SQL Server ou Sybase.
• Depuis le milieu des années 80 , les systèmes sont capables de gérer des bases hétérogènes.
2
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 4
heg Haute école de gestionde Neuchâtel
Définition
• On appel base de données répartie une base de données composées de plusieurs base de données visible comme un système unique, qui échangent des données avec des messages.
• Une base de données répartie ne contient en principe pas de redondance, si les données sont copiées d ’une BD à l ’autre, on parle de BD répliquées
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 5
heg Haute école de gestionde Neuchâtel
Exemple de base de données répartie
• On peut imaginer deux sites de production de véhicule gérant plusieurs usines et un site de gestion pour une même société.
VEHICULE
USINE
PRODUCTION
REGION_A
VEHICULE
USINE
PRODUCTION
REGION_B
CLIENT
COMMANDES
CENTRE
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 6
heg Haute école de gestionde Neuchâtel
Objectifs des bases de données réparties
• Indépendance à la localisation– Transparence pour les applicatifs et les utilisateurs
• Indépendance à la fragmentation– Accès uniforme à des données fragmentées sur n
sites • Indépendance aux SGBD
– Utilisations de SGBD hétérogènes• Autonomie des sites
– Chaque site garde son indépendance locale
3
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 7
heg Haute école de gestionde Neuchâtel
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 leurs localisations. – Les avantages de la transparence à la localisation sont
tout d'abord de simplifier la vue utilisateur et l'écriture des requêtes, mais surtout d'introduire la possibilité de déplacer les objets sans modifier les requêtes.
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 8
heg Haute école de gestionde Neuchâtel
Autonomie locale
• Eviter la nécessité d'une administration centralisée– L'autonomie locale vise à garder une administration
locale séparée et indépendante pour chaque serveur participant à la base de données répartie.
– Les reprises après panne doivent être accomplies localement et ne pas avoir d’impacts sur les autres sites.
– Les mises à niveau de logiciel doivent être possibles sans avoir de répercussions sur les autres sites.
• Chaque base conserve donc son dictionnaire local contenant les schémas locaux.
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 9
heg Haute école de gestionde Neuchâtel
Entreprise avec une base de données répartie
4
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 10
heg Haute école de gestionde Neuchâtel
Répartition d ’une base de données
• Avantages– Performance
• Accès sur le site global
– Intégrité des données globales• Dico centralisé
– extensibilité• Inconvénients
– Complexité de mise en œuvre– Maintenance– Difficulté d ’intégration des BD hétérogènes
» voir de paradigmes différents (relationnelles, objets,fichiers,..)
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 11
heg Haute école de gestionde Neuchâtel
SGBD-Réparties
• Un SGBD-R permet de géré une base de données répartie en faisant appel à des SGBD locaux
• Il fournit un mécanisme d'accès qui rend la répartition transparente aux utilisateurs
» Dictionnaire de données réparties» Traitement des requêtes réparties» Gestion des transactions réparties (pannes !)» Communication de données inter-site» Gestion de cohérence et de sécurité
SGBDR1SGBDR1 SGBDR2SGBDR2
SGBDRSGBDR
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 12
heg Haute école de gestionde Neuchâtel
SGBD réparti
• Logiquement réparti– SGBDR , SGBDR 1 et SGBDR 2
sur le même site» Souvent hétérogène
• Physiquement réparti sur un réseau– SGBDR , SGBDR 1 et SGBDR 2
sur des sites différents» Moins résistant aux pannes
SGBDR1SGBDR1 SGBDR2SGBDR2
SGBDRSGBDR
5
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 13
heg Haute école de gestionde Neuchâtel
Plan du module 2
• Introduction aux bases de données réparties• Concepts des base de données réparties• Le médiateur et son paramétrage• Outils de distribution• Lecture de données réparties• Mise à jour de données distantes et réparties• Transactions réparties• Bases de données réparties hétérogènes
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 14
heg Haute école de gestionde Neuchâtel
Schéma local
• Une base de données locale comporte un schéma géré par le SGBD local.
• Lors de la constitution d’une base de données répartie, chaque base locale rend visible une partie de la base aux sites clients.
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 15
heg Haute école de gestionde Neuchâtel
Notion de Schéma global
• Comme toute base de données, une BDR possède un schéma appelé schéma global qui permet de définir l ’ensemble de la structure de la base.– Le schéma global ignore les concepts d ’implémentation.
• Dans une BDRep le schéma global n ’est pas forcément matérialisé, chaque base locale en implémente une partie– On le nomme également schéma conceptuel.
6
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 16
heg Haute école de gestionde Neuchâtel
Niveau de couplage
• Dans la pratique, il existe plusieurs niveaux de couplages entres les différents SGBD.
• La littérature propose différents termes (répartie, distribuées, fédérées,...)pour spécifier si les bases locales peuvent être accédées ou non directement.– Les différents auteurs ne sont pas d ’accord entre eux.
• On peut également parler de systèmes fortement ou faiblement couplé– La classification n’est pas rigoureuse, on est en règle
général face à des systèmes « mixtes »
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 17
heg Haute école de gestionde Neuchâtel
Base de données distribuées
• La base n ’est accessible que par le schéma global– La base « master » ne contient que des meta-données – Il matérialise le schéma global
BD1
BD2 BD3
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 18
heg Haute école de gestionde Neuchâtel
Base de données distribuées (suite)
• La base de données distribuée peut également contenir des données
BD1
BD2 BD3
7
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 19
heg Haute école de gestionde Neuchâtel
Base de données fédérées
• La base de données distribuée est accessible par le schéma global, les schéma locaux restent accessibles
BD1
BD2 BD3
– Le schéma global n ’est pas le résultat de l ’union des schémas locaux
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 20
heg Haute école de gestionde Neuchâtel
Système multi-base (faiblement couplé)
• Les bases sont interconnectées, il n ’y a pas de schéma global matérialisé– Très courant, mais peu formalisé
BD1BD2 BD3
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 21
heg Haute école de gestionde Neuchâtel
Système complet
• Une base de données fédérée avec implémentation d ’un schéma global et assurant l ’autonomie des sites contient tous les concepts (et les problèmes) des bases distribuées
• Elles sont rarement complètement implantée et représente plutôt un cas d ’école– C ’est le plus difficile
8
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 22
heg Haute école de gestionde Neuchâtel
Conception de base de données réparties
• Une base de données répartie est un système compliqué, qui si il peut-être évité, il devrait l ’être !
• Certaines circonstances dans la vie du SI nous impose la mise en place d ’une base de donnée répartie
• On distingue deux approches fondamentalement différentes– Conception ascendante– Conception descendante
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 23
heg Haute école de gestionde Neuchâtel
Conception de base répartie
Base de données
BD1 BD2 BDn...
Base de données
BD1 BD2 BDn...
• Conception ascendante– On utilise les différentes bases
« locales » pour créer un schéma global
• Conception descendante– On « éclate » le schéma global
en n bases locales
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 24
heg Haute école de gestionde Neuchâtel
Conception descendante
• La conception descendante est utilisée lors de la construction d ’une nouvelle base de données
• On créer d ’abord un schéma global, les diverses entités sont alors distribués sur les sites
• Part d ’une démarche « nouveau », orienté performance et disponibilité
• Plutôt rare et pas très compliqué à construire
9
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 25
heg Haute école de gestionde Neuchâtel
Conception ascendante
• La conception ascendante part de bases de données existantes.
• Obtention d ’un schéma global à partir de schémas locaux.
• La distribution est préexistante et doit être gérée• Cette approche nécessite généralement une
réconciliation sémantique• Exemple
– Fusion de société
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 26
heg Haute école de gestionde Neuchâtel
Cas courant
• La mise en place de système distribué est généralement issu de conception ascendante
• C ’est le cas le plus courant mais le plus compliqué, car il nécessite de gérer l ’existant qui est généralement hétérogènes– Machines (OS, Protocol,…)– SGBD – Modèles de données (réconciliation sémantique !!)
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 27
heg Haute école de gestionde Neuchâtel
Notion de fragments de données
• Un fragment est un sous-ensemble obtenu par la sélection de lignes et de colonnes à partir d ’une relation globale, localisée sur un site unique
– Fragmentation horizontale
– Fragmentation verticale
– Fragmentation mixte
10
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 28
heg Haute école de gestionde Neuchâtel
Techniques de fragmentation
• La conception descendante d'une base de données répartie conduit à distribuer sur différents sites des parties appelés fragments d'une table globale.– A partir d'une table globale, la fragmentation peut d'une
part s'effectuer par sélection de lignes, fragmentation horizontale, et par projection sur des colonnes ce qui représente la fragmentation verticale.
Région NE
Autres régions
Fragmentation horizontale
Client Produit
Fragmentation verticale
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 29
heg Haute école de gestionde Neuchâtel
Techniques de fragmentation
• Pour la conception ascendante on dispose de fragments existants sur les sites locaux. On consolide les différents fragments pour obtenir une relation globale.
• La difficulté consiste à obtenir une consolidation correcte a partir des fragments existants
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 30
heg Haute école de gestionde Neuchâtel
Fragmentation verticale
• La fragmentation verticale est le découpage d'une table en relations par projections permettant de sélectionner les colonnes composant chaque fragment.
• Afin de ne pas perdre d'informations, la table initiale doit pouvoir être recomposée par jointure des fragments
11
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 31
heg Haute école de gestionde Neuchâtel
Exemple de fragmentation verticale
CREATE VIEW v_commandeAS SELECT commande1.numero, commande1client,
commande2.produit, commande2.qteFROM commande1@Site1, commande2@Site2WHERE commande1.numero= commande2.numero;
CREATE VIEW v_commandeAS SELECT commande1.numero, commande1client,
commande2.produit, commande2.qteFROM commande1@Site1, commande2@Site2WHERE commande1.numero= commande2.numero;
Vue Commandenuméro client produit qté Commande1=Commande(numéro,client)
1 1 54 10 Commande2=Commande(numéro,produit,qté)
2 1 52 123 2 64 25 Commande=numéro,client,produit,qté
4 4 18 51 WHERE Commande1.numéro=Commande2.numéro
Commande1 Commande2numéro client numéro produit qté
1 1 1 54 102 1 2 52 123 2 3 64 254 4 4 18 51
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 32
heg Haute école de gestionde Neuchâtel
Fragmentation horizontale
• La fragmentation horizontale est un découpage d'une table en relations par utilisation de prédicats permettant de sélectionner les lignes appartenant à chaque fragment.
• Ce type de fragmentation est adapté à la régionalisation ou départementalisation dans une entreprise.
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 33
heg Haute école de gestionde Neuchâtel
Exemple de fragmentation horizontale
Vue Commandenuméro client produit qté Commande1=
Commande WHERECommande.client=client1.numéro
1 1 54 10 Commande2=Commande WHERE Commande.client=client2.numéro
2 1 52 123 2 64 25 Commande=Commande1+Commande2
4 4 18 51
Commande1 Commande2numéro client produit qte numéro client produit qte
1 1 54 10 3 2 64 252 1 52 12 4 4 18 51
CREATE VIEW v_commandeAS SELECT numero, client,produit, qteFROM Commande1@site1UNIONSELECT numero, client,produit, qteFROM Commande2@site2 ;
CREATE VIEW v_commandeAS SELECT numero, client,produit, qteFROM Commande1@site1UNIONSELECT numero, client,produit, qteFROM Commande2@site2 ;
12
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 34
heg Haute école de gestionde Neuchâtel
Fragmentation mixte
• La fragmentation mixte résulte de l'application successive d'opérations de fragmentation horizontale et de fragmentation verticale sur une relation globale.
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 35
heg Haute école de gestionde Neuchâtel
Schéma de répartition
• Chaque fragment est placé sur un site et doit pouvoir être localisé (localisation du fragment).
• 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écomposé sa requête globale en plusieurs requêtes locale en utilisant son schéma de répartition.
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 36
heg Haute école de gestionde Neuchâtel
Architecture d ’une base de données répartie
Schéma externe global 1
Schéma externe global 1
Schéma externe global 2
Schéma externe global 2
Schéma externe global 3
Schéma externe global 3
Schéma conceptuel global Schéma conceptuel global
Schéma d’allocationSchéma d’allocation
Schéma externe local 1
Schéma externe local 1
Schéma conceptuel local 1
Schéma conceptuel local 1
Schéma interne local 1
Schéma interne local 1
Schéma externe local 2
Schéma externe local 2
Schéma conceptuel local 2
Schéma conceptuel local 2
Schéma interne local 2
Schéma interne local 2
Schéma de fragmentationSchéma de fragmentation
13
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 37
heg Haute école de gestionde Neuchâtel
Requête répartie (en lecture)
Fragmentation
Optimisation
Requête sur unerelation globale
Requête surfragments
Plan d'exécution
Schémad'allocation
Schéma defragmentation Fragmentation
Optimisation
SELECT nomFROM client
WHEREnumero=234
SELECT nom FROM Client1 WHEREnumero=234 UNION
SELECT nom FROM Client2 WHEREnumero=234
Select nom FROM ClientA@Site1 WHEREnumero=234 UNION SELECT nom FROM
ClientB@Site2 WHERE numero=234
Client1=ClientA@Site1
Client2=ClientB@Site2
Client=Client1+Client2
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 38
heg Haute école de gestionde Neuchâtel
Exemple
BDR
Noeud0
BD1
Noeud1
BD2
Noeud2
Dispose du schéma de
répartition
SELECT nomFROM client
WHEREnumero=234
SELECT nom FROM client
WHERE numero = 234
SELECT nom FROM client
WHERE numero = 234
SELECT nom_personne FROM personne@site2
WHERE id = 234
SELECT nom_personne FROM personne@site2
WHERE id = 234
SELECT name FROM customer@site1
WHERE number = 234
SELECT name FROM customer@site1
WHERE number = 234
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 39
heg Haute école de gestionde Neuchâtel
Plan du module 2
• Introduction aux bases de données réparties• Concepts des base de données réparties• Le médiateur et son paramétrage• Outils de distribution• Lecture de données réparties• Mise à jour de données distantes et réparties• Transactions réparties• Bases de données réparties hétérogènes
14
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 40
heg Haute école de gestionde Neuchâtel
Dialogue entre les bases de données
• Les bases de données s ’échange des messages pour transférer les données
• Le site maître devient un client pour les sites locaux, le dialogue est établit alors sur le modèle client serveur.
• Lors d ’un requête complexe, une base de données sera alors tantôt cliente tantôt serveur
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 41
heg Haute école de gestionde Neuchâtel
Architecture client -serveur
• Une architecture client serveur repose toujours sur deux composant– Un client (front-end)– Un serveur (back-end)
• C ’est toujours le client qui émet une demande au serveur.
• Le client doit connaître l ’adresse du serveur.• La communication entre le client et le serveur doit
être un dialogue et non pas un échange de fichier
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 42
heg Haute école de gestionde Neuchâtel
Définition du modèle client serveur
• Est conforme au modèle client - serveur, une application qui fait appel à des services distants au travers d’un échange de messages (les requêtes) plutôt que par un échange de fichiers.
• «L’idée» du modèle est de transporter sur le réseau (lent) que ce qui est nécessaire en faisant dialoguer les machines
15
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 43
heg Haute école de gestionde Neuchâtel
Le principe du dialogue à sessions
Application cliente Processus Serveur (SGBDR)
L’application veut addresserune requête SQL (SELECT)Etablissement de laconnection
Création du curseur
Emmision de la requête Compilation de la requête
Execution de la requête, message de« done »
Demande de la structure durésultat
Envoi description de la structure durésultat
Demande des n premièreslignes composant le résultat
Envoi des n premières lignescomposant le résultat
Demande des n lignessuivants composant le résultat
Envoi des n lignes suivants composantle résultat
Demande des n lignessuivants composant le résultat
Réponse : plus de lignes à envoyer
Fin de connexion Destruction du curseur
Instructions
Data
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 44
heg Haute école de gestionde Neuchâtel
Conséquence sur l'architecture réseau
• Dans une architecture client serveur chaque nœud du même réseau est soit client, soit serveurs d ’un dialogue.
• Un serveur dans un dialogue peut-être client dans un autre
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 45
heg Haute école de gestionde Neuchâtel
Les composants logiciels
• Sur chaque machine, on retrouve les trois composants logiciels– Application– Middleware– Protocole
protocole protocolemiddleware middlewareapplication application
client serveur
16
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 46
heg Haute école de gestionde Neuchâtel
Les composants du middleware
• La couche API et la couche FAP forme le middleware
• Chaque couche "connaît" ses deux voisines.
• Permet de rendre le dialogue a session indépendant du protocol
Application
API Application Programme Interface
FAP Format And Protocol
Protocole
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 47
heg Haute école de gestionde Neuchâtel
Paramétrage du réseau
• Les BD réparties sont en principe accueillies sur des machines différentes.
• Les différents nœud doivent évidement être connectés.– (réseau, DNS, sécurité,…)
• Le paramétrage du réseau logique des BD se fait par « dessus » le protocole.– Ex : TCP/IP
• Le logiciel de communication est généralement propriétaire de la base de données– pour Oracle Net8
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 48
heg Haute école de gestionde Neuchâtel
Demande d ’un client
• Pour l ’établissement d ’un connexion entre le client et le serveur
• Le serveur doit être a l ’écoute d ’une connexion le concernant.– Serveur d ’écoute
• Résolution du nom par le client– un alias de base de donnée doit être résolu pour
atteindre celle-ci
17
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 49
heg Haute école de gestionde Neuchâtel
Nom global de base de données
• Pour qu ’un connexion puisse se produire, chaque base de données à un seul nom global de base de données dans le domaine de réseau.
• Le nom global de base de données identifie seulement une base de données dans un système réparti.
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 50
heg Haute école de gestionde Neuchâtel
Serveur d ’écoute (Net8)
• Sur chaque nœud du réseau on doit placer un serveur d ’écoute (listener)– C ’est un processus ou service qui lit en permanence un
port de la machine.• Le serveur d ’écoute connaît les BD se trouvant sur
le nœud, et établit la connexion entre le client et le serveur.– Pour chaque BD
» ID de la BD» Nom de la racine des binaires (Oracle Home)
• Ces paramètre se trouve dans le fichier listener.ora
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 51
heg Haute école de gestionde Neuchâtel
Contrôle du serveur d ’écoute (Net8)
• Démarrage du serveur
• Arrêt du serveur
• Interrogation du serveur
lsnrctl startlsnrctl start
lsnrctl stoplsnrctl stop
lsnrctl statuslsnrctl status
18
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 52
heg Haute école de gestionde Neuchâtel
Résolution du nom par le client
• Avec une base de données distribuée, une base locale peut être cliente d ’une autre base
• Il est donc nécessaire qu ’elle connaisse les bases ou elle ira se connecter.
• Lors d ’une connexion, en utilisant un alias, celui-ci doit être résolu en – Un nœud– Un port– Un protocole– un identificateur de BD
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 53
heg Haute école de gestionde Neuchâtel
Différentes méthodes de nommages (Net8)
• La résolutions des noms demandé par le client peut être fait de plusieurs façons– Nommage explicite
» TNSNAMES
– Serveur de nommage» ONAMES
– Nommage avec annuaire» LDAP
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 54
heg Haute école de gestionde Neuchâtel
Nommage par serveur de noms
• Chaque demande client de résolution d ’un nom serveur, passe par le serveur de nommage
Serveur de noms
Serveurs de données
Clients
19
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 55
heg Haute école de gestionde Neuchâtel
Paramétrage du médiateur
• Paramétrage général– sqlnet.ora
» domaine, cryptage,traçage
• Paramétrage du client– tnsnames.ora
» liste des serveurs accessibles
• Paramétrage du serveur– listener.ora
» Liste des bases de données du serveur, type de dispatcher
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 56
heg Haute école de gestionde Neuchâtel
Paramétrage du médiateur client-side
• Fichier sqlnet.ora– méthode utilisée pour le nommage:
» NAMES.DIRECTORY_PATH= (TNSNAMES,ONAMES,LDAP)– domaine par défaut
» NAMES.DEFAULT_DOMAIN = ACME.COM– niveau de traçage
» TRACE_LEVEL_CLIENT = USER– Type de criptage
» SQLNET.AUTHENTICATION_SERVICES= (NTS)
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 57
heg Haute école de gestionde Neuchâtel
Paramétrage du médiateur client-side
• Fichier tnsnames.ora– si méthode de nommage : TNSNAMES– Alias que le client peut atteindre:
SALES =(DESCRIPTION =
(ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCP)(HOST = serv1.company.com)(PORT = 1521)))
(CONNECT_DATA = (SERVICE_NAME = SALES.ACME.COM)))
SALES =(DESCRIPTION =
(ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCP)(HOST = serv1.company.com)(PORT = 1521)))
(CONNECT_DATA = (SERVICE_NAME = SALES.ACME.COM)))
20
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 58
heg Haute école de gestionde Neuchâtel
Paramétrage du médiateur serveur-side
• Fichier tnsnames.ora– si méthode de nommage : TNSNAMES– Alias que le serveur serv1.company.com. peut atteindre:
HQ =(DESCRIPTION =
(ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCP)(HOST = serv2.factory.com)(PORT = 1521)))
(CONNECT_DATA = (SERVICE_NAME = HQ.ACME.COM)))
HQ =(DESCRIPTION =
(ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCP)(HOST = serv2.factory.com)(PORT = 1521)))
(CONNECT_DATA = (SERVICE_NAME = HQ.ACME.COM)))
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 59
heg Haute école de gestionde Neuchâtel
Paramétrage du médiateur serveur-side
• Fichier listener.ora– fichier du serveur serv1.company.com
LISTENER =(DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = serv1.company.com)(PORT = 1521)))
SID_LIST_LISTENER =(SID_LIST =(SID_DESC =
(GLOBAL_DBNAME = SALES.ACME.COM )(ORACLE_HOME = /u01/app/oracle/product/8.1.7EE)(SID_NAME = ORCL)
)
LISTENER =(DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = serv1.company.com)(PORT = 1521)))
SID_LIST_LISTENER =(SID_LIST =(SID_DESC =
(GLOBAL_DBNAME = SALES.ACME.COM )(ORACLE_HOME = /u01/app/oracle/product/8.1.7EE)(SID_NAME = ORCL)
)
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 60
heg Haute école de gestionde Neuchâtel
Paramétrage du médiateur serveur-side
• Fichier initORCL.ora– fichier du serveur serv1.company.com– nom de la base (idem au SID lors de la création)
» DB_NAME = ORCL– domaine de la base ORCL
» DB_DOMAIN = ACME.COM– Vérification que le nom db link est identique à la base où
il se connecte (recommandé par Oracle)» GLOBAL_NAMES = TRUE
– Multithread Server» MTS_DISPATCHERS = "(PROTOCOL=TCP)(DISPATCHERS=3)"
21
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 61
heg Haute école de gestionde Neuchâtel
Paramétrage du médiateur serveur-side
• Visualisation des services du serveur d ’écoute
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 62
heg Haute école de gestionde Neuchâtel
Connexion Net8
• Contrôle des connections TCP/IP– PING
• Contrôle des serveurs d ’écoutes– lsnrctl
• Visualisation des fichiers de paramétrages clients– sqlnet.ora, tnsnames.ora
• Contrôle des connections Net8– tnsping
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 63
heg Haute école de gestionde Neuchâtel
Plan du module 2
• Introduction aux bases de données réparties• Concepts des base de données réparties• Le médiateur et son paramétrage• Outils de distribution• Lecture de données réparties• Mise à jour de données distantes et réparties• Transactions réparties• Bases de données réparties hétérogènes
22
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 64
heg Haute école de gestionde Neuchâtel
Méta-données de connexion
• Les bases de données doivent se connaître via leurs méta-données
• Ses liens logiques sont appellés database links.• Un database link comme une chemin de
communication unidirectionnel d’une base de données à une autre
• C ’est uniquement un chemin, il n ’implique aucune redondance
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 65
heg Haute école de gestionde Neuchâtel
Databaselink
• Un databaselink est unidirectionnel. Il est contenu dans les méta-donnée de la BD.
• Le chemin inverse n ’est pas possible
BD2 BD3
BD3 connaît BD2 et l ’inverse n ’est pas vrai
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 66
heg Haute école de gestionde Neuchâtel
Connections réciproques
• Si les deux bases de données doivent se « connaître » mutuellement, il faut créer deux databaselink
BD2 BD3
Lien de BD3 sur BD2Est contenu dans BD3Lien de BD2 sur BD3
Est contenu dans BD2
23
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 67
heg Haute école de gestionde Neuchâtel
Database link
• Un database link est un pointeur qui définit un lien unidirectionnel d ’une base de données d'oracle à une autre
• Il est définit dans les méta-données (dictionnaire)
– Syntaxe Oracle :
CREATE [PUBLIC] DATABASE LINK dblink[CONNECT TO user IDENTIFIED BY password][USING connect_string];
CREATE [PUBLIC] DATABASE LINK dblink[CONNECT TO user IDENTIFIED BY password][USING connect_string];
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 68
heg Haute école de gestionde Neuchâtel
Syntaxe du database link
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 69
heg Haute école de gestionde Neuchâtel
Type de database link
• Public Database link– Tous les utilisateurs et objet PL/SQL de la base pourront
utiliser ce lien pour accéder aux données et aux objets de la base distante correspondante.
• Private Database links– Appartient a un schéma. Seul le propriétaire du lien
pourra l'utiliser afin d'accéder aux données de la base de données distante.
» Ce lien sera plus sûre qu'un public database link.
24
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 70
heg Haute école de gestionde Neuchâtel
Global Database link
• Quand un réseau Oracle utilise un serveur de nom, celui-ci va créer et gérer automatiquement un global database link pour toutes les bases de données du réseau.
• Tous les utilisateurs et tous les objets PL/SQL de toutes les bases du réseau peuvent utiliser ce lien pour accéder aux objets et aux données de la base distante.
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 71
heg Haute école de gestionde Neuchâtel
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 leurs localisations. – Les avantages de la transparence à la localisation sont
tout d'abord de simplifier la vue utilisateur et l'écriture des requêtes, mais surtout d'introduire la possibilité de déplacer les objets sans modifier les requêtes.
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 72
heg Haute école de gestionde Neuchâtel
Indépendance à la localisation
• Le concept d ’indépendance à la localisation peut être traité avec des synonymes
– Exemple
• Le fragment peut alors être utilisé sans connaître sa localisation
CREATE SYNONYM matable FOR monfragment@mondblink ;
CREATE SYNONYM matable FOR monfragment@mondblink ;
25
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 73
heg Haute école de gestionde Neuchâtel
Plan du module 2
• Introduction aux bases de données réparties• Concepts des base de données réparties• Le médiateur et son paramétrage• Outils de distribution• Lecture de données réparties• Mise à jour de données distantes et réparties• Transactions réparties• Bases de données réparties hétérogènes
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 74
heg Haute école de gestionde Neuchâtel
Mise en place d ’une fragmentation horizontale
-- Creation des db_linkCREATE DATABASE LINK bd1.worldCONNECT TO monuser IDENTIFIED BY monpasswordUSING ’bd1 ’ ;CREATE DATABASE LINK bd2.worldCONNECT TO monuser IDENTIFIED BY monpasswordUSING ’bd2 ’ ;
--indépendance a la localisationCREATE 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, libelleFROM d_tab1 UNION
SELECT code, libelleFROM d_tab2 ;
-- Creation des db_linkCREATE DATABASE LINK bd1.worldCONNECT TO monuser IDENTIFIED BY monpasswordUSING ’bd1 ’ ;CREATE DATABASE LINK bd2.worldCONNECT TO monuser IDENTIFIED BY monpasswordUSING ’bd2 ’ ;
--indépendance a la localisationCREATE 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, libelleFROM d_tab1 UNION
SELECT code, libelleFROM d_tab2 ;
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 75
heg Haute école de gestionde Neuchâtel
Analyse de la requête
Execution Plan----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE1 0 VIEW OF 'D_TAB_FH'2 1 SORT (UNIQUE)3 2 UNION-ALL4 3 REMOTE* ES21.WORLD5 3 REMOTE* ES14.WORLD
4 SERIAL_FROM_REMOTE SELECT "CODE","LIBELLE" FROM "D_TAB1" "D_TAB1"5 SERIAL_FROM_REMOTE SELECT "CODE","LIBELLE" FROM "D_TAB2" "D_TAB2"
Execution Plan----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE1 0 VIEW OF 'D_TAB_FH'2 1 SORT (UNIQUE)3 2 UNION-ALL4 3 REMOTE* ES21.WORLD5 3 REMOTE* ES14.WORLD
4 SERIAL_FROM_REMOTE SELECT "CODE","LIBELLE" FROM "D_TAB1" "D_TAB1"5 SERIAL_FROM_REMOTE SELECT "CODE","LIBELLE" FROM "D_TAB2" "D_TAB2"
26
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 76
heg Haute école de gestionde Neuchâtel
Exemple de fragmentation verticale
CREATE SYNONYM d_tab3 FOR d_tab3@bd3 ;
CREATE OR REPLACE VIEW d_tab_fv AS SELECT t1.code, libelle, libelle2FROM d_tab1 t1, d_tab3 t3
WHERE t1.code = t3.code ;
CREATE SYNONYM d_tab3 FOR d_tab3@bd3 ;
CREATE OR REPLACE VIEW d_tab_fv AS SELECT t1.code, libelle, libelle2FROM d_tab1 t1, d_tab3 t3
WHERE t1.code = t3.code ;
Execution Plan----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE1 0 MERGE JOIN2 1 SORT (JOIN)3 2 REMOTE* ES14.WORLD 4 1 SORT (JOIN)5 4 REMOTE* ES21.WORLD
3 SERIAL_FROM_REMOTE SELECT "CODE","LIBELLE2" FROM "D_TAB3" "T3"5 SERIAL_FROM_REMOTE SELECT "CODE","LIBELLE" FROM "D_TAB1" "T1"
Execution Plan----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE1 0 MERGE JOIN2 1 SORT (JOIN)3 2 REMOTE* ES14.WORLD 4 1 SORT (JOIN)5 4 REMOTE* ES21.WORLD
3 SERIAL_FROM_REMOTE SELECT "CODE","LIBELLE2" FROM "D_TAB3" "T3"5 SERIAL_FROM_REMOTE SELECT "CODE","LIBELLE" FROM "D_TAB1" "T1"
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 77
heg Haute école de gestionde Neuchâtel
Exemple de fragmentation mixte
Execution Plan----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE1 0 MERGE JOIN2 1 SORT (JOIN)3 2 REMOTE* ES14.WORLD4 1 SORT (JOIN)5 4 VIEW OF 'D_TAB_FH'6 5 SORT (UNIQUE)7 6 UNION-ALL8 7 REMOTE* ES21.WORLD9 7 REMOTE* ES14.WORLD
3 SERIAL_FROM_REMOTE SELECT "CODE","LIBELLE2" FROM "D_TAB3" "T3"8 SERIAL_FROM_REMOTE SELECT "CODE","LIBELLE" FROM "D_TAB1" "D_TAB1"9 SERIAL_FROM_REMOTE SELECT "CODE","LIBELLE" FROM "D_TAB2" "D_TAB2"
Execution Plan----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE1 0 MERGE JOIN2 1 SORT (JOIN)3 2 REMOTE* ES14.WORLD4 1 SORT (JOIN)5 4 VIEW OF 'D_TAB_FH'6 5 SORT (UNIQUE)7 6 UNION-ALL8 7 REMOTE* ES21.WORLD9 7 REMOTE* ES14.WORLD
3 SERIAL_FROM_REMOTE SELECT "CODE","LIBELLE2" FROM "D_TAB3" "T3"8 SERIAL_FROM_REMOTE SELECT "CODE","LIBELLE" FROM "D_TAB1" "D_TAB1"9 SERIAL_FROM_REMOTE SELECT "CODE","LIBELLE" FROM "D_TAB2" "D_TAB2"
CREATE OR REPLACE VIEW d_tab_fv AS SELECT fh.code, libelle, libelle2FROM d_tab_fh fh, d_tab3 t3
WHERE fh.code = t3.code ;
CREATE OR REPLACE VIEW d_tab_fv AS SELECT fh.code, libelle, libelle2FROM d_tab_fh fh, d_tab3 t3
WHERE fh.code = t3.code ;
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 78
heg Haute école de gestionde Neuchâtel
Plan du module 2
• Introduction aux bases de données réparties• Concepts des base de données réparties• Le médiateur et son paramétrage• Outils de distribution• Lecture de données réparties• Mise à jour de données distantes et réparties• Transactions réparties• Bases de données réparties hétérogènes
27
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 79
heg Haute école de gestionde Neuchâtel
Mise à jour de données distante
• Le protocole le plus simple (et le plus ancien) de mise à jour de données à distante est RPC– Remote Process Call– C ’est l ’appel d ’un processus sur un système distant
» Depuis longtemps utilisé par les OS• unix, VMS, NT, …
• Pour les bases de données réparties, il s ’agit d ’appeler une procédure stockée dans une autre base de données.– On appel la procédure en la post-fixant avec un alias de
database linkEXECUTE maproc@monalias ;EXECUTE maproc@monalias ;
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 80
heg Haute école de gestionde Neuchâtel
Mise à jour distante
• La mise à jour de fragments distant se fait de en le post-fixant du database link
• Exemple
– Cet appel ne retourne pas de données » sauf un message d ’erreur en cas de violation de contrainte
UPDATE matable@monalias SET col = value WHERE condition ;
UPDATE matable@monalias SET col = value WHERE condition ;
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 81
heg Haute école de gestionde Neuchâtel
Mise à jour d’un fragment distant
• C’est du dialogue client serveur simple• L’appel d’une mise à jour par un client sur un
serveur de données utilise le même protocole– 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 retours» INSERT, UPDATE, DELETE
• On parle alors de la mise à jour à distance d’un fragment unique
28
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 82
heg Haute école de gestionde Neuchâtel
Requête répartie en écriture multi-site
• La mise à jour des données sur une base de données répartie nécessite la validation préalable de chaque site avant la demande du site fédérateur.(coordinateur)
• Ce protocole de validation se nomme Commit à deux phases et garantit le tout ou rien dans la base répartie. – Le principal inconvénient de la validation à deux phases
est sa lourdeur
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 83
heg Haute école de gestionde Neuchâtel
Plan du module 2
• Introduction aux bases de données réparties• Concepts des base de données réparties• Le médiateur et son paramétrage• Outils de distribution• Lecture de données réparties• Mise à jour de données distantes et réparties• Transactions réparties• Bases de données réparties hétérogènes
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 84
heg Haute école de gestionde Neuchâtel
Gestion des transactions
• Rappel :– Une transaction est composée d'une suite de requêtes
dépendantes de la base qui doivent vérifier les propriétés d'atomicité, de cohérence, d'isolation et de durabilité.
• Ces propriétés doivent être garanties dans le cadre d'un système réparti.
29
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 85
heg Haute école de gestionde Neuchâtel
Transaction répartie
• En particulier pour une transaction répartie, il faut assurer que toutes les mises à jour d'une transaction sont exécutées sur tous les sites ou qu'aucune ne l'est. – Le problème essentiel à résoudre est le risque
d'incohérence lié au contrôle puisque chaque site peut décider de valider ou d'annuler une transaction.
– Il faut donc coordonner les validations inter-sites
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 86
heg Haute école de gestionde Neuchâtel
Validation en deux phases
• Le protocole de validation en deux phases a été proposé afin de coordonner l'exécution des commandes COMMIT par tous les sites participant à une transaction.
• Le principe consiste à diviser la validation en deux phases.
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 87
heg Haute école de gestionde Neuchâtel
Phases du 2PC
• Phase 1 – réalise la préparation de l'écriture des résultats de mises
à jours dans la base de données et la centralisation du contrôle.
• Phase 2– réalisée seulement en cas de succès de la phase 1,
intègre effectivement les résultats des mises à jour dans la base de données répartie.
– Le contrôle du système réparti est centralisé sous la direction d'un site appelé coordinateur, les autres étant des participants
30
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 88
heg Haute école de gestionde Neuchâtel
Coordinateur et participant
• Le coordinateur représente le nœud d'un système réparti qui dirige le protocole en centralisant le contrôle.
• Le participant représente le nœud d'un système réparti qui exécute des mises à jour de la transaction et obéit aux commandes de préparation, validation ou annulation du coordinateur.
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 89
heg Haute école de gestionde Neuchâtel
Dialogue coordinateur-participant
CoordinateurCoordinateur ParticipantParticipant
PréparationPréparation
Préparer
ValidationValidation
Prêt / non-prêt
Valider / abandonner
Fini
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 90
heg Haute école de gestionde Neuchâtel
Commit à deux phases
• Lors de l’étape 1, le coordinateur demande aux autres sites s’ils sont prêts à valider leurs mises à jour par l’intermédiaire du message prepare. – Si tous les participants répondent positivement (ok), le
message commit est diffusé : tous les participants effectuent leur validation sur ordre du client.
– Si un participant n’est pas prêt et répond négativement (ko), le coordinateur demande à tous les autres sites de défaire la transaction (abort).
31
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 91
heg Haute école de gestionde Neuchâtel
Validation normale en Commit à deux phases
réception des messages "prêt"
Coordinateur
P1 P2
Préparer Préparer
Prêt Prêt
Valider Valider
Fin Fin
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 92
heg Haute école de gestionde Neuchâtel
Protocole Client - multiserveurs
• Le protocole client-multiserveurs de validation en deux étapes découle des concepts précédents.
• Le client joue le rôle de coordinateur et les serveurs celui de participants.
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 93
heg Haute école de gestionde Neuchâtel
Panne avant la validation de la transaction
• Le but du commit à deux phases est de garantir la cohérence de la mise à jour lors d ’une panne d ’un des participants.
• La panne est due à une indisponibilité de la base– Panne du nœud – Panne du SGBD– Panne du réseau
• Le COMMIT à deux phase résout le problème automatiquement sur une panne de courte durée
32
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 94
heg Haute école de gestionde Neuchâtel
Panne du participant P2 avant d'être prêt
reprise
Coordinateur
P1 P2
Préparer Préparer panne
Prêt
Abandon Abandon
Fin
Fin
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 95
heg Haute école de gestionde Neuchâtel
Panne pendant la transaction
• Le protocole nécessite la journalisation des mises à jour préparées et des états des transactions dans un journal local propre à chaque participant.
• La journalisation permet au coordinateur de retrouver l’état d’une transaction après une éventuelle panne et de continuer la validation éventuelle.
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 96
heg Haute école de gestionde Neuchâtel
Panne du participant P2 après s'être déclaré prêt
CoordinateurP1 P2Préparer Préparer
Prêt Prêt
Valider Validerpanne
FinPrêt reprise
Valider
Fin
33
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 97
heg Haute école de gestionde Neuchâtel
Limite du 2PC
• Lorsque le coordinateur devient inopérationnel, (par exemple en cas de panne), le 2PC est bloquant
• Les participants qui se sont déclarés prêt à valider restent bloqués. – Dans ce cas les participants doivent attendre la reprise
du coordinateur. » Tous les participants sont bloqués !!!!
– Un protocole bloquant limite donc les performances du système réparti en cas de panne.
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 98
heg Haute école de gestionde Neuchâtel
Panne du coordinateur avant la réception des messages "prêt"
Coordinateur
P1 P2
Préparer Préparer
Prêt Prêt panne
reprise
Préparer Préparer
Prêt Prêt
Valider Valider
Fin Fin
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 99
heg Haute école de gestionde Neuchâtel
Les solutions au problème de verrou mortel
• Deux classes de solutions sont possibles dans les SGBD répartis afin de résoudre le problème du verrou mortel
• la première, appelé prévention, empêche les situations de verrous mortels de survenir;
• la seconde, appelé détection, est une solution qui consiste à supprimer les verrous mortels par reprises de transactions.
34
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 100
heg Haute école de gestionde Neuchâtel
Vues du dictionnaires (Oracle)
• DBA_2PC_PENDING– Information sur les transactions réparties
• DBA_2PC_NEIGHBORS– Nœud impliqués dans les transactions douteuses
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 101
heg Haute école de gestionde Neuchâtel
Distribution des mises à jour
• La mise à jour d ’une table du schéma global formés de plusieurs fragments nécessite que la base maître transforme cette requête en requêtes sur les fragments.
• Pour transmettre ces sous-requêtes, la base doit connaître la localisation des fragments.– Localisation du fragment
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 102
heg Haute école de gestionde Neuchâtel
Méta-données de fragmentation
• D'un point de vue purement théorique, le SGBDR devrait permettre la définition et la localisation des fragments par une commande.
• 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 faite par le SGBD– Cette mise à jour peut-être complexe et posé des
problèmes avec des vues non modifiables par exemple
35
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 103
heg Haute école de gestionde Neuchâtel
Localisation des fragments Oracle
• Oracle 8 ne dispose pas de méta-données de localisation de fragment.– La notion même de fragment est implicite
• La localisation des fragments sont définis dans le query de la vue– Impossible d ’identifier les fragments pour le SGBD
– Impossible de transmettre la mise à jour au fragments
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 104
heg Haute école de gestionde Neuchâtel
Mise à jour des fragments avec Oracle
• Oracle propose d ’utiliser des triggers qui permettent de propager la mise a jours de la relation globale sur les fragments. – On créer alors un trigger qui se déclenchera à la place
de l ’instruction de mise à jour et décomposera la requête en sous-requêtes sur les fragments.
• La répartition de la mise à jour est donc mise en place entièrement par le développeur
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 105
heg Haute école de gestionde Neuchâtel
Trigger instead of (définition)
• Les triggers INSTEAD OF fournissent une manière transparente de modifier des vues qui, au premier abord, ne peuvent pas l'être directement avec les commandes SQL habituelles d'insertion, de mise à jour ou de suppression.
36
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 106
heg Haute école de gestionde Neuchâtel
Traitement de la requête globale
• Le trigger devra rediriger la requête globale en l ’ »éclatant » vers les tables de bases (fragments) afin que les changements soient directement effectués sur les tables distantes.– La vue va se mettre automatiquement à jour en prenant
tout changement effectué sur les tables de bases.
• Le trigger doit implémenter la règle de distribution
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 107
heg Haute école de gestionde Neuchâtel
Exemple d ’une fragmentation horizontale
• La règle de distribution se fait sur le code– Fragment dans BD1 pour code de ‘ A ’ à ‘ M ’
Table1numerocodelibelle
Table2numerocodelibelle
BETWEEN (N AND Z)BETWEEN (A AND M)
Table1numerocodelibelle
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 108
heg Haute école de gestionde Neuchâtel
Exemple de trigger pour l ’insertion
CREATE TRIGGER tr_tab INSTEAD OF INSERT ON d_tabBEGIN
IF :New.code <= 'M' THENINSERT INTO d_tab1 (numero, code, libelle)
VALUES ( :New.numero,:New.code, :New.libelle) ;ELSEINSERT INTO d_tab2 (numero, code, libelle)
VALUES ( :New.numero,:New.code, :New.libelle) ;END IF ;END ;/
CREATE TRIGGER tr_tab INSTEAD OF INSERT ON d_tabBEGIN
IF :New.code <= 'M' THENINSERT INTO d_tab1 (numero, code, libelle)
VALUES ( :New.numero,:New.code, :New.libelle) ;ELSEINSERT INTO d_tab2 (numero, code, libelle)
VALUES ( :New.numero,:New.code, :New.libelle) ;END IF ;END ;/
37
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 109
heg Haute école de gestionde Neuchâtel
Exemple de trigger pour l ’effacement
CREATE TRIGGER tr_tab INSTEAD OF DELETE ON d_tabBEGIN
IF :OLD.code <= 'M' THENDELETE FROM d_tab1 WHERE numero = :Old.numero);
ELSEDELETE FROM d_tab2 WHERE numero = :Old.numero);
END IF ;END ;/
CREATE TRIGGER tr_tab INSTEAD OF DELETE ON d_tabBEGIN
IF :OLD.code <= 'M' THENDELETE FROM d_tab1 WHERE numero = :Old.numero);
ELSEDELETE FROM d_tab2 WHERE numero = :Old.numero);
END IF ;END ;/
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 110
heg Haute école de gestionde Neuchâtel
Ex. de trigger pour la mise à jour d ’un attribut
CREATE TRIGGER tr_tab INSTEAD OF UPDATE ON d_tabBEGIN
IF :New.code <= 'M' THENUPDATE d_tab1 set libelle = :New.libelle
WHERE numero = :New.numero ;ELSEUPDATE d_tab2 set libelle = :New.libelle
WHERE numero = :New.numero ;END IF ;END ;/
CREATE TRIGGER tr_tab INSTEAD OF UPDATE ON d_tabBEGIN
IF :New.code <= 'M' THENUPDATE d_tab1 set libelle = :New.libelle
WHERE numero = :New.numero ;ELSEUPDATE d_tab2 set libelle = :New.libelle
WHERE numero = :New.numero ;END IF ;END ;/
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 111
heg Haute école de gestionde Neuchâtel
Ex. de trigger pour la m.à.j de la clé de répartition
CREATE TRIGGER tr_tab INSTEAD OF UPDATE ON d_tabBEGINIF :New.code <> :Old.code THEN
IF :New.code <= 'M' THENDELETE FROM d_tab1 WHERE numero = :Old.numero);INSERT INTO d_tab2 (numero, code, libelle)
VALUES ( :New.numero,:New.code, :New.libelle) ;ELSEDELETE FROM d_tab2 WHERE numero = :Old.numero);INSERT INTO d_tab1 (numero, code, libelle)
VALUES ( :New.numero,:New.code, :New.libelle) ;END IF ;
ELSE…
END IF ;END ;/
CREATE TRIGGER tr_tab INSTEAD OF UPDATE ON d_tabBEGINIF :New.code <> :Old.code THEN
IF :New.code <= 'M' THENDELETE FROM d_tab1 WHERE numero = :Old.numero);INSERT INTO d_tab2 (numero, code, libelle)
VALUES ( :New.numero,:New.code, :New.libelle) ;ELSEDELETE FROM d_tab2 WHERE numero = :Old.numero);INSERT INTO d_tab1 (numero, code, libelle)
VALUES ( :New.numero,:New.code, :New.libelle) ;END IF ;
ELSE…
END IF ;END ;/
38
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 112
heg Haute école de gestionde Neuchâtel
Remarques
• L’exemple précédent met en évidence les limites de la propagation des mises à jour sur les fragments
• Il est évident que si les fragments sont soumis à des contraintes (ex: FK) la mise à jour décrite dans le trigger précédent est inimaginable.
• Le respect des contraintes des schémas locaux rend très complexe la modification du schéma de distribution
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 113
heg Haute école de gestionde Neuchâtel
Contraintes déclaratives (rappel)
• Un des grands avantages des bases de données relationnelles réside dans le respect par le SGBD des contraintes déclaratives– Sont définies dans les méta-données, et ne nécessite
pas de programmation• Il existe plusieurs types de contraintes
– Contraintes de domaine– Contraintes d ’intégrité d ’entité– Contraintes d ’intégrité référentielle
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 114
heg Haute école de gestionde Neuchâtel
Contraintes distribuées
• Dans une base de données distribuées, il est nécessaire de dissocier les contraintes locales et les contraintes globales– Contraintes locale -> dans le schéma local– Contraintes globales -> dans le schéma global
• La relation globale est en général matérialisé par une vue et ne peut donc pas être contraintes– Les contraintes globales ne peuvent être matérialisées
39
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 115
heg Haute école de gestionde Neuchâtel
Exemple contrainte de domaine (check)
• En règle générale un check ou NOT NULL peut être placer uniquement sur le fragment
• Si la relation globale doit garantir une contrainte sur plusieurs fragments ne permettent pas de garantir la contrainte globale
c2 c3 c4c1T1– Exemple
» Une contrainte déclarative (c2 > c3) ne peut se placer que sur les fragments et ne peut être garantie
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 116
heg Haute école de gestionde Neuchâtel
Exemple contrainte d ’entité (clé primaire)
• La clé primaire est une contrainte d ’entité• La relation globale étant composé de fragment, une
contrainte sur les fragments ne permettent pas de garantir la contrainte globale
c2 c3 c4c1T1– Exemple
» La colonne C1 doit supporter la PK.
» La contrainte ne peut se placer que sur les fragments et ne peut garantir l ’unicité dans la relation T1
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 117
heg Haute école de gestionde Neuchâtel
Exemple contrainte d ’intégrité référentielle (FK)
• Un clé étrangère sur des relation n ’appartenant pas à la même base de données n ’est pas supportée
c2c1T1c2c1T1
40
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 118
heg Haute école de gestionde Neuchâtel
Contraintes globales
• Les contraintes déclaratives s ’appliquant à plusieurs bases de données ne sont pas supportées.– Le dictionnaire est contenu dans la base de données
• Les contraintes globales ne peuvent dont être placée comme les contraintes locales dans le schéma global.
• La mise en place des contraintes globales doit être faite de manière procédurale (trigger) par le développeur.
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 119
heg Haute école de gestionde Neuchâtel
Contraintes globale et locales
• La gestion des contraintes globales ne peut être simplement mise en place si l ’on veut garantir l ’autonomie des sites locaux.
• Un trigger sur le site global devant garantir une contraintes (unicité par exemple) ne sera pas déclenché lors d ’une manipulation sur le site local.
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 120
heg Haute école de gestionde Neuchâtel
Numérotation par le site global
• La numérotation est faite par le site global, les site locaux sont donc automatiquement unique
• Perte de l ’autonomie des sites– L ’insertion doit se faire par le site global ou au minimum
le site local doit « demander » un numéro au site global
41
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 121
heg Haute école de gestionde Neuchâtel
Numérotation par les sites locaux
• L ’identifiant ne peut être repris sur le site global• Solution courante concaténation de la clé su site
local avec l ’ID du site
• La relation globale ne peut être référencée
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 122
heg Haute école de gestionde Neuchâtel
En général
• Les limites de la gestion des contraintes globales avec une base de données répartie est vite atteinte
• Si les contraintes globales doivent être garanties avec des contraintes déclaratives, il est préférable de mettre en place un système répliqué
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 123
heg Haute école de gestionde Neuchâtel
Plan du module 2
• Introduction aux bases de données réparties• Concepts des base de données réparties• Le médiateur et son paramétrage• Outils de distribution• Lecture de données réparties• Mise à jour de données distantes et réparties• Transactions réparties• Bases de données réparties hétérogènes
42
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 124
heg Haute école de gestionde Neuchâtel
Bases de données hétérogènes
• Il arrive souvent, particulièrement en conception ascendante, que les différentes bases de données ne soient pas homogènes
• L’hétérogénéité des systèmes peuvent êtres de sources différentes– Système d’exploitation– Version de SGBD– Constructeurs de SGBD– Modèle de données (structures)– Paradigme de gestion de données
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 125
heg Haute école de gestionde Neuchâtel
Hétérogénéité des systèmes d’exploitation
• Il ne s’agit en général pas d’un problème majeur, et on ne peut pas parler de bases de données hétérogènes à proprement parler
• Le paramétrage correct du logiciel middleware rend la base de données indépendant du système d’exploitation– Un cas particulier réside dans l’utilisation de protocoles
réseaux différents. Ces problèmes seront résolus par le middleware
» Exemple : TCP/IP et Netware
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 126
heg Haute école de gestionde Neuchâtel
Hétérogénéité des versions du SGBD
• Il ne s’agit en général pas d’un problème majeur.• Les différentes versions doivent alors dialoguer,
mais il arrive que certaines contraintes nous interdisent de faire évoluer les systèmes les plus anciens.– La disponibilité des fonctionnalités de la base de
données répartie se résume alors souvent à celle de la version du SGBD la plus ancienne
43
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 127
heg Haute école de gestionde Neuchâtel
Hétérogénéité des SGBD (constructeurs)
• Les bases hétérogènes mettent souvent en liaison des SGBD de constructeurs différents
• Le cas est assez courant, il est classique de la conception ascendante.
• La normalisation du langage SQL fait que ces systèmes sont utilisables
• Le problème réside dans la résolution des dialectes, et surtout dans le dialogue des couches middleware propriétaires
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 128
heg Haute école de gestionde Neuchâtel
Passerelles de SGBD
• Pour résoudre le problèmes des dialectes entre SGBD, il faut utiliser une passerelle
• Ce composant logiciel va traduire les requêtes d ’un dialecte à l ’autre
– Les grands constructeurs proposent des passerelles entre leur systèmes et les leaders du marché
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 129
heg Haute école de gestionde Neuchâtel
Un cas particulier HS (Oracle et Win32)
44
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 130
heg Haute école de gestionde Neuchâtel
BD hétérogène physiquement distribuée
E. Meylan/ 11/11/2003 Informaticien de Gestion HES / Bases de données II- Distribution 131
heg Haute école de gestionde Neuchâtel
Différents paradigmes de gestion de données
• Le problème majeur et difficilement résolu des bases de données hétérogène réside dans des différences entre les modèles de données– Relationnel– Objet– Réseau– Hiérarchique– …