Bases de Données Dr. Benjamin NGUYEN UVSQ & INRIA Laboratoire PRiSM, CNRS UMR 8144 Equipe-Projet INRIA SMIS « Secured and Mobile.

Présentation au sujet: "Bases de Données Dr. Benjamin NGUYEN UVSQ & INRIA Laboratoire PRiSM, CNRS UMR 8144 Equipe-Projet INRIA SMIS « Secured and Mobile."— Transcription de la présentation:

1 Bases de Données Dr. Benjamin NGUYEN benjamin.nguyen@inria.fr UVSQ & INRIA Laboratoire PRiSM, CNRS UMR 8144 Equipe-Projet INRIA SMIS « Secured and Mobile Information Systems » Voir site de cours pour CPGE : http://webdam.inria.fr/Lili/ (Avec Serge Abiteboul, Yannick Le Bras et Pierre Senellart)

2 Programme de l’après midi  Séance 1 : Programme de CPGE (Rappels par rapport à l’année dernière) Exercices  Séance 2 : Les transactions ou la gestion de plusieurs utilisateurs

3 Plan Partie I 1.Introduction 2.Les concepts des SGBD 3.Les langages d’interrogation 4.Méthodologie de résolution de problèmes 5.Architectures 6.Exercices

4 Programme officiel 1/3  L’objectif de cette partie de la formation vise à développer les savoir-faire suivants : recourir aux concepts des bases de données relationnelles ; traduire les questions posées dans un langage de requête en respectant sa syntaxe ; prototyper et créer une base de données simple, à l’aide d’un outil interactif ; consulter une base de données à travers des requêtes de type SQL ; comprendre et décrire les rôles des différents éléments d'une architecture trois-tiers.  La formation doit mettre en évidence la nécessité d’un niveau d'abstraction suffisant dans la conception d’outils permettant la gestion de bases de données de taille importante, là où des algorithmes de recherche simples sur des structures « plates », orientées tableaux, deviennent inopérants : les schémas relationnels sont une réponse à ce problème.

5 Programme officiel 2/3 ContenusPrécisions et commentaires Vocabulaire des bases de données : relation, attribut, domaine, schéma de relation ; notion de clé primaire. Ces concepts sont présentés dans une perspective applicative, à partir d’exemples. Opérateurs usuels sur les ensembles dans un contexte de bases de données : union, intersection, différence. Opérateurs spécifiques de l'algèbre relationnelle : projection, sélection (ou restriction), renommage, jointure, produit et division cartésiennes ; fonctions d'agrégation : min, max, somme, moyenne, comptage. Ces concepts sont présentés dans une perspective applicative. Les seules jointures présentées seront les jointures symétriques, simples (utilisant JOIN … ON …=...). Concept de client-serveur. Brève extension au cas de l’architecture trois-tiers. On se limite à présenter ce concept dans la perspective applicative d’utilisation de bases de données.

6 Programme officiel 3/3  La liste suivante énumère un choix non exhaustif d’exercices pratiques. Les bases de données utilisées à des fins d’illustration concerneront de préférence des questions choisies au sein des autres disciplines scientifiques et technologiques. utiliser une application de création et de manipulation de données, offrant une interface graphique, notamment pour créer une base de données simple, ne comportant pas plus de trois tables ayant chacune un nombre limité de colonnes. L’installation et l’exploitation d’un serveur SQL ne fait pas partie des attendus. lancer des requêtes sur une base de données de taille plus importante, comportant plusieurs tables, que les étudiants n'auront pas eu à construire, à l’aide d’une application offrant une interface graphique ; enchaîner une requête sur une base de données et un traitement des réponses enregistrées dans un fichier.  Les principales capacités développées dans cette partie de la formation sont : utiliser une application offrant une interface graphique pour créer une base de données et l’alimenter, utiliser une application offrant une interface graphique pour lancer des requêtes sur une base de données, distinguer les rôles respectifs des machines client, serveur, et éventuellement serveur de données, traduire dans le langage de l’algèbre relationnelle des requêtes écrites en langage courant, concevoir une base constituée de plusieurs tables, et utiliser les jointures symétriques pour effectuer des requêtes croisées.

