Query processing method

• US 6,704,726 B1
• Filed: 11/07/2000
• Issued: 03/09/2004
• Est. Priority Date: 12/28/1998
• Status: Expired due to Term

• Current Assignee: Bull Sas (Atos SE)
• Original Assignee: Bull Sas (Atos SE)
• Inventors: Amouroux, Rémy
• Primary Examiner(s): ROBINSON, GRETA LEE
• Application Number:
  US09/622,357
• Time in Patent Office: 1,218 Days
• Field of Search: 707/3, 707/10, 707/4, 707/100
• US Class Current: 1/1
• CPC Class Codes: G06F 16/24524 Access plan code generation and invalidation; Reuse of access plans
• CPC Class Codes: Y10S 707/99934 Query formulation, input preparation, or translation

Abstract

The process and architecture for database query processing includes techniques allowing a query to be made of various heterogeneous data sources by a client application using an adapter device specific to each source. The client application or client transmits a query received by the adapter device of the corresponding source to which the query is directed. The adapter device or adapter provides an internal representation of the query. The internal representation is then used to rewrite the query in a format compatible with the source. The rewritten or converted query is then transmitted to the data source with production of a filter object and initialisation of at least one filter chain. The filter object retrieves the results and filters the results through the filter chain. An answer object is produced to transfer results from a result conversion module to the client.

Claims

1. A query and result processing process between one or a plurality of client applications, and a plurality of heterogeneous data sources by an adapter specific to each source, and having a format of a given architecture, characterised in that the process carries out the following steps independently:

reception of a query transmitted by an application in a format compatible with a client,

defining of an internal representation of the query in an adapter by a format of the adapter,

rewriting the query in a format compatible with the source by use of said internal representation of the query by an internal format conversion component in a source format,

initialising at least one filter chain composed of one or more filter components by transmitting of the converted query to a source, producing a filter object and using an internal representation by a process building component,

initialising in the filter chain the filter component (s) required to complete a first filtering operation resulting from the filter object so as to produce an answer compatible with the adapter'"'"'s format,

retrieving by the filter object the results from the source to transmit and filter the results through the initialised filter components in the chain, and

producing an answer object to transfer results from a result conversion module to a client application.

2. A processing process according to claim 1, characterised in that, for defining the internal representation, a plurality of components are stacked, including analysis components and conversion components.

3. A processing process according to claim 1 characterised in that the filter chain is initialised using the internal representation of the query and the filter object.

4. A processing process according to claim 1 characterised in that the answer object is produced using initialised filter components in the filter chain.

5. A processing process according to claim 1, characterised in that the answer object is returned to the client application for retrieving the results.

6. A processing process according to claim 1, characterised in that metadata relating to the schema of the data in the source, the operators supported by the source and the costs associated with said operators is supplied to the client application.

7. A processing process according to claim 2 characterised in that the filter chain is initialised using the internal representation of the query and the filter object.

8. A processing process according to claim 2 characterised in that the answer object is produced using initialised filter components in the filter chain.

9. A processing process according to claim 2, characterised in that the answer object is returned to the client application for retrieving the results.

10. A processing process according to claim 2, characterised in that metadata relating to the schema of the data in the source, the operators supported by the source and the costs associated with said operators is supplied to the client application.

26. The processing process according to claim 1, characterised in that the plurality of client applications each use a different query language.

11. An adapter architecture operable for a query and result processing process between one or a plurality of client applications, and a plurality of heterogeneous data sources by an adapter specific to each source, and having a format of a given architecture, wherein the process, that the adapter architecture carries out includes following steps:

reception of a query transmitted by an application in a format compatible with a client,

defining of an internal representation of the query in an adapter by a format of the adapter,

rewriting the query in a format compatible with the source by use of said internal representation of the query by an internal format conversion component in a source format,

initialising at least one filter chain composed of one or more filter components by transmitting of the converted query to a source, producing a filter object and using an internal representation by a process building component,

