En tant que spécialistes System i, nous savons fort bien que les accès base de données « classiques » y perdurent encore, même dans certains nouveaux développements. D’une part car adopter SQL induit des changements d’habitudes chez certains développeurs et d’autre part parce qu’il génère de nouvelles contraintes de développement.

Pour autant l’adoption de SQL est devenu un point de passage obligé dans l’évolution des techniques de développement. Avec l’avènement des développements multi-plateformes et l’arrivée de jeunes développeurs dans les entreprises, la question du choix ne se pose plus.

Les solutions ARCAD vont pouvoir vous aider en absorbant au maximum ces nouvelles contraintes de développement et en rendant le travail du développeur aussi simple qu’avant.

POURQUOI?...

Pourquoi adopter le langage SQL comme standard de manipulation des bases de données? 

SQL est un standard unique
Au même titre que TCP/IP s’est imposé comme l’unique standard dans le monde des réseaux, SQL n’a et n’aura pas de rival. C’est un standard mondial, reconnu par tous les acteurs du métier, sans exception. Avec les nouveaux outils en périphérie des applications, dans le domaine du Business Intelligence ou de l’EAI (Enterprise Application Integration), il a étendu encore son rayonnement dans le SI.

SQL est un langage de convergence
A l’heure où des développeurs de cultures très différentes se côtoient, il est nécessaire d’avoir des langages communs pour mieux se comprendre. S’il est incongru de penser qu’un jour les développeurs ne manipuleront qu’un seul et unique langage de programmation, on peut, grâce à SQL, au moins leur faire partager sans souci le même langage d’accès base de données. Au même titre qu’IBM a réussi à faire converger ses environnements de développement RPG/Cobol et JAVA, grâce au socle Eclipse, SQL est une autre brique technique « qu’anciens » et « modernes » peuvent mettre en commun. SQL est plus performant que les accès classiques. C’est un fait aujourd’hui et c’est tout à fait logique. Depuis le temps qu’IBM s’évertue à faire rentrer toutes les technologies les plus récentes et les plus performantes autour de ce standard au cœur même de la plateforme System i, il est cohérent d’en arriver à ce résultat. Bien utilisé, SQL est un langage parfaitement adapté pour traiter de très gros volumes de données, c’est là que pêchent les accès « classiques ».

SQL est un langage facilement maintenable
Il produit un code très concis et facilement adaptable. Les accès, même les plus complexes peuvent s’écrire en quelques lignes. La compréhension du code est aisée. A l’heure où les systèmes d’informations doivent évoluer de plus en plus vite, on a réellement besoin d’une telle flexibilité dans le code.

LES BASES DE DONNEES SUR SYSTEM I...

Le system i implémente la notion de base de données de façon relativement originale : il n’y a qu’une seule réelle base de données pour l’OS/400 ; la notion de collection correspond uniquement à une vue sélective (par schéma = bibliothèque) de celle-ci.
Ainsi, l’OS a pu concilier la notion de fichier DDS physique (PF), logique (LF) et les rendre également disponibles dans la base de données, en même temps que toutes les tables, vues, etc.

Le méta-langage SQL de description de base de données pour DB2/UDB peut être :

• saisi intégralement sous STRSQL,
• enregistré dans des membres sources et exécuté par RUNSQLSTM,
• constitué avec l’aide de System i Navigator,
• récupéré/exécuté depuis des outils de modélisation de base de données tels que Rational Software Architect, PowerAMC ou ERWin,
• …

Il permer de définir les « fichiers » par des types de données, tables, index, vues.
Afin de placer le maximum de règles de gestion au niveau de la base de données, on y définit également :

• des contraintes de clé, de vérification et les contraintes référentielles entre tables,
• des déclencheurs sur les actions d’ajout, modification, suppression (et même lecture) pour les enregistrements de tables (ou au niveau zone),
• des procédures stockées et des fonctions utilisateurs (traitements appelables depuis SQL),
• …

