ES2739810T3 - Procedimiento de consulta de base de datos - Google Patents

Abstract

Procedimiento de consulta de una base de datos por medios informáticos, que comprende las siguientes etapas: - de recepción de una primera solicitud (303) en un primer lenguaje, dirigida a obtener información contenida en la base de datos, estando dirigida dicha solicitud al menos a un objeto que tiene al menos una propiedad representada en la base de datos - de acceso (305) a una representación de la base de datos restringida al menos a un objeto, - de generación (312), a partir de dicha representación y de dicha al menos una propiedad de la primera solicitud, de al menos una segunda solicitud en un segundo lenguaje que está dirigida a obtener la información requerida en la primera solicitud, y - de consulta de la base de datos por medio de dicha al menos una segunda solicitud (313).

Description

DESCRIPCIÓN

Procedimiento de consulta de base de datos

La presente invención hace referencia al sector de las bases de datos. Hace referencia, más concretamente, al modo de consulta de las mismas para extraer información.

Para almacenar información en grandes cantidades y de manera óptima, en lo que respecta a la utilización de los recursos de memoria, los desarrolladores de bases de datos deben diseñar estructuras de base de datos complejas. Las estructuras de base de datos difieren según la aplicación.

Por ejemplo, en el caso de las bases de datos relacionales, el desarrollador debe elegir, en concreto, las tablas a crear, sus atributos, las claves principales, las secundarias y las asociaciones entre las tablas.

Para acceder a una información en una base de datos, un usuario, habitualmente, necesita conocer la estructura de la base de datos para formular una solicitud en un lenguaje más o menos complejo. Un lenguaje de este tipo es, por ejemplo, SQL (acrónimo de «Structured Query Language», «lenguaje de solicitud estructurado»).

Para actualizar las bases de datos de este tipo o para realizar operaciones de mantenimiento, se les asocian sistemas de gestión de base de datos (SGBD).

La utilización y la gestión de los datos contenidos en los SGBD (incluida la base de datos) son realizadas, en ciertos casos, por administradores cuya tarea principal es ocuparse de la totalidad del entorno del sistema (es decir, el sistema que incluye el propio SGBD). La utilización de la información presentada en la o las bases de datos, por ejemplo, permite conocer el estado de una red, las máquinas disponibles, la actividad presente y pasada del sistema u otros.

Los administradores del sistema están a cargo no la administración de la parte SGBD, sino del entorno que la contiene, y, generalmente, no tienen como actividad principal la matriz del conjunto complejo que constituye el SGBD.

Estos usuarios del SGBD necesitan acceder a la información sin tener que conocer la estructura de la base de datos ni el conjunto de las reglas que rigen los datos almacenados en la misma.

La implementación de librerías y de una API (acrónimo de «Application Programming Interface», en inglés, «Interfaz de programación de aplicación») especializadas no parece constituir una solución satisfactoria, dado que necesitan un aprendizaje relativamente largo y difícil para el usuario. Además, una API está basada, generalmente, en una librería que propone una lista limitada de funciones y procedimientos que puede ser extremadamente larga, y cuyos parámetros a veces son, en ocasiones, complejos de integrar. Por lo tanto, esta solución es rígida, puesto que la lista de primitivas proporcionada no puede ser modificada por el usuario final, que, si no encuentra la que corresponde a sus necesidades, debe desarrollarla, solicitar su desarrollo o combinar múltiples primitivas a fin de obtener el resultado esperado. Esto puede ocurrir, en concreto, cuando una búsqueda de información llama a varias tablas de la base de manera simultánea («solicitudes de múltiples tablas»).

El documento “QUERY ABBREVIATION IN THE ENTITY-RELATIONSHIP DATA MODEL”, Information Systems vol.

19, N° 6, páginas 491 a 511, 1994 Pergamon Press, ISSN 0306-4379, hace referencia a la utilización de deducciones contextuales para la interpretación de solicitudes por parte de un procesador. Para este propósito, el documento pretende permitir la utilización de solicitudes abreviadas, para simplificar la tarea a un usuario. A este efecto, el documento propone permitir al usuario realizar solicitudes con vínculos implícitos entre diferentes clases de datos. Se dan a conocer algoritmos «de expansión» de las solicitudes abreviadas, pero el documento no dice nada sobre la representación restringida a los objetos de una búsqueda.

Por lo tanto, existe la necesidad de obtener información de una base de datos de una manera simple y flexible, para prescindir de lenguajes específicos dedicados a los entornos de bases de datos y que requieren un conocimiento profundo de la estructura de la base de datos.

Un primer aspecto de la invención hace referencia a un procedimiento de consulta de una base de datos por medios informáticos, que comprende las etapas siguientes:

- de recepción de una primera solicitud en un primer lenguaje, dirigida a la obtención de información contenida en la base de datos, estando dirigida dicha solicitud, al menos, a un objeto que tiene, al menos, una propiedad representada en la base de datos,

- de acceso a una representación de la base de datos restringida, al menos, a un objeto,

- de generación, a partir de dicha representación y de dicha al menos una propiedad de la primera solicitud, de al menos una segunda solicitud en un segundo lenguaje, a fin de obtener la información solicitada en la primera solicitud, y

- de consulta de la base de datos por medio de dicha al menos una segunda solicitud.

La utilización de una representación parcial de la base de datos limitada a un objeto sobre el que se solicita información permite prescindir de la etapa previa que consiste en extraer de la base de datos las tablas que permiten formular una solicitud pertinente.

Para simplificar la consulta, el usuario no está obligado a consultar la base de datos según un lenguaje propio de la misma. Su solicitud puede ser convertida a otro lenguaje.

Según el procedimiento, la consulta de la base de datos se realiza en dos etapas. Con antelación, se analiza la solicitud del usuario, para determinar el objeto u objetos objetivo, y para determinar las propiedades a extraer de la base de datos relativa a estos objetos. A continuación, en una primera etapa, se busca simplificar el modo de consulta de la base de datos, limitándose a los objetos identificados en la solicitud. Finalmente, en una segunda etapa, la base de datos es consultada, en su lenguaje (por ejemplo, SQL), acerca de las propiedades a extraer, gracias a la vista restringida de la base de datos.

La representación de la base de datos se puede obtener sobre la marcha a partir de la base de datos en cada solicitud del usuario. También se puede obtener refinando una representación ya existente, por ejemplo, obtenida en una solicitud previa del usuario.

De este modo, el procedimiento puede comprender, además, una actualización de la representación, comprendiendo esta actualización las etapas siguientes:

- de generación, a partir de dicho al menos un objeto, de al menos una tercera solicitud en dicho segundo lenguaje, dirigida a navegar en la base de datos,

- de consulta de la base de datos por medio de dicha al menos una tercera solicitud, a fin de obtener información sobre la estructura de la base de datos y

- de determinación, a partir de dicha información obtenida, de dicha representación de la base de datos.

Según esta actualización, la consulta de la base de datos siempre está adaptada a la estructura actual de la base de datos. Por lo tanto, a diferencia de las librerías o a las API de la técnica anterior, antes de consultar la base de datos a fin de obtener la información requerida, se extrae de la misma información que permite conocer su estructura (que puede evolucionar con el tiempo mediante la agregación y/o la supresión de tablas, de relaciones entre las tablas, de claves u otro). Por lo tanto, es posible determinar una solicitud relevante y efectiva para la consulta final de la base de datos.

La primera consulta de la base de datos para determinar la representación de la base de datos se puede entender como una actualización de la misma.

Por ejemplo, la información acerca de la estructura se obtiene a partir de una navegación por la gráfica.

Los algoritmos de navegación por las gráficas ofrecen una solución eficaz de análisis completo de la base de datos que puede adoptar la forma de una gráfica de tablas con enlaces entre las mismas. Además, el conocimiento del objeto u objetos de interés para el usuario hace posible optimizar la navegación, centrándolo en este o estos objetos. Para optimizar el número de accesos a la base de datos, el procedimiento puede comprender, además, antes de la etapa de generación de dicha al menos una segunda solicitud, una etapa de verificación de dicha representación, para determinar si comprende dicho al menos un objeto de la primera solicitud, y en la que se implementa la actualización si la representación de la base de datos no incluye dicho al menos un objeto.

De este modo, la actualización de la representación restringida de la base de datos está condicionada por la necesidad de conocer una propiedad de un objeto nuevo. Esta condición puede ser implementada, por ejemplo, en el caso de que la representación restringida de la base de datos esté guardada en memoria para su utilización en varias solicitudes del usuario, para limitar los accesos a la base de datos.

Por ejemplo, dicha información acerca de la estructura de la base de datos comprende una lista que comprende, al menos, una tabla de la base de datos relativa, al menos, a un objeto.

La lista puede comprender, asimismo, al menos una tabla de asociación entre varias tablas de la lista.

El conocimiento de las tablas de la base de datos, y de su asociación (o relación) permite determinar las claves (primarias o secundarias) a utilizar para extraer las propiedades solicitadas por el usuario en la primera solicitud.

El procedimiento puede comprender, además, una etapa de realización de al menos una operación sobre al menos una de las tablas de dicha lista, para determinar dicha representación de la base de datos.

Por ejemplo, estas operaciones son operaciones básicas tales como uniones, proyecciones y/o restricciones u otros. Esta o estas operaciones son, por ejemplo, combinaciones de operaciones básicas de este tipo.

