El siguiente artículo corresponde al capítulo 2 del Manual para Instructores de Winisis, editado por CNEA
2. ¿Por qué ISIS? por Norberto Manzanos
A los que trabajamos con ISIS nos suelen plantear esta pregunta, tanto los informáticos y los gerentes, como a veces también los bibliotecarios: "¿Por qué ISIS?". Si contamos con el suficiente respaldo como para que se confíe ciegamente en nuestras decisiones podremos responder "¿Por qué no?"- poniendo en un apuro a nuestro interlocutor, que deberá recitar los prejuicios adquiridos a lo largo del tiempo con mayor o menor convencimiento. Pero en la mayoría de los casos tendremos que justificar lo más posible nuestra decisión y echar mano a una serie de argumentos rutinariamente establecidos que deberemos adecuar lo más posible a los conocimientos de nuestro interlocutor.
Ahora bien, la situación actual de la informática es bastante menos clara que hace unos años y no es tan fácil justificar el uso de un software u otro. Las soluciones que brindan los distintos paquetes abarcan aspectos tan diversos que sus áreas se superponen frecuentemente.
Siendo MicroISIS una aplicación para bases de datos, toda explicación debe partir de ubicar este software en el ámbito de este tipo de aplicaciones. Cuando se habla de sistemas de información se suele hacer la distinción entre IRS (Information Retrieval System) y RDBMS (Relational Data Base Model System). Los IRS también son llamados bases de datos documentales o bases de datos textuales u orientadas a texto. Una comparación exhaustiva entre ambos tipos de sistemas excede los límites de esta exposición, pero se intentará dar una aproximación muy resumida al problema, mediante una breve explicación del modelo relacional de bases de datos, tomando prestados algunos conceptos del modelo entidad/relación, a los fines expositivos por un lado, y un vistazo de los aspectos principales de la solución ISIS dentro del ámbito de las bases de datos documentales, por el otro.
En ambos casos, se tomarán en cuenta dos aspectos: la representación de la información, entendiéndose por esto la forma de estructurar los datos y la recuperación de la información.
Considerando lo expresado sobre la diversidad de soluciones de software existente, se intentará superar la distinción entre ambos tipos de aplicaciones, que tal vez es hoy por hoy un poco anacrónica, precisando la ubicación de MicroISIS dentro de las tendencias actuales.
Finalmente, se mencionarán algunos aspectos sobre el tema de los costos a ser tenidos en cuenta a la hora de decidir que tipo de sistema implementar.
Representación de la información
Muy suscintamente, una base de datos es una colección de entidades diversas, entre las cuales se establecen ciertas relaciones. Cada entidad posee uno o más atributos. Estos atributos se denominan, por analogía con una planilla, columnas (campos) y cada entidad configura una fila (registro). Las entidades de un mismo tipo configuran una tabla y cada entidad debe tener al menos una columna que la identifique unívocamente (clave primaria). Las relaciones entre distintas entidades se establecen mediante columnas creadas exclusivamente para tal fin (claves foráneas). Las relaciones tienen una determinada cardinalidad, es decir cuántos elementos de una tabla se relacionan con cuántos de la otra. Las posibilidades son básicamente 3: de uno a uno, de uno a muchos o de muchos a muchos.
Como surge de la analogía con la planilla, las columnas tienen una determinada longitud, a la cual deben ajustarse los datos. Se accede con rapidez a los datos mediante la confección de índices, que pueden mas de uno por tabla y pueden construirse con un único campo o con varios campos encadenados.
Las bases de datos han incorporado formas de introducir campos donde la longitud, o bien puede ser variable, o bien puede ser demasiado grande (como las campos memo, los campos BLOB, etc). Sin embargo, este tipo de datos no poseen la misma jerarquía que los otros. No es posible crear índices con estos campos.
Finalmente, mediante leyes de normalización, las bases de datos reducen la redundancia partiendo una tabla en varias, y estableciendo nuevas relaciones. Por ejemplo, para representar una relación muchos a muchos, es necesario crear una tabla intermedia, llamada tabla de relación, que posée una relación uno a muchos con cada una de las dos tablas. De esta forma, al introducir elementos abstractos y subdividir entidades, el modelo empieza a perder su grado de representatividad de la realidad, ganando en consistencia y estructuración.
La fig 1 muestra un ejemplo de representación tabular.
| TITULO | AUTOR | EDITORIAL |
| Bestiario | Cortázar J. | Sudamericana |
| El Hacedor | Borges J.L. | EMECE |
| Adán Buenosayres | Marechal L. | Sudamericana |
Fig 1. Ejemplo de bases de datos tabular
La fig 2 muestra un ejemplo de una base de datos bibliográfica mínima (sólo se considera los títulos, autores y datos de publicación) en donde se observan diversas tablas relacionadas. Se trata de una base de datos normalizada, por lo que se ha llegado a que cada dato configura una nueva tabla, e incluso ha sido necesario definir una tabla intermedia para la relación título/autor, dado que esta relación es una relación de muchos a muchos (Un título puede tener varios autores, un autor puede serlo de varios títulos). Los campos subrayados son las claves primarias de cada tabla, mientras que los campos que comienzan con 'FK' son las claves foráneas (foreign key). Obsérvese también que en la definición están indicadas las longitudes de los campos character.
Fig 2. Esquema RM de bases de datos bibliográfica mínima
MicroISIS, y las bases de datos documentales en general, en una primera mirada, no responden a este modelo. Los campos son de longitud variable: se pueden crear índices por cualquier campo e incluso por partes de campos, no requiere una clave primaria, no utiliza varios índices, sino un índice único en donde pueden figurar todos los campos (archivo invertido). Algunas bases de datos documentales, así como WWWISIS e ISISDLL y tal vez Winisis en el futuro, soportan la creación de varios archivos invertidos, con lo que manteniendo las ventajas del modelo de recuperación textual, se accede también a la posibilidad de acceder a índices por campo, como en las RDBM.
La representación de entidades distintas, con una relación de uno a muchos se produce con la definición de campos repetibles. Dado que los campos son de longitud variable, esto facilita la situación de que un campo posea o no información en un determinado caso. Simplemente el campo no posée ninguna información sin producirse derroche de memoria. Los campos pueden dividirse en subcampos, con lo cual no se cumple las premisas de normalización mencionadas.
Se puede apreciar por qué este modeolo es más apropiado para el tipo de información textual, en donde el título de un libro puede tener 2 caracteres o 300; en donde un dato que se quiere conservar dentro de un mismo ámbito, como los datos de publicación, puede a su vez dividirse en partes como lugar de publicación, editorial y fecha; en donde algunos documentos pueden tener extensos resúmenes y otros ninguno en absoluto; en donde puede haber un autor o varios, todos con la misma categoría, etc.
En una segunda aproximación, MicroISIS permite establecer relaciones entre tablas, mediante el comando REF. En este caso responde al modelo relacional, al menos en algunos aspectos, y se precisa una clave primaria y una clave foránea.
Sin embargo, como no es el relacional, el modelo que se ha tomado para desarrollar ISIS, ésta posibilidad está lejos de brindar la seguridad y consistencia que dan las bases de datos relacionales. Hasta la versión DOS esta definición de varias tablas se establecía en un nivel lógico, alojándose las tablas en un mismo archivo físico. Con la versión actual, las tablas pueden estar en distintas unidades físicas (bases de datos, en terminología ISIS).
Esta novedad, por un lado amplía las posibilidades de ISIS, dado que si bien las bases de datos tradicionales no se adaptan al material documental, también es cierto que es necesario poder establecer relaciones entre entidades, y es de esperar que éstas sean consistentes. Tal vez en un futuro cercano se pueda contar con alguna herramienta para establecer relaciones estables y consistentes en bases de datos ISIS.
La fig 3 muestra la definición de la misma base de datos del ejemplo anterior en MicroISIS.
Titulo 10 500 0 0
Autor 20 100 0 1
Publicación lef 30 100 0 0
Fig 3 Ejemplo de definición de base de datos ISIS (archivo FDT)
El otro punto crucial a tener en cuenta es la recuperación de la información, algo que es de vital importancia a la hora de pensar en un sistema documental.
Las bases de datos relacionales utilizan un lenguaje de consulta, SQL , que permite recuperar la información de las distintas tablas y columnas, aplicando todo tipo de operadores, ordenamiento, etc. El resultado de una consulta SQL es una tabla que cumple los criterios indicados. Eventualmente, esta tabla podrá configurar una vista, que es una forma de ver sólo una parte de una base de datos, usualmente a través de una consulta SQL, de manera que queda establecida una nueva tabla sobre la cual se podrá operar realizando modificaciones o consultas.
Como se adivinará este lenguaje es relativamente complejo, dada su gran potencia, su uso no está restringido a la recuperación de información, y requiere un conocimiento amplio de la estructura de la base de datos. Por consiguiente, se requiere la confección de una interfase de consulta para usuario en una aplicación en donde una eficaz recuperación de la información sea prioritaria. Como se vió anteriormente, si se desea recuperar por cualquier campo deben definirse tantos índices como campos hubiere. Las combinaciones de distintos campos que pueda realizar el usuario deben estar definidas de antemano.
La siguiente es una consulta SQL para la base de datos del ejemplo, cuyo fin es recuperar todos los documentos que publicó Julio Cortázar en la editorial Sudamericana y mostrar todos los demás datos (lugar de edición y fecha).
SELECT LIBROS.TITULOS, AUTORES.APELLIDO_Y_NOMBRE,EDITORIALES.EDITORIAL, CIUDADES,CIUDADES.CIUDAD, FECHAS.FECHA
FROM LIBROS,AUTOR, EDITORIALES,CIUDADES
WHERE AUTOR.APELLIDO_Y_NOMBRE='Cortazar' AND
EDITORIALES.EDITORIAL='Sudamericana' AND
LIBROS.IDTIT=LIBAUT.FKIDTIT AND
AUTORES.IDAUT=LIBAUT.FKIDAUT AND
LIBROS.IDFECHA=FECHAS.IDFECHA AND
LIBROS.IDEDI=EDITORIALES.IDEDI AND
LIBROS.IDCIU=CIUDADES.IDCIU
Siendo la consulta que se pretende realizar por demás sencilla, se puede apreciar claramente la complejidad del código SQL que deberá escribirse.
La fig 4 muestra la salida que produce la consulta, que no es más que una tabla que contiene la información solicitada.
LIBROS.TITULOS AUTORES.APELLIDO Y NOMBRE EDITORIALES.EDITORIAL FECHAS.FECHA
Rayuela Cortázar J. Sudamericana 1962
Bestiario Cortázar J. Sudamericana 1960
Fig 4. Ejemplo de visualización
En esto MicroISIS también se diferencia notablemente de este modelo. Como se vió, hay un único índice, por lo que sólo es necesario definir una vez por cuales campos se desea recuperar. No es necesario confeccionar programas, sólo hace falta crear archivos de definición que pueden ser modificados en forma bastante sencilla. Otra diferencia fundamental es que MicroISIS tiene un lenguaje de consulta bult in, es decir, un lenguaje construido dentro del programa, que no requiere de conocimientos de la estructura de la base de datos (al menos en una primera aproximación) y que está pensado exclusivamente para satisfacer las necesidades de recuperación de la información. También tiene la posibilidad de recorrer el índice y realizar las consultas a partir de datos positivamente existentes y no dejar sujeta la respuesta de la consulta a la exactitud del tipeo.
La misma consulta que en el ejemplo anterior, en el lenguaje de recuperación de ISIS es :
CORTAZAR$ * SUDAMERICANA
y suponiendo el formato
"Título: "V10/,"Autor: "v20/,"Publicación: "v30^l,", "v30^e,": "v30^f/##
se obtendría el resultado mostrado en la figura 5.
Título: Rayuela
Autor: Cortázar J.
Publicación: Bs.As., Sudamericana, 1962
Título: Bestiario
Autor: Cortázar J.
Publicación: Bs.As., Sudamericana, 1960
Fig 5 Ejemplo de visualización
La sencillez del ejemplo habla por sí misma. Pero también debe tenerse en cuenta que mientras en el ejemplo en SQL se realizan 7 accesos a índices distintos, en el ejemplo en ISIS sólo se abre un índice y se buscan dos términos.
Por su orientación a material textual, MicroISIS incorpora técnicas para generar índices por palabras dentro de un campo. También pueden generarse índices por palabras marcadas, de manera que el usuario decide cuáles son los elementos significativos que formarán el índice. Otra posibilidad de MicroISIS y las bases de datos documentales en general es la posibilidad de reconocer sinónimos. Todo esto es imposible sin programación adicional en las bases de datos tradicionales.
Todo lo dicho sobre ambos modelos de bases de datos no agotan, ni remotamente, este tema. Se pueden hacer más precisiones en cuánto a ventajas y desventajas de uno u otro modelo, pero, por un lado, una discusión tan exhaustiva excede los límites de este artículo y por otro, tal vez se trata de una dicotomía que el tiempo y las nuevas tecnologías están superando.
Todo lo dicho es válido, como se aclaró, si hacemos la comparación con bases de datos tradicionales. Pero actualmente estos modelos están en crisis, pues no responden a muchas necesidades nuevas: archivos de imágenes, herramientas CAD, CASE, etc, no pueden ser correctamente implementadas con el modelo relacional. Asimismo, no resulta sencillo ni práctico brindar soporte a los requerimientos de las tareas administrativas, que conviven con las necesidades de recuperación de información textual, con bases de datos documentales.
Se presentan dos posibles soluciones: sistemas híbridos o bases de datos orientadas a objetos.
Por sistemas híbridos se entiende sistemas que tienen las ventajas, tanto de un IRS como de un RDBMS. Un sistema tal puede construirse utilizando bases de datos ISIS y algúna base de datos relacional, utilizando ISISDLL, por ejemplo, para programar la interfase entre ambos.
La otra solución es el modelo orientado a objetos. La ventaja de la orientación a objetos es que ésta pretende modelar la realidad, de tal manera que un objeto es la representación de una entidad real (tangible o abstracta) lo cual acerca la abstracción del diseño a la visión intuitiva del usuario. La representación de un documento, como un objeto llamado documento, con sus atributos y comportamientos propios, es mucho más cercana a la realidad y a los usuarios que una enormidad de tablas cuidadosamente sincronizadas, que sólo puede ser modificada por un experto: su diseñador.
No existen actualmente muchas aplicaciones comerciales que brinden una implementación completa de este modelo, que curiosamente, se aproxima en su estructura física a MicroISIS, dado que la forma de representar objetos persistentes en un soporte físico es mediante estructuras de longitud variable, que permitan relaciones. Esto hace pensar que en el futuro, MicroISIS se asimile a este modelo, dado que en este programa, finalmente, trabajamos partiendo del concepto de que un registro representa la entidad que más nos interesa, por ejemplo, un documento, una metodología que se aproxima bastante al concepto de objetos. En el dinámico mundo del software, es bien posible que MicroISIS termine siendo un precursor de nuevas tendencias, más que un continuador de conceptos superados, y esto será, en gran parte, obra de los desarrolladores y docentes.
Otro argumento, muy relacionado con todo lo dicho, es la cuestión del costo. Más allá de que MicroISIS es de distribución gratuita, mientras que otros paquetes de bases de datos pueden costar desde cientos a miles de dólares, cuando se habla de costo se debe hacer un análisis detallado de otros aspectos que el mero valor comercial de un producto.
En general, los costos de desarrollo son directamente proporcionales a los costos en hardware y software de base. Consecuentemente, los costos de una implementación de bases de datos MicroISIS son menores que con otros paquetes. Cuando se habla de MicroISIS, se habla en este caso de la "familia" ISIS, compuesta por otros programas, aparte del Winisis en sí. En otros capítulos de este manual se habla de, por ejemplo, WWWISIS e ISIS_DLL, dos aplicaciones de BIREME, una para publicación de bases de datos ISIS en la Web y la otra, una serie de bibliotecas para programación de alto nivel utilizando bases ISIS. Paquetes como estos (por ejemplo ISISWEB o IQUERY), o bien son gratuitos, o bien son de bajo costo. Pero el aspecto que a veces se soslaya es que los costos de los desarrollos utilizando estos paquetes también son menores. Considérese que las aplicaciones comerciales para bibliotecas, paquetes integrados que pretenden abarcar tanto las necesidades de recuperación de la información, como las de índole administrativa, rondan los miles y aún cientos de miles de dólares, mientras que en una aplicación basada en ISIS apenas sobrepasan el millar, en el peor de los casos. La instalación de un sistema de consultas, altas y modificaciones de una base de datos bibliográficas, en una ambiente multiusuario implica, para un experto en ISIS, algunos días de trabajo (si utiliza algunos de los formatos de base de datos comunes); no hay costo de análisis, diseño y programación. El costo de un desarrollo similar con bases de datos relacionales implica diseños complejos, con decenas de tablas, interfases que requerirán un estudio muy detallado de los requerimientos de consulta de los usuarios y una programación consecuentemente compleja. A esto hay que sumarle el costo de un motor de bases de datos y el hardware que lo soporte.
Con las otras herramientas de la familia ISIS, se pueden realizar desarrollos para Internet o aplicaciones que cubran necesidades específicas, que si bien demandan un tiempo mayor, y por consiguiente, tienen un costo también mayor, éstos siguen siendo menores que utilizando otros paquetes.
Esta explicación ha tratado de demostrar la idoneidad de ISIS para cierto tipo de aplicaciones, a saber, las que giran en torno a documentación y a una eficiente recuperación de la misma. Pero no siempre este tipo de aplicaciones están aísladas de necesidades administrativas. Hasta la versión 3.08, este nicho sólo podía ser cubierto por programas realizados con el lenguaje nativo de ISIS, ISIS Pascal, que resultaba muchas veces insuficiente, sobre todo por las limitaciones de memoria heredadas del DOS. Si durante años los programadores de aplicaciones para bibliotecas se encontraron con programas muy pobres desde el punto de vista de la recuperación, realizadas en los paquetes comerciales estándar, también, por dar prioridad al aspecto recuperación, se llegaba a la situación inversa, en donde excelentes sistemas de recuperación, debían convivir con sistemas administrativos lentos e inecesariamente complejos. Actualmente, con Winisis y con todos los programas de la familia ISIS, ésta situación puede ser totalmente superada. Nada impide que bases de datos bibliográficas ISIS convivan con sistemas de gestión desarrollados con motores cliente/servidor o bases de datos ODBC; no hay impedimento, tecnología OLE mediante, para que los textos procesados con criterio de base de datos, que permitan recuperar, por ejemplo, palabras combinadas con operadores booleanos, sean trabajados desde el punto de vista de la edición, con procesadores de texto o paquetes de autoedición; no es imposible construir bases de datos de textos, imágenes, sonidos, videos, etc, que incluyan los documentos completos y que éstos puedan ser editados con sus herramientas específicas, sin por ello perder la posibilidad de una descripción adecuada y una consiguiente recuperación eficiente.
El viejo sueño de la enciclopedía universal, traído al mundo real por la red de redes, no necesariamente deba engendrar monstruos. Es posible organizar el caos, se pueden realizar cambios cualitativos sin perder las ventajas que brinda lo meramente cuantitativo.
La tendencia actual del software, y parece saludable que así sea, apunta más a la utilización de la herramienta adecuada para cada caso, y a la mayor colaboración posible entre las mismas, que a la formación de monopolios (de un software, de un formato, de un microprocesador, de un lenguaje, etc) en donde todo se realiza dentro de un único y esclavizante marco de referencia.
BIBLIOGRAFIA
Korth, H.F., Silberschatz, A. Fundamentos de bases de datos. McGraw Hill, USA, 1992
Los sistemas integrados de gestión bibliotecaria. Moya Anegón, F. Madrid: ANABAD, 1995
Por qué MicroISIS?; Bases de datos textuales versus bases de datos relacionales. Deco, A; Bender, C.; Crespo F. INFOISIS vol1 (1) jul, 1995. p 42