APIS DE TABLE POUR SQL SERVER

Transcription

1 APIS DE TABLE POUR SQL SERVER TRAVAIL DE BACHELOR D INFORMATICIEN DE GESTION D. PARTIE PRATIQUE Mode de réalisation : Extra-muros Date de création : Dernière modification : Cycle d étude : Date de restitution : Directeur de travail : M. Pierre-André Sunier Julien Ogi

2 Table des matières 1. Introduction SQL Server Les tables Le type TABLE Les triggers Insertion Mise à jour Suppression Les fonctions Audit Les procédures Journalisation Graphe non orienté La vue Les triggers Résultats des tests Graphe non orienté Plugin Les modèles Les paramètres Les paramètres de noms Les paramètres de code dynamique Les paramètres de blocs de code Les types de données Correspondance des types de données MCD et MLD Le type TABLE Les triggers Insertion Mise à jour Suppression Trigger INSTEAD OF de la vue Les fonctions Audit Les procédures Journalisation Les schémas Le bloc d exécution Différencier les SGBDR La classe MPDConstructor Les colonnes d audit JULIEN OGI PAGE 1 SUR 56

3 3.12. La table de journalisation Création du MPD Exécution du plugin Conclusion Annexes Les modèles Les scripts L archive du plugin Tables des illustrations JULIEN OGI PAGE 2 SUR 56

4 1. Introduction Cette partie présente la démarche suivie pour la réalisation du projet. Pour avoir une bonne compréhension du document il est conseillé de d abord lire la partie théorique. Ce document est séparé en deux parties. La première concerne SQL Server, ce fut également la première démarche effectuée. La seconde s intéresse au plugin et à son adaptation ainsi qu à son exécution. À la fin du document une conclusion apporte un ressenti personnel sur le travail ainsi qu une série d améliorations qui aurait pu être apportée au projet. La démarche entreprise pour réaliser ce travail a été de d abord commencer à s intéresser à SQL Server et le Transact-SQL et d effectuer quelques tests. Une fois ces derniers terminés, il a été possible de réaliser les APIs de table «manuellement», toujours qu en SQL afin de simuler ce que le plugin devrait générer et vérifier le bon fonctionnement des APIs. Ensuite seulement, l adaptation du plugin pu être concrétisée en s attaquant en premier lieu à la différenciation des SGBDR puis aux APIs de table. Pour adapter le plugin, la démarche suivie a été d examiner le code écrit pour Oracle et de s en inspirer. Du moins de reprendre la structure des classes existantes. Cela a notamment permis de comprendre le fonctionnement du code pour ces éléments. Concernant la distinction entre les différents SGBDR il n y a pas beaucoup de solutions. Il faut parcourir le code et trouver les endroits dont la séparation est indispensable. Ce travail ne prend pas en compte la transformation itérative et incrémentale 1 donc les classes adaptateurs n ont pas été retouchées. Tout au long de ce document des exemples seront donnés. Ils sont basés sur la table Cours du MLD (voir Figure 1). La partie sur SQL Server représente ce que devrait idéalement créer le plugin. Comme les tests des APIs en SQL ont été réalisés avant, il n était pas possible de savoir quelles restrictions le plugin imposait. À vrai dire il n y en a que deux. Le fait de ne pas pouvoir auditer et journaliser la table associative du graphe non orienté et qu il n est pas possible de préciser le nombre de fractions de secondes qu on veut au type de données DATETIME2. 1 Elle est encore en cours de développement JULIEN OGI PAGE 3 SUR 56

5 2. SQL Server Le MLD/MPD que devrait générer le plugin est le suivant 2 : Figure 1 MLD/MPD 2.1. Les tables La création des tables est des plus classiques, si ce n est la particularité de la clé primaire qui, contrairement à Oracle n a pas besoin de séquence pour être incrémentée. L utilisation du mot-clé IDENTITY suffit à indiquer au système que la valeur doit être incrémentée à chaque nouvelle insertion, ainsi que son pas d incrémentation. Table Cours : CREATE TABLE Cours ( numero INT IDENTITY(1,1) NOT NULL, libelle VARCHAR(50) NOT NULL, CTRLAJUSER VARCHAR(30) NULL, CTRLAJDATE DATETIME2(0) NULL, CTRLMOUSER VARCHAR(30) NULL, CTRLMODATE DATETIME2(0) NULL, CONSTRAINT PK_Cours PRIMARY KEY(Numero) ) GO Le zéro après le type de données DATETIME2 indique la précision des fractions de secondes. Dans notre cas on n en aura pas besoin. Par défaut la valeur vaut 7. 2 Pour plus de détail sur le modèle, voir le document théorique au Chapitre 3. JULIEN OGI PAGE 4 SUR 56

6 2.2. Le type TABLE Pour utiliser les APIs de table il est nécessaire à un moment ou à un autre d utiliser des fonctions et procédures et de leur passer la structure des tables en paramètre. La problématique qui se pose avec SQL Server est qu il est impossible de récupérer les colonnes d une table comme Oracle avec l attribut %ROWTYPE. Pour pouvoir passer les colonnes d une table en paramètre il faut créer son propre type de données ayant la même structure que la table. Pour créer cette structure on utilise l instruction CREATE TYPE. Grâce à ce type de données, il est possible de créer une variable ayant la même structure que nos tables à auditer et journaliser. On va donc pouvoir s en servir pour passer le type TABLE en paramètre des différentes fonctions et procédures nécessaires au fonctionnement des APIs. Type TABLE correspondant à la table Cours : CREATE TYPE typ_cours AS TABLE ( numero INT, libelle VARCHAR(50), CTRLAJUSER VARCHAR(30), CTRLAJDATE DATETIME2(0), CTRLMOUSER VARCHAR(30), CTRLMODATE DATETIME2(0) ) GO 2.3. Les triggers Les triggers permettent de mettre à jour les données d audit et de peupler la table de journalisation en appelant les fonctions et procédures respectives. Étant donné que le trigger BEFORE n existe pas avec SQL Server, l utilisation du trigger AFTER a été retenue. Le trigger INSTEAD OF aurait aussi pu être une possibilité mais le corps de ceux-ci auraient été différents pour chaque instruction d insertion, modification et suppression, sans prendre en compte le fait qu ils sont plus adaptés aux vues. C est pourquoi les triggers AFTER sont de meilleurs candidats et permettent d obtenir une certaine homogénéité. Néanmoins nous verrons apparaître un problème pour l insertion qu un trigger INSTEAD OF aurait pu éviter Insertion Lors d une insertion dans une table, le trigger AFTER INSERT se déclenche et va récupérer, dans la table INSERTED, les données que l on a insérées pour les mettre dans le type TABLE correspondant. Puis appelle la fonction de mise à jour des champs d audit et pour finir la procédure de journalisation. Trigger pour l insertion dans la table Cours : CREATE TRIGGER Crs_TAPIs_AI ON Cours AFTER INSERT AS BEGIN typ_cours; JULIEN OGI PAGE 5 SUR 56

