Bitácoras.

                         

En algunas organizaciones se requieren aplicaciones que sirvan de bitácora para que el usuario pueda plasmar en ellas comentarios, opiniones y seguimientos que no siempre son posibles de estandarizar. Por ejemplo, en una clínica, las descripciones de las dolencias no pueden estandarizarse puesto que depende de la edad del paciente, el historial médico y las complicaciones previstas e imprevistas que conforman un cuadro médico único e imposible de codificar en términos computacionales. En estos casos, podemos proveer alguna aplicación sencilla en el AS/400 que además de guardar el responsable del registro de la bitácora, la fecha y hora de registro y el texto descriptivo del cuadro médico o de la situación emergente que se está describiendo, podemos incluir algunos campos a manera de cuestionario para asegurarnos de que el usuario cargue información significativa que permita a cualquier supervisor de la organización tener una idea mas clara de lo que sucede con el caso en seguimiento.

Un ejemplo de esto podría se la inclusión de campos como:

Días adicionales en la clínica.

Monto adicional por día de estadía.

Cambio de dieta. (si o no)

Cambio de tratamiento.(si o no)

Cambio de enfermera (si o no)

Tratamientos adicionales (Si o no).

Estas y otras preguntas tipo cuestionario corto, pueden dar una información resumida de los aspectos relevantes en relación al paciente aún cuando el texto descriptivo contenga términos médicos o abreviaturas que aunque para el médico son vitales, para otras áreas administrativas de la organización que realizan seguimiento del caso puede resultar engorroso y de poca utilidad operativa. La idea además de cubrir un requerimiento no estandarizable, es asegurarnos de que el usuario información significativa para la organización entera que operativamente funciona como un todo integrado que recibe y envía información continuamente.

Este ejemplo es exportable para cualquier otro tipo de organización que requiere llevar bitácoras en línea con información no estándar ni codificable desde el punto de vista informático.

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.

SQL y el JOIN

                        

En el manejo del SQL el empleo del JOIN es muy importante para realizar búsquedas en la base de datos y sobretodo para comprobar la integridad de la data.

Existen tres tipos de JOIN: INNER JOIN, LEFT JOIN, RIGHT JOIN.

Vamos a ver con un ejemplo como funcionan estos JOIN.

Supongamos que tenemos dos bases de datos:

La base de datos EMPLEADOS que contiene la siguiente información.

Clave = Id, Nacionalidad

Id. 5886825

Nombre= Pedro Perez

Nacionalidad = USA

Id. 66677889

Nombre = Juan Rodríguez

Nacionalidad = MEX

La base de Datos SUELDOS que contiene la siguiente información:

Clave = ID, NACIONALIDAD, DEPARTAMENTO

Id. 5886825

Nacionalidad = USA

Sueldo = 5000,00

Departamento = Contabilidad.

Id. 444333221

Nacionalidad = BOL

Sueldo = 8000,00

Departamento = Finanzas

En este momento Juan Rodríguez no ha sido asignado a ningún departamento.

La denominación Archivo1 se lo asignamos a la Base de Datos  EMPLEADOS

La denominación Archivo2 se lo asignamos a la base de Datos SUELDOS

Vamos a ver cual es el resultado de la consulta cuando trabajamos con INNER JOIN:

SELECT Archivo1.ID, Archivo2.ID, Archivo1.NOMBRE, Archivo2.SUELDO INNER JOIN SUELDOS Archivo2 ON  Archivo1.ID = Archivo2.ID and Archivo1.NACIONALIDAD = Archivo2.NACIONALIDAD.

El resultado de la búsqueda es:

5.886.825, 5.886.825, Pedro Perez. 5000

Esto corresponde en la imagen al área de color amarillo de la figura, donde están los empleados que se encuentran en ambas bases de datos.

Vamos a ver cual es el resultado de la consulta cuando trabajamos con LEFT JOIN:

SELECT Archivo1.ID, Archivo2.ID, Archivo1.NOMBRE, Archivo2.SUELDO LEFT JOIN SUELDOS Archivo2 ON  Archivo1.ID = Archivo2.ID and Archivo1.NACIONALIDAD = Archivo2.NACIONALIDAD.

66.677.889, NULL, Juan Rodríguez. NULL

Esto corresponde en la imagen al área de color azul de la figura, donde están los empleados que se encuentran SOLO en la base de datos: EMPLEADOS.

Vamos a ver cual es el resultado de la consulta cuando trabajamos con RIGHT JOIN:

SELECT Archivo1.ID, Archivo2.ID, Archivo1.NOMBRE, Archivo2.SUELDO RIGHT JOIN SUELDOS Archivo2 ON  Archivo1.ID = Archivo2.ID and Archivo1.NACIONALIDAD = Archivo2.NACIONALIDAD.

NULL, 444333221, NULL, 8000

Esto corresponde en la imagen al área de color verde de la figura, donde están los empleados que se encuentran SOLO en la base de datos: SUELDOS. Este último resultado nos está señalando que no hay integridad en la Base de Datos y debemos revisar que está ocurriendo.

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.

Haciendo Fácil lo Difícil

Una estrategia de programación muy vieja pero muy buena.

Cuando realizamos programas de actualización que permiten ingresar, modificar y eliminar información, podemos vernos atrapados en lazos dentro de lazos dentro de lazos. Siguiendo el Estándar de IBM en el manejo de las teclas de función, usamos el  F3 para salir y F12 para regresar a la pantalla anterior, (en todas las pantallas) y para navegar de una pantalla a otra dentro del programa hacemos While que a su vez tienen internamente otros While que tienen otros While, etc. Todos estos while finalizan por la misma condición *in03 o también *in12.

Si utilizamos un CASE como el MAIN del programa, se nos facilita el proceso. Este CASE  según el nivel de ejecución (mas interno o mas externo) direcciona a la rutina ha ser ejecutada sin necesidad de tener lazos anidados.

Algoritmo de Ejemplo.

                     NIVEL = 1

                     DOW NIVEL <> 0

                       CASE

                        NIVEL = 1      EXSR pantalla1

                        NIVEL = 2      EXSR pantalla 2

                       ENDCAS

                     ENDDO

                    *INLR = *ON

BEGSR PANTALLA1

Muestra pantalla1

Valida pantalla1

Si F12 or F3 entonces Nivel = 0

Sino

   Si no hay error nivel = 2

   Fin-SI

  Fin_SI

ENDSR

BEGSR PANTALLA2

Muestra pantalla2

Valida pantalla2

Si F12 entonces Nivel = 1

Sino

Si F3 entonces Nivel = 0

 Sino

   Si no hay error Procesar

      Fin-SI

      Fin-SI

Fin-SI

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.