7 De la difficulté d’interroger les grandes masses de données …  Soit un ensemble de données représentant des clients, leurs comptes en banque et les opérations sur ces comptes.  On souhaite interroger ces données pour retrouver les comptes d’un client, calculer des moyennes, etc. 1.Il faut modéliser ces données (existe-t-il une méthode générique simple applicable?) 2.Il faut définir pour chaque opération d’interrogation un programme qui réalise cette opération. On pourra définir des sous-programmes pour des tâches à réaliser fréquemment. 3.On souhaite rendre les données pérennes : 1. Il faut les sauvegarder sur un média durable 2. Il faut gérer les pannes à tout moment 4.On souhaite modifier les données 5.On souhaite sécuriser l’accès aux données 6.Etc.

8 Exemple : un compte et ses opérations  Définir une structure compte complexe qu’on va mettre dans un tableau. En soi c’est déjà compliqué. struct compte{ identifiant : string; operations : tableau [N] de float ; }  Calculer le solde d’un compte = écrire (puis exécuter) une fonction float solde (compte c){ float somme = 0; for(int i=0;i<N;i++) somme+=e.operations[i]; return somme; }  Stocker les données = définir un format de fichier et les procédures permettant de lire ou écrire des données.  Modifier les données = écrire un programme  Sécuriser les donnée = écrire (plusieurs) programmes  Etc. DEJA SUR CET EXEMPLE CE N’EST PAS SIMPLE !!

9 Les problèmes des systèmes à base de fichiers  Format de fichiers non standards (chacun crée le sien)  Redondance de données (incohérences possibles ou difficiles à gérer)  Écriture d’un programme spécifique pour chaque interrogation : coûts de développement élevés, coûts de maintenance élevés  Gestion des pannes à programmer soi même (l’OS ne suffit pas)  Partage de données difficile  Sécurisation des données difficile BREF TOUT EST A FAIRE SOI-MEME !

10 La réponse « SGBD » = un « package » comprenant :  Indépendance physique Possibilité de modifier les structures de stockage sans modifier les programmes Ecriture des applications par des non- spécialistes des fichiers Meilleure portabilité, indépendance vis-à-vis du matériel  Indépendance logique Possibilité d’ignorer les données d’autres applications Possibilité d’enrichir les applications sans devoir tout réécrire Possibilité de protéger (rendre confidentielles) certaines données  Manipulation aisée Par le biais d’un langage déclaratif (SQL) équivalent à la logique du 1 er ordre  Conception aisée Par le biais de méthodes utilisant des modèles simples à manipuler (Modèle E/A)  Vues multiples (virtuelles) des données  Exécution et optimisation Les requêtes sont traduites en un langage procédural (algèbre relationnelle) … qui peut être optimisé automatiquement. (des années de recherche en BD…)  Intégrité logique (Contraintes d’intégrité) Par le biais d’un langage déclaratif Détection de mises à jour erronées Contrôle sur les données élémentaires et les relations  Intégrité physique Tolérence aux pannes Transactions Système (panne courrant) Disque (crash)  Partage de données Isolation (chacun a l’air d’être seul) Concurrence (tout le monde peut agir en même temps)  Confidentialité  Standardisation Cours 2

11 I - Le Modèle Entité – Association (E/R Model) - HP  Ensemble de concepts pour modéliser les données d'une application (d'une entreprise)  Ensemble de symboles graphiques associés  Formalisé en 1976 par Peter Chen dans : The Entity-Relationship model, towards a unified view of data, in ACM Transactions on Database Systems, 1(1), pp 9-36, 1976  Etendu vers E/R généralisé puis vers l'objet  Permet de créer ensuite des schémas relationnels facilement

12 Un exemple de modèle Entité-Association

13 B. Nguyen Compte Opération Client Subit Possède Ville NCo Type NODateMontant Prenom Nom 1..* 1..1 0..* Entité Association Cardinalité Clés Primaires : - (NC) clé de Compte - (NO) clé de Opération - (Nom, Prénom) clé de Client Attribut Cardinalités : Notation MinMax (ISO)

14 II - Les concepts  Domaine D (ou type) Les entiers, les chaînes de caractères de longueur 32, les pays, les couleurs aux cartes, etc.  Attribut : un couple nom/domaine (= Colonne en SQL)  Variable de relation : un ensemble ordonné d’attributs (sert d’entête à une relation) (Nom:String, Age:Int)  Tuple (n-uplet) : un ensemble ordonné de couples attribut/valeur (= Rangée ou Row en SQL) (Nom: Toto, Age : 18)  Relation : un ensemble de tuples (= Table en SQL) Toto18 Titi22 Tata20 Etudiants Nom Age

