24/10/2010

Cas de panne d’un participant Oracle et la distribution des

données
SGBD Oracle
– gestion du catalogue de la
BDR
• SQL*Net
– connexion client-serveur,
login à distance automatique
– requêtes distribuées,
transactions distribuées,
réplication
• SQL*Connect : passerelle
vers les bases non-Oracle

Database link • Exemple :

• requête globale :
• Lien à une table dans une BD distante spécifiée
par: • SELECT nom FROM client WHERE numero=
– nom de lien 234 ;
– nom de l'utilisateur et password • requête locale :
– chaîne de connexion Net8 (protocole réseau, nom de
site, options, etc…) • SELECT nom FROM client1@site1 WHERE
• Exemple numero=234
CREATE DATABASE LINK empParis • UNION
CONNECT TO anne IDENTIFIEDBY monPW
USING Paris.emp • SELECT nom FROM client2@site2 WHERE
numero=234;

1
 24/10/2010

Fédération de BD • 2) Traduction des schémas (résolution de

l’hétérogénéité syntaxique)
• Procédure d’intégration : – Origine : utilisation de modèles différents dans les BD
composantes
– 1) Traitement de l’hétérogénéité sémantique – Effet : nécessite des traductions de tous les modèles vers
– 2) Traduction des schémas (résolution de tous les modèles
l’hétérogénéité syntaxique) – Solution : traduction de tous les schémas dans un
– 3) Intégration des schémas modèle commun (dit canonique ou pivot)
– Problématique :
• 1) Hétérogénéité sémantique • Le modèle canonique doit avoir un pouvoir de modélisation ≥ à
ceux des modèles des BD composantes
– Origine : Résulte des conceptions indépendantes des • Nécessité de compléter sémantiquement des modèles de BD
différentes BD composantes qui seraient trop pauvres
– Effet : Désaccord sur la signification des données – Choix du modèle canonique :
• Entité - Association et Relationnel
– Solution : Analyse sémantique comparée des • Objet
données préalable à la fédération souvent groupée
avec la phase de traduction

2
 24/10/2010

• 3) Démarche d’intégration
– Pré-intégration :
• Mise en évidence des dépendances induites par les schémas
Quelques cas de conflits
• Définitions des équivalences entre domaines
• Convention de désignation
• Conflits d’attributs
– Comparaison ou analyse - mise en évidence des conflits : – Conflit de nom → renommage
• de désignation (homonymie, synonymie)
– Conflit de type → conversion
• structurels
• de domaine • Attribut sans équivalent dans l’autre relation
• de contraintes – Attribut optionnel → valeur nulle
• …. – Attribut indispensable → relation auxiliaire
– Mise en conformité : résolution des conflits • Conflit de relation
• renommage pour les conflits de noms – Conflit multi-attribut : un attribut correspond à plusieurs dans l’autre
• étude au cas par cas pour les conflits structurels relation (ex. adresse et N°, rue, code, ville) utilisation d’un calcul sur les
attributs (ex. extraction)
– Fusion des schémas - Qualités recherchées : – Conflit de clé
• complétude (pas de perte d’information) • pas la même clé → changement de clé
• minimalité (absence de redondance) • la clé d’une des relations composantes n’est pas une clé générale :
• clarté – génération d’une nouvelle clé par ajout d’un élément (ex. nom de localité pas déterminant
au niveau national ajout du numéro de département au nom de la localité pour créer la
– Restructuration - Amélioration du schéma global nouvelle clé)
• pour l’essentiel recherche de clarté sans remise en cause des qualités • ….
recherchées

SGBD réparti
Niveaux de transparence à la localisation
• Trois types d’accès : - La transparence à la
• Client / Multibases : localisation est assurée
– RDA (Remote Data Access) - Standard ISO par la définition de la
– DRDA (Distributed Relational Database Architecture) d’IBM base répartie
(en voie de disparition)
– SQL-CLI (Call Level Interface) de l’Open Group - Les différentes
– ODBC (Open Database Connectivity) de Microsoft opérations sont prises en
• Spécification contrôlée par Microsoft et supportée par les principaux charge par les différents
fournisseurs de SGBD
• Difficulté : niveau de SQL supporté, développement des pilotes, SGBD
– JDBC (Java Database Connection) de SUN - Un protocole de
• Spécification commune à Sun et différents fournisseurs de SGBD
validation à 2 phases est
• Difficulté : risque potentiel d’intrusion dans des systèmes par
l’intermédiaire du code mobile (byte-code) supporté
• Vues réparties (sur BD fédérées)
• SGBD réparti

