Université de la Nouvelle-Calédonie Frédéric Flouvat Fondements des Bases de Données.

Université de la Nouvelle-Calédonie frederic.flouvat@univ-nc.nc Frédéric Flouvat Fondements des Bases de Données

Présentation de l'UE Volume horaire : 14h de cours (7 séances), 16h de TD (8 séances) et 10h de TP (5 séances) répartition cours/TD en fonction de l'avancement TP pour appliquer une fois les notions abordées en cours et TD Evaluation en contrôles continus: 2 TP notés -> 2 notes de CC un CC à la fin de chaque chapitre -> 2 notes de CC Objectif : interrogations avancées et normalisation des bases de données approfondir les connaissances pratiques (contraintes, programmation procédurale, vues, …) et théoriques (algèbre relationnel, dépendances et normalisation) 2

Plan du cours Chapitre 1: Manipuler les données Rappels: modèle relationnel, algèbre relationnel et SQL Programmation procédurale Contrôler les transactions Chapitre 2: Définir et structurer les bases de données Contraindre les données Définir des vues des données Normaliser leur structure 3

Université de la Nouvelle-Calédonie frederic.flouvat@univ-nc.nc Frédéric Flouvat (en partie dérivé du cours du Pr. Jeffrey Ullman, Stanford University) Chapitre 1: Manipuler les données Rappels

Généralités Une Base de Données : ensemble structuré et organisé permettant le stockage de grandes quantités d’informations afin d'en faciliter l'exploitation. Un Système de Gestion de Bases de Données : comprend un ensemble de données liées (la bd) et un ensemble de programmes permettant la définition, la saisie, le stockage, le traitement, la modification, la diffusion et la protection de ces données. Liens entre les données Cohérence des données Souplesse d’accès aux données Sécurité Partage des données Indépendance des données Performances 5 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Architecture ANSI/SPARC 6 Schéma conceptuel Schéma logique Vue 1Vue 2Vue n Représentation physique Niveau externe Niveau conceptuel Niveau physique Groupe d’utilisateurs 1Groupe d’utilisateurs 2Groupe d’utilisateurs n … Base de Données Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

La démarche de conception 7 Elaboration du schéma Entité-Association Passage au schéma relationnel Univers d’application Implémentation sur le SGBD Conceptuel Logique Physique Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Modèle relationnel Dans le modèle relationnel, les données sont structurées en relation, d'ordinaire représentées sous forme tabulaire. Ex : Une relation est définie sur un schéma de relation. Chaque ligne est appelée un tuple. Les noms des colonnes sont appelés attributs. Ex : La relation Personnes est définie sur le schéma PERSONNES qui compte 4 attributs :schema(PERSONNES)={nss, nom, prenom, age} t = est un tuple de cette relation (t  Personnes) 8 Personnesnssnomprenomage 12IjoJohn45 MayerSolange35 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Modèle relationnel Une base de données est un ensemble de relations r i sur R i. Un schéma de base de données est un ensemble {R 1, …, R n } de schémas de relations. Ex : Soit d={Personnes, Departements, Activites} une base de données. 9 Personnesnssnomprenomage 12IjoJohn45 MayerSolange35 Departementsdepadresse SciencesNouville LettresMagenta Activites#nss#depfonction 12SciencesProf 45SciencesVacataire 45LettresMdC 12EcoVacataire Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Définitions Soit A un attribut. On note DOM(A), le domaine de A i.e. l’ensemble des valeurs que peux prendre l’attribut A. Ex : DOM(dep) = {Sciences, Lettres, Eco, Droit, SHS …} Ex : DOM(age) = ensemble des entiers naturels Le domaine actif de A dans r noté ADOM(A,r), est l’ensemble des valeurs constantes prises par A dans r. Ex : ADOM(dep,Activites) = {Sciences, Lettres, Eco} La projection d’un tuple t sur l’attribut A (resp. {A,B}) est notée t[A] (resp t[A,B]). Ex : Soit t = t[nom] = et t[nom, prenom] = 10 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Différents types de langages LDD : Langage de Définition de Données Schéma de la bd et des vues LMD : Langage de Manipulation de Données Requêtes, mises à jour LCD : Langage de Contrôle des Données Gestion des accès utilisateurs LCT : Langage de Contrôle des Transactions Gestion des transactions 11 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Langages de requêtes relationnels Les langages de requêtes sont généralement déclaratifs i.e. on spécifie ce que la sortie doit contenir et non comment l’obtenir. Les SGBD relationnels fonctionnent en amont avec des langages procéduraux qui spécifient comment obtenir les résultats aux requêtes. Déclaratif : {nss  DOM(Activites) | (nss,dep,fonction)  Activites, (dep,adresse)  Departements, adresse=‘Carnot'} Procédural : for each tuple t 1 = in relation Activites do for each tuple t 2 = in relation Departements do if d=d’ and a=‘Carnot' then output n end 12 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Langages de requêtes relationnels Le modèle relationnel supporte des langages de requêtes simples et puissants qui permettent beaucoup d’optimisation. Langages théoriques Algèbre relationnelle : Langage procédural très utile pour représenter les plans d'exécution des requêtes. Calcul relationnel : Langage déclaratif orienté utilisateur. Datalog : Langage déclaratif à base de règles. Augmente le calcul relationnel avec des capacités d'inférence. Langages commerciaux SQL : Les opérateurs s’inspirent des différents langages théoriques. 13 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Syntaxe générale d'une requête SQL 14 SELECT FROM [WHERE ] [GROUP BY ] [HAVING ] [ORDER BY ] SELECT FROM [CONNECT BY PRIOR ] [START WITH ] Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Principes des langages de requêtes relationnels Elle est constituée d'un ensemble d'opérateurs algébriques : π, σ, , ,  Entrée : une ou deux relations (opérateurs unaires ou binaires) Sortie : une relation Requête relationnelle : Composition d'un nombre fini d'opérateurs algébriques. Le résultat d'une requête est une relation. L'ordre d'évaluation des opérateurs est spécifié dans la requête (requête procédurale). L’algèbre relationnelle manipule des ensembles. 15 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Intérêts A la base de l’optimisation de requêtes : Les SGBDR traduisent les requêtes formulées avec SQL en une requête interne construite avec les opérateurs algébriques, requête qui sera par la suite optimisée pour en générer un plan d’exécution équivalent. Tous les LMD sont construits à partir de ces opérateurs de base. + généralement mise à jour de la bd et emploi d'expressions arithmétiques et de fonctions d'agrégation telles que cardinalité, somme, minimum, maximum et moyenne. 16 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Les opérateurs Opérateurs de base Projection (π) Sélection (σ) Produit cartésien (  ) Différence (  ) Union (  ) Opérateurs supplémentaires (non essentiels, mais très utiles) Intersection (  ) Jointure ( ⋈ ) Division (  ) Renommage (ρ A→B ) 17 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Projection Soient r une relation sur R et Y  schema(R). La projection de r sur Y notée π Y (r), est définie par : π Y (r) = { t[Y]  DOM(Y) | t  r } Soit S le schéma de relation associé à π Y (r). On a schema(S)=Y. Ex : π nom (Personnes) = π nom,prenom (Personnes) = π dep (Activites) = 18 nom Ijo Mayer nomprenom IjoJohn MayerSolange dep Sciences Lettres Eco Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Sélection Soient r une relation sur R et F une formule de sélection. La sélection des tuples de r par rapport à F notée σ F (r), est définie par : σ F (r) = { t  r | t ⊨ F } Soit S le schéma de relation associé à σ F (r). On a schema(S) = schema(R). Ex : σ fonction=‘Prof’ (Activites) = 19 nssdepfonction 12SciencesProf Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Sélection Une formule de sélection simple sur R est une expression de la forme : A = a ou A = B, où A, B  schema(R) et a  Dom(A). Une formule de sélection est une expression composée de formules de sélection simples connectées à l'aide des connecteurs logiques , ,  et des parenthèses. Soit r une relation sur R, t  r et F une formule de sélection. t satisfait F, noté t ⊨ F, est défini récursivement par : 1)t ⊨ A = a si t[A] = a 2)t ⊨ A = B si t[A] = t[B] 3)t ⊨ F 1  F 2 si t ⊨ F 1 et t ⊨ F 2 4)t ⊨ F 1  F 2 si t ⊨ F 1 ou t ⊨ F 2 5)t ⊨  F si t ⊭ F 6)t ⊨ (F) si t ⊨ F 20 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Opérateurs ensemblistes Soient r 1 et r 2 deux relations sur R 1 et R 2. Union : r 1  r 2 = { t | t  r 1 ou t  r 2 }. Différence : r 1 – r 2 = { t | t  r 1 et t  r 2 }. Intersection : r 1  r 2 = { t | t  r 1 et t  r 2 }. Ex : r 1  r 2 = r 1 - r 2 = r 1  r 2 = 21 r1ABC 123 111 122 r2ABC 222 111 ABC 123 111 122 222 ABC 123 122 ABC 111 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Opérateurs ensemblistes Propriétés : σ  F (r) = r  σ F (r) σ F1  F2 (r) = σ F1 (r)  σ F2 (r) σ F1  F2 (r) = σ F1 (r)  σ F2 (r) Toutes ces opérations prennent comme entrées deux relations qui doivent être compatibles vis-à-vis de l’union. Soit S le schéma de relation associé à r 1  r 2, r 1 - r 2 ou r 1  r 2. On a par convention schema(S) = schema(R 1 ). 22 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Produit cartésien Soient r 1 et r 2 deux relations sur R 1 et R 2 avec schema(R 1 )  schema(R 2 ) = ø. Le produit cartésien r 1  r 2 est définie par : r 1  r 2 = { t |  t 1  r 1 et  t 2  r 2 tel que t[schema(R 1 )]= t 1 et t[schema(R 2 )]= t 2 } Soit S le schéma de relation associé à r 1  r 2. On a schema(S) = schema(R1)  schema(R 2 ). 23 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Produit cartésien Ex : r 1  r 2 = 24 r1ABC 123 111 122 r2DE 24 13 ABCDE 12324 11124 12224 12313 11113 12213 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Jointure Soient r 1 et r 2 deux relations sur R 1 et R 2 et F une formule de sélection. La jointure de r 1 et r 2 par rapport à F, notée r 1 ⋈ F r 2, est définie par : r 1 ⋈ F r 2 = σ F (r 1  r 2 ) Soit S le schéma de relation associé à r 1 ⋈ F r 2. On a schema(S) = schema(R1)  schema(R 2 ). Équi-jointure quand F est une égalité. Thêta-jointure quand F n’est pas une égalité (>, =, ). Auto-jointure quand r1 = r2. Jointure naturelle quand équi-jointure sur tous les attributs communs à R1 et R2 + projection (pas utile d’écrire F). 25 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Jointure 26  Ex : r 1  r 2 = r 1 ⋈ A=D r 2 = r 1 ⋈ A<D r 2 = r1ABC 123 111 122 r2DE 24 13 ABCDE 12324 11124 12224 12313 11113 12213 ABCDE 12313 11113 12213 ABCDE 12324 11124 12224 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Jointure naturelle 27 r1ABC 222 111 r2ADE 123 112 231 312 r3ABC 111 123 r4DEF 111 222  Ex : r 1 ⋈ r 2 = r 1 ⋈ r 3 = r 1 ⋈ r 4 = r 1  r 3 r 1  r 4 ABCDE 22231 11123 11112 ABC 111 ABCDEF 222111 222222 111111 111222 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Renommage Soient r une relation sur R, A  schema(R) et B  schema(R). Le renommage de A en B dans r noté ρ A→B (r), est défini par : ρ A→B (r) = { t |  u  r, t[schema(R)  {B}] = u[schema(R)  {A}] et t[B] = u[A]} Soit S le schéma de relation associé à ρ A→B (r). On a schema(S) = (schema(R)  {A})  {B}. Ex : r 1 ⋈ ρ B→B’,C→C’ (r 3 ) = 28 ABCB’C’ 11111 11123 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Division La division permet d'exprimer le quantificateur universel (  ). Exemple de requête : "Donner la liste des étudiants qui sont inscrits à tous les cours". 29 Inscription s etudcours 1BD 1RO 1BI 2RO Enseignementscours BD RO BI Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Division Soient r une relation sur R, avec schema(R) = XY, et s une relation sur S, avec schema(S) = Y. La division de r par s notée r  s, est défini par : r  s = { t[X] | t  r et s  π Y (σ F (r))} avec X={A 1,..., A q } et F =(A 1 =t[A 1 ])  …  (A q =t[A q ]) Soit schema(T) le schéma de relation associé à r  s. On a schema(T) = X. 30 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Division La division n'est pas une opération essentielle car elle peut être exprimée à l'aide des opérateurs de projection, différence et produit cartésien. Pour calculer r  s, il faut calculer toutes les valeurs de X dans r qui ne sont pas disqualifiées par des valeurs de Y dans s. Une valeur de X est disqualifiée si en lui rattachant une valeur de Y de s, le tuple obtenu sur XY n'appartient pas à r. Valeurs disqualifiées de X : π x ((π x (r)  s)  r) r  s = π x (r)  valeurs disqualifiées de X  r  s = π x (r)  π x ((π x (r)  s)  r) 31 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Division 32 UNCetudcours 1c1 1c2 1c3 1c4 2c1 2c2 3 4 4c4 Mod1cours c2 F3F3 etud 2 4 Mod2cours c1 c3 c4  Ex : UNC  Mod1 = UNC  F3 = UNC  Mod2 = etud 1 2 3 4 cours c2 etud 1 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Propriétés σ F (σ F’ (r)) = σ F’ (σ F (r)) π X (π Y (r)) = π X  Y (r) σ F (π X (r)) = π X (σ F (r)) σ F (r ⋈ s) = σ F (r) ⋈ s si F porte sur schema(R) π X (r ⋈ s) = π X (r) ⋈ π X (s) si schema(R)  schema(S) = X (r1  r2) ⋈ r3 = (r1 ⋈ r3)  (r2 ⋈ r3) Ex : Si schema(R1)=XY et schema(R2) =XZ, exprimer r 1 ⋈ r 2 avec , ρ, σ, π Ex : Si schema(R1)=schema(R2), exprimer r 1  r 2 avec  33 r 1 ⋈ r 2 = π XYZ (σ X=X’ (r 1  ρ X→X’ (r 2 ))) r 1  r 2 = r 1  (r 1  r 2 ) Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Représentation en arbre Une expression algébrique peut se représenter sous forme d’arbre : La racine de l’arbre correspond à la requête Les feuilles de l’arbre correspondent aux relations Les nœuds de l’arbre correspondent aux opérateurs algébriques Ex : Représenter Q = π X (σ C1 (r1 ⋈ r2) ⋈ (σ c2 (r3)  r4)) 34 σ c2 Q ⋈ r1 σ C1 r2 πXπX  r4 r3 ⋈ Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Arbres et optimisation de requêtes Quels sont les couples possibles avec une femme de Nouméa et un homme de Koné ? 42 cases manipulées 19 cases manipulées 35 Hommec3 (nom) c4 (adr) BobNouméa SamKoné Femmec1 (nom) c2 (adr) CathyWé JuliaNouméa LindaNouméa π c1, c3 4 col, 2 lig σ c2= "Nouméa" and c4= "Koné" x femmehomme 4 col, 6 lig 2 col, 3 lig 2 col, 2 lig x femmehomme π c1 π c3 σ c2= "Nouméa" σ c4= "Koné" 2 col, 3 lig2 col, 2 lig 2 col, 1 lig 1 col, 1 lig1 col, 2 lig Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Extension de l’algèbre relationnelle Quatre nouveaux opérateurs: δ (delta) : élimine de la relation résultat les tuples en double.  Extension de la théorie aux multi-ensembles τ (tau) : trie les tuples. γ (gamma) : groupe et agrège. Outerjoin : évite les "tuples incomplets" = les tuples qui ne sont liés/joins à aucun autre tuple. 36 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Elimination des doublons R1 := δ (R2). R1 est une copie de chaque tuple qui apparaissent dans R2 une ou plusieurs fois (une copie sans doublons donc). Exemple: 37 R = (AB ) 12 34 12 δ (R) =AB 12 34 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Trier R1 := τ L (R2). L est une liste d’attributs de R2. R1 est la liste des tuples de R2 triés par rapport au premier attribut de L, puis par rapport au deuxième attribut, … si plusieurs solutions sont possibles, en prend une arbitrairement τ est le seul opérateur n’ayant pas pour résultat un ensemble ou un multi-ensemble. le résultat est une séquence de tuples Exemple: 38 R = ( A B ) 1 2 3 4 5 2 τ B (R) = [(5,2), (1,2), (3,4)] Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Opérateurs d’agrégation Les opérateurs d’agrégation ne sont pas des opérateurs de l’algèbre relationnelle. Ils sont appliqués sur une colonne d’une table et ont pour résultat une seule valeur. Exemple d’opérateurs: SUM, AVG, COUNT, MIN, et MAX. Exemple: 39 R = ( A B ) 1 3 3 4 3 2 SUM(A) = 7 COUNT(A) = 3 MAX(B) = 4 AVG(B) = 3 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Opérateur de regroupement R1 := γ L (R2). L est une liste composées d’éléments de type: 1.attributs (regroupement ). 2.AGG(A), où AGG est un des opérateurs d’agrégation et A est un attribut. –Une flèche et un nouveau nom d’attribut renomme la composante. Fonctionnement de γ L (R) Groupe R par rapport à tous les attributs de regroupement de L –forme un groupe pour chaque liste de valeur distincte pour les attributs de R Pour chaque groupe, calcule AGG(A) Chaque groupe est associé à un tuple dans la relation résultat –avec pour attributs, les attributs de regroupement –et les résultats des opérations d’agrégation 40 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Exemple: 41 R = ( A B C ) 1 2 3 4 5 6 1 2 5 γ A,B,AVG(C)->X (R) = ?? Premièrement, regrouper R par rapport A et B : ABC 123 125 456 Puis, calculer la moyenne de C pour chaque groupe: ABX 124 456 Opérateur de regroupement Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Jointure externe (Outerjoin) Supposons que l’on fasse R ⋈ C S. Un tuple de R qui n’est associé à aucun tuple de S par jointure est dit incomplet. De la même manière pour un tuple de S. La jointure externe conserve les tuples incomplets dans la solution en leur associant la valeur NULL. 42 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Exemple: 43 R = ( AB )S = ( B C ) 1223 4567 (1,2) est associé par jointure à (2,3), mais les autres tuples sont incomplets R OUTERJOIN S =ABC 123 45NULL NULL67 Jointure externe (Outerjoin) Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

