Bienvenidos a Iseries Venezuela

Las mejores prácticas, recursos, tips, enlaces, videos y artículos para informáticos relacionados con el Iseries y el As/400 lenguajes de programación RPG, ILE RPG y SQL.

The best practices, resources, tips, links, videoes and articles for computer related to the Iseries and the As/400 languages of programming RPG, ILE RPG and SQL.
Showing posts with label Base de Datos. Show all posts
Showing posts with label Base de Datos. Show all posts

Friday, May 23, 2014

Cinco Recomendaciones Para Crear Archivos con DDS


 En esta oportunidad voy a referirme a la clásica creación de “base de datos” utilizando DDS. 

Coloco entre comillas base de datos porque en realidad DDS es un manejador de archivos y no un manejador de base de datos.



Crear Bases de datos con  DB2 tiene una serie de validaciones automáticas suministradas por el DB2 que impiden de alguna manera la generación de algunos “Frankenstein”; en cambio, la libertad del uso de las DDS  si permiten la proliferación de algunas creaturas terroríficas que deambulan en los pantanos de los sistemas de las organizaciones





1.-El Diccionario de Datos.

El uso del diccionario de datos que tuvo su auge en  décadas pasadas ha pasado a ser, en varias instalaciones, una colección mas en el  baúl de los recuerdos. El Diccionario de datos permite mantener la consistencia e integridad de la data. En algunas instalaciones vemos por ejemplo, que unos archivos tienen el código de país de tres posiciones alfabéticos, otros los tienes de dos posiciones numéricos y otros de seis posiciones alineados a la izquierda utilizando solo los primeros dos caracteres. Para evitar esta variedad de definiciones que rompen con la consistencia de la base de datos es importante y fundamental utilizar un diccionario de datos.

2.-Normalización de las Bases de Datos.

Hay material de estudio académicamente certificado que explica como definir una base de datos siguiendo las reglas normalización de primera forma normal hasta quinta forma normal. Es bueno desempolvar lo que aprendimos en las instituciones y llevarlo a las mejores prácticas en nuestros sitios laborales. En los siguientes artículos vamos a ver la aplicación de la normalización de las bases de datos en el desarrollo de programas RPG usando DDS.

3.-NO colocar índices en los archivos físicos.

Colocar claves en los archivos físicos retarda los procesos de recuperación, copia y salvado de la data. Incluso retardan el tiempo de respuesta de los procesos. Es preferible utilizar lógicos, SQL o cualquier otro medio de acceso indexado que satisfaga esa necesidad de ordenamiento.

4.-Deje algunos campos comodín.

Dada la dinámica de los cambios en las normas y reglas del negocio, algunas veces es imposible predecir la necesidad de expandir un archivo creándole mas campos y cuando las modificaciones que requiere el negocio nos lleva a la necesidad de crear campos adicionales preferimos crear otras tablas o archivos que viene a ser la “extensión” del archivo base. Es conveniente crear algunos campos extras de tipo carácter y numérico que permita prevenirnos de modificaciones dramáticas a futuro, que involucre la recompilacion de varios programas que depende de las definiciones de los archivos.
Aunque algunos prefieran crear tablas adicionales, la consulta de estas tablas en procesos nocturnos (hacer chain una y otra vez) puede retrasar el tiempo de respuesta.

5.-Sea consistente en la nomenclatura de los campos.

Aún utilizando el diccionario de datos, los archivos que reposan sobre él en cuanto a su definición pueden tener sus propios nombres de campos según el criterio del analista o las normas de desarrollo del departamento de sistemas.
¿Qué es eso de la consistencia en los nombres?
Por ejemplo para los campos que sean código utilice las tres primeras posiciones de la izquierda como COD  o si lo prefiere CD o de cualquier otra manera. Cualquier sea su elección mantenga esa nomenclatura en todos lados. Si se trata de una descripción y decide utilizar DES utilice DES a lo largo y ancho de la base de datos.
Aunque una longitud de 6 posiciones es bastante corta para describir el concepto del uso de un campo, el respeto por las convenciones de uso y nomenclatura establecidas por el departamento de sistemas y de base de datos, facilita al analista entender rápidamente de qué se trata el contenido de la data.

