Bases de Données Avancées 20010-2011 KHCHERIF Raoudha Raoudha.khcherif@topnet.tn Bureau 109

Plan Rappel Optimisation des requêtes Gestion des Transactions et Gestion de concurrences Architectures Client/Serveur Bases de données reparties

Rappel: Introduction Base de Données ? Une collection de données cohérentes entre elles, généralement de taille importante. Modélise une entreprise du monde réel Entités (ex., étudiants, Briques) Associations (ex., Paul est inscrit en BD) Un Système de Gestion de Bases de Données (SGBD) est un logiciel destiné au stockage et à la manipulation de bases de données.

Pourquoi un SGBD? Indépendance des données/applications et sûreté d’accès aux données. Temps de développement d’application réduit. Intégrité des données et sécurité des accès. Administration des données uniforme. Concurrence des accès et reprise sur panne.

Modèle de données Un modèle de données est un ensemble de concepts sur les données. Un schéma est une description d’un ensemble de données, s’appuyant sur un modèle de données. Le modèle relationnel est le plus répandu. Concepts de base: relation, table avec tuples et des colonnes. Chaque relation a un schéma, qui décrit ses colonnes. Les modèles objet et objet-relationnel sont utilisés pour gérer des données complexes. Les modèles semi-structurés se cherchent une place dans les applications web, intégration de données hétérogènes, …

Niveaux d’abstraction Plusieurs vues, un schéma conceptuel et un schéma physique. Les vues décrivent comment l’utilisateur voit les données. Le schéma conceptuel définit la structure logique des données. Le schéma physique décrit la structure physique, de stockage, des données.

Système de gestion de bases de données 2. Objectifs des SGBD Système de gestion de bases de données I- Indépendance Physique X - Standards II- Indépendance Logique IX - Gestion de la confidentialité BD III – Langage de manipulation VIII - Concurrence d’accès IV - Gestion des vues VII - Gestion des pannes V - Optimisation des questions VI - Gestion de la cohérence

I - Indépendance Physique Indépendance des programmes d'applications vis à vis du modèle physique : Possibilité de modifier les structures de stockage (fichiers, index, chemins d'accès, …) sans modifier les programmes; Ecriture des applications par des non-spécialistes des fichiers et des structures de stockage; Meilleure portabilité des applications et indépendance vis à vis du matériel.

II - Indépendance Logique Les applications peuvent définir des vues logiques de la BD Gestion des médicaments Cabinet du Dr. Masse Nombre_Médicaments Id-M Nom Description Nombre 1 Aspegic 1000 …………………………….. 30 2 Fluisédal 20 3 Mucomyst 230 …. …….. ….. Prescription Prescription Visites Visites Id Id - - V V Ligne Ligne Id Id - - M M Posologie Posologie Id Id - - D D Id Id - - P P Id Id - - V V Date Date Prix Prix 1 1 1 1 12 12 1 par jour 1 par jour 1 1 2 2 1 1 15 juin 15 juin 250 250 1 1 2 2 5 5 10 gouttes 10 gouttes 2 2 3 3 4 4 1 mars 1 mars 250 250 …. …. …. …. …. …. ………… ………… Patients Patients Id Id - - P P Nom Nom Prénom Prénom Médicament Médicament 1 1 Lebeau Lebeau Jacques Jacques Id Id - - M M Nom Nom Description Description 2 2 Troger Troger Zoe Zoe 1 1 Aspegic 1000 Aspegic 1000 …………………………….. …………………………….. …. …. ……. ……. ……. ……. 2 2 Fluisédal Fluisédal …………………………….. …………………………….. 3 3 Mucomyst Mucomyst …………………………….. …………………………….. …. …. …….. …….. …………………………….. …………………………….. Système de gestion de bases de données Traduction

Avantages de l’indépendance logique Possibilité pour chaque application d'ignorer les besoins des autres (bien que partageant la même BD). Possibilité d'évolution de la base de données sans réécriture des applications : ajout de champs, ajout de relation, renommage de champs. Possibilité d'intégrer des applications existantes sans modifier les autres. Possibilité de limiter les conséquences du partage : Données confidentielles.

