image

L'IBM i a-t-il besoin de plus de bases de données ?

Il existe de nombreuses différences entre IBM i et les autres plates-formes : stockage, sécurité, modèles de programmation...

Mais l’une des spécificités de la plate-forme IBM i est sa base de données DB2 intégrée. La base de données DB2, utilisée exclusivement par presque la totalité des clients IBM i. Elle n’est pas accessible sur d’autres plates-formes. Mais peut-être est-il temps pour IBM i de diversifier sa prise en charge de base de données ?

À bien des égards, DB2 pour IBM i est le plus grand atout de la plate-forme. IBM i est réputé pour ses capacités de traitement des transactions qui contrôlent l’ERP et d’autres applications métier, mais également pour DB2 (anciennement DB2/400, mais ne prononcez pas ce nom devant Mike Cain), le solide moteur qui gère ces transactions.

Il est théoriquement possible de faire fonctionner un serveur IBM i sans DB2 pour i. Vous souhaitez peut-être diffuser des requêtes HTTP avec une base de données Oracle ou SQL Server séparée tournant sur un serveur X86. Mais pour cela, vous devriez renoncer aux principaux avantages des plates-formes, et ce serait donc contre les lois de la nature informatique. Dans des configurations hétérogènes, fréquentes dans Oracle JD Edwards et SAP Business Suite, le serveur IBM i gère presque toujours la base de données, tandis que les principaux serveurs X86 et leurs systèmes d’exploitation Windows et Linux alimentent l’application et les serveurs HTTP.

Cette identité axée sur la base de données a servi la plate-forme milieu de gamme IBM pendant des décennies. La base de données DB2 pour i est à la fois très mature et très puissante, elle prend en charge les constructions de programmation SQL et DDS et est davantage compatible ANSI SQL que d’autres bases de données relationnelles (tout comme IBM i est paradoxalement davantage compatible avec POSIX qu’avec tous les systèmes d’exploitation Unix, même si ce n’est pas Unix). De plus, DB2 pour i s’améliore à chaque nouvelle version d’IBM i. Alors, pourquoi, IBM i aurait-il besoin de quoi que ce soit d’autre ?

 

Pour les données bien sûr

La réponse la plus courante à cette question serait peut-être que la nature des données elle-même évolue et que, par conséquent, les méthodes de stockage doivent également être modifiées.

Lorsqu’IBM a tout d’abord développé l’AS/400, le stockage (principal et disque) coûtait cher par rapport aux prix pratiqués aujourd’hui, et les entreprises souhaitaient donc minimiser leur stockage. L’architecture de stockage d’IBM reflétait donc cette réalité et, par conséquent, les données écrites sur le disque étaient très précises ou structurées.

Cette emphase mise sur la structuration des données a bien servi l’industrie et un système de gestion de base de données relationnelle (SGBDR) a été développé pour soutenir les processus métier bien définis et exécutés dans les systèmes ERP qui ont fleuri pendant les années 1990.

Mais au fur et à mesure que les années passaient et que les coûts de stockage diminuaient, la nécessité d’optimiser les données et de les structurer pour s’adapter aux petits espaces se faisait de moins en moins ressentir. Vers l’an 2000, nous avons commencé à entendre parler de ce que l’on appelle le langage de balisage extensible (XML) qui ouvrait des perspectives spectaculaires avec nos données et applications en rendant les données autoréférencables, chaque donnée ou document XML se définissait grâce aux métadonnées qui l’accompagnaient et serait accessible par des traducteurs écrits avec un langage extensible de feuilles de style (XLS).

Le XML était censé simplifier considérablement les problèmes posés par l’intégration des données. Mais, pour diverses raisons, cela n’a pas fonctionné. La plus évidente étant la lenteur de l’analyse des documents XML et l’appétit en ressources du processeur des programmes XLS dans un format pris en charge par DB2 pour i. C’était un peu compliqué, particulièrement pour le programmeur RPG traditionnel, adepte de simplicité et de facilité d’utilisation.

