PARTIE THÉORIQUE : BASES ET RÉFÉRENCES APIS DE TABLES PLUGIN VP

Transcription

1 Travail de Bachelor PARTIE THÉORIQUE : BASES ET RÉFÉRENCES APIS DE TABLES PLUGIN VP Nom : Veya Prénom : Samuel Classe : 3IGPT Ecole : Haute école de Gestion Arc samuel.veya@he-arc.ch Date de création : Dernière modification : Version : 2.1 Mode de réalisation : Intra-muros Date début Bachelor : Date fin Bachelor : Numéro de référence : TBIG Objet : Partie théorique travail de Bachelor d'informaticien de gestion

2 1. Table des matières 1. Table des matières Introduction Présentation Visual Paradigm For UML La suite logicielle Fonctionnalités de Visual Paradigm For UML L interface utilisateur Pour aller plus loin Méthodologie de projet Méthodologie utilisée Concept utilisé Référentiel Oracle Référentiel «Visual Paradigm» Marquage Java Gestion des exceptions Gestion de fichiers Pattern de persistance et de création Base de données relationnelles Transactions Oracle 11g PL/SQL Audit Journalisation Clé primaires Exceptions «Oracle» Oracle Designer APIs de tables Trigger logique Développement logiciel Dénormalisation Contraintes métier /29

3 2. Introduction Ce document a comme objectif de présenter les outils, techniques et méthodologies qui ont été utilisés durant mon travail de Bachelor. Les éléments abordés sont ceux qu il m a semblé pertinent d expliquer ou de détailler. Les thèmes présentés ont donc été choisis parce qu ils représentent une difficulté particulière du travail ou encore parce qu ils m ont demandé d effectuer des analyses ou un travail de recherche de documentation. Certains thèmes ont également été choisis parce qu ils sont essentiels à la compréhension de la suite du travail. Pour peu que les notions abordées dans ce document qui présente les notions théoriques du travail de Bachelor soient connues du lecteur, il n est pas obligatoire à la compréhension du document présentant le travail pratique de mon travail de Bachelor, puisqu il n explique pas le travail effectué mais les notions qui m ont permis de le réaliser. Pour cette raison les thèmes abordés sont très variés et ne présentent pas à première vue de liaison les uns avec les autres. En effet, ce n est que par mon travail pratique de Bachelor que la mise en commun de toutes ces notions prend un sens sous la forme du travail de développement /29

4 3. Présentation Visual Paradigm For UML L objet du travail de Bachelor reposant sur le développement d un plug-in pour Visual Paradigm For UML, il convient de présenter ce dernier au lecteur pour qu il puisse mieux se situer lors de la lecture des parties ultérieures. 3.1 La suite logicielle Visual Paradigm est un éditeur qui propose une suite logicielle, constituée des outils suivants : Visual Paradigm For UML : permet la création des diagrammes UML et des modèles qui en sont à l origine. Ceux-ci peuvent alors générer du code dans un langage de programmation déterminé. Il propose également la création d autres types de diagrammes, comme celui qui permet la modélisation des bases de données pouvant, lui aussi, générer des canevas d applications basé sur des Framework et Pattern mais en plus, générer du code SQL qu il peut ensuite déployer automatiquement dans différents environnements. Business Process Visual Architect : permet la modélisation de processus normalisés par le langage BPMN, ainsi que la génération des modèles en processus exécutables. Agilian : offre les fonctionnalités nécessaires pour gérer l architecture de l entreprise autour des processus, et le développement agile de logiciels. Il permet la réalisation de maquettes, la gestion des exigences, le travail collaboratif, la gestion des règles métiers ou encore la définition d un vocabulaire commun. A 3 Platform : gère les projets de développement en équipe, de même que la maintenance, respectivement en se basant sur des propositions de la méthodologie Unified Process et en offrant des solutions de gestion des problèmes et des tests. Teamwork Server : fournit un référentiel permettant le stockage des spécifications réalisées par tous les autres outils de la suite. Il assure le travail en équipe, notamment par la prise en charge des technologies de versionning. L ensemble des fonctionnalités tourne sur un même socle d exécution. C est le choix d une ou l autre de ces solutions qui va alors activer les fonctions autorisées au sein du programme de base /29