7 -- Récupère les données insérées INSERT ( numero, libelle, CTRLAJUSER, CTRLAJDATE, CTRLMOUSER, CTRLMODATE) SELECT numero libelle, CTRLAJUSER, CTRLAJDATE, CTRLMOUSER, CTRLMODATE FROM INSERTED; -- Mets à jour les valeurs d audit SET CTRLAJUSER = f.ctrlajuser, CTRLAJDATE = f.ctrlajdate FROM Crs_TAPIs.autogen_column_ins(@tab) AS f; UPDATE Cours SET CTRLAJUSER = t.ctrlajuser, CTRLAJDATE = t.ctrlajdate AS t WHERE Cours.numero = t.numero; END GO -- Appelle la procédure de journalisation EXEC 'INS'; L utilisation des alias (f et t) est ici obligatoire pour différencier les noms des colonnes. Si on ne le fait pas, le trigger ne se créera pas et retournera une erreur expliquant que le nom de la colonne est ambigu. On est donc obligé de bien différencier les colonnes. Mais ce trigger pose problème au niveau de la deuxième instruction UPDATE. Le trigger AFTER UPDATE posé sur la table s exécutera, ce qui aura pour incidence de compléter les lignes d audit concernant la mise à jour. Pour éviter ce problème, il est obligatoire de désactiver la récursivité indirecte des triggers dans la base de données grâce au paramètre de serveur nested triggers de la procédure sp_configure. EXEC sp_configure 'nested triggers', 0; GO RECONFIGURE; GO Le deuxième paramètre de la procédure représente l activation ou la désactivation de la récursivité. S il est à 0 cela signifie que la récursivité est désactivée, ce qui est le cas ici. Le mot-clé RECONFIGURE JULIEN OGI PAGE 6 SUR 56

8 permet d activer le changement pour qu il prenne effet. Bien entendu si une personne désire utiliser la récursivité des triggers cela posera problème pour les APIs de table. [MIC-08] Mise à jour Pour la mise à jour, on utilise un trigger AFTER UPDATE. Le code est sensiblement identique au trigger d insertion. Sauf que ce sont les champs d audit concernant la mise à jour qui sont mis à jour. CREATE TRIGGER Crs_TAPIs_AU ON Cours AFTER UPDATE AS BEGIN typ_cours; -- Récupère les données mises à jour -- Ici le code est identique au trigger précédent -- Mets à jour les données d audit SET CTRLMOUSER = f.ctrlmouser, CTRLMODATE = f.ctrlmodate FROM Crs_TAPIs.autogen_column_upd(@tab) AS f; UPDATE Cours SET CTRLMOUSER = t.ctrlmouser, CTRLMODATE = t.ctrlmodate AS t WHERE Cours.Numero = t.numero; END GO -- Appelle la procédure de journalisation EXEC 'UPD'; Lors du second UPDATE, le trigger ne sera donc pas non plus exécuté à nouveau car la récursivité directe est aussi désactivée Suppression Pour la suppression c est un trigger AFTER DELETE qui est déclenché. Il suffit juste d insérer les valeurs de la table DELETED dans le type TABLE et de passer la variable en paramètre de la procédure de journalisation. CREATE TRIGGER Crs_TAPIs_AD ON Cours AFTER DELETE AS BEGIN typ_cours; JULIEN OGI PAGE 7 SUR 56

9 -- Récupère les données supprimées INSERT ( numero, libelle, CTRLAJUSER, CTRLAJDATE, CTRLMOUSER, CTRLMODATE) SELECT numero, libelle, CTRLAJUSER, CTRLAJDATE, CTRLMOUSER, CTRLMODATE FROM DELETED; END GO -- Appelle la procédure de journalisation EXEC 'DEL'; 2.4. Les fonctions Les fonctions permettent d affecter les valeurs d audit aux champs d audit. On y passe en paramètres le type TABLE correspondant à la table en cours de modification. Comme il n est malheureusement pas possible de modifier un type TABLE dans une fonction, il faut créer une structure de retour identique qui retournera les champs d audit mis à jour. La ci-dessous. C est donc une fonction table multi-instructions Audit Dans la fonction ci-dessous les champs d audit pour l insertion sont mis à jour. CREATE FUNCTION Crs_TAPIs.autogen_column_ins(@pi_crtrec typ_cours READONLY) TABLE ( numero INT, libelle VARCHAR(50), CTRLAJUSER VARCHAR(30), CTRLAJDATE DATETIME2(0), CTRLMOUSER VARCHAR(30), CTRLMODATE DATETIME2(0) ) AS BEGIN INSERT ( numero, libelle, CTRLAJUSER, CTRLAJDATE, CTRLMOUSER, JULIEN OGI PAGE 8 SUR 56

10 CTRLMODATE) SELECT numero, libelle, USER, CURRENT_TIMESTAMP, CTRLMOUSER, CTRLMODATE END; GO RETURN; Les fonctions USER et CURRENT_TIMESTAMP permettent d identifier respectivement l utilisateur et la date et l heure actuelle. La fonction appelée lors d une mise à jour est identique, excepté le fait que ce sont les colonnes de modification (CTRLMOUSER et CTRLMODATE) qui sont mises à jour Les procédures Les procédures permettent de journaliser les tables. Elles prennent en paramètres le type TABLE correspondant à la table en cours de modification et l opération en cours (INS, UPD, DEL) Journalisation La procédure ci-dessous journalise la table Cours. CREATE PROCEDURE typ_cours CHAR(3) AS BEGIN INSERT INTO Cours_JN ( JN_OPERATION, JN_USER, JN_DATETIME, JN_NOTES, JN_APPL, JN_SESSION, numero, libelle, CTRLAJUSER, CTRLAJDATE, CTRLMOUSER, CTRLMODATE) USER, CURRENT_TIMESTAMP, NULL, 'Cours_TAPIs', JULIEN OGI PAGE 9 SUR 56

11 END; GO numero, libelle, CTRLAJUSER, CTRLAJDATE, CTRLMOUSER, CTRLMODATE Pour connaître le numéro de session on utilise la variable système 2.6. Graphe non orienté Pour le graphe non orienté, la philosophie est la même concernant l audit et la journalisation. Cependant des éléments supplémentaires doivent être créés : une vue et deux triggers. Le MLD concernant les graphes non orientés est le suivant. On peut voir ici que la table associative Routes contient des colonnes d audit et une table de journalisation ainsi que les triggers, fonctions et procédures respectifs. Ce que le plugin ne fait pas actuellement. Figure 2 MLD/MPD du graphe non orienté Les éléments nouveaux ici sont la vue Rte_INSTEADOFTAPIs et les triggers Rte_TAPIs_NoDML et Rte_TAPIs_IOI. JULIEN OGI PAGE 10 SUR 56