III - Manipulation aisée La manipulation se fait via un langage déclaratif La question déclare l’objectif sans décrire la méthode Le langage suit une norme commune à tous les SGBD SQL : Structured Query Langage Sémantique Logique du 1er ordre ++ Syntaxe (aperçu !) SELECT <structure des résultats> FROM <relations> WHERE <conditions>

IV – Des vues multiples des données Les vues permettent d’implémenter l’indépendance logique en permettant de créer des relations virtuelles Vue = Question stockée Le SGBD stocke la définition et non le résultat Exemple : la vue des patients parisiens la vue des docteurs avec leurs patients La vue des services statistiques ...

V –Exécution et Optimisation Traduction automatique des questions déclaratives en programmes procéduraux :  Utilisation de l’algèbre relationnelle Optimisation automatique des questions Utilisation de l’aspect déclaratif de SQL Gestion centralisée des chemins d'accès (index, hachages, …) Techniques d’optimisation poussées Economie de l'astuce des programmeurs milliers d'heures d'écriture et de maintenance de logiciels.

VI - Intégrité Logique Objectif : Détecter les mises à jour erronées  Contrôle sur les données élémentaires Contrôle de types: ex: Nom alphabétique Contrôle de valeurs: ex: Salaire mensuel entre 1 et 5MD Contrôle sur les relations entre les données Relations entre données élémentaires: Prix de vente > Prix d'achat Relations entre objets: Un électeur doit être inscrit sur une seule liste électorale

Contraintes d’intégrité Avantages : simplification du code des applications sécurité renforcée par l'automatisation mise en commun des contraintes Nécessite : un langage de définition de contraintes d'intégrité la vérification automatique de ces contraintes

VII - Intégrité Physique Motivations : Tolérance aux fautes Transaction Failure : Contraintes d'intégrité, Annulation System Failure : Panne de courant, Crash serveur ... Media Failure : Perte du disque Communication Failure : Défaillance du réseau Objectifs : Assurer l'atomicité des transactions Garantir la durabilité des effets des transactions commises Moyens : Journalisation : Mémorisation des états successifs des données Mécanismes de reprise

Transaction Begin CEpargne = CEpargne - 3000 Incohérence possible... Etat cohérent Etat cohérent Begin Commit Transaction Begin CEpargne = CEpargne - 3000 CCourant = CCourant + 3000 Commit T1

Transaction: Exécution d’un programme au dessus d’une BD Concept clé : transaction, une séquence atomique d’actions sur une BD (lectures/écritures) séparant un commit ou un rollback du commit ou du rollback suivant. Chaque transaction doit laisser la BD dans un état cohérent après l’avoir prise dans un état cohérent. Les utilisateurs peuvent spécifier des contraintes d’intégrité simples sur les données et le SGBD se charge de les garder inviolables. En dehors de ça, le SGBD n’a pas conscience de la sémantique des données (ex., il ne comprend pas comment les intérêts d’un compte bancaire sont calculés). Le fait qu’une transaction préserve la cohérence de la BD est au bout du compte de la responsabilité de l’utilisateur!

Ordonnancement et concurrence des transactions Les SGBD assurent que l’exécution de {T1, ... , Tn} soit équivalente à une exécution en série T1’ ... Tn’. Avant de lire/écrire un élément, chaque transaction demande à émettre un verrou sur l’élément et attend que le SGBD lui accorde ce verrou. Tous les verrous sont relâchés à la fin de la transaction (protocole V2P strict.) Idée: Si une action de Ti (ex., écrire X) affecte Tj (qui effectue une lecture sur X), une des deux, disons Ti, obtient le verrou sur X la première et Tj est forcée à attendre la fin de Ti; cette façon de faire permet d’ordonner les transactions. Et si Tj a déjà verrouillé Y et que Ti demande par la suite à verrouiller Y? (Deadlock!) Ti ou Tj est abandonnée (aborted) et remise en concurrence!

Propriétés des transactions Atomicité Unité de cohérence : toutes les mises à jour doivent être effectuées ou aucune. Cohérence La transaction doit faire passer la base de donnée d'un état cohérent à un autre. Isolation Les résultats d'une transaction ne sont visibles aux autres transactions qu'une fois la transaction validée. Durabilité Les modifications d ’une transaction validée ne seront jamais perdue