Une particularité de le System i est de permettre que des déclencheurs « systèmes » délèguent leur traitement à des programmes non SQL (RPG, COBOL, etc.). De même, les procédures stockées et les fonctions peuvent aussi servir de protocole d’appel à des programmes natifs (ou des procédures ILE).
L’accès aux données en SQL encapsulé à l’intérieur de programmes natifs (RPG, COBOL, …) est devenu une alternative à l’utilisation des ordres spécifiques à chacun de ces langages pour les accès aux fichiers (fichiers classiques PF-LF ou Tables, vues).
Ceci permet notamment d’utiliser une méthode unique d’accès aux fichiers, partagée par tous les développeurs (qu’ils soient issus de l’AS/400 ou des nouvelles technologies).

SQL est un langage standard. Mais toutefois, il comporte des spécificités pour chaque type de bases de données, qu’il faut éviter d’utiliser si l’on souhaite une portabilité complète vers d’autres plateformes.

APPLICATIONS  AVEC DU SQL...

Pour les applications comportant du SQL embarqué et/ou des bases de données en DB2/UDB, ARCAD-Skipper permet de :

Fournir des références croisées

• pour les utilisations de fichiers (et leurs zones) par SQL depuis le SQLRPG(LE), SQLCBL(LE), mais aussi depuis des sources IFS (Java, VB, Delphi, …) lorsque ceux-ci accèdent aux bases de données sur le System i via JDBC, ODBC, …
• depuis les déclencheurs de type « système » vers les programmes L3G appelés,
• depuis les procédures stockées ou fonctions « système » vers les programmes L3G appelés,
• entre les tables possédant des contraintes référentielles,
• entre les sources SQL des tables, procédures stockées, fonctions vers les fichiers utilisés ou les procédures stockées/fonctions appelées.

Apporter la méthodologie pour la maintenance d’une base de données en version

Sans outil, il est bien plus facile de livrer la première fois une base de données complète que, plus tard, de livrer des ajouts/modifications/suppressions de tables, vues, procédures, … sur une base de données existante.

Pour cela, ARCAD a choisi de gérer des composants (source + objet) de type :

• TABLE (avec ses zones, ses clés, ses contraintes et ses déclencheurs),
• INDEX,
• VIEW,
• SQLUDT (types de données),
• SQLPRC (procédures stockées) (*),
• SQLUDF (fonctions utilisateurs) (*),
• SQLSEQ (séquences = compteurs),

Chaque source permet de créer/recréer l’objet, par une compilation. Tous ces sources peuvent être récupérés depuis les objets d’une base de données existant déjà.
Dans une version, on peut choisir de modifier juste quelques composants DB2, ou bien d’effectuer des modifications importantes sur une base de données.
Ces modifications peuvent être effectuées sur les sources ou directement sur les objets. (sous contrôle d’ARCAD ou non).

Dans les deux cas, ARCAD détecte ensuite le delta des ajouts/modifications/suppressions et les incorpore à la version (en comparant les objets de référence à ceux éventuellement modifiés).
Le contrôle global de la version s’assure de la cohérence source/objet.

Pour transporter ces composants modifiés lors de mise en test, production ou distribution sur des sites/clients, on peut choisir :

• de transporter les sources puis de recompiler,
• ou de transporter directement tous les objets nécessaires.

A l’installation :

• les données existantes sont préservées,
• les contraintes vers une table livrée sont aussi préservées.

Pour les compilations, une étude des sources détermine automatiquement le bon ordre de compilation, en cas de dépendance entre tables, entre vues.
Le système de Rollback ARCAD prend en compte tous ces types d’objets.
Des déclencheurs de substitutions gérés par ARCAD permettent de faciliter la maintenance et les surtout les tests (dans une version) de programmes L3G, quand ils sont appelés depuis des déclencheurs systèmes posés sur des tables, sans nécessiter de modifier la table.

(*) avec un objet « virtuel » si procédure stockée ou fonction « système»

AVANTAGES...

Avec ARCAD-Skipper, vous allez pouvoir :

• Faciliter un passage en douceur vers l’adoption de ce standard de fait,
• Augmenter la productivité de vos développements, en automatisant la « logistique » d’évolution de votre code SQL,
• Sécuriser vos upgrades de bases de données,
• Automatiser les mises en production de vos composants SQL, au même titre que n’importe quel autre type de composants.