Il y a environ 10 ans, au tout début de la révolution du Web 2.0, nous avons commencé à entendre parler de format de données textuelles générique JavaScript (JSON). Comme le XML, le JSON est un format de données auto-défini et semi-structuré. Mais le JSON présente plusieurs avantages par rapport au XML, notamment le fait qu’il soit lisible par l’homme et qu’il soit beaucoup plus rapide à traiter que le XML.

 

La Naissance du NoSQL

Le JSON a largement dépassé le XML en tant que format de données privilégié utilisé sur le Web aujourd’hui. Et il a également stimulé la création d’une nouvelle classe de systèmes de gestion de bases de données non relationnelles, que l’on nomme dans leur ensemble NoSQL. La base de données NoSQL la plus populaire est une base de données orientée documents appelée MongoDB qui stocke les données dans un format de type JSON appelé BSON. Couchbase est une autre base de données NoSQL qui stocke les données dans un format similaire à JSON et qui est très populaire parmi les développeurs.

Bien sûr, le SGBDR domine encore l’industrie. Selon les moteurs DB, la base de données éponyme d’Oracle, MySQL, SQL Server et PostgreSQL – tous les systèmes relationnels – sont les quatre bases de données les plus populaires au monde. Il existe une longue liste de SGBDR installés dans le monde qui alimentent des applications qui coûtent des milliards de dollars à développer. Et elles ne disparaîtront pas de sitôt.

Mais les bases de données NoSQL gagnent rapidement des parts de marché sur de nouvelles applications, en particulier pour les applications Web et mobiles qui sont le ticket gagnant en informatique de nos jours. Les grandes avancées du mouvement NoSQL peuvent être facilement suivies en observant le fait que les développeurs, lorsqu’ils ont le choix, préfèrent programmer leurs applications pour qu’elles soient capables de lire et écrire sur une base de données NoSQL que sur toute autre base de données relationnelle. C’est parce que les bases de données NoSQL, axées sur le stockage des types de données auto-définis, n’ont pas de schéma fixe, ce qui les rend beaucoup plus faciles à modifier et à adapter à une base de données au fil du temps.

Les SGBDR, tout comme DB2, évoluent pour prendre en charge certaines astuces de NoSQL, notamment une évolutivité horizontale et une prise en charge de JSON. IBM est également aux premiers stades de l’ajout de la prise en charge de JSON sur DB2 pour i, ce qui peut être la preuve que mêmes les vieux singes peuvent apprendre de nouvelles grimaces (ou un signe que DB2 pour i n’est tout simplement pas un vieux singe). Le parcours du JSON n’est pas terminé pour IBM et son DB2 pour i, et d’autres fonctionnalités sont attendues avec les prochains Technology Refreshes.

 

Pourquoi d’autres bases de données ?

Bien que DB2 pour i domine l’histoire des bases de données sur IBM i, ce n’est pas la seule base de données officiellement prise en charge sur la plate-forme.

Il y a plus de dix ans, IBM a officiellement accueilli MySQL, une base de données relationnelle open source créée par Monty Widenius, utilisée pour alimenter la majorité des applications PHP, sur sa plate-forme propriétaire, notamment pour valider l’adoption du PHP. Aujourd’hui, en raison du comportement égoïste d’Oracle concernant MySQL – sans parler de l’incompréhensible décision de 2011 d’abandonner la prise en charge MySQL sur IBM i – une autre banque de données Widenius, baptisée MariaDB, a supplanté MySQL partout, y compris sur IBM i.

Cependant, MariaDB et MySQL sont toutes deux des bases de données relationnelles. Bien qu’elles bénéficient du soutien des communautés de développement PHP, Perl et Python et rationalisent ainsi l’adoption des applications écrites dans ces langues sur IBM i, elles ne proposent pas de fonctionnalités de stockage de données radicalement différentes de celles offertes par DB2 pour i.

