Cette séquence termine la série sur la présentation du langage de requêtes SQL.

Transcription

1 Cette séquence termine la série sur la présentation du langage de requêtes SQL. Le modèle relationnel est fondé sur la logique des prédicats du premier ordre, dont il a «hérité» un langage de requête formel, appelé calcul relationnel. L objectif de ce cours n est pas de rentrer dans le détail des bases formelles du modèle relationnel. Nous souhaitons juste ici illustrer quelques ressemblances et différences entre le calcul relationnel et SQL, qui sont importantes pour comprendre certaines complexités du langage SQL, en particulier en ce qui concerne les requêtes comportant des négations. Dans cette séquence, nous utilisons la syntaxe originelle de SQL, dans laquelle la clause FROM ne contient qu une liste de relations et où les condition s de jointure sont placées dans la clause WHERE. Cette notation facilite l interprétation logique des requêtes alors que la notation récente est plus proche du langage opérationnel interne des bases de données (l algèbre relationnelle, voir cours intitulé «SGBD relationnels et performances») 1

2 Intuitivement, la logique du premier ordre consiste à ajouter des variables à la logique des propositions, ce qui revient à ajouter en plus des quantificateurs pour ces variables (quel que soit, il existe). On garde les connecteurs logiques (et, ou, non) et leur tables de vérité. Une relation peut donc être vue comme un prédicat et les attributs comme des variables. Le prédicat est vrai quand les valeurs prises par les attributs correspondent à un tuple de la relation. On peut, à partir de la logique, créer un langage logique dans lequel on peut décrire ce que l on cherche. Dans l exemple, on cherche les noms des viticulteurs et les crus qu ils produisent. Cela revient à rechercher les couples (nom, cru) tels qu une certaine condition est vérifiée. On a une interprétation logique des requêtes. La même interprétation peut être faite sur la requête SQL équivalente : Select nom, cru from personne pe, production pr, vin v where v.nv=pr.nv and pe.id=pr.np Tout comme SQL, le calcul relationnel de tuple (CRT) est fermé, ce qui signifie que le résultat d une requête CRT (respectivement SQL) est un prédicat (respectivement une relation). 2

3 Prenons une requête SQL simple (sans imbrication) Le transparent présente de manière schématique sa traduction en calcul relationnel : on recherche de l ensemble des tuples ayant pour attributs A1..An, tels qu il existe des tuples r1 de R1 rm de Rm, tels que les conditions sont vérifiées et que les attributs des tuples solutions sont issus des tuples des relations R. Exemple : Select np From prod, vins Where prod.nv = vins.nv and cru= Muscadet {t: (np) / pr production, v Vins, (and (t(np) = pr(pr) ) and pr(nv) = v(nv) and v(cru) = Muscadet } On remarque qu une requête SQL sans imbrication de requêtes est équivalente à une requête CRT avec uniquement des quantificateurs existentiels. Que se passe-t-il quand la requête CRT possède des quantificateurs universels? 3

4 Reprenons l exemple de la requête des producteurs qui ne produisent pas de «Côtes de Nuit» Cette requête, exprimée en CRT, revient à introduire un quatificateur universel : Il s agit de l ensemble des tuples ayant np pour attribut, tels que : quelque soit le tuple de Production, et quelque soit le tuple de Vins, Si le producteur résultat est le producteur qui a produit le vin, alors le vin d est pas du CdN. Compte tenu que SQL n exprime que des quantificateurs existenciels, il faut réintroduire les quantificateurs existenciels selon la formule donnée en début de transparent. Traduction de la requête CRT avec. Tout vient de la définition de l implication logique : (si p, alors q) === (p q) === (non p ou q). (non (p q)) == (non (non p ou q)) == (p et non q). Une fois la requête CRT modifiée pour faire réapparaitre les quantificateurs existenciels, on peut retrouver la requête SQL équivalente. Pour chaque tuple de la table production, on recherche s il existe au moins un tuple dans production dont le producteur est le même et dont le vin produit est celui recherché (ici Côte de Nuit). Ensuite, on peut simplifier la requête car la relation production pr peut ne pas être utilisée. 4

5 Commentaires : On voit ici 2 manières différentes d exprimer la requête. Une avec l opérateur not in et l autre avec le prédicat not exists. Pour requêtes simples : une syntaxe mais 2 lectures possibles : procédurale et logique. Pour requêtes compliquées (négation, même s il s agit de la négation du il existe (tous les vins!), il y a deux syntaxes possibles : issue du CRT (il existe), issue d un équivalent procédural (algèbre relationnelle), avec not in. La requête avec not in est généralement plus simple : la sous-requête n est exécutée qu une seule fois, elle est indépendante de la requête principale. Alors qu avec le prédicat not exists, la sous-requête est évaluée pour chaque tuple de la 1 ère requête. 5

6 Exemple plus complexe! Il s agit de l ensemble des tuples ayant np pour attribut, tels que : quelque soit le vin choisi, il existe un producteur qui produit le vin et qui est donc solution. Il existe une requête équivalente (et même au moins 2) issue de l algèbre relationnelle avec l opérateur not in. Mais elle est compliquée. Elle sera vue en TD). Requête équivalente avec not in : select p.np from production p where p.np not in ( select p1.np from production p1, vins v1 where p1.np not in ( select np from production p2 where p2.nv = v1.nv)); 6

7 Comme on le voit, SQL n a pas les mêmes qualités que le calcul relationnel. En particulier, il perd son caractère déclaratif pour des requêtes complexes (avec quantificateur universel). Mais une autre limite existe : SQL ne permet pas d exprimer des requêtes déductives. Il faut penser à des extensions de type langage de programmation pour le faire. Sera vu dans le TP sur PL-SQL et JDBC. 7