Designer et l ingénierie du logiciel Les APIs de tables pour garantir l intégrité des données

Transcription

1 Designer et l ingénierie du logiciel Les APIs de tables pour garantir l intégrité des données P.-A. Sunier, ISNet Neuchâtel avec le concours de C. Kohler et P. Ferrara 1 Introduction Le concept Les applications Oracle Les applications tierces Bi-polarité d utilisation Structure de code Paquetages Triggers Appel de la requête SQL-DML depuis les procédures Appel des procédures d APIs depuis les triggers d APIs Exemples de services offerts Génération de valeurs de colonnes Auto-incrémentation de clé primaire Colonnes d audit Journalisation des manipulations Génération Installation Liens utiles Plus d informations Références Introduction Dans le premier article consacré à Designer, Newsletter 2/2003 d avril 2003, sous le titre Notions élémentaires, nous avons présenté les concepts de Designer sur la base d une approche d ingénierie du logiciel alliant méthodologie, normalisation et standardisation, qualité et réutilisation. Nous avons décrit succinctement les générateurs de scripts SQL-DDL et d APIs de tables. Dans le troisième article, Newsletter 4/2003 de novembre 2003, sous le titre Modélisation de l intégrité des données, nous avons présenté la modélisation de règles métier et de l intégrité de données en tant que contraintes d intégrité aux niveaux conceptuels et logiques. Dans cet article, nous expliquerons le concept des APIs de tables, nous présenterons quelques exemples de services qu ils offrent pour garantir l intégrité des données et donnerons quelques explications sommaires quant à leur génération. Dans nos prochains articles, nous détaillerons la structure et la dynamiques des APIs de tables et nous étudierons l incidence des spécifications du référentiel sur le code généré par les générateurs de scripts SQL-DDL et d APIs de tables. Remarque: La lecture des articles précédents n est pas impérative à qui veut simplement comprendre ce que sont les APIs de tables. Article 4-1/12- Août 2005

2 2 Le concept 2.1 Les applications Oracle Les APIs de tables sont des paquetages PL/SQL invoqués par les applications clientes Oracle (Form, Web PL/SQL) pour exécuter des manipulations de données sur les tables. Les applications clientes Oracle n envoient pas directement de requêtes SQL-DML (INSERT, UPDATE, DELETE) de manipulations de tables mais, elles passent par l appel de procédures offertes par les APIs de tables. A chaque table est associée un paquetage PL/SQL ; chaque paquetage contient des procédures et fonctions PL/SQL permettant de réaliser les opérations de base, à savoir : Insérer un nouvel enregistrement. Mettre à jour un enregistrement. Supprimer un enregistrement. Bloquer (Lock) un enregistrement avant une mise à jour ou une suppression. La finalité des APIs de tables n est pas de remplacer les requêtes SQL-DML (INSERT, UPDATE, DELETE) par l appel de procédures PL/SQL. En fait, les APIs enrichissent ou complètent les contraintes spécifiées par les scripts SQL-DDL de définition des données: ils valident les données qui seront utilisées par les requêtes SQL-DML. Si les données sont correctes et complètes, ils envoient les requêtes SQL-DML ; si les données sont incorrectes, ils envoient un message d erreur à l application cliente appelante et n exécutent pas les requêtes SQL-DML. ils prennent en charge de multiples contraintes usuelles de SII 1 de gestion qui ne sont pas supporté par la norme SQL ANSI-92. Figure 1 - APIs pour les applications Oracle Plus concrètement, les APIs de tables effectuent les opérations suivantes avant d envoyer les requêtes SQL- DML : Validation des colonnes obligatoires. Validation des contraintes de clé primaire, de clé étrangère, d unicité ou encore de check. Validation des arcs (implantation Oracle des contraintes d exclusion entre associations, comme par exemple, un ou-exclusif). Validation de valeurs par rapport à une table de code de référence (reference code tables) Validation de valeurs de domaines. 1 SII : Système d information informatisé Article 4-2/12- Août 2005

3 Auto-génération de valeurs de colonnes : o Valeurs uniques et séquentielles pour les colonnes alimentées par une séquence. o Valeurs pré-définies. o Valeurs dérivées. o Informations d audit de manipulation des enregistrements. Conversion de valeurs de colonnes en majuscule. Maintien d un journal de trace de toutes les manipulations effectuées sur une table. Maintien de valeurs actualisées de colonnes dénormalisées. La liste ci-dessus, n est pas exhaustive ; de plus, le concepteur peut ajouter son propre code dans les APIs de tables pour pouvoir réaliser des contraintes qui ne sont pas prévues par Oracle. 2.2 Les applications tierces Grâce aux APIs, nous disposons de bases de données qui gèrent elles-mêmes l intégrité de leurs données. La qualité des données n est plus liée aux multiples applications clientes qui réaliseront plus ou moins bien les contrôles d intégrité ; la qualité des données ne dépend que de l exactitude du seul code des APIs de tables. Figure 2 - APIs pour les applications tierces Toutefois, cette intégrité n est garantie que si toutes les applications clientes passent par l intermédiaire des APIS de tables pour effectuer les manipulations de données et manifestement ceci n est pas possible, ne serait-ce que le cas d une manipulation directe avec SQL*Plus. Afin que l intégrité soit aussi respectée pour les applications qui font des appels directs aux requêtes SQL-DML, les APIs de tables sont couplés à des triggers. Les triggers associés aux APIs se déclenchent lors de toute requête SQL-DML et redirigent la requête vers les APIs de tables en faisant un appel à la procédure adéquate d insertion, de mise à jour ou de suppression d enregistrement. Article 4-3/12- Août 2005

