• Cálculo relacional
• ¿Por qué Python?
• Comentando el programa
• Funcionalidades de Pycemen
• Pycemen en acción
• ¿Por qué una interfaz basada en texto?

Cálculo relacional

 ¿Por qué Python?

Python es un lenguaje interpretado, orientado a objetos de propósito general. Python permite mantener de forma sencilla interacción con el sistema operativo, y resulta muy adecuado para manipular archivos de texto. Está disponible en MS-Windows, GNU/Linux, Mac y cualquier entorno *IX.

Python es un lenguaje de scripts, sencillo pero potente. Hablamos de scripts pero...¿qué es un script? Un script es un conjunto de instrucciones que se ejecutan paso a paso, instrucción a instrucción. Esto significa que Python no genera ejecutables, si no que es Python el encargado de ejecutar nuestro código. Es por tanto un lenguaje interpretado, no compilado. Esto le dota de ventajas, pero también de algunos inconvenientes:

Ventajas

• Desarrollo más rápido : Puedes escribir un programa, salvarlo y ejecutarlo. En un lenguaje compilado tienes que pasar por los pasos de compilar y ligar el software, lo cual puede ser un proceso lento.
• Multiplataforma : El mismo código funciona en cualquier arquitectura, la única condición es que disponga del intérprete del lenguaje. No es necesario compilar el código una vez para cada arquitectura.

Inconvenientes

• Lentitud : Los programas interpretados son más lentos que los compilados. Sin embargo los programas interpretados suelen ser cortos, en los que la diferencia es inapreciable.

Si desea saber más sobre Python puede consultar Introducción a Python.

 Comentando el programa

 Funcionalidades de Pycemen

Lo primero, puede verse el código del programa en este link.

La única funcionalidad de Pycemen es añadir datos a la bbdd. Lo que no es poco. Por ejemplo. Algo sencillo como la adición de un panteón a la base de datos. El programa averigua un código ID_Tumba válido. ¿Cómo? Realizando una consulta a la bbdd, interpretando los resultados y calculando un número que sirva (en este caso no es más que sumarle 1 al último ID_Tumba que exista). Una vez tengamos nuestro ID_Tumba, es necesario saber en qué sector va a ser emplazado. Para ello se realiza una consulta en la tabla de sectores y se muestran por pantalla dejando al usuario que decida uno válido. Además es necesario conocer a qué familiar se le va a asociar dicho panteón. Y muchos detalles más.

Otro detalle importante es que Pycemen no sólo añade datos en la bbdd, sino que también guarda todas las sentecias SQL de adición de datos que ejecuta. Esto era especialmente importante para nosotros, ya que al ser poco expertos tanto en PostgreSQL como en SQL en ocasiones cometíamos errores que no sabíamos corregir. Como guardábamos un log con todas las sentencias introducidas, nunca tuvimos que lamentar pérdidas de datos (que aunque ficticios, importantes por lo aburrido que resulta añadirlos). Como ejemplo más claro de esto mostramos el siguiente fichero generado enteramente por Pycemen.

 Pycemen en acción

Vamos a echar un vistazo al funcionamiento al programa. Aunque la versión final puede cambiar (al menos la interfaz) las rutinas que subyacen ya están programadas y funcionan bastante bien (o eso creemos).

Veamos cómo es el proceso de añadir un nuevo nicho a nuestra bbdd. Lo primero es acceder al menú de adición de datos, tras lo cual seleccionamos la opción de añadir una nueva tumba.

Al seleccionar añadir tumba, el programa calcula un nuevo ID_Tumba que sea coherente con los ya presentes anteriormente y lo muestra en pantalla. A continuación averigua los sectores del cementerio y nos pide que seleccionemos aquel en el que va a ser emplazado el nuevo nicho:

Ahora se nos preguntará el tipo de tumba que queremos añadir (nicho, pateón o fosa común, nicho en este caso), la inscripción visible en el nicho y la altura de éste.

Y ya hemos añadido el nicho. Si observamos el fichero de log donde guardamos todas las sentencias SQL de adición de datos, podemos ver:

Y haciendo una consulta a la bbdd:

Este es uno de los ejemplo más sencillos. Se pueden dar situaciones más complicadas como la adición de un fallecido que vaya a ser enterrado en un nicho. En este caso tendremos que cumplimentar además una factura entre otros detalles. Sería algo como esto:

Hasta aquí todo sencillo. Tan sólo una sencilla consulta para ver los enterradores que tenemos en nómina. Ahora y dado que el fallecido irá a parar a un nicho, hemos de cumplimentar los datos de los familiares. Pude darse el caso de que el familiar que pague la factura sea diferente al que aparezca ligado al fallecido(por ejemplo, en caso de accidente de tráfico, en la factura aparecerá la compañía de seguros). Puede ser que el familiar ya esté en nuestra bbdd o puede ser que no. El programa presenta los posibles familiares y pregunta si se desea añadir una nueva entrada en la tabla de familiares:

Ahora es el momento de cumplimentar la factura. Se observa el caso que comentamos anteriormente, que en los datos de la factura aparezca un familiar diferente:

Ahora que ya hemos cumplimentado e introducido la factura, es hora de elegir un nicho para el difunto. Para ello el programa selecciona de los nichos existentes, los que están libres:

Fácil, ¿no?

 ¿Por qué una interfaz basada en texto?

Se nos ocurren diversas respuestas a esta pregunta, pero sólo comentaremos las dos más importantes:

• Sólo permitimos accesos locales a la bbdd (precisamente por esto hemos venido usando OpenSSH, para permitir accesos locales desde máquinas remotas. Esta decisión responde a diversas razones, principalmente la seguridad (no somos expertos en PostgreSQL como para permitir a cualquiera el acceso a la bbdd). Bien, ya que todo lo que hagamos se ejecutar en la máquina remota, pensemos que ocurriría si tuviésemos un programa que se ejecutase gráficamente. Nosotros en la máquina remota tendríamos que recibir toda la información gráfica de la aplicación (ventanas, botones, imágenes...) a través de la red. Esto es factible y perfectamente posible en redes LAN con velocidades de 10 Mbps. Sin embargo a través de una WAN (internet), siendo la velocidad de subida de la máquina que ejecuta el programa de 128Kbps esto no es posible.
• Velocidad de desarrollo: Hemos preferido añadir funcionalidades a la aplicación que diseñar una interfaz gráfica de usuario (que al fin y al cabo nadie iba a usar). Esta decisión nos ha permitido utilizar el programa aún en fase muy primitiva de desarrollo para añadir datos a la bbdd. Siempre es más cómodo que las sentencias SQL.