1 Les dépendances entre les données et les moyens de les vérifier Y Kermarrec (à partir des transparents de J Ullman et de son livre)

2 Les dépendances fonctionnelles uX -> A est une assertion sur une relation R : lorsque deux n-uplets ont les même valeurs dattributs sur X alors ils doivent avoir les même valeurs sur les attributs A uX -> A : X détermine A

3 Exemple uDrinkers(name, addr, beersLiked, manf, favBeer). uDF évidentes : 1.name -> addr 2.name -> favBeer 3.beersLiked -> manf

4 Exemple nameaddr beersLiked manffavBeer JanewayVoyager Bud A.B.WickedAle JanewayVoyager WickedAle PetesWickedAle SpockEnterprise Bud A.B.Bud Car name -> addr car name -> favBeer Car beersLiked -> manf

5 Clés des Relations uK est une clé de la relation R si: 1.Lensemble K détermine tous les attributs de R 2.Pour aucun sous ensemble de K, (1) est vrai wSi K vérifie (1), et pas (2), on dira que K est une super-clé

6 Comment trouver les DFs ? uAnalyser le problème et produire un cahier des charges précis uMettre en évidence les liens entre les données uReformuler le tout au client …

7 Comment trouver les clés ? 1.Au hasard ou en relisant le cahier des charges, en essayant de trouver une super clé puis une clé 1.Ex : deux cours ne peuvent pas avoir lieu dans la même salle en même temps 2.Salle heure -> cours 2.Détermination des clés à partir des DF

8 Fermeture des DF uFermeture de Y notée Y + uPoint de départ : Y + = Y uitération: trouver une DF dont la partie gauche est un sous-ensemble de Y +. Si cette DF est X -> A, rajouter A à Y +.

9 Y+Y+ new Y + XA

10 A quoi ça sert ? uVérifier que K est une clé uUtile pour la normalisation cad la décomposition de relations uExemple: ABCD avec comme DF AB ->C, C ->D, et D ->A. wDécomposer R en ABC, AD. Quelles sont les DFs sur ABC wAB ->C, mais aussi C ->A !

11 Anomalies uLa conception dun schéma relationnel doit éviter les anomalies wAnomalie de mise à jour : une occurrence dune donnée est mise à jour mais pas toutes wAnomalie de destruction : une information est perdue lorsque le n-uplet est enlevé

12 Exemple de mauvaise conception Drinkers(name, addr, beersLiked, manf, favBeer) nameaddrbeersLikedmanffavBeer JanewayVoyagerBudA.B.WickedAle Janeway???WickedAlePetes??? SpockEnterpriseBud???Bud Les données sont redondantes car les ??? Peuvent être déduits À partir des DFs name -> addr favBeer et beersLiked -> manf.

13 Dautres anomalies nameaddrbeersLikedmanffavBeer JanewayVoyagerBudA.B.WickedAle JanewayVoyagerWickedAlePetesWickedAle SpockEnterpriseBudA.B.Bud anomalie de mise à jour anomalie de destruction

14 Décomposition uLes 2 extrêmes : wUne seule relation avec tous les attributs (aussi appelée relation universelle) wAutant de relations que dattributs (un attribut par relation) uAvantages et inconvénients ?

15 Lidéal uNe pas perdre de données uNe pas perdre de DFs uNe pas générer de nouvelles informations lors de jointures (afin de reconstituer la relation universelle)

16 Boyce-Codd Normal Form uUne relation R est en BCNF si pour toute DF X ->A (non-triviale) X est une super-clé. wNon trivial A nest pas un sous ensemble de X

17 Exemple uDrinkers(name, addr, beersLiked, manf, favBeer) uDFs: name->addr favBeer, beersLiked->manf uSeule clé {name, beersLiked}. uPour chaque DF, la partie gauche nest pas une super clé uDrinkers nest pas en BCNF

18 Exemple uBeers(name, manf, manfAddr) uDF: name->manf, manf->manfAddr uClé : {name}. uname->manf respecte la règle BCNF, mais pas manf->manfAddr