Atomicité Les SGBD assurent l’atomicité (tout ou rien) même si un crash surgit au milieu d’une exécution de transaction. Idée: garder un journal ou log (histoire) de toutes les actions réalisées par le SGBD : Avant qu’un changement ne soit réalisé sur la BD, l’action est tracée dans un log file. Après un crash, les effets d’une exécution partielle d’une transaction sont défaites à l’aide du fichier log.

Atomicité et Durabilité Begin CEpargne = CEpargne - 3000 CCourant = CCourant + 3000 Commit T1  Annuler le débit !! DURABILITE Begin CEpargne = CEpargne - 3000 CCourant = CCourant + 3000 Commit T1 S’assurer que le virement a été fait ! Panne Crash disque

VIII - Partage des données BD Accès concurrent aux mêmes données Conflits d’accès !!

Isolation et Cohérence BD Système de gestion de bases de données Le SGBD gère les accès concurrents Chacun à l’impression d’être seul (Isolation) Cohérence conservée (Pas de maj conflictuelles)

IX – Confidentialité Objectif : Protéger les données de la BD contre des accès non autorisés Deux niveaux : Connexion restreinte aux usagers répertoriés (mot de passe) Privilèges d'accès aux objets de la base Usagers : Usager ou groupe d’usagers Objets : Relation, Vue, autres objets (procédures, etc.)

X - Standardisation L’approche bases de données est basée sur plusieurs standards Langage SQL (SQL1, SQL2, SQL3) Communication SQL CLI (ODBC / JDBC) Transactions (X/Open DTP, OSI-TP) Force des standards Portabilité Interopérabilité Applications multisources…

Architecture Fonctionnelle de Référence Plan d'Accès META-BASE BD ANALYSEUR TRADUCTEUR OPTIMISEUR EXECUTEUR Requête Analyse syntaxique Analyse sémantique Gestion des schémas Modification de requêtes Contrôle d'intégrité Contrôle d'autorisation Ordonnancement Optimisation Élaboration d'un plan Exécution du plan Méthodes d'accès Contrôle de concurrence Atomicité des transactions

3. Architecture des SGBD Les architectures physiques de SGBD sont très liées au mode de répartition. — BD centralisée — BD client/serveur — BD client/multi-serveurs — BD répartie — BD hétérogène — BD mobile Le challenge se déplace des Péta-bases aux Pico-bases. — Péta-bases => parallélisme et grandes mémoires — Pico-bases => faible empreinte et forte sécurité

Architecture centralisée Terminaux passifs réseau Appli 1 Appli 2 Appli n Mainframe SGBD données

Architecture client-serveur Clients intelligents Appli 1 Appli 2 Appli n réseau serveur SGBD code données

Architecture Client-Multiserveurs Appli 1 SQL SQL ODBC ODBC SQL SQL SGBD 1 SGBD 2 code données code données

Architecture répartie Appli 1 Appli 2 Appli n SGBD 1 SGBD 2 code données code données

Architecture mobile Clients intelligents mobiles Données répliquées et/ou personnelles Réseau sans fil serveur SGBD code données

Applications traditionnelles des SGBD 2 grandes familles de serveurs de BDR OLTP (On Line Transaction Processing) Cible des SGBD depuis leur existence Banques, réservation en ligne ... Très grand nombre de transactions en parallèle Transactions simples OLAP (On Line Analytical Processing) Entrepôts de données , Data Mining … Faible nombre de transactions Transactions très complexes

Evolution des BD BD d’entreprise BD personnelles BD ‘light’ (PDA / Tél.) PicoDBMS carte à puce Capacité Prix Nombre

L’optimisation des requêtes

Architecture en couche d’un SGBD

Traitement de requêtes relationnelles P.A META-BASE BD ANALYSEUR TRADUCTEUR OPTIMISEUR EXECUTEUR Requête Le processeur de requêtes assurent les fonctions suivantes: Analyse syntaxique et éventuellement sémantique des requêtes afin de vérifier leur validité. Décomposition des requêtes en séquences d’opérations élémentaires , le SGBD procède a l’optimisation, c a d rechercher la décomposition qui conduit a un temps d’exécution minimal Exécution; au cours de cette phase, le processeur accède aux données spécifiées par la requête et réalise le calcul nécessaire.