De este modo, la representación es más fácil de manipular para determinar la segunda solicitud, ya que la información contenida en la representación es más relevante y menos numerosa.

El procedimiento puede comprender, además, las etapas siguientes:

- formatear un resultado de la segunda consulta, y

- enviar dicho resultado formateado.

De este modo, el resultado puede estar más adaptado al lenguaje utilizado por el usuario en la primera solicitud. Por ejemplo, la base de datos es una base de datos relacional. De este modo, la asociación entre los objetos a los que se dirige la primera solicitud y las tablas de la base de datos es más sencilla de determinar.

El primer lenguaje es, por ejemplo, un lenguaje pseudo natural, lo que permite al usuario no tener que formalizar su solicitud según el lenguaje específico de la base de datos.

El procedimiento según el primer aspecto puede ser implementado, por ejemplo, mediante un intérprete de solicitudes. Este intérprete puede estar implementado por medios informáticos dispuestos entre la base de datos y el terminal del usuario. Este intérprete puede estar integrado, asimismo, en la base de datos o en el terminal del usuario.

Un segundo aspecto de la invención hace referencia a un programa informático, así como a un producto de programa informático y a un soporte de almacenamiento para un programa y un producto de este tipo, que permite la implementación de un procedimiento según el primer aspecto de la invención, cuando el programa está almacenado en una memoria de un dispositivo de consulta de base de datos, tal como un intérprete de solicitudes, y ejecutado por un procesador de un dispositivo de este tipo.

Un tercer aspecto de la invención hace referencia a un dispositivo de consulta de base de datos, configurado para la implementación de un procedimiento según el primer aspecto de la invención.

Un dispositivo de este tipo comprende:

- una unidad de comunicación, configurada para recibir una primera solicitud, en un primer lenguaje, dirigida a la obtención de información contenida en la base de datos, teniendo dicha solicitud dirigida, al menos, a un objeto, al menos una propiedad representada en la base de datos, y para consultar la base de datos mediante al menos una segunda solicitud, y

- una unidad de procesamiento configurada para acceder a una representación de la base de datos restringida, al menos, a un objeto, y para generar, a partir de dicha representación y de dicha al menos una propiedad de la primera solicitud, dicha al menos una segunda solicitud en un segundo lenguaje, dirigida a obtener la información solicitada en la primera solicitud.

El dispositivo puede comprender, además, una unidad de memoria, configurada para almacenar dicha representación de la base de datos.

Según realizaciones:

- la unidad de procesamiento está configurada, además, para actualizar dicha representación, comprendiendo esta actualización la generación, a partir de dicho al menos un objeto, de al menos una tercera solicitud en dicho segundo lenguaje, dirigida a navegar en la base de datos y para determinar, a partir de información acerca de la estructura de la base de datos obtenida, dicha representación de la base de datos, y

- la unidad de comunicación está configurada, además, para consultar la base de datos por medio de dicha al menos una tercera solicitud (308), a fin de obtener dicha información.

Los objetos según los segundo y tercer aspectos de la invención proporcionan al menos las mismas ventajas que las proporcionadas por el procedimiento según el primer aspecto. El dispositivo según el tercer aspecto puede comprender medios para la implementación de características opcionales solicitadas para el primer aspecto en términos de procedimiento.

Otras características y ventajas de la invención se harán evidentes con la lectura de la presente descripción detallada que sigue, a modo de ejemplo no limitativo, y de las figuras adjuntas, en las que:

- la figura 1 ilustra un ejemplo de contexto general de implementación de una realización de la invención;

- la figura 2 ilustra tablas de una base de datos;

- la figura 3 es un diagrama de intercambio y de etapas implementados en una realización; y

- la figura 4 ilustra esquemáticamente un dispositivo según una realización de la invención.

En la descripción que sigue, se propone una interfaz de consulta intuitiva, accesible a los usuarios mediante lenguaje natural o pseudo natural y que puede adaptarse a sus necesidades, enmascarando la complejidad de la estructura de datos.

En otras palabras, el usuario emite, a través de la interfaz, consultas a la base de datos sin conocer los detalles de la estructura de la base, indicando la información deseada (por ejemplo, identificación de un objeto y propiedades que el usuario desea extraer de la base de datos) y relaciones lógicas entre esta información (por ejemplo, del tipo «Y» / «O»).

La interfaz permite transcribir una solicitud del usuario en un lenguaje simple a un conjunto de consulta más complejas en el lenguaje de la base de datos según la estructura de la misma. Por consiguiente, esta interfaz puede actuar como intérprete, permitiendo simplificar la consulta de la base de datos por pare del usuario).