15 Définitions 1/2  Soit D={D i } un ensemble de domaines. String, int, etc.  Soit C un ensemble (fini) d’attributs A i (colonnes) sur des domaines D i C={NOM:string, PRENOM: string, NC:int, …}  Soit R un ensemble fini de noms de relations (représentent des concepts ou associations de concepts). R={RESPONSABLE, COURS, ETUDIANT, INSCRIT}  Soit h une fonction R  2 C qui à une relation associe un sous ensemble de C, appelé schéma (relationnel) de la relation r h(RESPONSABLE)={NR:int, NOM:string, PRENOM:string} …  On dit que S=(D, R, h) est un schéma (d’une base de données). e.g. RESPONSABLE (NR:int, NOM:string, PRENOM:string) COURS (NC:int, CODE_COURS:string, INTITULE:string) ETUDIANT (NE:int, NOM:string, PRENOM:string) INSCRIT (NE:int, NC:int,ANNEE:int)

16 Définitions 2/2  Un tuple (ou n-uplet) est défini comme une fonction partielle de C  D 0  D 1  … (i.e. cette fonction donne une valeur à un attribut) t 1 =(NE: 123456, NOM: «Marie », PRENOM: « LEGRAND »)  Le sous ensemble de C sur lequel t est défini est appelé domaine de t et noté dom(t).  L’ensemble de tous les tuples possibles (sur D) est noté T D  Etant donné un schéma S=(D, R, h), une base de données relationnelle DB est définie comme une fonction de R  2 TD qui associe à chaque relation r de R un sous-ensemble fini de T D tel que pour chaque tuple t de ce sous-ensemble h(r)=dom(t)

17 La Clé : un concept fondamental… qu’on n’exploitera pas dans le programme.  GROUPE D'ATTRIBUTS MINIMUM QUI DETERMINE UN TUPLE UNIQUE DANS UNE RELATION = clé « candidate »  Exemples: Ajouter NUMETU dans ETUDIANTS …ou bien un ensemble d’attributs dont la valeur est unique!  Dans un SGBD, pour chaque relation une clé (la plus simple possible) est choisie, et est appelée clé primaire de la relation. (utile pour l’indexation – HP) Si on définit pas de clé, alors on pourrait penser que canoniquement l’ensemble des attributs composant le domaine de la relation sera une clé. (pas tout à fait vrai : SQL gère des multi-ensembles)

18 Notations  NOM DE LA RELATION, LISTE DES ATTRIBUTS AVEC DOMAINES, ET LISTE DES CLES D'UNE RELATION  Exemple: ETUDIANTS(NE: Int, NOM:texte, DATENAISS:entier, VILLE:texte, SECTION:texte) Par convention, seule la clé primaire est soulignée  INTENTION ET EXTENSION Un schéma de relation définit l'intention de la relation Une instance de table représente une extension de la relation  SCHEMA D'UNE BD RELATIONNELLE C'est l'ensemble des schémas des relations composantes  PLUS DES CONTRAINTES (HP) Contraintes d’intégrité Dépendances fonctionnelles

19 Clé Etrangère (HP)  GROUPE D'ATTRIBUTS DEVANT APPARAITRE COMME CLE DANS UNE AUTRE RELATION  Les clés étrangères définissent les contraintes d'intégrité référentielles Lors d'une insertion, la valeur des attributs doit exister dans la relation référencée Lors d'une suppression dans la relation référencée les tuples référençant doivent disparaître Elles correspondent aux liens entité-association obligatoires

20 Normalisation / Dépendances fonctionnelles (HP)  Une dépendance fonctionnelle permet d’indiquer que certains attributs dépendent d’autres attributs e.g. La valeur de la prime d’un employé dépend de son poste i.e. SECTION  DEPARTEMENT ou (PRODUIT, QUANTITE)  PRIX  Formes normales : on divise la relation en attributs clé et attributs non clé 1 ère forme normale Tous les attributs sont monovalués (et la relation doit avoir une clé) 2 e forme normale Les attributs non clé ne peuvent pas dépendre d’un sous-ensemble d’une clé candidate 3 e forme normale Les attributs non clé ne peuvent pas dépendre d’un sous-ensemble d’attributs non clé Boyce-Codd NF Les attributs clé ne peuvent pas dépendre d’un sous-ensemble d’attributs non clé. « The key, the whole key, nothing but the key, so help me Codd » Permet de réaliser un « bon » schéma relationnel (éviter les redondances, et donc les problèmes de mise à jour). Par contre ça demande de faire plus de jointures …