Optimisation :???

Le problème : Équivalence sémantique

Objectifs de l’optimisation Trouver le meilleur plan d’exécution …. MEILLEUR ??? Donnant les résultats le + vite …. Optimisation pour le temps de réponse ( response time) Minimisant la consommation de ressources Optimisation du travail total (Total work) Minimisant le temps de délivrance des premiers tuples Optimisation de la latence (Latency /First tuples …)

Importance de l’optimiseur dans un SGBDR Évaluation efficace d’une requête relationnelle: Le SGBD doit évaluer un certain nombre de stratégies (Plan d’exécution) potentiellement efficaces pour traiter la requête Choisir celle qui optimise l’utilisation des ressources de la machine telle que : Espace mémoire, temps de calcul. E/S disques et éventuellement les communications réseaux. Le module qui remplit cette fonction : Optimiseur de requêtes La conception d’un optimiseur est une tache difficile et importante a la quelle les concepteurs de SGBD donnent beaucoup d’importance Impact sur les performances du SGBD et sur le temps de réponse des requêtes La capacité du SGBD a traiter rapidement les requêtes dépend de l’efficacité de l’optimiser a choisir le meilleur plan d’exécution. Libérer le programmeur de la connaissance du fonctionnement des opérateurs Au moment de l’optimisation Compilation : Optimisation a priori Stokage dans une bibliothèque Interprète ; Optimisation a chaque requête

Les acteurs de l’optimisation Idéalement : 2 requêtes équivalentes en SQL ( langage déclaratif) doivent, après l’optimisation, produire le même arbre algébrique ! En plus cet arbre doit être le meilleur ! Seuls les concepteurs de SGBD ( noyau) doivent comprendre l’optimisation et l’exécution Dans la pratique : 2 requêtes équivalentes ne donnent pas toujours le même plan Le plan n’est pas toujours le meilleur ! l’utilisateur (concepteur de l’application ) devra comprendre !!!

Les composants de l’optimiseur Le travail de l’optimiseur est souvent décomposé en deux phases: Phase 1 : optimisation logique, appelée aussi réécriture Optimisation indépendante du coût d’exécution: elle est basée sur des transformations algébriques de la requêtes d’origine. La réécriture simplifie le travail de l’optimisation physique en effectuant un premier ordonnancement Phase 2: optimisation physique, phase principale de tout processus d’optimisation Elle prends les décisions liées aux informations sur le placement physique des données Générations des plans d’exécutions candidats Choix du meilleur plan dont l’évaluation est la moins coûteuse, par exemple qui s’exécute en un minimum de temps

Optimisation logique L’optimisation effectuée dépend essentiellement de l’ordre des opérateurs apparaissant dans arbre algébrique Effectuer un premier ordonnancement des opérations: transformations algébriques Reposent sur le concept d’expression algébriques équivalentes Réalisent prioritairement les opérations de sélection : c1 et c2(R)=c1( c2(R))=c2( c1(R)) Combinent une sélection et un produit cartésien en un opérateur de jointure c(RS)= RcS Regroupent les séquences d’opérateurs unaires tels que sélections et projections et insèrent les opérateurs unaires dans les opérandes d’opérateurs binaires c(RS)=c(R)S c1 et c2(RS)=c1(R)   c2(S) Recherchent les sous expression identiques qui apparaissent plusieurs fois dans une expression algébrique

ARBRES RELATIONNELS n RESTRICTION n PROJECTION n TRI n JOINTURE n V. CRU "BEAUJOLAIS" = V.NV, V.CRU V.CRU, V.MILL V n JOINTURE V n DIFFERENCE V A. NV V. NV = n AGREGAT — A V B1 B2 n PRODUIT CARTESIEN n UNION COUNT(*),AVG(DEGRE) B1 B2  B1 B2 U V.CRU, V.MILL V