MAINTENANT --- RETOUR AU SQL Chaque opération a un équivalent en SQL 44 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Jointures externe R OUTER JOIN S est l’instruction principale pour faire une jointure externe. Elle est complétée par: 1.NATURAL devant OUTER (Optionnel). 2.ON après JOIN (Optionnel). 3.LEFT, RIGHT, ou FULL devant OUTER (Optionnel). uLEFT = conserve les tuples incomplets de R seulement. uRIGHT = conserve les tuples incomplets de S seulement. uFULL = conserve les tuples incomplets des deux; valeur par défaut. Exemple: A partir de Sells(bar, beer, price) et Frequents(drinker,bar), afficher tous les clients et les bières qu’ils peuvent consommer SELECT drinker, beer FROM Sells, Frequents RIGHT OUTER JOIN ON Sells.bar = Frequents.bar ; 45 Uniquement une des deux Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Agrégations SUM, AVG, COUNT, MIN, et MAX peuvent être appliqués à une colonne dans une clause SELECT afin d’appliquer l’agrégation sur cette colonne. Egalement, COUNT(*) pour compter le nombre de tuples. Exemple: A partir de Sells(bar, beer, price), trouver le prix moyen d’une Bud: SELECT AVG(price) FROM Sells WHERE beer = ’Bud’; 46 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Eliminer les doublons dans une Agrégation Utiliser DISTINCT à l’intérieur de l’agrégation. Exemple: Trouver le nombre de prix différents associés à la Bud: SELECT COUNT(DISTINCT price) FROM Sells WHERE beer = ’Bud’; 47 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Les valeurs NULL ne contribuent jamais à une somme, une moyenne, ou un comptage, et ne peuvent jamais être le minimum ou le maximum d’une colonne. Mais s’il n’y a pas de valeurs non-NULL dans une colonne, alors le résultat de l’agrégation est NULL. Exception: COUNT d’un ensemble vide retourne 0. Exemple: Le nombre de bars qui vendent de la Bud à un prix connu Le nombre de bars qui vendent de la Bud Les NULL ignorés dans les Agrégations 48 SELECT count(*) FROM Sells WHERE beer = ’Bud’; SELECT count(price) FROM Sells WHERE beer = ’Bud’; Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Groupement Après l’expression SELECT-FROM-WHERE, ajouter GROUP BY et une liste d’attributs. La relation qui résulte du SELECT-FROM-WHERE est groupées en accord avec les valeurs de tout ces attributs, et un opérateur d’agrégation est appliqué sur chaque groupe. Exemple: A partir de Sells(bar, beer, price), trouver ler prix moyen de chaque bière: SELECT beer, AVG(price) FROM Sells GROUP BY beer; 49 beerAVG(price) Bud2.33… Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Groupement 50 Exemple: A partir de Sells(bar, beer, price) et Frequents(drinker,bar), trouver pour chaque client le prix moyen de la Bud au bar qu’ils fréquentent: SELECT drinker, AVG(price) FROM Frequent,Sells WHERE beer = ‘Bud’ AND Frequents.bar = Sells.bar GROUP BY drinker; Construit tous les tuples drinker- bar-price associés à la Bud Puis, les regroupent par clients Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Restriction sur le SELECT avec une Agrégation Si une agrégation est effectuée, alors chacun des éléments du SELECT doit être soit: 1.Une opération d’agrégation, ou 2.Un attribut utilisé au niveau d’un GROUP BY Exemple de requête interdite: Il semble correcte de rechercher le bar qui vend les bières Bud les moins chères par la requête: SELECT bar, MIN(price) FROM Sells WHERE beer = ’Bud’; Mais cette requête est interdite en SQL. 51 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Clauses HAVING HAVING peut suivre une clause GROUP B. Si tel est le cas, la condition est appliquée à chaque groupe, et les groupes ne satisfaisant pas la condition sont ignorés. Exemple: A partir de Sells(bar, beer, price) et Beers(name, manf), trouver le prix moyen des bières qui sont soient servies dans au moins trois bars ou sont fabriquées par Pete. ??? 52 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Les groupes de bières avec au moins 3 bars non-NULL et aussi les groupes de bières avec pour fabricant Pete Clauses HAVING 53 Les bières fabriquées par Pete Exemple: SELECT beer, AVG(price) FROM Sells GROUP BY beer HAVING COUNT(bar) >= 3 OR beer IN (SELECT name FROM Beers WHERE manf = ’Pete’’s’); Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Restrictions sur les conditions du HAVING Tout doit être dans une sous-requête. A part les sous-requêtes, les conditions peuvent être sur des attributs uniquement si: 1.ce sont les attributs utilisés pour le regroupement, ou 2.s’ils sont agrégés (même condition que pour la clause SELECT lorsqu’elle est utilisée pour une agrégation). 54 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Modifications des relations d’une base de données Une commande de modification ne retourne pas de résultat (comme le fait une requête), mais change le contenu des relations. Trois types de modifications: 1.Insert : insertion d’un ou plusieurs tuples. 2.Delete : suppression d’un ou plusieurs tuples. 3.Update : mise à jours des valeurs d’un ou plusieurs tuples existants. 55 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Insertion Pour insérer un unique tuple: INSERT INTO VALUES ( ); Attention: les valeurs doivent être dans le même ordre que les attributs de la relation et les types doivent correspondre. Exemple: Ajouter à Likes(drinker, beer) le fait que Sally aime les bières Bud. INSERT INTO Likes VALUES(’Sally’, ’Bud’); 56 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

57 Spécifier les attributs de l’INSERT Il est possible d’ajouter au nom de la relation une liste d’attributs Deux raisons de faire ainsi: 1.l’ordre des attributs de la relation a été oublié. 2.il n’y a pas de valeurs pour tous les attributs, et nous voulons que le SGBD remplace ces valeurs manquantes par NULL ou par une valeur par défaut. Exemple: Une autre approche pour ajouter à Likes(drinker, beer) le fait que Sally aime les Bud : INSERT INTO Likes(beer, drinker) VALUES(’Bud’, ’Sally’); Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Ajouter des valeurs par défaut Dans la commande CREATE TABLE permettant de créer une table, il est possible de faire suivre la définition d’un attribut par DEFAULT et une valeur. Lorsqu’un tuple à insérer n’a pas de valeur pour cet attribut, la valeur par défaut est utilisée. Exemple: CREATE TABLE Drinkers ( name CHAR(30) PRIMARY KEY, addr CHAR(50) DEFAULT ’123 Sesame St.’, phone CHAR(16) ); 58 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Exemple : INSERT INTO Drinkers(name) VALUES(’Sally’); relation résultat: Ajouter des valeurs par défaut 59 Sally123 Sesame St NULL name address phone Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Insertion de plusieurs tuples Il est possible d’insérer la totalité du résultat d’une requête dans une relation, en faisant: INSERT INTO ( ); Exemple : En utilisant la relation Frequents(drinker, bar), insérer dans une nouvelle relation PotBuddies(name) contenant tous les amis potentiels de Sally, i.e. les clients qui fréquente au moins un des bars que fréquente Sally. 60 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Insertion de plusieurs tuples 61 les pairs de tuples de clients où le premier est Sally et le second est quelqu’un d’autre, et les bars sont les mêmes les autres clients Exemple : INSERT INTO PotBuddies (SELECT d2.drinker FROM Frequents d1, Frequents d2 WHERE d1.drinker = ’Sally’ AND d2.drinker <> ’Sally’ AND d1.bar = d2.bar ); Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Suppression de tuples Pour supprimer les tuples d’une relation en fonction de conditions: DELETE FROM WHERE ; Exemple: Supprimer de Likes(drinker, beer) le fait que Sally aime la Bud: DELETE FROM Likes WHERE drinker = ’Sally’ AND beer = ’Bud’; Supprimer tous les tuples d’une relation: DELETE FROM Likes; Remarque: pas de clause WHERE. 62 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Problème de suppression 63 Bières faite par le même fabricant et ayant un nom différent du nom de la bière représenté par le tuple b. namemanf BudAnheuser-Busch Bud liteAnheuser-Busch ManPeterson namemanf ManPeterson namemanf Bud liteAnheuser-Busch ManPeterson ? Exemple: Supprimer de Beers(name,manf) toutes les bières pour lesquelles il y a une autre bière fournie par le même fabricant. DELETE FROM Beers b WHERE EXISTS ( SELECT name FROM Beers WHERE manf = b.manf AND name <> b.name); Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Problème de suppression Exercice: exécution de la suppression Supposons que Anheuser-Busch fait uniquement de la Bud et de la Bud Lite. Supposons que le SGBD arrive au tuple b de la première Bud. La sous-requête est non vide, à cause du tuple avec Bud Lite, donc le tuple b de la Bud est supprimé. Maintenant, quand le tuple b devient le tuple avec Bud Lite, est-il aussi supprimé ? ➡ Réponse: le tuple avec Bud Lite est aussi supprimé Ceci est dû au fait que la suppression s’effectue en deux étapes: 1.marquer les tuples pour lesquels la condition du WHERE est satisfaite 2.supprimer les tuples marqués 64 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Mise à jour Pour changer la valeur de certains attributs dans certains tuples d’une relation: UPDATE SET WHERE ; Exemple: Modifier le numéro de téléphone du client Fred à la valeur 555-1212: UPDATE Drinkers SET phone = ’555-1212’ WHERE name = ’Fred’; Fixer à $4 le prix maximum d’une bière: UPDATE Sells SET price = 4.00 WHERE price > 4.00; 65 Modifications des données en SQLAlgèbre relationnelle et SQLLe modèle relationnel