12 La vue D. PARTIE PRATIQUE - APIS DE TABLE POUR SQL SERVER La vue se crée pour matérialiser les routes entre les villes comme vu dans la partie théorique. Le code d une telle vue sera l union de deux requêtes de sélection qui simule la route dans les deux sens. CREATE VIEW Rte_INSTEADOFTAPIs AS SELECT villes_routea_numero, villes_routeb_numero FROM Routes UNION SELECT villes_routeb_numero, villes_routea_numero FROM Routes; GO Les triggers Le trigger Rte_TAPIs_IOI se déclenche en lieu et place de l insertion par la vue et interdit d insérer un double lien. CREATE TRIGGER Rte_INSTEADOFTAPIs_IOI ON Rte_INSTEADOFTAPIs INSTEAD OF INSERT AS BEGIN int; int; int; -- Récupère les données insérées = = Villes_routeB_numero FROM INSERTED; -- Vérifie s il existe un lien inverse = COUNT(*) FROM Routes WHERE villes_routea_numero AND villes_routeb_numero -- Si un lien inverse existe alors une erreur est levée -- sinon l insertion se fait > 0 RAISERROR('Il n''est pas possible de créer un lien inverse dans un graphe non orienté', 11, 1); ELSE INSERT INTO Routes(villes_routeA_numero, villes_routeb_numero) END GO JULIEN OGI PAGE 11 SUR 56

13 Aucune solution n a été trouvée pour le trigger Rte_TAPIs_NoDML. Avec Oracle la solution est d utiliser la procédure who_called_me qui permet de savoir quels éléments a appelés le trigger. Si c est le trigger Rte_INSTEADOFTAPIs, alors l insertion dans la table Routes se fait, sinon l insertion est refusée. Malheureusement, après quelques recherches, SQL Server ne propose pas une telle procédure. Une solution serait d investiguer plus en profondeur le CLR avec lequel il est sans doute possible de créer cette procédure manquante Résultats des tests Si on reprend notre table Cours et qu on teste l insertion, la mise à jour et la suppression de données, on obtient les résultats suivants : Insertion : INSERT INTO Cours(Libelle) VALUES('Chant'); La table Cours contient les données insérées en plus des valeurs d audit d insertion. Figure 3 Table Cours après une insertion Tandis que dans la table de journalisation, on retrouve nos données insérées en plus des valeurs propres à la journalisation (les noms de colonnes préfixées JN). Mise à jour : UPDATE Cours SET Libelle = 'Guitare' WHERE Libelle = 'Chant'; Figure 4 Table Cours_JN après une insertion Après une modification les colonnes CTRLMOUSER et CTRLMODATE, en l occurrence les colonnes d audit, sont mises à jour. Figure 5 Table Cours après une modification JULIEN OGI PAGE 12 SUR 56

14 La table de journalisation contiendra une ligne de plus, respectivement celle qui vient d être modifiée. Suppression : DELETE FROM Cours WHERE Libelle = 'Guitare'; Figure 6 Table Cours_JN après une modification Ici en l occurrence comme il n y avait que cette donnée dans la table, cette dernière se retrouve vide. Figure 7 Table Cours après une suppression Dans la table de journalisation on retrouve bien notre ligne supprimée, insérée à la suite des deux autres. Figure 8 Table Cours_JN après une suppression Ces résultats indiquent que le code SQL rédigé est fonctionnel et peut donc être repris et adapté pour le plugin Graphe non orienté Nous pouvons maintenant tester les graphes non orientés. Le seul élément à tester ici est le trigger Rte_INSTEADOFTAPIs_IOI lié à la vue. On va partir du postulat qu il existe déjà deux lignes dans notre table Villes. Figure 9 Table Villes JULIEN OGI PAGE 13 SUR 56

15 Insérons maintenant une route entre les deux villes. INSERT INTO Routes_INSTEADOFTAPIs(villes_routeA_numero, villes_routeb_numero) VALUES(1, 2); Le résultat sera le suivant : Si maintenant on insère un lien inverse. Figure 10 Vue Routes_INSTEADOFTAPIs INSERT INTO Routes_INSTEADOFTAPIs(villes_routeA_numero, villes_routeb_numero) VALUES(2,1); Nous obtenons bien le message d erreur spécifié. Msg 50000, Niveau 11, État 1, Procédure Routes_INSTEADOFTAPIs_IOI, Ligne 19 Il n'est pas possible de créer un lien inverse dans un graphe non orienté JULIEN OGI PAGE 14 SUR 56

16 3. Plugin Maintenant que les APIs de table ont été testées il est possible de les créer via le plugin Les modèles Les MLD sont les suivants : Figure 11 MLD/MPD général JULIEN OGI PAGE 15 SUR 56

17 Figure 12 MLD/MPD du graphe non orienté 3.2. Les paramètres Les paramètres permettent plus de souplesse dans le nommage des différents objets. Ils sont paramétrés à des emplacements bien spécifiques dans le code ou dans le fichier de propriétés et peuvent ensuite être réutilisés à travers les classes et templates. Si par exemple on désire changer l implémentation d une fonction SQL, qui est réutilisée à plusieurs endroits, il ne sera pas nécessaire de la modifier partout mais seulement une seule fois dans la méthode où elle est implémentée Les paramètres de noms Pour créer les paramètres de noms (texte entre accolades et en minuscule), il existe un fichier de propriétés (plugin.properties) qui permet de définir le texte qui remplacera ces paramètres. Ces propriétés sont reprisent dans une classe (Properties.java) et il est possible de les atteindre depuis d autres classes à travers le code. Tous ces paramètres de nom sont référencés dans l énumération SqlserverNameType du package mpdmemory.sqlserver Liste des paramètres Nom du paramètre Description Nom de la propriété Le nom du schéma qui database.sqlserver.constr. {package_tapis} contiendra les différents package.tapis.format.name éléments mpd.sqlserver.typetable. {typetable_name} Le nom du type TABLE name Le nom de la variable qui sera du mpd.sqlserver.typetable. {variable_typetable_name} type TABLE variable.name {autogen_column_ins} Le nom de la fonction de mise à jour des valeurs d audit d insertion mpd.sqlserver.code.autogen. column.ins JULIEN OGI PAGE 16 SUR 56