En el siguiente enlace conseguirás mas información sobre creación de base de datos publicada en otros artículos de este mismo blog.

Haz click aqui:  Bases de Datos


En las próximas entregas voy a ilustrar la definición y el uso paso a paso de una base de datos adaptado a DDS y para desarrolladores RPG además de otras recomendaciones.




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

Monday, January 13, 2014

Mejorando los Tiempos de Respuesta: Miembros en Archivos Físicos



Hay varias opciones para agilizar los tiempos de respuesta en el proceso de accesar la data de un archivo. Esta vez vamos a ver el uso de miembros en un archivo físico.

Los archivos físicos pueden ser “particionados” en varios miembros.  Esto de lo Miembros es  parecido a las particiones que se hacen a un disco con la diferencia de que se trata de particiones virtuales. Es decir particiones lógicas.

 Con el comando ADDPFM se pueden agregar miembros

 El comando es:
 ADDPFM FILE(LIBRERIA/ARCHIVO) MBR(NOMBRE-del-Miembro)

  El tope es hasta 32.767 miembros.
 Podemos poner un nombre mnemónico a cada miembro que nos permita a simple vista entender que tipo de data se almacena en ese miembro.

Supongamos que queremos tener en disco la data de cierre del año fiscal desde hace 14 años hasta el año actual. (Año actual =2014)
Cada miembro puede contener data de distintos años. Podemos crear tres miembros. Por ejemplo, el primer miembro contiene la data de los primeros cinco años, el segundo de los otros cinco y el tercero de los últimos cinco años.

Cuando vamos a grabar en un archivo debemos detectar la fecha de la data y hacer ovrdbf sobre el archivo con el miembro destino de la información. Las consultas, listadores y procesos deben grabar sobre el miembro que contiene la data correspondiente a la fecha dentro del rango definido.
Lo archivos lógicos además deben ser creados apuntando a cada miembro. De esta manera cada miembro tiene sus propios archivos lógicos e índices asociados. Cada aplicativo que utiliza el archivo hace una cantidad de accesos a la data mucho menor cuando se limita el alcance a un miembro específico que tiene un total de registros mucho menor que la sumatoria de todos los miembros.

Hagamos un ejercicio:

Al primer miembro lo podemos llamar AF00AL05 para indicar que contiene la data del año fiscal  (AF) desde el año 2000 (00) al año 2005 (05).

Creamos el miembro:
ADDPFM FILE(LIBRERIA/ARCHIVO) MBR(AF00AL05)

En caso de utilizar directamente el archivo físico en el programa, el OVRDBF correspondiente que tendría que hacer el aplicativo antes de actualizar o leer es:
OVRDBF FILE(ARCHIVO) TOFILE(LIBRERIA/ARCHIVO) MBR(AF00AL05)

Si decidimos crear un archivo lógico para utilizarlo en nuestras aplicaciones lo creamos de
Esta manera:
CRTLF FILE(LIBRERIA/LOGICO1) DTAMBRS((LIBRERIA/ARCHIVO(AF00AL05)))

Al segundo miembro lo podemos llamar AF06AL10 para indicar que contiene la data del año fiscal  (AF) 2006 (06) al 2010 (10)

Creamos el miembro:
ADDPFM FILE(LIBRERIA/ARCHIVO) MBR(AF06AL10)

En caso de utilizar directamente el archivo físico en el programa, el OVRDBF correspondiente que tendría que hacer el aplicativo antes de actualizar o leer es:
OVRDBF FILE(ARCHIVO) TOFILE(LIBRERIA/ARCHIVO) MBR(AF06AL10)

