Recordando MS Access

No es que tenga mucha experiencia en diseño de bases de datos (BD), pero con uno de los trabajos que estoy haciendo me topé con el geronte Microsoft Access. Un sistema que usa tablas relacionadas entre si y que sólo permite cierto formato previo diseño. Ideal forma de recolección de datos para cualquier uso ulterior.
El objetivo de esta entrada es un recordatorio personal y comentar el diseño de una herramienta de recolección de datos que muy bien intencionada no ofrece todo lo que un investigador esperaría. Ya es segunda vez que trabajo con esta BD y un mapeo registrado de la misma ayudará a nuevas manipulaciones de la misma.
Todo comienza con la formulación de la pregunta de investigación. Este es un trabajo biomédico que habla de que tan útil es mantener antibióticos (ATB) empíricos por diferentes periodos en una unidad clínica. Como cualquier trabajo biomédico existen muchas variables, tanto confundentes como “end-points” o simples miembros del contexto de la recolección de datos.
En esta BD se pueden agrupar variables en distintos grupos (que quizás luego editaré): Antecedentes previos al ingreso de la unidad, antecedentes del ingreso mismo, comportamiento durante la internación, alta de la unidad y algunos controles posteriores.
Para este trabajo lo importante es la evaluación de factores previos, las características al ingreso y sobretodo como end-points factores asociados a la presciencia de microorganismos.
Esta idea de investigación se basa de manera práctica que existe una BD aparentemente completa y fiable, por lo que para cumplir con la idea de investigación se debe buscar las variables que respondan a los distintos ejes para poder satisfacer la pregunta de investigación

LA BASE DE DATOS
Es un archivo clásico del diabólico MS Access, que debí abrir en Windows para poder analizar su interior. Realmente son dos archivos, uno que contiene las BDs y tablas accesorias y otro que posee el sistema amigable con el humano para el ingreso y sistema de informes.

Su estructura interna consta de 32 tablas. La tabla que es la BD es PACIENTES, hay otras dos grandes también, pero no incursioné en ellas, además al análisis de las relaciones no parecen ser importantes.

Existen 10 flujos de relaciones importantes, donde dos de ellas destacan mucho que tienen el mismo diseño. Ambos flujos de relaciones son similares en que son diagnósticos (uno son comorbilidades y otro diagnósticos de egreso) y por lo tanto pueden ser más de uno para una misma entrada. Usualmente esto se maneja de forma WYSIWYG agregando columnas con todos los diagnósticos posibles, ya que evidentemente es inútil para el análisis posterior colocar en una celda infinidad de diagnósticos. En el caso de esta BD se usa una tabla auxiliar que está entre la BD importante y otra que lista los diagnósticos. Esta tabla auxiliar no tiene un campo de “auto-ID”, por lo que los ID de la BD importante se repiten la cantidad necesaria de veces según cuantos diagnósticos existen.

Por lo tanto, una vez que se requiera algún informe o salida de resultados, probablemente el sistema busca en esta tabla auxiliar el ID de la observación en cuestión y lista el(los) diagnostico(s) asociados a ese identificador. Lamentablemente esto sólo ayuda para las consultas rígidas y programadas por lo que planteo como solución:

Exportación de la tabla importante y las dos auxiliares.
Exportar a csv para su lectura posterior en R
Crear “colnames” en R con cada diagnóstico de ambas tablas auxiliares
Crear un programa if-else-then para rellenar en la BD importante de R los TRUE o FALSE para cada observación de las columnas creadas

Todo lo anterior permite tener un BD con todos los parámetros para un clásico análisis descriptivo y/o estadístico. Cabe destacar que las tablas auxiliares están diseñadas por dos columnas: El ID del paciente (sin relación establecida) y el código del diagnóstico (con relaciones) con la tabla que posee el mismo código con el nombre del diagnóstico.
Al momento de exportar los datos se pierde en la misma los valores de la extensa epicrisis e indicaciones que sería interesante rescatar para futuro, quizás en R alguna función print() donde sólo considere el ID del paciente y su epicrisis.
Por último, como cotejación de datos, sería interesante imprimir las epicrisis (formateadas y lindas por el programador) donde aparecen todos los datos de la hospitalización con categorías absolutas y la epicrisis. De esta forma se debería leer la epicrisis y corregir los datos absolutos que presenten incongruencias, para luego actualizar la BD con los datos categóricos corregidos. Dentro de este proceso sería necesario un write.csv(x) y su posterior lectura una vez corregido.
Llama la atención que las distintas categorías las cuales se puede optar al momento de llenar información de los pacientes están definidas dentro del mismo campo en la vista diseño de Access, perdiendo de esta forma las relaciones y por lo tanto la posibilidad de filtrar datos.
NOTA: No faltaba…. Al momento de exportar la BD grande a texto elegí las opciones por default, donde la coma (“,”) era el separador de campos. El sistema me arrojaba el error de que coincidía con el separador de decimales del sistema, por lo que no se podía exportar. Finalmente elegí usar punto y coma (“;”) para este efecto, por lo que se debe recordar cuando se proceda a leer el archivo (que además es .txt) en R.