1 Créer les Applications de BDs : SQL Imbriqué Witold Litwin.

Présentation au sujet: "1 Créer les Applications de BDs : SQL Imbriqué Witold Litwin."— Transcription de la présentation:

1 1 Créer les Applications de BDs : SQL Imbriqué Witold Litwin

2 2 Introduction Destiné aux programmeurs d'application Les ordres sont imbriqués parmi les instructions d'un langage de programmation favori: –Cobol, PL1, C... Ces ordres sont ensuite précompilés

3 3 Exemple de texte source PL1 DCL GIVENS# CHAR(5) ; DCL RANK FIXED BIN(15) ; DICL CITY CHAR(15); DCL.... EXEC SQL DECLARE S TABLE ( S# CHAR(5)NOT NULL SNAME CHAR(20), STATUS INT, CITY CHAR(20) ) ; EXEC SQL INCLUDE SQLCA ;............ IF ALPHA > BETA THEN GETSTC EXEC SQL SELECT STATUS CITY INTO :RANK, :CITY FROM S WHERE S# = :GIVENS# ;............. PUT SKIP LIST (RANK, CITY) Texte blanc: PL1 Vert & jaune: SQL

4 4 Exemple de texte source PL1 DCL GIVENS# CHAR(5) ; DCL RANK FIXED BIN(15) ; DICL CITY CHAR(15); DCL.... EXEC SQL DECLARE S TABLE ( S# CHAR(5)NOT NULL SNAME CHAR(20), STATUS INT, CITY CHAR(20) ) ; EXEC SQL INCLUDE SQLCA ;............ IF ALPHA > BETA THEN GETSTC EXEC SQL SELECT STATUS CITY INTO :RANK, :CITY FROM S WHERE S# = :GIVENS# ;............. PUT SKIP LIST (RANK, CITY) SQL Communication Area Variables Hôte Interface entre le hôte et le SGBD

5 5 Communication hôte-SQL Variables -hôtes (de forme :x ) –type doit être compatible avec les attributs SQL correspondants –SGBD, ex. DB2, en général peut fait certaines conversions entre types faibl. compatibles ex.: CITY char (15) : CITY Char (20) Les variables-hôtes peuvent être employées dans les clauses de requêtes

6 6 Communication hôte-SQL SQLCA avec SQLCODE: 0 = ordre exécuté OK 100 = résultat vide (pas de tuples) 0 100 = SQL warning < 0 = SQL erreur Codes warning et erreur ne sont pas normalisés entre les dialectes –ODBC de facto standard ??

7 7 Préparation et exécution d'une application SQL Bind Appl. Plan Modif. source Module Compil. DB Request Module Object Mod. Module source Ed. de liens Mod. de charg. Mod. de charg. Precomp. App. Plan Suprv. d'Exec. Gest. de Données Gest. de Tampons Autres Mémoire centrale BD

8 8 Concept de curseur Pointeur d'un tuple dans la table temporaire définit par une requête SQL imbriquée SQL curseur Table virtuelle

9 9 Concept de curseur Pointeur d'un tuple dans la table temporaire définit par une requête SQL imbriquée SQL curseur

10 10 Curseurs (sémantique) Nécessaires pour les opérations navigationnelles, car non-SQL Plusieurs curseurs peuvent simultanément partager une table (virtuelle). Un curseur n'a pas de valeur connue ; –seul le tuple pointé est mis à la disposition Un curseur ne peut qu'avancer, d'un tuple à la fois Un curseur peut être ouvert, puis fermé, puis reouvert etc.

11 11 SELECT sans curseur le résultat doit être un seul tuple: EXEC SQL SELECT STATUS, CITY INTO :RANK, :CITY FROM S WHERE S# = :GIVENS# ; Si les nuls peuvent être trouvés, alors on peut déclarer les variables indicateurs: EXEC SQL SELECT STATUS, CITY INTO :RANK:RANKID, :CITY FROM S WHERE S# = :GIVENS# ; IF RANKIND < 0 THEN traite le nul...

12 12 UPDATE sans curseur EXEC SQL UPDATE S SET STATUS = STATUS + :RAISE WHERE CITY = 'PARIS' ; S'il n'y a pas de tuple satisfaisant WHERE, alors SQLCODE := 100 ;