Université de la Nouvelle-Calédonie frederic.flouvat@univ-nc.nc Frédéric Flouvat (dérivé du cours du Pr. Jeffrey Ullman, Stanford University et du cours du Pr. Christian Retoré, Université de Bordeaux) Chapitre 1: Manipuler les données Programmation procédurale 66

Le SQL dans de vrais programmes Pour l’instant, le SQL est utilisé comme interface générique pour faire des requêtes un environnement où l’utilisateur est face à un terminal et fait des requêtesà une base de données. La réalité est différente: des programmes conventionnels interagissent avec le SQL. Les options possibles: le code dans un langage spécifique est stocké dans la base de données (PSM, PL/SQL). les instructions SQL sont englobées dans un langage hôte (p.ex. le C) et transformées/exécutées en ligne par un préprocesseur (Embedded SQL). des outils de connections sont utilisés pour permettre à un langage conventionnel d’accéder à la base de données (p.ex. CLI, JDBC, PHP) 67 Premières procédures PSM Manipuler les requêtes SQLPL/pgSQL

Les Procédures Stockées PSM, ou “persistent stored modules,” permet de stocker des procédures comme des éléments du schéma de la base de données. PSM = un mélange d’instructions conventionnelles (if, while, etc.) et de SQL. Permet de faire des choses que ne permet pas le SQL tout seul. 68 Premières procédures PSM Manipuler les requêtes SQLPL/pgSQL

Structure de base d’une commande PSM Procédure: CREATE PROCEDURE ( ) ; Fonction: CREATE FUNCTION ( ) RETURNS ; Les paramètres: contrairement à la syntaxe nom-type des langages tels que le C ou Java, PSM utilise la syntaxe mode-nom-type, avec mode égal à : –IN = variable en entrée, non modifiée par la procédure. –OUT = variable retournée en sortie de l’algorithme. –INOUT = les deux. 69 Premières procédures PSM Manipuler les requêtes SQLPL/pgSQL

Exemple de procédure sockée 70 les paramètres sont tous les deux en lecture seule, i.e. non modifiés le corps --- une seule insertion Ecrivons une procédure avec deux paramètres b et p, et qui ajoute un tuple ayant bar = ’Joe’’s Bar’, beer = b, et price = p, à la relation Sells(bar, beer, price). utilisée par Joe pour ajouter des bières à sa carte plus facilement. CREATE PROCEDURE JoeMenu ( INbCHAR(20), IN pREAL ) INSERT INTO Sells VALUES(’Joe’’s Bar’, b, p); Premières procédures PSM Manipuler les requêtes SQLPL/pgSQL

Invoquer des Procédures Utiliser simplement l’instruction CALL, avec le nom de la procédure souhaitée et ses paramètres. Exemple: CALL JoeMenu(’Moosedrool’, 5.00); Les fonctions peuvent être utilisées dans des expressions SQL, à condition que le type de la valeur retournée soit approprié. 71 Premières procédures PSM Manipuler les requêtes SQLPL/pgSQL

Premières instructions PSM Retourner la valeur d’une fonction: RETURN Contrairement au C, etc., RETURN ne met pas fin à l’exécution de la fonction. Déclarer une variable locale: DECLARE Définir un bloc d’instructions: BEGIN... END séparer les instruction par des points virgules. Affecter une valeur: SET = ; Exemple: SET b = ’Bud’; 72 Premières procédures PSM Manipuler les requêtes SQLPL/pgSQL

Instruction conditionnelle IF Forme la plus simple: IF THEN END IF; Ajouter ELSE si besoin IF... THEN... ELSE... END IF; Ajouter des cas supplémentaires: ELSEIF IF … THEN … ELSEIF … THEN … ELSEIF … THEN … ELSE … END IF; 73 Premières procédures PSM Manipuler les requêtes SQLPL/pgSQL

Exemple: IF 74 nombre de clients du bar b retourne la valeur ici et non lors des autres RETURN IF imbriqués Classer les bars en function de leur nombre de clients en utilisant la relation Frequents(drinker,bar). <100 clients: ‘unpopular’. 100-199 clients: ‘average’. >= 200 clients: ‘popular’. La fonction Rate(b) classe le bar b. CREATE FUNCTION Rate (IN b CHAR(20) ) RETURNS CHAR(10) DECLARE cust INTEGER; BEGIN SET cust = (SELECT COUNT(*) FROM Frequents WHERE bar = b); IF cust < 100 THEN RETURN ’unpopular’ ELSEIF cust < 200 THEN RETURN ’average’ ELSE RETURN ’popular’ END IF; END; Premières procédures PSM Manipuler les requêtes SQLPL/pgSQL

Les boucles Forme basique: : LOOP END LOOP; Interrompre une boucle: EXIT Exemple: loop1: LOOP... EXIT loop1;... END LOOP; 75 si cette instruction est exécutée fin de la boucle Premières procédures PSM Manipuler les requêtes SQLPL/pgSQL

Les boucles WHILE DO END WHILE; REPEAT UNTIL END REPEAT; 76 Premières procédures PSM Manipuler les requêtes SQLPL/pgSQL

Les requêtes Les requêtes générales SELECT-FROM-WHERE ne peuvent pas être exécutées directement en PSM. Il y a trois méthodes pour avoir le résultat d’une requête: Les requêtes produisant une valeur peuvent être récupérés par affectation. SELECT... INTO. Curseurs. 77 Premières procédures PSM Manipuler les requêtes SQL PL/pgSQL

Exemple: Affectation/Requête En utilisant une variable locale p et Sells(bar, beer, price), nous pouvons obtenir le prix des Bud vendues par Joe’s Bar: SET p = (SELECT price FROM Sells WHERE bar = ’Joe’’s Bar’ AND beer = ’Bud’); 78 Premières procédures PSM Manipuler les requêtes SQL PL/pgSQL

SELECT... INTO Un autre moyen de récupérer la valeur d’une requête qui retourne un tuple est d’utiliser INTO après la clause SELECT. Exemple: SELECT price INTO p FROM Sells WHERE bar = ’Joe’’s Bar’ AND beer = ’Bud’; 79 Premières procédures PSM Manipuler les requêtes SQL PL/pgSQL

Curseurs Un curseur est principalement une variable de type tuple qui stocke tous les tuples résultats d’une requête. Déclaration d’un curseur c : DECLARE c CURSOR FOR ; Utilisation d’un curseur c: initialisation du curseur: OPEN c; –la requête c est évaluée, et c pointe sur le premier tuple du résultat. libération du curseur:CLOSE c; 80 Premières procédures PSM Manipuler les requêtes SQL PL/pgSQL

Parcourir les tuples d’un Curseur Pour accéder au tuple suivant du curseur c, utiliser la commande: FETCH FROM c INTO x1, x2,…,xn ; les x sont des variables référençant chaque composant du tuple en stocké dans c. c est déplacé automatiquement au prochain tuple. Sortir d’une boucle d’un curseur l’utilisation classique d’un curseur est de créer une boucle avec FETCH, et de faire un traitement pour chaque tuple parcouru. mais comment sortir de la boucle quand tous les tuples ont été traités? 81 Premières procédures PSM Manipuler les requêtes SQL PL/pgSQL

Sortir de la boucle d’un Curseur Chaque opération SQL retourne un statuts, qui est une chaîne de caractère de 5 chiffres. –Par exemple, 00000 = “Tout est OK,” et 02000 = “Pas de tuple" En PSM, il est possible de récupérer la valeur du statuts dans une variable appelée SQLSTATE. Il est donc possible de définir une condition sur une variable booléenne qui est vrai si et seulement si SQLSTATE a une valeur particulière. Par exemple, DECLARE NotFound CONDITION FOR SQLSTATE ’02000’; 82 Premières procédures PSM Manipuler les requêtes SQL PL/pgSQL

Sortir de la boucle d’un Curseur Exemple: Déclarons une condition NotFound pour représenter 02000 par: DECLARE NotFound CONDITION FOR SQLSTATE ’02000’; Structure de la boucle sur le curseur est donc: cursorLoop: LOOP … FETCH c INTO … ; IF NotFound THEN LEAVE cursorLoop; END IF; … END LOOP; 83 Premières procédures PSM Manipuler les requêtes SQL PL/pgSQL

Exemple: Curseur (déclaration) 84 Utilisé pour stocker les pairs beer-price lors du parcours du curseur Retourne le menu de Joe Ecrivons une procédure qui examine Sells(bar, beer, price), et qui augmente de $1 le prix des bières en dessous de $3 chez Joe’s Bar. Egalement possible de faire cela par un simple UPDATE. CREATE PROCEDURE JoeGouge( ) DECLARE theBeer CHAR(20); DECLARE thePrice REAL; DECLARE NotFound CONDITION FOR SQLSTATE ’02000’; DECLARE c CURSOR FOR (SELECT beer, price FROM Sells WHERE bar = ’Joe’’s Bar’); Premières procédures PSM Manipuler les requêtes SQL PL/pgSQL

Exemple: Curseur (corps de la procédure) 85 Vérifie si le dernier FETCH à échouer à récupérer un tuple Si Joe vend une bière moins $3, augmenter son prix de $1 à Joe’s Bar. BEGIN OPEN c; menuLoop: LOOP FETCH c INTO theBeer, thePrice; IF NotFound THEN LEAVE menuLoop END IF; IF thePrice < 3.00 THEN UPDATE Sells SET price = thePrice + 1.00 WHERE bar = ’Joe’’s Bar’ AND beer = theBeer; END IF; END LOOP; CLOSE c; END; Premières procédures PSM Manipuler les requêtes SQL PL/pgSQL

PostgreSQL utilise une variante du SQL/PSM appelée PL/pgSQL. extension de PSM Structure de base: DECLARE BEGIN END; La section DECLARE est optionnelle. 86 Premières procédures PSMManipuler les requêtes SQL PL/pgSQL

Structure d’une procédure PL/pgSQL CREATE OR REPLACE FUNCTION ( ) RETURNS AS $$ BEGIN END; $$ LANGUAGE plpgsql; SELECT * from ( ) ; ou SELECT ( ) ; ou EXECUTE ( ) ; uniquement si la fonction a été "préparée" avant (évite de calculer plusieurs fois le plan d'exécution) PREPARE ( ) ; 87 instructions obligatoires Premières procédures PSMManipuler les requêtes SQL PL/pgSQL

PL/pgSQL Déclarations et Affectations Les paramètres en PL/pgSQL, ainsi que les variable locales, ne sont pas déclarés comme dans le standard SQL/PSM: L’ordre est nom-mode-type, non mode-nom-type. De nouveaux types. –p.ex. type composite CREATE TYPE element_inventaire AS ( nomtext, id_fournisseurinteger, prixnumerix ); Le mot DECLARE n’apparaît pas devant chaque déclaration locale. Utiliser seulement le nom de la variable et son type. Exemple: id_user integer ; url varchar ; 88 Premières procédures PSMManipuler les requêtes SQL PL/pgSQL

PL/pgSQL Déclarations et Affectations Il est possible d’associer à une variable le type d’un attribut x d’une relation R par R.x%TYPE. Très utile pour éviter des erreurs de types. Egalement, R%ROWTYPE pour avoir une variable ayant la même structure que les tuples de R. Le mot clé SET n’est pas utilisé pour les affectations, et := est utilisé à la place de = Exemple: x := y; 89 Premières procédures PSMManipuler les requêtes SQL PL/pgSQL

Exemple: JoeMenu 90 ces types correspondent aux informations de b et p Définissons une procédure JoeMenu(b,p) qui ajoute une bière b au prix p à l’ensemble des bières vendues par Joe (relation Sells). CREATE OR REPLACE FUNCTION JoeMenu ( b IN Sells.beer%TYPE, p IN Sells.price%TYPE ) RETURNS void AS $$ BEGIN INSERT INTO Sells VALUES (’Joe’’s Bar’, b, p); END; $$ LANGUAGE plpgsql; SELECT JoeMenu(‘Kro’,10) ; Premières procédures PSMManipuler les requêtes SQL PL/pgSQL

Retourner un ensemble de valeurs Définir le type de retour de la fonction comme étant une table RETURNS TABLE(,, … ) Retourner l'ensemble des valeurs avec RETURN QUERY ; si on retourne tous les tuples en une seule fois (cad le résultat d'une requête) RETURN NEXT ; si on retourne un tuple à la fois CREATE OR REPLACE FUNCTION BarSallyJo () RETURNS TABLE( bar TEXT, name VARCHAR(30) ) AS $$ BEGIN RETURN QUERY SELECT bar, drinker FROM Frequents WHERE drinker = 'Sally' OR drinker = 'Jo'; END; $$ LANGUAGE plpgsql; 91 Premières procédures PSMManipuler les requêtes SQL PL/pgSQL