18 {autogen_column_upd} {pi_crtrec} {po_crtrec} {ins_jn} {table_jn} {jn_operation} {jn_user} {jn_datetime} {jn_notes} {jn_appl} {jn_session} {audit_user_value} {audit_date_value} {trigger} Le nom de la fonction de mise à jour des valeurs d audit de modification Paramètre d entrée des fonctions de mise à jour des valeurs d audit Paramètre de sortie des fonctions de mise à jour des valeurs d audit Le nom de la procédure de journalisation Le nom de la table de journalisation Le nom de la colonne de journalisation qui contiendra le nom de l opération effectuée (INS, UPD, DEL) Le nom de la colonne de journalisation qui contiendra le nom de l utilisateur ayant effectué une modification Le nom de la colonne de journalisation qui contiendra la date (et l heure) de modification Le nom de la colonne de journalisation qui contiendra d éventuelles notes du concepteur Le nom de la colonne de journalisation qui contiendra le nom de l API utilisée Le nom de la colonne de journalisation qui contiendra le numéro de session de l utilisateur ayant effectué une modification La valeur d audit du champ utilisateur La valeur d audit du champ date Le nom du trigger mpd.sqlserver.code.autogen. column.upd mpd.sqlserver.code.picrtrec mpd.sqlserver.code.pocrtrec mpd.sqlserver.code.ins.jn Database.sqlserver.constr. tablejn.format.name mpd.column.jn.operation mpd.column.jn.user mpd.column.jn.datetime mpd.column.jn.notes mpd.column.jn.appl mpd.column.jn.session mpd.sqlserver.column.audit. user.value mpd.sqlserver.column.audit. date.value database.sqlserver.constr.trigger. format.name {table} Le nom de la table Valeurs tagguées {function_alias} Le nom de l alias des fonctions mpd.sqlserver.function.alias {typetable_alias} Le nom de l alias des types TABLE mpd.sqlserver.typetable.alias {view} Le nom de la vue database.sqlserver.constr.view. format.name JULIEN OGI PAGE 17 SUR 56

19 {view_variables} Le nom des variables utilisées pour distinguées les routes dans le cas d un graphe non orienté Tableau 1 Liste des paramètres mpd.sqlserver.view.insteadof. variable Les éléments en vert représentent les paramètres qui ont dû être créés ou adaptés spécialement pour ce travail, les autres existaient déjà et ont pu être utilisés tels quels. Ces paramètres peuvent être utilisés autant bien dans les classes que dans les templates. Cependant l utilisateur n ayant pas forcément accès au code source, ils seront surtout utiles dans les templates. Ci-dessous un exemple d utilisation des paramètres. Fichier de template : CREATE FUNCTION {package_tapis}.{autogen_column_ins}({pi_crtrec} {typetable_name} READONLY) RETURNS {po_crtrec} TABLE ( {ALL_COLUMNS_TYPETABLE}) AS BEGIN INSERT INTO {po_crtrec} ( {ALL_COLUMNS_NAME}) SELECT {ALL_COLUMNS_FUNCTION_AJ} FROM {pi_crtrec}; RETURN; END; Ce bout de code se trouve dans un fichier de template et on peut voir l utilisation de plusieurs paramètres de noms. Ces paramètres prendront la valeur que l on a définie dans le fichier de propriétés une fois la transformation effectuée. Résultat après transformation : CREATE FUNCTION Crs_TAPIs.autogen_column_ins(@pi_crtrec typ_cours READONLY) TABLE ( Numero INT,Libelle VARCHAR(30),CTRLAJUSER VARCHAR(30),CTRLAJDATE DATETIME2,CTRLMOUSER VARCHAR(30),CTRLMODATE DATETIME2 ) AS BEGIN INSERT ( Numero,Libelle,CTRLAJUSER,CTRLAJDATE,CTRLMOUSER,CTRLMODATE ) JULIEN OGI PAGE 18 SUR 56

20 SELECT Numero,Libelle,USER,CURRENT_TIMESTAMP,CTRLMOUSER,CTRLMODATE END; RETURN; On retrouve en vert les paramètres de noms qui ont été remplacés par leur valeur du fichier de propriétés. Les éléments en majuscules et entre accolades représentent du code dynamique. Cette notion est expliquée au prochain chapitre Les paramètres de code dynamique Les paramètres de code dynamique fonctionnent selon la même logique que les paramètres de noms. A ceci près qu étant donné qu ils sont dynamiques, ce sont des classes Java qui s occuperont de les traiter. Ici aussi certains paramètres ont été définis. La liste complète est ci-dessous. Ces paramètres sont contenus dans l énumération SqlserverDynamicCodeType du package mpdmemory.sqlserver Liste des paramètres de code dynamique Nom du paramètre {ALL_COLUMNS_TYPETABLE} {ALL_COLUMNS_NAME} {ALL_COLUMNS_FUNCTION_AJ} {ALL_COLUMNS_FUNCTION_MO} {UPDATE_COLUMNS_AUDIT_AJ} {UPDATE_COLUMNS_AUDIT_MO} {DECLARE_VARIABLES_VIEW_INSTEADOF} {INSERT_INTO_VARIABLES} {ALL_PK} {ALL_PK_VALUES} {INS_JN_INS} {INS_JN_UPD} Description Affiche toutes les colonnes de la table avec leurs types de données Affiche toutes les colonnes de la table Affiche toutes les colonnes de la table avec les colonnes d audit d ajout Affiche toutes les colonnes de la table avec les colonnes d audit de modification Affiche la mise à jour des colonnes d audit d ajout Affiche la mise à jour des colonnes d audit de modification Affiche la déclaration des variables représentant les routes entre les villes dans le cas d un graphe non orienté Affecte les variables représentant les routes entre les villes avec les valeurs de la table INSERTED Affiche toutes les PK Affiche les variables représentant les routes entre les villes Affiche l appel de la procédure de journalisation lors d une insertion Affiche l appel de la procédure de journalisation lors d une mise à jour JULIEN OGI PAGE 19 SUR 56

21 Affiche l appel de la procédure de journalisation lors {INS_JN_DEL} d une suppression Affiche les lignes du premier SELECT de la vue {ASSNN_REF_NONORIENTED_COLFIRST} matérialisant les colonnes de la table associative d un graphe non orienté Affiche les lignes du deuxième SELECT de la vue {ASSNN_REF_NONORIENTED_COLSECOND} matérialisant les colonnes de la table associative d un graphe non orienté Tableau 2 Liste des paramètres de code dynamique Tous les paramètres ont été créés sauf {INS_JN_INS}, {INS_JN_UPD} et {INS_JN_DEL} et les deux derniers qui ont été repris et adaptés pour SQL Server. Si on reprend le code de l exemple précédent on peut voir les paramètres de code dynamique, en violet ci-dessous. Fichier de template : CREATE FUNCTION {package_tapis}.{autogen_column_ins}({pi_crtrec} {typetable_name} READONLY) RETURNS {po_crtrec} TABLE( {ALL_COLUMNS_TYPETABLE}) AS BEGIN INSERT INTO {po_crtrec} ( {ALL_COLUMNS_NAME}) SELECT {ALL_COLUMNS_FUNCTION_AJ} FROM {pi_crtrec}; RETURN; END; Résultat après transformation : CREATE FUNCTION crs_tapis.autogen_column_ins(@pi_crtrec typ_cours READONLY) TABLE ( Numero INT,Libelle VARCHAR(30),CTRLAJUSER VARCHAR(30),CTRLAJDATE DATETIME2,CTRLMOUSER VARCHAR(30),CTRLMODATE DATETIME2 ) AS BEGIN INSERT ( Numero,Libelle,CTRLAJUSER,CTRLAJDATE,CTRLMOUSER,CTRLMODATE ) SELECT JULIEN OGI PAGE 20 SUR 56

