Por nuestra experiencia en System i, sabemos bien que el acceso a la base de datos « clásica » perdura todavía, igual en ciertos desarrollos nuevos. De una parte por que adoptar SQL induce cambios de hábitos en ciertos programadores y de la otra porque genera nuevas dificultades de desarrollo.

Por otro lado, la adopción de SQL ha llegado a ser un punto de pasaje obligado en la evolución de técnicos de desarrollo. Con la llegada de desarrollos multi-plataformas y la llegada de jóvenes programadores en las empresas, la cuestión de opción no se hace más.

Las soluciones ARCAD podrán ayudarle absorbiendo un máximo de estas nuevas dificultades de desarrollo y volviendo el trabajo del programado tan simple como antes.

¿Porque?...

¿Porque adoptar el lenguaje SQL como estándar de manipulación de bases de datos? 

SQL es un estándar único.
Así como TCP/IP se impone como el único estándar en el mundo de redes, SQL no tiene ni tendrá rival. Es una estándar mundial, reconocido por todos los actores del oficio, sin excepción. Con todas las nuevas herramientas en periferia de aplicaciones, en el dominio de Business Intelligence o de EAI (Enterprise Application Integration), ha extendido su influencia  en el SI.

SQL es un lenguaje de convergencia
Al momento en el que programadores de culturas diferentes se contactan, es necesario tener lenguajes comunes para mejor comprenderse. Si es incongruente pensar que un día los programadores no manipularan mas que un solo y único lenguaje de programación, se puede, gracias a SQL, al menos compartir sin problema el mismo lenguaje de acceso de bases de datos. Así como IBM ha logrado converger sus entornos de desarrollo RPG/COBOL y JAVA, gracias a la base Eclipse, SQL es otro ladrillo técnico que “antiguos” y “modernos” pueden poner en común. SQL rinde más que los accesos clásicos. Es un hecho al día de hoy y resulta lógico. Desde que IBM se abrió a hacer entrar todas las tecnologías las más recientes y más rendidoras alrededor de este estándar y al corazón mismo de la plataforma System i, es coherente llegar a este resultado. Bien usado, SQL es un lenguaje perfectamente adaptado para tratar grandes volúmenes de datos y es aquí donde son pescados los accesos “clásicos”.

SQL es un lenguaje de fácil mantenimiento
Produce un código muy conciso y fácilmente adaptable. Los accesos, igual y los más complejos pueden escribirse en solo algunas líneas. La comprensión de código es fácil. En el momento en que los sistemas de información deben evolucionar mas y mas rápido, se tiene realmente la necesidad de tal flexibilidad en el código.

Las bases de datos sobre System i DB2/UDB y el lenguaje SQL…

El System i implementa la noción de base de datos de manera relativamente original: no hay mas que una sola base de datos real para el OS/400; la noción de colección corresponde únicamente a una vista selectiva (por esquema = biblioteca) de esta. Así, el OS puede conciliar la noción de fichero físico DDS (PF), lógico (LF) y ponerlas igualmente disponibles en la base de datos, al mismo tiempo que todas las tablas, vistas, etc.

El meta-lenguaje SQL de descripción de bases de datos para DB2/UDB puede ser :

• Accesado integralmente sobre STRSQL,
• Grabados en miembros Fuentes y ejecutado por RUNSQLSTM,
• Constituido con la ayuda del System i Navigator,
• Recuperado/ejecutado desde las herramientas de modelizacion de bases de datos tales como Rational Software Architect, PowerAMC o ERwin.
• …

Permite definir los « archivos » por tipo de datos, tablas, índices, vistas. A fin de colocar el máximo de reglas de gestión al nivel de la base de datos, se define igualmente :

• Limites de clave, de verificación y los limites referenciales entre tablas,
• Desencadenadores sobre las acciones de agregación, modificación, supresión (y lectura igualmente) para el grabado de tablas (o a nivel de zona),
• Procedimientos almacenados y de funciones usuarios (tratamientos llamados desde SQL).
• …