La presente invención encuentra aplicaciones en sistemas para los cuales existe la necesidad de que los usuarios accedan a una información contenida en una base de datos, sin conocer, por lo tanto, el lenguaje apropiado (por ejemplo, SQL) o incluso la estructura completa de la base de datos.

La descripción que sigue se encuentra en el marco de los sistemas y redes informáticos de alto rendimiento (denominados «clústeres HPC» en terminología anglosajona, siendo HPC el acrónimo de «High Performance Computing», informática de alto rendimiento).

En general, estos clústeres están acoplados a SGBD para almacenar la gran cantidad de información relativa a la gran cantidad de equipos que los componen. El administrador del «clúster» no tiene como actividad principal el mantenimiento del SGBD. Su cometido consiste más bien en gestionar el propio clúster. La información contenida en el SGBD es, para él, una herramienta para su cometido. Este administrador debe poder acceder a la información contenida en el SGBD de manera flexible, rápida e intuitiva, sin preocuparse por la estructura del mismo. El acceso a esta información tiene, en general, como objetivo, diagnosticar un problema en el «clúster» o, posiblemente, anticiparlo.

La figura 1 ilustra un contexto de implementación de la invención en este marco.

Una gran cantidad de equipos 100, 101, 102 (fuentes de alimentación, dispositivos de refrigeración, ordenadores u otros) están conectados entre sí de manera directa, o a través de una red 103. Estos equipos están enumerados en una o varias bases de datos 104, 105, 106, permitiendo conocer el estado de la red y de los equipos que están conectados a la misma (de manera directa o indirecta). Estas bases de datos están gestionadas mediante un sistema de gestión de bases de datos 107.

Los inventores han constatado que, en este tipo de entorno, el acceso a la información es diferente para los diferentes usuarios conectados a la red a través de un terminal 108, habitualmente, un ordenador. Por ejemplo, un sistema de gestión, habitualmente, necesita datos tales como los relativos a las máquinas que conforman su entorno, en los sistemas operativos, al estado de los sistemas de archivos, u otros. Por lo general, un gestor de red necesita habitualmente estadísticas relativas a los conmutadores, al estado de los puertos de la red que administra. Para comprender una situación compleja de una red o de un sistema, también puede ser necesario para cotejar estos datos. Esto requiere, por consiguiente, el establecimiento de relaciones entre diversos datos contenidos en las bases de datos.

Por lo tanto, cada usuario debería poder acceder de manera sencilla a los datos que le interesan, sin tener que enfrentarse a datos que no son relevantes para él.

En lo que sigue, se considera que un usuario desea acceder a propiedades de un objeto descrito en la base de datos.

Un objeto corresponde, por ejemplo, a un elemento determinado en la estructura de datos de la base. Se trata, por ejemplo, de un dispositivo, de un grupo de dispositivos, u otro. A un objeto están asociadas ciertas propiedades. Se trata, por ejemplo, de su identificación, de su tipo, de su modelo, o de otro. Estas propiedades están disponibles, bajo demanda y a su elección, mediante la construcción de una consulta específica de la base de datos.

A continuación, se define un subconjunto de ocurrencias del objeto en base a los criterios de selección definidos por el usuario.

La figura 2 ilustra una base de datos con tablas (correspondientes a objetos) y los enlaces que vinculan estas tablas. Tablas específicas (no representadas) pueden contener, por ejemplo, los diferentes enlaces que vinculan las tablas. En la base de datos, un objeto está definido mediante una tabla «principal» (por ejemplo, un nodo de clúster), en la que se encuentran, particularmente, sus propiedades intrínsecas y/o sus conexiones de primer nivel con otros objetos (por ejemplo, un nodo conectado a una red).

A estos otros objetos corresponden tablas «principales», que describen asimismo sus propiedades intrínsecas y que se utilizan como tablas «secundarias» para enriquecer los datos del primer objeto, y, por consiguiente, la construcción de la solicitud de acceso a cualquier información requerida.

Una tabla 200 («Nodo») hace referencia a los nodos de la red. Esta tabla recopila varias propiedades de los nodos (también llamadas «atributos», «campos» o «claves»).

La tabla 200 comprende los identificadores de los nodos («ID_Nodo», este campo constituye la clave principal de la tabla, está representada subrayada), los identificadores de los armarios que los contienen («ID_Bastidor»), su función («Función») su modelo («Modelo») u otro. A título de ilustración, se ha representado una línea para un nodo identificado bajo el número «7102», que pertenece al rango identificado bajo la referencia «R007» que tiene una función identificada como «calcular» (es decir, un calculator, en inglés), y de modelo «S6010».

