Utilisation de PlugDB - smis

1
Utilisation de PlugDB
I Introduction
Les tokens sécurisés SMIS embarquent une base de données relationnelle et jouent le rôle de
serveur.
Le client envoie via USB des requêtes SQL au token, qui ont été préalablement transformées en
QEP (Query Execution Plan) par le programme QGen. Les QEP consistent en un codage de la
requête qui sera compréhensible par le SGBD.
Cette transformation est nécessaire afin que le client fasse un pré-traitement sur les requêtes
pour minimiser les calculs côté serveur, du fait de sa faible puissance de calcul et de sa mémoire
limitée.
Une fois obtenus les QEP, qui sont donc des requêtes SQL pré-traitées, le client peut les envoyer
au token via l’API JDBC et récupérer les résultats.
Ce tutoriel explique comment utiliser le programme QGen et comment intégrer les résultats
produits dans un programme client en Java qui communiquera avec le token en s’interfaçant
avec JDBC.
La partie II explique comment utiliser le programme QGen et comment construire un schéma et
un fichier de requête.
Enfin la troisième partie sert de guide pour la création d’un projet utilisant JDBC et exploitant les
résultats de QGen.
Fichiers nécessaires
o Projet JDBCng Dans le cas ou vous utilisez le token, sinon le projet JDBC si vous vous
servez du simulateur, il vous faut aussi dans ce cas le projet SGBD.
o Projet PlugDBcomm Projet qui communiquera plus tard avec le SGBD
o stsw-stm32102.zip Contient le fichier 'VCP_V1.4.0_Setup.exe'(Driver du token)
o QGen

2
Pré-requis de l’ordinateur
o Windows (XP, 7, 8) ou bien Linux (Debian, Ubuntu, …) ;
o Eclipse ;
o JDK.
Mais avant de commencer, je dois vous notifier que vous pouvez suivre ce tutoriel en utilisant
soit le token, soit son simulateur et ce, sur Windows ou sur Linux !
II Utilisation de QGen
Cette partie explique le fonctionnement de QGen ainsi que la création des schémas SQL et des
fichiers de requêtes.
1 Exécution
 Sur Linux
Le programme s’exécute en ligne de commande comme ceci :
./QGen<schema.sql><queries.sql><QEP.java>
 schema.sql : IN
 queries.sql : IN
 QEP.java : OUT
 Sur Windows
Pour Windows, il faut aussi taper une commande:
QGen.exe <schema.sql><queries.sql><QEP.java>
 schema.sql : IN
 queries.sql : IN
 QEP.java : OUT
2 Schéma
Le schema.sql correspond au schéma de la base de données. On peut y créer 3 types d'objet :
o Des tables.
o Des SKT, pour Subtree Key Table, qui sont des index de jointure.
o Des CI, pour Climbing Index, qui sont des index de sélection.
Pour fonctionner sur les tokens, les schémas doivent être structurés en arbre, c'est à dire avec
une arborescence comme celle-ci :
Concrètement, cela signifie que la table T1 possède 2 clés étrangères qui référencent les tables
T11 et T12 et que la table T0 référence les tables T1 et T2.

3
a. Tables
La syntaxe d’une création de table est la suivante :
CREATE TABLE TableName
(
IdGlobal numeric PRIMARY KEY,
Attribut1 char(50),
Attribut2 numeric
)
/
Seuls 3 types d'attributs sont pour l'instant supportés : numeric, char et date.
Attention à ne pas oublier le '/' à la fin de la requête.
Attention, toutes les clés primaires doivent s'appeler ‘IdGlobal’.
Pour créer une clé étrangère, on utilise la syntaxe suivante :
ForeignKey numeric REFERENCES TableRefName(IdGlobal)
ForeignKeycorrespond au nom de la clé étrangère, TableRefName correspond au nom de la table
référencée (et pas au nom de la table que l’on crée), et IdGlobal correspond au nom de la clé
primaire de la table référencée.
b. Index SKT
La déclaration des SKT est obligatoire. Ce sont des index de jointures qui permettent d’exécuter
sur le token des requêtes avec des jointures ‘lourdes’ malgré la faible quantité de RAM
disponible. Chaque table qui référence une ou plusieurs clés étrangères doit avoir sa SKT
correspondante.
La syntaxe est celle-ci :
CREATE SKT TableName
(
TableRefName (IdGlobal)
)
/
À noter qu'une SKT référence les clés étrangères de sa table, mais également les clés étrangères
des tables filles.
En reprenant le schéma vu précédemment, la SKT d’une table T0 qui référence les tables T2 et T1,
cette dernière référençant les tables T11 et T12, sera déclarée comme ceci :
CREATE SKT T0
(
T1 (IdGlobal),
T2 (IdGlobal),
T11 (IdGlobal),
T12 (IdGlobal)
)
/
Attention, le nom de la SKT doit correspondre au nom de la table correspondante.
c. Index CI
La déclaration des CI est facultative. Cela correspond à des index de sélection, qui permettent
d’accélérer les traitements sur des attributs souvent utilisés. Chaque clé primaire aura un CI créé
automatiquement sur elle-même. La déclaration d'autres CI est au libre choix du concepteur du
schéma.
La syntaxe est la suivante :
CREATE INDEX CIName ON
TableName (AttributeName)
/
Attention, il n’y a pas de parenthèses pour la déclaration d’un CI.