initialising in the filter chain the filter component (s) required to complete a first filtering operation resulting from the filter object so as to produce an answer compatible with the adapter'"'"'s format,

retrieving by the filter object the results from the source to transmit and filter the results through the initialised filter components in the chain, and

producing an answer object to transfer results from a result conversion module to a client application; and

further characterised in that the adapter architecture comprises four modules including;

(a) a co-ordination module acting as an interface with a client application and including a connection component and an answer component;

(b) a query conversion module, including at least one analysis component, at least one conversion component and a process building component;

(c) a communication module with the source including a source component and a source access filter component; and

(d) a result conversion module including filter components all having the same interface; and

each module including components, each with a specified interface.

12. The adapter architecture according to claim 11, characterised in that the same application programming interface (API), the same query language and the data pattern in the form of metadata from the source are used to process each source.

13. The adapter architecture according to claim 12, characterised in that the result conversion module is composed of a set of components selected from the group consisting of the following four types of filter components:

operator components applying additional limits to the answer, extraction filters performing an information extraction or structuring method chain, structure conversion filters to retrieve the data schema, and answer building filters converting the answer to the data format of the client application.

14. The adapter architecture according to claim 13, characterised in that a plurality of components are stacked including analysis components and conversion components.

16. The adapter architecture according to claim 11, characterised in that the filters of the result conversion module all comprise the same interface including OPEN, GET-NEXT and CLOSE methods and process data in the same internal format, the filters being concatenated in any order according to the extraction, checking, and conversion requirements.

17. The adapter architecture according to claim 13, characterised in that first three types of components may be used several times in the chain with different initialisations to carry out conversions, which are impossible only using one filter.

18. The adapter architecture according to claim 11, characterised in that the interfaces with the client application enable the local or remote use of an adapter.

19. The adapter architecture according to claim 13, characterised in that each adapter supports a subset of said usable operators selected from the search, select, project, merge and combine operators.

20. The adapter architecture according to claim 11, characterised in that a method is used to send the data structure in the source to the client application and thus enable the client application to retrieve the results.

21. The adapter architecture according to claim 11, characterised in that the connection component uses an interface composed of a first query reception method, a second getCapability encoding method for the list of query operators supported by the adapter, a third getSchema internal representation method of a schema class for the data on the source, a fourth getCost method encoding the cost information associated with each operator used to evaluate the time and memory of the result of a query, the second, third and fourth methods presenting the information in string form.

22. The adapter architecture according to claim 11, characterised in that the analyzer extracts, by means of a first setRequest method, different elements of the query and uses the different methods listed below, a second getSelectClause method which returns a string type list name (name, alias) of the projected attributes (selectclause), a third getFromClause method which returns a relation (from clause) string type list name (name, alias), a fourth getWhereClause which returns a predicate describing the selection condition (where clause), a fifth getGroupByClause method which returns an attribute (groupby clause) string type list (name, alias) and a sixth getHavingClause method which returns a predicate using all the operators used to select the groups (having clause).

23. The adapter architecture according to claim 22, characterised in that the format of the predicate is dependent on the implementation.

24. The adapter architecture according to claim 12, characterised in that the result conversion module is composed of a set of components selected from the group consisting of the following four types of filter components:

operator components applying additional limits to the answer, extraction filters performing an information extraction or structuring method chain, structure conversion filters to retrieve the data schema, and answer building filters converting the answer to the data format of the client application.

25. The adapter architecture according to claim 12, comprising incoming query analysis means to identify a plurality of elements used in producing the query accepted by the source and in converting the results from the source, the elements including:

names of the relation, attributes of the projection, and selection and concatenation predicates.

27. The adapter architecture according to claim 11, characterised in that the plurality of client applications each use a different query language.

15. The adapter architecture according to 30, comprising incoming query analysis means to identify a plurality of elements used in producing the query accepted by the source and in converting the results from the source, the elements including:

names of the relation, attributes of the projection, and selection and concatenation predicates.