13 13 DELETE & INSERT sans curseur EXEC SQL DELETE FROM SP WHERE :CITY = (SELECT CITY FROM S WHERE S.S# = SP.S#) ; Idem pour SQLCODE si la clause WHERE n'est pas satisfaite EXEC SQL INSERT INTO P (P#, PNAME, WEIGHT) VALUES (:PNO, :PNAME, :W) ;

14 14 Opérations sur les curseurs Exemple EXEC SQL DECLARE X CURSOR FOR SELECT S#, SNAME, STATUS FROM S WHERE CITY = :Y ; EXEC SQL OPEN X ; DO pour tous les tuples de S accessibles via X: EXEC SQL FETCH X INTO :S#, :SNAME, :STATUS...... END EXEC SQL CLOSE X ;

15 15 Opérations sur les curseurs EXEC SQL DECLARE curseur CURSOR FOR expression-de-sélection [ FOR UPDATE OF attribut [, attribut ]... | ORDER BY attribut [, attribut ]... ] ; ORDER BY est pour les interrogations seulement EXEC SQL FETCH curseur INTO cible [, cible ].... cible := :variable-hôte [:variable-indicateur ].... Variable-indicateur de FETCH est gérée comme pour le SELECT sans curseur

16 16 CURRENT OF curseur Spécifie le tuple en cours, pour la navigation avec un UPDATE ou un DELETE EXEC SQL UPDATE TABLE SET STATUS = STATUS + :UPGRADE, CITY = :CITY WHERE CURRENT OF X ; EXEC SQL DELETE FROM SP WHERE CURRENT OF Y ;

17 17 CURRENT OF curseur UPDATE CURRENT et DELETE CURRENT ne sont pas permis quand: –SELECT inclue UNION ou ORDER BY –CREATE VIEW avec ce SELECT aurait défini une vue impossible à mettre à jour. Pour UPDATE CURRENT, on doit préalablement déclarer le curseur et les attributs mis à jour.

18 18 SQL Dynamique Un ordre de SQL imbriqué à exécuter peut ne pas à être connu à la compilation Exemples : –un interface convivial à SQL interactif –une application offrant le SQL interactif lui-même, ex. MsAccess SQL dynamique est une solution à ce problème, ajoutée à SQL imbriqué originel –plusieurs SGBDs n'avaient pas de SQL dynamique pendant plusieurs années (INGRES)

19 19 L'idée SQL "statique": –on déclarait au précompilateur un texte d'une requête SQL, SQL dynamique: –on déclare seulement une variable soit V de SQL à l'exécution, run-time, on chargera dynamiquement dans V le texte reçu

20 20 SQL Dynamique: commandes DCL SQLSOURCE CHAR (256) VARYING ; EXEC SQL DECLARE SQLOBJ STATEMENT ; INPUT (SQLSOURCE) ; EXEC SQL PREPARE SQLOBJ FROM :SQLSOURCE ; EXEC SQL EXECUTE SQLOBJ ; La procédure INPUT initialise :SQLSOURCE avec le texte d'une requête SQL, par exemple venant d'un terminal. –ex. 'SELECT * FROM S' SQLSOURCE est une variable PL1, mais SQLOBJ est une variable SQL destinée à recevoir le run-time texte de SQL SQLCODE est initialisé comme d'habitude

21 21 Avantages/désavantages Une flexibilité ou une nécessité pour certaines applications Mais, une possible détérioration de performances d'une requête –peut être importante –c'est pourquoi, on garde le SQL "statique"

22 22 Conclusion SQL imbriqué : un sous-langage relationnel pour imbriquer dans les langages de programmation traditionnels Offre les fonctions non-procedurales et navigationnelles –déclarations de tables –curseurs Offre les interfaces de communication: –variables dans les requêtes –SQLCA

23 23 Conclusion L'idée conduit au problème de l'impédance mismatch Modèle de données hôte Modèle relationnel

24 24 Conséquences négatives Le programmeur d'application doit maîtriser deux modèles de données et la conversion entre eux –en général on ne peut pas écrire une application vite prototyper en quelques heures écrire en quelques jours –perte des avantages non-proceduraux du relationnel Les opérations non-relationnelles souvent nécessite l'extraction navigationnelle de la totalité d'une ou plusieurs tables –performances médiocres voire inacceptables de l'ensemble

25 25 Solutions proposées Langages 4-GL –génération rapide d'applications –bonne convivialité inhérente d'utilisation de SGBD –Très gros succès ! SGBD extensibles (faillite) Interoperabilité (en cours de preuve) OO-SGBDs et relationnel-objet (idem) –LBD est un langage de progr. complet donc pas de mismatch

26 26 FIN

27 27