EXEMPLE D'ARBRE Consommateur (NC,NOM,PRENOM,ADRESSE,REGION) RESULTAT C.NOM, C.PRENOM A.DATE P.NOMP 08-08-07 « P1 » < = A.NP P.NP PRODUIT P C.NC A.NC C.VILLE "PARIS" CONSOMMATEUR C ACONSOMMER A Consommateur (NC,NOM,PRENOM,ADRESSE,REGION) Aconsommer (NC,NP,DATE,QUANTITE) Produit(NP,NOMP,REGION,CHOIX) REQUETE : "NOM ET PRENOM DES COSOMMATEURS PARISIENS AYANT COSOMMER DU « P1 » , AVANT LE 8 AOUT 2007" Coût d'exécution: 10 millions de consommateurs dont 1 m à Paris 10 millions d‘ aconsommer dont 10000 de P1 1000 Produits 10 m + 10m * 1m + 10 m * 1000 +…… de l'ordre de 10 ** 13 comparaisons de tuples !!!

Exemple d’arbre SELECT P.NOM, SUM(L.PRIX * (1-L.DISCOUNT)) RECETTE SELECT P.NOM, SUM(L.PRIX * (1-L.DISCOUNT)) FROM CLIENTS C, COMMANDES O, LIGNES L, FOURNISSEUR F, PAYS P, CONTINENTS T WHERE C.NUMCLI = O.NUMCLI AND O.NUMCOM = L.NUMCO AND L.NUMFOU = F.NUMFOU AND C.NUMPAYS = F.NUMPAYS AND F.NUMPAYS = P.NUMPAYS AND P.NUMCONT = T.NUMCONT AND T.NOM = « EUROPE » AND O.DATE ³ $D1 AND O.DATE < $D2 GROUP BY P.NOM ORDER BY RECETTE DESC ; P.NOM, RECETTE P.NOM C.NUMCLI = O.NUMCLI O.NUMCOM = L.NUMCO L.NUMFOU = F.NUMFOU L C.NUMPAYS = F.NUMPAYS C F.NUMPAYS = P.NUMPAYS F P.NUMCONT = T.NUMCONT $D1 £ O.DATE <$D1+1 P T.NOM = « EUROPE » O T

3. RESTRUCTURATION ALGEBRIQUE Problème : suivant l'ordre des opérateurs algébriques dans un arbre, le coût d'exécution est diffèrent Pourquoi? 1. le coût des opérateurs varient en fonction du volume des données traitées i.e., plus le nombre de tuple des relations traitées est petit, plus les coûts cpu et d'E/S sont minimisés 2. certains opérateurs diminuent le volume des données e.g., restriction et projection

Commutativité des Jointures/Produit cartésien X R1 R2 <==> S S R

Associativité des jointures Il existe N!/2 arbre de jointure de N relations. R S T

Groupage des Restrictions/Projection Ai = a Aj = b A2 Ai = a et Aj = b A1 A2 <==> A1

Semi-commutativité des Projections Il est possible de descendre les projections, mais les attributs utilisés dans la suite doivent être conservés !!! Ai = a A1, … Ap Ai, A1,… Ap

Semi-commutativité des restrictions et jointures Ai = vi X <==> R1 (.. Ai..) R2 (.. Bj..) R2 (.. Bj..)

Semi-commutativité des restrictions et jointures <==> A1 = vi R1 (.. Ai..) R2 (.. Bj..)

Commutation des projection avec les unions R1(..AI..) R2(..AI..) È A1..Ap <====>

Règles de Restructuration (1) Commutativité des jointures (2) Associativité des jointures (3) Groupabilité des restrictions (4) Semi-commutativité des projections et restrictions (5) Semi-commutativité des restrictions et jointures (6) Semi-distributivité des projections / jointures (7) Distributivité des restrictions / unions ou différences (8) Distributivité des projections / unions

Algorithme d’optimisation d’une expression de l’algèbre relationnelle Entrée : un arbre syntaxique représentant une expression de l’algèbre relationnelle Sortie: un programme d’évaluation de l’expression Méthode: Exécuter tout d’abord les opérations unaires (sélection, projection) puis les opérations binaires Pour considérer les arbres de flux de données minimum, déplacer les sélections et les projections vers le bas Si deux projections successives portent sur une même relation, les regrouper et éliminer des éventuelles projections inutiles ai auraient pu apparaître ( projection sur tout les attributs) Utiliser la règle (3) pour décomposer une sélection comportant plusieurs prédicats en une séquence de sélection Pour chaque sélection déplacer les sélections aussi bas que possible dans l’arbre (règles 4, 5 et 7) Pour chaque projection, déplacer les projetions aussi bas que possible dans l’arbre (règles 4, 6 et 8) Combiner les séquences de sélections et de projections en une seule sélection, une seule projection, ou une sélection suivie par une projection. L'ordre des unions, différences et jointures reste inchangé !!!