Retourner un ensemble de valeurs OU CREATE OR REPLACE FUNCTION BarSallyJo () RETURNS TABLE( bar TEXT, name VARCHAR(30) ) AS $$ DECLARE r RECORD; BEGIN SELECT bar, drinker INTO r FROM Frequents WHERE drinker = 'Sally'; RETURN NEXT r; SELECT bar, drinker INTO r FROM Frequents WHERE drinker = 'Jo'; RETURN NEXT r; END; $$ LANGUAGE plpgsql; 92 Premières procédures PSMManipuler les requêtes SQL PL/pgSQL

PL/pgSQL Structures de contrôles Structure conditionnelle: Comme IF … en SQL/PSM, mais utiliser ELSIF à la place de ELSEIF. IF … THEN … ELSIF … THEN … ELSIF … THEN … ELSE … END IF; Boucles: LOOP … END LOOP comme en SQL/PSM. A la place de LEAVE …, PL/pgSQL utilise EXIT WHEN et lorsque la condition correspond à l’absence de tuples dans le curseur c, il est possible d’écrire NOT FOUND comme condition. 93 Premières procédures PSMManipuler les requêtes SQL PL/pgSQL

PL/pgSQL Structures de contrôles Boucles: WHILE même syntaxe qu’en SQL/PSM mais LOOP… END LOOP à la place de DO … END WHILE WHILE LOOP END LOOP; Boucle Pour FOR IN.. LOOP END LOOP; Exemple: FOR i IN 1.. 20 LOOP … END LOOP 94 Premières procédures PSMManipuler les requêtes SQL PL/pgSQL

PL/pgSQL Curseurs Déclaration d’un curseur PL/SQL (id. SQL/PSM) DECLARE CURSOR [( )] FOR ; Exemple: DECLARE curs1 CURSOR (b varchar) FOR SELECT * FROM Sells WHERE beer = b ; Ouverture du curseur OPEN [( )] ; Pour parcourir les valeurs de la requête: FETCH c INTO ; 95 Premières procédures PSMManipuler les requêtes SQL PL/pgSQL

Exemple: JoeGouge() en PL/pgSQL (déclaration) La procédure JoeGouge() envoie un curseur sur une partie des ventes de Joe’s-Bar, et augmente de $1 le prix des bières initialement vendue en dessous de $3 chez Joe’s Bar. CREATE OR REPLACE FUNCTION JoeGouge() AS $$ DECLARE theBeer "Sells".beer%TYPE; thePrice "Sells".price%TYPE; c CURSOR FOR SELECT beer, price FROM "Sells" WHERE bar = ’Joe’’s Bar’; 96 Premières procédures PSMManipuler les requêtes SQL PL/pgSQL

Exemple: JoeGouge() en PL/pgSQL (corps) 97 condition d’arrêt de la boucle Note: ceci est une clause SET d’un UPDATE, et non une affectation. PL/pgSQL utilise := pour les affectations. BEGIN OPEN c; LOOP FETCH c INTO theBeer, thePrice; EXIT WHEN NOT FOUND; IF thePrice < 3.00 THEN UPDATE "Sells" SET price = thePrice + 1.00 WHERE bar = ’Joe’’s Bar’ AND beer = theBeer; END IF; END LOOP; CLOSE c; END; $$ LANGUAGE plpgsql; Premières procédures PSMManipuler les requêtes SQL PL/pgSQL

Variables de type tuple PL/pgSQL permet à une variable d’avoir le type d’un tuple. x R%ROWTYPE donne à x le type des tuples de R. R peut être une relation or un curseur. x.a donne la valeur de l’attribut a du tuple x. Exemple: Reprendre la JoeGouge() avec une variable bp of type beer-price. CREATE OR REPLACE FUNCTION JoeGouge() AS $$ DECLARE CURSOR c FOR SELECT * FROM "Sells" WHERE bar = ’Joe’’s Bar’; bp "Sells"%ROWTYPE; 98 Premières procédures PSMManipuler les requêtes SQL PL/pgSQL

Variables de type tuple BEGIN OPEN c; LOOP FETCH c INTO bp; EXIT WHEN NOT FOUND; IF bp.price < 3.00 THEN UPDATE "Sells" SET price = bp.price + 1.00 WHERE bar = ’Joe’’s Bar’ AND beer =bp.beer; END IF; END LOOP; CLOSE c; END; 99 l’accès aux composants de bp est obtenu avec un point et le nom de l’attribut Premières procédures PSMManipuler les requêtes SQL PL/pgSQL

Université de la Nouvelle-Calédonie frederic.flouvat@univ-nc.nc (dérivé du cours du Pr. Jeffrey Ullman, Stanford University) Chapitre 1: Manipuler les données Contrôler les transactions

Pourquoi des Transactions? Les systèmes de gestion de bases de données sont normalement utilisés par plusieurs utilisateurs ou processus à la fois. Interrogations et modifications. Contrairement aux systèmes d’exploitation, qui supportent les interactions entre processus, un SGBD a besoin d’éviter que de mauvaises interactions soient faites. Exemple: Deux personnes titulaires d’un compte commun retirent au même moment $100 dans deux distributeurs de billets différents. –Le SGBD doit alors s’assurer que les deux retraits sont bien appliqués au compte sous-jacent. A l’opposé: un système d’exploitation permet à deux personnes d’éditer le même document en même temps. Toutefois, à l’écriture, une seule des modifications n’est conservée. 101

Exemple: Transfert entre 2 comptes Le guichet 1 exécute T1 : Transfert(A,B,100) Le guichet 2 exécute T2 : Transfert(A,B,-200) 102 Transfert(A,B,M) Begin varA := Read(A) varA := varA + M Write(A,varA) varB := Read(B) varB := varB - M Write(B,varB) Commit

Transactions Transaction = ensemble de requêtes d’interrogation ou de modification sur la base de données, sous le contrôle d’un utilisateur ou processus. Normalement avec des propriétés fortes par rapport aux accès concurrents. Ecrits en SQL à partir d’instructions simples ou contrôlé explicitement dans un programme. Exemple de transactions: Réservation d’une place d’avion Retrait d’une somme d’argent à partir d’un distributeur Passer une commande sur un catalogue en ligne … 103

Transactions et SQL Définir une transaction Begin; COMMIT; L’instruction SQL COMMIT valide une transaction. Ses modifications sont maintenant permanentes dans la base de données. L’instruction SQL ROLLBACK implique aussi la fin d’une transaction, mais en l’annulant. Aucun effets sur la base de données. Une erreur comme une division par zéro ou une violation de contraintes peut également provoquer un rollback, même si le programmeur ne l‘a pas déclenché explicitement. 104

Propriétés ACID des transactions Les transactions ACID sont: Atomiques : la transaction est appliquée intégralement ou pas du tout. Cohérentes : les contraintes de la base de données sont préservées. Isolées : une transaction ne doit jamais voir les résultats intermédiaires des autres transactions (comme si elle était là seule à être exécutée). Durables : Dès qu’une transaction est validée, le système doit assurer que ses effets ne seront jamais perdus, même en cas de panne. Optionnel: des formes moins restrictives de transactions sont également souvent supportées. 105

Utilisons la relation Sells(bar,beer,price), et supposons que Joe’s Bar vend uniquement de la Bud pour $2.50 et de la Miller pour $3.00. Sally est en train d’interroger Sells afin d’avoir le prix le plus haut et le prix le plus bas de Joe’s bar. Joe decide d’arrêter de vendre de la Bud et de la Miller, mais décide de vendre uniquement de la Heineken à $3.50. 106 Exemple de processus en interaction et problèmes

Programme de Sally: Sally exécute les deux requêtes SQL suivantes (appelons les (min) et (max) pour simplifier les notations) (max)SELECT MAX(price) FROM Sells WHERE bar = ’Joe’’s Bar’; (min)SELECT MIN(price) FROM Sells WHERE bar = ’Joe’’s Bar’; Programme de Joe: Au même moment, Joe exécute les requêtes suivantes (notées (del) et (ins)). (del) DELETE FROM Sells WHERE bar = ’Joe’’s Bar’; (ins) INSERT INTO Sells VALUES(’Joe’’s Bar’, ’Heineken’, 3.50); 107

Exemple de processus en interaction et problèmes Problème lié à l’entrelacement des instructions Bien que (max) doive être effectué avant (min), et (del) avant (ins), il n’y a aucune contrainte sur l’ordre de ces instructions, à moins que les instructions de Sally et/ou celles de Joe soient regroupées en transactions. Exemple de problème: Supposons que les instructions soient exécutées dans l’ordre (max)(del)(ins)(min). Prix de Joe: Instruction: Résultat: Sally voit MAX < MIN! 108 {2.50,3.00} (del)(ins) {3.50} (min) 3.50 {2.50,3.00} (max) 3.00

Exemple de processus en interaction et problèmes  Résolution du problème en utilisant des transactions: Si les instructions de Sally (max)(min) sont regroupées dans une transaction, alors l’incohérence précédente n’a pas lieu. BEGIN; SELECT MAX(price) FROM Sells WHERE bar = ’Joe’’s Bar’; SELECT MIN(price) FROM Sells WHERE bar = ’Joe’’s Bar’; COMMIT; Dans ce cas, Sally voit les prix de Joe à un instant donné. –soit avant ou après que Joe change les prix. –soit au milieu, mais le MAX et le MIN sont calculés à partir des mêmes données. 109

Exemple de processus en interaction et problèmes Autre problème lié à l’annulation d’une transaction Supposons que Joe exécute (del)(ins) de manière classique (pas une transaction), mais qu’après les avoir exécutés il décide de les annuler par un ROLLBACK. Si Sally exécute ses requêtes après (ins) mais avant le rollback, elle voit une valeur, 3.50, qui n’existe pas dans la base de données.  Solution: Si Joe exécute (del)(ins) en tant que transaction, ses effets ne peuvent être vus par les autres qu’au moment où la transaction fait le COMMIT. –Si la transaction fait un ROLLBACK à la place, alors les modifications faites par celle-ci sont annulées de manière totalement transparente pour les autres utilisateurs. 110

Définir le niveau d’isolation des transactions SQL défini quatre niveaux d’isolation choisir quelles sont les interactions permises pour les transactions exécutées au même moment. Seulement un niveau (“serializable”) respectant les propriétés ACID. Chaque SGBD implémente les transactions à sa manière. Choisir le niveau d’isolation (à l’intérieur d’une transaction) SET TRANSACTION ISOLATION LEVEL X où X = 1.SERIALIZABLE 2.REPEATABLE READ 3.READ COMMITTED 4.READ UNCOMMITTED 111

Transactions en mode SERIALIZABLE Niveau d’isolation SERIALIZABLE = sérialisable, c.a.d. en série Si Sally = (max)(min) et Joe = (del)(ins) sont les deux transactions Supposons que Sally exécute sa transaction avec le niveau d’isolation SERIALIZABLE, alors elle verra la base de données soit avant, soit après que la transaction de Joe soit exécutée Mais pas au milieu. 112 {2.50,3.00} (del)(ins) {3.50} (max) 3.50 (min) {3.50} 3.50 Prix de Joe: Instruction: Résultat: {2.50,3.00} (min) 2.50 (del) {3.50} (ins) {2.50,3.00} (max) 3.00 {2.50,3.00} Prix de Joe: Instruction: Résultat:

Transactions en mode READ COMMITED Niveau d’isolation READ COMMITED = lecture de données validées Si Sally exécute sa transaction avec le niveau d’isolation “lecture de données validées” (READ COMMITTED), alors elle ne pourra voir que les données validées, mais pas nécessairement les mêmes données à chaque fois. Exemple: En mode READ COMMITTED, l’entrelacement (max)(del)(ins)(min) est permis, mais tant que Joe valide après (ins), Sally voit toujours MAX < MIN. 113 {2.50,3.00} (del)(ins) commit {3.50} (min) 3.50 {2.50,3.00} (max) 3.00 {3.50} Prix de Joe: Instruction: Résultat:

Transactions en mode REPEATABLE READ Niveau d’isolation REPEATABLE READ = lecture répétée Même comportement que READ COMMITED c.a.d. accès aux données validées Avec une contrainte en plus: Si les données sont lues à plusieurs reprises dans la même transaction, alors toutes les informations vues la première fois sont également vues la seconde fois –données vues = données première lecture + données actuellement validées  Attention: la seconde lecture et celles suivantes peuvent voir plus de tuples que ce qu’il y a réellement dans la base de données.  Lectures "fantômes" interdites dans PostgreSQL:  Une transaction de ce type voit un instantané au début de la transaction, et non pas du début de la requête en cours à l'intérieur de la transaction. 114

Transactions en mode REPEATABLE READ Exemple: Supposons que Sally utilise le mode REPEATABLE READ, et que l’ordre de l’exécution est (max)(del)(ins)(min). –(max) voit les prix 2.50 et 3.00. –(min) peut voir 3.50, mais aussi 2.50 et 3.00, car ils étaient vus lors de la lecture précédente faite par (max). 115 {2.50,3.00} (del)(ins) commit {2.50,3.00,3.50} (min) 2.50 {2.50,3.00} (max) 3.00 {3.50} Prix de Joe: Instruction: Résultat:

Transactions en mode READ UNCOMMITTED Niveau d’isolation READ UNCOMMITTED = lecture de données non validées Une transaction en mode READ UNCOMMITTED peut voir toutes les données de la base de données, même si elles ont été écrites par une transaction non validées. Exemple: Si Sally exécute sa transaction en mode READ UNCOMMITTED, elle peut voir un prix de 3.50 même si Joe l’annule ensuite. 116

Le niveau d’isolation est un choix personnel Votre choix, p.ex. transaction sérialisable, affecte uniquement la manière dont vous voyez la base de données Aucun effet sur la vision des autres utilisateurs. Exemple: Si Joe utilise le mode sérialisable, mais pas Sally, alors Sally peut ne voir aucun prix pour Joe’s Bar. –c.a.d., les requêtes de Sally peuvent s’exécuter au milieu de la transaction de Joe. 117

Résumé des niveaux d’isolation et de leurs propriétés lecture sale = transaction lit les données écrites par une transaction concurrente non validée. lecture non reproductible = transaction relit des données qu'elle a lu précédemment et trouve que les données ont été modifiées par une autre transaction (validée depuis la lecture initiale). lecture fantôme = transaction ré-exécute une requête renvoyant un ensemble de lignes satisfaisant une condition de recherche et trouve que l'ensemble des lignes satisfaisant la condition a changé du fait d'une autre transaction récemment validée. 118 Niveau d’isolationLecture saleLecture non reproductible Lecture fantôme Uncommited Read possible Commited Readimpossiblepossible Repeatable Readimpossible possible Serializableimpossible

Isolation sérialisable et vrai sérialisation définition "mathématique" d’exécution sérialisable: toute paire de transactions concurrentes validée avec succès apparaîtra comme ayant été exécutée en série, l'une après l'autre -- bien que celle survenant en premier n'est pas prévisible l’ordre d’exécution réel des transactions ne change pas le résultat Isolation sérialisable de PostgreSQL ne respecte pas totalement cette définition évite les comportements non désirables précédents mais le résultat peut changer en fonction de l’ordre d’exécution 119

Isolation sérialisable et vrai sérialisation Exemple: si A exécuté avant : sommeB = 330 si B exécuté avant : sommeB = 300 Solution pour garantir une vrai sérialisation: système de verrous explicites des ressources mais complexe à mettre en place et très coûteux PostgreSQL le permet (cf chapitre 13.3 Verrouillage explicite) 120 classevaleur 110 120 2100 2200 Transaction A: Begin; SELECT SUM(valeur) into sommeA FROM ma_table WHERE classe = 1; INSERT INTO ma_table value(2,sommeA); COMMIT; Transaction B: Begin; SELECT SUM(valeur) into sommeB FROM ma_table WHERE classe = 2; INSERT INTO ma_table value(1,sommeB); COMMIT;  Pas réellement sérialisable

Université de la Nouvelle-Calédonie frederic.flouvat@univ-nc.nc Frédéric Flouvat (dérivé du cours du Pr. Jeffrey Ullman, Stanford University) Chapitre 2: Définir et structurer les bases de données Contraindre les données 121

Contraintes et Triggers Une contrainte est une règle que doivent respecter les données et que le SGBD doit imposer. Exemple: contraintes de clés. Les Triggers sont uniquement exécutés lorsqu’une condition prédéfinie apparaît, p.ex. insertion d’un tuple. Plus facile à implémenter que des contraintes complexes. 122 Introduction aux contraintes en SQL Les triggers Retour à la théorie: les dépendances

Les types de contraintes Les clés (primaires). Les clés étrangères, ou contraintes d’intégrité référentielle. Les contraintes de valeurs. contraintes de valeurs sur un attribut particulier. Les contraintes sur les tuples. relations entre composants. Les assertions: n’importe quelle expression SQL booléenne. contraintes booléennes sur les objets de la base de données. 123 Introduction aux contraintes en SQL Les triggers Retour à la théorie: les dépendances

Clé primaire composé d’un seul attribut: Mettre PRIMARY KEY ou UNIQUE après le type dans la déclaration de l’attribut. CREATE TABLE Beers ( nameCHAR(20) UNIQUE, manfCHAR(20) ); Différence PRIMARY KEY vs. UNIQUE il peut y avoir une seule PRIMARY KEY pour une relation, mais plusieurs attributs UNIQUE. Aucun attribut d’une PRIMARY KEY ne peut avoir la NULL pour un tuple, alors que les attributs déclarés UNIQUE peuvent prendre la valeur NULL et ceci plusieurs fois. 124 Les clés primaires Introduction aux contraintes en SQL Les triggers Retour à la théorie: les dépendances

Clé primaire composée de plusieurs attributs: Mettre PRIMARY KEY( ) après le dernier attribut. CREATE TABLE Sells ( barCHAR(20), beerVARCHAR(20), priceREAL, PRIMARY KEY (bar, beer) ); 125 Les clés primaires Introduction aux contraintes en SQL Les triggers Retour à la théorie: les dépendances

Les clés étrangères Les valeurs prises par les attributs de la clé étrangère d’une relation doivent aussi apparaître ensemble au niveau des attributs d’une autre relation. une clé étrangère est clé primaire dans une autre relation. attributs utilisés pour les jointures. Exemple: Dans Sells(bar, beer, price), les valeurs pour l’attribut beer apparaissent aussi toutes au niveau de l’attribut name de la relation Beers(name, manf). 126 namemanf BudAnheuser-Busch Bud liteAnheuser-Busch ManPeterson 17Al barbeerprice PeteBud5 PeteBud lite2.22 KendMan1 Introduction aux contraintes en SQL Les triggers Retour à la théorie: les dépendances

Définir des clés étrangères Utiliser le mot clé REFERENCES, au choix : 1.après un attribut (pour une clé composé d’un attribut). 2.comme un élément de l‘expression: FOREIGN KEY ( ) REFERENCES ( ) Les attributs référencés doivent être déclarés PRIMARY KEY ou UNIQUE. 127 Introduction aux contraintes en SQL Les triggers Retour à la théorie: les dépendances

Exemple avec un attribut: CREATE TABLE Beers ( nameCHAR(20) PRIMARY KEY, manfCHAR(20) ); CREATE TABLE Sells ( barCHAR(20), beerCHAR(20) REFERENCES Beers(name), priceREAL ); Définir des clés étrangères 128 Introduction aux contraintes en SQL Les triggers Retour à la théorie: les dépendances

Exemple en tant qu’élément du schéma de la relation: CREATE TABLE Beers ( nameCHAR(20) PRIMARY KEY, manfCHAR(20) ); CREATE TABLE Sells ( barCHAR(20), beerCHAR(20), priceREAL, FOREIGN KEY(beer) REFERENCES Beers(name) ); Définir des clés étrangères 129 Introduction aux contraintes en SQL Les triggers Retour à la théorie: les dépendances

Si une contraint de clé étrangère est définie de la relation R vers la relation S, deux violations de cette contrainte sont possibles: 1.Une insertion ou une mise à jour de R introduit des valeurs qui n’existent pas dans S. 1.Une suppression ou mise à jour de S entraîne que des tuples de R deviennent “incomplets”. 130 Violation des contraintes de clé étrangère barbeerprice PeteBud5 PeteBud lite2.22 KendNber1 namemanf BudAnheuser-Busch Bud liteAnheuser-Busch ManPeterson 17Al barbeerprice PeteBud5 PeteBud lite2.22 KendMan1 namemanf BudAnheuser-Busch Bud liteAnheuser-Busch ManPeterson 17Al Introduction aux contraintes en SQL Les triggers Retour à la théorie: les dépendances

Actions à prendre pour imposer les contraintes de clé étrangère Exemple: Supposons que R = Sells, S = Beers. Une insertion ou une mise à jour de Sells doit être rejetée lorsqu’elle implique la vente d’une bière n’existant pas. Une suppression ou une mise à jour de Beers qui enlève une valeur de bière utilisée dans certains tuples de Sells peut être traitée de trois façons. 1.Default : rejet de la modification. 2.Cascade : faire les mêmes modifications dans Sells. bière supprimée : supprime des tuples de Sells. bière mise à jour: change des valeurs dans Sells. 3.Set NULL : remplace la bière par NULL. 131 Introduction aux contraintes en SQL Les triggers Retour à la théorie: les dépendances

Exemple: CASCADE Suppression du tuple de la bière Bud de la relation Beers: –Alors supprimer tous les tuples de Sells qui ont beer = ’Bud’. Mise à jour du tuple de la bière Bud en changeant ’Bud’ par ’Budweiser’: –Alors changer tous les tuples de Sells qui ont beer = ’Bud’ par beer = ’Budweiser’. Exemple: SET NULL Suppression du tuple de la bière Bud de la relation Beers: –Alors changer tous les tuples de Sells qui ont beer = ’Bud’ par beer = NULL. Mise à jour du tuple de la bière Bud en changeant ’Bud’ par ’Budweiser’: –même changement que pour la suppression. 132 Actions à prendre pour imposer les contraintes de clé étrangère Introduction aux contraintes en SQL Les triggers Retour à la théorie: les dépendances

Choisir une politique de validation de contrainte Quand une clé étrangère est déclarée, la politique de validation de la contrainte peut être SET NULL ou CASCADE indépendamment des suppressions et des mises à jours. Faire suivre la déclaration de clé étrangère par: ON [UPDATE, DELETE][SET NULL, CASCADE] Les deux clauses UPDATE ET DELETE peuvent être utilisées. Si aucune n’est définie, celle par défaut est utilisée (rejet). 133 Introduction aux contraintes en SQL Les triggers Retour à la théorie: les dépendances

Choisir une politique de validation de contrainte Exemple: définir une politique CREATE TABLE Sells ( barCHAR(20), beerCHAR(20), priceREAL, FOREIGN KEY(beer) REFERENCES Beers(name) ON DELETE SET NULL ON UPDATE CASCADE ); 134 Introduction aux contraintes en SQL Les triggers Retour à la théorie: les dépendances

Contraintes sur les attributs Contraintes sur la valeur d’un attribut. Ajouter CHECK( ) après la déclaration de l’attribut. La condition peut être définie sur l’attribut contraints, mais tout autre relations ou attributs doivent être dans une sous-requête. Exemple: CREATE TABLE Sells ( barCHAR(20), beerCHAR(20)CHECK ( beer IN (SELECT name FROM Beers)), priceREAL CHECK ( price <= 5.00 ) ); 135 Introduction aux contraintes en SQL Les triggers Retour à la théorie: les dépendances

Timing des vérifications Vérifications des valeurs effectuées uniquement quand une valeur pour l’attribut contraint est insérée ou mise à jour. Exemple: CHECK (price <= 5.00) -vérifie chaque nouveau prix et refuse la modification (pour le tuple visé) si le prix est supérieur à 5$. CHECK (beer IN (SELECT name FROM Beers)) –vérifie que chaque nouvelle bière soit une bière référencée dans Beers –pas vérifié si une bière est supprimée de Beers, contrairement aux clés étrangères. 136 Introduction aux contraintes en SQL Les triggers Retour à la théorie: les dépendances

Contraintes sur les tuples CHECK ( ) peut être ajoutée comme un élément de la définition du schéma de la relation. Dans ce cas, la condition peut traiter de tous les attributs de la relation. mais l’utilisation d’un autre attribut ou d’une autre relation nécessite de faire une sous-requête Vérifiée à l’insertion ou lors de la mise à jour uniquement. Exemple: Seul les bars de Joe peuvent vendre de la bière à plus de 5$. CREATE TABLE Sells ( barCHAR(20), beerCHAR(20), priceREAL, CHECK (bar = ’Joe’’s Bar’ OR price <= 5.00) ); 137 Introduction aux contraintes en SQL Les triggers Retour à la théorie: les dépendances

Les Triggers: Motivation Les contraintes sur les attributs et les tuples sont vérifiées à des instants connus, mais ne sont pas “puissantes”. Les triggers laissent l’utilisateur décider à quel moment une condition doit être vérifiée. 138 Introduction aux contraintes en SQL Les triggersRetour à la théorie: les dépendances

Des règles Evénement-Condition-Action Un autre nom des “trigger” est règles ECA, ou règles événement- condition-action. Evénement : typiquement un type de modification de la base de données, p.ex. “insertion dans Sells.” Condition : Toute expression booléenne SQL. Action : Toute instruction SQL. Exemple: A la place d’utiliser une clé étrangère et de rejeter les insertions dans Sells(bar, beer, price) avec des bières inconnues, un trigger peut ajouter cette bière à Beers, en mettant la valeur NULL pour le fabriquant. 139 Introduction aux contraintes en SQL Les triggersRetour à la théorie: les dépendances

Définition d’un Trigger 140 l’événement la condition l’action Exemple précédent: CREATE TRIGGER BeerTrig AFTER INSERT ON Sells REFERENCING NEW ROW AS NewTuple FOR EACH ROW WHEN (NewTuple.beer NOT IN (SELECT name FROM Beers)) INSERT INTO Beers(name) VALUES(NewTuple.beer); Introduction aux contraintes en SQL Les triggersRetour à la théorie: les dépendances

Options: CREATE TRIGGER CREATE TRIGGER BeerTrig AFTER INSERT ON Sells REFERENCING NEW ROW AS NewTuple FOR EACH ROW WHEN (NewTuple.beer NOT IN (SELECT name FROM Beers)) INSERT INTO Beers(name) VALUES(NewTuple.beer); CREATE TRIGGER OU CREATE OR REPLACE TRIGGER utile pour remplacer ou modifier un trigger. 141 Introduction aux contraintes en SQL Les triggersRetour à la théorie: les dépendances