5 3.2 Fonctionnalités de Visual Paradigm For UML Le logiciel qui nous intéresse est Visual Paradigm For UML. Il est à notre sens très complet mais relativement coûteux. Plus spécifiquement, il permet : La modélisation UML 2.0 qui inclut ses 13 diagrammes La génération de code de programmation dans une bonne partie des langages communs, plus exactement : Java, C#, VB.NET, PHP, ODL, ActionScript, IDL, C++, Delphi, Perl, XML Schema, Python, Objective-C, Objective-C 2.0, Ada95 et Ruby La modélisation de bases de données relationnelles La génération de code SQL et le déploiement dans les principaux SGBDR, à savoir : MySQL, MS SQL Server, Oracle, HSQL, Sybase ASE, Sybase SQL Anywhere, PostgreSQL, Cloudscape-Derby, DB2, Ingres, OpenEdge, Informix, Firebird, FrontBase, Cache, SQLite et H2 Le «reverse engineering», qui consiste en la création automatique de modèles depuis du code de programmation ou depuis une base de données existante La gestion des exigences L analyse d impacts, qui permet de connaître à l avance les conséquences d un changement La création de rapports automatisés Notons que la HEG-Arc de Neuchâtel dispose de deux éditions distinctes du logiciel : «Profesionnal Edition», qui offre les fonctionnalités listées, et «Enterprise Edition», qui est la plus complète et qui fournit les éléments suivant supplémentaires : Modélisation des processus avec le langage BPMN et exportation des modèles en processus exécutables Simulation de l exécution de processus Modélisation de l architecture d entreprise Définition de règles métier Réalisation de schémas «Mind Map» /29

6 3.3 L interface utilisateur L interface du programme, que l on peut découper en cinq grandes zones principales, se présente de la façon suivante : /29

7 3.3.1 Barre d outils (1) La barre d outils permet d accéder intuitivement aux différentes fonctions que Visual Paradigm met à disposition. Chaque icône peut contenir un sous-ensemble de plusieurs fonctionnalités. Par exemple, l outil «Database» contient l accès aux deux diagrammes liés à la modélisation des données. Parmi les rubriques disponibles, voici une brève explication de celles qui semblent être les plus utiles, ou qui ont attrait au présent projet : Icône 1 Nom de l outil Description Project Permet de créer un nouveau projet, d en ouvrir un existant ou d en sauvegarder un autre. UML Modeling Permet de créer des diagrammes UML parmi les 13 disponibles. Business Process Modeling Database Requirement Modeling Team Collaboration Code engineering Object relationnal mapping Permet de créer des diagrammes de processus. Un seul type de diagramme est disponible dans la version professionnelle. Permet de créer des diagrammes entités-relations ou de mapping objet-relationnel. Ce dernier permet de mettre en correspondance des classes de programmation avec des entités de base de données. Permet la création de diagrammes d exigences parmi les six disponibles. Outil «client» qui permet l accès au référentiel du «Teamwork Server», et donc le travail en équipe sur un projet. Apporte les fonctionnalités de génération de code de dans un certain nombre de langages proposés, tel que Java, C# Offre des outils de génération et de reverse engineering pour les bases de données, de plus que des «synchronisations» entre modèle objet et modèle entités-relations. 1 Source : Le tableau contient uniquement les outils principaux. Les descriptions sont traduites en français /29

8 3.3.2 Navigateur (2) Le navigateur propose principalement deux modes d affichages des éléments présents dans un projet Visual Paradigm : la vue des diagrammes et l explorateur de modèles. La première liste les différents diagrammes et les regroupe par type. La seconde représente, en réalité, le référentiel du projet, car tous les objets de ce dernier sont visibles, que ce soit des classes, des tables, des diagrammes ou encore des acteurs. Le navigateur de diagrammes (à gauche) et l explorateur de modèles (à droite) Tous les objets figurants dans les diagrammes ne sont qu une représentation visuelle des éléments du modèle ; ils ne sont donc qu une référence qui pointe vers leur existence propre présente dans l explorateur de modèles. Cette manière de construire rend tout à fait possible la création d objets sans pour autant disposer d un quelconque diagramme Tableau de propriétés (3) Le tableau de propriétés permet de visualiser et modifier les principaux paramètres de l objet sélectionné. Pour accéder à un objet, il suffit de le sélectionner dans la zone de création (détaillé ciaprès), ou d employer l un des deux navigateurs. L'entier des différents paramètres est disponible, de manière plus graphique, en effectuant un double clic sur l élément voulu, ce qui aura pour action d ouvrir une fenêtre dédiée Zone de création des diagrammes (4) Cette zone permet la création effective de diagrammes, accessible par des onglets comme on le remarque sur la capture d écran. L on distingue deux parties : À gauche se trouve la barre d outils composés d éléments propres au diagramme ouvert, qui peuvent être ajoutés à ce dernier par simple glissé déposé. La grande partie de droite est la zone de dessin où l on peut visualiser et travailler avec le diagramme /29

9 3.3.5 Zone d affichage de message (5) La zone d affichage permet d informer l utilisateur à l aide de messages au format «texte». Cette zone est importante dans le cadre de notre projet, car c est au travers d elle que le plug-in pourra afficher une trace des différentes manipulations faites ou, plus simplement, d afficher des erreurs ou avertissements. 3.4 Pour aller plus loin Celui qui désire obtenir davantage d informations quant à Visual Paradigm For UML peut se rendre sur la page de l éditeur qui résume les fonctionnalités 2 ou sur le guide d utilisateur 3. Enfin, sachez qu une version gratuite, appelée «Community Edition» et limitée à une utilisation non commerciale, est disponible 4. Elle permet d utiliser les diagrammes sans limites, mais restreint les fonctionnalités avancées, telles que la génération de code ou le travail en équipe. 2 [WEB-VP-03] 3 [WEB-VP-04] 4 [WEB-VP-05] /29

