Hace tiempo que estoy buscando la manera de mejorar y hacer más efectivo el manejo de la información que suelo procesar en una base de datos, pues generalmente he topado con algunos problemas serios a la hora de intentar compartir esa información entre usuarios de distintos gestores de bases de datos y, sobre todo, entre las distintas plataformas más utilizadas (Windows, Mac, Linux). Uno de los peores problemas es el paso de los datos entre los diferentes programas de aplicación propietarios, así como de las herramientas de procesamiento y análisis que cada uno de ellos puede generar. Por ejemplo, al intentar pasar la información de una vieja base de datos documental que utilicé para la escritura de mi tesis doctoral y que fue diseñada en el DBMS Microsoft Access a otro programa (en este caso, FileMaker, por la flexibilidad para trabajar y compartir información entre diversas plataformas, específicamente Windows y Mac), me encontré que, en ocasiones, los datos de algunos campos no tenían transparencia del 100% a la hora de migrarlos. Pero lo que me pareció más terrible es que las consultas SQL diseñadas en Access gracias a la integración del Visual Basic en el propio DBMS, eran irrecuperables en el nuevo programa de gestión de datos (aunque en FileMaker también se pueden ejecutar consultas SQL, pero la escritura del script es diferente). Finalmente, lo más patético es que resulta casi imposible compartir los datos y las consultas con otros colegas o con un equipo de trabajo si cada quien utiliza una plataforma distinta, un programa de aplicación distinto, más aún en el caso de que se quiera que la base de datos sea útil para un equipo de colabores que aporten información y que la usen colectivamente para la investigación.
El caso es que mi decepción sobre el diseño de bases de datos con los gestores comerciales se le ha sumado que, con el paso del tiempo, he acumulado una creciente desconfianza en el uso de software propietario para la investigación histórica. A la vez estoy cada vez más convencido de la necesidad de crear nuestros propios recursos para poder compartir nuestros datos entre más colegas a la vez que nos aseguramos que no sean perecederos por causa de la caducidad tecnológica tanto de software como de hardware.
Todo esto para comentar que una de las soluciones que me ha parecido más viable en teoría es la de crear bases de datos con recursos informáticos menos anclados a las directrices del software propietario común y corriente. En este caso (y gracias a una explicación que me dio hace algunos años Esteban Sánchez Rodríguez), la solución más inteligente sería la creación de una base de datos SQL que resida en un servidor. Para ello, lo más fácil sería la utilización de MySQL que, aunque es software propietario, permite una mayor flexibilidad de uso en diferentes plataformas. A esto le seguiría el diseño de un recurso de gestión y visualización en el navegador Web mediante un lenguaje de programación de alto nivel. Esto permite compartir la base de datos en Internet aprovechando las posibilidades de la Web 2.0.; es decir, de la misma manera en la que operan sitios como Facebook, Wikipedia o WordPress, lo cual nos da la posibilidad de integrar un equipo de trabajo amplio que pueda hacer uso de la base de datos ya sea vía consulta o directamente alimentando los datos en línea si el usuario tiene las credenciales adecuadas para ello.
Después de conversar con Jairo Antonio Melo el otro día sobre el diseño de una base de datos prosopográfica con estas características, me envió el enlace a un ejemplo muy interesante. Se trata de Project Quincy, una base de datos que se puede visualizar en Internet y que ha permitido desarrollar proyectos como The Early American Foreign Service Database (EAFSD), que cubre los primeros cincuenta años de la historia de la diplomacia estadounidense enfocada en los individuos que formaron parte de ella.
The Early American Foreign Service Database
Project Quincy fue desarrollado por la joven historiadora y programadora Jean Bauer (hija, por cierto, de un informático y una novelista). Bauer diseñó una base de datos en MySQL que almacena información sobre personas, lugares e instituciones y que permite trazar la formación de redes de relaciones sociales (parentesco, patronazgo), la correspondencia entre individuos; la formación, crecimiento y decadencia de organizaciones y de las propias redes, todo ello a través del tiempo. Permite vincular la mención de fuentes para cada evento individual, y un largo etcétera. Por su parte, la visualización y gestión de la base de datos se hace mediante un sencillo framework para aplicaciones web, Django, cuyo código está escrito en Python y por lo tanto bastante accesible para historiadores programadores neófitos.
Project Quincy (trace the network)
Project Quincy tiene a su favor que es una base de datos creada por una historiadora para historiadores interesados en las redes. Como dice la propia Jean: «La base de datos existe para conectar gente con otra gente en un momento particular, en un lugar en particular y por una razón en particular, permitiendo al usuario el mapeo de redes de correspondencia […] tiene más o menos seis módulos de interconexión, cada uno para rastrear diferentes tipos de redes e información: biográfica (profesional, relaciones personales, lugares de residencia); organizaciones (afiliación e historia de la institución), correspondencia (cartas); asignaciones (conectar a una persona, un trabajo y un lugar en un periodo de tiempo específico), ubicaciones y citas documentales y/o bibliográficas. »
Dos cosas a su favor es que la base de datos trabaja en línea y puede integrar a múltiples usuarios para trabajo en colectivo. Otra cosa a su favor es que el código está disponible de manera libre en el GitHub de Jean. En cuanto tenga un tiempito voy a descargarlo y hacer una prueba. Ya les comentaré.
cuaderno en crudo 