Si decidimos crear un archivo lógico para utilizarlo en nuestras aplicaciones lo creamos de
Esta manera:
CRTLF FILE(LIBRERIA/LOGICO2) DTAMBRS((LIBRERIA/ARCHIVO(AF06AL10)))
Al tercer miembro lo podemos llamar AF11AL15 Para indicar que contiene la data del año fiscal  (AF) 2011 (11) al 2015 (15)

Creamos el miembro:
ADDPFM FILE(LIBRERIA/ARCHIVO) MBR(AF11AL15)
En caso de utilizar directamente el archivo físico en el programa, el OVRDBF correspondiente que tendría que hacer el aplicativo antes de actualizar o leer es:
OVRDBF FILE(ARCHIVO) TOFILE(LIBRERIA/ARCHIVO) MBR(AF11AL15)
Si decidimos crear un archivo lógico para utilizarlo en nuestras aplicaciones lo creamos de
Esta manera:
CRTLF FILE(LIBRERIA/LOGICO3) DTAMBRS((LIBRERIA/ARCHIVO(AF11AL15)))

Gráficamemente podemos representar el archivo de la siguiente manera.




Algunas organizaciones al cierre de año, crean a tiempo de ejecución un miembro nuevo cuando detectan que es un año fiscal que no tiene miembro asignado. Es decir en los programas CLP crean un nuevo miembro siguiendo una nomenclatura estándar y grabando en un archivo aparte el nombre del nuevo miembro con el rango de fechas que le ha sido asignado.
Por ejemplo, podemos tener  un archivo de control de miembros definido de esta manera



Con la siguiente data cargada manual o automáticamente.









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







Monday, January 11, 2010

Base de Datos vs. DFU
















Cuando estamos realizando pruebas de programas, generalmente recurrimos al uso del DFU para proveernos de un conjunto de datos improvisados por nosotros mismos para realizar pruebas parciales y unitarias de programas. En general, existe la sensación de que en un ambiente de desarrollo, todo es válido. Puede corromperse la data para realizar pruebas, tener redundancia de información y alterar la data como la requerimos.

En ambientes de desarrollo donde no hay control de versiones, esto puede representar un problema cuando otros programadores necesitan realizar pruebas con los mismos archivos y se encuentran con una data corrompida. Aunque dupliquemos los archivos en nuestras librerías de trabajo personales para manejar la data a nuestro antojo, no debemos olvidar que la situación que estamos forzando “No se ajusta a la realidad”. Ese escenario que estamos produciendo de manera forzosa, probablemente nunca ocurrirá en el ambiente de producción. Entonces ¿Qué estamos probando?.

La elaboración de escenarios de pruebas debe estar basada en un principio de “correspondencia con la realidad” que se presenta en la operativa diaria del negocio.

Las datas de prueban deben ser generadas por las aplicaciones que fueron desarrolladas para tal fin. Las aplicaciones velan para que las validaciones se encarguen de la integridad y la consistencia de la data. Cuando realizamos pruebas en base a data generadas por las aplicaciones, garantizamos que el ambiente de desarrollo sea idéntico a lo que ocurre en el ambiente de producción, que en resumidas cuentas, es lo que sucede día a día en las actividades diarias del negocio.

Es recomendable que los profesionales asignados al mantenimiento y la custodia de los datos sean quienes suministren la data de prueba a los analistas y programadores. Corresponde al personal de Base de Datos colocar en el ambiente de desarrollo una data que simule la data de producción.

En algunas empresas, por razones de estrategia de negocios y protección de la identidad de los clientes, la data debe ser tratada previamente por estos profesionales de Base de Datos antes de ser entregada al ambiente de desarrollo donde todos los analistas y programadores puedan accederla.


Autor: Ing. Liliana Suárez


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

Thursday, December 10, 2009

Definiendo Las Claves en los Archivos












                                                                      (Haz Click en la imágen para agrandarla)

Un error muy común en aquellos centros de informática donde se utilizan sistemas que no se basan en DB2 sino en el manejo tradicional de archivos según la DDS definidas por los desarrolladores, consiste en confundir Clave con Índices de Acceso.


