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

Eddy.Meylan@hegne.ch

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– …