Options: L’événement CREATE TRIGGER BeerTrig AFTER INSERT ON Sells REFERENCING NEW ROW AS NewTuple FOR EACH ROW WHEN (NewTuple.beer NOT IN (SELECT name FROM Beers)) INSERT INTO Beers(name) VALUES(NewTuple.beer); AFTER ou BEFORE Egalement, INSTEAD OF, si la relation est une vue. INSERT, DELETE ou UPDATE UPDATE peut être UPDATE OF ON … pour cibler un ou plusieurs attributs. Recommandations: BEFORE pour vérifier ou modifier les données insérées ou maj AFTER pour propager des modifications sur d'autres tables 142 Introduction aux contraintes en SQL Les triggersRetour à la théorie: les dépendances

Options: FOR EACH ROW CREATE TRIGGER BeerTrig AFTER INSERT ON Sells REFERENCING NEW ROW AS NewTuple FOR EACH ROW WHEN (NewTuple.beer NOT IN (SELECT name FROM Beers)) INSERT INTO Beers(name) VALUES(NewTuple.beer); Les triggers sont “niveau ligne” ou “niveau instruction.” FOR EACH ROW indique un trigger niveau ligne; par défaut niveau instruction. Le triggers niveau ligne: executé une fois pour chaque tuple modifié. Les triggers niveau instruction: exécuté une fois pour chaque instruction SQL, peu importe le nombre de tuples modifiés. 143 Introduction aux contraintes en SQL Les triggersRetour à la théorie: les dépendances

Options: REFERENCING CREATE TRIGGER BeerTrig AFTER INSERT ON Sells REFERENCING NEW ROW AS NewTuple FOR EACH ROW WHEN (NewTuple.beer NOT IN (SELECT name FROM Beers)) INSERT INTO Beers(name) VALUES(NewTuple.beer); Un événement INSERT implique un nouveau tuple (niveau ligne) ou une nouvelle table (niveau instruction). la “table” est l’ensemble des tuples insérés. DELETE implique un ancien tuple ou une table. UPDATE impliques les deux. En résumé [NEW OLD][ROW TABLE] AS 144 Introduction aux contraintes en SQL Les triggersRetour à la théorie: les dépendances

Options: La Condition CREATE TRIGGER BeerTrig AFTER INSERT ON Sells REFERENCING NEW ROW AS NewTuple FOR EACH ROW WHEN (NewTuple.beer NOT IN (SELECT name FROM Beers)) INSERT INTO Beers(name) VALUES(NewTuple.beer); Toute condition à résultat booléen. Evaluée sur la base de données avant ou après l’événement, en fonction de BEFORE ou AFTER. mais toujours avant que les changements prennent effet. Accède au nouvel/ancien tuple/table grâce à la variable définie dans la clause REFERENCING. 145 Introduction aux contraintes en SQL Les triggersRetour à la théorie: les dépendances

Options: L’Action CREATE TRIGGER BeerTrig AFTER INSERT ON Sells REFERENCING NEW ROW AS NewTuple FOR EACH ROW WHEN (NewTuple.beer NOT IN (SELECT name FROM Beers)) INSERT INTO Beers(name) VALUES(NewTuple.beer); Il peut y avoir plus d’une instruction SQL dans l’action. Entouré par BEGIN... END s’il y en a plus d’une. Mais les requêtes d’interrogations n’ont pas de sens dans une action, une action est donc limitée à des requêtes de modifications. Attention: l'action peut déclencher à nouveau le trigger Risque d'exécution infinie 146 Introduction aux contraintes en SQL Les triggersRetour à la théorie: les dépendances

Un autre Exemple de trigger 147 événement: uniquement les changements de prix mises à jour -> accés aux anciens et nouveaux tuples si le prix augmente assez, ajouter le bar dans RipoffBars considérer chaque changement de prix condition: une augmentation du prix > 1$ En utilisant Sells(bar, beer, price) et une relation unaire RipoffBars(bar), maintenir la liste des bars qui augmentent le prix d’une bière de plus de 1$. CREATE TRIGGER PriceTrig AFTER UPDATE OF price ON Sells REFERENCING OLD ROW AS ooo NEW ROW AS nnn FOR EACH ROW WHEN(nnn.price > ooo.price + 1.00) INSERT INTO RipoffBars VALUES(nnn.bar); 147 Introduction aux contraintes en SQL Les triggersRetour à la théorie: les dépendances

Remarque sur la visibilité des modifications 148 Quelles sont les données que voit un trigger lorsqu'il s'exécute ? Dans certains cas pas évident car la requête Q qui a déclenché le trigger peut être encore active et faire des modifications  Trigger niveau instruction Si BEFORE évènement: aucune des modifications de Q visibles Si AFTER évènement: toutes les modifications de Q visibles  Trigger niveau ligne (FOR EACH ROW) Si BEFORE événement: les modifications des lignes déjà traitées par Q sont visibles pb: ordre de traitement des tuples pas prévisible Si AFTER événement: toutes les modifications de Q visibles Introduction aux contraintes en SQL Les triggersRetour à la théorie: les dépendances

Les Trigger dans PostgreSQL Les différences Obligatoirement associé à une fonction qui retourne un objet trigger –Nécessité de créer la fonction d'abord, puis de créer le trigger –Nécessité de retourner un objet trigger Si niveau instruction, RETURN NULL Si niveau ligne, si AFTER événement, RETURN NULL si BEFORE événement, RETURN NULL annule la requête en cours RETURN NEW pour valider INSERT/UPDATE RETURN OLD pour valider DELETE Référencer le tuple modifié (celui sur lequel se fait l'action) –NEW dans la fonction pour INSERT/UPDATE –OLD dans la fonction pour DELETE/UPDATE Ne supporte pas les instructions OF…(colonnes)…ON table et REFERENCING … –p.ex. CREATE TRIGGER PriceTrig AFTER UPDATE OF price ON Sells REFERENCING OLD ROW AS ooo NEW ROW AS nnn … 149 Introduction aux contraintes en SQL Les triggersRetour à la théorie: les dépendances

Les exemples précédents dans PostgreSQL CREATE OR REPLACE FUNCTION trig_beer() RETURNS TRIGGER AS ' BEGIN INSERT INTO "Beers"(name) VALUES (NEW.beer); RETURN NULL; END; ' LANGUAGE 'plpgsql' CREATE TRIGGER BeerTrigger AFTER INSERT ON "Sells" FOR EACH ROW WHEN ( NEW.beer NOT IN (SELECT name FROM Beers) ) EXECUTE PROCEDURE trig_beer() ; 150 Introduction aux contraintes en SQL Les triggersRetour à la théorie: les dépendances

Les exemples précédents dans PostgreSQL CREATE OR REPLACE FUNCTION trig_price() RETURNS TRIGGER AS ' BEGIN INSERT INTO "RipoffBars" VALUES (NEW.bar); RETURN NULL; END; ' LANGUAGE 'plpgsql' CREATE TRIGGER PriceTrig AFTER UPDATE ON "Sells" FOR EACH ROW WHEN ( NEW.price > OLD.price + 1.00 ) EXECUTE PROCEDURE trig_price(); 151 Introduction aux contraintes en SQL Les triggersRetour à la théorie: les dépendances

Les contraintes du point de vue théorique 152 Différents concepts théoriques pour représenter les principaux types de contraintes (appelées aussi "classes de contraintes") Dépendances fonctionnelles -> fondement théorique des clés et de la normalisation Dépendances d'inclusions -> fondement théorique des clés étrangères Dépendances multi-valuées, …  Mécanismes formels pour exprimer des propriétés attendues pour les données  Dépendances utilisées pour protéger les données contre certaines anomalies (p.ex. avec des triggers) améliorer la conception/maintenance d'un schéma pour améliorer les performances 152 Introduction aux contraintes en SQL Les triggersRetour à la théorie: les dépendances

Erreur de conception et Anomalies 153 Bon schéma relationnel: pas de redondance –redondance = plusieurs fois la même information le fait que A.B. soit le fabricant de la Bud pas d’anomalies. –Anomalie de mise à jour : une occurrence d’une information est modifiée et pas les autres si Janeway part pour l’Intrepid, pensera-t-on à changer tous les n- uplets? –Anomalie de suppression : une information pertinente est perdue en détruisant un n-uplet. : si personne n’aime Bud, on perd le fait que son fabricant soit A.B. 153 nameaddrbeersLikedmanffavBeer JanewayVoyagerBudA.B.WickedAle JanewayVoyagerWickedAlePete’sWickedAle SpockEnterpriseBudA.B.Bud Introduction aux contraintes en SQL Les triggersRetour à la théorie: les dépendances

Dépendances Fonctionnelles 154 X -> A propriété d’une relation R si 2 n-uplets (tuples) sont égaux sur les attributs X alors ils sont égaux sur l’attribut A. Quand c’est le cas, on dit que R satisfait la DF “X -> A ” Conventions: …, X, Y, Z ensembles d’attributs; A, B, C,… attributs. On écrit ABC, plutôt que {A,B,C }. Exemple: Drinkers(name, addr, beersLiked, manf, favBeer) FD naturelles pour ce schéma: 1.name -> addr 2.name -> favBeer 3.beersLiked -> manf 154 Introduction aux contraintes en SQL Les triggersRetour à la théorie: les dépendances

nameaddr beersLiked manffavBeer JanewayVoyager Bud A.B.WickedAle JanewayVoyager WickedAle Pete’sWickedAle SpockEnterprise Bud A.B.Bud Parce que name -> addr Parce que beersLiked -> manf Exemple 155 Parce que name -> favBeer Introduction aux contraintes en SQL Les triggersRetour à la théorie: les dépendances

DF à plusieurs attributs 156 Plus d’un attribut à droite: pratique mais pas indispensable Pratique comme racourci pour plusieurs DF Exemple: name -> addr name -> favBeer deviennent name -> addr favBeer Plus d’un attribut à gauche: essentiel. Exemple: bar beer -> price 156 Introduction aux contraintes en SQL Les triggersRetour à la théorie: les dépendances

Clés d’une Relation 157 K est une clé de R ssi pour tout attribut A de R on a la DF K -> A K est une clé minimale de R ssi K est une clé, et aucun sous ensemble strict de K n’est une clé de R Exemple: Drinkers(name, addr, beersLiked, manf,favBeer) {name, beersLiked} est une clé: ces 2 attributs déterminent tous les autres. name -> addr favBeer et beersLiked -> manf {name, beersLiked} est une clé minimale: ni {name}, ni {beersLiked} ne sont des clés name ne détermine pas manf; beersLiked ne détermine pas addr. Il n’y a pas d’autre clé minimale, mais il y a beaucoup d’autres clés –tout ensemble d’attributs contenant {name, beersLiked}. 157 Introduction aux contraintes en SQL Les triggersRetour à la théorie: les dépendances

Les dépendances d'inclusions (DI) 158 Autre type de dépendances appelées dépendances d’inclusion (DI) ou ≪ contraintes d'intégrité référentielles ≫. Entre deux relations. Exemple: Tout titre projeté actuellement (présent dans la relation Programme) est le titre d’un film (c’est-à-dire apparaissant dans la relation Films). Programme[Titre] ⊆ Films[Titre]. Les DI peuvent faire intervenir des séquences d’attributs de chaque côté. 158 Introduction aux contraintes en SQL Les triggersRetour à la théorie: les dépendances

Différences DF versus DI 159 Les DI se différencient des DF sur plusieurs points 1.Peuvent être définies entre attributs de relations différentes 2.Possèdent un caractère plus global (représentent les liens logiques entre des relations). 3.Les DI sont définies non pas entre deux ensembles quelconques d’attributs, mais entre deux séquences d’attributs de même taille. –L’ordre des attributs est donc très important pour les DI ! ! ! 159 Introduction aux contraintes en SQL Les triggersRetour à la théorie: les dépendances

Syntaxe et sémantique des DI 160 Soit R un schéma de base de données. Une dépendance d’inclusion sur R est une expression de la forme R [X ] ⊆ S [Y ], où R,S ∈ R, X et Y sont des séquences d’attributs distincts respectivement de R et de S, et |X| = |Y|. Une DI est satisfaite dans une base de données si toutes les valeurs prises par la partie gauche apparaissent dans la partie droite. Autrement dit, Soit d = {r 1, r 2,..., r n } une base de données sur un schéma R = {R1,...,R n }. Une dépendance d’inclusion R i [X] ⊆ R j [Y] sur R est satisfaite dans d, noté d |= R i [X] ⊆ R j [Y], si ∀ t i ∈ r i, ∃ t j ∈ r j tel que t i [X] = t j [Y] de manière équivalente, π X (r i ) ⊆ π Y (r j ). 160 Introduction aux contraintes en SQL Les triggersRetour à la théorie: les dépendances

Exemple 161 Supposons des schémas de relation pour décrire les modules : MODULE = {NUMMODULE ; INTITULE ; DESC } et un schéma de relation pour décrire les séances de cours : SEANCE = {DATE ; NUMMODULE ; NUMSALLE } Pour forcer que les numéros de modules dans les séances soient bien des modules qui existent, on devra alors définir la contrainte : SEANCE [NUMMODULE ] ⊆ MODULE [NUMMODULE ] 161 Introduction aux contraintes en SQL Les triggersRetour à la théorie: les dépendances