En la figura tenemos un diagrama donde se puede ver un encabezado de factura y sus tres campos que definen la clave. También podemos ver múltiples ocurrencias del archivo de detalle en el cual se especifica el artículo facturado al cliente.

En general es común creer que la clave del archivo de detalle es la que se ilustra en el diagrama, es decir, la misma clave que el encabezado de factura agregando además el artículo facturado. El concepto de clave implica además de su unicidad, su inmovilidad en el tiempo, es decir, es inmodificable. Si el cliente decide cambiar el artículo, no es posible desde un punto de vista conceptual, realizar el cambio. Para realizar el cambio en la factura, la aplicación debe permitir agregar artículos y eliminar artículos mas no modificar el código del artículo. El usuario de la aplicación debe entonces eliminar el artículo de la factura y agregar la información del nuevo artículo que desea el cliente.

En este punto algunos desarrolladores piensan que la solución entonces es colocar como campos claves del detalle del artículo los mismos campos claves de su cabecera. Con esta acción se pierde la clave del archivo puesto que deja de ser única y se repite tantas veces como artículos haya en la factura.

La solución ajustada a las reglas y normas de construcción de Base de Datos es generar un consecutivo. Es decir, cada vez que se crea un artículo, el programa genera un número de secuencia que identificaría en forma unívoca a cada registro dentro del archivo de detalles. Esto es particularmente útil cuando el inventario es más complicado y cada artículo se define a su vez por medidas, pesos, litros, láminas.

(Haz Click en "Más Información" para seguir leyendo)

Sunday, July 19, 2009

¿Qué es un Trigger?






Un trigger es un atributo de un archivo físico que permite al manejador de Base de datos del AS400 ejecutar un programa en el mismo instante que se haga algún cambio sobre ese archivo. El comando para agregar un trigger es: ADDPFTRG.

Podemos especificar que queremos que se ejecute un programa antes o después de añadir, eliminar o modificar un registro en el archivo físico sobre el cual estamos ejecutando el trigger. Este programa es desarrollado por nosotros como programadores del sistema.

El programa que se “dispara” al ejecutar una actualización del archivo debe ser especificado en el comando ADDPFTRG. Este programa debe recibir dos parámetros el primero de los cuales comprende el encabezado o “header” de la información que el manejador de base de datos devuelve sobre el cambio que se ha realizado sobre el archivo. El segundo parámetro contiene especificaciones mas detalladas sobre el cambio que se realizó en los campos del registro que fue alterado.

Cabe destacar que el Trigger no es un Journal. No devuelve trazas de auditoria que indique quien hizo el cambio ni que programa realizó el cambio, simplemente ejecuta el programa que le indicamos debe ejecutar.

A manera de prueba he declarado dos parametros de 5000 posiciones carácter cada uno y me han funcionado las pruebas de trigger.

Sin embargo, para detalles bien precisos sobre el contenido y las longitudes que nuestro programa debe tener para capturar la información del cambio de la base de datos pueden acceder a este link:

http://www.help400.es/asp/scripts/nwart.asp?Num=78&Pag=34&Tip=U


¿Para qué sirve un trigger?

Un trigger puede utilizarse por ejemplo para capturar data entre dos sistemas o módulos completamente distintos. Supongamos que tenemos un Sistema Autorizador de Tarjeta de Crédito que verifica el pin del cliente, su limite de crédito y que no esté bloqueada la tarjeta. El sistema autorizador puede aprobar el crédito y dejar un registro que sea parte de un archivo histórico de la solicitud de consumo recibida, sin embargo el sistema autorizador no tiene la capacidad de detectar un consumo “atípico” relacionado con el comportamiento del cliente que pueda detectar un fraude por usurpación de identidad o robo de tarjeta. Este proceso de detección de fraude le corresponde al Sistema de Monitoreo de Fraude. Si añadimos un trigger en el archivo histórico del autorizador y hacemos que este trigger disparé un programa que ingrese esta información de consumo en forma automática al Sistema de Monitoreo entonces la detección del fraude puede ser prácticamente inmediata y puede procederse preventivamente a un bloqueo de tarjeta para proteger al cliente y al banco de un proceso fraudulento.

