¿Tiene sentido indexar por pares (atributo, valor) una base de datos relacional ?

En este artículo se defiende la tésis de la utilidad que como complemento a un gestor de base de datos relacional de un motor de indexación, en el que los token de búsqueda son pares (atributo, valor) y los objetos búscados son los registros de la base de datos.

Por simplicidad, supongamos que tenemos una única tabla, por ejemplo clientes, que contiene N registros, con M atributos o campos por registro. Los objetos que jugarán el papel que en los sistemas de búsqueda de información tradicional corresponde a los documentos, en este caso se corresponderán con registros de la tabla. Los "tokens" por los que se indexan los elementos serán los pares (atributo, valor). El equivalente a una consulta de texto de redacción libre, para este caso, es un conjunto de pares (atributo, valor), que pude considerarse como un patrón de búsqueda de registros de la tabla.

Dada una consulta, por ejemplo (Provincia=Madrid, Apellidos="Pérez Gómez", Moroso=No), el sistema constuirá el vector de tokens, de manera análoga al modelo TF-IDF de la teoría vectorial de términos, y recuperará los registros que más se asemejen a dicho patrón, utilizando como medida de semejanza vectorial la medida COSIM (producto escalar).

En http://en.wikipedia.org/wiki/Tf%E2%80%93idf, puede encontrase una introducción a los conceptos de la teoría vectorial de términos. Lo aquí expuesto es una generalización que no exige desarrollos ni aplicaciones específicas. Podría utilizarse cualquier sistema de recuperación de la información. Para ello bastaría seguir estos pasos:

1. Generar un documento por cada registro de cada tabla de la base de datos a indexar.
2. Por cada tabla y para cada registro, generar un "documento" en el que las "palabras" son la concatenación del nombre de tabla, con el nombre del campo seguido del valor, concatenando los elementos con el carácter "_", y sustituyendo los espacios en blanco por |
3. Lo que resta es cargar los documentos (confiando que el tokenizador del motor no suprima las "palabras" generadas en el punto 2 como términos descriptores de cada registro. Como clave o URL del documento se pondrá el valor de la clave del registro en la base de datos.
4. En la consulta, bastaría con poner los tokens por los que queremos buscar.

Esta es una primera aproximación que puede dar idea de la utilidad. Para incorporarlo en aplicaciones de usuario final, habría que cuidar el interfaz para facilitar la construcción de las "consultas".

Finalmente, cabe pensar en múltiples mejoras. Por ejemplo, añadir como términos al documento descriptivo de cada registro, las palabras encontradas dentro de los valores de los campos con contenido texto.

Cualquier comentario, opinión, crítica, etc..., es bienvenida.

Text-mess

El proyecto Text-mess nace con la vocación de crear la tecnología base en la que se apoyen los buscadores del futuro. El planteamiento , por lo que he podido deducir de la escasa información que todavía figura en su página, es integrar tecnología de procesamiento de lenguaje natural, recuperación de información e inteligencia artificial, para conseguir no ya localizar los documentos que puedan figurar indexados por los términos de la consulta ordenados en base a una puntuación basada en criterios de similitud con la consulta y la relevancia del propio documento, sino dar un paso más e intentar deducir cual es el propósito del usuario. Así, si preguntaramos a un sistema de información con un interfaz de este tipo "Población de la Comunidad de Madrid, contestaría, si ese dato figurase en la base de conocimiento con el número de ciudanos que viven en la Comunidad de Madrid, es decir cerca de 6 millones, en lugar de facilitar una serie de documentos que incluyan los términos de consulta y que por algún algoritmo hayan obtenido una alta puntuación (page rank).

Todavía se muy poco de este proyecto, el objetivo es ambicioso y los participantes muchos de de muchas universidades españolas. Confiemos que pronto empiece a dar resultados y atraiga suficientes recursos para que contribuya al desarrollo de esta tecnología.

Ejemplo

A modo de ejemplo del modelo de interfaz de acceso a una compleja base de datos estructurada, imaginemos el repositorio formado por todas las base de datos de un banco, con datos sus clientes, empleados, productos, proveedores de servicios, etc... Lo lógico es que haya un conjunto de sistemas transaccionales, que gestionen el flujo de información (altas, bajas y modificaciones), y que dicha información se vuelque, en su totalidad o parcialmente a un datawarehouse periodicamente para análisis. Centrándonos en el datawarehouse, típicamente se utilizará un motor OLAP, que presente la información organizada en atributos categóricos, dimensiones y magnitudes, facilitando la realización de operaciones de desglose, agregación etc...

Si se quiere volcar toda la información del banco, es fácil que se tengan varios miles de dimensiones y magnitudes, dificultando encontrar aquellas con las que se quiere operar. Ahora imaginemos que toda la metadata, datos acerca de los datos, contenida en el diccionario del motor OLAP se utiliza para alimentar un motor de indexación de los objetos del datawarehouse, a partir de los términos que figuren en las descripciones de los objetos, así como los términos de los valores de los dominios de las dimensiones, e incluso de las magnitudes.

Con los elementos descritos anteriormente es fácil imaginar un interfaz de acceso al datawarehouse tipo google, que a partir de un conjunto de términos, keywords, localize los objetos del datawarehouse a los que se quiere acceder.

Por ejemplo, ante un texto de entrada del tipo Sevilla sucursal 10020, el sistema podría contestar proponiendo realizar un desglose por la variable sucursales y establecer una condición de filtro para con el valor de la sucursal 10020 de Sevilla. O, por poner otro ejemplo, ante un texto pepe.nieto@terracom.es, proponer un filtro sobre las variables, dimensiones, que contengan dicho valor, y recuperar todos los registros de las tablas de hechos con dicho valor en algún campo utilizado para almacenar correos electrónicos.

Si todo lo anterior lo aderezamos con información de contexto, o de un modelo del usuario, que influya en el algoritmo de puntuación del buscador, tendríamos una idea del tipo de sistemas de los que me gustaría tratar en este blog.

Indexación por términos y datawarehouse

La disponibilidad de una creciente capacidad de computo y de memoria ha propiciado el desarrollo de la tecnología de búsqueda de información a partir de términos. El paradigma es google, que se ha convertido en la puerta de entrada al inmenso repositorio de información parcialmente estructurada que es Internet.

Extendiendo este modelo, se están desarrollando sistemas que plantean los sistemas de recuperación de información a partir de términos como interfaces de acceso a grandes bases de datos con información estructurada. Imaginemos que todas las bases de datos de una gran corporación, o de la Administración, sirviesen de fuente para generar los índices inversos de un sistema de recuperación de los objetos de una base de datos tradicional (tablas, atributos, y valores), y que deseamos encontrar si un determinado número de teléfono figura en el repositorio. Con un enfoque tradicional buscaríamos en el catálogo de la base de datos los campos susceptibles de contener un número de teléfono, y lanzaríamos consultas SQL para ver si figura el valor objetivo. Sin embargo, situando un motor de búsqueda que tenga los términos de los valores de todos los campos y de todas las tablas, como índices, y con la tecnología de los buscadores actuales, en cuestión de milisegundos tendremos una referencia a los objetos de la base de datos que contengan dicho valor, en nuestro ejemplo el teléfono.

Este blog nace con el objetivo de recoger información de iniciativas y proyectos que aborden el problema de la sobrecarga de información en el acceso a grandes bases de datos estructuradas mediante la utilización de la tecnología desarrollada en el ámbito de los sistema de recuperación de información.