Exemple d'Arbre Optimisé Résultat Coût d'exécution: 10 m + 1m * 100000 + 1 m * 1000 + … de l'ordre de 10 ** 11 comparaisons de tuples ! C.NOM, C.PRENOM A.NP P.NP = C.NOM, C.PRENOM,A.NP C.NC A.NC = P.NP C.NC, C.NOM, C.PRENOM A.NC, A.NP P.NOMP = « P1" C.VILLE = "PARIS" A.DATE > 01-01-83 P C A

Optimisation de requêtes (Schémas) (Declarative) Optimisation logique Réécriture Requête (Algebrique) Optimisation physique Modèle de coût Générateur de Plans Espace de Recherche Stratégie de Recherche Estimateur de tailles Méthodes d’implantation Plan d'exécution Optimal

Optimisation Physique de requêtes Optimisation physique de requêtes dans les SGBD est modélisée selon 3 composantes: Espace de recherche : décrit de façon abstraite l’ensemble des plans d’exécution alternatifs pour représenter la requête a optimiser (espace des possibilités=espace de tous les plans possibles) Modèle de coût/ fonction de coût: prédire le coût d’un plan d’exécution Pour comparer les plans d’exécutions, l’optimiser a besoin d’un modèle de coût, qui associe une valeur ou un vecteur de valeurs a chaque plan Ces valeurs sont des estimations de diverses caractéristiques de l’exécution du plan, par exemple le nombre d’E/S disque. Elles se basent sur des informations statistiques maintenues dans le catalogue Estimation des tailles des résultats intermédiaires Stratégie de recherche: Décrit les plans d’exécution qui sont explorés et dans quel ordre, Produit le meilleur plan d’exécution relativement a l’ensemble des plans examinés.

Optimisation physique des requêtes La restructuration algébrique est insuffisante car elle n’ordonne pas les opérations binaires. Aussi l’application d’une sélection initiale peut faire perdre un index qui serait utile pour exécuter une jointure. Solution possible: Générer tous les plans Estimer le coût de chacun Choisir celui du moindre coût. Mais le nombre de plans est très grand Éliminer a priori tous les plans qui font appel a des produits cartésiens Éliminer tous les plans qui n’effectuent pas les sélections des que possible

CARD((R)) = s(critère)*CARD(R) Modèle de coût Nécessite la connaissance : Taille des résultats intermédiaires de toutes les opérations considérées Prise en compte des chemins d’accès aux relations (index, placement…) qui change directement ces coûts. Le modèle simple est celui qui suppose l’uniformité de la distribution des valeurs et l’indépendance des attribut. Un tel modèle nécessite de connaître au minimum: Le nombre de valeur d’un attribut A noté CARD(A) Les valeurs minimum et maximum d’un attribut A, MIN(A), MAX(A) Le nombre de valeurs distinctes de chaque attribut A noté NDIST(A) Le nombre de tuples de chaque relation R noté CARD(R) Le nombre de tuples d’une restriction (R) est alors calculé par la formule: CARD((R)) = s(critère)*CARD(R)

Facteur de sélectivité s(critère) désigne la probabilité que le critère soit vérifié appelé aussi facteur de sélectivité ou prédicat de restriction Coefficient associé a une table représentant la proportion de tuples de la table satisfaisant la condition de sélection.

Sélectivité des Restrictions TAILLE (s(R)) = s * TAILLE(R) avec: s (A = valeur) = 1 / NDIST(A) s(A > valeur) = (max(A) - valeur) / (max(A) - min(A)) s(A < valeur) = (valeur - min(A)) / (max(A) - min(A)) s (A IN liste valeurs) = (1/NDIST(A)) * CARD(liste valeurs) s(P et Q) = s(P) * s(Q) s(P ou Q) = s(P) + s(Q) - s(P) * s(Q) s( not P) = 1 - s(P) Le coût dépend de l'algorithme (index, hachage ou balayage).