19 Décomposition en BCNF uSoit R avec F lensemble des DFs uTrouver une DF qui ne respecte pas la règle BCNF, soit X ->B. ucalculer X + wNe doit pas générer tous les attributs car sinon X est une super clé.

20 Décomposer R avec X -> B -Remplacer R par : -R 1 = X +. -R 2 = (R – X + ) U X. -Projeter les DFs de R sur les 2 nouvelles relations R1 et R2 -Calculer la fermeture de F = toutes les DFs -Ne garder les DFs que celles dont tous les attributs sont dans R 1 ou dans R 2.

21 Principe de décomposition R-X +R-X + XX +-XX +-X R2R2 R1R1 R

22 Exemple uDrinkers(name, addr, beersLiked, manf, favBeer) uF = name->addr, name -> favBeer, beersLiked->manf uDrinkers nest pas BCNF car name->addr. uCalcul de la fermeture {name} + = {name, addr, favBeer}. uDécomposer en 2 relations: 1.Drinkers1(name, addr, favBeer) 2.Drinkers2(name, beersLiked, manf)

23 Exemple uDrinkers1 et Drinkers2 sont elles BCNF? uProjeter les DFs est compliqué mais simple dans cet exemple. uPour Drinkers1(name, addr, favBeer), les DFs sont name->addr et name->favBeer wDonc name est la seule clé et la relation est BNCF.

24 Exemple uPour Drinkers2(name, beersLiked, manf), la seule DF beersLiked->manf et la seule clé est {name, beersLiked}. wViolation de la règle BCNF. ubeersLiked + = {beersLiked, manf}, on décompose Drikers2 en 1.Drinkers3(beersLiked, manf) 2.Drinkers4(name, beersLiked)

25 Exemple uLe résultat de la décomposition de Drinkers: 1.Drinkers1(name, addr, favBeer) 2.Drinkers3(beersLiked, manf) 3.Drinkers4(name, beersLiked) wA noter Drinkers1 nous parle des buveurs, Drinkers3 nous parle de bières, et Drinkers4 nous parle des relations entre bière et buveurs.

26 Contraintes et Triggers uUne contrainte est une relation entre les données que le SGBD doit vérifier wExemple: contraintes de clés. uTriggers : ce sont des actions qui sont déclenchées sur événement

27 Les contraintes uLes clés uLes clés étrangères. uLes contraintes de domaine wContraindre le domaine dun attribut donné uDes contraintes sur des tuples uAssertion : une expression booléenne SQL

28 Les clés étrangères uSoit la relation Sells(bar, beer, price). uOn peut sattendre à ce que la valeur de lattribut beer apparaisse dans la relation Beers.Name uUne contrainte qui impose quune bière dans Sells soit une bière dans Beers est appelée contrainte de clé étrangère

29 Clé étrangère uUtiliser le mot clé REFERENCES soit : 1.Lors de la déclaration de lattribut (sil est seul) 2.En tant quélément du schéma FOREIGN KEY ( ) REFERENCES ( ) uLes attributs ainsi référencés doivent être déclarés PRIMARY KEY ou UNIQUE.

30 Exemple CREATE TABLE Beers ( nameCHAR(20) PRIMARY KEY, manfCHAR(20) ); CREATE TABLE Sells ( barCHAR(20), beerCHAR(20) REFERENCES Beers(name), priceREAL );

31 Exemple (autre formulation) CREATE TABLE Beers ( nameCHAR(20) PRIMARY KEY, manfCHAR(20) ); CREATE TABLE Sells ( barCHAR(20), beerCHAR(20), priceREAL, FOREIGN KEY(beer) REFERENCES Beers(name));

32 Vérifier une clé étrangère uSil y a une clé étrangère sur des attributs de R vers une clé primaire de la relation S, 2 cas de violations sont possibles: 1.Une insertion ou mise à jour de R introduit une valeur absente dans S. 2.Une destruction ou mise à jour de S qui provoque des références fantômes (« dangling reference »)

33 Action -- 1 uSuppose R = Sells, S = Beers uUne insertion ou mise à jour de Sells qui introduit une bière non existante doit être rejetée uUne destruction ou mise à jour de Beers qui enlève une valeur de bière présente dans un n-uplet de Sells peut être traité de 3 manières