10 4. Méthodologie de projet 4.1 Méthodologie utilisée La méthodologie qui a été choisie pour la réalisation de ce travail s apparente aux principes édictés par les méthodes agiles 5. Il existe trois raisons principales pour lesquelles j ai choisi de respecter ces principes. Premièrement, étant donné que les objectifs du cahier des charges ne sont pas très détaillés, j ai pu adapter le choix des fonctionnalités à implémenter en cours de développement du projet. Cette manière de procéder correspond tout-à-fait à la vision adaptative des méthodologies agiles, à la seule différence que l adaptation ne n est pas motivée par des demandes de changement du client du projet, mais par mes propres choix et en fonction des analyses et expérimentations effectuées au cours du projet. Deuxièmement, parce que je souhaite répartir mon temps d analyse, de développement et de documentation sur toutes la durée du projet et non pas limiter ces tâches à une certaine période. Ceci correspond selon moi à la vision itérative des méthodes agiles, qui préconise qu un projet soit mené en plusieurs cycles composés de toutes les phases menant de la planification à la terminaison du projet. Troisièmement, dans l optique d avoir des livrables permettant de mieux situer l avancement du projet, mais également de répartir mes risques, je souhaitais séparer mon travail en plusieurs incrémentations indépendantes. Ces livrables n ont pas été demandés directement par le directeur de travail, mais cette manière de procéder est, selon moi, la méthode qui s appliquerait le mieux dans le cadre d un travail en entreprise car il est ainsi possible d avoir très rapidement des versions fonctionnelles dotées de capacités limitées au départ puis de plus en plus complète. 5 [WEB-AGI-01], [WEB-AGI-02] /29

11 5. Concept utilisé 5.1 Référentiel Oracle Description Une des notions principales d «Oracle Designer» est la notion de référentiel. Un référentiel est ici une base de données qui regroupe toutes les définitions des objets. Au sein d un référentiel, il est alors possible de créer des espaces de travail qui regroupent plusieurs projets qui sont le conteneur racine d une application. La navigation dans le référentiel peut ce faire grâce au «Navigateur RON». Il est ensuite possible de créer des répertoires dans un projet pour classifier, séparer les objets qui le composent. 5.2 Référentiel «Visual Paradigm» Description Dans «Visual Paradigm» la notion de référentiel est également présente. En effet, lors de la création d un projet «Visual Paradigm» produit automatiquement un fichier propriétaire qui est en fait un référentiel unique. La notion d espace de travail utilisé dans «Oracle Designer» ne possède pas vraiment d équivalent ; j ai donc décidé de travailler en me basant sur l idée qu un projet possède un espace de travail unique. La création de projet peut, elle, être reproduite grâce à l utilisation de modèle. Au sein d un modèle il n est en effet pas possible d avoir deux objets possédant le même nom ce qui est nécessaire pour garantir la cohérence du référentiel. La visualisation du contenu du référentiel depuis «Visual Paradigm» peut, quant à elle, se faire par le biais d un menu appelé «Module Explorer». La notion de répertoire permettant de regrouper, séparer des éléments est quant à elle reproduite en créant des package dans le «Module Explorer» /29

12 5.2.2 Diagramme comparatif des référentiels Structure du référentiel d «Oracle Designer» reprise de [WEB-SPA-10] Référentiel Projet Projet Répertoire Espace de travail Répertoire Répertoire Projet = Objet Structure du référentiel de «Visual Paradigm» définie pour ce travail fichier.vpp Modèle Package Package Projet Package Modèle = Objet 6 6 [WEB-SPA -10] Le diagramme se base sur une image trouvée dans cet article décrivant l architecture du référentiel d «Oracle Designer» et à été reproduit pour effectuer la comparaison avec «Visual Paradigm» /29

13 5.2.3 Utilité dans le projet L utilisation d un référentiel me permet d assurer que les modifications apportées sur un objet sont répercutées pour toutes les représentations graphiques du référentiel. Par exemple, imaginons le cas ou mon plugin ajoute une colonne sur une table. Cette modification sera reproduite sur tous les diagrammes qui possèdent une représentation de cette table. Ce fonctionnement me garantit donc une cohérence des objets et de leurs représentations. L autre avantage vient du fait que lors de la création d une représentation, il suffit de glisser un élément du référentiel sur un diagramme pour avoir sa représentation. On évite ainsi d avoir à recréer à chaque fois les éléments. 5.3 Marquage Description Le standard «UML» définit deux types de customisation d éléments qui sont les Stéréotypes et les Tags. Ces customisation sont réalisables à l aide de «Visual Paradigm». Les Stéréotypes peuvent typiquement être utilisés pour regrouper des éléments dans une famille, par exemple dans le cadre de ce travail, il a été défini que les tables constituant un «MLD» devrait toutes porter le Stéréotype «MLD». Finalement un ou des Tags peuvent être entrés sur un élément pour lui ajouter des informations sous la forme d un nom et d une valeur associée Exemple de «User Defined Tag» /29