3
 24/10/2010

Schéma conceptuel de la base

• Implémentation de la base :
• Personne (N° personne, nom, prénom, adresse, …)
• Sites 75, 78, 91, 92, 93, 94, 95
– Bases préfectorales avec Voitures, Conducteur et
• Voiture (N° véhicule, marque, type, …) Personne pour les voitures immatriculées dans le
département (Personne, Voiture, Conducteur)
• Conducteur (N° personne, N° véhicule, NB_accidents,..) • SAMU : base SAMU de la région parisienne
(Accident, Blessé)
• Accident (N° accident, date, département, N° véhicule, N° • La requête « liste des blessés graves dans une
personne, …) voiture type yyy de marque xxx dans la région
parisienne » émane d’un site appelé
• Blessé (N° accident, N° personne, gravité, ….) interrogation

Plan d’exécution répartie

• Requêtes sur S75, S78, S91, S92, S93, S94,
• Requête sur site SAMU : S95 :
- SELECT B.N°personne, A.N°véhicule FROM Blessé RECEIVE temp1 FROM SAMU
B, Accident A
- SELECT P.nom,P.prénom FROM Personne P, temp1
WHERE B.N°accident = A.N°accident AND B.gravité T, Voiture V
> « commotions »
WHERE P.N°personne = T.N°personne AND
AND A.département IN (75, 78, 91, 92, 93, 94, 95) T.N°véhicule = V.N°véhicule
INTO temp1
AND V.marque = « xxx » AND V.type = « yyy » INTO
-SEND temp1 to S75, S78, S91, S92, S93, S94, S95 temp2.i
– SEND temp2.i TO Interrogation

4
 24/10/2010

• Requête sur site Interrogation : Optimisation des requêtes réparties

– RECEIVE temp2.75 FROM S75 …… • Établissement d’un plan d’évaluation optimal
RECEIVE temp2.95 FROM S95 • Optimisation d’une fonction de coût ou de temps de réponse de la
forme :
UNION temp2.75, temp2.78,…..temp2.95 • coût global = a x coût(E/S) + b x coût(Processeur) + c x
coût(Communication) + d x coût(Transfert des données)
INTO résultat • Rappel : la compilation d’une requête SQL produit un arbre
d’évaluation composé d’un certain nombre d’opérateurs de base :
• Conclusion – Projection : ΠX R projection de la relation R sur la liste d ’attributs X
– Le SGBD réparti a pris en charge tous les – Sélection : σP R sélection des tuples de R vérifiant le prédicat P
– Équijointure : R1 R2 jointure des relations R1 et R2 selon l’attribut A
problèmes liés à la répartition (R1.A=R2.A)
– Produit cartésien : x produit de deux relations
– Les transferts sont minimisés : – Union : ∪ union de 2 relations
• seuls les N° des blessés et des véhicules sont – Intersection : ∩ intersection de deux relations
transférés • L’optimisation vise à transformer l’arbre d’évaluation en un arbre
optimal

Exemple - Définition de la base

de données :
B : buveurs (N°B, nom, prénom,
ville)
V : vins (N°V, cru, millésime,
degré)
C : commandes (N°V,N°B, date,
quantité)
Exemple de requête de sa
traduction et de son
optimisation en l’absence de
répartition :
SELECT nom, prénom FROM
buveurs (B), vins (V),
commandes (C)
WHERE V.cru = « Volnay » AND
V.degré > 12 AND C.quantité >
100
AND C.N°V = V.N°V AND C.date
>1/1/2000 AND B.N°B = C.N°B
AND B.ville = « Paris »

5
24/10/2010