Una particularidad del System i es el de permitir que los desencadenadores « sistemas » delegan su tratamiento a programas no SQL (RPG, COBOL, etc.). Así mismo, los procedimientos almacenados y las funciones pueden también servir de protocolo de llamado a programas nativos (o de procedimientos ILE). El acceso a los datos en SQL encapsulado al interior de programas nativos (RPG, COBOL,…) es una alternativa al uso de ordenes especificas a cada uno de estos lenguajes por el acceso a los archivos (archivos clásicos PF-LF o tablas, vistas). Esto permite notablemente utilizar un método único de acceso a los archivos, compartido por todos los programadores (que vengan del AS/400 o de nuevas tecnologías).

SQL es un lenguaje estándar pero de hecho, presenta especificidades para cada tipo de base de datos, que hay que evitar de usar si se desea una portabilidad completa hacia otras plataformas.

Aplicaciones con SQL y mantenimiento de bases de datos DB2/UDB…

Para las aplicaciones que contengan SQL embarcado y/o bases de datos en DB2/UDB, ARCAD-Skipper permite :

Proveer referencias cruzadas

• Para el uso de archivos (y sus zonas) por SQL desde el SQLRPG(LE), SQLCBL(LE), pero también desde las fuentes IFS (Java, VB, Delphi,…) cuando estas acceden a las bases de datos sobre el System i vía JDBC, ODBC,…
• Desde los desencadenadores de tipo “sistema” hacia los programas L3G llamados,
• Desde los procedimientos almacenados o funciones “sistema” hacia los programas L3G llamados,
• Entre las tablas que poseen dificultades referenciales,
• Entre las fuentes SQL de tablas, procedimientos almacenados, funciones hacia los archivos usados o los procedimientos almacenados/funciones llamados.

Aportar la metodología por el mantenimiento de una base de datos en versión.

Sin herramienta, es mas fácil de entregar la primera vez una base de datos completa que, mas adelante, de entregar agregaciones/modificaciones/supresiones de tablas, vistas, procedimientos sobre una base de datos existentes.

Para esto, ARCAD selecciono el de administrar componentes (fuente + objeto) del tipo :

• TABLA (con sus zonas, sus claves, sus dificultades y sus desencadenadores),
• INDICE,
• VISTA,
• SQLUDT (tipos de datos),
• SQLPRC (procedimientos almacenados) (*),
• SQLUDF (funciones usuarios) (*),
• SQLSEQ (secuencias = contadores),

Cada fuente permite de crear/recrear el objeto, por una compilacion. Todas estas fuentes pueden ser recuperadas desde los objetos de una base de datos ya existente.
En una versión, se puede seleccionar el modificar justo algunos componentes DB2, o bien de efectuar modificaciones importantes sobre una base de datos.
Estas modificaciones pueden ser efectuadas sobre las fuentes o directamente sobre los objetos. (Sobre control de ARCAD o no).

En los dos casos, ARCAD detecta enseguida la diferencia de agregaciones/modificaciones/supresiones y las incorpora a la versión (comparando los objetos de referencia a aquellos eventualmente modificados).
El control global de la versión se asegura de la coherencia fuente/objeto.
Para transportar estos componentes modificados en el momento de la puesta en test, producción o distribución sobre sitios/clientes, se puede seleccionar :

• Transportar las fuentes y luego recompilarlas,
• O de transportar directamente todos los objetos necesarios.

En la instalación :

• Los datos existentes son preservados,
• Las dificultades hacia una tabla entregada son también preservadas.

Para las compilaciones, un estudio de fuentes determina automáticamente el buen orden de compilacion, en caso de dependencia entre tablas, entre vistas.
El sistema de Rollback ARCAD toma en cuenta todos estos tipos de objetos.
Los desencadenadores de substitución almacenados por ARCAD permiten facilitar el mantenimiento y sobretodo los tests (en una versión) de programas L3G, cuando son llamados desde los desencadenadores sistemas puestos sobre las tablas, sin necesidad de modificar la tabla.

(*) Con un objeto « virtual » si procedimiento almacenado o función « sistema »

VENTAJAS...

Con Arcad-Skipper, puede :

• Facilitar el pase hacia la adopción de este estándar,
• Aumentar la productividad de sus desarrollos, automatizando la “logística” de evolución de su código SQL,
• Asegurar sus actualizaciones de bases de datos,
• Automatizar las puestas en producción de sus componentes SQL, al mismo titulo que no importa que otro tipo de componentes,