4
d. Tables Update et Delete ( obligatoires )
Ces tables servent à faire des requêtes de type UPDATE et DELETE, même s’il n’est pas prévu
d'en exécuter. Vous devez inclure ces tables, le SGBD en a besoin pour ses routines de rollback.
La position de leur déclaration dans le schéma n’a en revanche pas d’importance.
CREATE TABLE LogDeleted
(
TabId numeric,
TuplePos numeric,
Flag numeric
)
/
CREATE TABLE UpdateLog
(
TabId numeric,
TuplePos numeric,
TupleSize numeric,
CompleteTup char(498)
)
/
e. Table QEP ( Obligatoire )
La création de cette table est aussi obligatoire. Elle contiendra essentiellement les QEP stockés
dans le token ( attribut QEPStr ).
CREATE TABLE QEP
(
IdGlobal numeric PRIMARY KEY,
QEPStr char(458),
SQLStr Blob,
ExplainStr Blob
)
/
3 Requêtes
Le fichier queries.sql correspond aux requêtes dont on a besoin et qui seront traitées par QGen.
Exemples de requêtes :
-- /* Exemple d’insertion */
--public static String EP_T0_INSERT =
INSERT INTO T0 VALUES ( ?, ?, ?, ? )
/
-- /* Exemple de mise à jour */
--public static String EP_T0_UPDATE
UPDATE T0 SET Attribute1 = ? WHERE IdGlobal = ?
/
-- /* Exemple de suppression */
--public static String EP_T0_DELETE
DELETE FROM T0 WHERE IdGlobal = ?
/
-- /* Exemple de selection simple */
--public static String EP_T0_SELECT_BY_ID =
SELECT Attribute1 FROM T0 WHERE IdGlobal = ?
/

5
-- /* Exemple de jointure */
--public static String EP_T0_SELECT_BY_T1 =
SELECT t0.Attribute1, t1.Attribute1
FROM T0 t0, T1 t1
WHERE t0.ForeignKeyT1 = t1.IdGlobal AND t1.Attribute2 = ?
/
Un point important est l'utilisation du symbole '?', qui correspond à une valeur d'attribut non
encore déterminée.
En effet, contrairement à l'utilisation classique client/serveur des SGBD, où l'on spécifie
directement la valeur voulue des attributs dans la clause 'WHERE', on crée ici des requêtes qui
peuvent être vues comme des fonctions prenant en paramètre la valeur des attributs.
L’intérêt est de disposer des plans d’exécution des requêtes spécifiées dans le fichier queries.sql,
et de pouvoir les exécuter plusieurs fois avec des valeurs d’attributs variables, sans avoir besoin
de créer un nouveau plan d’exécution { chaque fois que la valeur change.
Néanmoins, si on le souhaite, on peut spécifier directement la ou les valeurs d'attribut(s) dans la
requête. Cela implique que cette requête sera statique et ne pourra prendre d'autres valeurs
dans la clause WHERE.
Par exemple :
-- /* Exemple de selection statique */
--public static String EP_T0_SELECT_BY_STRING =
SELECT * FROM T0 WHERE Attribute1 = 'Something'
/
Le texte présent après les ‘--‘ est considéré comme un commentaire par QGen, et écrit tel quel
dans le fichier de sortie.
Chaque requête est précédée par la déclaration d’une String statique en Java, par exemple:
--public static String EP_T0_SELECT_BY_STRING =
Le QEP produit sera considéré comme une chaine de caractère dans le fichier Java généré, et
sera appelé plus tard par le programme utilisant JDBC pour exécuter la requête.
4 Résultat produit
Le résultat généré par QGen est une classe Java qui sera utilisée par l’application cliente.
La classe est constituée d'une String statique META, qui correspond au codage du schema.sql,
ainsi que des requêtes transformées en QEP.
Chaque QEP correspond à une String statique dans la classe.
5 Erreurs à l’exécution
Une exécution qui s'est bien déroulée affichera 'DONE' { la dernière ligne de l’output dans la
console.
Autrement, le programme plantera et affichera une ou plusieurs erreurs, qui indiqueront la
plupart du temps où se situe l’erreur.
Néanmoins, si cela ne suffit pas, la façon la plus simple pour savoir où a planté le programme est
d'afficher QEP.java et voir où l’exécution s’est arrêtée :
o Si QEP.java est vide : l'erreur est probablement au niveau du schéma : vérifiez la syntaxe
de la création des tables et des SKT. Vérifiez également que les fichiers passés en
paramètres sont les bons.
o Si QEP.java s'est arrêté au niveau d'un QEP : la requête est probablement mal déclarée.
Vérifier la syntaxe et la cohérence de la requête. Des optimisations dans QGen font
qu'une requête syntaxiquement correcte mais sémantiquement incohérente plantera
probablement.