MariaDB et MySQL sont les meilleurs exemples de bases de données alternatives sur la plate-forme, mais il existe quelques autres projets dont vous n’avez peut-être jamais entendu parler. L’un d’entre eux est le Projet Inuendo créé par Christopher Burns, un développeur IBM i qui vit dans l’État de New York.

Inuendo est une base de données associative pour IBM i conçu pour considérablement simplifier la façon dont les données sont stockées, et donc significativement accélérer le traitement des transactions. Au lieu de construire un schéma de base de données avec des dizaines de tables, d’index et de chemins d’accès interdépendants, la base de données associative simplifie considérablement le schéma, tout en s’appuyant sur un ensemble unique d’identifiants permettant d’accéder aux entités commerciales stockées dans la base de données. Bien que le SQL soit pris en charge, l’accès se fait principalement via un nombre déterminé d’API.

Un autre exemple d’une base de données alternative sur IBM i est la base de données ERROS Connectionist, brevetée il y a plusieurs décennies par Rob Dixon, un développeur IBM i au Royaume-Uni.

Dixon a d’abord développé ERROS pour prendre en charge une application S/38 qu’il développait alors et s’appelait STIPPLE (System for Tabulating and Indexing People, their Possessions, Life and Everything). Elle était initialement conçue pour créer une histoire des beaux-arts. ERROS cataloguait les données sur ces entités de manière à permettre une flexibilité future tout en respectant les autorités et en maintenant des performances élevées.

En tant que base de données « connexionniste », elle est particulièrement adaptée pour définir des relations bidirectionnelles, où « la navigation entre ces [relations] dans les deux sens se fait sans nécessité de langage de requête, et où la capacité de stocker des hiérarchies est presque illimitée, avec des “enfants” capables d’avoir plusieurs “parents”, » déclare Dixon dans IT Jungle.

Plus particulièrement, au lieu de remplacer DB2, comme d’autres bases de données, ERROS peut s’appuyer sur DB2. La « structure de données universelle » au cœur d’ERROS stocke toutes les définitions de données, les définitions d’application et les autorités, ainsi que toutes les données utilisateur, indique Dixon.

« Cela permet un développement incrémentiel, sans spécification détaillée des utilisateurs, sans conception ou normalisation de fichiers physiques, sans SQL et surtout sans codage de programme », écrit Dixon. « Il se trouve que j’ai créé ERROS pour disposer d’un système avancé pour les sciences humaines, mais ERROS est également adapté à la création de grands systèmes Internet dans un environnement commercial, y compris le traitement des transactions ».

 

Les Bases de Données en tant qu’Outils

Tout comme la nature des données, nous générons des changements, et c’est également le cas des données que nous utilisons pour les enregistrer. IBM i a peut-être des atouts pour le traitement des transactions, et cela ne disparaîtra pas de sitôt. Mais une grande partie des données que les organisations veulent stocker aujourd’hui n’est pas de nature relationnelle et ne correspond pas parfaitement à un SGBDR.

IBM fait de son mieux pour s’adapter à ces changements avec DB2 pour i, alors que d’autres, comme MariaDB, proposent une compatibilité de plug-in pour les programmes développés dans des langages open source. De la même façon que le spectre des outils de développement disponibles pour le programmeur s’est développé ces dernières années, le nombre et la variété des bases de données n’a cessé de croître.

À bien des égards, les développeurs choisissent des bases de données – relationnelles ou NoSQL ; ici, une base de données associative ou connexionniste – de la même manière qu’ils utilisaient les outils de développement pour Java, .NET ou PHP. IBM a accompli un travail admirable en intégrant les dernières technologies de développement dans IBM i. Pour rester compétitif dans un univers en perpétuelle évolution, à l’avenir, il devrait être plus facile aux programmeurs de connecter différents types de moteurs de traitement de données à IBM i.

 

Vous avez des questions concernant la base de données DB2 for i ou concernant votre plateforme IBM i ? Alors contactez-nous au 01 88 32 12 34, ou via le formulaire de contact.