14 Exemple de Stéréotypes Utilité dans le projet La méthode qui a été retenue pour ajouter des informations sur des tables dans «Visual Paradigm» sont les Tags. Ceux appelés «User Defined Tag» me permettent de proposer à l utilisateur de préciser des informations supplémentaire sur une table et donc, dans mon cas, de communiquer avec le plugin certaines informations que seul l utilisateur du plugin possède /29

15 6. Java 6.1 Gestion des exceptions Description 7 Les exceptions en Java permettent de signaler un problème apparu lors de l exécution ou de la compilation d une application. Le principe de base est qu une exception va être lancée à l emplacement qui pose problème, cette action s appelle un «Throws». Cette exception va alors remonter dans le code des appelants jusqu'à ce qu elle soit attrapée par un bloc appelé «Catch». Une fois qu une exception à été attrapée, il faut alors prendre les mesures nécessaires telles que par exemple loguer le message d exception, l afficher à l utilisateur ou encore lancer une action corrective. Une méthode qui peut lancer une exception devra donc, soit posséder un bloc permettant de l attraper et de la traiter, soit définir dans sa signature le type d exception qu elle peut lancer. Les méthodes appelantes voient cette information et doivent à leur tour, soit avoir un bloc permettant de traiter l exception, soit définir à nouveau dans leur signature le type d exception pouvant être lancé. Il existe dans Java plusieurs types d exceptions qui peuvent être levées lors du déroulement d une application. Les «Error» et les «Runtime Exception» n ont pas besoin d être déclarées comme étant «Throws» dans la signature des méthodes alors que les autres doivent être déclarées «Throws» ou être capturées «Catch» dans la méthode. 7 [WEB-ORA-06], [WEB-EXC-01], [WEB-EXC-02], [WEB-EXC-03] [DOC-MWA-01] /29

16 Diagramme des classes d exceptions Throwable (Checked) Error (Unchecked) Exception (Checked) Runtime Exception (Unchecked) Exemple : NullPointerException, ArrayOutOfBoundException Exception personnalisé (Checked) Exemple : IoStereotypeException, NoModelException Exception Java API (Checked) Exemple : SQLExeption, IOExeption De manière générale, les «Checked Exception» doivent être attrapées et un traitement approprié doit être effectué. Ce type d exception est en quelque sorte les exceptions que l on s attend à voir survenir. Les «Errors» (Unchecked) représentent une erreur grave pour laquelle le programme ne devrait normalement pas se rétablir de lui-même. Les «Runtime Exception» (Unchecked) représentent normalement des erreurs de programmation. Il existe plusieurs Pattern pour gérer de manière correcte des exceptions : 1. Le Pattern «Let Exception Propagate» définit qu il faudrait laisser les exceptions remonter dans notre code pour éviter qu une méthode métier de bas niveau ne doive s occuper, par exemple, d afficher des messages d erreur dans l interface utilisateur. 2. Le Pattern «Catch What You Can Handle» définit qu il faut attraper seulement les exceptions que l on sait traiter correctement. Par exemple, il ne faudrait pas récupérer une exception provenant de la base de données dans une classe qui ne sait pas comment effectuer un «Rollback» ou une fermeture de la connexion. 3. Le Pattern «Name The Problem Not The Thrower» définit qu il faut nommer une exception selon le problème auquel elle est liée plutôt que l endroit où elle a été lancée. Par exemple une exception «NoPkException» donne déjà beaucoup d informations alors qu une exception «MethodeInsertException» ne nous aide pas à savoir quel a été le problème /29

17 Il existe encore beaucoup d autres Pattern d exceptions qui peuvent être utiles pour mettre en place une gestion correcte des exceptions. Tous ne sont toutefois pas listés ici car ils n ont pas été utilisés dans ce projet Utilité dans le projet Les exceptions sont principalement utilisées pour dans mon plugin pour définir les différents problèmes qui peuvent survenir durant l exécution et pour pouvoir prendre les mesures appropriées à la gravité de chaque exception. J ai également utilisé ce mécanisme pour avertir l utilisateur qu il n utilisait pas mon plugin de manière correcte /29

