En busca del buen buscador
Mientras que la mayoría de la prensa técnica se enfoca en documentos no estructurados, al igual que en tecnologías de búsqueda de lenguaje extensible de marcas (XML) y lenguaje de marcas de hipertexto (HTML), la verdad que no se da a conocer sigue siendo que más del 80 por ciento de las aplicaciones comerciales de hoy en día requieren una interacción con la base de datos relacional. Como Terry Moriarty mencionó en la conferencia Software Development West Conference del 2004, la organización se trata de la base de datos". El otro esqueleto en el closet de los datos, o el penoso secreto de la industria, es que existe muy poca ayuda de búsqueda para el usuario comercial cuando se trata de localizar la información corporativa en las bases de datos. Y debido a que localizar cuentas de información para el 25 al 35 por ciento del tiempo de un usuario de información, la falta de enfoque en la búsqueda de las bases de datos resulta en un punto ciego de productividad en la atención corporativa y de los medios.
La gran parte de la razón de este punto ciego recae en el doble significado (y algunas veces confuso) del término búsqueda cuando se aplica a las bases de datos: esto puede significar datos, o puede significar metadatos (en otras palabras, la categoría comercial de los datos, como nombres de tablas y de columnas, y descripciones). Históricamente, una búsqueda a nivel de la base de datos significa una pregunta de datos, o específicamente, un lenguaje de preguntas estructurado (SQL), contra una tabla o grupo de tablas. Por lo tanto, la meta tecnológica tradicional de los proveedores de software fue hacer SQL más sencillo de generar, a través de tutoriales, analizadores sintácticos de lenguaje natural, etc. El santo grial o la meta última del acceso a datos es: sólo haga la pregunta comercial, y nuestro producto hará la pregunta De igual forma, la meta de los entrenadores de tecnología de la información (IT) y de los administradores era educar a los usuarios a desarrollar habilidades SQL para reducir su dependencia en los programas.
¿Cuál es el problema?
A pesar de que los usuarios puedan componer left outer joins (datos contendidos en el lado izquierdo de una tabla definida), el problema de localizar la base de datos, tabla y columna correcta (contra la cual preguntar o reportar) en una empresa de bases de datos múltiples (con frecuencia con miles de tablas y varios miles de columnas) puede ser enorme. Este aspecto del problema de búsqueda, la búsqueda antes de la búsqueda, se describe como el problema de la búsqueda de metadatos: ¿en qué base de datos, esquema, tabla o columna está la información? Los usuarios comerciales hacen preguntas características al buscar algo: Si quiero preguntar por las comisiones totales al mes, ¿dónde debo buscar para encontrar las comisiones de me personal de ventas? Si quiero crear un reporte de ventas por productos, ¿dónde encontraría las órdenes de venta de mi cliente? Y como un analista IT; si quiero integrar los datos de nuestro cliente, ¿dónde encontraría la dirección del cliente?
Este problema de búsqueda de metadatos está compuesta de más del mero tamaño y la distribución de los datos, consta de amplias variaciones en el diseño de metadatos y en el etiquetado. Los vocabularios variados y arbitrarios, los léxicos, y los formatos dispersos entre los nombres de las tablas y las columnas, todo contribuye al reto de localizar los metadatos correctos previos a las preguntas, al reporte y a la integración real de datos.
Existen soluciones estándares para este problema de búsqueda de metadatos: (a) estar en la compañía por mucho tiempo para conocer la localización de todo; (b) llamar a un programador que esté familiarizado con la base de datos comercial y las tablas en cuestión; (c) navegar a en la lista de esquemas o exploradores para cada base de datos, abrir cualquier tabla candidata que se vea sospechosa; o (d) pedir un catálogo de todas las posibles combinaciones de estructuras semánticas y léxicas. El demonio de los metadatos es incluso más intimidante si es un consultor de viajes nuevo para los almacenes de datos de los clientes (¿a quién va a llamar?).
Un vaso medio lleno
La introducción de los datos estandarizados o ejemplares, sinónimo de diccionarios, y de los repositorios ayudaron a aliviar esta pena al centralizar todos los metadatos y proporcionar un vocabulario con un lenguaje más natural. Sin embargo, todavía existen inconvenientes en este acercamiento. Estos diccionarios por lo general necesitan construirse de forma manual y referenciadas de forma cruzada con sus respectivas bases de datos fuentes. Con miles de elementos comerciales, esto puede ser una ardua tarea por inaugurar, y mantener. Y más importante, gran parte del problema de la búsqueda sigue siendo, ¿cómo localizar el metadato deseado de forma rápida y entre innumerables elementos? Un explorador de esquemas en un diccionario de metadatos es casi tan extenso como su contraparte la fuente nativa. La búsqueda de frases o carácter de sustitución todavía reta al sistema y el diseñador del diccionario para su rango en variaciones léxicas y de sinónimos.
La meta, por supuesto, es hacer la búsqueda de los metadatos de la base de datos es tan sencillo y dinámico como una búsqueda Web, pero con la habilidad agregada para acomodar los problemas únicos de la estructura de los metadatos de las bases de datos. Las herramientas que pueden ayudar a lograr esta meta son tan importantes y útiles como las herramientas que ayudan a abstraer las complejidades de la generación de SQL por parte del usuario final. Idealmente, la meta final de la recuperación de información de la base de datos es una herramienta dinámica (sin la intervención IT) que esconde por completo tanto los metadatos y las SQL de los usuarios comerciales. Sin embargo, las amplias variaciones de los metadatos (a pesar de la sintaxis de las SQL) retará este ideal, posiblemente por algún tiempo. Un programa puede ayudarle al usuario a realizar conjeturas calculadas de metadatos correctos, pero por último el ojo y la mente humana necesitarán involucrarse.
Los administradores que se enfrentan a problemas complejos de la gestión de metadatos necesitan estar concientes de que además del gran problema de integrar y recuperar metadatos y datos dispersos en documentos y XML; el problema de de las búsquedas y del acceso de metadatos y datos en las bases de datos para los usuarios finales también es de gran importancia. Se deben terminar los días en los que se llamaban a los programadores (o almacenistas de datos claves) al rescate cada vez que se necesitaba una pregunta o un reporte comercial. ¿Dónde guardamos los datos de contacto del proveedor? es una pregunta para los analista de sistemas y es una pregunta muy buscada en los metadatos de las bases de datos.
El reto de los datos de Mazda y su solución
Esta pregunta se ha eliminado casi por completo en Mazda Norteamérica, gracias a MetaTrieve, la herramienta de búsqueda de metadatos de lenguaje natural de MetaTrieval Software. Mazda Norteamérica es un fabricante automotriz de equipo original (OEM) que vende autos y camiones a través de una red de más de 700 comerciantes a través de Estados Unidos y Canadá. La especialidad de Mazda es vehículos divertidos de manejar con una orientación a los autos deportivos. El nuevo CX-7 y MAZDASPEED 6 son vehículos representativos de Mazda, y están muy bien retratados en los comerciales "zoom-zoom" de Mazda, que muestran a un joven susurrando "zoom zoom" mientras conduce un Mazda.
Para soportar las ventas y el servicio del vehículo y de sus partes, Mazda mantiene múltiples bases de datos de varios vendedores y opera en una gran variedad de plataformas. Esto incluye un marco de trabajo del procesamiento de transacción en línea (ILTP) una base de datos universal de comercio electrónico (UDB) para soportar MazdaUSA.com. Para el soporte de campañas de mercadotecnia y reportes, Mazda utiliza una base de datos del servidor SQL (que también soporta el sistema de respuesta KANA eMail), y para agentes de asistencia al cliente, utiliza una base de datos SQL de gestión de las relaciones con los clientes (CRM). Una base de datos UDB soporta las ventas y el servicio del concesionario, una base de datos SQL compartida con Ford Motor rastrea problemas de seguridad y múltiples bases de datos de Access departamentales soportan el negocio.
Los analistas comerciales, auditores analistas de tecnología de la información (IT), y programadores en Mazda necesitan generar un gran número de preguntas y reportes ad hoc para el soporte de análisis y la planificación de iniciativas comerciales y objetivos del concesionario. Sin embargo, la información que necesitan puede distribuirse y duplicarse a lo largo de varias bases de datos, con vocabularios no estándares para elementos comerciales en tablas y columnas. Aquí el reto es localizar la información a través de la empresa antes de preguntar, reportar, integrar o almacenar los datos. La dificultad de este reto recae en la gran inmensidad de pasos involucrados en la tarea:
- Examinar a través de silos de impresiones de bases de datos, esquemas o modelos.
- Abrir cada tabla en una herramienta de navegador de esquema o de Explorer.
- Intentar múltiples búsquedas de catálogo contra múltiples bases de datos.
- Llamar a un programador o a un administrador de bases de datos (DBA) que esté familiarizado con el área comercial.
Para resolver este reto, Mazda instaló MetaTrieve en el 2004. Al utilizar MetaTrieve, el usuario IT o comercial simplemente ingresa el elemento comercial para buscar (por ejemplo, la fecha de compra de un vehículo) y MetaTrieve localiza la base de datos, la tabla y la columna en segundos. El usuario ahora conoce dónde se almacena la información. Un ejemplo específico de tarea ilustra un problema de descubrimiento de datos muy común y dos preguntas muy comunes en el negocio: ¿Tenemos estos datos en la compañía? ¿Dónde están?
Mazda y sus socios de campaña de mercadotecnia decidieron ejecutar una campaña de servicio para incitar a los clientes a visitar a las concesionarias Mazda autorizadas para un servicio automotriz. La fecha límite para la extracción de datos se aproximaba rápidamente, y todavía faltaba la pieza final de la información que se tenía que incluir en el material de mercadotecnia, las horas de servicio de la concesionaria. Nadie en el grupo de mercadotecnia estaba seguro si los datos se encontraban ahí, y si sí, en qué base de datos, tabla y columna estaban. Alguien en la compañía sabía, pero ¿quién era esa persona? ¿Sería necesario llamar a cada programador que trabajó con los sistemas de servicio de la concesionaria?
Un usuario que tenía instalada MetaTrieve fue capaz de acelerar las cosas. El usuario llevó a cabo una simple búsqueda de las horas de servicio de la concesionaria a través de la empresa y encontró la información en segundos. El extracto del archivo de campaña estuvo completo y a tiempo para su entrega al cliente.
El mundo y todo lo que hay en él
Ahora más que nunca, los usuarios de información comercial tienen necesidades de datos urgentes, y grandes expectativas con respecto a las tecnologías de búsqueda de leguaje natural y fáciles. La Web y las compañías como Google y Yahoo! los han malcriado en este aspecto. Los usuarios con frecuencia asumen que esta misma facilidad de búsqueda se debería extender a la base de datos y a sus metadatos, y los directores esperan que tal solución no sea cara y que requiera poco mantenimiento. Estas suposiciones recientemente se han completado con constructores de preguntas en lenguaje natural y tecnologías de búsqueda de metadatos en las bases de datos. Se acerca el momento de una búsqueda empresarial completa.
Acerca del autor
Daniel Oldis (doldis@metatrieval.com) es cofundador y presidente de tecnología de Meta Trieval Software, LLC. Ha trabajado como consultor de software, maestro y autor por veinticinco años, y ha publicado en Software Development y Enterprise Systems Journal.