[go: up one dir, main page]

EP1057128A1 - Procede de traitement d'une requete - Google Patents

Procede de traitement d'une requete

Info

Publication number
EP1057128A1
EP1057128A1 EP99964723A EP99964723A EP1057128A1 EP 1057128 A1 EP1057128 A1 EP 1057128A1 EP 99964723 A EP99964723 A EP 99964723A EP 99964723 A EP99964723 A EP 99964723A EP 1057128 A1 EP1057128 A1 EP 1057128A1
Authority
EP
European Patent Office
Prior art keywords
source
adapter
filter
request
components
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP99964723A
Other languages
German (de)
English (en)
Inventor
Rémy AMOUROUX
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bull SAS
Institut National de Recherche en Informatique et en Automatique INRIA
Original Assignee
Bull SAS
Institut National de Recherche en Informatique et en Automatique INRIA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bull SAS, Institut National de Recherche en Informatique et en Automatique INRIA filed Critical Bull SAS
Publication of EP1057128A1 publication Critical patent/EP1057128A1/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2452—Query translation
    • G06F16/24524—Access plan code generation and invalidation; Reuse of access plans
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99931—Database or file accessing
    • Y10S707/99933—Query processing, i.e. searching
    • Y10S707/99934—Query formulation, input preparation, or translation