18 6.2 Gestion de fichiers Description 8 La classe «File» est utilisée en Java pour représenter le chemin d un fichier ou d un répertoire. La classe «FileWriter» permet, en prenant en argument une instance de la classe «File», d écrire un flux de caractère dans un fichier existant ou de le créer. La classe «StringBuffer» est utilisé en Java pour créer des séquences de caractère de manière dynamique. Cette classe peut être utilisée dans un environnement multithread. Un «StringBuffer» possède une certaines taille à sa création qui est automatiquement agrandie quand il est rempli Diagramme des classes de gestion de fichiers Object File Writer OutputStreamWriter FileWriter Utilité dans le projet La classe «StringBuffer» me permet de stocker les scripts que je génère. Les classes «File» et FileWriter me permettent d écrire dans des fichiers les scripts contenus dans mes «StringBuffer». Les «StringBuffer» utilisés dans le projet sont pour la plupart construits avec une taille par défaut que j ai définie qui leur permet d éviter d avoir à trop s auto agrandir. 8 [WEB-ORA-01], [WEB-DVZ-03] /29

19 6.3 Pattern de persistance et de création Description 9 Java Enterprise Edition «J2EE» définit un certain nombre de Pattern qui permettent de recenser les bonnes pratiques de programmation en Java. Le Pattern «Data Access Object» fait partie de ce catalogue. Son objectif est de définir, dans le cadre du développement d une application Java, une méthode de séparation par couche de la logique de persistance des autres types de logiques que sont, la logique de services, la logique métier et applicative et la logique de présentation. Le but de cette séparation est de pouvoir ainsi rendre l application indépendante du système de persistance utilisé. Le changement ou la modification de notre système de persistance, par exemple le passage d une base de donnée «Oracle» à une base de donnée «SQL Server», se fait ainsi effectué beaucoup plus facilement. En effet, notre couche contenant la logique de persistance est la seule partie de code qu il faudra adapter, le reste du code pourra lui être conservé. Le Pattern «Data Access Object» est généralement utilisé avec un Pattern de création. Un Pattern de création définit une méthode permettant de simplifier le processus de création, instanciation d objet. Le Pattern de création qui nous intéresse, ici «Factory Method», est tiré d un livre écrit par le «GoF» qui définit 23 Patterns. De manière résumée, l utilisation de ce Pattern va nous permettre d éviter d avoir à instancier nous-mêmes les objets dont on a besoin. Concrètement, il faudra faire appel à une fabrique abstraite d objet qui pourra elle-même instancier une fabrique concrète qui elle saura comment instancier les objets finaux Diagramme de classe d une Factory Method Utilité dans le projet Les Patterns de persistance et de création présentée ci-dessus ont été utilisé pour mettre en place l architecture de mon application. L objectif est de la plus souple, adaptable et surtout d utiliser des principes testé et reconnu. 9 [WEB-DVZ-01], [DOC-CBA-03] 10 Diagramme reproduit depuis [WEB-DVZ-01] /29

20 7. Base de données relationnelles 7.1 Transactions Description Une transaction est un ensemble de modifications effectuées sur des données. Pour être correcte, une transaction doit respecter quatre caractéristiques principales qui sont, l atomicité, la cohérence, l isolation et la durabilité. L atomicité définit qu il faut pouvoir valider entièrement les opérations effectuées ou au contraire les annuler entièrement en cas de problèmes. La cohérence définit qu il faut que, en tout temps, au cours d une transaction, la base soit dans un état cohérent. L isolation définit qu il faut protéger les données par le biais de verrouillage pour éviter qu une transaction travaille avec des données qui ont changé ou qui n existe plus. La durabilité définit qu à la fin d une transaction les changements effectués ou rejetés doivent être durables Utilité dans le projet Ce principe est important car lors de l utilisation de mon plugin, les «APIs de tables» générées vont effectuer des actions au milieu des transactions et ne doivent pas interrompre ou perturber la transaction. De même, dans le cas ou quelque chose se passait incorrectement, il est très important que la transaction soit correctement annulée /29

21 8. Oracle 11g 8.1 PL/SQL Description Le PL/SQL est un langage propriétaire à Oracle. L objectif de ce langage est d enrichir le langage SQL avec des fonctionnalités de programmation procédurale. Seules les notions qui sont utilisées de manière spécifique à ce projet, et qu il me semblait important de préciser, ont été expliquées. Les autres concepts tels que la notion de procédures, fonctions, boucle condition, ne seront pas expliqués car communs à beaucoup d autres langages de programmation Packages PL/SQL Description Un package PL/SQL est un ensemble de procédures, fonctions, déclarations de variable, définition de type, définition d exception répartis dans une spécification et un corps de package. Une fois défini, un package est ensuite compilé et stocké dans une base «Oracle» pour pouvoir être appelé à tout moment. De manière générale, la spécification du package va contenir les éléments qui pourront être accédés de manière public, tels que la signature des procédures et des fonctions alors que le corps du package contient l implémentation des spécifications ainsi que des possible procédures internes Utilité dans le projet Le principe des packages va me permettre de regrouper tous le code relatif à une «API de tables» au même endroit et de le stocker dans la base de données. Un autre avantage apporté par les packages est qu une fois un canevas de package établi, seuls certains éléments, tels que le corps des procédures ou la définition des types personnalisés, vont changer d un package à l autre. Les «APIs de tables» sont donc toutes stockées de manière similaire ce qui facilite leur création et leur utilisation /29