22 Numero,Libelle,USER,CURRENT_TIMESTAMP,CTRLMOUSER,CTRLMODATE END; RETURN; Les paramètres de blocs de code Ils sont semblables aux paramètres de code dynamique dans le sens où ils s écrivent aussi en majuscules. Par contre ils référencent les fichiers de template dont le code viendra s insérer en lieu et place du nom du paramètre. Ces derniers se trouvent dans l énumération SqlserverBlockType du package mpdmemory.sqlserver Liste des paramètres de blocs de code Nom du paramètre Description {TYPE_TABLE} Insère le bloc de code correspondant au type TABLE {BLOCK_COLUMN_AUDIT_AJ} Insère le bloc de code correspondant à la fonction de mise à jour des valeurs d audit d insertion {BLOCK_COLUMN_AUDIT_MO} Insère le bloc de code correspondant à la fonction de mise à jour des valeurs d audit de modification {INS_JN_BODY} Insère le bloc de code correspondant à la procédure de journalisation Tableau 3 Liste des paramètres de bloc de code Si par exemple dans un template on utilise le paramètre {TYPE_TABLE}, le résultat après transformation sera la structure du type TABLE sélectionné. Fichier de template : {TYPE_TABLE} Résultat après transformation : CREATE TYPE typ_cours AS TABLE ( Numero INT,Libelle VARCHAR(30),CTRLAJUSER VARCHAR(30),CTRLAJDATE DATETIME2,CTRLMOUSER VARCHAR(30),CTRLMODATE DATETIME2 ); JULIEN OGI PAGE 21 SUR 56

23 3.3. Les types de données Visual Paradigm associe les types de données à un numéro plus ou moins aléatoire. Du moins il n y a aucune logique à première vue. Ces numéros sont indispensables au plugin car ce dernier se base dessus pour créer les types de données MLD. Numéro Type de données 1 bit 31 char 2 bit 32 char 3 bit 33 nchar 4 float 34 text 5 real 35 text 6 float 36 text 7 tinyint 37 text 8 smallint 38 ntext 9 int 39 binary 10 int 40 varbinary 11 decimal 41 varbinary 12 money 42 char 13 decimal 43 char 14 smallmoney 44 nchar 15 numeric 45 text 16 bigint 46 nvarchar 17 date 47 text 18 date 48 uniqueidentifier 19 time 49 N/A 20 datetime 50 bit 21 smalldatetime 51 numeric 22 datetime 52 text 23 image 53 vhar 24 image 54 datetimeoffset 25 image 55 text 26 image 56 datetime2 27 varchar 57 varchar 28 varchar 58 timestamp 29 varchar 59 image 30 nvarchar 60 datetimeoffset Tableau 4 Numéros des types de données JULIEN OGI PAGE 22 SUR 56

24 Pour trouver ces numéros il a fallu créer une boucle qui affiche chaque numéro en regard des types de données. Code : Comme on ne sait pas en avance combien de numéros il existe on indique une valeur de boucle limite assez grande pour être sûr de tous les avoir. Ici en l occurrence 100, qui est bien suffisant étant donné que le numéro maximum est 60. Cette portion de code ci-dessus a été mise au tout début de la fonction runmvccd de la classe MCDToMLDTransformer du package services. Évidemment il est nécessaire de supprimer ce code pour utiliser le plugin en production. Une fois les numéros connus il est possible de les gérer depuis l énumération IDBColumnSqlserverTypeEnum. Code : Tout le code n est volontairement pas affiché ici pour alléger le document et faciliter la lecture Correspondance des types de données MCD et MLD C est la classe MCDToMLD qui se charge de faire la correspondance entre les types de données MCD et MLD. Plus précisément la méthode chargetypemapper. Elle va se charger de récupérer tous les types de données présents dans le MCD et les comparer avec la liste des types de données MLD et si une correspondance existe alors elle mappe le type de données MCD avec celui du MLD. Évidemment il faut séparer les différents SGBDR car les types de données MLD ne seront pas forcément les mêmes. JULIEN OGI PAGE 23 SUR 56

25 Code : Inutile de mettre tout le code ici non plus, cette séquence est assez représentative. Ce sera une structure de else if pour chaque type de données qui nous intéresse. Certains types doivent avoir des tailles définies comme c est le cas pour le type booléen qui devient un type CHAR au niveau du MLD avec une taille obligatoirement de Le type TABLE Tous les exemples suivants seront basés principalement sur la table Cours. La création du type TABLE se fait grâce à un fichier de template. Template type_table.txt : CREATE TYPE {typetable_name} AS TABLE ( {ALL_COLUMNS_TYPETABLE} ); Le paramètre de noms {typetable_name} de couleur orange est défini dans le fichier de propriétés. Fichier de propriétés : mpd.sqlserver.typetable.name=typ_{table} Le paramètre {ALL_COLUMNS_TYPETABLE} de couleur violette est créé dynamiquement dans la méthode allcolumnstypetable de la classe SqlserverSchema du package mpdmemory.sqlserver. JULIEN OGI PAGE 24 SUR 56

26 Méthode pour {ALL_COLUMNS_TYPETABLE} : La seule particularité ici est la condition de la taille du type de données. Si celui-ci en a une alors il faut la créer entre parenthèses. Il ne reste plus qu à appeler la méthode, cela se fait dans la fonction getdynamiquecode située dans la même classe. Appel de la méthode : La condition stipule tout simplement que si la clé du code dynamique correspond à la clé de la valeur ALL_COLUMN_TYPETABLE localisée dans l énumération SqlserverDynamicCodeType, alors on exécute la fonction allcolumnstypetable. Ces appels de méthodes sont tous les mêmes et ne seront par conséquent plus décrit par la suite. Résultat après transformation : CREATE TYPE typ_cours AS TABLE ( Numero INT,Libelle VARCHAR(30),CTRLAJUSER VARCHAR(30),CTRLAJDATE DATETIME,CTRLMOUSER VARCHAR(30),CTRLMODATE DATETIME ); On retrouve en orange le paramètre de noms {typetable_name} et en violet le paramètre de code dynamique. JULIEN OGI PAGE 25 SUR 56

27 3.5. Les triggers Les triggers se créent aussi grâce à des fichiers de template Insertion L insertion utilise le fichier de template ai.txt. Template ai.txt : CREATE TRIGGER {trigger} ON {table} AFTER INSERT AS BEGIN DECLARE {variable_typetable_name} {typetable_name}; INSERT INTO {variable_typetable_name} ({ALL_COLUMNS_NAME}) SELECT {ALL_COLUMNS_NAME} FROM INSERTED; UPDATE {variable_typetable_name} SET {UPDATE_COLUMNS_AUDIT_AJ} FROM {package_tapis}.{autogen_column_ins}({variable_typetable_name}) AS {function_alias}; UPDATE {table} SET {UPDATE_COLUMNS_AUDIT_AJ} FROM {variable_typetable_name} AS {typetable_alias} WHERE {ALL_PK}; END; EXEC {INS_JN_INS} Le paramètre {ALL_COLUMNS_NAME} retourne toutes les colonnes de la table. Pour ce faire c est la méthode selectcolumns de la classe SqlserverTrigger du package mpdmemory.sqlserver qui sera appelée. JULIEN OGI PAGE 26 SUR 56