Una tabla 201 («Fila_de_bastidores»), relacionada con la tabla 200, reúne los diferentes armarios de la red y proporciona la fila en el que se encuentran geográficamente en un centro de cálculo («datacenter», en inglés).

La tabla 201 comprende los identificadores de los armarios («ID_Bastidor», este campo constituye la clave principal de la tabla, y se representa subrayado) y los identificadores de las filas («Fila»). A título de ilustración, se ha presentado una línea relativa al armario identificado bajo la referencia «R007» que se encuentra en la fila «H». Una tabla 202 («7102_Conexiones»), vinculada a la tabla 200, agrupa el conjunto de los elementos conectados al nodo identificado bajo el número «7102». A título de ilustración, se ha ilustrado la conexión con un elemento identificado por el identificador «esw003».

Una tabla 203 («R007_Contenido»), vinculada a la tabla 201, agrupa el conjunto de los elementos («Elemento») contenidos en el armario identificado bajo la referencia «R007», así como el número del piso («Piso», este campo constituye la clave principal de la tabla, y se representa subrayado) en el que se encuentran. A título de ilustración, se ha representado una línea relativa al último piso «N» del armario que contiene el dispositivo de número «7102». Una tabla 204 («Conmutador»), vinculada a la tabla 201, hace referencia a los conmutadores de la red. Esta tabla agrupa a los identificadores («ID_Conm», este campo constituye la clave principal de la tabla, y se representa subrayado) de los conmutadores, a los identificadores («ID_Bastidor») de los armarios en los que están dispuestos y el tipo («Tipo») de los conmutadores. A título de ilustración, se ha representado una línea relativa al conmutador que tiene el identificador «esw003» dispuesto en el armario que tiene la referencia «R008» del tipo «Ethernet».

En un procedimiento según la invención, un software intérprete de la interfaz puede tener a su disposición una vista virtual de la base de datos restringida únicamente a los elementos (tablas y asociaciones de tablas) correspondientes a la solicitud del usuario. Esta vista contiene los campos correspondientes a la selección de los datos de las diversas tablas afectadas por el objeto demandado. Los campos de estas tablas son seleccionados de manera automática según la lista de propiedades solicitadas por el usuario.

En un entorno de bases de datos relacionales, están disponibles operadores “relacionales”. Por ejemplo, las operaciones de unión (implícita o explícita) consisten en realizar un producto cartesiano entre registros de varias tablas. A fin de poder procesar de manera eficaz este tipo de operaciones, la interfaz propuesta tiene conocimiento de la arquitectura interna (estructura) de la base de datos. Se trata de las rutas entre las diversas tablas (relaciones) a fin de obtener la información buscada.

En el caso de uniones, la solicitud correspondiente a la demanda del usuario se crea cada vez con mayor frecuencia mediante un procedimiento de navegación en la base. De este modo, es posible obtener el conjunto de las propiedades intrínsecas del objeto, pero también del conjunto de datos en relación con él, a través de las tablas vinculadas.

La función de unión no es necesaria para acceder solo a las propiedades intrínsecas del objeto. Es posible limitarse solo a las tablas «principales» si, en un caso sencillo, el criterio de selección también se relaciona con las propiedades intrínsecas.

El software puede gestionar las solicitudes emitidas en lenguaje pseudo natural ofreciendo una visión de un objeto de una base de datos relacional a la vez al nivel de la interfaz y al nivel de la implementación. Un lenguaje de este tipo puede ser del tipo <prefijo>, <atributo>, o el prefijo corresponde al identificador del objeto.

Un esquema de implementación podría ser el siguiente:

1. Analizar la solicitud del usuario para extraer los datos de “estructuración” (es decir, los equivalentes a una noción de nombre de objeto / de tabla).

2. Analizar de manera dinámica la estructura de la base de datos para determinar la ubicación en la que se almacena la información relevante y la vinculación o las vinculaciones entre ellos. Este análisis se puede realizar generando un conjunto de solicitudes de SQL del tipo de “navegación por gráficos” que permite explorar la base de datos y obtener una descripción completa de la estructura de la misma.

3. Devolver una vista virtual de la parte de la estructura de la base de datos “útil” según los criterios elegidos por el usuario durante el envío de su solicitud. Es decir, la parte restringida a los objetos objetivo en la solicitud.

4. Analizar la estructura restringida para generar de manera automática las solicitudes de SQL necesarias para obtener la información deseada por el usuario. Se utilizan la información de la estructura obtenida previamente y la solicitud inicial del usuario.

5. Ejecutar las solicitudes de SQL para recuperar el resultado o resultados, y después, analizarlos y formatearlos para constituir la respuesta para el usuario.

La figura 3 representa un diagrama de intercambio entre el usuario 300, el software de interpretación 301 (por ejemplo, implementado por el terminal de usuario) y la base de datos 302 (por ejemplo, a través de un sistema de gestión de base de datos).