22 8.1.3 Trigger Description 11 Un trigger est un déclencheur auquel on peut associer du code. L apparition de l évènement associé au déclencheur va lancer l exécution du code contenu dans le trigger. De manière générale, les évènements pouvant être associé à un trigger sont : Les évènements DML (commande INSERT, UPDATE, DELETE) Les évènements DDL (commande CREATE, ALTER, DROP) Les évènements utilisateur (Login, logoff) Les évènements système (démarrage de la base de données, message d erreurs système) En fonction du type d évènement qui les déclenche, les triggers sont catégorisés en plusieurs familles qui sont : Les triggers déclenché par des ordres DML/DDL sur des tables. Les triggers «INSTEAD OF» qui interceptent des ordres passés sur des vues. Les triggers déclenchés par des évènements systèmes. Un trigger peut s exécuter pour chaque ligne impactée par l évènement ou pour la commande dans son ensemble. Ces deux types sont appelés «Row Trigger» ou un «Statement Trigger». Il est également possible de définir si le trigger doit se déclencher avant ou après l évènement qui lui est associé. L avantage des triggers qui ne se déclenchent qu une fois pour une requête est qu ils consommeront moins de ressources dans le cas d une requête impactant un grand nombre de lignes. A l intérieur du trigger, il est possible d accéder aux anciennes valeurs d avant l évènement déclencheur du trigger ou aux nouvelles valeurs d après l évènement déclencheur du trigger. Cette fonctionnalité est toutefois dépendante du type de trigger utilisé, puisque il ne sera par exemple pas possible dans un trigger s exécutant après un évènement d accéder aux valeurs d avant l évènement. Au sein du code d un trigger, il faut faire particulièrement attention à prendre en compte le fait qu un trigger se trouve par définition au sein d une transaction et qu il faut donc en respecter les principes généraux. De plus, il faut éviter le risque de créer une boucle ou des triggers s appellent mutuellement et qui pourrait mettre à mal notre base de données Utilité dans le projet Les triggers vont nous servir de point d entrée des «APIs de tables». Ce sont eux qui vont fournir aux «APIs de tables» les informations nécessaires sur les données impactées par l évènement déclencheur du trigger. 11 [WEB-DVZ-02], [WEB-ORA-01], [WEB-ORA-02], [WEB-ORA-03] /29

23 8.2 Audit Description 12 L audit est le fait de permettre d observer et de surveiller les actions effectuées sur une base de données. Ces évènements peuvent être de type : Les évènements DML (commande INSERT, UPDATE, DELETE) Les évènements DDL (commande CREATE, ALTER, DROP) Les évènements système (Login, logoff) Oracle 11g possède un système d audit qui permet de définir quelle table, colonne, utilisateur doit être audité. Les outils à disposition sont une commande «AUDIT» pour un audit simple ou l utilisation du package «DBMS_FGA» pour un audit plus pointu, basé sur définition créé par l utilisateur. Les informations d audit seront alors stockées dans des vues sur lesquelles il est possible d effectuer des requêtes pour en voir le contenu. Les trois vues principales sont : «DBA_AUDIT_TRAIL» «DBA_FGA_AUDIT_TRAIL» «DBA_COMMON_AUDIT_TRAIL» Les informations que l on peut généralement trouver dans ses vues sont de manière non exhaustive, le nom de l utilisateur ayant effectué une action, la date, le schéma de l objet impacté, le nom de l objet, le type de commande qui a été exécuté, un id de transaction Utilité dans le projet L objectif de l audit dans mon «API de table» est de pouvoir stocker des informations d audit directement dans des champs dans la table auditée et non pas dans une vue. Ces informations seront donc plus facilement et rapidement accessibles et pourront être utilisé pour effectuer des sélections plus précises. Un autre avantage vient du fait que la création et l alimentation de champs sur une table est un principe qui peut être mis en place quel que soit la base de données, alors que si l on utilise des fonctionnalités d audit propre à Oracle 11g, il devient impossible de changer de base de données. 12 [WEB-AUD-01], [WEB-AUD-02], [WEB-AUD-03], [WEB-ORA-04] /29