21 Exemple de Schéma  EXEMPLE client (idclient, nom, prenom, ville) compte (idcompte, idproprietaire, type) operation(idop, idcompte, montant, informations)  CLES ETRANGERES compte.idproprietaire references client.idclient operation.idcompte references compte.idcompte  CLES CANDIDATES UNIQUE(client.nom, client.prenom, client.ville) Compte Opération Client Subit Possède Ville idcompte Type idoperationinfosMontant Prenom Nom 1..* 1..1 0..* idclient

22 Synthèse : Syntaxe SQL  CREATION DES TABLES EN SQL CREATE TABLE ( +) [{PRIMARY KEY | UNIQUE} ( +)]  avec : ::= [NOT NULL [{UNIQUE | PRIMARY KEY}] ]  Exemple : CREATE TABLE client ( idclient int(5) NOT NULL, nom varchar(128) NOT NULL, prenom varchar(128) NOT NULL, ville varchar(128) NOT NULL, PRIMARY KEY (idclient) ); Les tables sont la plupart du temps créées via une interface. Le code SQL sert à les créer« automatiquement »

23 III – Langages d’interrogation  Dans la suite nous allons décrire 2 approches/langages « équivalentes » L’algèbre relationnelle : langage impératif (procédural) La « syntaxe » Structures Query Language (SQL), un langage déclaratif utilisant les opérateurs de l’algèbre relationnelle.  Il existe une 3 e approche, non détaillée ici, et hors programme, le calcul relationnel (présenté l’année dernière): langage déclaratif (intentionnel) dérivé de la logique du premier ordre.  Les parties « de base » de ces trois langages sont équivalents (au sens du pouvoir expressif) selon le théorème de Codd (1970)  Les 3 langages utilisent des concepts proches, et des noms parfois différents.

24 Comment interroger une BD  Un ensemble d’expressions formelles Calcul relationnel (déclaratif = impossible à implémenter, facile à énoncer) Algèbre relationnelle (procédural = possible à implémenter, dur à énoncer)  Ces opérations permettent d'exprimer toutes les requêtes sous forme d'expressions algébriques qui pourront être exécutées et optimisées  Elles sont la base du langage SQL qui est un langage déclaratif Paraphrasage en anglais des expressions du calcul relationnel  Ces opérations sont extensibles

25 Les requêtes du calcul relationnel (HP)  Le calcul relationnel se décline de deux manières Calcul relationnel de tuples Calcul relationnel de domaines  Ce sont des fragments de la logique du premier ordre e.g.  ne, nometu, date, ville | Etudiant(ne, nometu, date, ville)  ns, nomsec | Section(ns, nomsec)  annee | Inscrit(ne, ns, annee)

26 Calcul Relationnel de tuples : Atomes (HP)  Les formules atomiques (ou atomes) sont des formules terminales (i.e. elles n’incluent aucune autre proposition)  Soit V un ensemble de variables (à valeurs dans l’ensemble des tuples)  Les atomes autorisés sont les suivants : si v  V, w  V, a  dom(v), b  dom(w) alors v.a = w.b est un atome e.numetu = i.numetu si v  V, a  dom(v), k  D alors v.a = k est un atome e.ville = Versailles si v  V, r  R, dom(v)=h(r) alors r(v) est un atome Etudiant(e)  La sémantique formelle est définie étant donnée une base de données et une affectation des variables à des tuples.