El usuario emite una solicitud (303) en lenguaje pseudo natural que comprende uno o varios objetos y una o varias propiedades relacionadas con este o estos objetos. El intérprete recibe esta solicitud y, a continuación, la analiza (304).

Este análisis está dirigido a identificar los objetos de la solicitud y las propiedades. Este análisis está dirigido asimismo a identificar los vínculos lógicos («=», «Y», «O», u otro) entre estos objetos y estas propiedades y los valores dados por el usuario.

El intérprete accede (305) a continuación a una representación de la base de datos que se limita a los objetos identificados en el análisis de la solicitud de del usuario. A continuación, determina (306), posiblemente, si actualizar esta representación, por ejemplo, porque no comprende bastantes elementos para responder a la solicitud del usuario. Una implementación de este tipo se puede decidir según criterios de antigüedad de la representación. Puede ser necesario actualizar la representación de manera regular para seguir las evoluciones de la base de datos. Si se decide una actualización de este tipo (SÍ), el intérprete genera (307) una o varias solicitudes de navegación, en el lenguaje de la base de datos (por ejemplo, SQL) dirigidas a navegar en la base de datos, por ejemplo, implementando un algoritmo de navegación en la gráfica para conocer las tablas y las asociaciones de tablas relevantes para responder a la solicitud del usuario.

Estas solicitudes (308) son enviadas a continuación a la base de datos para ser ejecutadas (309).

Los resultados (310) de la ejecución de las solicitudes por parte de la base de datos son recibidos a continuación por el intérprete del lado de la base. Por ejemplo, estos resultados, o información de estructura, comprenden una o varias listas de tablas o de tablas de asociación de la base de datos.

A continuación, el intérprete actualiza (311) la representación de la base de datos. Para ello, puede implementar operaciones adicionales de filtrado u operaciones relacionales para evitar dañar la representación existente, o para evitar duplicar la información.

El intérprete determina las tablas principales de la base de datos correspondientes a los objetos objetivo en la solicitud, así como las tablas secundarias que serán útiles para la elaboración de la solicitud de extracción de la base de datos.

El intérprete pasa a la etapa de generación (312) de una solicitud de extracción de datos de la base de datos según la información de estructura (310) recibida del lado de la base de datos.

Se puede asignar una variable de trabajo a cada una de las tablas y, todos los campos necesarios para responder a la solicitud del usuario pueden ser reconstruidos «prefijándolos» de la variable correspondiente a la tabla sin la cual se almacenan los datos a extraer.

Asimismo, se puede construir una unión estructural vinculando las tablas secundarias a las tablas principales por medio de las variables de trabajo. Se puede efectuar igualmente una selección sobre una propiedad principal o secundaria (según una gramática más o menos compleja que combina los vínculos «Y», «O» u otro) «prefijando» la propiedad mediante la variable de la tabla.

La solicitud es enviada a continuación hacia la base de datos que la ejecuta (314). El intérprete recibe a continuación el resultado (315) de la ejecución de la solicitud y, lo pone posiblemente, en forma (316) antes de transmitirlo (317) al usuario.

Las partes extraídas de la base de datos (propiedades, uniones, selecciones u otras) pueden ser ensambladas mediante un lenguaje de pegamento («glue language» en terminología anglosajona).

Volviendo a la etapa de decisión de actualización (306), para el caso en el que se ha decidido no actualizar la representación (NO), el intérprete pasa directamente a la etapa (312) de generación de la solicitud de extracción. Dada la complejidad de la arquitectura de los clústeres actuales (varias decenas de miles de equipos), las solicitudes de consulta de la base de datos que contienen la descripción, el estado, la información de configuración (u otro) del conjunto de estos equipos son cada vez más complejas.

Por ejemplo, una solicitud de usuario puede consistir en obtener la lista de nodos ubicados en el último piso de los bastidores de la fila referenciada con “H”, de función “calcular”, de modelo “S6010”, conectados al conmutador de Ethernet denominado “esw0003”.

Para obtener esta lista por medio de las solicitudes de SQL, sería necesario conocer de antemano el conjunto de las tablas que contienen la información relativa a los diferentes criterios (nodo, conmutador de Ethernet, posición geográfica, función). Serían necesarias varias solicitudes sucesivas en las diferentes tablas para obtener el resultado.

Al utilizar una librería, sería necesario utilizar varias funciones diferentes y, a continuación, ejecutar un programa para analizar los resultados de las funciones utilizadas para obtener la lista deseada.