El trigger puede ahorrarnos el hacer muchos programas que actualicen archivos de auditoria, y archivos para consulta en línea. Además para procesos nocturnos de largo tiempo de procesamiento el trigger es mas rápido que invocar varios programas que graben información sobre la actualización de la data u otra traza de auditoría que desee almacenarse.


Si te pareció interesante, reenvialo 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

Friday, May 8, 2009

Restricciones de Integridad de la Base de Datos










(Para ampliar la imagen haz click)

En muchos centros informáticos se trabaja el diseño de base de datos sin el uso de DB2 que es el manejador de Base de Datos del Iseries. Luego del desarrollo de un sistema en estas condiciones, la documentación debería reflejar las restricciones de la base de datos para asegurar la consistencia e integridad de la información contenida en la misma.

Para la base de datos que ilustra la figura del artículo, coloco un ejemplo de las reglas de integridad que rigen a esta base de datos y que deberían estar reflejadas en la documentación técnica que apoya el mantenimiento y expansión de todas las aplicaciones que residen en el Iseries.


Restricciones de Integridad de la base de datos.

1.-Un Directorio no puede crearse para Áreas Distintas.

2.- El Identificador del listado es único para cada área, pero puede repetirse para áreas distintas. Por tanto la clave que identifica un reporte es área-Identificador de Reporte (Prefijo). Esto se diseño en esta forma para no disminuir el rango de Identificadores de reportes para cada área.

3.- No puede eliminarse un reporte si pertenece a un directorio. Primero hay que “deshacer” el Enlace con el directorio y luego Eliminar el reporte del área.

4.- Si desea eliminarse un Directorio debe eliminarse primero su enlace al área que pertenece y luego se eliminará el directorio.


5.- Los programas deben validar y actualizar respetando los puntos anteriormente expuestos.


Si te pareció interesante, reenvialo 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

Monday, April 6, 2009

Establecer Relaciones de la Tablas de Datos











Pregunta:

Te comento que estoy ha cargo de un sistema informático en un Centro de Rehabilitación, quiero encontrar la forma de generar un gráfico para determinar las relaciones de los archivos físicos (algo similar a lo que se puede hacer en SQL Server u Oracle) talvez conoces la forma de realizarlo o existe alguna herramienta en el AS400 ?

Saludos. Jaime Maza, Ecuador.

Respuesta:

La mayoria de los programadores o diseñadores no crean base de datos sino una colección de archivos que en ningun momento especifican al AS400 cuales son las relaciones entre ellos. Al crear archivos manualmente via DDS (fisicos, lógicos creados manualmente al compilar el fuente SEU) no hay manera de informarle al DB2 del AS400, cómo es la relación entre ellos.

Existe una herramienta que se llama Erwin para generar las relaciones entre archivos y construir la base de datos en el AS400, pero los archivos deben haber sido diseñados bajo los estándares de modelos relacionales de base de datos.
El DB2 del AS400 controla el cumplimiento de estos estándares.

El procedimiento para generar bases de datos DB2 es:

1.-Modelar en Erwin las base de datos del AS400 desde windows,
2.-Luego esta información generada por Erwin es transferida al AS400,
3.-Finalmente los administradores de la base de datos del AS400 activan, en el AS400 un procedimiento que genera en forma automática una base de datos controlada por el manejador DB2, las tablas son creadas con comandos SQL en el AS400(create table etc) en base a la información recibida desde windows con el modelo Erwin.

Si no estan diseñados de esa manera, el AS400 no tiene manera, que yo sepa, de "adivinar" la relaciones entre ellos.

Si los sistemas han sido comprados a un proveedor, el proveedor debe darte las relaciones de los archivos de la base de datos.

