Bases de Données II Rappels

Présentation au sujet: "Bases de Données II Rappels"— Transcription de la présentation:

1 Bases de Données II Rappels
Benjamin NGUYEN 4A STI

2 Rappels 0. Introduction La modélisation E/A Les concepts des SGBD
Les langages d’interrogation Méthodologie de résolution de problèmes Exercices

3 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 !

4 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 1er 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é / Sécurité (Cours 5A) Standardisation ACID = atomicity, consistency, isolation, durability

5 I - Le Modèle Entité – Association (E/R Model)
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

6 Un exemple de modèle Entité-Association

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

8 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) Etudiants Nom Age Toto 18 Titi Tata 20

9 Définitions 1/2 Soit D={Di} un ensemble de domaines.
String, int, etc. Soit C un ensemble (fini) d’attributs Ai (colonnes) sur des domaines Di 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2C 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)

10 Définitions 2/2 Un tuple (ou n-uplet) est défini comme une fonction partielle de CD0´D1´… (i.e. cette fonction donne une valeur à un attribut) t1=(NE: , 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é TD Etant donné un schéma S=(D, R, h), une base de données relationnelle DB est définie comme une fonction de R2TD qui associe à chaque relation r de R un sous-ensemble fini de TD tel que pour chaque tuple t de ce sous-ensemble h(r)=dom(t)

11 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) 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) 9

12 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 Contraintes d’intégrité Dépendances fonctionnelles 10

13 Clé Etrangère 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 11

14 Normalisation / Dépendances fonctionnelles
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é) 2e forme normale Les attributs non clé ne peuvent pas dépendre d’un sous-ensemble d’une clé candidate 3e 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 …

15 Exemple de Schéma EXEMPLE CLES ETRANGERES CLES CANDIDATES Type
idcompte 1..* 1..* Compte Possède Client 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) 0..* idclient Prenom Subit Nom Ville 1..1 Opération idoperation Montant infos 12

16 Synthèse : Syntaxe SQL CREATION DES TABLES EN SQL CREATE TABLE <relation name> (<attribute definition>+) [{PRIMARY KEY | UNIQUE} (<attribute name>+)] avec : <attribute definition> ::= <attribute name> <data type> [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 » 15

17 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 3e 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.

18 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 16

19 Les requêtes du calcul relationnel
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)

20 Calcul Relationnel de tuples : Atomes
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.