Según una realización, el usuario proporciona la lista de los criterios deseados. A continuación, el intérprete obtiene la lista de las tablas a utilizar, así como los vínculos entre estas tablas (a través de los códigos primarios y secundarios de estas tablas). De este modo, el intérprete construye una visión “virtual” orientada al objeto, que permite describir el conjunto de los objetos a modelizar en función de los criterios de entrada. En el presente caso, los objetos de base son: un nodo, un conmutador y un bastidor. La posición geográfica es un atributo (propiedad) del objeto bastidor, así como otro atributo del objeto nodo y el conmutador de Ethernet. La función es un atributo del objeto nodo.

La identificación de las tablas necesarias se realiza mediante la navegación de la estructura de la base de datos para seleccionar, en el presente ejemplo, las tablas: nodo, conmutador de Ethernet, bastidor, posición, función. Esto se realiza de manera automática desde el punto de vista del usuario.

El algoritmo de búsqueda a implementar en SQL se podría expresar en pseudo código de la manera siguiente: pour tous les noeuds dans la base faire :

si ( noeud.type = "compute" et noeud.modéle-'S6010") alors

noeud_courant = nceud;

si ( trouver_rack(noeud_courant).rangée = "H ") alors

si ( position_rack(noeud_courant) = "top") alors

si ( existe(noeud_courant.commutateur) = "esw0003") alors retourner noeud_courant;

finsi

finsi

finsi

finsi

finfaire

Para una solicitud en lenguaje pseudo natural, el usuario no tiene que realizar esa solicitud, puesto que esta es generada de manera automática por el intérprete.

El usuario puede introducir, por ejemplo, una solicitud del tipo:

$ get_db_info

get

noeud.type-'compute" ET

noeud.modéle="S6010" ET

rack.rangée="H" ET

noeud.posit¡on="top" ET

noeud,switch="esw0003"

Según ciertas realizaciones, la solicitud es proporcionada al intérprete, lo que permite optimizar la fase de análisis de la estructura de la base de datos y guardarla en la memoria (o implementar a continuación la solución en una base de cliente / servidor, pudiendo guardar el servidor en la memoria la estructura obtenida después de una navegación completa en la base de datos.

Siendo esta solicitud la primera recibida por el intérprete, se obtiene la estructura de la base de datos en la que se ha realizado la navegación, y se guarda en la memoria.

Esto se puede ilustrar mediante la secuencia siguiente:

> get

noeud.type-'compute" ET

noeud. modéle="S6010"

Dado que esta solicitud no llama a ningún objeto que no forme parte de la estructura en la memoria, la navegación en la base de datos no se vuelve a ejecutar.

> get

pdu.type="apc" ET

rack.rangée="H"

El objeto PDU (signo de «Power Distribution Unit» en inglés, es decir, unidad de distribución de energía) no está presente en la representación restringida de la base de datos en la memoria. De este modo, se realiza de nuevo una navegación en la base de datos para completar su representación de la misma con el objeto PDU.

Un programa informático para la implementación de un procedimiento según una realización de la invención puede ser realizado a partir del diagrama de la figura 3 y de la presente descripción detallada.

Un dispositivo de consulta de base de datos según una realización se describe haciendo referencia a la figura 4. El dispositivo 400 de la figura 4 comprende una unidad de memoria 401 (MEM) Esta unidad de memoria comprende una memoria activa para almacenar de manera no permanente datos de cálculo utilizados durante la implementación de un procedimiento según la invención, según diversas realizaciones. La unidad de memoria comprende, por otra parte, una memoria no volátil (por ejemplo, del tipo EEPROM) para almacenar, por ejemplo, un programa informático, según una realización, para su ejecución por parte de un procesador (no representado) de una unidad de procesamiento 402 (PROC) del dispositivo. Por ejemplo, la unidad de memoria almacena una representación actual de la base de datos. El servidor de control comprende, además, una unidad de comunicación 403 (COM) para llevar a cabo las comunicaciones, en particular para recibir solicitudes del lado de los usuarios y enviar solicitudes hacia una o varias bases de datos.

Por supuesto, la presente invención no se limita a las realizaciones descritas, son posibles otras variaciones y combinaciones de características.

La presente invención ha sido descrita e ilustrada en la presente descripción detallada haciendo referencia a las figuras adjuntas. Sin embargo, la presente invención no se limita a las realizaciones presentadas. Otras variantes y realizaciones pueden ser deducidas e implementadas por el experto en la materia con la lectura de la presente descripción y de las figuras adjuntas.

En las reivindicaciones, el término “incluir” no excluye otros elementos u otras etapas. El artículo indefinido “uno” no excluye el plural. Solo se puede utilizar un procesador o varias unidades adicionales para implementar la invención. Las diferentes características presentadas y/o reivindicadas pueden ser combinadas ventajosamente. Su presencia en la descripción o en diferentes reivindicaciones dependientes no excluye, en efecto, la posibilidad de combinarlas. Los signos de referencia no deben ser entendidos como limitativos del alcance de la invención.

Claims (15)

REIVINDICACIONES

1. Procedimiento de consulta de una base de datos por medios informáticos, que comprende las siguientes etapas: - de recepción de una primera solicitud (303) en un primer lenguaje, dirigida a obtener información contenida en la base de datos, estando dirigida dicha solicitud al menos a un objeto que tiene al menos una propiedad representada en la base de datos

- de acceso (305) a una representación de la base de datos restringida al menos a un objeto,

- de generación (312), a partir de dicha representación y de dicha al menos una propiedad de la primera solicitud, de al menos una segunda solicitud en un segundo lenguaje que está dirigida a obtener la información requerida en la primera solicitud, y

- de consulta de la base de datos por medio de dicha al menos una segunda solicitud (313).

2. Procedimiento según la reivindicación 1, que comprende, además, una actualización de dicha representación, comprendiendo dicha actualización las etapas siguientes:

- de generación (307), a partir de dicho al menos un objeto, de al menos una tercera solicitud en dicho segundo lenguaje dirigida a navegar en la base de datos,

- de consulta de la base de datos por medio de dicha al menos una tercera solicitud (308) a fin de obtener información acerca de la estructura de la base de datos (310), y

- de determinación (311), a partir de dicha información obtenida, de dicha representación de la base de datos.

3. Procedimiento según la reivindicación 2, en el que la navegación en la base de datos se realiza mediante la navegación en una gráfica.

4. Procedimiento según una de las reivindicaciones 2 y 3, que comprende, además, antes de la etapa de generación de dicha al menos una segunda solicitud, una etapa de verificación (306) de dicha representación a fin de determinar si comprende dicho al menos un objeto de la primera solicitud, y en el que la actualización es implementada si la representación de la base de datos no comprende dicho al menos un objeto.

5. Procedimiento según una de las reivindicaciones 2 a 4, en el que dicha información acerca de la estructura de la base de datos comprende una lista que incluye al menos una tabla de la base de datos relacionada con dicho al menos un objeto.

6. Procedimiento según la reivindicación 5, en el que dicha lista comprende al menos una tabla de asociación entre varias tablas de la lista.

7. Procedimiento según una de las reivindicaciones 5 y 6, que comprende, además, una etapa de ejecución de al menos una operación en al menos una parte de las tablas de dicha lista, para determinar dicha representación de la base de datos.

8. Procedimiento según una de las reivindicaciones precedentes, que comprende, además, las etapas siguientes de: - formateado de un resultado de la segunda solicitud (316) y

- envío de dicho resultado formateado (317).

9. Procedimiento según una de las reivindicaciones precedentes, en el que la base de datos es una base de datos relacional.

10. Procedimiento según una de las reivindicaciones precedentes, en el que el primer lenguaje es un lenguaje pseudo natural.

11. Procedimiento según una de las reivindicaciones precedentes implementado por un intérprete de solicitudes.

12. Programa informático que comprende instrucciones para llevar a cabo un procedimiento según una de las reivindicaciones 1 a 11, cuando es ejecutado mediante un procesador de un dispositivo de consulta de base de datos.

13. Dispositivo de consulta de base de datos que comprende:

- una unidad de comunicación (403), configurada para recibir una primera solicitud (303) en un primer lenguaje dirigida a la obtención de información contenida en la base de datos, estando dirigida dicha solicitud al menos a un objeto que tiene al menos una propiedad representada en la base de datos, y para consultar la base de datos por medio de al menos una segunda solicitud (313), y

- una unidad de procesamiento (402), configurada para acceder (305) a una representación de la base de datos restringida al menos a un objeto, y para generar (312), a partir de dicha representación y de dicha al menos una propiedad de la primera solicitud, dicha al menos una segunda solicitud en un segundo lenguaje dirigida a obtener la información requerida en la primera solicitud.

14. Dispositivo según la reivindicación 13, que comprende, además, una unidad de memoria (401) configurada para almacenar dicha representación de la base de datos.

15. Dispositivo según una de las reivindicaciones 13 y 14, en el que:

- la unidad de procesamiento está configurada, además, para actualizar dicha representación, comprendiendo esta actualización la generación (307), a partir de dicho al menos un objeto, de al menos una tercera solicitud en el segundo lenguaje, destinada a navegar en la base de datos, y la determinación (311), a partir de información acerca de la estructura de la base de datos obtenida, de dicha representación de la base de datos, y

- la unidad de comunicación está configurada, además, para consultar la base de datos por medio de dicha al menos una tercera solicitud (308) a fin de obtener dicha información (310).