28 Méthode pour {ALL_COLUMNS_NAME} : Rien de particulier si ce n est la gestion de la virgule. Cette méthode contient aussi du code qui concerne les vues et qui est à peu de chose près identique au code ci-dessus. Le paramètre {UPDATE_COLUMNS_AUDIT_AJ} crée la mise à jour des colonnes d audit d insertion. Méthode pour {UPDATE_COLUMNS_AUDIT_AJ} : Les propriétés MPD_COLUMN_AUDIT_AJ_USER et MPD_COLUMN_AUDIT_AJ_DATE retourne les noms des colonnes d audit d insertion. On sépare ici le code selon si ça concerne une fonction ou un type TABLE. Il est obligatoire de le faire pour avoir le bon alias. Il aurait aussi été possible de séparer les deux conditions en créant une seconde fonction pour les types TABLE, cependant il est plus pratique de réunir les deux conditions dans une fonction car elles sont très semblables et si une modification doit être effectuée sur une, alors il sera très simple de reporter cette modification sur l autre. JULIEN OGI PAGE 27 SUR 56

29 La propriété {ALL_PK} permet d insérer le code de comparaison des clés primaires de la table et du type TABLE, pour retrouver la bonne ligne à modifier. Code pour {ALL_PK} : La variable booléenne morethanone permet de savoir si la clé primaire est composée de plusieurs colonnes, utile pour la table associative dans notre cas. Ici aussi le code est séparé selon si c est une table ou une vue. Et pour finir le paramètre {INS_JN_INS} crée le code d appel de la procédure de journalisation. Méthode {INS_JN_INS} : Le paramètre représente l opération effectuée. INS pour une insertion, UPD pour une modification et DEL pour une suppression. Appel de la méthode : On vérifie d abord si la table doit être journalisée et si c est le cas alors on passe en paramètre la valeur correspondante et on appelle la méthode. JULIEN OGI PAGE 28 SUR 56

30 Résultat après transformation : CREATE TRIGGER Ins_TAPIs_AI ON Inscrire AFTER INSERT AS BEGIN typ_inscrire; INSERT ( Etu_Inscrire_Numero, Crs_Inscrire_Numero, CTRLAJUSER, CTRLAJDATE, CTRLMOUSER, CTRLMODATE) SELECT Etu_Inscrire_Numero, Crs_Inscrire_Numero, CTRLAJUSER, CTRLAJDATE, CTRLMOUSER, CTRLMODATE FROM Inserted; SET CTRLAJUSER = f.ctrlajuser, CTRLAJDATE = f.ctrlajdate FROM Ins_TAPIs.autogen_column_ins(@tab) AS f; UPDATE Inscrire SET CTRLAJUSER = t.ctrlajuser, CTRLAJDATE = t.ctrlajdate AS t WHERE Inscrire.Etu_Inscrire_Numero = t.etu_inscrire_numero AND Inscrire.Crs_Inscrire_Numero = t.crs_inscrire_numero; END; EXEC Ins_TAPIs.ins_jn tab, 'INS'; JULIEN OGI PAGE 29 SUR 56

31 Mise à jour D. PARTIE PRATIQUE - APIS DE TABLE POUR SQL SERVER Comme déjà vu plus haut, le trigger de mise à jour est quasiment identique à celui de l insertion. La seule différence ici concerne l audit et l appel de la procédure de journalisation. Template au.txt : CREATE TRIGGER {trigger} ON {table} AFTER UPDATE AS BEGIN DECLARE {variable_typetable_name} {typetable_name}; INSERT INTO {variable_typetable_name}({all_columns_name}) SELECT {ALL_COLUMNS_NAME} FROM INSERTED; UPDATE {variable_typetable_name} SET {UPDATE_COLUMNS_AUDIT_MO} FROM {package_tapis}.{autogen_column_ins}({variable_typetable_name}) AS {function_alias}; UPDATE {table} SET {UPDATE_COLUMNS_AUDIT_MO} FROM {variable_typetable_name} AS {typetable_alias} WHERE {ALL_PK}; END; EXEC {INS_JN_UPD}; Le paramètre {UPDATE_COLUMNS_AUDIT_MO} est identique à celui de l insertion excepté le fait que ce sont évidemment les colonnes d audit de modification qui sont retournées et non ceux d insertion. Et ensuite le paramètre {INS_JN_UPD} appelle la procédure de journalisation, le code est le même que lors de l insertion, sauf le paramètre qui indique l opération effectuée, UPD dans ce cas donc. JULIEN OGI PAGE 30 SUR 56

32 Suppression D. PARTIE PRATIQUE - APIS DE TABLE POUR SQL SERVER Le code est ici simplifié mais aucun nouvel élément n apparaît sauf l appel de la procédure de journalisation. Ce sera {INS_JN_DEL} qui sera utilisé pour que l opération passée en paramètre soit la bonne. Template ad.txt : CREATE TRIGGER {trigger} ON {table} AFTER DELETE AS BEGIN DECLARE {variable_typetable_name} {typetable_name}; INSERT INTO {variable_typetable_name} ({ALL_COLUMNS_NAME}) SELECT {ALL_COLUMNS_NAME} FROM DELETED; END; EXEC {INS_JN_DEL}; Trigger INSTEAD OF de la vue Ce trigger est spécifique à une vue mais cela ne change rien à la façon de faire. Pour empêcher l insertion d un lien inverse dans un graphe non orienté, on utilise un trigger INSTEAD OF qui se déclenchera à la place de l ordre d insertion. Template ioi.txt : CREATE TRIGGER {trigger} ON {view} INSTEAD OF INSERT AS BEGIN DECLARE {DECLARE_VARIABLES_VIEW_INSTEADOF}; int; SELECT {INSERT_INTO_VARIABLES} FROM Inserted; = COUNT(*) FROM {table} WHERE {ALL_PK}; > 0 RAISERROR('Il n''est pas possible de créer un lien inverse dans un graphe non orienté', 11, 1); ELSE INSERT INTO {table}({all_columns_name}) VALUES({ALL_PK_VALUES}); END; JULIEN OGI PAGE 31 SUR 56

33 Le paramètre de code dynamique {DECLARE_VARIABLES_VIEW_INSTEADOF} représente la déclaration des variables qui contiendront les valeurs des colonnes de clés primaires de chacune des villes. À la place du paramètre de blocs dynamiques {INSERT_INTO_VARIABLES} sera générée l affectation des variables des colonnes de clés primaires précédemment créées. Le dernier paramètre {ALL_PK_VALUES} énumère les variables des colonnes de clés primaires. Le code dynamique du paramètre {DECLARE_VARIABLES_VIEW_INSTEADOF} se trouve dans la classe SqlserverTrigger du package mpdmemory.sqlserver. Code : La variable i sert à incrémenter une séquence pour différencier les noms des variables. Dans notre cas on aurait pu créer deux propriétés représentant chacune une colonne de la table Routes étant donné que nous n avons que deux colonnes, une pour chaque ville. Cependant ce n aurait pas été très efficient au niveau réutilisabilité et souplesse. Le code dynamique du paramètre {INSERT_INTO_VARIABLES} se trouve dans la même classe. Il est très semblable au code ci-dessus, si ce n est qu il n y a pas de gestion du type de données. JULIEN OGI PAGE 32 SUR 56