24 8.3 Journalisation Description La journalisation est le fait de garder une trace des actions effectuées et de l évolution des données sur une base de données. En plus de cela, des informations d audit peuvent être ajoutées telles que le nom de l utilisateur ayant effectué l action ou la date à laquelle il l a effectué. Oracle 11g possède de base un système de journalisation appelé les fichiers «REDO LOG». Ce système fonctionne au moyen de fichiers de log qui se remplissent au fur et à mesure des actions effectuées sur la base. Une rotation entre les fichiers s effectue dès qu un fichier est plein. Il est obligatoire pour une base «Oracle 11g» de posséder au minimum 2 fichiers «REDO LOG». Plutôt que de remplacer les anciens fichiers de log, il est également possible de les archiver au fur et à mesure. Ces fichiers sont consultables au moyen d outils tel que «LOGMINER» et peuvent donc servir à effectuer une restauration de l état d une base de données à une date ultérieure. Toutes les actions effectuées sur la base sont journalisées de manière séquentielle dans ces fichiers Utilité dans le projet Mon plugin va mettre en place une solution personnalisée de journalisation. L objectif est de permettre de définir précisément quelle table et quelle informations sont journalisées. De plus, le stockage de ces informations de journalisation est effectué dans une table plutôt que dans un fichier de log, ce qui rend l utilisation de ces informations bien plus facile à consulter et utiliser. Comme pour la fonctionnalité d audit, et dans le cas où le plugin devrait être complété pour fonctionner sur un autre système de base de données, le fait de ne pas avoir utilisé les outils spécifique à «Oracle 11g» mais d avoir au contraire développé une solution spécifique rendra cette adaptation plus facilement réalisable. 8.4 Clé primaires Description La notion de clé primaires est un des fondements des bases de données relationnelles. Ce mécanisme consiste à imposer une contrainte d unicité pour permettre de retrouver un enregistrement d une table. Une clé primaire peut être définie sur un ou plusieurs champs de la table mais devra dans tous les cas être unique. Dans Oracle l alimentation, des valeurs de clé primaires devraient être effectuées par le biais de «Trigger» déclenchant des «Séquences». Une alimentation manuelle est possible mais le risque de se retrouver avec des valeurs incohérentes est grandement augmenté Utilité dans le projet Comme expliqué précédemment, une «API de tables» possède des triggers se déclenchant avant et après les ordres lancés sur une table. Il est donc tout à fait envisageable de gérer cette problématique des clés primaires dans une «API de tables» pour éviter d avoir à créer des triggers ne s occupant que de ça /29

25 8.5 Exceptions «Oracle» Description Il existe de manière générale deux types d exception dans Oracle. Les exceptions définies en interne et les exceptions définies par l utilisateur. Les exceptions définies en interne sont levées automatiquement par le système quand l erreur associée est levée alors que les erreurs définies par l utilisateur doivent être levées au moyen de la commande «RAISE» Utilité dans le projet Lors de l utilisation de mes «APIs de tables» il faut que toutes les erreurs, alertes, informations importantes qui ont été déclenchées en cours d exécution soit interceptées, traitées, puis retransmises à l appelant /29

26 9. Oracle Designer 9.1 APIs de tables Description 13 Une des fonctionnalités qui était offerte par «Oracle Designer», en plus de générer des formulaires des modules et des interfaces, est de générer des «APIs de tables». Une «API de tables» est un package contenant du code PL/SQL et des triggers spécifiques à une table. L objectif de ce package est alors d intercepter les requêtes d insertion de modification et de suppression lancées sur une table et d effectuer un traitement avant ou après ces requêtes. De manière plus détaillée, une «API de tables» est composée premièrement de triggers se déclenchant avant et après une insertion, une modification ou une suppression d une ligne, ou d un groupe de lignes. Deuxièmement, d un package composé d une entête et d un corps de package, contenant des procédures de base qui sont appelées par les triggers. Dans l entête de package, il y a, en plus de la signature des procédures, la déclaration d un «Record» servant à contenir les informations de la ou des lignes concernées par la requête et la déclaration d un «Record» qui permet à l aide de valeur «booléenne» de savoir quelle colonne de la table a été modifiée. Ces procédures de bases sont une procédure, appelée lors d une insertion, d une modification, et d une suppression, une procédure chargée de verrouiller une ligne et finalement une procédure chargée de sélectionner une ligne. En plus de cela, suivant la configuration de «Oracle Designer», une procédure se chargeant des colonnes auto générées telles que les colonnes de clé primaires et une autre se chargeant de journaliser sont créées. Il y a de manière générale deux utilisations possibles à une «API de tables». La première est de faire appel directement aux procédures de base sans passer par les triggers. La deuxième est d effectuer des requêtes de manière habituelle sur les tables ce qui va déclencher les triggers qui vont eux se charger d appeler les bonnes procédures. En plus de cela, un mécanisme de gestionnaire d exceptions permet de gérer les exceptions de manière centralisée et de les afficher correctement. Le but d une «API de tables» est d effectuer des contrôles et des traitements au niveau de la base de données sur les requêtes exécutées sur une table Utilité dans le projet L objectif de mon travail sera de reproduire de manière la plus complète possible ce que «Oracle Designer» permettait de faire avec ces «APIs de tables». Seule la manière d utilisation passant par les triggers est conservée car l appel direct aux procédures n a de sens que dans un environnement entièrement propriétaire. De ce fait, les procédures de sélection et de verrouillage n ont plus d utilité puisque les verrous et la sélection aura eu lieu avant le déclenchement de l «API de tables», lors de l exécution de la requête. 13 [WEB-SPA -07], [WEB-SPA -08], [WEB-SPA -11] /29

