ES2636758T3

ES2636758T3 - Procedimiento implementado por ordenador para mejorar la ejecución de consulta en bases de datos relacionales normalizadas en el nivel 4 y superior

Info

Publication number: ES2636758T3
Application number: ES13461545.9T
Authority: ES
Inventors: Krystian Piecko
Original assignee: PILAB S A; PILAB SA
Current assignee: PILAB S A; PILAB SA
Priority date: 2013-08-30
Filing date: 2013-08-30
Publication date: 2017-10-09
Anticipated expiration: 2033-08-30
Also published as: EP2843567B1; US20150066986A1; PL2843567T3; US11893022B2; US10095743B2; US20190042624A1; EP2843567A1

Abstract

Un procedimiento implementado por ordenador para ejecutar una consulta de base de datos en una base de datos, comprendiendo el procedimiento las etapas de: - proporcionar, al menos, una estructura de datos, definida por un esquema de base de datos de dicha base de datos, que comprende, al menos, un objeto que tiene, al menos, dos propiedades, teniendo cada propiedad un tipo de datos asignado, en el que dichos tipos de datos pueden compararse con respecto a su tamaño de datos; - establecer (401), usando dicho esquema de base de datos de dicha base de datos, por comparación, de dichos tipos de datos de las al menos dos propiedades, una propiedad de una estructura de datos seleccionada que comprende los valores únicos más pequeños para registros dados de tipo de datos almacenados en esa propiedad particular; - ejecutar (402) la consulta de base de datos, que incluye cualquier parámetro de limitación, configurado para recibir solo datos desde la propiedad que comprende los valores únicos más pequeños que son recuperables para un registro; - empezar (403) a recuperar resultados de la consulta (402) recuperada; - para cada conjunto de número de resultados recuperados predefinido, ejecutar (405) un nuevo proceso de acceso a la base de datos que se configura para recuperar datos que están presentes en los registros identificados con los valores únicos más pequeños.

Description

5

10

15

20

25

30

35

40

45

50

55

DESCRIPCION

Procedimiento implementado por ordenador para mejorar la ejecucion de consulta en bases de datos relacionales normalizadas en el nivel 4 y superior

El objeto de la presente invencion es un procedimiento implementado por ordenador para optimizacion de la ejecucion de consulta de bases de datos. El procedimiento encuentra su aplicacion en sistemas de recuperacion y procesamiento de datos.

De acuerdo con WIKIPEDIA (
www.wikipedia.org), las consultas de tipo JOIN se definen en la tecnica anterior como sigue. Una clausula JOIN de SQL (Lenguaje de Consulta Estructurado, del ingles Structured Query Language) combina registros de dos o mas tablas en una base de datos. Crea un conjunto de datos que se puede guardar como una tabla o usarse tal cual. Una consulta JOIN es un medio para combinar cambios de dos o mas tablas mediante el uso de valores comunes en cada una. El estandar ANSI SQL especifica cuatro tipos de JOIN: INNER, OUTER, LEFT, y RIGHT. Como caso especial, una tabla (tabla base, vista, o una tabla unida) puede UNIRSE a sf misma en una autounion.

Un programador escribe un predicado JOIN para identificar los registros que unira. Si el predicado evaluado es verdadero, el registro combinado se produce, entonces, en el formato esperado, un registro establecido o tabla temporal.

Las bases de datos relacionales actuales a menudo se normalizan con el fin de eliminar informacion duplicada cuando los objetos pueden tener relaciones uno a uno, uno a muchos o muchos a muchos. Por ejemplo, se puede asociar un unico Departamento asociado con muchos Empleados diferentes. Unir dos tablas de manera eficaz crea otra tabla que combina informacion de ambas tablas. Esto es a un cierto coste en terminos del tiempo que toma para computar la union.

Esto es a un cierto coste en terminos del tiempo que toma para computar la union, ya que los sistemas relacionales muy comunmente llaman a unirse, aunque se enfrentan a dificultades para optimizar su ejecucion eficiente. En casos en los que una consulta requiere unir mas de una estructura de datos, el tiempo de ejecucion puede aumentar exponencialmente.

Existen tres algoritmos para realizar operaciones de tipo JOIN: una union de bucle anidado que s un algoritmo s imple que une dos conjuntos usando dos bucles anidados; una union de clase combinacion que es un algoritmo para ordenar primero las r elaciones por el atributo de union, de modo que las exploraciones lineales entrelazadas encontraran estos conjuntos al mismo tiempo; y una union hash que es un algoritmo realizado por la ejecucion de un algoritmo hash de u n conjunto de datos en una memoria basada en la union de columnas y la lectura del otro y probar la tabla hash en busca de coincidencias.

Como se menciono previamente, las bases de datos relacionales a menudo se normalizan. El objetivo de la normalizacion es almacenar solo la minima cantidad de informacion, para eliminar redundancias en los datos, para eliminar anomalfas y para reestructurar datos con el fin de proporcionar almacenamiento mas eficiente.

El concepto de normalizacion de datos se desarrollo por E.F. en 1970. El Sr. Codd en su publicacion sobre "Further Normalization of the Data Base Relational Model' definio formas normales para reducir la cantidad de redundancia y dependencia de inconsistencia dentro de las bases de datos. El Sr. Codd definio tres formas normales, pero durante los anos posteriores dos formas normales mas se introdujeron.

Existen cuatro formas normales mas comunmente usadas: la forma normal primera (1NF), la segunda (2NF) y la tercera (3NF), y a veces se usa la forma Boyce-Coddnormal (BCNF).