34 Le paramètre {ALL_PK}, déjà vu au Chapitre est aussi utilisable pour les vues. Mais cette fois on va s intéresser à la suite de la méthode. Code : Ce code est relativement similaire au précédent. Attention cependant à ne pas incrémenter la valeur de i. Il faut en effet la décrémenter depuis la valeur de size de l ArrayList de retour de la méthode getcolumns. Sinon il sera possible d insérer un lien inverse. Le dernier paramètre {ALL_PK_VALUES} ne fait que reprendre les variables de clé primaire séparées par une virgule. Résultat après transformation : CREATE TRIGGER Rte_TAPIs_IOI ON Rte_INSTEADOFTAPIs INSTEAD OF INSERT AS BEGIN INT; INT; = = Vil_routeB_Numero FROM Inserted; = COUNT(*) FROM Routes WHERE Vil_routeA_Numero AND Vil_routeB_Numero > 0 RAISERROR('Il n''est pas possible de créer un lien inverse dans un graphe non orienté', 11, 1); ELSE INSERT INTO Routes ( Vil_routeA_Numero, Vil_routeB_Numero) VALUES(@route_1 JULIEN OGI PAGE 33 SUR 56

35 END; 3.6. Les fonctions Pour rappel les fonctions servent à mettre à jour les données d audit Audit Le template de la fonction de mise à jour des données d audit d insertion se nomme audit_aj.txt. Template audit_aj.txt : CREATE FUNCTION {package_tapis}.{autogen_column_ins}({pi_crtrec} {typetable_name} READONLY) RETURNS {po_crtrec} TABLE ( {ALL_COLUMNS_TYPETABLE}) AS BEGIN INSERT INTO {po_crtrec} ( {ALL_COLUMNS_NAME}) SELECT {ALL_COLUMNS_FUNCTION_AJ} FROM {pi_crtrec}; RETURN; END; La nouveauté ici est la propriété {ALL_COLUMNS_FUNCTION_AJ} qui retourne toutes les colonnes ainsi que les colonnes d audit d insertion grâce à la méthode allcolumnsvaluefunctionaj contenue dans la classe SqlserverSchema du package mpdmemory.sqlserver. Méthode pour {ALL_COLUMNS_FUNCTION_AJ} : JULIEN OGI PAGE 34 SUR 56

36 Cette méthode s occupe de remplacer les noms des colonnes d audit par les valeurs qu elles doivent prendre. Si la propriété MPD_COLUMN_AUDIT_AJ_USER qui représente le nom de la colonne d audit de l utilisateur correspond au nom de la colonne actuellement sélectionnée alors la valeur du nom de l utilisateur sera retournée (USER). Si la propriété MPD_COLUMN_AUDIT_AJ_DATE qui représente le nom de la colonne d audit de la date correspond au nom de la colonne actuellement sélectionnée alors la valeur de la date actuelle sera retournée (CURRENT_TIMESTAMP). Résultat après transformation : CREATE FUNCTION Crs_TAPIs.autogen_column_ins(@pi_crtrec typ_cours READONLY) TABLE ( Numero INT,Libelle VARCHAR(30),CTRLAJUSER VARCHAR(30),CTRLAJDATE DATETIME,CTRLMOUSER VARCHAR(30),CTRLMODATE DATETIME ) AS BEGIN INSERT ( Numero,Libelle,CTRLAJUSER,CTRLAJDATE,CTRLMOUSER,CTRLMODATE ) SELECT Numero,Libelle,USER,CURRENT_TIMESTAMP,CTRLMOUSER,CTRLMODATE END; RETURN; Pour la fonction concernant la mise à jour c est le même principe sauf qu évidemment ce seront les valeurs d audit de modification qui seront concernées. Template audit_mo.txt CREATE FUNCTION {package_tapis}.{autogen_column_upd}({pi_crtrec} {typetable_name} READONLY) RETURNS {po_crtrec} TABLE ( {ALL_COLUMNS_TYPETABLE}) AS BEGIN INSERT INTO {po_crtrec} ( JULIEN OGI PAGE 35 SUR 56

37 END; {ALL_COLUMNS_NAME}) SELECT {ALL_COLUMNS_FUNCTION_MO} FROM {pi_crtrec}; RETURN; La seule différence avec la fonction précédente est le bloc {ALL_COLUMNS_FUNCTION_MO} qui fait la même chose que le bloc {ALL_COLUMNS_FUNCTION_AJ} mais pour la modification Les procédures La procédure est utilisée pour journaliser les opérations effectuées sur les tables Journalisation La journalisation se fait grâce à cette procédure. Template ins_jn.txt : CREATE PROCEDURE {package_tapis}.{ins_jn} {pi_crtrec} {typetable_name} VARCHAR(3) AS BEGIN INSERT INTO {table_jn} ( {jn_operation}, {jn_user}, {jn_datetime}, {jn_notes}, {jn_appl}, {jn_session}, {ALL_COLUMNS_NAME}) {audit_user_value}, {audit_date_value}, null, {ALL_COLUMNS_NAME} FROM {pi_crtrec}; END; Ici les paramètres {audit_user_value} et {audit_date_value} représentent respectivement la valeur de l utilisateur qui ira dans la colonne {jn_user} et la valeur de la date de modification qui ira dans la colonne {jn_datetime}. JULIEN OGI PAGE 36 SUR 56

38 Résultat après transformation : CREATE PROCEDURE typ_cours VARCHAR(3) AS BEGIN INSERT INTO Cours_JN ( JN_OPERATION, JN_USER, JN_DATETIME, JN_NOTES, JN_APPL, JN_SESSION, Numero,Libelle,CTRLAJUSER,CTRLAJDATE,CTRLMOUSER,CTRLMODATE ) USER, CURRENT_TIMESTAMP, null, Numero,Libelle,CTRLAJUSER,CTRLAJDATE,CTRLMOUSER,CTRLMODATE END; FROM pi_crtrec; 3.8. Les schémas La création des schémas se gère dans le fichier de template schema.txt. Template schema.txt : CREATE SCHEMA {package_tapis} AUTHORIZATION dbo; Tout ce qu il fait ici est de reprendre le nom du schéma généré lors de la transformation. Résultat après transformation : CREATE SCHEMA Crs_TAPIs AUTHORIZATION dbo; JULIEN OGI PAGE 37 SUR 56

39 3.9. Le bloc d exécution Maintenant il faut regrouper les types TABLE, fonctions et procédures dans le schéma, donc dans un bloc d instruction qui représente en fait les schémas. Le bloc est aussi créé grâce à un fichier de template. Tous les paramètres contenus dans ce template sont des paramètres de blocs de code. Template tapis.txt : exec('{type_table}') exec('{block_column_audit_aj}') exec('{block_column_audit_mo}') exec('{ins_jn_body}') Le paramètre {TYPE_TABLE} insère la création du type TABLE vu au Chapitre 3.4. Le paramètre {BLOCK_COLUMN_AUDIT_AJ} insère le code de la fonction qui permet de mettre à jour les colonnes d audit lors de l ajout. Vu au Chapitre Quant au paramètre {BLOCK_COLUMN_AUDIT_MO}, il crée la fonction de mise à jour des valeurs d audit lors d une mise à jour. Vu au Chapitre Le dernier paramètre est {INS_JN_BODY} et insère la procédure de journalisation. Vu au Chapitre Ces blocs se trouvent dans l énumération SqlserverBlockType sous forme d énumération et font en fait référence aux fichiers de template des différents blocs à insérer. Ainsi le paramètre {TYPE_TABLE} référence le template type_table.txt, le bloc {BLOCK_COLUMN_AUDIT_AJ} le template audit_aj.txt et ainsi de suite. Code : Pour référencer les fichiers il suffit d entrer l URL et de l affecter à la variable templatedir. Code : En l occurrence les templates se trouvent à l emplacement mld-r/sqlserver/blocks. Le problème qu on a maintenant est qu il est impossible d utiliser la commande GO en dehors des utilitaires de SQL Server. De ce fait il faut trouver une solution de remplacement. Une solution consiste JULIEN OGI PAGE 38 SUR 56

40 à séparer les différents blocs pour qu ils s exécutent les uns après les autres et ainsi simulent la commande GO. Si on ne sépare pas les blocs ainsi une erreur sera retournée. Résultat après transformation : exec('create TYPE typ_cours AS TABLE( Numero INT,Libelle VARCHAR(30),CTRLAJUSER VARCHAR(30),CTRLAJDATE DATETIME,CTRLMOUSER VARCHAR(30),CTRLMODATE DATETIME );') exec('create FUNCTION crs_tapis.autogen_column_ins(@pi_crtrec typ_cours READONLY) TABLE( Numero INT,Libelle VARCHAR(30),CTRLAJUSER VARCHAR(30),CTRLAJDATE DATETIME,CTRLMOUSER VARCHAR(30),CTRLMODATE DATETIME ) AS BEGIN INSERT Numero,Libelle,CTRLAJUSER,CTRLAJDATE,CTRLMOUSER,CTRLMODATE ) SELECT Numero,Libelle,USER,CURRENT_TIMESTAMP,CTRLMOUSER,CTRLMODATE RETURN; END;') -- Les autres blocs de code sont similaires Les blocs de code de création de la fonction de mise à jour des valeurs d audit et la procédure de journalisation suivent le même principe. JULIEN OGI PAGE 39 SUR 56

41 3.10. Différencier les SGBDR Un des buts du projet est de proposer le ciblage de la base de données. En fait ce point est arrivé implicitement lors de la réalisation de ce travail. Effectivement on est bien obligé à un moment ou à un autre de différencier les SGBD cibles. Comme le plugin dispose d un fichier de propriétés, le plus simple et logique est de l utiliser pour effectuer cette tâche. Une propriété a donc été ajoutée et elle permet de choisir vers quel fabricant on désire effectuer la transformation. La propriété s appelle database.constructor.name. Figure 13 Propriété de choix du fabricant cible Ci-dessus la propriété a pour valeur sqlserver. Cela signifie que la transformation se fera donc pour SQL Server. Si on désirerait avoir comme constructeur cible Oracle on écrirait tout simplement oracle à la place. Toutefois il n est pas possible de mettre n importe quelle valeur. Si on entre une valeur non prise en charge, le plugin retournera une erreur, il serait donc judicieux d indiquer dans un document annexe quels constructeurs sont pris en charge. Pour le moment seuls Oracle et SQL Server sont pris en charge. Evidemment la valeur représentant le constructeur est unique, si le programmeur décide que la valeur sera sqlserver alors il n est pas possible d entrer autre chose comme par exemple SQLServer. Cette propriété existe bien entendu dans la classe Properties.java. Code : Concrètement lorsqu il est nécessaire de séparer les constructeurs on fait appel à cette propriété à travers le code. Une simple condition suffit comme démontré ci-dessous. Code : JULIEN OGI PAGE 40 SUR 56

42 Parfois il faudra directement appeler la variable statique dans la classe MPDConstructor. Code : Il faut veiller à bien choisir la base de données cible, grâce aux cases à cocher, dans Visual Paradigm également sinon les types de données ne seront pas les bons dans le MLD. La quintessence serait de pouvoir reprendre le choix de la base de données cible que l utilisateur a coché. Malheureusement cette fonctionnalité n est pas disponible, du moins pas encore La classe MPDConstructor Cette classe permet de créer les types de données des fabricants pris en charge par le plugin. Elle comporte plusieurs méthodes importantes. Le constructeur déjà qui crée soit les types de données pour Oracle, soit pour SQL Server. Constructeur : On peut apercevoir deux variables statiques tout au début de la classe. Il y a autant de ces variables qu il y a de fabricants pris en charge par le plugin. Et lorsqu on veut «initialiser» un fabricant on y passe une de ces variables statiques en paramètres du constructeur. Appel du constructeur : JULIEN OGI PAGE 41 SUR 56

43 Dans ce cas ici, on «initialise» un fabricant. Le constructeur appelle une méthode appelée createsqlservercoltypes. Cette dernière est chargée d ajouter les types de données à l ArrayList cidessus. Fonction createsqlservercoltypes : Et cette fonction en appelle une autre qui, concrètement, attribuera les contraintes que chaque type de données doit respecter. Fonction createsqlservercoltype : Seule une partie des types de données est représentée ici. JULIEN OGI PAGE 42 SUR 56

44 3.11. Les colonnes d audit La création des colonnes d audit se passe dans la classe MLDTable du package mldmemory et plus précisément dans la fonction createcolsaudit. Il est nécessaire de séparer les SGBDR car les valeurs que prendront ces colonnes ne sont pas les mêmes selon le fabricant choisi. Code : Le code pour Oracle est exactement le même à part le nom de certaines propriétés, en l occurrence celles où il y a écrit SQLSERVER. On peut voir ci-dessus que l on différencie les SGBDR et qu ensuite on attribue le type de données à la colonne concernée. Si on prend la première colonne qui est le nom de l utilisateur ayant effectué l opération d ajout, représenté par la propriété MPD_COLUMN_AUDIT_AJ_USER, on lui attribue le type de données défini par la propriété MPD_SQLSERVER_COLUMN_AUDIT_USER_TYPE_NAME dont la valeur vaut VARCHAR La table de journalisation La création de la table de journalisation se passe dans la classe MLDTable du package mldmemory, au sein de la fonction createtablejn. Une séparation des SGBDR est aussi requise. Code : JULIEN OGI PAGE 43 SUR 56