Definitions

  • the present invention relates to a method for processing a request.
  • the invention relates more particularly to a request and result transformation method between a client application and a plurality of heterogeneous sources of data by an adapter device of given architecture, specific to each data source, and the given architecture of adapter allowing the implementation of said process.
  • a lot of useful information is locked up in private files, and manual extraction of information, even partially usable, requires a lot of time.
  • the integration of new servers or databases is laborious work and the result is generally inflexible and difficult to understand.
  • the main problems are accessing information where it is, in its original form, transforming it into a usable format and delivering it to the applications that need it.
  • the processing of a customer's request is done by an adapter.
  • a specific adapter is associated with each data source.
  • the present invention therefore aims to overcome the drawbacks of the prior art by proposing a method for processing a request, common to all the adapters.
  • the method according to the invention provides a uniform access interface to information sources such as relational DBMSs (DataBase Management System), system files, "Lotus Notes” databases, document management systems and "Web” servers (WorldWideWeb), for example.
  • the aim of the invention is to propose a method which makes it possible to extract information by working directly, for example, from a report, invitations to tender or similar documents in heterogeneous formats such as HTML (HyperText Markup Language) or ASCII (American Standard Code for Information Interchange), to obtain an object, a publication date or for example the place of a call for tenders published on a server having a determined protocol such as HTTP ( HyperText Transmission Protocol).
  • the proposed method must allow information to be filtered to select useful information, instead of adding another specific function for each application which needs the information.
  • This object is achieved by the fact that the process for processing requests and results between a client and a plurality of heterogeneous sources of data by an adapter device specific to each source, of given architecture, performs the following steps independently:
  • the initialization of the filter chain is carried out from the internal representation of the request and of the filter object.
  • the response object is produced from the filter chain.
  • the response object is returned to the client application to allow it to retrieve the results.
  • metadata concerning the schema of the data in the source, the operators supported by the source and the costs associated with these operators are provided to the client application.
  • Another object of the invention is to propose a given architecture adapter allowing the implementation of said method.
  • the adapter comprises four modules, a coordination module serving as an interface with the client application comprising a connection component and a "response" component, a request transformation module, comprising at at least one analysis component, at least one translation component and one processing construction component, a source communication module comprising a first "source” component and a second "source access filter” component and a transformation of the result comprising third filter components all having the same interface, each module comprises components each having a determined interface.
  • the same application programming interface API
  • the same query language and the same data model in the form of source metadata are used to process each source.
  • the transformation module of the result consists of a set of components chosen from four kinds of thirds filter components, "operator” components applying additional constraints to the response, extraction filters, structure translation filters and response construction filters transforming the response into the data format of the client application.
  • analysis components and / or translation components are stacked.
  • FIG. 1 represents the architecture of an adapter according to the invention and the treatment method of a request.
  • the adapters (1) are based on the transformation of requests and results between an application (6) and a data source (7) by a double process of rewriting the request and transforming the result .
  • An adapter is associated with a source. The adapter is responsible for giving a relational view of the source to which it is attached.
  • the requests coming from the client application (6) are analyzed, then transformed into requests supported by the data source manager (7), the parameters of the request are extracted and used to guide the transformation of the result.
  • the results are transformed by information extraction and restructuring processes.
  • Adapters can be used directly to access data sources from applications.
  • the client application (6) can be any application needing to access a data source in a structured relational form.
  • the architecture of the adapter (1) according to the invention can be broken down into four main modules: a coordination module (2), a request transformation module (3), a result transformation module (4) and a source communication module (5).
  • the coordination module (2) serves as an interface with the client application (6).
  • the coordination module (2) communicates with the client application (6) by exchanging requests and responses with the client application (6).
  • the request transformation module (3) is responsible for analyzing the request received and translating of it in operations supported by the data source manager (7).
  • the result transformation module (4) is responsible for restructuring the results, translating the data types from the source into the data types of the client application (6) in general, and elaboration of the response sent to the client application (6).
  • the adapters offer query features and data models based on relational database technology to provide uniform access to different data sources. This involves translating a database query into a non-database query and translating unstructured results into relational structured results.
  • the communication module (5) with the source is responsible for communication with the source (7) and encapsulates responses in data structures compatible with the source in data structures compatible with the adapter (1). Its role is on the one hand, to send the request to the source and on the other hand, to recover the results that the source (7) returns.
  • Each module is made up of a set of components. The functionality of each module and the various components used to build them will now be described.
  • the modules making up the architecture can be classified into three different layers: the "Client” layer (8), the internal layer
  • the "Client” layer (8) comprises the coordination module (2) and the “Source” layer comprises the communication module (5) with the source.
  • the internal layer (9) of the adapter deals with the content, that is to say with the requests received from the client application and sent to the source (7), and the data received from the source and sent to the client application.
  • the internal layer (9) comprises the transformation module (3) of the request and the transformation module of the result (4).
  • the client application using this configuration file determines the adapter used.
  • the "Client” layer (8) groups the components that deal with the client application at the access level. Its role is to serve as an interface with the client application.
  • the components of the client layer create an interface used by the client application (6).
  • the coordination module (2) of this client layer has four main responsibilities. First, a connection component (21) accepts a request (71) from a client application and passes (72) the request to the request transformation module (3). Second, a "Response" component (22) is used to transfer the result, coming from the transformation module (4) of the result, to the client application (6). Third, it delivers metadata to the client application regarding the schema of the data in the source, the operators of the query with their costs when required. Metadata is data about the structure of the data itself. Fourth, it dynamically initializes and configures the other components of the adapter.
  • the internal layer (9) of the adapter groups the components which deal with data transformation.
  • Two modules are associated with the two main transformations carried out which are the query transformation module (3) and the results transformation module (4).
  • the main functions of the request transformation module (3) are on the one hand, to rewrite the request coming from the coordination module into a request which can be submitted to the data source (7) and on the other hand, d 'initialize the results transformation module (4) which will process the results retrieved from the source (7). This is done in three phases. First, the incoming request is analyzed to identify the elements used, during the elaboration of a request accepted by the source and during the transformation results. These elements are the names of the relation, the attributes of the projection, and the selection or join predicates.
  • This step consisting in establishing an internal representation of the request, is carried out by an analysis component (31).
  • the information made up of these elements is used in a translation component (32) which rewrites the request in a form which can be accepted by the manager of the data source (5).
  • the information is used by a "process builder" component (33) to initialize all the necessary filters.
  • the query submitted to the data source provides a set of responses which is then filtered to produce a correct response to the client application. Passing this set of responses through the filters may be required to extend or increase the request processing capabilities of a data source manager.
  • the analysis of the request, by the component (33) makes it possible to initialize filters according to the needs of the client application.
  • the result transformation module (4) is responsible for extracting the relevant information from the responses obtained by the communication module with the source (5). This module (4) is also responsible for carrying out transformation on these, if necessary, and then for formatting the response to the data format of the client application (6).
  • This module consists of a stack of components (42 to 45) called filters. Passing through this filter chain (46) corresponds to data extraction, verification against the initial request and conversions.
  • the filters of the results transformation module (4) all have the same interface including "open”, “get-next", “close” methods and manipulate the data in the same internal format. Thus, the filters can be chained in any order according to the needs of extraction, verification and conversion. There are four classes of filters.
  • the so-called "operator” filters (42) apply additional constraints to the response returned by the source, corresponding to selection or projection operators for example.
  • So-called extraction filters (43) carry out a chain of information extraction and structuring methods.
  • a structure translation filter (44) can be used to retrieve the data schema. These three types of components can be used several times in the chain with different initializations to carry out transformations which prove impossible by using only one filter.
  • a response construction filter (45) ends the chain. This filter transforms the response from the internal data format of the adapter (1) to the data format of the client application.
  • the “Source” layer (10) groups the components, which manage access from the source (7), in order to send a request to the source and retrieve the results.
  • a first “Source” component (51) accepts requests in the format of the data source originating from the translation component of the request (32).
  • a second component “Source access filter” (52) retrieves the results that the source returns according to the protocol of the source, these results being in the form, in the format and in the coding used by the source. This component (52) transforms these results to send them to the filter chain (46) in the internal format of the internal layer (9) of the adapter.
  • the coordination module (5) with the source (7) has two functions. It sends a request to the data source, for example a SQL (Structured Query Language), or HTTP request. It uses the "filter” interface of the result transformation module (4) to return the next element of the response from the data source in the adapter's internal data format.
  • FIG. 1 A description of the processing by the adapter of requests received from customers will now be made with reference to FIG. 1 in which the continuous arrows with a full head represent the path of a request, of a representation of a request or of 'particular information and the arrows with broken lines and with full head represent the data flow and the arrows with broken lines and with hollow head represent the operations of creation of an object of the process.
  • a client (6) When a client (6) has requests to send to an adapter (1), it opens a connection to the adapter using a "Wapper" interface (annex), and submits the requests to the adapter.
  • the connection component (21) receives the request (71) and transmits the request (72) via the "Analysis" interface to the module (3) for transforming the request.
  • the adapter uses the analysis component (31) of the request forming part of the module (3) for transforming the request to establish an internal representation (73, 74) of the request which it transmits to the translation component (32) in a format compatible with the interface "Request Builder".
  • This internal representation (73, 74) is also compatible with the "Process Builder” interface of the processing component (33).
  • the representation (74) of the request is used by the request translation component (32) to translate the initial request (71) of the client application into a format compatible with the "Source” interface. that the source can understand.
  • the translated request (75) is submitted to the source through a "Source” component (51) of the source layer, and a filter object corresponding to the "Source access filter” component (52) is produced.
  • This filter object (52) realizes the "Filter” interface (represented in appendix 1 by the references 18 and 181 to 184) of the result transformation module.
  • This filter object (52) is the first element of the filter chain which will filter and allow to retrieve the results from the source using the methods "open” (182), “next” (183), “close” (184 ).
  • the adapter uses a component “processing constructor” or “filter initializer” (33), to initialize in the filter chain, the filter or filters necessary to complete the first filtering (52) in order to produce a response compatible with the format of the adapter.
  • the adapter gives this processing constructor (33) on the one hand the internal representation (73) of the request by a function which uses as parameters the results of the "Analysis” interface and on the other hand share, by the arrow referenced (76), the filter object (52) produced by the source component (51.
  • This processing constructor (33) renders a filter chain (46) made up of different filter components (42 to 45)
  • the final phase is the construction of a response object, corresponding to the "Response" component (22).
  • This response object is produced by the connection component (21) using the filter chain (46) that the processing constructor (33) provides it via the link (77).
  • the connection component (21) gives the client application (6) the response object.
  • the client application uses the "Answer” interface (12) of this component (22), comprising "open”, “next” methods, "close”, to retrieve the results in the particular data format of the interface.
  • the following interfaces appearing in appendix 1 and 2 make it possible to submit a request, to retrieve results and to manage an adapter in operation.
  • the notation used for the interfaces is the following "vector getSelectClause (), in which the content in parentheses expresses the parameters used by the function” getSelectClause "and” vector "expresses the form of the result provided by the function used by the interface.
  • This result can be in the form of a chain (string), boolean (boolean), vector (vector) or an object (object)
  • the "Client” layer defines the interfaces and components allowing the use of an adapter.
  • the interfaces of the "Client” layer make it possible to use an adapter locally or remotely.
  • the "Client” layer (8) comprises two specific interfaces, a first interface at the same time of connection (11, appendix 1), called “Wrapper” and adapter administration (13, appendix 1), produced by the connection component (21), and a second "Answer” interface (12) produced by the "response” component (22).
  • first "Wrapper” interface provides the application cl have access to the basic services of an adapter (1).
  • This interface includes a first "query” method (111) which uses an object as an input argument. This "query” method allows you to receive the request from the client application using as an input argument an object representing the request issued by the client application.
  • This "query” method also makes it possible to return (78) to the client application the response object (22) which provides a certain number of functions defined in the "Answer (12) interface.
  • a second method (GetCapability ) (112) of the first "Wrapper" interface does not take any input argument into account.
  • This second method returns a string encoding the list of query operators supported by the adapter and their conditions of use. representing the capabilities of the adapter.
  • the character string describes the operators that the adapter supports and how they can be combined.
  • the operators that can be used are exploration, selection, projection, union and combination operators. Each adapter supports a subset of these operators.
  • a third method (getSchema) (113) of the first "Wrapper" interface takes no input argument into account and returns a character string constituting a list of types.
  • Each type describes the internal representation of a class in the source data schema.
  • Types are constructed using, on the one hand, basic types such as integer, real, boolean, string and, on the other hand, constructors for sets and tuples or "tuples”.
  • a tuple is a list of pairs (attribute-value). The types are defined when the adapter is created.
  • This third method is used to transmit to the client application the structure of the data in the source and thus allow the client application to retrieve the results.
  • a fourth method (getCost) (114) of the first "Wrapper" interface (11) does not take into account any argument and returns a string encoding the cost information associated with each operator. The cost information makes it possible to evaluate the time and the memory size of the result of a query.
  • the client application maintains a cost model in order to select the best execution plan, that is to say the best filter chain.
  • a default cost model is defined on the client application. In order to improve this model, costs are passed from adapters to the client application using the function of the fourth method (getcost) (114).
  • the second "Answer” interface (12, appendix 1) provides the client application (6) with the services to retrieve the results of the request submitted.
  • This interface includes different methods.
  • a first method (getAII) (121) of the second "Answer” interface takes no input and returns a set of "tuples", list of pairs (attribute-value). This function returns a set of all the tuples returned by the source and filtered by the adapter.
  • the second (open) method (122) of the second "Answer” interface takes no input and produces no output. It performs the necessary initialization procedure before the first "tuple” can be sent to the client application.
  • a third method (getNext) (123) of the second "Answer” interface takes no arguments and returns a "Tuple” object.
  • This object sets a "tuple” which is a part of the response to subqueries passed to the response object of the "Response" component (22). If there are no other tuples in the response, it returns a "null”.
  • a fourth (close) method (124) of the second "Answer” interface takes no arguments. It performs cleaning operations. It does nothing if called before an opening call. This function can be called before retrieving the last "tuple”.
  • the third method getnext
  • the "Client” layer (8) includes a third "AdaptaterAdmin” interface (13, appendix 1) making it possible to initialize and configure the components of the adapter according to the access parameters of the source.
  • This third interface provides administration services for managing an adapter during or after initialization.
  • JDBC Java DataBase Connectivity
  • "Java” is a new programming language, designed by the company “Sun”, based on C ++.
  • JDBC is a utility for connecting "Java” to databases.
  • This fourth JDBC interface (14, appendix 1) is a standard SQL database access interface, providing uniform access to a wide range of databases. As the query is an object, this JDBC interface (14) can be used with any type of database provided that there is an underlying translation component. A JDBC manager needs to handle SQL queries, which cannot be done at the interface level.
  • the adapter programmer for the analysis component (31) in the module request transformation (3) is a SQL grammar analyzer
  • the adapter will be fully JDBC compliant.
  • the interfaces are not the same, features found in the interfaces (11, 12, 13) of the "Client" layer described above can be found in the fourth JDBC interface.
  • the various JDBC interfaces listed below, "java. Sql. Driver”, “java. Sql. Connection””java.sql.ResultSet” and “java.sql.DatabaseMetadata” are part of the JDBC standard.
  • the creation of the "java. Sql. Driver” interface (141) replaces the third interface (AdaptaterAdmin) described above. The configuration must be done before connecting the database.
  • the realization of the interface "java. Sql. Connection” (142) plays the same role as the realization of the interface “Wrapper” for the recovery of metadata and the submission of the request.
  • the realization of "java.sql.ResultSet” (143) plays the same role as the realization of the interface "Answer” (12) to retrieve results.
  • the methods to retrieve the adapter capacities and the cost information correspond to methods of the "java.sql.DatabaseMetadata" interface.
  • the request transformation module (9) must contain three elements for each adapter: an analysis component (31), a request translation component (32) and a processing construction component (33) which can each be stackable. So for another client language the adapter will use another analysis component (31 '), another query translation component (32') and another processing construction component (33 '), each adapted to this other language, but uses the same methods that make up interfaces for a given component. Each has its own interface used by the coordination module (2) to finally generate an execution plan, that is to say the filter chain (46), is defined by the "ProcessBuilder” components from the file configuration and information extracted from the request by the analysis component for a received request.
  • a first "Analysis" interface (15) contains the methods that a request analyzer (31) must perform.
  • the query is considered something similar to SQL queries.
  • the request is given to the analyzer (31) at the time of creation or with a first method “setRequest” (151).
  • the format of the request depends on the interface made.
  • the parser must extract different elements from the request and uses the different methods below.
  • a second method “getSelectClause” (152) returns a list (name, alias), of type string, of the projected attributes ("selectclause”).
  • a third method “getFromClause” (153) returns a list (name, alias) of type chain of relations ("from clause”).
  • a fourth “getWhereClause” method (154) returns a predicate describing the selection condition ("where clause”). The format of the predicate depends on the implementation.
  • a fifth method “getGroupByClause” (155) returns a list (name, alias), of type string, of attributes (groupby clause).
  • a sixth method “getHavingClause” (156) returns a predicate using all of the operators used to select the groups (having clause). The format of the predicate depends on the implementation.
  • the analysis of the request can be carried out in phases by stacking different analyzers. A stack (31, 31 ', ...) of analysis components may be necessary to solve conversion problems for example.
  • a second "Request Builder” interface (16) contains the methods that a request translation component (32) must perform.
  • the incoming request is defined as the output of the previously described parser ("select clause", “from clause”, “where clause”, “groupby clause” and “having clause”).
  • the request is given to the translation component at the time of creation or with the "setRequest” (161) method. This method returns the value “true” if all goes well, “false” otherwise.
  • the format of the translated request depends on the type of format that the source can accept.
  • Another method “getTranslatedQuery” (162) returns the translation of the previously given query. In the same way as the analysis components, different translation components (32, 32 ', ...) can be stacked.
  • a third interface "Process builder” (17) contains the signatures of the method that a processing constructor (33) must carry out.
  • the processing constructor (33) needs to produce the execution plan.
  • the processing manufacturer supplies the filter chain (46), which constitutes the main component of the execution plan corresponding to the given request.
  • a first method (171) makes it possible to give the processing constructor (33) the necessary information, extracted by the analysis component (31), to generate the execution plan.
  • a second method (172) makes it possible to give the processing constructor (33) the first filter element of the execution plan. This first element is the filter object corresponding to the "Source access filter” component (52), supplied by the source component (51) after the submission of the translated request, and making it possible to retrieve the results from the source.
  • a third method (173) returns to the connection component (21) the execution plan (77), that is to say the chain (46) of filters calculated for the request.
  • the result transformation module (4) contains interfaces and classes for building a filter chain that processes data from the source before sending it to the client application.
  • the following interfaces and classes are used by each component of this module in order to reduce the dependence of the components and to promote the reuse of these components.
  • Each filter component (42 to 45) must provide a "Filter” interface (18). This interface makes it possible to compose a filter chain (46) by inserting any filter component at any position.
  • a first method "initialize” (181) initializes the filter with the given list of parameters contained in a direct access table (hashtable).
  • a second "open” method (182) opens the stream of data delivered by the chain.
  • a third method “next” (183) returns an object of the class "DataFormat” representing a tuple. This method allows you to take the tuples of the same request one after the other.
  • a fourth "close” method (184) closes the data stream delivered by the chain.
  • a class "DataFormat” defines the structure for processing common data in the adapter. In the case of filters, it corresponds to a list of attribute-value pairs or "tuples" which is transmitted from one filter in the chain to the next filter.
  • a set of methods (61), given by way of example in appendix 2, makes it possible to handle a tuple containing semi-structured data defined by the "DataFormat” class.
  • the result transformation module can include additional interfaces to allow, for example, to perform processing in parallel.
  • the components of the source layer (10) must provide a "Source” interface (62, appendix 2) in order to be used by the connection component (21) of the coordination module to retrieve the information in the form of metadata and to send the request at the source.
  • This interface includes a first method “checkMetadata” (621) which checks the availability of metadata.
  • This interface includes a second method “getMetaData” (622) retrieves the metadata delivered by the source and translates it into something understandable by the upper client layer.
  • a third "sendQuery” method (623) receives a request understandable by the source, produces and returns (76) to the processing constructor (33) a filter object (52) in order to retrieve the results.
  • the source component (51) If the source component (51) is configurable during the operating period, it must provide another interface (63), called the "Admin" interface.
  • This interface includes a first method “setConfig” (631) to give the configuration parameter to the source component.
  • the source component programmer must provide the format and form of this or these parameters.
  • the interface uses a second “getConfig” method (632) to retrieve the configuration parameters available in the adapter.
  • the adapters according to the invention have many advantages. They offer a uniform access interface to heterogeneous sources of information, each interface relying on a minimum number of carefully selected methods.
  • the same application programming interface (API) the same query language and the same data model are used to process each source, even if these sources are completely different in terms of access protocol, query language and the data model. Only the objects to which the methods apply are modified according to the source languages and the languages of the client applications.
  • the definition of a generic architecture with common interfaces for the components included in the adapter modules makes it possible to produce components, for example, connection (21), analyzer (31), translator (32), filter (42 45), processing (33) source (5), reusable. These components can be reused in several adapters without modifications.
  • the composition of reusable components in component chains allows programmers to easily make adapters.
  • the evolution of data sources and the evolution of components can be easily supported by plugging components into chains of components already existing in the adapter or by replacing one component with another.
  • the rapid creation of robust adapters relies on these reusable components.
  • the common architecture according to the invention can be used with libraries of reusable components to create adapter families characterized by a common data manager, for example "Lotus Notes", or to create specialized adapters made for a source of specific data.
  • Three types of components can be distinguished according to their dependence on the data manager of the associated source. This dependency dictates how the components can be reused from one adapter to another. Some components are specific to an adapter and cannot be reused.
  • query building for a WWW depends on the language that this particular source accepts.
  • Some components are common to an adapter family.
  • the HTTP communication module can be reused for all adapters associated with a website-based data source.
  • Some components are common to all adapters.
  • the projection and selection filters applied to data obtained from the source do not depend on the source, and can potentially be reused to build each adapter.
  • the method according to the invention makes it possible to provide "metadata" to the client application to optimize the requests and allow better use of the source.
  • the adapter provides metadata about the source of data, allowing a programmer to build applications that dynamically use this metadata, thus making the applications reusable from completely different sources. This makes building and managing these applications easier.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computational Linguistics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Computer And Data Communications (AREA)

Abstract

La présente invention concerne un procédé de traitement d'une requête. Le procédé de traitement de requêtes et de résultat entre un client et une pluralité de sources hétérogènes de données par un dispositif adaptateur (1) spécifique à chaque source, d'architecture donnée, réalise les étapes suivantes de façon indépendante: réception de la requête (71) émise par l'application client; établissement d'une représentation interne (73, 74) de la requête par l'adaptateur, utilisation de cette représentation interne de la requête pour réécrire la requête en un format compréhensible par la source, transmission de la requête traduite (75) à la source (7), production d'un objet filtre (52) et initialisation d'au moins une chaîne de filtres (46) constituée d'un ou plusieurs composants 'filtres' (45, 44, 43, 42); récupération par l'objet filtre (52) des résultats provenant de la source pour les transmettre et les faire filtrer à travers la chaîne (46) de composants 'filtres', production d'un objet réponse (22) pour transférer les résultats provenant du module de transformation du résultat à l'application client.

Description

Procédé de traitement d'une requête
La présente invention concerne un procédé de traitement d'une requête.
L'invention concerne plus particulièrement un procédé de transformation de requête et de résultats entre une application cliente et une pluralité de sources hétérogènes de données par un dispositif adaptateur d'architecture donnée, spécifique à chaque source de données, et l'architecture donnée d'adaptateur permettant la mise en œuvre dudit procédé.
De nombreuses informations de tous types existent dans les fichiers des entreprises ou du domaine public, par exemple. La plupart de ces informations ne peuvent pas être exploitées car elles se trouvent dans des bases de données multiples qui sont difficiles à intégrer ou dans de multiples fichiers de traitement de texte. Des solutions ont été apportées pour rendre les données brutes accessibles par des environnements Intranet ou Internet. Ces solutions ne résolvent pas les problèmes critiques se présentant aux gestionnaires de transfert de données. L'information est gardée dans un ensemble mélangé de systèmes, chaque système ayant ses propres protocoles d'accès et ses propres interfaces. Lorsqu'une information est demandée par un client sous forme d'une requête, seule une partie de l'information est généralement utile aux besoins de l'application client. Les données ne sont jamais dans la bonne forme. La plupart du temps un programme ad hoc doit être écrit pour transformer les données dans un format utilisable. De nombreuses informations utiles sont enfermées dans des fichiers privés, et l'extraction manuelle d'informations, même partiellement utilisables, nécessite beaucoup de temps. L'intégration de nouveaux serveurs ou de bases de données représente un travail laborieux et le résultat est généralement peu flexible et peu compréhensible. Les principaux problèmes sont d'accéder à l'information là où elle est, dans sa forme originale, de la transformer dans un format utilisable et de la délivrer aux applications qui en ont besoin. Le traitement de la requête d'un client s'effectue par un adaptateur. Un adaptateur spécifique est associé à chaque source de donnée.
La présente invention a donc pour objet de pallier les inconvénients de l'art antérieur en proposant un procédé de traitement d'une requête, commun à tous les adaptateurs. Le procédé selon l'invention procure une interface d'accès uniforme aux sources d'informations telles que les DBMSs relationnelles (DataBase Management System), les fichiers système, les bases de données "Lotus Notes", les systèmes de gestion de document et les serveurs "Web" (WorldWideWeb), par exemple. Le but de l'invention est de proposer un procédé qui permette d'extraire des informations en travaillant directement, par exemple, à partir d'un compte rendu, d'appels d'offre ou de documents similaires dans des formats hétérogènes tels que HTML (HyperText Markup Language) ou ASCII (Américain Standard Code for Information Interchange), pour obtenir un objet, une date de publication ou la place par exemple, d'un appel d'offre publié sur un serveur ayant un protocole déterminé tel que HTTP (HyperText Transmission Protocol). Le procédé proposé doit permettre de filtrer l'information pour sélectionner l'information utile, au lieu d'ajouter une autre fonction spécifique pour chaque application qui a besoin de l'information. Ce but est atteint par le fait que le procédé de traitement de requêtes et de résultat entre un client et une pluralité de sources hétérogènes de données par un dispositif adaptateur spécifique à chaque source, d'architecture donnée, réalise les étapes suivantes de façon indépendante :
- réception de la requête émise par l'application client, - établissement d'une représentation interne de la requête par l'adaptateur,
- utilisation de cette représentation interne de la requête pour réécrire la requête en un format compréhensible par la source,
- transmission de la requête traduite à la source, production d'un objet filtre et initialisation d'au moins une chaîne de filtres constituée d'un ou plusieurs composants "filtres", - récupération par l'objet filtre des résultats provenant de la source pour les transmettre et les faire filtrer à travers la chaîne de composants "filtres",
- production d'un objet réponse pour transférer les résultats provenant du module de transformation du résultat à l'application client. Selon une autre particularité, l'initialisation de chaîne de filtre s'effectue à partir de la représentation interne de la requête et de l'objet filtre.
Selon une autre particularité, l'objet réponse est produit à partir de la chaîne de filtres.
Selon une autre particularité, l'objet réponse est retourné à l'application client pour lui permettre de récupérer les résultats.
Selon une autre particularité, des métadonnées concernant le schéma des données dans la source, les opérateurs supportés par la source et les coûts associés à ces opérateurs, sont fournies à l'application client.
Un autre but de l'invention est de proposer un adaptateur d'architecture donné permettant la mise en oeuvre dudit procédé.
Ce but est atteint par le fait que l'adaptateur comprend quatre modules, un module de coordination servant d'interface avec l'application client comprenant un composant de connexion et un composant "réponse", un module de transformation de la requête, comprenant au moins un composant d'analyse, au moins un composant de traduction et un composant de construction de traitement, un module de communication avec la source comprenant un premier composant "source" et un second composant "Filtre d'accès source" et un module de transformation du résultat comprenant des troisièmes composants filtres possédant tous la même interface, chaque module comprend des composants possédant chacun une interface déterminée.
Selon une autre particularité, la même interface de programmation d'application (API), le même langage de requête et le même modèle de données sous forme de métadonnées de la source sont utilisés pour traiter chaque source.
Selon une autre particularité, le module de transformation du résultat est constitué d'un jeu de composants choisis parmi quatre sortes de troisièmes composants filtres, des composants "opérateurs" appliquant des contraintes supplémentaires à la réponse, des filtres d'extraction, des filtres de traduction de structure et des filtres de construction de la réponse transformant la réponse au format de donnée de l'application client. Selon une autre particularité, des composants d'analyse et/ou des composants de traduction sont empilés.
D'autres particularités et avantages de la présente invention apparaîtront plus clairement à la lecture de la description ci-après faite en référence au dessin annexé dans lequel la figure 1 représente l'architecture d'un adaptateur selon l'invention et le procédé de traitement d'une requête.
En référence à la figure 1 , les adaptateurs (1) sont basés sur la transformation de requêtes et de résultats entre une application (6) et une source (7) de données par un double procédé de réécriture de la requête et de transformation du résultat. Un adaptateur est associé à une source. L'adaptateur est chargé de donner une vue relationnelle de la source à laquelle il est attaché. Les requêtes provenant de l'application client (6) sont analysées, puis transformées en requêtes supportées par le gestionnaire de la source (7) de données, les paramètres de la requête sont extraits et utilisés pour guider la transformation du résultat. Les résultats sont transformés par des processus d'extraction d'information et de restructuration. Les adaptateurs peuvent être utilisés directement pour accéder à des sources de données à partir d'applications. L'application client (6) peut être une application quelconque ayant besoin d'accéder à une source de données sous une forme relationnelle structurée. L'architecture de l'adaptateur (1 ) selon l'invention peut se décomposer en quatre principaux modules : un module de coordination (2), un module de transformation (3) de la requête, un module de transformation du résultat (4) et un module de communication avec la source (5). Le module de coordination (2) sert d'interface avec l'application client (6). Le module de coordination (2) communique avec l'application client (6) en échangeant des requêtes et des réponses avec l'application client (6). Le module de transformation de la requête (3) est responsable de l'analyse de la requête reçue et de la traduction de celle-ci en opérations supportées par le gestionnaire de la source de données (7). Le module de transformation du résultat (4) est responsable de la restructuration des résultats, de la traduction des types de données de la source en des types de données de l'application client (6) d'une manière générale, et de l'élaboration de la réponse envoyée à l'application client (6). Les adaptateurs offrent des caractéristiques de requête et des modèles de données basés sur une technologie de base de données relationnelle afin de procurer un accès uniforme à différentes sources de données. Ce qui implique une traduction d'une requête de type base de données en une requête qui n'est pas de type base de données et la traduction de résultats non-structurés en des résultats structurés de manière relationnelle.
Le module de communication (5) avec la source est responsable de la communication avec la source (7) et encapsule des réponses dans des structures de données compatible avec la source dans des structures de données compatible avec l'adaptateur (1). Son rôle est d'une part, d'envoyer la requête à la source et d'autre part, de récupérer les résultats que la source (7) renvoie.
Chaque module est composé d'un jeu de composants. La fonctionnalité de chaque module et les différents composants utilisés pour les construire vont à présent être décrits. Les modules composant l'architecture peuvent être classés en trois différentes couches : la couche "Client" (8), la couche interne
(9) de l'adaptateur, et la couche "Source" (10). La différence entre ces trois couches est basée sur leur rôle. La couche "Client" (8) et la couche "Source"
(10) traitent avec les contenants, c'est-à-dire l'interface procurée à l'application client et la manipulation des interfaces des sources. La couche "Client" (8) comporte le module de coordination (2) et la couche "Source" comporte le module de communication (5) avec la source. La couche interne (9) de l'adaptateur traite avec le contenu, c'est-à-dire avec les requêtes reçues de l'application client et envoyées à la source (7), et les données reçues de la source et envoyées à l'application client. La couche interne (9) comporte le module de transformation (3) de la requête et le module de transformation du résultat (4). Dans un adaptateur donné, grâce à la structure homogène des interfaces quelque soit le langage utilisé par l'application ou par la source, il est possible de mettre plusieurs couches internes (9) l'une au-dessus de l'autre, chacune des couches étant adaptée à un langage différent, tout en ayant qu'une seule couche "Client" (8) et qu'une seule couche "Source" (10). Cet empilage est défini par un fichier de configuration de l'adaptateur.
L'application cliente en utilisant ce fichier de configuration détermine l'adaptateur utilisé.
La couche "Client" (8) regroupe les composants qui traitent avec l'application client au niveau de l'accès. Son rôle est de servir d'interface avec l'application client. Les composants de la couche client réalisent une interface utilisée par l'application client (6). Le module de coordination (2) de cette couche client a quatre principales responsabilités. Premièrement, un composant de connexion (21 ) accepte une requête (71) d'une application client et passe (72) la requête au module de transformation (3) de requête. Deuxièmement, un composant "Réponse" (22) permet de transférer le résultat, provenant du module de transformation (4) du résultat, à l'application client (6). Troisièmement, il délivre à l'application client des métadonnées, concernant le schéma des données dans la source, les opérateurs de la requête avec leurs coûts lorsque cela est requis. Les métadonnées sont des données sur la structure des données elle-même. Quatrièmement, il initialise dynamiquement et configure les autres composants de l'adaptateur.
La couche interne (9) de l'adaptateur regroupe les composants qui traitent de la transformation des données. Deux modules sont associés aux deux principales transformations effectuées qui sont le module de transformation de la requête (3) et le module de transformation des résultats (4). Les principales fonctions du module de transformation de la requête (3) sont d'une part, de réécrire la requête provenant du module de coordination en une requête qui peut être soumise à la source de données (7) et d'autre part, d'initialiser le module de transformation de résultats (4) qui traitera les résultats récupérés de la source (7). Ceci est effectué en trois phases. Premièrement, la requête entrante est analysée pour identifier les éléments utilisés, pendant l'élaboration d'une requête acceptée par la source et pendant la transformation des résultats. Ces éléments sont les noms de la relation, les attributs de la projection, et les prédicats de sélection ou de jointure. Cette étape, consistant à établir une représentation interne de la requête, est réalisée par un composant d'analyse (31). Deuxièmement, l'information constituée par ces éléments est utilisée dans un composant de traduction (32) qui réécrit la requête dans une forme pouvant être acceptée par le gestionnaire de la source de données (5). Troisièmement, l'information est utilisée par un composant "constructeur de traitement" (33) pour initialiser tous les filtres nécessaires. La requête soumise à la source de données fournit un ensemble de réponses qui est ensuite filtré pour produire une réponse correcte à l'application client. Le passage de cet ensemble de réponses à travers les filtres peut être requis pour étendre ou augmenter les capacités de traitement de la requête d'un gestionnaire de source de données. L'analyse de la requête, par le composant (33), permet d'initialiser des filtres en fonction des besoins de l'application client. Le module de transformation du résultat (4) est responsable de l'extraction des informations pertinentes dans les réponses obtenues par le module de communication avec la source (5). Ce module (4) est également chargé de l'accomplissement de transformation sur celles-ci, si c'est nécessaire, et ensuite du formatage de la réponse au format de données de l'application client (6). Ce module est constitué d'un empilement de composants (42 à 45) appelés filtres. Le passage à travers cette chaîne (46) de filtres correspond à de l'extraction de données, à de la vérification par rapport à la requête de départ et à des conversions. Les filtres du module de transformation des résultats (4) possèdent tous la même interface incluant des méthodes "open", "get-next", "close" et manipulent les données dans un même format interne. Ainsi, les filtres peuvent être enchaînés dans n'importe quel ordre en fonction des besoins en extraction, en vérification et en conversion. Il existe quatre classes de filtres. Les filtres dits "opérateurs" (42) appliquent à la réponse retournée par la source, des contraintes supplémentaires, correspondant à des opérateurs de sélection ou de projection par exemple. Des filtres dits d'extraction (43) réalisent une chaîne d'extraction d'information et de méthodes de structuration. Un filtre (44) de traduction de structure peut être utilisé pour récupérer le schéma des données. Ces trois types de composants peuvent être utilisés plusieurs fois dans la chaîne avec différentes initialisations pour réaliser des transformations qui se révèlent impossibles en n'utilisant qu'un seul filtre. Un filtre (45) de construction de la réponse termine la chaîne. Ce filtre transforme la réponse du format de données interne de l'adaptateur (1) au format de données de l'application client.
La couche "Source" (10) regroupe les composants, qui gèrent l'accès de la source (7), afin d'envoyer une requête à la source et de récupérer les résultats. Un premier composant "Source" (51) accepte les requêtes au format de la source de données provenant du composant de traduction de la requête (32). Un second composant "Filtre d'accès source" (52) récupère les résultats que la source renvoie suivant le protocole de la source, ces résultats étant sous la forme, dans le format et dans le codage utilisés par la source. Ce composant (52) transforme ces résultats pour les envoyer à la chaîne de filtres (46) au format interne de la couche interne (9) de l'adaptateur. Le module de coordination (5) avec la source (7) a deux fonctions. Il envoie une requête à la source de données, par exemple une requête SQL (Structured Query Language), ou HTTP. Il utilise l'interface "filtre" du module de transformation du résultat (4) pour retourner le prochain élément de la réponse de la source de données au format de données interne de l'adaptateur.
Une description du traitement par l'adaptateur de requêtes reçues des clients va à présent être effectuée en référence à la figure 1 sur laquelle les flèches continues à tête pleine représentent le chemin d'une requête, d'une représentation d'une requête ou d'une information particulière et les flèches à trait discontinu et à tête pleine représentent le flux de données et les flèches à trait discontinu et à tête creuse représentent les opérations de création d'un objet du procédé. Quand un client (6) a des requêtes à envoyer à un adaptateur (1), il ouvre une connexion vers l'adaptateur en utilisant une interface "Wapper" (annexel), et soumet les requêtes à l'adaptateur. Le composant de connexion (21) réceptionne la requête (71) et transmet la requête (72) par l'interface "Analyse" au module (3) de transformation de la requête. Dans une première phase, l'adaptateur utilise le composant d'analyse (31) de la requête faisant partie du module (3) de transformation de la requête pour établir une représentation interne (73, 74) de la requête qu'il transmet au composant de traduction (32) dans un format compatible avec l'interface "Request Builder". Cette représentation interne (73,74) est également compatible avec l'interface "Process Builder" du composant de traitement (33). Dans la seconde phase, la représentation (74) de la requête est utilisée par le composant de traduction de la requête (32) pour traduire la requête initiale (71) de l'application client dans un format compatible avec l'interface "Source" que la source peut comprendre. La requête traduite (75) est soumise à la source à travers un composant "Source" (51 ) de la couche source, et un objet filtre correspondant au composant "Filtre d'accès source" (52) est produit. Cet objet filtre (52) réalise l'interface "Filter" (représentée annexe 1 par les références 18 et 181 à 184) du module de transformation de résultat. Cet objet filtre (52) est le premier élément de la chaîne de filtres qui filtrera et permettra de récupérer les résultats provenant de la source par utilisation des méthodes "open" (182), "next" (183), "close" (184). Dans une troisième étape, l'adaptateur utilise un composant "constructeur de traitement" ou "initialisateur de filtre" (33), pour initialiser dans la chaîne de filtres, le ou les filtres nécessaires pour compléter le premier filtrage (52) afin de produire une réponse compatible avec le format de l'adaptateur. Pour initialiser ces filtres, l'adaptateur donne à ce constructeur de traitement (33) d'une part la représentation interne (73) de la requête par une fonction qui utilise comme paramètres les résultats de l'interface "Analyse" et d'autre part, par la flèche référencée (76), l'objet filtre (52) produit par le composant source (51. Ce constructeur de traitement (33) restitue une chaîne de filtres (46) constituée de différents composants filtres (42 à 45). La phase terminale est la construction d'un objet réponse, correspondant au composant "Réponse" (22). Cet objet réponse est produit par le composant de connexion (21) en utilisant la chaîne de filtres (46) que le constructeur de traitement (33) lui fournit par la liaison (77). Ensuite, le composant de connexion (21) donne à l'application client (6) l'objet réponse. L'application client utilise l'interface "Answer" (12) de ce composant (22), comportant des méthodes "open", "next", "close", pour récupérer les résultats dans le format de données particulier de l'interface.
Une description des interfaces utilisées entre les différentes couches et les différents modules va à présent être effectuée. Ces interfaces font partie de la définition d'une architecture commune pour tous les adaptateurs. Les interfaces des différents composants sont communes à tous les adaptateurs.
Les interfaces suivantes figurant en annexe 1 et 2 permettent de soumettre une requête, de récupérer des résultats et de gérer un adaptateur en fonctionnement. La notation utilisée pour les interfaces est la suivante "vector getSelectClause( ), dans laquelle le contenu entre parenthèse exprime les paramètres utilisés par la fonction "getSelectClause" et "vector" exprime la forme du résultat fourni par la fonction utilisée par l'interface. Ce résultat peut être sous forme de chaîne (string), de booléen (boolean), de vecteur (vector) ou d'un objet (object). La couche "Client" définit les interfaces et les composants permettant d'utiliser un adaptateur. Les interfaces de la couche "Client" (8) permettent d'utiliser un adaptateur localement ou à distance. La couche "Client" (8) comprend deux interfaces spécifiques, une première interface à la fois de connexion (11 , annexe 1), appelée "Wrapper" et d'aministration d'adaptateur (13, annexe 1) , réalisée par le composant de connexion (21), et une seconde interface (12) "Answer" réalisée par le composant "réponse" (22). La première interface "Wrapper" procure à l'application client un accès aux services de base d'un adaptateur (1). Cette interface comprend une première méthode "requête" (query) (111) qui utilise un objet comme argument d'entrée. Cette méthode "requête" (query) permet de recevoir la requête de l'application client en utilisant comme argument d'entrée un objet représentant la requête émise par l'application client. Cette méthode "requête" (query) permet également de retourner (78) à l'application client l'objet réponse (22) qui fournit un certain nombre de fonctions définies dans l'interface "Answer (12). Une seconde méthode (GetCapability) (112) de la première interface "Wrapper" ne prend en compte aucun argument d'entrée. Cette seconde méthode retourne une chaîne de caractères (string) encodant la liste des opérateurs de requête supportés par l'adaptateur et leurs conditions d'usage représentant les capacités de l'adaptateur. La chaîne de caractères décrit les opérateurs que l'adaptateur supporte et la façon dont ils peuvent être combinés. Les opérateurs utilisables sont des opérateurs d'exploration, de sélection, de projection, d'union et de combinaison. Chaque adaptateur supporte un sous-ensemble de ces opérateurs. En utilisant cette fonction (GetCapability) (112), l'application client sait quels sont les opérateurs de requête supportés par chacun des adaptateurs utilisés par l'application client et peut ainsi optimiser sa requête. Une troisième méthode (getSchema) (113) de la première interface "Wrapper" ne prend en compte aucun argument d'entrée et retourne une chaine de caractères constituant une liste de types. Chaque type décrit la représentation interne d'une classe du schéma des données sur la source. Les types sont construits en utilisant d'une part, des types de base tels que entier, réel, booléen, chaîne et d'autre part, des constructeurs pour ensembles et uplets ou "tuples". Un tuple est une liste de paires (attribut-valeur). Les types sont définis au moment de la création de l'adaptateur. Cette troisième méthode est utilisée pour transmettre à l'application client la structure des données dans la source et permettre ainsi à l'application client de récupérer les résultats. Une quatrième méthode (getCost) (114) de la première interface "Wrapper" (11) ne prend pas en compte d'argument et retourne une chaîne encodant les informations de coût associées à chaque opérateur. Les informations de coût permettent d'évaluer le temps et la taille mémoire du résultat d'une requête. L'application client maintient un modèle de coût afin de sélectionner le meilleur plan d'exécution, c'est-à-dire la meilleure chaîne de filtres. Un modèle de coût par défaut est défini sur l'application client. Afin d'améliorer ce modèle, les coûts sont transmis des adaptateurs à l'application client en utilisant la fonction de la quatrième méthode (getcost) (114).
La seconde interface "Answer" (12, annexe 1) procure à l'application client (6) les services pour récupérer les résultats de la requête soumise. Cette interface comprend différentes méthodes. Une première méthode (getAII) (121) de la seconde interface "Answer" ne prend aucune entrée et retourne un ensemble de "tuples", liste de paires (attribut-valeur). Cette fonction retourne un ensemble de tous les tuples retournés par la source et filtrés par l'adaptateur. La deuxième méthode (open) (122) de la seconde interface "Answer" ne prend aucune entrée et ne produit aucune sortie. Elle exécute la procédure d'initialisation nécessaire avant que le premier "tuple" puisse être envoyé à l'application client. Une troisième méthode (getNext) (123) de la seconde interface "Answer" ne prend en compte aucun argument et retourne un objet "Tuple". Cet objet fixe un "tuple" qui est une partie de la réponse aux sous- requêtes passée à l'objet réponse du composant "Réponse" (22). S'il n'y a pas d'autres tuples dans la réponse, il retourne un "nul". Une quatrième méthode (close) (124) de la seconde interface "Answer" ne prend aucun argument. Elle exécute des opérations de nettoyage. Elle ne fait rien si elle est appelée avant un appel d'ouverture. Cette fonction peut être appelée avant la récupération du dernier "tuple". Quand un appel d'ouverture par la première méthode (open) apparaît après un appel de fermeture de la quatrième méthode (close), la troisième méthode (getnext) retourne un "nul", même si la fermeture a été exécutée avant la fin de l'ensemble de réponse.
La couche "Client" (8) comprend une troisième interface "AdaptaterAdmin" (13, annexe 1) permettant d'initialiser et de configurer les composants de l'adaptateur en fonction des paramètres d'accès de la source. Cette troisième interface procure des services d'administration permettant de gérer un adaptateur pendant ou après l'initialisation.
Les différentes interfaces de la couche "Client" décrites précédemment peuvent être remplacées par une interface JDBC (Java DataBase Connectivity). Le "Java" est un nouveau language de programmation, conçu par la société "Sun", basé sur le C++. JDBC constitue un utilitaire pour la connexion de "Java" aux bases de données. Cette quatrième interface JDBC (14, annexe 1) est une interface d'accès aux bases de données SQL standard, procurant un accès uniforme à une large gamme de base de données. La requête étant un objet, cette interface JDBC (14) peut être utilisée avec tout type de base de données à condition qu'il existe un composant de traduction sous-jacent. Un gestionnaire JDBC a besoin de manipuler des requêtes SQL, ce qui ne peut pas être assuré au niveau de l'interface. Si le choix du programmeur d'adaptateur pour le composant d'analyse (31) dans le module de transformation de la requête (3) est un analyseur grammatical SQL, l'adaptateur sera totalement conforme à JDBC. Bien que les interfaces ne soient pas les mêmes, des caractéristiques trouvées dans les interfaces (11 , 12, 13) de la couche "Client" décrites précédemment peuvent être trouvées dans la quatrième interface JDBC. Les différentes interfaces de JDBC citées ci- après, "java. sql. Driver", "java. sql. Connection" "java.sql.ResultSet" et "java.sql.DatabaseMetadata" font partie de la norme JDBC. La réalisation de l'interface "java. sql. Driver" (141 ) remplace la troisième interface (AdaptaterAdmin) décrite précédemment. La configuration doit être effectuée avant la connexion de la base de données. La réalisation de l'interface "java. sql. Connection" (142) joue le même rôle que la réalisation de l'interface "Wrapper" pour la récupération de métadonnées et la soumission de la requête. La réalisation de "java.sql.ResultSet" (143) joue le même rôle que la réalisation de l'interface "Answer" (12) pour récupérer des résultats. Les méthodes pour récupérer les capacités de l'adaptateur et les informations de coût correspondent à des méthodes de l'interface "java.sql.DatabaseMetadata".
Le module de transformation de la requête (9) doit contenir trois éléments pour chaque adaptateur : un composant d'analyse (31), un composant de traduction (32) de requête et un composant de construction de traitement (33) qui peuvent être chacun empilables. Ainsi pour un autre langage client l'adaptateur utilisera un autre composant d'analyse (31'), un autre composant de traduction (32') de requête et autre composant de construction de traitement (33'), chacun étant adapté à cet autre langage, mais utilise pour un composant donné les mêmes méthodes constitutives des interfaces. Chacun a sa propre interface utilisée par le module de coordination (2) pour finalement générer un plan d'exécution, c'est-à-dire la chaîne de filtres (46), est définie par les composants "ProcessBuilder" à partir du fichier de configuration et des informations extraites de la requête par le composant analyse pour une requête reçue. Une première interface "Analyse" (15) contient les méthodes qu'un analyseur de requête (31) doit réaliser. La requête est considérée comme quelque chose de similaire à des requêtes SQL. La requête est donnée à l'analyseur (31) au moment de la création ou avec une première méthode "setRequest" (151). Le format de la requête est dépendant de l'interface réalisée. L'analyseur doit extraire différents éléments de la requête et utilise les différentes méthodes ci-après.
Une deuxième méthode "getSelectClause" (152) retourne une liste (nom, alias), de type chaîne, des attributs projetés ("selectclause"). Une troisième méthode "getFromClause" (153) retourne une liste (nom, alias) de type chaîne des relations ("from clause"). Une quatrième méthode "getWhereClause" (154) retourne un prédicat décrivant la condition de sélection ("where clause"). Le format du prédicat est dépendant de l'implémentation. Une cinquième méthode "getGroupByClause" (155) retourne une liste (nom, alias), de type chaîne, des attributs (groupby clause). Une sixième méthode "getHavingClause" (156) retourne un prédicat utilisant l'ensemble des opérateurs permettant de sélectionner les groupes (having clause). Le format du prédicat est dépendant de l'implémentation. L'analyse de la requête peut être effectuée en phases en empilant différents analyseurs. Un empilement (31 , 31',...) de composants d'analyse peut être nécessaire pour résoudre des problèmes de conversion par exemple.
Une deuxième interface "Request Builder" (16) contient les méthodes qu'un composant traduction de requête (32) doit réaliser. La requête entrante est définie comme la sortie de l'analyseur précédemment décrit ("sélect clause", "from clause", "where clause", "groupby clause" and "having clause"). La requête est donnée au composant de traduction au moment de la création ou avec la méthode "setRequest" (161). Cette méthode retourne la valeur "vrai" si tout se passe bien, "faux" sinon. Le format de la requête traduite dépend du type de format que la source peut accepter. Une autre méthode "getTranslatedQuery" (162) retourne la traduction de la requête précédemment donnée. De la même façon que les composants d'analyse, différents composants de traduction (32, 32',...) peuvent être empilés.
Une troisième interface "Process builder" (17) contient les signatures de la méthode qu'un constructeur de traitement (33) doit réaliser. Le constructeur de traitement (33) a besoin de produire le plan d'exécution. Le constructeur de traitement fournit la chaîne (46) de filtres, qui constitue le composant principal du plan d'exécution correspondant à la requête donnée. Une première méthode (171) permet de donner au constructeur de traitement (33) les informations nécessaires, extraites par le composant analyse (31), pour générer le plan d'exécution. Une deuxième méthode (172) permet de donner au constructeur de traitement (33) le premier élément filtre du plan d'exécution. Ce premier élément est l'objet filtre correspondant au composant "Filtre d'accès source" (52), fourni par le composant source (51) après la soumission de la requête traduite, et permettant de récupérer les résultats de la source. Une troisième méthode (173) retourne au composant de connexion (21) le plan d'exécution (77), c'est-à-dire la chaîne (46) de filtres calculée pour la requête.
Le module de transformation du résultat (4) contient des interfaces et des classes permettant de construire une chaîne de filtres qui traite les données venant de la source avant de les envoyer à l'application client. Les interfaces et les classes suivantes sont utilisées par chaque composant de ce module afin de réduire la dépendance des composants et de favoriser la réutilisation de ces composants. Chaque composant filtre (42 à 45) doit réaliser une interface "Filtre" (18). Cette interface permet de composer une chaîne de filtre (46) en insérant tout composant filtre à toute position. Une première méthode "initialize" (181) initialise le filtre avec la liste donnée des paramètres contenus dans une table à accès direct (hashtable). Une deuxième méthode "open" (182) ouvre le flot de données délivrées par la chaîne. Une troisième méthode "next" (183) retourne un objet de la classe "DataFormat" représentant un tuple. Cette méthode permet de prendre l'un après l'autre les tuples d'une même requête. Une quatrième méthode "close" (184) ferme le flot de données délivré par la chaîne.
Une classe "DataFormat" (60) définit la structure de traitement des données communes dans l'adaptateur. Dans le cas des filtres, elle correspond à une liste de paires attribut-valeur ou "tuples" qui est transmise d'un filtre de la chaîne au filtre suivant. Un ensemble de méthodes (61), données à titre d'exemple dans l'annexe 2 permet de manipuler un tuple contenant des données semi-structurées définies par la classe "DataFormat". Le module de transformation du résultat peut comprendre des interfaces supplémentaires pour permettre, par exemple, d'effectuer des traitements en parallèle.
Les composants de la couche source (10) doivent réaliser une interface "Source" (62, annexe 2) afin d'être utilisés par le composant de connexion (21) du module de coordination pour récupérer les informations sous forme de métadonnées et pour envoyer la requête à la source. Cette interface comprend une première méthode "checkMetadata" (621) qui vérifie la disponibilité des métadonnées. Cette interface comprend une deuxième méthode "getMetaData" (622) récupère les métadonnées délivrées par la source et les traduit en quelque chose de compréhensible par la couche client supérieure. Une troisième méthode "sendQuery" (623) reçoit une requête compréhensible par la source, produit et retourne (76) au constructeur de traitement (33) un objet filtre (52) afin de récupérer les résultats. Si le composant source (51) est configurable pendant la durée d'exploitation, il doit réaliser une autre interface (63), appelée interface "Admin". Cette interface comprend une première méthode "setConfig" (631) pour donner le paramètre de configuration au composant source. Le programmeur de composant source doit fournir le format et la forme de ce ou ces paramètres. L'interface utilise une deuxième méthode "getConfig" (632) pour récupérer les paramètres de configuration disponibles dans l'adaptateur.
Les adaptateurs selon l'invention présentent de nombreux avantages. Ils proposent une interface d'accès uniforme aux sources hétérogènes d'information, chaque interface reposant sur un nombre minimum de méthodes soigneusement sélectionnées. La même interface de programmation d'application (API), le même langage de requête et le même modèle de données sont utilisés pour traiter chaque source, même si ces sources sont totalement différentes au niveau du protocole d'accès, du langage de la requête et du modèle de données. Seuls les objets auxquels s'appliquent les méthodes sont modifiés en fonction des langages source et des langages des applications client. La définition d'une architecture générique avec des interfaces communes pour les composants inclus dans les modules de l'adaptateur permet de réaliser des composants, par exemple, de connexion (21 ), analyseur (31 ), traducteur (32), filtre (42 à 45), de traitement (33) de source (5), réutilisables. Ces composants peuvent être réutilisés dans plusieurs adaptateurs sans modifications. La composition des composants réutilisables dans des chaînes de composants permet aux programmeurs de réaliser facilement des adaptateurs. L'évolution des sources de données et l'évolution des composants peut être facilement supportée en branchant des composants dans des chaînes de composants déjà existantes dans l'adaptateur ou en remplaçant un composant par un autre. La création rapide d'adaptateurs robustes s'appuie sur ces composants réutilisables. L'architecture commune selon l'invention peut être utilisée avec des bibliothèques de composants réutilisables pour créer des familles d'adaptateur caractérisées par un gestionnaire de données commun, par exemple "Lotus Notes", ou pour créer des adaptateurs spécialisés fabriqués pour une source de données spécifique. Trois types de composants peuvent être distingués en fonction de leur dépendance au gestionnaire de donnée de la source associée. Cette dépendance dicte la manière dont les composants peuvent être réutilisés d'un adaptateur à l'autre. Certains composants sont spécifiques à un adaptateur et ne peuvent pas être réutilisés. Par exemple, la construction de requête pour un moteur de recherche WWW (World Wide Web) dépend du langage que cette source particulière accepte. Certains composants sont communs à une famille d'adaptateur. Par exemple, le module de communication HTTP peut être réutilisé pour tous les adaptateurs associés à une source de données basée sur un site Web. Certains composants sont communs à tous les adaptateurs. Par exemple, les filtres de projection et de sélection appliqués sur les données obtenues à partir de la source ne dépendent pas de la source, et peuvent être potentiellement réutilisés pour construire chaque adaptateur. Le procédé selon l'invention permet de fournir des "métadonnées" à l'application client pour optimiser les requêtes et permettre une meilleure utilisation de la source. L'adaptateur procure des métadonnées sur la source de données, ce qui permet à un programmeur de construire des applications utilisant dynamiquement ces métadonnées, rendant ainsi les applications réutilisables avec des sources totalement différentes. La construction et la gestion de ces applications sont ainsi plus faciles.
Il est clair que d'autres modifications à la portée de l'homme du métier entrent dans le cadre de l'invention.
ANNEXE 1 interface "Wrapper" xλ χ -Answer query (object request) m -String getCapabιlιty() j 12 -String getSchema() -String getCost()^^
interface "AdapterAdmin"
" 15 interface "Analyse"
-boolean setReques (θ ject query) 151
-Vector getSelectClauseQ 152 -^
-Vector getFromClause() 153
-Object getWhereClause() | 54
-Vector getGroupByClausèζA" 155
-Object getHavingClauseQ 156 interface "Request Buιlder"~ 16
-boolean setRequest(Vector seiectClause, Vector fromClause, Object whereClause, Vector groupbyClause, Object havingCIâTϋe -Object getTranslatedQueryO 161
162
17 interface "Process Builder - setRequest(Vector seiectClause, Vector fromClause, Object whereClause, Vector groupbyClause, Object havιngClause"T~"" -void setSourceFιlter(Fιlter source 171 -Filter getProcessQ 173 — 172 interface "Filter" J8 ^~-
-ιnιtιalιze(Hashtable params, Filter previous)
181
- open() -— 182
-DataFormat next() ] 83
-close() ι ;1 ANNEXE 2
60 61 classe "DataFormaP-"'"
- setAtt(Stπng name, Object value) "donne la valeur du nom de l'attribut donné"
- removeAtt(Stπng name) "enlève l'attribut donné par son nom"
-String getAttName(ιnt index) "retourne le nom de l'attribut correspondant à l'index" -mt getAttlndex(Strιng name) "retourne l'index de l'attribut correspondant au nom" -Object getAttValue(ιnt index) "retourne la valeur de l'attribut correspondant à l'index" -Object getAttValue(Strιng name) "retourne la valeur de l'attribut avec le nom donné" -boolean ιsAttrιbute(Stπng attrName) "pour savoir si un attribut est déjà défini" -mt getNumAtt() "retourne le nombre des attributs dans le tuple"
- appendsLast(DataFormat toAdd) "ajoute le Dataformat donné à l'objet présent" -DataFormat getCopy() "retourne un clone de cet objet"
-String toStπng() "retourne une représentation de type chaîne, de l'objet" interface "Source" 21
-boolean checkMe1adata0 ____ 522 -DataFormat getMetaDataT '' , -Filter sendQuery(Object qirëry) interface "Admin"
631 setConfιg(Hashtabie-parameters)
Hashtable getConfιg()
632

Claims

REVENDICATIONS
1. Procédé de traitement de requêtes et de résultat entre un ou une pluralité de client pouvant utiliser chacun un langage différent et une pluralité de sources hétérogènes de données par un dispositif adaptateur (1) spécifique à chaque source, d'architecture donnée, caractérisé en ce qu'il réalise les étapes suivantes de façon indépendante :
- réception de la requête (71) émise par l'application dans le format compréhensible par le client, - établissement par l'adaptateur d'une représentation interne (73, 74) de la requête au format de l'adaptateur,
- utilisation de cette représentation interne de la requête par un composant de traduction du format interne dans le format source pour réécrire la requête en un format compréhensible par la source, - transmission de la requête traduite (75) à la source (7), production d'un objet filtre (52) et utilisation de la représentation interne par un composant constructeur de traitement (33) pour initialiser au moins une chaîne de filtres (46) constituée d'un ou plusieurs composants "filtres" (45, 44, 43, 42), ), en initialisant dans la chaîne de filtres, le ou les composants "filtres" nécessaires pour compléter le premier filtrage résultant de l'objet filtre (52) afin de produire une réponse compatible avec le format de l'adaptateur
- récupération par l'objet filtre (52) des résultats provenant de la source pour les transmettre et les faire filtrer à travers les composants "filtres" initialisés de la chaîne (46) - production d'un objet réponse (22) pour transférer les résultats provenant du module de transformation du résultat à l'application client.
2. Procédé de traitement selon la revendication 1 , caractérisé en ce que pour l'établissement de la représentation interne une pluralité de composants d'analyse et/ou de composants de traduction sont empilés.
3. Procédé de traitement selon la revendication 1 ou 2, caractérisé en ce que l'initialisation de chaîne de filtre s'effectue à partir de la représentation interne de la requête et de l'objet filtre (52).
4. Procédé de traitement selon la revendication 1 ou 2 ou 3, caractérisé en ce que l'objet réponse (22) est produit à partir des composants filtres (46) initialisés de la chaîne.
5. Procédé selon l'une des revendications précédentes, caractérisé en ce que l'objet réponse (22) est retourné à l'application client (6) pour lui permettre de récupérer les résultats.
6. Procédé de traitement selon l'une des revendications précédentes, caractérisé en ce que des métadonnées concernant le schéma des données dans la source, les opérateurs supportés par la source et les coûts associés à ces opérateurs, sont fournies à l'application client.
7. Architecture donnée d'adaptateur permettant la mise en œuvre du procédé selon la revendication 1 , caractérisée en ce que l'adaptateur comprend quatre modules, un module de coordination (2) servant d'interface avec l'application client (6) comprenant un composant de connexion (21) et un composant "réponse" (22), un module de transformation de la requête, comprenant au moins un composant d'analyse (31), au moins un composant de traduction (32) et un composant de construction de traitement (33), un module de communication (5) avec la source comprenant un composant "source" (51) et un composant "Filtre d'accès source" (52) et un module de transformation du résultat (4) comprenant des composants "filtres" (42, 43, 44, 45) possédant tous la même interface, chaque module comprend des composants possédant chacun une interface déterminée.
8. Architecture donnée d'adaptateur selon la revendication 7, caractérisée en ce que la même interface de programmation d'application (API), le même langage de requête et le même modèle de données sous forme de métadonnées de la source sont utilisés pour traiter chaque source.
9. Architecture donnée d'adaptateur selon la revendication 7 ou 8, caractérisé en ce que le module de transformation du résultat est constitué d'un jeu de composants choisis parmi quatre sortes de composants filtres, des composants "opérateurs" (42) appliquant des contraintes supplémentaires à la réponse, des filtres d'extraction (43) réalisent une chaîne d'extraction d'information et de méthodes de structuration, des filtres de traduction de structure (44) pour récupérer le schéma de données et des filtres de construction de la réponse (45) transformant la réponse au format de donnée de l'application client.
10 Architecture donnée d'adaptateur selon la revendication 7, caractérisé en ce que des composants d'analyse et/ou des composants de traduction sont empilés.
11 Architecture donnée d'adaptateur selon l'une des revendications 7 à 8, caractérisé en ce qu'elle comporte des moyens d'analyse de la requête entrante pour identifier les éléments utilisés que sont les noms de la relation, les attributs de la projection et les prédicats de sélection ou de jointure
12. Architecture donnée d'adaptateur selon la revendication 7, caractérisé en ce que les filtres du module de transformation des résultats (4) possèdent tous la même interface incluant les méthodes "open", "get-next", "close" et manipulent les données dans un même format interne, les filtres étant enchaînés dans n'importe quel ordre en fonction des besoins en extraction, en vérification et en conversion
13. Architecture donnée d'adaptateur selon la revendication 9, caractérisé en ce que les trois premiers types de composants peuvent être utilisés plusieurs fois dans la chaîne avec différentes initialisations pour réaliser des transformations qui se révèlent impossibles en utilisant qu'un seul filtre.
14. Architecture donnée d'adaptateur selon la revendication 7, caractérisé en ce que les interfaces avec l'application "Client" permettent d'utiliser un adaptateur localement ou à distance
15. Architecture donnée d'adaptateur selon la revendication 9, caractérisé en ce que chaque adaptateur supporte un sous-ensemble de ces opérateurs utilisables choisi parmi les opérateurs d'exploration, de sélection, de projection, d'union et de combinaison.
16. Architecture donnée d'adaptateur selon la revendication 7, caractérisé en ce qu'une méthode est utilisée pour transmettre à l'application client la structure des données dans la source et permettre ainsi à l'application client de récupérer les résultats.
17 Architecture donnée d'adaptateur selon la revendication 7 ou 8, caractérisé en ce que le composant de connexion (21) utilise une interface constituée d'une première méthode "query" de réception, une deuxième méthode "getCapability" d'encodage de la liste des opérateurs de requête supportés par l'adaptateur, une troisième méthode "getSchema" de représentation interne d'une classe du schéma des données sur la source, une quatrième méthode "getCost" encodant les informations de coût associées à chaque opérateur permettant d'évaluer le temps et la taille mémoire du résultat d'une requête, les deuxième, troisième et quatrième méthodes présentant les informations sous forme de chaîne.
18. Architecture donnée d'adaptateur selon l'une des revendications 7 à 8, caractérisé en ce que l'analyseur extrait par une première méthode "setRequest, différents éléments de la requête et utilise les différentes méthodes ci-après, une deuxième méthode "getSelectClause" (152) qui retourne une liste (nom, alias), de type chaîne, des attributs projetés ("selectclause"), une troisième méthode "getFromClause" (153) qui retourne une liste (nom, alias) de type chaîne des relations ("from clause"), une quatrième méthode "getWhereClause" (154) qui retourne un prédicat décrivant la condition de sélection ("where clause"), une cinquième méthode "getGroupByClause" (155) qui retourne une liste (nom, alias), de type chaîne, des attributs (groupby clause), une sixième méthode "getHavingClause" (156) qui retourne un prédicat utilisant l'ensemble des opérateurs permettant de sélectionner les groupes (having clause).
19. Architecture donnée d'adaptateur selon la revendication 18, caractérisé en ce que le format du prédicat est dépendant de l'implémentation
EP99964723A 1998-12-28 1999-12-27 Procede de traitement d'une requete Ceased EP1057128A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR9816780A FR2787957B1 (fr) 1998-12-28 1998-12-28 Procede de traitement d'une requete
FR9816780 1998-12-28
PCT/FR1999/003294 WO2000039709A1 (fr) 1998-12-28 1999-12-27 Procede de traitement d'une requete

Publications (1)

Publication Number Publication Date
EP1057128A1 true EP1057128A1 (fr) 2000-12-06

Family

ID=9534805

Family Applications (1)

Application Number Title Priority Date Filing Date
EP99964723A Ceased EP1057128A1 (fr) 1998-12-28 1999-12-27 Procede de traitement d'une requete

Country Status (6)

Country Link
US (1) US6704726B1 (fr)
EP (1) EP1057128A1 (fr)
JP (1) JP2002533842A (fr)
CA (1) CA2320891A1 (fr)
FR (1) FR2787957B1 (fr)
WO (1) WO2000039709A1 (fr)

Families Citing this family (62)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1074925B8 (fr) * 1999-08-06 2011-09-14 Ricoh Company, Ltd. Système de gestion de documents, dispositif de traitement d'informations, procédé de gestion de documents et médium d'enregistrement lisible par ordinateur
US7185016B1 (en) * 2000-09-01 2007-02-27 Cognos Incorporated Methods and transformations for transforming metadata model
US7231433B1 (en) * 2000-01-19 2007-06-12 Reynolds And Reynolds Holdings, Inc. Enterlink for providing a federated business to business system that interconnects applications of multiple companies
US6988109B2 (en) 2000-12-06 2006-01-17 Io Informatics, Inc. System, method, software architecture, and business model for an intelligent object based information technology platform
US20100223295A1 (en) * 2000-12-06 2010-09-02 Io Informatics, Inc. Applied Semantic Knowledgebases and Applications Thereof
AU2002230765A1 (en) * 2000-12-06 2002-07-16 Biosentients, Inc. System, method, software architecture and business model for an intelligent object based information technology platform
FR2823044B1 (fr) * 2001-03-30 2004-05-21 France Telecom Dispositif et procede d'echange de flux entre un dispositif client et un serveur bases sur un protocole d'adapatation de contenu de fichiers internet de type icap
EP1271342A1 (fr) * 2001-04-30 2003-01-02 Sun Microsystems, Inc. Méthode pour accéder aux colonnes d'une table d'une base de données
US7099871B2 (en) * 2001-05-04 2006-08-29 Sun Microsystems, Inc. System and method for distributed real-time search
US7171415B2 (en) * 2001-05-04 2007-01-30 Sun Microsystems, Inc. Distributed information discovery through searching selected registered information providers
US7013303B2 (en) * 2001-05-04 2006-03-14 Sun Microsystems, Inc. System and method for multiple data sources to plug into a standardized interface for distributed deep search
US6961723B2 (en) * 2001-05-04 2005-11-01 Sun Microsystems, Inc. System and method for determining relevancy of query responses in a distributed network search mechanism
US6934702B2 (en) * 2001-05-04 2005-08-23 Sun Microsystems, Inc. Method and system of routing messages in a distributed search network
US6950821B2 (en) * 2001-05-04 2005-09-27 Sun Microsystems, Inc. System and method for resolving distributed network search queries to information providers
US7464072B1 (en) 2001-06-18 2008-12-09 Siebel Systems, Inc. Method, apparatus, and system for searching based on search visibility rules
US20030046276A1 (en) * 2001-09-06 2003-03-06 International Business Machines Corporation System and method for modular data search with database text extenders
WO2003065251A1 (fr) * 2002-01-29 2003-08-07 Children's Hospital Boston Echange d'informations entre bases de donnees heterogenes via une identification automatisee d'equivalences de concepts
US7228306B1 (en) * 2002-12-31 2007-06-05 Emc Corporation Population of discovery data
EP1482418A1 (fr) * 2003-05-28 2004-12-01 Sap Ag Procédé et système de traitement de données
US8694532B2 (en) * 2004-09-17 2014-04-08 First American Data Co., Llc Method and system for query transformation for managing information from multiple datasets
US8510325B1 (en) 2004-12-30 2013-08-13 Google Inc. Supplementing search results with information of interest
US7769579B2 (en) * 2005-05-31 2010-08-03 Google Inc. Learning facts from semi-structured text
US8468445B2 (en) 2005-03-30 2013-06-18 The Trustees Of Columbia University In The City Of New York Systems and methods for content extraction
US9208229B2 (en) * 2005-03-31 2015-12-08 Google Inc. Anchor text summarization for corroboration
US7587387B2 (en) 2005-03-31 2009-09-08 Google Inc. User interface for facts query engine with snippets from information sources that include query terms and answer terms
US8682913B1 (en) 2005-03-31 2014-03-25 Google Inc. Corroborating facts extracted from multiple sources
US7831545B1 (en) * 2005-05-31 2010-11-09 Google Inc. Identifying the unifying subject of a set of facts
US8996470B1 (en) 2005-05-31 2015-03-31 Google Inc. System for ensuring the internal consistency of a fact repository
US7827562B1 (en) 2005-06-16 2010-11-02 The Trizetto Group, Inc. System and method for flexible publishing and consumption of data between disparate applications
US8260785B2 (en) 2006-02-17 2012-09-04 Google Inc. Automatic object reference identification and linking in a browseable fact repository
US7464084B2 (en) * 2006-01-30 2008-12-09 International Business Machines Corporation Method for performing an inexact query transformation in a heterogeneous environment
WO2007115254A2 (fr) * 2006-03-31 2007-10-11 Visto Corporation Système et procédé de recherche de mémoires de données par l'intermédiaire d'un dispositif éloigné
US8122026B1 (en) 2006-10-20 2012-02-21 Google Inc. Finding and disambiguating references to entities on web pages
US20080114752A1 (en) * 2006-11-14 2008-05-15 Microsoft Corporation Querying across disparate schemas
US8347202B1 (en) 2007-03-14 2013-01-01 Google Inc. Determining geographic locations for place names in a fact repository
US7970766B1 (en) 2007-07-23 2011-06-28 Google Inc. Entity type assignment
US8832076B2 (en) * 2007-10-19 2014-09-09 Oracle International Corporation Search server architecture using a search engine adapter
US8812435B1 (en) 2007-11-16 2014-08-19 Google Inc. Learning objects and facts from documents
US8266112B1 (en) * 2007-12-19 2012-09-11 Symantec Corporation Techniques for recovery of application level objects
US8606803B2 (en) * 2008-04-01 2013-12-10 Microsoft Corporation Translating a relational query to a multidimensional query
US8745076B2 (en) * 2009-01-13 2014-06-03 Red Hat, Inc. Structured query language syntax rewriting
US10156954B2 (en) * 2010-01-29 2018-12-18 Oracle International Corporation Collapsible search results
US9009135B2 (en) * 2010-01-29 2015-04-14 Oracle International Corporation Method and apparatus for satisfying a search request using multiple search engines
US20110191333A1 (en) * 2010-01-29 2011-08-04 Oracle International Corporation Subsequent Search Results
US8271435B2 (en) * 2010-01-29 2012-09-18 Oracle International Corporation Predictive categorization
US10120913B1 (en) * 2011-08-30 2018-11-06 Intalere, Inc. Method and apparatus for remotely managed data extraction
US9159052B2 (en) * 2012-05-09 2015-10-13 Sap Se Generalizing formats of business data queries and results
EP2728494A1 (fr) * 2012-11-05 2014-05-07 Software AG Système et procédé pour créer graphiquement des requêtes sur des données de modèle
US9454585B2 (en) * 2013-08-09 2016-09-27 Openlane, Inc. Searching multiple data sources
US10114861B2 (en) * 2014-01-31 2018-10-30 Dell Products L.P. Expandable ad hoc domain specific query for system management
US9619537B2 (en) 2014-04-15 2017-04-11 Sap Se Converting data objects from single- to multi-source database environment
US9971794B2 (en) * 2014-07-08 2018-05-15 Sap Se Converting data objects from multi- to single-source database environment
US20170068712A1 (en) * 2015-09-04 2017-03-09 Palantir Technologies Inc. Systems and methods for database investigation tool
CN106227824A (zh) * 2016-07-25 2016-12-14 四川通发电信股份有限公司 基于零散数据的聚合式推送查询系统
CN106448157A (zh) * 2016-09-05 2017-02-22 天津中兴智联科技有限公司 一种交通数据平台适配器的实现方法及系统
US20190065547A1 (en) * 2017-08-30 2019-02-28 Ca, Inc. Transactional multi-domain query integration
CN110399474B (zh) * 2019-07-18 2023-06-09 腾讯科技（深圳）有限公司 一种智能对话方法、装置、设备及存储介质
US11256709B2 (en) 2019-08-15 2022-02-22 Clinicomp International, Inc. Method and system for adapting programs for interoperability and adapters therefor
CN111078961B (zh) * 2019-12-24 2023-09-15 用友网络科技股份有限公司 多数据源查询驱动系统、方法、装置和存储介质
US12093259B2 (en) 2020-08-07 2024-09-17 Target Brands, Inc. Ad hoc data exploration tool
US11675814B2 (en) 2020-08-07 2023-06-13 Target Brands, Inc. Ad hoc data exploration tool
US11550800B1 (en) * 2020-09-30 2023-01-10 Amazon Technologies, Inc. Low latency query processing and data retrieval at the edge

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0765032A (ja) * 1993-08-27 1995-03-10 Toshiba Corp データベース言語変換機能を持つ情報処理システム
JPH1049410A (ja) * 1996-08-07 1998-02-20 Matsushita Electric Ind Co Ltd 異種データベースアクセス装置
US6212529B1 (en) * 1996-11-13 2001-04-03 Puma Technology, Inc. Synchronization of databases using filters
US5832501A (en) * 1996-12-31 1998-11-03 Apple Computer, Inc. Method and system for filtering file manager attribute values
US5966707A (en) * 1997-12-02 1999-10-12 International Business Machines Corporation Method for managing a plurality of data processes residing in heterogeneous data repositories
US6182064B1 (en) * 1998-03-06 2001-01-30 International Business Machines Corporation Method and system for identifying an object located among a number of multiple interconnected computing systems
US6233586B1 (en) * 1998-04-01 2001-05-15 International Business Machines Corp. Federated searching of heterogeneous datastores using a federated query object
US6546381B1 (en) * 1998-11-02 2003-04-08 International Business Machines Corporation Query optimization system and method
US6134548A (en) * 1998-11-19 2000-10-17 Ac Properties B.V. System, method and article of manufacture for advanced mobile bargain shopping
US6470332B1 (en) * 1999-05-19 2002-10-22 Sun Microsystems, Inc. System, method and computer program product for searching for, and retrieving, profile attributes based on other target profile attributes and associated profiles

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0039709A1 *

Also Published As

Publication number Publication date
FR2787957B1 (fr) 2001-10-05
WO2000039709A1 (fr) 2000-07-06
US6704726B1 (en) 2004-03-09
JP2002533842A (ja) 2002-10-08
FR2787957A1 (fr) 2000-06-30
CA2320891A1 (fr) 2000-07-06

Similar Documents

Publication Publication Date Title
WO2000039709A1 (fr) Procede de traitement d'une requete
Roth et al. Don't Scrap It, Wrap It! A Wrapper Architecture for Legacy Data Sources.
Lacy OWL: Representing information using the web ontology language
FR2832236A1 (fr) Interface graphique de portail web semantique
EP1880325B1 (fr) Méthode dynamique de génération de documents xml á partir d'une base de données
US20090138498A1 (en) Rdf store database design for faster triplet access
Kashyap et al. Information brokering across heterogeneous digital data: a metadata-based approach
JP2001511279A (ja) ネットワーク情報へのアクセスの方法及びシステム
EP0702312A1 (fr) Dispositif de génération d'interfaces orientées objet pour des bases de données relationnelles et procédé mis en oeuvres par ledit dispositif
EP2188744A1 (fr) Installation de gestion d'une base de données
WO2004017228A2 (fr) Plateforme de type logicielle dediee au referencement de sites du reseau internet
FR2826748A1 (fr) Description d'une interface applicable a un objet informatique
EP1290578B1 (fr) Procede de recherche de donnees automatise et securise au moyen d'un reseau de transmission de donnees
Jafta et al. Investigating Ontology-based data access with GitHub
WO2002003245A1 (fr) Procede de stockage d'objets informationnels au format xml dans une base de donnees relationnelle
Flynn et al. Enabling Cross-Language Data Integration and Scalable Analytics in Decentralized Finance
EP1408428A1 (fr) Système et procédé de traitement et de visualisation des résultats de recherches effectuées par un moteur de recherche à base d'indexation, modèle d'interface et méta-modèle correspondants
Langegger et al. SemWIQ–Semantic Web Integrator and Query Engine
Kakaletris et al. Spatiotemporal Data-Cube Retrieval and Processing with xWCPS.
FR2872940A1 (fr) Systeme d'interrogation de bases de donnees heterogenes et procede d'interrogation
Ghawi Ontology-based Cooperation of Information Systems
FR3151675A1 (fr) Procédé d’exécution de premières instructions en langage naturel relatives à un traitement analytique souhaité des données d’une base de données
Anokhin et al. Resolving Inconsistencies in the Multiplex Multidatabase System
Chung Effective Indexed Data for Mobile Service Management
Dania Ontologies et Mauvaises Pratiques de Conception

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20000712

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20081218