Este tema es dominado con mayor profundidad, por gente que se dedica a Administrar la Base de Datos en el AS400.

Pueden haber proveedores que te vendan herramientas programadas por ellos para que puedas ver las relaciones entre las tablas, sin embargo estas herramientas deben ser alimentadas manualmente, al crear los archivos, bien sea con meta lenguajes o al momento de crear la Base de datos para que el AS400 pueda almacenar las relaciones de los modelos entidad-relacion de la base de datos y luego tu puedas tener una "vista" de las relaciones entre archivos.

Por ejemplo, en este link: http://aquafold.com/es/index-db2-iseries.html puedes ver un proveedor que hizo una herramienta para visualizar base de datos en el as400, pero como siempre, basada en que los archivos fueron construidos con DB2.

Hasta ahora no conozco otra manera de obtener la información que estas solicitando. Si me llega alguna otra información sobre este tema te la hago llegar.

Si alguno de los lectores del blog, conoce alguna información adicional o específica que pueda proveer de mayor beneficio al tema que estamos publicando nos la puede hacer llegar bien sea a través de comentarios a este articulo o al correo: rpg.iseries@gmail.com luego, publicaremos el autor de la nota y el contenido de la misma.


Si te pareció interesante, reenvialo 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

Wednesday, March 11, 2009

Integridad de la base de datos.











En la imagen asociada a este artículo se observa un relación 1:N, en una base de datos hipotética de cualquier institución comercial. Tenemos un encabezado de Factura en el nivel mas alto de la jerarquía del modelo y los detalles de los artículos en el siguiente nivel. (Haz Click sobre la imagen si la quieres ver ampliada)

Un buen contingente de programadores hace esto al grabar, en los archivos, la información incluida por el usuario:

C Lee artículo
C*
C Dow Not (*in99)
C |
C | Monto Total Factura = Monto Total Factura + Monto Artículo
C |
C | Write artículo
C |
C | Lee artículo
C |
C | Enddo

C Write Encabezado de Factura


La idea de este algoritmo, es ir acumulando los montos parciales facturados para luego grabar el monto total en el encabezado de la factura.

Esta secuencia de pasos mostrado en este pseudocódigo puede poner en peligro la integridad de la base de datos. Si hay una caída del sistema, antes de que se grabe el encabezado de factura, quedaran los artículos grabados sin tener su respectivo encabezado asociado y recuperar la información que quedó incompleta será más difícil:


1.- Si el sistema genera los códigos de factura con un consecutivo en forma automática y hay varios usuarios cargando factura en el mismo momento en que el sistema cae podrían mezclarse artículos de distintas facturas, dependiendo del algoritmo que se utilice para generar las facturas.

2.-Los reportes y consultas que totalizan por artículo vendido en un rango de fecha no podrían reflejar estos artículos que quedaron sin encabezado.

3.-Probablemente, el cruce de información entre los reportes consolidados y los reportes detallados no reflejarán el descuadre porque tanto en los reportes de totales facturados como en los detallados en un período de tiempo, posiblemente, omiten las facturas que quedaron incompletas. Esto dificulta al analista de sistemas como al analista de negocio localizar los errores con prontitud.




Haciendo algunos cambios en el algoritmo presentado, se reduce el riesgo de atentar en contra de la integridad de la base de datos:

C Write Encabezado de Factura /* con monto total en cero, */
C*
C Lee artículo
C*
C Dow Not (*in99)
C |
C | Monto Total Factura = Monto Total Factura + Monto Artículo
C |
C | Write artículo
C |
C | Lee artículo
C |
C | Enddo

C Update Encabezado de Factura


Si hay una caída del sistema, puede detectarse con facilidad las facturas que quedaron inconclusas en información puesto que el monto del encabezado quedó grabado en cero.
Por otra parte, el cruce de reportes consolidados y detallados reflejaría inmediatamente un descuadre que sería rápidamente detectado por cualquier analista del negocio aunque no pertenezca al área de sistemas.


Si te pareció interesante, reenvialo 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