4 2.3 Bi-polarité d utilisation Les APIs de tables peuvent être appelées par les applications clientes et par l intermédiaire des triggers lors de requête SQL-DML directes selon les choix de réalisation des applications clientes. Figure 3 - APIS pour toutes applications Lors de l appel des APIs par une application cliente Oracle, les APIs effectuent une requête SQL-DML sur la table ; cette requête est aussi interceptée par les triggers! Mais, dans ce cas, les APIs de tables ne doivent pas être appelés. Lors de l envoi d une requête SQL-DML directe, les triggers feront appel aux APIs de tables ; mais, dans ce cas, les APIs de table ne devront pas effectuer de requête de manipulation! Un mécanisme de garde est mis en place pour éviter les appels circulaires que les deux situations décrites pourraient provoquer. Nous reviendrons plus en détail sur ce mécanisme de garde dans un prochain article. Article 4-4/12- Août 2005

5 3 Structure de code Paquetages Pour chaque table, le générateur d APIs crée un paquetage préfixé CG$ ; par exemple, pour une table REPRESENTANTS, il crée un paquetage nommé CG$REPRESENTANTS. Chaque paquetage fournit les procédures de manipulation et de verrouillage d enregistrement. Figure 4 - Procédures fournies par les APIs Les procédures ins() et upd() reçoivent en paramètre la variable cg$rec qui contient l enregistrement à insérer ou modifier ; la structure de cette variable correspond à la structure de la table. La procédure del() reçoit en paramètre la variable cg$pk qui contient la clé primaire de l enregistrement à supprimer ; la structure de cette variable correspond à la structure de clé primaire. Les paramètres do_ins, do_upd et do_del sont les gardes que nous avons présentées au chapitre précédent et qui éviteront les appels circulaires, c est-à-dire, éviter que les APIs se rappellent eux-mêmes Triggers Pour chaque table, le générateur d APIs crée un jeu de trriggers préfixé CG$ ; La figure 5 montre les triggers créés pour la table REPRESENTANTS de notre exemple. Rappel Les 3 lettres précédents le nom de la table ont la signification suivante : 1 ère lettre o B Before ; avant l événement déclencheur o A After ; après l événement déclencheur 2 ème lettre o I - INSERT o U - UPDATE o D - DELETE 3ème lettre Figure 5 - Triggers d'apis o R - for each row, pour chaque enregistrement o S statement, une fois pour l instruction Article 4-5/12- Août 2005

6 3.1.3 Appel de la requête SQL-DML depuis les procédures La figure 6 symbolise l appel de la requête SQL-DML par les procédures des APIs ; la figure 7 illustre cet appel par un exemple. Figure 6 - Requêtes SQL-DML Figure 7 - Procédure d'insertion ins() des APIs La figure 7 montre le code de la procédure d insertion ins() de l API de la table REPRESENTANTS; nous voyons la requête INSERT d insertion de l enregistrement dans la table REPRESENTANTS; nous pouvons aussi observer que cet appel est gardé par la variable do_ins. Article 4-6/12- Août 2005

7 3.1.4 Appel des procédures d APIs depuis les triggers d APIs La figure 8 symbolise le déclenchement des triggers d APIs et l appel aux procédures d APIS ; la figure 9 illustre cet appel par un exemple. Figure 8 Appel des procédures d APIs Figure 9 - Triggers avant insertion des APIs La figure 8 montre le code du trigger CG$BIR_REPRESENTANTS déclenché avant l insertion d un enregistrement de la table REPRESENTANTS. Nous voyons l appel à la procédure ins() des APIs. Nous pouvons aussi observer que cet appel est gardé par la variable called_from_package. Article 4-7/12- Août 2005