27 Calcul Relationnel de tuples : Formules et Requêtes (HP)  Les atomes peuvent être combinées en formules selon la grammaire suivante : Atome = {v.a = v.b | v.a = k | r(v)} Formule = {Atome | Formule 1  Formule 2 | Formule 1  Formule 2 |  Formule 1 |  v:H (Formule 1 ) |  v:H (Formule 1 )}  t : {idclient, nom, prenom, ville} (client(t) ∧ t.ville = « Versailles »} Signifie : il existe un client habitant à Versailles  Une requête est de la forme : {v : H | Formule(v)} {e : {nom} |  t : {idclient, nom, prenom, ville} (t.nom = e.nom ∧ client(t) ∧ t.ville = « Versailles »} Signifie : Trouver le nom de tous les clients Versaillais /!\ On ne gère pas les agrégats, il faut étendre le formalisme

28 A quoi ça sert ? A EXPRIMER FACILEMENT DES REQUETES ! (pour des mathématiciens/logiciens ) Comme c’est pas si simple pour le commun des mortels, on a inventé SQL ! (on va voir ça plus tard) Mais comment calculer le résultat d’une requête ?  avec l’algèbre relationnelle

29 Les opérations de l’algèbre relationnelle ETUDIANTSECTION INSCRIT NE NOM DN NOMV NS NOM DPT ANNEE 1..10..* VILLE DPT VIT A 1..1 0..* Etudiant(NE, NOM, DN, VILLE) Ville(NOMV, DPT) Section(NS, NOM, DPT) Inscrit(NE, NS, ANNEE)

30 Opérations Ensemblistes Classiques  Opérations binaires pour des relations de même schéma (on peut donner une sémantique formelle) UNION notée  INTERSECTION notée  DIFFERENCE notée —  Opérations binaires pour des relation de schéma différents Produit cartésien  Pas d’opérations unaires  Extension Union externe pour des relations de schémas différents Ramener au même schéma avec des valeurs nulles

31 Exemple de Produit Cartésien VILLENOMVDPT VERSAILLES 78 PARIS 75 Q NOMDNVILLE NOMV DPT ETU NOMDNVILLE ANNE1991 VERSAILLES BERNARD1993 PARIS CELINE 1993 PARIS DAVID1991 VERSAILLES ANNE1991 VERSAILLESVERSAILLES78 ANNE1991 VERSAILLESPARIS75 BERNARD1993 PARISVERSAILLES78 BERNARD1993 PARISPARIS75 CELINE 1993 PARISVERSAILLES78 CELINE 1993 PARISPARIS75 DAVID1991 VERSAILLESVERSAILLES78 DAVID1991 VERSAILLESPARIS75 Q=ETU × VILLE × Q = R × S = { q:{q 1,...,q n } |  r  R,  s  S (q 1 =r 1  q 2 =r 2 …  q k =r k  q k+1 =s 1 …  q n =s p ) } Sémantique Formelle :

32 Projection  Elimination des attributs non désirés et suppression des tuples en double  Relation  Relation notée:  A1,A2,...Ap (R) ETU NOMDNVILLE 1991VERSAILLES 1993PARIS 1993VELIZY  DN,VILLE (ETU) DNVILLE  DN,VILLE (ETU) ANNE1991 VERSAILLES BERNARD1993 PARIS CELINE 1993 PARIS DAVID1991 VERSAILLES EMILIE1993 VELIZY Q =  (R) = { q:{q 1,...,q p } |  r :{r 1,...,r n }  R (q 1 =r 1  q 2 =r 2 …  q p =r p ) } Sémantique Formelle :

33 Restriction  Obtention des tuples de R satisfaisant un critère Q  Relation  Relation, notée  Q (R)  Q est le critère de qualification de la forme : A i  Valeur  { =, =, >, <=, !=}  Il est possible de réaliser des "ou" (union) et des "et" (intersection) de critères simples S =  Q  (R) = { s:{s 1,...,s n } |  r :{r 1,...,r n }  R (s 1 =s 1  s 2 =s 2 …  s n =r n  Q(r 1 …r n ) } Sémantique Formelle :

34 Exemple de Restriction  DN>1992 (ETU) ETU NOMDNVILLE ANNE1991 VERSAILLES BERNARD1993 PARIS CELINE 1993 PARIS DAVID1991 VERSAILLES EMILIE1993 VELIZY ETU NOMDNVILLE BERNARD1993 PARIS CELINE 1993 PARIS EMILIE1993 VELIZY

35 Jointure  Composition des deux relations sur un domaine commun  Relation X Relation ->Relation notée  Critère de jointure Attributs de même nom égaux : Attribut = Attribut Jointure naturelle Se fait en principe en utilisant une clé étrangère !!! Comparaison d'attributs : Attribut1  Attribut2 Théta-jointure  Sémantique formelle : La jointure peut se voir comme un produit cartésien, combiné à une restriction sur l’attribut de jointure, puis d’une projection pour éliminer l’attribut doublon.

36 Exemple de Jointure VILLENOMVDPT VERSAILLES 78 PARIS 75 R NOMDNVILLEDPT ETU NOMDNVILLE ANNE1991 VERSAILLES BERNARD1993 PARIS CELINE 1993 PARIS DAVID1991 VERSAILLES ANNE1991 VERSAILLES78 BERNARD1993 PARIS75 CELINE 1993 PARIS75 DAVID1991 VERSAILLES78 ETU.VILLE = VILLE.NOMV R=ETU VILLE

37 Jointure et Produit Cartésien R1R1 R2R2 A = B Équivaut à :  A=B (R 1 × R 2 ) R NOMDNVILLE NOMV DPT ANNE1991 VERSAILLESVERSAILLES78 ANNE1991 VERSAILLESPARIS75 BERNARD1993 PARISVERSAILLES78 BERNARD1993 PARISPARIS75 CELINE 1993 PARISVERSAILLES78 CELINE 1993 PARISPARIS75 DAVID1991 VERSAILLESVERSAILLES78 DAVID1991 VERSAILLESPARIS75

38 Division – peu usitée, peu implémentée  L’opération de division permet d’implémenter le « quel que soit » de la logique du premier ordre. L’opérateur est défini pour deux relation R et S telle que dom(S)  dom(R) et s’écrit : Q=R  S Q a la propriété suivante : Q  S  R  Sémantique formelle : On note dom(R) = {r 1..r i, s 1..s j } tel que dom(S) = {s 1..s j } R ÷ S = { t:{r 1,...,r n } | t  R  s  S ( (t[r 1,...,r n ]  s)  R) }  L’opération est peu utilisé en pratique  L’opérateur en lui-même n’existe pas en SQL  L’opération Q=R  S se réalise par : T =  r1..ri (R)  S (tous les tuples possibles) U = T – R (les tuples qui ne sont pas dans R) V =  r1..ri (U) Q =  r1..ri (R) – V

39 A quoi ça sert ? A EXECUTER  Une expression de l’algèbre relationnelle peut se lire de manière fonctionnelle comme un plan d’exécution de la requête. i.e. si on a implémenté les opérateurs de l’algèbre relationnelle, et qu’on utilise des structures de type relation il me suffit de les appeler en passant en paramètre les relations en question !  Les plans sont souvent représentés sous forme d’arbre. A OPTIMISER  Il est important de noter que certaines opérations sont commutatives, c’est la base de l’optimisation des requêtes.

40 Pourquoi ça marche ? Complétude Relationnelle  Théorème de Codd : l'algèbre relationnelle a un pouvoir expressif équivalent à celui du calcul relationnel. (article Relational completeness of data base sublanguages) Les cinq (sept) opérations de base permettent de formaliser sous forme d'expressions toutes les questions que l'on peut poser avec la logique du premier ordre.  Exemple : Nom et Section des étudiants de Versailles nés en 1991 ? Algèbre Relationnelle :  NOM, NOMSEC (  DATEN=1991 ET VILLE=« VERSAILLES » ( ETU INSCR SECTION ) Calcul Relationnel : {t:{nom, nomsec} |  e:{ne, nom, ville, datenaiss}, i:{ne, ns},s:{ns, nomsec} (etu(e)  inscription(i)  section(s)  t.nom = e.nom  t.nomsec = s.nomsec  i.ne=e.ne  i.ns=s.ns  e.datenaiss = 1991  e.ville = « Versailles »)

41 Et SQL ?  Une requête SQL (donc une description en langage « naturel ») peut se traduire sous la forme d’une expression de l'algèbre relationnelle (en fait SQL va plus loin : en particulier avec les agrégations)  Requête élémentaire : SELECT A 1, A 2, …A p FROM R 1, R 2, …R k WHERE Q [{UNION |INTERSECT | EXCEPT } … ]  « Sémantique » du bloc select avec l’algèbre:  A1,A2,…Ap (  Q (R 1 × R 2 × … × R k ) ) ) /!\ UN PRODUIT CARTESIEN N’EST PAS UNE JOINTURE !!!  Et pourtant SQL est déclaratif … ? {t:{A 1, A 2, … A n } |  x 1 :{…}, x 2 :{…}, …x n :{…} k (Q(x 1, x 2,…x n )  LIEN(t, x 1, x 2, …x n )} NB: LIEN inclue l’appartenance d’un x i à une relation  Tout le problème réside dans la manière de calculer Q !

42 Principe de fonctionnement du moteur d’exécution du SGBD 1.On écrit sa requête en SQL 2.Cette requête a une sémantique formelle donnée par le calcul relationnel 3.Cette requête est traduite (et optimisée) en utilisant l’algèbre relationnelle

43 Exemple d’exécution et optimisation (HP) Produit Cartésien X R S Projection idclient, idcompte Différence _ S R Union R S U Selection Jointure R.a = S.b S R type=‘PEA’

44 Ex. Plan d’exécution candidat (1) idproprietaire Client Compte Operation = idclient idcompte = idoperation R prenom = « Sylvie » ^ date > 1/1/2014 ^ type = « PEA » Plan candidat N°1 Liste des idcompte, idoperation de tous les clients se prénommant « Sylvie » ayant un « PEA » après le « 1/1/2014 » Requête

45 Ex. Plan d’exécution candidat (2) CLIENT Compte Operation prenom = "Sylvie" date > "1/1/2014" type = “PEA" idclient = idcompte = idoperation R Idproprietaire type = “PEA" CLIENT Compte Operation prenom = “Sylvie" date> " 1/1/2014 " idclient idcompte idproprietaire = = idcompte idoperation R Plan candidat N°2 Plan candidat N°3 De ces 3 arbres, lequel est le meilleur ?

46 Ex. Plan d’exécution candidat (2) CLIENT Compte Operation prenom = "Sylvie" date > "1/1/2014" type = “PEA" idclient = idcompte = idoperation R Idproprietaire type = “PEA" CLIENT Compte Operation prenom = “Sylvie" date> " 1/1/2014 " idclient idcompte idproprietaire = = idcompte idoperation R Plan candidat N°2 Plan candidat N°3 De ces 3 arbres, lequel est le meilleur ? Le premier est sûrement moins bon, mais les 2 derniers ?

47 Renommage  Pour changer le nom d’une colonne.  Notation simple en algèbre relationnelle:  A  B (R)  Exemple : ETU2 =  DN  DATEN (ETU1) ETU1 NOMDNVILLE BERNARD1993 PARIS CELINE 1993 PARIS EMILIE1993 VELIZY ETU2 NOMDATENVILLE BERNARD1993 PARIS CELINE 1993 PARIS EMILIE1993 VELIZY

48 B. Nguyen 48 Projection implicite sur ces colonnes Fonctions et Agrégats  FONCTION Fonction de calcul en ligne appliquée sur un ou plusieurs attributs Exemple : INTERETS = SOLDE*1,5/100  AGREGAT Partitionnement horizontal d'une relation selon les valeurs d'un groupe d'attributs (B i ), suivi d'un regroupement par une (ou plusieurs) fonction(s) F i de calcul en colonne (SUM, MIN, MAX, AVG, COUNT, …) sur les attributs C i respectifs  NOTATION : gamma minuscule  (R) F 1 (C 1 ), F 2 (C 2 ), …,F N (C N ) B 1, B 2, …,B N

49 Exemples d'agrégats AVG(AGE) 19.75 VILEMAX(AGE) VERSAILLES PARIS 21 19 SQL : SELECT VILLE, MAX(AGE) FROM ETU GROUP BY VILLE; ETU NOMAGEVILLE ANNE21 VERSAILLES BERNARD19 PARIS CELINE 19 PARIS DAVID20 VERSAILLES SQL : SELECT AVG(AGE) FROM ETU;  AVG(AGE) (ETU) VILLE  MAX(AGE) (ETU) /!\ le HAVING se fait tout simplement avec un 

50 IV - Méthodologie Cette méthodologie se propose de remplir une requête de type SELECT...FROM...WHERE... de la manière suivante (étant donné une question). 1.Construction de la clause SELECT 2.Construction des groupes 3.Construction des restrictions 4.Construction des jointures 5.Construction des sous-requêtes

51 Méthodologie Construction de la clause SELECT 1. Identifier les attributs qui doivent être affichés, et les tables les contenant. 2. Mettre ces tables dans la clause FROM et donner un nom de variable à chaque table. 3. Mettre les attributs à affichés, préfixés par le nom de variable de la table correspondante dans la clause SELECT 4. Identifier les fonctions à calculer, et les attributs nécessaires au calcul de ces fonctions, puis si nécessaire, ajouter des tables supplémentaires dans la clause FROM, et enfin ajouter la fonction dans la clause SELECT

52 Méthodologie Construction des groupes 1. Identifier les attributs utilisés pour le partitionnement et les mettre dans la clause GROUP BY. 2. Compléter si nécessaire les tables de la clause FROM. 3. Compléter la clause SELECT en rajoutant les attributs utilisés pour le partitionnement. En général, ces attributs auront déjà été identifiés car ils vont a priori apparaître dans le résultat final, puisqu’ils s’agissent de critères de regroupement. En effet, est ce qu’une requête qui calculerait le revenu moyen en fonction de la ville et qui n’afficherait pas le nom de la ville de chaque groupe aurait une quelconque utilité ?

53 Méthodologie Construction des restrictions 1. Regarder sur quels attributs (ou groupes d’attributs) de quelles tables portent les restrictions. 2. Rajouter ces tables, si elles ne sont pas encore présentes, dans la clause FROM. 3. Rajouter les restrictions sur les attributs en question dans la clause WHERE. Attention, il est capital de noter qu’une condition de restriction peut tout à fait s’exprimer en utilisant une sous-requête (voir plus bas). 4. Rajouter les restrictions qui portent sur des valeurs agrégées dans la clause HAVING.

54 Méthodologie Construction des jointures Rajouter dans la clause WHERE les conditions de jointure, permettant de lier toutes les tables de la clause FROM les unes aux autres. Une telle jointure se fait en utilisant les clés étrangères des tables en question. Il peut arriver qu’il ne soit pas possible de lier une table aux autres. Cela signifie qu’il faudra introduire une ou plusieurs autres tables intermédiaires permettant de lier cette table par le biais d’un chemin composé de clés étrangères. En général, une clé étrangère est mono-valuée, donc si on a n tables dans la clause FROM il faudra avoir n − 1 conditions de jointure dans la clause WHERE.

55 Méthodologie Construction des sous requêtes Pour chaque sous requête utilisée dans la clause WHERE, vérifier qu’elle a besoin ou non d’être paramétrée. 1. Une sous requête non paramétrée signifie que sa valeur ne dépend pas du moment où elle est calculée. Une telle requête s’écrit directement dans la clause WHERE sans difficulté. e.g. une sous requête peut être utilisée pour calculer le salaire moyen. 1. Une sous requête paramétrée signifie que sa valeur dépend de la ligne qui est en train d’être traitée. Dans ce cas, celle-ci devra avoir une condition de paramétrisation dans la clause WHERE. Cette condition de paramétrisation fera intervenir un identifiant de table de la requête « extérieure ». e.g. le fait qu’un idproprietaire donné possède un compte de type Livret A est une sous requête paramétrée.

56 V- Architecture Client/Server ou 3-Tiers  Le SGBD tourne sur une machine (c’est le serveur SGBD) Cette machine peut directement être interrogée par un programme « client ». On parle alors d’architecture client/serveur. Cette approche nécessite l’utilisation d’un programme client spécifique. Dans de nombreux cas, le programme client est un navigateur Web (Firefox, IE, Chrome, etc.) Un tel client n’a pas les capacités d’interroger directement un SGBD. En revanche, il sait très bien interroger un serveur web (apache, WebSphere, etc.), qui lui devra savoir interroger le SGBD (ce qui se fait via des programmes spécifiques). On parle alors d’architecture 3-Tiers (serveur SGBD serveur Web navigateur) D’une manière plus générale le 3-Tiers rajouter une couche intermédiaire dite de « traitement métier » entre le SGBD et la couche de présentation

57 Comparaison Client/Serveur  fonctionnement sans intermédiaires superflus.  nécessite le développement d’une application « métier » spécifique à chaque fois.  permet une gestion des droits directement sur le SGBD. Architecture 3-Tiers  allègement du poste de travail client  prise en compte de l'hétérogénéité des plates-formes (serveurs, clients, langages, etc.)  le serveur SGBD n’est pas (forcément) ouvert sur internet  meilleure sécurité  meilleure répartition de la charge entre différents serveurs d'application. En particulier, il permet de décharger le SGBD (/!\ ce n’est pas forcément une optimisation que de travailler avec un langage procédural plutôt qu’avec SQL…)

58 VI - Exercices 1.Nom et Prenom de tous les clients habitant à Paris. 2.idcompte et type de tous les comptes de toutes les personnes se prénommant ‘Marie’ (avec une jointure plutôt qu’une requête imbriquée) 3.Nom et Prenom des clients n’ayant pas de compte de type ‘Livret A’ 4.Solde de chaque compte, identifié par son idcompte. Idem en rajoutant le propriétaire du compte à côté. Idem pour les comptes uniquement débiteurs. 5.Nombre moyen de comptes par client. 6.Nombre de comptes possédé par chaque client (liste exhaustive). 7.Liste des idproprietaire possédant moins de comptes que la moyenne.

59 Les Transactions (HP) Transparents de mon cours en M2 « Mécanismes Internes des SGBD » Certains transparents ont été réalisés par : N. Anciaux, L. Bouganim, P. Pucheral, G. Gardarin