Introduction

La migration d’une base de données legacy (par exemple IMS, fichiers VSAM, IDS/II) vers SQL est découpée en deux phases :

  • La première phase est la création de la base de données cible (Oracle, DB2…) qui offre les avantages de systèmes relationnels et permet la migration de données.
  • La seconde phase est la transformation des programmes de l’application afin qu’ils utilisent la base de données cible, sans changer les fonctionnalités.

Pendant un projet de migration, la base de données cible doit être conçue afin que toutes les données source puissent y être migrées. Chez Rever, nous commençons habituellement par modéliser la base de données source et transformons le modèle source pour obtenir la base de données cible. Grâce à la boîte à outils de DB-Main, nous sommes sûrs que la base de données cible peut stocker les données de la source.

Dans ce blog, nous allons expliquer comment une base de données relationnelle (DB2, Oracle…) peut être conçue à partir d’une base de données source. La base de données source peut être IMS, fichiers VSAM, IDS/II et le langage de programmation utilisé pour accéder aux données est COBOL.

Transformation de la structure

Il y a trois types de structures pour lesquels une attention particulière est requise :

  • Traduction des types
  • Transformation des tableaux COBOL (“OCCURS”)
  • Transformation des clauses REDEFINES

La difficulté de la conception est de trouver l’équilibre correct entre une base de données bien conçue (selon les standards en base de données relationnelle) et l’efficacité de l’application legacy qui a besoin d’y accéder.

Transformation du type

COBOL a seulement deux types de données (alphanumérique – PIC X – et numérique – PIC 9), mais les SGBD relationnels (Système de Gestion de Base de Données) en ont beaucoup plus (alphanumérique, varchar, numérique, date, heure, blob, booléen…). La manière la plus simple de traduire le type de données est de traduire “PIC X” comme alphanumérique et “PIC 9” comme numérique. Cette solution présente plusieurs inconvénients :

  • “PIC X” peut contenir des données binaires : certains SGBD ne permettent pas de stocker des données binaires dans des colonnes “char” car elles n’acceptent que des caractères imprimables (selon le jeu de caractères de la base de données). Un autre souci avec les données binaires est que leur conversion est différente des caractères alphanumériques. Si la base de données source et la base de données cible n’utilisent pas le même jeu de caractères (EBCDIC vers Ascii ou Utf-8 par exemple), une conversion des données est nécessaire pendant la migration des données.
  • La solution ne tire pas avantage de l’expressivité de la base de données cible : par exemple, si une colonne a une date, le SGBD relationnel peut vérifier si la donnée est une date valide, offre une fonction pour manipuler et ordonner les dates.
  • Soucis de performance : par exemple, si un “PIC X(1000)” est traduit en “char(1000)” alors 1000 caractères seront réservés dans chaque ligne, mais bien souvent dans une colonne aussi grande, tous les caractères ne sont pas utilisés. Si c’est traduit en “varchar(1000)” uniquement l’espace nécessaire sera utilisé.

Pour toutes ces raisons, il est important de sélectionner correctement le type de données des colonnes de la base de données cible.

Transformation d’un tableau COBOL (“OCCURS”)

Dans une base de données source et en COBOL, les enregistrements peuvent contenir des tableaux (ou OCCURS) de données. Mais les bases de données relationnelles n’acceptent pas une telle structure et elles doivent donc être traduites. Il existe trois façons de les traduire, chacune avec ses avantages et ses désavantages :

  • Comme une (sous-)table : le tableau est transformé en une table qui est connectée à la table principale par une clé étrangère.
  • Comme une liste de colonnes : le tableau est transformé en une liste de colonnes (une colonne pour chaque élément du tableau).
  • Comme une grande colonne (concaténée) : le tableau est transformé en une grande colonne qui contiendra tous les éléments concaténés du tableau.
Table source

Transformation des clauses REDEFINES

En COBOL, il est possible de définir des « REDEFINES » (utilisation de descriptions de données différentes pour décrire la même zone de stockage). Par exemple, dans le code qui suit, ORDER et DETAIL partagent la même zone de stockage. La définition à utiliser dépend de la valeur d’une autre variable. Dans cet exemple, la définition de ORDER est utilisée si DET-NUM est égal à zéro, sinon c’est la définition de ORDER qui est utilisée.

Table source legacy colonnes

Les bases de données relationnelles n’offrent pas une telle fonctionnalité, chaque redéfinition doit donc être transformée vers une structure différente.

Il y a deux manières de transformer des « REDEFINES » :

  • Chaque « REDEFINES » est transformé en table : dans notre exemple ORDER et DETAIL deviennent des tables séparées.
  • Chaque champ du « REDEFINES » est transformé en colonne (nullable) : chaque champ de « REDEFINES » différent devient une colonne (nullable), des check/triggers (validateurs/déclencheurs) doivent être ajoutés afin de vérifier que les colonnes des différents « REDEFINES » contiennent une valeur.

Conclusion

La conception de la base de données est une phase très importante car elle va déterminer la performance et la lisibilité de la nouvelle base de données.

Afin de correctement concevoir la nouvelle base de données, une très bonne compréhension de la base de données source est nécessaire. Cette compréhension peut prendre du temps et peut être réalisée grâce à la rétroingénierie.