21 Calcul Relationnel de tuples : Formules et Requêtes
Les atomes peuvent être combinées en formules selon la grammaire suivante : Atome = {v.a = v.b | v.a = k | r(v)} Formule = {Atome | Formule1 Ù Formule2 | Formule1 Ú Formule2 | ØFormule1 | $v:H (Formule1) | "v:H (Formule1)} $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

22 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

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

24 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 17

25 Exemple de Produit Cartésien
Sémantique Formelle : Q = R × S = { q:{q1,...,qn} | $ rÎR, $ sÎS (q1=r1Ùq2=r2…Ùqk=rkÙqk+1=s1…Ùqn=sp) } Q=ETU × VILLE ETU NOM DN VILLE VILLE NOMV DPT ANNE VERSAILLES BERNARD PARIS CELINE PARIS DAVID VERSAILLES × VERSAILLES PARIS Q NOM DN VILLE NOMV DPT ANNE VERSAILLES VERSAILLES 78 ANNE VERSAILLES PARIS 75 BERNARD PARIS VERSAILLES 78 BERNARD PARIS PARIS 75 CELINE PARIS VERSAILLES 78 CELINE PARIS PARIS 75 DAVID VERSAILLES VERSAILLES 78 DAVID VERSAILLES PARIS 75

26 Projection DN,VILLE(ETU)  A1,A2,...Ap (R)
Elimination des attributs non désirés et suppression des tuples en double Relation  Relation notée:  A1,A2,...Ap (R) ETU NOM DN VILLE ANNE VERSAILLES BERNARD PARIS CELINE PARIS DAVID VERSAILLES EMILIE VELIZY DN,VILLE(ETU) DN,VILLE(ETU) DN VILLE VERSAILLES PARIS VELIZY Sémantique Formelle : Q = P(R) = { q:{q1,...,qp} | $ r :{r1,...,rn} ÎR (q1=r1Ùq2=r2…Ùqp=rp) } 18

27 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 : Ai Valeur Î { =, <, >=, >, <=, !=} Il est possible de réaliser des "ou" (union) et des "et" (intersection) de critères simples Sémantique Formelle : S = sQ (R) = { s:{s1,...,sn} | $ r :{r1,...,rn} ÎR (s1=s1Ùs2=s2…Ùsn=rnÙQ(r1…rn) } 19

28 Exemple de Restriction
ETU NOM DN VILLE ANNE VERSAILLES BERNARD PARIS CELINE PARIS DAVID VERSAILLES EMILIE VELIZY DN>1992 (ETU) ETU NOM DN VILLE BERNARD PARIS CELINE PARIS EMILIE VELIZY 20

29 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 q 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. 21

30 Exemple de Jointure R=ETU VILLE VERSAILLES 78 PARIS 75
ETU NOM DN VILLE ANNE VERSAILLES BERNARD PARIS CELINE PARIS DAVID VERSAILLES R=ETU VILLE VILLE NOMV DPT ETU.VILLE = VILLE.NOMV VERSAILLES PARIS ETU.VILLE = VILLE.NOMV R NOM DN VILLE DPT ANNE VERSAILLES 78 BERNARD PARIS 75 CELINE PARIS 75 DAVID VERSAILLES 78 22

31 Jointure et Produit Cartésien
sA=B(R1 × R2) Équivaut à : A = B R NOM DN VILLE NOMV DPT ANNE VERSAILLES VERSAILLES 78 ANNE VERSAILLES PARIS 75 BERNARD PARIS VERSAILLES 78 BERNARD PARIS PARIS 75 CELINE PARIS VERSAILLES 78 CELINE PARIS PARIS 75 DAVID VERSAILLES VERSAILLES 78 DAVID VERSAILLES PARIS 75

32 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) = {r1..ri, s1..sj} tel que dom(S) = {s1..sj} R ÷ S = { t:{r1,...,rn} | tÎR Ù"sÎS ( (t[r1,...,rn]´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 = Pr1..ri(R)´S (tous les tuples possibles) U = T – R (les tuples qui ne sont pas dans R) V = Pr1..ri(U) Q = Pr1..ri(R) – V

33 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.

34 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 : PNOM, NOMSEC (sDATEN=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 ») 23

35 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 A1, A2, …Ap FROM R1, R2, …Rk WHERE Q [{UNION |INTERSECT | EXCEPT } … ] « Sémantique » du bloc select avec l’algèbre: PA1,A2,…Ap ( sQ (R1 × R2 ×… × Rk) ) ) /!\ UN PRODUIT CARTESIEN N’EST PAS UNE JOINTURE !!! Et pourtant SQL est déclaratif … ? {t:{A1, A2, … An} | $x1:{…}, x2:{…}, …xn:{…}k (Q(x1, x2,…xn) Ù LIEN(t, x1, x2, …xn)} NB: LIEN inclue l’appartenance d’un xi à une relation Tout le problème réside dans la manière de calculer Q ! 24

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

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

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

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

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

41 Renommage rAB (R) Pour changer le nom d’une colonne.
Notation simple en algèbre relationnelle: rAB (R) Exemple : ETU2 = rDNDATEN (ETU1) ETU NOM DN VILLE ETU NOM DATEN VILLE BERNARD PARIS CELINE PARIS EMILIE VELIZY BERNARD PARIS CELINE PARIS EMILIE VELIZY

42 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 (Bi), suivi d'un regroupement par une (ou plusieurs) fonction(s) Fi de calcul en colonne (SUM, MIN, MAX, AVG, COUNT, …) sur les attributs Ci respectifs NOTATION : gamma minuscule g (R) B1, B2, … ,BN F1(C1), F2(C2), …,FN(CN) Projection implicite sur ces colonnes 26

43 Exemples d'agrégats gAVG(AGE)(ETU) VILLE gMAX(AGE)(ETU)
ETU NOM AGE VILLE ANNE VERSAILLES BERNARD PARIS CELINE PARIS DAVID VERSAILLES gAVG(AGE)(ETU) VILLE gMAX(AGE)(ETU) SQL : SELECT AVG(AGE) FROM ETU; SQL : SELECT VILLE, MAX(AGE) FROM ETU GROUP BY VILLE; AVG(AGE) 19.75 /!\ le HAVING se fait tout simplement avec un s VILE MAX(AGE) VERSAILLES 21 PARIS 19 27

44 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). Construction de la clause SELECT Construction des groupes Construction des restrictions Construction des jointures Construction des sous-requêtes 32 44

45 Méthodologie Construction de la clause SELECT
Identifier les attributs qui doivent être affichés, et les tables les contenant. Mettre ces tables dans la clause FROM et donner un nom de variable à chaque table. Mettre les attributs à affichés, préfixés par le nom de variable de la table correspondante dans la clause SELECT 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 32 45

46 Méthodologie Construction des groupes
Identifier les attributs utilisés pour le partitionnement et les mettre dans la clause GROUP BY. Compléter si nécessaire les tables de la clause FROM. 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é ? 32 46

47 Méthodologie Construction des restrictions
Regarder sur quels attributs (ou groupes d’attributs) de quelles tables portent les restrictions. Rajouter ces tables, si elles ne sont pas encore présentes, dans la clause FROM. 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). Rajouter les restrictions qui portent sur des valeurs agrégées dans la clause HAVING. 32 47

48 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. 32 48

49 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. 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. 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. 32 49

50 V - Exercices Nom et Prenom de tous les clients habitant à Paris.
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) Nom et Prenom des clients n’ayant pas de compte de type ‘Livret A’ 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. Nombre moyen de comptes par client. Nombre de comptes possédé par chaque client (liste exhaustive). Liste des idproprietaire possédant moins de comptes que la moyenne. 50