Migraciones y Base de Datos.

Tradicionalmente el programador de RPG no trabaja con base de datos. Los archivos físicos son creados vía DDS y luego se crean los lógicos que constituyen, en la mayoría de los casos, índices de búsqueda y acceso pero no claves del archivo.

Cuando se va realizar migraciones desde archivos en plataforma AS400/Iseries que no han pasado por el manejador de Base de Datos DB2, podemos conseguir dificultades a la hora de migrar hacia plataformas como Oracle, MySQL, y otras.

Para no quedar fuera de las bases académicas y de la vanguardia tecnológica es importante que los programadores y analistas en RPG, retomen los conceptos de normalización de base de datos y desarrollen sistemas basados realmente en manejadores de base de datos relacionales que permiten en forma automática proteger y controlar la integridad  y consistencia de la data. Hacer el cambio desde archivos DDS hacia tablas basadas en DB2 es de importancia fundamental.

Por ejemplo, un error común en el cual se incurre frecuentemente es en el caso clásico de dos archivos como son el encabezado y el detalle de facturas. Muchas veces se incurre en el error de “amarrar” el encabezado con sus detalles a través de un número de factura y decir que esa es la clave. Esa puede ser la clave para el encabezado pero no para los detalles de la factura puesto que no es posible distinguir un detalle de factura de otro detalle sólo con el Número de factura. Se requiere además un número consecutivo de detalle o el código de artículo o cualquier otro campo que unívocamente identifique un detalle de factura. Como la relación entre archivos no se maneja como una base de datos, entonces el programador dentro del código de su programa, lee todos los detalles, totaliza las cantidades o los ítems facturados y luego graba el encabezado con esta información. 

Un manejador de base de datos inmediatamente provocaría un error en la ejecución del programa que le impediría al programador cometer este error contra la  integridad de la data. Lo correcto en este caso sería grabar el encabezado de facturas (con totales en cero), luego recorrer los detalles e ir totalizando la información y por último actualizar el encabezado de factura (update) con el total de los detalles. Si en algún momento dado se produce una caída del sistema, no hay pérdida de integridad puesto que la entidad encabezado de facturas fue grabada de primero (o no fue grabada) y luego sus detalles parcial o totalmente. Es mucho mas sencillo retomar la recuperación de la data con este escenario que con los archivos definidos y basados en el uso de las DDS.

Si quisiéramos hacer reingenieria de nuestros sistemas en el Iseries para pasarlos desde archivos DDS hacia las tablas del manjeador DB2, el proceso no es sería sencillo  puesto que los programas pueden comenzar a fallar en forma masiva cuando el manejador de la base de datos comience a validar las reglas de integridad de la data y cancele todos los programas que incumplen las reglas de integridad, para impedir que la base de datos sea corrompida.

Cuando se realizan migraciones desde una data configurada según DDS hacia un manejador de base de datos, la solución que queda es arreglar la data masivamente o en forma manual a través de programas de mantenimiento, para luego probar la integridad contra los manejadores de Base de datos de la plataforma destino (Oracle, etc) antes de hacer la migración a la plataforma destino.

Una vez mas, es imperativo crear bases de datos basadas en manejadores relacionales proporcionados por el Iseries (DB2) y dejar a un lado el uso de archivos DDS. Aunque pueda resultar difícil adaptarse, es parte del proceso de cambio el estar al día con  las nuevas tecnologías y cumplir cabalmente con los conceptos formales académicos que un buen profesional debe seguir.

Si te pareció interesante, reenvíalo a un amigo haciendo click en el sobrecito que está al final del artículo. El conocimiento es valioso, compártelo.


Autor: Ing. Liliana Suárez