Crer les Applications de BDs : SQL Imbriqu

1
Créer les Applications de BDs SQL Imbriqué

• Witold Litwin

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
Exemple de texte source PL1
Texte blanc PL1 Vert jaune SQL

• 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 gt BETA THEN
• GETSTC
• EXEC SQL SELECT STATUS CITY
• INTO RANK, CITY
• FROM S
• WHERE S GIVENS

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 gt BETA THEN
• GETSTC
• EXEC SQL SELECT STATUS CITY
• INTO RANK, CITY
• FROM S
• WHERE S GIVENS

Interface entre le hôte et le SGBD
SQL Communication Area
Variables Hôte
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) lt-gt CITY Char (20)
• Les variables-hôtes peuvent être employées dans
  les clauses de requêtes

6
Communication hôte-SQL

• SQLCA avec SQLCODE
• 0 ordre exécuté OK
• 100 résultat vide (pas de tuples)
• 0 lt SQLCODE ltgt 100 SQL warning
• lt 0 SQL erreur
• Codes warning et erreur ne sont pas normalisés
  entre les dialectes
• ODBC de facto standard ??

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

• Pointeur d'un tuple dans la table temporaire
  définit par une requête SQL imbriquée

Table virtuelle
SQL
curseur
9
Concept de curseur

• Pointeur d'un tuple dans la table temporaire
  définit par une requête SQL imbriquée

SQL
curseur
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
SELECT sans curseur

• le résultat doit être un seul tuple
• EXEC SQL SELECT STATUS, CITYINTO RANK,
  CITYFROM SWHERE S GIVENS
• Si les nuls peuvent être trouvés, alors on peut
  déclarer les variables indicateurs
• EXEC SQL SELECT STATUS, CITYINTO RANKRANKID,
  CITYFROM SWHERE S GIVENS
• IF RANKIND lt 0 THEN traite le nul...

12
UPDATE sans curseur

• EXEC SQL UPDATE SSET STATUS STATUS
  RAISEWHERE CITY 'PARIS'
• S'il n'y a pas de tuple satisfaisant WHERE, alors
  SQLCODE 100

13
DELETE INSERT sans curseur

• EXEC SQL DELETEFROM SPWHERE 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
Opérations sur les curseursExemple

• EXEC SQL DECLARE X CURSOR FORSELECT S, SNAME,
  STATUSFROM SWHERE 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
Opérations sur les curseurs

• EXEC SQL DECLARE curseur CURSORFOR
  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
CURRENT OF curseur

• Spécifie le tuple en cours, pour la navigation
  avec un UPDATE ou un DELETE
• EXEC SQL UPDATE TABLESET STATUS STATUS
  UPGRADE, CITY CITYWHERE CURRENT OF X
• EXEC SQL DELETEFROM SPWHERE CURRENT OF Y

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
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
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
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
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
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
Conclusion

• L'idée conduit au problème de l'impédance mismatch

Modèle de données hôte
Modèle relationnel
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
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

• FIN

27
(No Transcript)