34 Action -- 2 uLes 3 manières de réagir à la disparition de bières sont : 1.Default : rejeter la modification 2.Cascade : réaliser les mêmes modifications dans Sells wDeleted beer : destruction des tuples de Sells wUpdated beer: modifier les valeurs dans Sells. 3.Set NULL : mettre bière à NULL

35 Exemple: Cascade uOn retire Bud de la liste des bières wOn enlève tous les n-uplest de Sells qui ont Bud comme valeur dattribut pour bière uOn modifie Bud en Budweiser. wOn modifie tous les tuples de Sells avec beer = Bud par beer = Budweiser.

36 Exemple: Set NULL uOn enlève BUD de Beers wModifie tous les n-uplets avec beer = Bud et remplacer cet attribut par beer = NULL. uOn modifie le tuple en changeant de nom Bud vers Budweiser. wMême modification que précédemment

37 Choix dune politique uLorsquon déclare une clé étrangère, il faut aussi préciser la politique SET NULL ou CASCADE pour les destructions ET les mises à jour uLa précision est donnée lors de la déclaration de la clé étrangère: ON [UPDATE, DELETE][SET NULL CASCADE] uLaction par défaut est de rejeter

38 Exemple CREATE TABLE Sells ( barCHAR(20), beerCHAR(20), priceREAL, FOREIGN KEY(beer) REFERENCES Beers(name) ON DELETE SET NULL ON UPDATE CASCADE );

39 Vérification sur attributs uDonner une contrainte sur le domaine de valeur dun attribut uCHECK( ) : à utiliser lors de la définition de lattribut uLa condition peut référencer lattribut en direct mais aussi nimporte quelle autre requête (relation et attribut).

40 Exemple CREATE TABLE Sells ( barCHAR(20), beerCHAR(20)CHECK ( beer IN (SELECT name FROM Beers)), priceREAL CHECK ( price <= 5.00 ) );

41 Les vérifications uLa vérification est réalisée uniquement sur ajout ou mise à jour du n-uplet. wExemple: CHECK (price <= 5.00) wExemple: CHECK (beer IN (SELECT name FROM Beers))

42 Tuple-Based Checks uCHECK ( ) peut faire partie de la déclaration du schéma de relation uLa condition peut référencer nimporte quel attribut de la relation (ou dune autre avec une requête) uVérification sur insertion et mise à jour uniquement

43 Exemple: Tuple-Based Check useul Joes Bar peut vendre des bières à plus de $5: CREATE TABLE Sells ( barCHAR(20), beerCHAR(20), priceREAL, CHECK (bar = Joes Bar OR price <= 5.00) );

44 Assertions uUn élément dune schéma dune base de données uDéfinies par : CREATE ASSERTION CHECK ( ); uLa condition peut faire intervenir nimporte quelle relation ou attribut de la base

45 Exemple: Assertion upour Sells(bar, beer, price), aucun bar ne doit faire payer plus de $5 en moyenne CREATE ASSERTION NoRipoffBars CHECK ( NOT EXISTS ( SELECT bar FROM Sells GROUP BY bar HAVING 5.00 < AVG(price) )); Bars avec un Prix moyen De 5 USD

46 Exemple: Assertion uIl ne peut pas y avoir plus de bars que de buveurs CREATE ASSERTION FewBar CHECK ( (SELECT COUNT(*) FROM Bars) <= (SELECT COUNT(*) FROM Drinkers) );

47 Triggers uLes contraintes sur attributs ou tuples sont parfois limitées uLes assertions sont puissantes mais difficiles à mettre en oeuvre par les SGBD wIl faut ne faire que les vérifications nécessaires

48 Triggers uUn trigger permet à l(utilisateur de décider quand faire une action donnée uComme une assertion, un trigger peut spécifier une condition générale et surtout exécuter nimporte quelle action sur la base

49 Des règles uUne règle : un événement + une condition + action uévénement: classiquement une modification de la base, e.g., insert on Sells. uCondition : une expression SQL uAction : une suite dinstructions SQL

50 Exemple dun 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); Lévénement la condition Laction