8 4 Exemples de services offerts Nous décrivons ci-après quelques services pris en charge par les APIs de tables dans le but d en illustrer le mécanisme par quelques exemples concrets. 4.1 Génération de valeurs de colonnes La génération automatique de valeurs de colonnes se fait par la procédure up_autogen_columns(). Cette procédure est appelée par la procédure ins() que nous avons vu précédemment mais, aussi par la procédure upd() Auto-incrémentation de clé primaire La figure 10 montre le code de génération de valeur de la colonne de clé primaire ; nous voyons que la génération de valeur de clé primaire est déclenchée seulement si l appel est fait depuis la procédure d insertion ; le champ cg$rec.numero est alimenté par le résultat de l interrogation de la séquence REPR_SEQ. Figure 10 - Procédure de génération de valeurs de colonnes Remarque : la valeur du champ NUMERO de la variable cg$rec sera donné à la colonne NUMERO de la table lors de la requête INSERT Colonnes d audit Figure 11 - Génération de valeurs La figure 11 montre le code de génération des colonnes d audit. La colonne CTRLMODATE contiendra la date du serveur à laquelle l opération est réalisée et la colonne CTRLMOUSER contiendra le nom de l utilisateur connecté. Par ailleurs, nous observons que la procédure up_autogen_columns() prend aussi en charge la transformation en majuscule de colonnes. Article 4-8/12- Août 2005

9 4.2 Journalisation des manipulations La journalisation de toutes les manipulations est effectuée par la procédure insert_jn() des APIs qui reçoit en paramètre, l enregistrement à journaliser et l opération (INSERT, UPDATE, DELETE) effectuée. La procédure insert_jn () est appelée par les 3 procédures ins(), upd() et del() de manipulation des données. Figure 12 - Procédure de journalisation des manipulations Remarque : Nous avons reproduit la commande INSERT dans la table de journalisation en deux parties pour en avoir une vision de synthèse ; les deux parties sont tronquées par manque de place. Article 4-9/12- Août 2005

10 5 Génération Les APIs de tables sont créés par le générateur d APIs de Designer à partir des spécifications du référentiel. Le générateur d APIs de tables produit les scripts de création d APIs à partir des spécifications du modèle logique de données, Server Model, tout comme le générateur de scripts SQL-DDL. Figure 13 - Génération des scripts Le générateur de scripts SQL-DDL est capable de produire des scripts de consolidation de la base de données cible ; ces scripts permettent de mettre à jour la base de données cible à partir des spécifications du référentiel sans altérer les tables existantes. Ce mécanisme de consolidation ou de «round-trip engineering», dans les AGL orientés objets, n existe pas pour le générateur de scripts d APIs de tables ; les scripts d APIs de tables (paquetages et triggers) doivent être entièrement re-générés à chaque changement de spécification des tables du modèle logique de données. Article 4-10/12- Août 2005

11 6 Installation Les scripts SQL-DDL de création ou de modification de tables doivent impérativement être exécutés dans la base cible avant l exécution des scripts de création d APIs. Les procédures PL/SQL et les triggers qui forment les APIs de tables réfèrent aux tables qu ils enrichissent ; ils ne peuvent pas être compilés si les tables n existent pas. De même, ils ne peuvent pas être compilés si la structure des tables de la base cible diffère de celle du modèle logique de données, Server Model, à partir duquel le générateur d APIs a produit le code. La figure 14 montre le code de déclaration du paquetage CG$REPRESENTANTS. Nous voyons la déclaration de la variable cg$row qui fait référence à la table REPRESENTANTS. Ensuite, cette variable est utilisée pour créer le type cg$row_type. Chaque membre de cette variable (NOM, SEXE, PRENOM ) est définie par la colonne correspondante de la table REPRESENTANTS; si la table venait à ne pas correspondre à cette structure, la compilation du paquetage ne serait pas possible. Figure 14 - Dépendance entre tables et APIs A chaque modification de structure des tables, il est impératif de réinstaller les paquetages et triggers des APIS de tables modifiées pour garantir leur correspondance avec les nouvelles définitions de tables. Article 4-11/12- Août 2005

12 7 Liens utiles 7.1 Plus d informations Si vous souhaitez plus d informations, notre site consacré à Designer est à votre disposition. Le site Designer contient plusieurs entrées ; nous n avons pas encore publié de documents spécifiques à la version 9i, nos documents les plus récents sont consacrés à la version 6i. Pour plus de détails spécifiques au APIs de tables, nous vous recommandons la lecture du rapport [CK-2003] de C. Kohler daté de 2003 et intitulé : Oracle Designer 9i - Structure de code des APIs de tables. 7.2 Références L auteur Pierre-André Sunier pierre-andre.sunier@he-arc.ch HES-SO Haute Ecole Spécialisée de Suisse occidentale HEG-NE Haute Ecole de Gestion de Neuchâtel ISNet Génie logiciel Site Designer Projet ISNet-14 [CK-2003] Centre de compétences Systèmes d information et informatique de gestion Centres d intérêt du laboratoire de génie logiciel sous la rubrique «Génie logiciel» Notre site de formation consacré à Designer et ses sous-sites Projet de recherche appliquée ISNet-14 Atelier de génie logiciel et génération Web Oracle Designer 9i Structure des APIS de tables /2IGHESEE/KohlerC/index.htm Les anciens articles sont accessibles en Intranet sur le site du SOUG, ou en Internet sur le site de la He-Arc : Article 4-12/12- Août 2005