Sélectivité des projections Le nombre de tuples d’une projection sur un groupe d’attributs X est plus simplement donnée par la formule: CARD((R))=(1-d)*CARD(R)) Avec d = probabilité de doubles. La probabilité de doubles peut être estimée en fonction du nombre de valeurs distinctes des attributs composant X.

Sélectivité des jointures CARD( R1  R2) = p * CARD(R1) * CARD(R2) p dépend du type de jointure et de la corrélation des colonnes : p = 0 si aucun tuple ne joint p = 1 / MAX(NDIST(A),NDIST(B)) si distribution uniforme équiprobable des attributs A et B sur un même domaine p = 1 si produit cartésien L'algorithme change radicalement les coûts linéaire si index, produit des tailles si boucles imbriquées.

Stratégies de Recherche Le nombre de plans d’exécution possibles peut être très grands pour des questions complexes, afin d’éviter de les explorer tous, les optimiseurs modernes sont construits comme des générateurs de plans couplées a une stratégie de recherche découlant des techniques d’optimisation de la recherche opérationnelle Procédure utilisée par l’optimiseur pour explorer l’espace des plans d’exécutions afin de déterminer un plan de coût proche du minimum possible.

Différentes Stratégies de recherche Enumérative Aléatoire Recuit simulé Exhaustive Amélioration itérative Augmentation Génétique

Stratégies de recherche Stratégies énumératives: Énumèrent systématiquement des plans possibles Stratégies exhaustives: les énumèrent tous Stratégies par augmentation: les construisent progressivement en partant par exemple de la projection finale et en introduisant progressivement les relations par ordre de taille croissante, elle évitera en général les produits cartésiens et appliquera des que possible restriction et projection. Stratégies aléatoires Explorent aléatoirement l’espace des plans L’amélioration itérative: tire au hasard n plans et essaie de trouver pour chacun d’eux le plan optimum le plus proche. L’optimum des plans localement optimum est alors retenu comme plan d’accès La stratégie du recuit simulé procède a partir d’un plan qu’on tente d’optimiser en appliquant les transformations successives. Les transformations retenues améliorent le plan exceptées quelques unes introduites afin d’explorer un espace plus large. Stratégie génétique: visent a fusionner deux plans pour en obtenir un 3eme.

Problème d’ordonnancement Il faut pouvoir ordonner les jointures, union différences en fonction des tailles des relations arguments. Nécessité de développer un modèle de coût général permettant d'évaluer le coût d'un plan, c'est-à-dire d'un arbre annoté par des choix d'algorithmes. Annotation: Marque associée à un noeud indiquant l'algorithme à utiliser pour l'opérateur avec ses paramètres (index, hachage, …)

Optimisation physique Choix des meilleurs algorithmes pour les opérations relationnelles Utilisation des indexs jointure par index , etc... En fonction de Structures de données existantes Statistiques sur les relations Algorithmes existants

Opérateur de jointure Jointure Sans Index Boucles imbriquées Tri fusion Hachage Boucles_Imbriquees(R1,A,R2,B) { Pour chaque tuple de R1 faire { LIRE (R1,Tuple1) Pour chaque tuple de R2 faire {Lire(R2,Tuple2); si tuple1.A=tuple2.B alors Ecrire(Resultat,tuple1||tuple2); } Cout en E/S= Page(R1)+Page(R1)*Page(R2) Tri_Fusion (R1,A,R2,B) { R1T=TRIER(R1,A); R2T=TRIER(R2,B); Resultat=FUSIONNER(R1,R2) } Cout en E/S= Page(R1)*LOG(Page(R1)) + Page(R2)*LOG( Page(R2)) + Page(R1)+ Page(R2)

Opérateur de jointure Jointure avec index: Une des relations (R1) est indexée sur l’attribut de jointure, il suffit de balayer la deuxième relation et d’accéder au fichier indexée pour chaque tuple. Le coût est de l’ordre 3*CARD(R2), en supposant 3 accès en moyenne pour trouver un article dans le fichier indexé Les 2 relations sont indexées sur les attributs de jointure, il suffit de fusionner les 2 index. L’algorithme est peu coûteux en E/S.