Tambien se conoce una cuarta forma (4NF) normal, que es una forma normal usada en la normalizacion de la base de datos. Introducido por Ronald Fagin en 1977, 4NF es el siguiente nivel de normalizacion despues de la forma normal de Boyce-Codd (BCNF). Considerando que la segunda, la tercera, y la forma normal Boyce-Codd se ocupan de las dependencias funcionales, 4NF se refiere a un tipo mas general de dependencia conocida como una dependencia conocida como una dependencia de valor multiple [fuente: WIKIPEDIA].

Tambien existe en la tecnica anterior, una Quinta forma (5NF) normal, tambien conocida como forma (JPNF) normal de union-proyeccion, que establece que no existe ninguna dependencia de union no trivial. El 5NF establece que cualquier hecho debena poder reconstruirse sin ningun resultado anomalo en ningun caso, independientemente del numero de tablas que se estan uniendo. Una tabla 5NF debena tener solo claves candidatas y su clave primaria debena consistir en solo una unica columna.

El problema con estas formas normales es el tamano de las uniones que se requieren para reconstruir cualquier dato no trivial. Un desarrollador puede depender de vistas y procedimientos para simplificarlos, pero los datos subyacentes todavfa terminan siendo muy complejos. Tambien existen problemas de rendimiento a considerar - que es por lo que 4NF y 5NF son a menudo academicos. En la mayona de los casos, 3NF (o BCNF) se implementan. (fuente:
http://www.devshed.com/c/a/Administration/Database- Normalization/4/).

5

10

15

20

25

30

35

40

45

50

55

La normalizacion produce muchas tablas, que tiene cada una relativamente pocas columnas, por ejemplo, dos columnas - una clave primaria y un valor. Para usar los datos de normalizacion contenidos en estas columnas, uno tiene que poner la informacion de vuelta junta uniendo las columnas usando sus relaciones de claves primarias/remotas.

Ejecutar consultas a una base de datos normalizada normalmente requiere recuperacion de datos almacenados para multiples tablas normalizadas. La base de datos normalizada, por lo tanto, necesita localizar y recuperar las tablas solicitadas y, entonces, une la informacion de las bases de datos para responder a la solicitud de datos.

Las solicitudes de tipo JOIN reducen el rendimiento de la base de datos ralentizando el proceso y colocando tension de procesamiento pesado sobre el hardware informatico. Las bases de datos normalizadas necesitan mayor CPU, memoria, e I/O para procesar transacciones y consultas que las bases de datos no normalizadas y desnormalizadas. En las bases de datos existentes, las consultas de tipo JOIN incurren en sobrecarga de procesamiento significante, que conduce a la incapacidad para trabajar en tiempo real.

Por lo tanto, podna ser muy ventajoso aumentar el rendimiento de las consultas de la base de datos, especialmente en las consultas de tipo JOIN ya que son cruciales para las bases de datos normalizadas.

Algunas bases de datos de la tecnica anterior implementan las llamadas tecnicas de optimizacion de consulta. La optimizacion de la consulta es una funcion de sistemas de gestion de bases de datos, tales como sistemas (RDBMS) de gestion de bases de datos relacionales. El optimizador de consultas trata de determinar el modo mas eficiente de ejecutar una consulta dada considerando los planes de consulta posibles. En implementaciones tfpicas, el optimizador de consulta no puede ser accesible directamente por los usuarios RDBMS: una vez que las consultas se envfan a un servidor de base de datos, y se analizan por el analizador, pasan seguidamente al optimizador de consulta donde tiene lugar la optimizacion.

Por ejemplo, una publicacion de patente US 5.548.758 titulada "Optimization of SQL queries using early-out join transformations of column-bound relational tables" desvela un procedimiento y aparato para optimizar solicitudes SQL en un sistema de gestion de bases de datos relacionales que usa transformaciones de union de retiro anticipado. Una union de retiro anticipado comprende una union existencia de muchos a uno, en la que la union busca una coincidencia en una tabla interior para cada fila de la tabla externa y termina la busqueda para cada fila de la tabla externa cuando una unica coincidencia se encuentra en la tabla. Para transformar una union de muchos a muchos para una union de retiro anticipado, la consulta debe incluir un requisito de caracter distintivo, tanto explfcita como implfcitamente, en una o mas columnas de resultado para cada operacion de union. El caracter distintivo puede especificarse usando la palabra clave DSTINCT en la clausula SELECT o puede ser implfcita a partir de los predicados presentes en la consulta. La transformacion de union de retiro anticipado tambien necesita que no se haga referencia a ninguna columna en la tabla interna despues de la union, o si se hace referencia a una columna de tabla interna despues de la union, de que cada columna referenciada sea "obligada". Una columna referenciada puede ser obligada de una de tres maneras: (1) una columna de tabla interna puede ser obligada a una constante a traves de un predicado de igualdad, (2) una columna de tabla interna puede ser obligada a una columna de tabla externa, o (3) una columna de tabla interna puede ser obligada a un valor correlacionado, en el que el valor correlacionado origina el bloqueo de consulta. En los tres casos, una columna de tabla interior puede ser obligada a traves de transitividad de predicados de igualdad.

Una solicitud de patente US20120246147 titulada "MODULAR QUERY OPTIMIZER', desvela programas informaticos codificados en un medio de almacenamiento informatico que proporciona un optimizador de consulta modular. En un aspecto, un producto programa informatico incluye seleccionar una o mas proyecciones de un conjunto de proyecciones para cada tabla en una consulta de base de datos en la que cada una de las proyecciones seleccionadas para la tabla ha llevado a costes de ejecucion inferiores estimados para la consulta en comparacion con las proyecciones no seleccionadas; generar ordenes de union para la consulta basada en distribucion de datos de una o mas de las proyecciones seleccionadas entre sitios en una red informatica en la que las ordenes de union reflejan diferentes combinaciones de operaciones de distribucion de datos aplicadas a la salida de una o mas uniones de consulta; y seleccionar una orden de union desde las ordenes de union basandose en las ordenes de union que usan un modelo de coste.

Los inconvenientes de la optimizacion de consulta conocidos en las bases de datos normalizadas incluyen, por ejemplo, requisitos de mayor memoria y CPU y dificultades en formular consultas complejas.

Hasta ahora, tales problemas se han dirigido con un uso de un hardware mas poderoso, tal como servidores de bases de datos que tienen mayor rendimiento y mas memoria en lugar de soluciones relacionadas con el diseno de bases de datos y de ejecucion de consultas.

Por ejemplo, una solicitud de patente US2012117027 titulada "Methods and systems for hardware acceleration of database operations and queries for a versioned database based on multiple hardware accelerators" desvela un acelerador de hardware que asiste a un sistema de base de datos huesped que esta procesando sus consultas. El acelerador de hardware comprende elementos de procesamiento de objetivo especial que son capaces de recibir tareas de consulta/operacion de base de datos en la forma de instrucciones de base de datos de codigo de maquina,

5

10

15

20

25

30

35

40

45

50

55

ejecutar, entonces, en un hardware sin software, y devolver el resultado de la consulta/operacion de vuelta al sistema huesped. Por lo tanto, el sistema se refiere a sistemas de base de datos que se optimizan usando aceleracion pura de hardware. Una solicitud de patente de Estados Unidos US2003229640A1 desvela un aparato, producto de programa y un procedimiento que utiliza un bufer de consulta dinamicamente rellenada para facilitar el maneo de al menos una parte de la consulta de base de datos en paralelo. Una consulta se implementa usando, al menos, una primera y una segunda parte, donde la segunda parte de la consulta se ejecuta en paralelo usando una pluralidad de procesos. La primera parte de la consulta se ejecuta para rellenar dinamicamente un bufer de consulta con registros desde una fuente de datos, y la pluralidad de procesos que ejecutan la segunda parte de la consulta se especifican en el bufer de consulta para que la fuente de datos efectiva para la segunda parte de la consulta comprenda los registros que se rellenan dinamicamente en el bufer de consulta. Teniendo en cuenta el estado de la tecnica anterior, existe una necesidad de disenar e implementar una optimizacion de ejecucion de consulta de base de datos eficiente que sena mas eficiente que las consultas de tipo JOIN. En particular, tal optimizacion debena dirigirse a aumentar el rendimiento de recuperacion de datos en bases de datos normalizadas en el nivel 4NF o 5NF y, preferentemente no requerira componentes de hardware especializados.

El objetivo de la presente invencion es un es un procedimiento implementado por ordenador para ejecutar una consulta de base de datos como se define en las reivindicaciones adjuntas.

Estos y otros objetivos de la invencion presentados en el presente documento se logran proporcionando un procedimiento implementado por ordenador para optimizacion de ejecucion de consulta. Mas detalles y caractenstica de la presente invencion, y naturaleza y diversas ventajas devendran mas evidentes a partir de la descripcion detallada siguiente de las realizaciones preferentes mostradas en un dibujo, en los que:

la figura 1 presenta un ejemplo de una estructura normalizada en el nivel 2; la figura 2 muestra una normalizacion 3NF para la base de datos de la figura 1; la figura 3 muestra una normalizacion 5NF para la base de datos de la figura 1;

la figura 4 presenta un procedimiento para ejecutar una consulta de base de datos de acuerdo con la invencion; la figura 5 muestra una implementacion ejemplar del procedimiento mostrado en la figura 4; las figuras 6 y 7 muestran un sistema de base de datos de tipo diagrama de ideas; y,

la figura 8 muestra un sistema de base de datos ejemplar, para el que el procedimiento presente se ha disenado por el que puede implementarse.

En la siguiente descripcion detallada, los operadores UNION, EXCEPT e INTERSECT se llamaran operadores de conjunto.

La figura 1 presenta un ejemplo de una estructura normalizada en el nivel 2. En el ejemplo de un sistema de base de datos relacional en esta figura, se asume que se recopila informacion acerca de los empleados. La tabla "Empleados" principal comprendera informacion sobre datos personales. Un empleado tiene un identificador 101, un nombre 102, un apellido 103 y vive en una ciudad 104 en una cierta direccion 105.

Tambien se recopila informacion acerca de las capacidades y aficiones de los empleados de la siguiente manera. Existe una tabla "Aficiones" que comprende la ID 106 Empleado como una clave remota, la descripcion de la aficion 107 y su nombre 108. De manera similar, existe una tabla "Capacidades" que comprende la ID 109 Empleado como una clave remota, descripcion de la capacidad 110 y su nombre 111.

Una normalizacion 3NF para la base de datos de la figura 1 se ha mostrado en la figura 2. Como se puede ver, la tabla Empleados sigue siendo la misma, pero las tablas aficiones y capacidades se han combinado en la tabla Hobbies_Skills, que comprende columnas de tanto la tabla de Aficiones como de Capacidades. Por lo tanto, hay un numero de tablas que se ha reducido por uno, pero la adicion de nuevas capacidades o aficiones para un empleado particular requerira duplicar un registro en la tabla Hobbies_Skills.

Una normalizacion 5NF, como se muestra en la figura 3, traena los siguientes cambios. La tabla Empleado sigue siendo la misma, mientras que, en comparacion con la tabla 3NF, la tabla Hobbies_Skills se ha dividido en cuatro tablas diferentes. Se han creado dos tablas de puramente de indexacion de Employee_Hobby y Employee_Skill, que solo comprende una clave Employee_ID y un mdice 112, 113 local de la aficion o capacidad, respectivamente. Esas dos tablas son enlaces entre las tablas Aficiones y Capacidades, que, en comparacion a las tablas originales de la figura 1 no comprenden ningun dato de la tabla Empleados.

Como ya se ha explicado, conforme el nivel de normalizacion aumenta, el esfuerzo computacional requerido con el fin de acceder y filtrar los datos tambien aumenta drasticamente. En primer lugar, el tiempo requerido en el servidor de base de datos para obtener los datos aumenta. Segundo, los datos se designan de tal manera que cuando los resultados ya estan localmente listos, la base de datos informa al cliente de como acceder al primer elemento del conjunto de resultados y entonces el cliente puede recuperar de manera interactiva todos los registros del conjunto de resultados. Tfpicamente, esto se ejecuta por un registro, con el fin de ahorrar ancho de banda del medio de comunicacion entre el cliente y el servidor. Este enfoque surge del hecho de que incluso aunque un conjunto de resultados puede ser grande, no todos los datos en el necesitan estar preparados para la presentacion.

Por lo tanto, cualquier mejora relacionada con minimizar el esfuerzo informatico en el servidor y/o reducir el tiempo

5

10

15

20

25

30

35

40

45

50

de recuperacion entre el cliente y el servidor de la base de datos son cruciales.

La figura 4 representa un procedimiento para ejecutar una consulta de base de datos de acuerdo con la invencion. Asumamos que en un simple ejemplo de la figura 1 uno necesita extraer os empleados en una ciudad determinada. Este simple ejemplo dara como resultado en la optimizacion del tiempo de entrega de los lados mas que en el tiempo de procesamiento de la consulta en el servidor.

En el resto de esta memoria descriptiva, una columna de una tabla es equivalente a una propiedad de un objeto de una estructura de datos dada (un conjunto).

En la etapa 401, el sistema necesita establecer, que columna/propiedad de una estructura/tabla de datos comprende el valor unico mas pequeno para registros dados. No es el valor real de datos, sino mas bien el tipo de datos en tal columna/propiedad lo que se toma en cuenta. El tamano de valores se determina tipicamente como tamano de campo de datos. Por ejemplo, los valores tales como numeros enteros de 64 bits son mayores que los valores tales como los numeros enteros de 16 bits.

En el ejemplo de la figura 1, la columna de Identificacion comprende los valores unicos mas pequenos (es decir, un numero entero que es tfpicamente 32/64 bits frente a una Cadena que es tfpicamente de 256 bytes). En la vida real existen muchos casos en los que un registro comprende varios valores unicos dentro de un conjunto/tabla/estructura. Por ejemplo, un artfculo comercial comprende un identificador, un codigo QR (del ingles Quick Response) y un numero de fabricacion que son todos unicos para un artfculo dado.

La cuestion de si un valor de tipo de datos de columna unico dado es mas pequeno que otro valor unico puede responderse usando un esquema de base de datos.

El esquema de base de datos es una estructura logica de una base de datos que se define tipicamente en un DBMS (Sistema de Administracion de Bases de Datos, del ingles Database Management System) con un uso de un lenguaje especial, por ejemplo, un DDL (un Lenguaje de Descripcion de Datos, del ingles Data Description Language). La estructura de base de datos interna se define como metadatos (este termino se refiere a "datos sobre datos") en un esquema llamado de informacion. En bases de datos relacionales, el esquema de informacion son datos que proporcionan informacion acerca de todas las tablas y/o vistas y/o columnas y/o procedimientos en una base de datos. Este conjunto de datos en dependiente de la base de datos y sus procedimientos de acceso normalmente son dependientes de la base de datos. Es, sin embargo, comun para una base de datos proporcionar tal estructura y acceso a ella. Los metadatos proporcionaran informacion acerca de los tipos de datos en cada columna/propiedad de cada tabla. Estos tipos pueden compararse con el fin de encontrar la columna/propiedad de valor unico mas pequeno.

La identificacion, en la etapa 401, del valor unico mas pequeno que se puede recuperar para un registro permite cantidad educida de datos necesarios que transferiran desde un servidor de base de datos hasta un cliente de base de datos.

En la etapa 402, se ejecuta una consulta, que incluye cualquier parametro de limitacion (un filtro de datos), que recuperara solo los datos desde la columna/propiedad que comprende el valor unico mas pequeno que se puede recuperar para un registro. Por tal enfoque, uno reduce al mmimo la cantidad de datos que se recuperaran.

A continuacion, en la etapa 403, comienza la recuperacion de resultados. Tan pronto como un numero predefinido de resultados (o todos los resultados disponibles) se ha recuperado, el sistema comprueba si el fin del conjunto de resultados se ha alcanzado 404.

Tfpicamente, el numero predefinido de resultados permanecera en un intervalo de entre 75 a 150 ya que hay una limitacion de base de datos de una cache de consulta y las consultas que exceden consulta elementos 150 puede devenir demasiado grande para ajustarse a un unico bufer de consulta, aumentando asf el esfuerzo computacional requerido por el procesamiento de la consulta. Por otra parte, dividir el resultado en conjuntos de varios elementos aumentana significativamente la sobrecarga en los procesos de gestion.

Una tabla hash se crea preferentemente donde los valores unicos mas pequenos de la consulta de la seccion 402 son claves y los resultados de las consultas de las secciones 405 y 406 son valores de la tabla hash.

Si hay mas registros en el conjunto de resultados, en la etapa 405 use crea un nuevo proceso de acceso a la base de datos que recuperara los datos que estan presentes en los registros identificados con el valor unico mas pequeno seleccionado en la etapa 401. De lo contrario, si no hay mas resultados en el conjunto de resultados, el proceso recupera los registros restantes en la etapa 406 donde un proceso final se crea que recuperara datos de los registros restantes identificados.

Una vez que el proceso 405 comienza, el procedimiento avanza a la etapa 403, donde otro lote de resultados de la seccion 402 de consulta se recupera, mientras que el proceso de la seccion 405 opera.

Cuando un conjunto de resultados se obtiene para la consulta ejecutada en un proceso 405, 406 de recuperacion de

5

10

15

20

25

30

35

40

45

50

datos, los datos se leen en la tabla hash definida previamente.

Es, por lo tanto, evidente que puede haber una pluralidad de procesos iniciados en la etapa 405, que pueden ejecutarse en paralelo.

Por lo tanto, los resultados finales se obtienen usando procesamiento paralelo y la etapa inicial de recuperacion de datos que son los datos representativos mas pequenos del conjunto de resultados completo.

Con el fin de mejorar adicionalmente la eficacia en cada proceso 405, 406, un operador establecido, en este caso el operador UNION se usa en una consulta, que combina el resultado de dos o mas declaraciones SELECT. La declaracion UNION tiene varios requisitos, que son que cada declaracion SELECT dentro de la UNION debe tener el mismo numero de columnas, y las columnas deben tener tipos de datos similares a las columnas en cada declaracion SELECT debe estar en el mismo orden.

El uso de un operador UNION incita al motor del servidor de base de datos al diferente enfoque de procesamiento de consultas que en el caso de un operador OR tfpico entre diferentes valores o parametros. En el caso de UNION hay consultas internas separadas de parametros separados de una unica consulta.

Por ejemplo, una consulta ejecutada en un proceso puede tener una forma similar a uno definido basandose en la tabla Empleados de la figura 1:

SELECT Employees.* FROM Employees WHERE ID=3 UNION SELECT Employees.* FROM Employees WHERE ID=6 UNION

SELECT Employees.* FROM Employees WHERE ID=16 UNION

El proceso de ejecutar una consulta 402, que incluye cualquier parametro de limitacion, puede optimizarse adicionalmente, especialmente en caso en el que la seleccion de valores particulares de la columna/propiedad que comprende el valor unico mas pequeno requiere consultar numerosas tablas/estructuras de datos.

En 4NF o 5NF, las consultas tfpicas de tipo JOIN a menudo son tan complejas que sus ejecuciones toman horas de procesamiento de datos extensivo.

Por ejemplo, uno necesita seleccionar empleados a los que les gusta el ciclismo (tabla de aficiones separada) y que se promocionaron durante los dos ultimos anos (tabla de promociones). En tales casos, en lugar de usar consultas de tipo JOIN uno puede emplear un operador INTERSECT. El operador INTERSECT se usa entre dos consultas SELECT seleccionadas con el fin de devolver solo valores que coinciden dentro de ambos conjuntos de datos devueltos por las consultas SELECT respectivas.

Por ejemplo:

SELECT Employee.ID FROM Employees WHERE Employee.NAME =

'ADAM'

INTERSECT

SELECT Hobbies.Employee_ID FROM Hobbies WHERE Hobbies.Name =

'cycling';

Esto devolvera una lista de identificadores de empleados cuyo nombre es Adam y a los que, al mismo tiempo, les gusta el ciclismo. Tal enfoque de utilizacion de INTERSECT y no JOIN con el fin de encontrar los valores unicos mas pequenos es muy eficiente.

El uso de consultas de interseccion es mucho mas eficiente para consultar estructura cruzada y la presente invencion devuelve los mejores resultados, en terminos de tiempo de recuperacion de datos, en caso de consultas de estructura cruzada compleja.

La figura 5 muestra una implementacion ejemplar del procedimiento mostrado en la figura 4 por simplicidad y presentacion de una idea general que puede implementarse en diferentes lenguajes de programacion, el presente ejemplo se formula en pseudocodigo.

El sistema presentado en el presente documento es especialmente util en bases de datos basandose en diagramas de ideas tal como una base de datos desvelada en la Solicitud de Patente Europea pendiente de aprobacion numero EP13461516.0 por el mismo Solicitante. En que tipo de base de datos particular, es especialmente facil ejecutar un procedimiento para encontrar objetos de interes que se relacionan a diferentes estructuras de datos porque, una relacion entre objetos esta presente en la estructura de datos OBJECT RELATIONS.

El uso de consultas que operan sobre conjuntos de datos, es decir, el uso de operadores de conjunto, en una base de datos de tipo esquema de ideas proporciona resultados mejorados debido a la estructura de la base de datos. Cada consulta que tendra en cuenta descripciones de objeto, objetos, relaciones, columnas y conjuntos requerina cada vez formular una consulta, que debido a la heterogeneidad de los tamanos de las tablas sena altamente

5

10

15

20

25

30

35

40

45

50

55

ineficiente, especialmente cuando se ejecutan con frecuencia.

Los objetos y sus descripciones en estructuras de una base de datos de tipo esquema de ideas, comprende un identificador de objeto. Por lo tanto, cuando se busca un objeto uno puede limitar no solo la estructura de datos caractensticos de objeto, es decir, la cuarta estructura 701 de datos, ya que esta estructura identifica sin ambiguedad un objeto. Esto tiene una especial ventaja durante la busqueda de objetos que se relacionen con otros objetos de un conjunto diferente. Tal busqueda puede formularse como sigue:

• para objetos seleccionados y una relacion seleccionada, ejecutar una funcion de busqueda sobre relaciones 708 de objeto con un identificador de relacion seleccionado

• desde la estructura de caractensticas, seleccionar, por medio de otra funcion de busqueda, solo aquellos que cumplen la condicion, por ejemplo, en la columna 13 hay un valor de "ADAM";

• Combinar ambas consultas con un operador INTERSECT.

Anadir otra restriccion relacionada con un valor diferente en una columna diferente es meramente una adicion de una consulta simple y que limita los resultados con un uso de operador INTERSECT.

Lo mas importante es que el proceso de busqueda y de navegacion completos de los resultados se centra en varias consultas que permanecen inalteradas excepto por los valores espedficos de parametros, debido a lo que no hay necesidad de escribir codigo de programacion redundante con el fin de cubrir mas consultas y mas espedficas.

Debido al uso de UNION e INTERSECT, existe una posibilidad de procesamiento mejorado y mas rapido de consultas.

Otro aspecto relacionado con UNION, INTERSECT y EXCEPT es que las estructuras de datos fundamentalmente diferentes pueden consultarse para los mismos datos.

La siguiente seccion de la memoria descriptiva presenta una parte clave de la Solicitud de Patente Europea pendiente de aprobacion numero EP13461516.0 del Solicitante.

La figura 6, que corresponde a la figura 2 de la solicitud pendiente de aprobacion, muestra un nuevo sistema de base de datos de acuerdo con la presente invencion. Con el fin de cooperar perfectamente con esquemas de ideas, el sistema de base de datos de acuerdo con la invencion se ha disenado de diferente manera a los sistemas de bases de datos conocidos. El sistema de base de datos comprende seis conjuntos de nucleo de datos y conjuntos opcionales. Los conjuntos de nucleos comprenden CONJUNTOS, OBJETOS, COLUMNAS, CARACTERfSTICAS, RELACIONES y RELACIONES DE OBJETOS. Cabe senalar que los nombres anteriores son ejemplares solo y que los conjuntos de nucleos respectivos se definen mas por su funcion dentro del sistema que por su nombre.

El primer conjunto de datos se llama CONJUNTOS 604, porque se usa para mantener logicamente datos relacionados con los conjuntos de datos. Los conjuntos de datos pueden representarse sobre un esquema de ideas como nodos. Cada entrada en la estructura 604 de datos CONJUNTOS comprende, al menos, un unico identificador 605a y preferentemente tambien su nombre 605. En referencia, de nuevo, al ejemplo de la figura 1, existen tres CONJUNTOS, es decir, COLORES que tienen identificacion de 1, MATERIALES que tienen identificacion de 2 y HERRAMIENTAS que tienen identificacion de 3. La estructura de datos CONJUNTOS es una estructura de nivel superior y no se refiere a otras estructuras de datos, sino que otras estructuras de datos se refieren a ello como identificandose por las flechas respectivas entre los conjuntos de la figura 6.

Cada conjunto de datos, como en el mundo real, se caracteriza por algunas propiedades tfpicamente llamadas columnas. Por lo tanto, el segundo conjunto de datos se llama COLUMNAs 606. Una propiedad, llamada tfpicamente una columna, se identifica unicamente con un identificador ID 607 y se asocia con un conjunto, definido en la estructura 604 de datos CONJUNTOS, por medio de un identificador llamado en el presente documento ID DE CONJUNTO 608. Una columna tambien se asocia preferentemente con un nombre 609. Como se indica por una flecha 604a, la estructura de datos COLUMNAS logicamente, se refiere directamente a la estructura de datos CONJUNTOS, porque usa los identificadores de conjuntos. Si, por ejemplo, cada color del conjunto llamado COLORES tiene otra propiedad, digamos, valor RGB, podna anadirse a una entrada que comprende los siguientes valores: "1", "4", "RGB". En este nivel del sistema, los tipos de datos respectivos tales como texto, numero entero, BLOB no se consideran como su aplicacion en el presente sistema es trabajo de rutina.

Habiendo definido las estructuras de datos de CONJUNTOS y COLUMNAS se pueden definir objetos que formaran elementos de CONJUNTOS respectivos y tendran propiedades definidas por las estructuras de datos COLUMNAS. Los objetos se mantienen en la estructura de datos OBJETOS 601. Esta estructura de datos mantiene unicamente entradas identificadas con un identificador ID 603 y un se asocian con un conjunto, definido en la estructura 604 de datos CONJUNTOS, por medio de un identificador llamado en el presente documento ID DE CONJUNTO 602. Como se indica por una flecha 601a, la estructura de datos OBJETOS logicamente, se refiere directamente a la estructura de datos CONJUNTOS, porque usa los identificadores de conjuntos.

La cuarta estructura de datos nucleo es una estructura de datos que mantiene entradas de datos de cada propiedad de cada objeto. Esta estructura de datos se ha llamado CARACTERfSTICAS 301 en la figura 6. Esto es una de las

5

10

15

20

25

30

35

40

45

50

55

diferencias fundamentales de todas las bases de datos conocidas donde hay filas de datos que comprenden entradas para todas las columnas de una tabla de datos. En la presente invencion, cada propiedad de un objeto se almacena como una entrada separada, que mejora enormemente la escalabilidad del sistema y permite, por ejemplo, anadir propiedades de objetos en tiempo real.

La estructura de datos CARACTERfSTICAS 701 mantiene unicamente entradas identificadas con un identificador ID DE OBJETO 702 y se asocia con una propiedad, definida en la estructura 606 de datos COLUMNAS, por medio de un identificador llamado en el presente documento ID DE COLUMNA 703. Ademas, cada entrada en la estructura de datos CARACTERfSTICAS, comprende un valor de la propiedad dada del objeto particular. Como se indica por las flechas respectivas que se originan a partir de las fuentes A y B, la estructura 701 de datos CARACTERfSTICAS logicamente, se refiere directamente a estructura de datos COLUMNAS y estructura de datos OBJETOS, porque usa los identificadores desde las estructuras de datos respectivas.

La quinta estructura de datos nucleo, del sistema de base de datos de acuerdo con la presente invencion, se disena para mantener dato respecto a las relaciones presentes en la base de datos. Esta estructura se ha llamado aqu RELATIONS 705. Es una estructura muy simple y, en principio, mantiene un identificador de una relacion ID 707 y, preferentemente tambien mantiene la descripcion textual de la relacion, es decir, un NAME 706. Como se indica por una flecha 705a, la estructura de datos RELACIONES logicamente, hace directamente referencia hacia abajo de la estructura de datos RELACIONES DE OBJETOS, porque las RELACIONES DE OBJETOS usan los identificadores de las relaciones.

La ultima estructura de datos nucleo de la presente invencion es la mencionada estructura 708 de datos RELACIONES DE OBJETOS. Esta estructura de datos de disena para proporcionar un esquema entre una relacion de la estructura 705 de datos RELACIONES y dos objetos de la estructura 701 de datos OBJETOS. Por ejemplo, la primera entrada en la estructura 708 de datos define que la relacion que tiene identificador de lexiste entre el un objeto que tiene un identificador de 1 y el objeto que tiene un identificador de 6.

Opcionalmente, existe una septima estructura de datos en el sistema de base de datos de la presente invencion. Esta estructura de datos mantiene datos con respecto a las relaciones entre los conjuntos de datos respectivos y en la figura 7 se llama RELACIONES DE CONJUNTOS 712. Esta estructura de datos se disena para proporcionar un esquema entre una relacion desde la estructura 705 de datos RELACIONES y dos conjuntos de estructura 604 de datos CONJUNTOS. Por ejemplo, la primera entrada en la estructura 712 de datos RElAcIONES DE CONJUNTOS define que la relacion que tiene un identificador de 1 existe entre un conjunto que tiene un identificador de 1 y un conjunto que tiene un identificador de 2. Proporcionar una entrada en la estructura 712 de datos RELACIONES DE CONJUNTOS entre un conjunto que tiene un identificador de 1 y un conjunto que tiene un identificador 2, asf como entre un conjunto que tiene un identificador de 2 y un conjunto que tiene un identificador de 1, permite crear una relacion bidireccional.

Tambien hay una posibilidad de referencia propia desde un conjunto dado. Por ejemplo, tal caso puede estar presente cuando hay un conjunto de personas y existe una relacion de estudiante - profesor entre personas asignadas a un conjunto particular.

Como se describe, por ejemplo, un sistema de base de datos relacional de cien tablas se almacenara en el presente sistema en las seis estructuras de datos descritas anteriormente. Naturalmente, la mayona de los datos permaneceran en las estructuras de datos OBJETOS y CARACTERfSTICAS.

Como se puede ver en la base de datos de tipo esquema de ideas, los objetos se relacionan directamente por medio de relaciones de objeto.

La figura 8 muestra un sistema de base de datos ejemplar, para el que el procedimiento presente se ha disenado por el que puede implementarse. El sistema de base de datos comprende un cliente 801 y un servidor 802. El cliente 801 accede a los datos y, por lo general, es un terminal remoto del servidor 802 que aloja una base 806 de datos y un sistema 807 de gestion de bases de datos responsable de responder las consultas del cliente. El cliente es normalmente un ordenador que comprende una memoria 803, un procesador 804 y un modulo 805 para ejecutar el procedimiento definido en la figura 4. Sera evidente que un canal de comunicacion adecuado debe establecerse entre el cliente 801 y el servidor 802.

Puede reconocerse facilmente, por un experto en la materia, que el procedimiento implementado por ordenador anterior para ejecutar consultas de bases de datos puede realizarse y/o controlarse por uno o mas programas informaticos. Tales programas informaticos se ejecutan tfpicamente utilizando recursos informaticos en un dispositivo informatico tal como ordenadores personales, asistentes digitales personales, telefonos moviles, receptores y decodificadores de television digital o similares. Las solicitudes se almacenan en memoria no volatil, por ejemplo, una memoria flash o memoria volatil, por ejemplo, RAM, y se ejecutan por un procesador. Estas memorias son medios de grabacion ejemplares para almacenar programas informaticos que comprenden instrucciones ejecutables por ordenador que realizan todas las etapas del procedimiento implementado por ordenador de acuerdo con el concepto tecnico presentado en el presente documento.

Mientras la invencion presentada en el presente documento se ha representado, descrito, y se ha definido con

referencia a realizaciones preferentes particulares, tales referencias y ejemplos de implementacion en la memoria descriptiva anterior no implican ninguna limitacion de la invencion. Sera, sin embargo, evidente que diversas modificaciones y cambios pueden realizarse en ello sin alejarse del ambito mas amplio del concepto tecnico. Las realizaciones preferentes presentadas son solo ejemplares, y no son exhaustivas del ambito del concepto tecnico 5 presentado en el presente documento.

Por consiguiente, el ambito de proteccion no se limita a las realizaciones preferentes descritas en la memoria descriptiva, sino que solo se limita por las reivindicaciones que siguen.

Claims

5

10

15

20

25

30

35

40

45

50

55

REIVINDICACIONES

1. Un procedimiento implementado por ordenador para ejecutar una consulta de base de datos en una base de datos, comprendiendo el procedimiento las etapas de:

• proporcionar, al menos, una estructura de datos, definida por un esquema de base de datos de dicha base de datos, que comprende, al menos, un objeto que tiene, al menos, dos propiedades, teniendo cada propiedad un tipo de datos asignado, en el que dichos tipos de datos pueden compararse con respecto a su tamano de datos;

• establecer (401), usando dicho esquema de base de datos de dicha base de datos, por comparacion, de dichos tipos de datos de las al menos dos propiedades, una propiedad de una estructura de datos seleccionada que comprende los valores unicos mas pequenos para registros dados de tipo de datos almacenados en esa propiedad particular;

• ejecutar (402) la consulta de base de datos, que incluye cualquier parametro de limitacion, configurado para recibir solo datos desde la propiedad que comprende los valores unicos mas pequenos que son recuperables para un registro;

• empezar (403) a recuperar resultados de la consulta (402) recuperada;

• para cada conjunto de numero de resultados recuperados predefinido, ejecutar (405) un nuevo proceso de acceso a la base de datos que se configura para recuperar datos que estan presentes en los registros identificados con los valores unicos mas pequenos.
2. El procedimiento de acuerdo con la reivindicacion 1 en el que la etapa (401) de establecimiento se basa en la informacion de esquema de la base de datos.
3. El procedimiento de acuerdo con la reivindicacion 1 en el que el numero predefinido esta entre 75 y 150 y los procesos de acceso a la base de datos se ejecutan en paralelo.
4. El procedimiento de acuerdo con la reivindicacion 1 en el que los resultados recuperados se almacenan en una tabla hash en la que los valores unicos mas pequenos de la consulta (402) son claves y los resultados de las consultas (405), (406) posteriores son valores de la tabla hash.
5. El procedimiento de acuerdo con la reivindicacion 1 en el que la consulta ejecutada por cada proceso (405), (406) utiliza los operadores UNION entre las consultas SELECT limitadas con los valores de la propiedad de valor unico mas pequena.
6. El procedimiento de acuerdo con la reivindicacion 1 en el que la etapa de ejecutar una consulta (402) utiliza, en caso de estructuras de datos de numerosas consultas cruzadas, un operador INTERSECT entre subconsultas relacionadas con diferentes estructuras de datos.
7. El procedimiento de acuerdo con la reivindicacion 1 en el que la base de datos comprende:

• una primera estructura (604) de datos, almacenada en la memoria, que comprende una definicion de al menos un conjunto de datos en la que cada conjunto de datos comprende un identificador de conjunto de datos y contiene de manera logica objetos de datos del mismo tipo;

• una segunda estructura (606) de datos, almacenada en la memoria, que comprende definiciones de propiedades de objetos en las que cada propiedad comprende un identificador de la propiedad y un identificador de un conjunto, desde la primera estructura (604) de datos, a la que la propiedad se asigna;

• una tercera estructura (601) de datos, almacenada en la memoria, que comprende definiciones de objetos en la que cada objeto comprende un identificador y un identificador de un conjunto, desde la primera estructura (604) de datos, a la que el objeto se asigna;

• una cuarta estructura (701) de datos, almacenada en la memoria, que comprende definiciones de propiedades de cada objeto en la que cada propiedad de un objeto asocia un valor con un objeto, desde la tercera estructura (601) de datos, y una propiedad del conjunto,desde la segunda estructura (606) de datos, a la que el objeto se asigna;

• una quinta estructura (705) de datos, almacenada en la memoria, que comprende definiciones de relaciones en la que cada relacion comprende un identificador de relacion; y

• una sexta estructura (708) de datos, almacenada en la memoria, para almacenar definiciones de relaciones entre objetos en la que cada relacion de objetos se asocia una relacion, desde la quinta estructura (708) de datos, hasta dos objetos desde la tercera estructura (601) de datos.
8. Un programa informatico que comprende medios de codigo de programa para realizar todas las etapas del procedimiento implementado por ordenador de acuerdo con cualquiera de las reivindicaciones 1 - 7 cuando dicho programa se ejecuta en un ordenador.
9. Un medio legible por ordenador que almacena instrucciones ejecutables por ordenador que realizan todas las etapas del procedimiento implementado por ordenador de acuerdo con cualquiera de las reivindicaciones 1 - 7 cuando se ejecuta en un ordenador.