DI et clé étrangère 162 Une contrainte d’intégrité référentielle est une DI dont la partie droite est une clé Un attribut (ou ens. d’attributs) d’une relation apparaît comme clé d’une autre relation. La partie gauche d’une contrainte d’intégrité référentielle est appelée clé étrangère 162 Introduction aux contraintes en SQL Les triggersRetour à la théorie: les dépendances

Exemple 163 les DI ne définissent pas toujours des clés étrangères ! ! ! Il suffit d’imaginer qu’on souhaite imposer que tous les cours possèdent au moins une séance dans l’année. On définira alors une DI : COURS[NUMCOURS] ⊆ SEANCE[NUMCOURS] Tous les cours apparaîtront au moins une fois dans la relation des séances NUMCOURS n’est pas une clé de SEANCE (on imagine difficilement que tous les cours n’aient qu’une seule séance !) Donc ce n’est pas une clé étrangère 163 Introduction aux contraintes en SQL Les triggersRetour à la théorie: les dépendances

Les Dépendances : comment les trouver et pourquoi ? 164 Comment les trouver ? L'analyse du problèmes donne des dépendances de bon sens –“jamais deux cours à la même heure dans la même salle” heure salle -> cours. Problème: –des dépendances peuvent être impliquées de façon implicite par d'autres dépendances nom -> adresse et adresse -> ville, donc nom -> ville –ces contraintes implicites peuvent échapper à la connaissance du concepteur  Nécessité de méthodes permettant de déduire l'ensemble des dépendances induites par un ensemble de dépendances de départ Inférence des DF, DI, … 164 Introduction aux contraintes en SQL Les triggersRetour à la théorie: les dépendances

Les Dépendances : comment les trouver et pourquoi ? 165 Pourquoi cette formalisation théorique des contraintes ? Exhiber des propriétés théoriques Définir des algorithmes permettant de découvrir automatiquement les dépendances –même celles implicites Normaliser les schémas pour éviter les anomalies dans les données –normaliser = décomposer les schémas en fonction des dépendances 165 Introduction aux contraintes en SQL Les triggersRetour à la théorie: les dépendances

Université de la Nouvelle-Calédonie frederic.flouvat@univ-nc.nc (dérivé du cours du Pr. Jeffrey Ullman, Stanford University) Chapitre 2: Définir et structurer les bases de données Définir des vues des données

Les Vues Une vue est une relation définie en fonction de tables stockées (appelée tables de base) et d’autres vues. Il existe deux types de vues: 1.Virtuelles = pas stockées dans la base de données; juste une requête enregistrée construisant à chaque appel la relation. 2.Matérialisées = relation réellement construite et enregistrée. 167

Déclarer une Vue Déclaré par l’instruction SQL: CREATE [MATERIALIZED] VIEW AS ; Par défaut, la vue est virtuelle. Exemple: CanDrink(drinker, beer) est une vue « contenant » les pairs buveur-bière tel que le buveur fréquente au moins un bar proposant la bière: CREATE VIEW CanDrink AS SELECT drinker, beer FROM Frequents, Sells WHERE Frequents.bar = Sells.bar; 168

Accéder à une Vue Interroger une vue comme si c’était une table de base. Dans certains cas, possibilité de modifier le contenu d’une vue si celle-ci ne dépend que d’une seule table de base. modifier = INSERT, DELETE, UPDATE par contre ALTER toujours possible Exemple: SELECT beer FROM CanDrink WHERE drinker = ’Sally’; 169

Modification de Vues grâce à des Triggers En général, il est impossible de modifier une vue virtuelle, tout simplement parce qu’elle n’existe pas concrètement. Mais l’option d’événement INSTEAD OF des triggers permet d’interpréter des modifications sur des vues d’une manière qui fait sens. CREATE TRIGGER INSTEAD OF [INSERT, DELETE, UPDATE] ON REFERENCING [NEW, OLD] [ROW, TABLE] AS [FOR EACH ROW] WHEN 170

Jointure naturelle entre Likes, Sells, et Frequents Prend une copie de chaque attribut Modification de Vues grâce à des Triggers Exemple: La vue Synergy est composée du triplet (drinker, beer, bar) et représente les buveurs, les bières qu’ils aiment, ainsi que les bars qui les servent. CREATE VIEW Synergy AS SELECT Likes.drinker, Likes.beer, Sells.bar FROM Likes, Sells, Frequents WHERE Likes.drinker = Frequents.drinker AND Likes.beer = Sells.beer AND Sells.bar = Frequents.bar; 171

Modification de Vues grâce à des Triggers Exemple (suite): Nous ne pouvons pas insérer dans Synergy --- c’est une vue virtuelle. Mais nous pouvons utiliser à la place un trigger avec INSTEAD OF pour transformer l’insertion d’un tuple (drinker, beer, bar) en trois insertions sur Likes, Sells, et Frequents. –Sells.price aura la valeur NULL. CREATE TRIGGER ViewTrig INSTEAD OF INSERT ON Synergy REFERENCING NEW ROW AS n FOR EACH ROW BEGIN INSERT INTO LIKES VALUES(n.drinker, n.beer); INSERT INTO SELLS(bar, beer) VALUES(n.bar, n.beer); INSERT INTO FREQUENTS VALUES(n.drinker, n.bar); END; 172

Les vues Matérialisées CREATE MATERIALIZED VIEW AS ; Problème: chaque fois qu’une table de base change, la vue matérialisée peut changer. Il faut reconstruire la vue à chaque changement. Solution: Reconstruction périodique de la vue matérialisée, qui sans cela serait "périmée". L’implémentation dépend du SGBD. 173

Les vues Matérialisées Exemples: Mailing List d’une classe –La mailing list d’une classe peut être obtenue par une vue matérialisée sur la table de base contenant tous les étudiants. –si la vue est mise à jour 4 fois par jours, les étudiants enregistrés entre deux mises à jour ne recevront pas les mails. Un entrepôt de données –Les magasins Wal-Mart stockent les ventes de tous les magasins dans une base de données. –Pendant la nuit, les ventes du jour sont utilisées pour mettre à jour un entrepôt de données (data warehouse) = des vues matérialisées sur les ventes. –L’entrepôt est utilisé par les preneurs de décision pour prédire les tendances et envoyer des produits là où ils se vendent le mieux. 174

Les vues matérialisées dans PostgreSQL La notion de vue matérialisée n’existe pas dans PostgreSQL Une solution: utiliser une table standard pour représenter la vue, et définir des fonctions et des trigger pour la rafraichir Créer une table matviews pour stocker les informations sur les vues matérialisées créées. –au moins 2 attributs: nom de la vue mv_name et date du dernier rafraichissement de la vue last_refresh. Créer 3 fonctions pour créer, supprimer et rafraichir la vue. –vérifier l’existence de la vue –créer/supprimer une table ayant pour nom celui de la vue –rafraichir les informations (supprimer tout et réinsérer) –mettre à jour les informations dans matviews Créer des triggers qui rafraichissent la « table vue » pour chaque action sur les tables sous-jacentes. –possibilité d’utiliser last_refresh pour éviter de trop rafraichir 175

Les vues matérialisées dans PostgreSQL Attention: solution actuelle très simplifiée Pour la rendre générique, –il faudrait stocker dans matviews les informations sur la requête faite pour construire la vue (nom des tables, attributs, sélection, regroupement,…). –il faudrait généraliser les fonctions et triggers à n’importe quelle requête.  Obtenir une implémentation complète des vues matérialisées est complexe prendre en compte le fait que la structure de la vue peut être changée généraliser les traitements des fonctions et triggers si la vue dépend d’autres vues, il faut rafraichir les autres vues avant de rafraichir la vue courante … 176

Université de la Nouvelle-Calédonie frederic.flouvat@univ-nc.nc (dérivé du cours du Pr. Jeffrey Ullman, Stanford University et du cours du Pr. Christian Retoré, Université de Bordeaux) Chapitre 2: Définir et structurer les bases de données Inférence des DF et normalisation

PLAN  Inférence des DF  Normalisation de bases de données 178

Rappels sur les Dépendances Fonctionnelles 179 La DF X -> Y est satisfaite dans la relation R ssi 2 tuples égaux sur les attributs X sont aussi égaux sur les attributs Y p.ex. name -> addr favBeer Une clé primaire représente un cas particulier de DF Intérêt des DF: améliorer le schéma des bases de données en évitant des anomalies Anomalie de mise à jour et anomalie de suppression Des DF peuvent être déduites en analysant le problème (p.ex. heure salle -> cours)  Problème: des DF implicites pouvent échappées à cette analyse Problème de l'inférence des DF, i.e. à partir d'un ensemble de DF connues, comment trouver toutes les DF satisfaites par une relation 179

Déduire des DF 180 On se donne F un ensemble de DF: X 1 -> A 1, X 2 -> A 2,…, X n -> A n, et on souhaite savoir si une DF Y -> B est la conséquence sémantique de F c’est-à-dire Y -> B est satisfaite dans tout modèle satifaisant F. Exemple: Si A -> B et B -> C sont vraies, sans doute que A -> C aussi, même si on ne le dit pas. Important pour la conception de bons schémas relationnels. 180

Test d'inférence 181 Pour tester si Y -> B, commencer par supposer que deux tuples sont égaux sur tous les attributs de Y Y 0000000... 0 00000??... ? Utiliser l'ensemble de DF de départ pour en déduire que les tuples sont égaux sur d’autres attributs Si B est l’un des attributs pour lesquels il y a égalité alors Y -> B est vrai Sinon les 2 tuples, avec les égalités induites par les dépendances, forment un contre-exemple demontrant que Y -> B n'est pas une conséquence des DF de départ 181

Test d'inférence Exemple : DF données { C->B, AB->D } AC-> D ? C->B AB->D Donc AC->D est satisfait AB-> C ? 182 ABCDE a’b’c’d’e’ a’c’ ABCDE a’b’c’d’e’ a’b’c’ ABCDE a’b’c’d’e’ a’b’c’ d’

Test de fermeture Une façon plus simple pour inférer des DF est de calculer la fermeture de Y, noté Y + Etant donné un ensemble F de DF et X est un ensemble d’attributs, on note X + l’ensemble des attributs A tels que X->A est conséquence de F  Fermeture d'un ensemble d'attributs Initialisation: Y + = Y. Induction: Rechercher une partie gauche de DF dans F qui soit inclue dans le Y + courant. Si la DF est X->A, ajouter A à Y +. Répéter ces opérations jusqu'à ce que l'on n'ajoute plus de nouveaux attributs dans Y +. Autrement dit, Y + n+1 =Y + n U {A| Z->A et Z inclus dans Y + n } Arrêt: stabilité Y + n+1 =Y + n 183 Y+Y+ new Y + XA

Test de fermeture Exemple : Soit F = { AB->C, C->A, BC->D, ACD->B, D->EG, BE->C, CG->BD, CE->AG }, quelle est la fermeture de BD ? Initialisation: BD + ={B,D} Itération 1: –rechercher les DF dont la partie gauche est dans BD + : D->EG –ajouter leur partie droite dans la fermeture: BD + ={B,D,E,G} Itération 2: –rechercher les DF dont la partie gauche est dans le nouveau BD + : D->EG, BE->C –ajouter leur partie droite dans la fermeture: BD + ={B,D,E,G,C} Itération 3: –rechercher les DF dont la partie gauche est dans le nouveau BD + : C->A, BC->D, D->EG, BE->C, CE->AG –ajouter leur partie droite dans la fermeture: BD + ={B,D,E,G,C,A} … 184

Idée simple pour trouver toutes les DF Commencer à partir d'un ensemble de DF connues et trouver toutes les DF non triviales qui découle de cet ensemble de DF non triviale = partie droite non inclue dans la partie gauche  Fermeture d'un ensemble de DF Un algorithme simple, mais exponentiel 1.Pour chaque ensemble d’attribut X de la relation, on calcule X +. 2.Ajouter X ->A pour tout A dans X + - X. 3.Supprimer XY ->A si on découvre X ->A. car XY ->A découle de X ->A quelle que soit la manière dont on projette Astuces: Inutile de calculer la fermeture de l'ensemble contenant tous les attributs et celle de l'ensemble vide Si on trouve X + = tous les attributs, alors il en va de même de tout X’ contenant X 185

Idée simple pour trouver toutes les DF Exemple: Soit la relation ayant pour schéma {A,B,C} avec les DF A ->B et B ->C, cad F={A->B, B->C} A + =ABC ; donne A ->B, A ->C B + =BC ; donne B ->C C + =C ; ne donne rien AB + ; inutile de calculer car A + = tous les attributs AC + ; inutile de calculer car A + = tous les attributs BC + =BC ; ne donne rien DF obtenues: F + ={A ->B, A ->C, B ->C} 186

Objectif de l'inférence des DF Motivation: "normalisation", le processus où le schéma d'une relation est divisé en plusieurs schémas. Exemple: Soit une relation R ayant pour schéma {A,B,C,D} avec l'ensemble de DF {AB->C, C->D, D->A} Décomposer en 2 schémas {A,B,C} et {A,D}. Quelles DF doivent être satisfaites dans {A,B,C} ? non seulement AB->C mais aussi C->A ! 187 a1b1ca1b1c ABC ABCD a2b2ca2b2c a 1 b 1 c d 1 a 2 b 2 c d 2 donne d 1 =d 2 parce que C -> D a 1 =a 2 parce que D -> A Ainsi, des tuples issus de la projection avec les mêmes valeurs pour C ont la même valeur pour A, cad C -> A.