27 9.2 Trigger logique Description La notion de trigger logique d «Oracle Designer» représente en fait des bouts de code (procédures ou appel à des procédures) qui s intègrent dans les «APIs de tables» à des emplacements précis. Ces emplacements sont définis avant et après les principaux traitements des «APIs de tables». Typiquement, un emplacement, avant et après la procédure déclenchée lors d une insertion, est prévu. Ces bouts de code son appelés trigger logique car comme un trigger, ils vont déclencher un traitement avant ou après un quelconque évènement Utilité dans le projet L utilisation des triggers logiques me permet d avoir un mécanisme de personnalisation 14 des «APIs de tables». La seule condition d utilisation qu il faudra respecter est que le code du trigger logique ajouté soit correct au risque de rendre l «API de tables» inutilisables. 14 [DOC-SPA-06] /29

28 10. Développement logiciel 10.1 Dénormalisation Description Pour expliquer le principe de la dénormalisation, il faut déjà rappeler en quoi consiste la normalisation 15. Dans le cadre de la modélisation des données pour une base de données relationnelle, la normalisation est le faite d essayer d éviter d avoir de la redondance et des dépendances incohérente entre nos tables. Lors de la création de modèle relationnel et dans le but de pouvoir mesurer la qualité de la normalisation mise en place, plusieurs niveaux ont été définis. Ces niveaux ajoutent chacun de nouvelles contraintes et sont faits de telle manière que respecter un niveau supérieur amènera forcément à respecter les niveaux inférieurs. La dénormalisation découle de l utilisation des modèles relationnels créés en respectant les principes énoncée ci-dessus. En effet, dans bien des cas notre modèle relationnel respectant les formes normales sera certes correct au niveau de la modélisation mais pausera certains problèmes de performances. Une adaptation au cas par cas des points clé qui posent des problèmes s avère donc souvent obligatoire. Typiquement ce type de problèmes peut survenir quand un calcul doit être effectué avant de pouvoir répondre à une requête ou encore quand les requêtes les plus souvent exécutées sur notre système passent par un grand nombre de jointures avant de pouvoir retourner l information voulue. Il existe quatre manières principales d effectuer une dénormalisation 16 : Le partitionnement horizontal Le partitionnement vertical La fusion de tables La dénormalisation de colonnes Comme le document [DOC-SPA-06] 17 l explique, Designer permet plusieurs méthodes pour effectuer une dénormalisation de colonnes. Ces méthodes sont la dérivation, la dénormalisation et la création de code personnalisé. 15 [WEB-WIKI-02] 16 [WEB-SAP-01] 17 [DOC-SPA-06] /29

29 Utilité dans le projet Dans le cadre d une dénormalisation de colonnes il est tout à fait envisageable d utiliser mes «APIs de tables» pour mettre en place une fonctionnalité permettant d alimenter et de tenir à jour la colonne dénormalisée (par exemple un champ dupliqué). Seul la technique permettant de dénormaliser par le biais de code personnalisé a été conservé car c est la seul manière de faire qui permet de n être appliqué que sur un certain type d opérations telles que les insertions et non pas sur tous les types d opération. Le désavantage cité dans le document [DOC-SPA-06] de cette technique est qu à la différence des deux autres, rien n est automatisé si ce n est que le code personnalisé sera automatiquement placé au bon endroit. Pourtant ce n est, selon moi, pas vraiment un problème puisque la dénormalisation est par définition un cas particulier. Le fait que ce processus ne soit pas automatisé n est donc pas particulièrement pénalisant Contraintes métier Description Lors du développement d une application basée sur un modèle de données, il est indispensable pour assurer l intégrité et la qualité des données, de mettre en place certaines contraintes sur les données pouvant être insérées dans la base de données. Ces contraintes peuvent être de différents types, tels qu une vérification des valeurs insérées, un formatage des données dans un format particulier ou encore l ajout automatique d informations. De manière générale ces contraintes peuvent être implémentées soit au niveau de chaque application utilisant le modèle de données soit directement dans la base de données elle-même Utilité dans le projet Les contraintes métiers implémentées au niveau de l application ne nous concerne pas pour ce travail car elles sont écrites dans le langage de l application et spécifique à chaque développement. En revanche le plugin développé permet à l utilisateur d insérer dans une «API de tables» une contrainte qui sera implémentée directement dans la base de données. Étant donné que les contraintes métier sont par définition spécifiques à l environnement métier de l utilisateur et au développement de chaque application, il n est pas possible de toutes les prévoir. C est pourquoi le mécanisme mis en place doit permettre à un développeur de spécifier ces contraintes par lui-même /29