PLAN Inférence des DF  Normalisation de bases de données 188

Design de schéma relationnel L'objectif du design de schéma relationnel est d'éviter les anomalies et les redondances Anomalie de mise à jour : une occurrence d’une information est modifiée et pas les autres Anomalie de suppression : une information pertinente est perdue en détruisant un n-uplet. Exemple de mauvais design: Drinkers(name, addr, beersLiked, manf, favBeer) Les données sont redondantes, car chaque ??? peut être retrouvé en utilisant les DF name -> addr favBeer et beersLiked -> manf. 189 nameaddrbeersLikedmanffavBeer JanewayVoyagerBudA.B.WickedAle Janeway???WickedAlePete’s??? SpockEnterprise???A.B.Bud

Design de schéma relationnel Ce mauvais schéma fait aussi ressortir des anomalies Anomalie de mise à jour: si Janeway part pour l’Intrepid, pensera-t-on à changer tous les tuples? Anomalie de suppression: si personne n’aime Bud, on perd le fait que son fabricant soit Anheuser-Busch.  Besoin de propriétés, de règles, de méthodes permettant de concevoir de bons schémas 190 nameaddrbeersLikedmanffavBeer JanewayVoyagerBudA.B.WickedAle JanewayVoyagerWickedAlePete’sWickedAle SpockEnterpriseBudA.B.Bud

Forme Normale de Boyce-Codd (BCNF) Une relation R est dite en BCNF ssi pour toute Dépendance Fonctionnelle non triviale X ->A sur les attributs de R, X est une super clé. non triviale = X ne contient pas A super clé = clé (minimale) ou sur-ensemble d'une clé (minimale) Exemple: Drinkers(name, addr, beersLiked, manf, favBeer) DF: name->addr favBeer, beersLiked->manf Une seule clé minimale {name, beersLiked}. Pour chaque DF: la partie gauche n’est pas une super clé Drinkers n’est pas en BCNF (prendre l’une des deux DF au choix) 191

Forme Normale de Boyce-Codd (BCNF) Autre exemple: Beers(name, manf, manfAddr) DF: name->manf, manf->manfAddr Une seule clé minimale {name}. name->manf ne contredit pas BCNF, mais par contre la relation n’est pas BCNF à cause de manf->manfAddr. 192

Décomposer un schéma en BCNF Soit une relation R avec un ensemble F de DF Chercher les DF X ->B telles que X ne soit pas une clé Si R pas BCNF, il y en a au moins une. Calculer X +. Rq: X + ne contient pas tous les attributs, sinon X serait une clé. Décomposer R en suivant X->B Remplacer R par par deux relations dont les attributs sont: –R 1 = X + –R 2 = R – (X + – X ) Projeter les DF de la fermeture de F sur ces deux nouveaux schémas 193 R R - X + XX + - X R2R2 R 1 =X +

Décomposer un schéma en BCNF Exemple : Drinkers(name, addr, beersLiked, manf, favBeer) F = { name->addr, name -> favBeer, beersLiked->manf } Trouver une DF qui fait que Drinkers n’est pas en BCNF: name->addr Calcule de la fermeture des attributs de la partie gauche: {name} + = {name, addr, favBeer} On obtient deux relations: 1.Drinkers1(name, addr, favBeer) = {name} + 2.Drinkers2(name, beersLiked, manf) = {name, addr, beersLiked, manf, favBeer} - {addr, favBeer} 194

Décomposer un schéma en BCNF Exemple (suite) : Ce n'est pas fini; nous devons vérifier que Drinker1 et Drinker2 sont en BCNF Projeter les DF est assez facile pour ce cas (car F=F + ) –F + = { name->addr, name -> favBeer, beersLiked->manf } –Pour Drinkers1(name, addr, favBeer), les DF pertinentes sont name->addr et name->favBeer. –{name} est donc la seule clé et Drinkers1 est en BCNF. –Pour Drinkers2(name, beersLiked, manf), la seule DF est beersLiked->manf, et la seule clé est {name, beersLiked}.  Pas BCNF, on recommence la décomposition pour Drinkers2. 195

Décomposer un schéma en BCNF Exemple (suite) : La DF qui fait que Drinkers2 n’est pas en BCNF est beersLiked->manf Calcule de la fermeture {beersLiked} + = {beersLiked, manf} On décompose donc Drinkers2 en 1.Drinkers3(beersLiked, manf)=X + 2.Drinkers4(name, beersLiked)={name,beersLiked,manf} - {manf} Projeter les DF de l'ensemble F + dans ces nouveaux schémas –Pour Drinkers3(beersLiked, manf), la seule DF pertinente est beersLiked->manf –{beersLiked} est donc la seule clé et Drinkers3 est en BCNF –Pour Drinkers4(name, beersLiked), aucune DF (implicite ou pas) n'est pertinente –{name, beersLiked} est clé et Drinkers4 est en BCNF 196

Décomposer un schéma en BCNF Exemple (fin) :  Décomposition de Drinkers : 1.Drinkers1(name, addr, favBeer) 2.Drinkers3(beersLiked, manf) 3.Drinkers4(name, beersLiked) Rq: Drinkers1 décrit les personnes, Drinkers3 décrit les bières, et Drinkers4 décrit la relation entre les personnes et les bières. 197 nameaddrfavBeer JanewayVoyagerWickedAle SpockEnterpriseBud beersLikedmanf BudA.B. WickedAlePete's namebeersLiked JaneWayBud JaneWayWickedAle SpockBud Drinkers1 Drinkers4 Drinkers3

Problème de la décomposition en BCNF Certaines configurations de DF posent problème lorsque l'on essaye de décomposer un schéma en BCNF Exemple: AB ->C et C ->B avec A = street, B = city, et C = zip Il y a deux clés, {A,B } et {A,C } C ->B contredit BCNF, il faudrait décomposer en {A,C} et {B,C} Problème: si nous utilisons ces schémas, nous ne retrouvons plus la DF AB ->C à partir des DF projetées 198

Exemple de DF non préservée faire une jointure sur le code postal Bien qu'aucune DF ne soit violée dans chacune des relations décomposées, la DF street city -> zip est violée dans la base de données dans son ensemble 199 street zip 545 Tech Sq.02138 545 Tech Sq.02139 city zip Cambridge02138 Cambridge02139 street city zip 545 Tech Sq.Cambridge02138 545 Tech Sq.Cambridge02139

La 3NF évite le problème de non préservation des DF 3 e Forme Normale (3NF) assouplit la condition de BCNF pour garantir une décomposition préservant les DF Un attribut est dit premier s’il fait partie d’une clé minimale. Une relation n’est pas en 3NF ssi on peut trouver une DF X ->A telle que X n’est pas une clé et A n'est pas premier (ne fait pas partie d’une clé minimale) Exemple : Dans l'exemple précédent avec la relation ayant pour schéma {A,B,C} et les DF {AB ->C, C ->B} Les clés minimales sont AB et AC Chaque attribut A, B, ou C est premier Bien que C ->B contredise BCNF, ce schéma est en 3NF 200

Couverture minimale des DF Besoin de calculer une couverture minimale des DF pour décomposer en 3NF Toutes DF a un seul attribut à droite Aucune DF ne peut être retirée –si on en retire une, la fermeture de la couverture minimale n'est plus égale à celle de l'ensemble de DF de départ Aucun attribut ne peut être enlevé –sans changer le résultat de la fermeture  Plus petit ensemble de DF équivalent  leurs fermetures sont égales Méthode: 1.Décomposer chaque DF pour avoir un seul attribut à droite 2.Supprimer les attributs en surnombre à gauche 3.Supprimer les DF redondantes 201

Exemple de couverture minimale des DF Soit F={A->B, ABCD->E, EF->G, EF->H, ACDF->EG} Décomposition des DF pour avoir un seul attribut à droite ACDF->EG devient ACDF->E et ACDF->G  F={A->B, ABCD->E, EF->G, EF->H, ACDF->E,ACDF->G} Suppression des attributs en surnombre à gauche (tester chaque attribut de chaque DF) ABCD->E peut être remplacé par ACD->E car ABCD + =ACD + (grâce à A->B)  F={A->B, ACD->E, EF->G, EF->H, ACDF->E,ACDF->G} Suppression les DF redondantes ACDF->G peut être supprimé car cette dépendance est impliquée par ACD->E et EF->G idem pour ACDF->E  F={A->B, ACD->E, EF->G, EF->H} 202

Construction d'une décomposition 3NF Soit une relation R et un ensemble F de DF Calculer une couverture minimale de F Pour chaque DF X->A dans cette couverture minimale, créer une relation ayant pour schéma {X,A} Si la clé (minimale) n'est pas contenue dans aucune DF, alors ajouter une relation avec pour schéma la clé Exemple : Soit la relation R avec pour schéma {A,B,C}, pour ensemble de DF F={A->B, C->B}, et pour clé minimale {A,C} La couverture minimale est {A->B, C->B} Création de deux relations à partir des DF: R 1 ={A,B} et R 2 ={C,B} Création d'une relation à partir de la clé de R: R 3 ={A,C} 203

Propriétés importantes pour les décompositions Préservation des dépendances fonctionnelles On peut vérifier dans les relations projetées que les dépendances originales sont préservées. Contre-exemple: décomposition BCNF de street-city-zip où street city -> zip n'est plus forcément vérifié Décomposition Sans Perte d’Information (SPI) On peut projeter la relation de départ sur chacune des composantes et reconstruire la relation de départ. une décomposition BCNF vérifie SPI Exemple: décomposition de Drinkers en Drinkers1, Drinkers3 et Drinkers4 204

Comment tester une décomposition préservant les DF ? Soit un ensemble F de DF connues et une décomposition de la relation R en R 1, R 2, … R k Calculer la fermeture F + de l'ensemble des DF Projeter cet ensemble de DF sur les relations issues de la décomposition Pour chaque relation R i, conserver uniquement les DF composées des attributs de R i On obtient donc k ensembles de DF: F R1, F R2,… F Rk Rappel: méthode utilisée pour la décomposition en BCNF Faire l'union des DF projetées sur R 1, R 2, … R k et vérifier que le résultat est bien égale à F + Autrement dit, (F R1 U F R2 U… U F Rk ) + =F + 205

Comment tester une décomposition SPI ? Soit une décomposition de la relation R en R 1, R 2, … R k Si on projette les données de R dans R 1, R 2, … R k, peut-on retrouver R en faisant une jointure ? Tout tuple de R peut être retrouvé à partir de ses fragments projetés Donc la seule question est: quand nous faisons la jointure, a-t-on des tuples supplémentaires qui n'existaient pas initialement ? 206 NameProjectBranch BrownMarsL.A. GreenVenusMiami HoskinsSaturnMiami Décomposition NameBranch BrownL.A GreenMiami HoskinsMiami ProjectBranch MarsL.A. VenusMiami SaturnMiami NameProjectBranch BrownMarsL.A. GreenVenusMiami HoskinsSaturnMiami GreenSaturnMiami HoskinsVenusMiami r π Name,Branch (r) π Project,Branch (r) π Name,Branch (r) π Project,Branch (r) Jointure

Le test de Chase Supposons qu'un tuple t = abc… soit construit par la jointure des relations R i issues de la décomposition Créer un tableau représentant le résultat de la jointure des relations décomposées Pour chaque relation décomposée R i, créer un tuple dans ce tableau tel qu'il a les valeurs a,b,c… pour les attributs de R i a i,b i,c i … pour les autres attributs Exemple: –soit R={A,B,C,D} décomposé en trois relations R 1 ={A,B}, R 2 ={B,C} et R 3 ={C,D} 207 ABCD abc1c1 d1d1 a2a2 bcd2d2 a3a3 b3b3 cd

Le test de Chase (suite) Appliquer l'ensemble des DF connues afin de déduire des égalités dans les données Si deux tuples ont les mêmes valeurs pour une partie gauche de DF, faites que leurs valeurs pour les attributs de la partie droite correspondent aussi Remplacer par les valeurs du tuples t=abc… Exemple (suite) –F={C->D, B->A} donc Si une ligne correspondant au tuple t=abc… apparaît, décomposition SPI Sinon, perte d'informations Exemple (fin):  décomposition SPI 208 ABCD abc1c1 d1d1 a a 2 bcd d 2 a3a3 b3b3 cd car B->A car C->D

Exemple de décomposition avec perte d'informations Soit R={A,B,C,D} décomposé en trois relations R 1 ={A,B}, R 2 ={B,C} et R 3 ={C,D F={C->D} Construction du tableau Application des DF C->D  Décomposition avec perte d'informations car on ne retrouve pas le tuple abc 209 ABCD abc1c1 d1d1 a2a2 bcd2d2 a3a3 b3b3 cd ABCD abc1c1 d1d1 a2a2 bcd a3a3 b3b3 cd

Propriétés des décompositions 3NF et BCNF 210 BCNF3NF Décomposition Sans Perte d’Information oui Préservation des dépendances fonctionnelles Pas forcément (ex: street-city-zip) oui

Université de la Nouvelle-Calédonie Frédéric Flouvat Fondements des Bases de Données.

Présentations similaires

Présentation au sujet: "Université de la Nouvelle-Calédonie Frédéric Flouvat Fondements des Bases de Données."— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Université de la Nouvelle-Calédonie Frédéric Flouvat Fondements des Bases de Données.

Présentations similaires

Présentation au sujet: "Université de la Nouvelle-Calédonie Frédéric Flouvat Fondements des Bases de Données."— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back