JP2005524138A - Method, computer program, and computer for accessing data in a multi-data repository environment - Google Patents

Abstract

A method, computer program, and computer for accessing data in a multiple data repository environment.
The present invention is generally directed to systems, methods, and products for accessing data regardless of the particular way in which the data is physically represented. In one embodiment, the data repository abstraction layer provides a logical diagram of the underlying data repository that is independent of the particular method of data representation. In one embodiment, the data repository abstraction layer specifies the location of data in the repository and how to access the data. A query abstraction layer is also provided, which is based on the data repository abstraction layer. The runtime component performs the translation of the abstract query into a form that can be used for a particular physical data representation.

Description

  The present invention relates to a method, a computer program, and a computer for accessing data in a multiple data repository environment.

  A database is a computerized information storage and retrieval system. A relational database management system is a computer database management system (DBMS) that uses relational technology to store and retrieve data. The most popular type of database is a relational database, a tabular database where data is defined so that it can be recognized and accessed in a variety of different ways.

  Regardless of the specific architecture, in a DBMS, a requesting entity (eg, application, operating system, or user) seeks access to a specified database by issuing a database access request. Such a request can include, for example, a combination of a simple catalog lookup request or transaction and a transaction that operates to read, modify, and add records specified in the database. These requests are made using an advanced query language such as Structured Query Language (SQL). By way of example, SQL is intended to obtain and update information from databases such as DB2 from International Business Machine (IBM), SQL Server from Microsoft, and database products from Oracles, Sybase, and CompterAssociates. Used for making interactive queries. The term “query” refers to a set of commands for retrieving data from a stored database. Queries take the form of command languages that allow programmers and programs to select, insert, update, and retrieve data locations.

  One problem faced by data mining and database query applications is generally their close relationship with a given database schema (eg, a relational database schema). This relationship makes it difficult to support the application as changes are made to the corresponding underlying database schema. In addition, migration of applications to alternative basic data representations is prohibited. In today's environment, the above disadvantages are largely due to the use of SQL by dependent applications that assume that a relational model is used to represent the information being queried. In addition, a given SQL query depends on a particular relational schema because specific database tables, columns, and relationships are referenced within the SQL query expression. Some problems arise as a result of these limitations.

  One problem is that changes in the underlying relational data model require changes to the SQL foundation on which the corresponding application is built. Therefore, application designers need to either precede changes in the underlying data model to avoid maintaining the application or change the application to reflect changes in the underlying relational model. Another issue is that different versions of the application need to extend the application to work with multiple relational data models to reflect the unique SQL requirements promoted by each unique relational schema. It is to be done. Yet another problem is the development of applications to work with alternating data representations, as SQL is designed for use with relational systems. By extending applications to support alternative data representations such as XML, it becomes necessary to rewrite the application's data management layer to use non-SQL access methods.

  A typical method used to address the above problem is software encapsulation. Software encapsulation involves the use of a software interface or component to encapsulate the access method into a particular underlying data representation. An example is in the Enterprise Java (R) Bean (TM) (EJB) specification, which is a component of Java (R) 2 Enterprise Edition (J2EE) suite technology. In the EJB example, entity beans expose a set of application program interfaces (APIs) that can be used to access the information, and encapsulate a given set of data. Function. This requires that the software be written (in the form of a new entity EJB) whenever a new set of data is to be accessed, or if a new pattern of data access is desired. It is a specialized method. The EJB model also requires code updates, application construction, and deployment cycles to react to the reconstruction of the underlying physical data model or to support alternative data representations. EJB programming also requires specialized skills because it requires more advanced Java programming techniques. Thus, the EJB method and other similar methods are fairly inflexible and expensive to maintain for general query applications that access an evolving physical data model. (Java® and all Java®-based trademarks are trademarks of Sun Microsystems, Inc. in the United States and / or other countries.)

In addition to the problem of accessing disparate data representations, today's environment is complicated by the fact that data is often highly distributed. A popular infrastructure such as the Internet includes a large number of data sources that need to be accessible to users in order to be valuable. Traditional solutions that deal with localized and homogenized data are no longer practical, and solutions that are under development to deal with heterogeneous distributed data must have knowledge of the location of each data source. Because there is a need to provide unique logic (software) to handle each different kind of data representation, there are many problems. Thus, typical solutions (such as providing a data warehouse that contains all of the information required by an application using the warehouse) change the location or representation of the data being consumed. Therefore, it is not easily configured and cannot be easily relocated to work with different data topologies. Data warehouses also create problems when the contents of the warehouse need to be extended with additional, publicly available information. In some cases, external data sources are very large and are subject to change. Maintaining a local copy of such data within a given data warehouse can be very expensive.
Reference number ROC920020088 (corresponding Japanese Patent Application JP-A-2003-323324)

  Therefore, there is a need for an improved and more flexible way to access data that is not limited to the specific way in which the underlying physical data is represented.

  According to one aspect, the present invention provides an abstract query according to a query specification of a requesting entity in a method for accessing data in a plurality of data repository environments, wherein the query specification includes a plurality of abstract queries. Receiving an abstract query in which a definition for a logical field is provided, mapping the logical field to the physical entity of the data by defining a method of accessing each of the physical entities and a location of each of the physical entities Transforming the abstract query into a query that matches a particular physical data representation of the data.

  Of course, this method can be performed using computer software.

  Preferably, methods, computer programs, and computers are provided for remote data access and integration of distributed data sources through a data scheme and query abstraction.

  The present invention is preferably directed to methods, computers, and computer programs for accessing data regardless of the particular way in which the data is physically represented. Preferably, it represents the various distributed data sources that are available for use by the application, to access and / or update information contained in these data sources, An abstraction layer is provided to describe the query used by the application. A runtime component uses information contained in a data repository abstraction component (one of the abstraction layers) to create an abstract query and specific data for one or more data repositories. -It preferably takes the role of breaking down into access requests.

  One embodiment provides a method for providing access to data having a particular physical data representation. The method includes providing a requesting entity with a query specification that includes a plurality of logical fields for defining an abstract query, and a data repository abstraction that maps the plurality of logical fields to a physical entity of the data. Providing a visualization. In one embodiment, the data repository abstraction defines, for each logical field, at least one locator that defines the location of the physical entity of the data and a mechanism for accessing the physical entity of the data. Access method.

  One embodiment includes a processor, a requesting entity that includes at least (i) a query specification that provides a definition for an abstract query that includes a plurality of logical fields, and (ii) a mapping rule that maps the logical fields to physical entities of data A data repository abstraction component, wherein the mapping rule includes a location specification for each of at least some of the logical fields of the abstract query, wherein each location specification specifies a physical entity to be accessed. A data repository abstraction component that specifies the location of the containing data source; and (iii) a runtime component for transforming the abstract query into a query that matches the physical entity of data according to the mapping rules. Memo To provide a computer that contains the door.

  According to another aspect, data comprising: (i) a query specification that provides a definition for an abstract query that includes a plurality of logical fields; and (ii) a mapping rule that maps the logical fields to physical entities of data. A repository abstraction component, wherein the mapping rule includes a location specification for each of at least some of the logical fields of the abstract query, each location specification including a physical entity to be accessed. A memory including a data repository abstraction component that specifies a location of the source; and (iii) a runtime component for transforming the abstract query into a query that matches the physical entity of data according to the mapping rules; Execute the contents of the memory Cormorants computer including a processor configured is provided.

  In accordance with one embodiment, in a method for providing access to data in a multiple data repository environment, a query specification including a plurality of logical fields for defining an abstract query is provided to a requesting entity. And providing at least a method for accessing the data and an access method for specifying a location of the data for each of the plurality of logical fields.

  Preferably, the method includes issuing the abstract query by the requesting entity according to the query specification, transforming the abstract query into a query that matches a particular physical data representation of the data, Accessing a data repository specified by the location in a method for accessing the physical entity of the data for a particular logical field of the logical field.

  Preferably, the query that matches the specific physical data representation is one of an SQL query, an XML query, and a procedure request.

  Preferably, transforming the abstract query into the query that matches the particular physical data representation comprises dividing the abstract query into sub-queries grouped according to type of access method. including.

  Preferably, the type of access method is selected from the group comprising an SQL query type, an XML query type, and a procedure request type.

  According to a preferred embodiment, in a method for accessing data in a multiple data repository environment, an abstract query is provided that conforms to a query specification of a requesting entity, and the query specification provides definitions for a plurality of logical fields that the query specification has. Mapping the logical field to the physical entity of the data by defining a step of issuing an abstract query by the requesting entity, a method of accessing each of the physical entities, and a location for each of the physical entities Transforming the abstract query into a query that matches a particular physical data representation of the data according to an access method.

  Preferably, a data repository designated by the location relative to a physical entity of the data for a particular logical field of the plurality of logical fields is accessible.

  Preferably, the abstract query includes at least one selection criterion and a result specification.

  Preferably, the method determines, for a physical entity of the data for a particular logical field of the plurality of logical fields, whether the physical entity of the data is located in a local cache; If not, accessing a data repository specified by the location in an access method for the physical entity of the data.

  Preferably, transforming the abstract query into the query that matches the particular physical data representation includes dividing the abstract query into subqueries grouped according to type of access method.

  Preferably, the type of access method is selected from the group comprising an SQL query type, an XML query type, and a procedure request type.

  According to a preferred embodiment, a program that, when executed by a processor, performs an operation that provides access to data in an environment of multiple data repositories, wherein the multiple queries for defining an abstract query Per logical field, each defining a query specification for a requesting entity, including logical fields, a method for accessing a physical entity of the data, and a plurality of parameters to be passed to the method to access the physical entity There is provided a computer readable medium comprising a program including an access method, wherein at least one parameter is a location parameter that specifies a location of a data source that includes the physical entity.

  The requesting entity may be an application, for example.

  Preferably, each of the plurality of access methods defines a specific physical representation and location of the respective physical entity of the data.

  Preferably, the operation comprises issuing the abstract query by the requesting entity according to the query specification, transforming the abstract query into a query that matches the particular physical data representation, and the plurality of logic Accessing a data repository specified by the location of the data relative to the physical entity for a particular logical field of the field.

  According to a preferred embodiment, a program that, when executed by a processor, performs an operation of accessing data having a specific physical data representation, and is abstracted by a requesting entity according to a query specification of the requesting entity. Issuing a query, wherein the query specification provides a definition for a logical field of the abstract query, a method for accessing at least the physical entity for each of the physical entities, and the physical Transforming the abstract query into a query that matches a particular physical data representation of the data according to an access method that maps the logical field to a physical entity of the data by defining an entity location; The program that contains the action No computer-readable medium is provided.

  According to a preferred embodiment, includes at least (i) a requesting entity that includes a query specification that provides a definition for an abstract query that includes a plurality of logical fields, and (ii) a mapping rule that maps the logical fields to physical entities of data. A data repository abstraction component, wherein the mapping rule includes a location specification for each of at least some of the logical fields of the abstract query, wherein each location specification includes a physical entity to be accessed. A note that includes a data repository abstraction component that specifies the location of the source; and (iii) a runtime component for transforming the abstract query into a query that conforms to the physical entity of data according to the mapping rules. When a computer comprising a processor configured to execute the contents of the memory are provided.

  Preferably, the first part of the data source specified by the respective location specification is local and the second part is remote.

  Preferred embodiments of the present invention will now be described by way of example only with reference to the following drawings.

Introduction The present invention is generally directed to systems, methods, and products for accessing data regardless of the particular way in which the data is physically represented. The data can include a number of different data sources.

  In one embodiment, the data repository abstraction layer provides a logical diagram of one or more underlying data repositories that are independent of a particular method of data representation. When multiple data sources are provided, an instance of the data repository abstraction layer is configured with a location specification that indicates the location of the data to be accessed. A query abstraction layer is also provided, which is based on the data repository abstraction layer. The runtime component performs the translation of the abstract query (configured according to the query abstraction layer) into a form that can be used for a particular physical data representation.

  One embodiment of the invention is implemented as a program product for use with a computer system, such as the computer system 100 shown in FIG. 1 and described below. One or more programs of the program product define the functionality of the embodiments (including the methods described herein) and can be included in various signal support media. Exemplary signal support media include, but are not limited to: (i) information stored permanently in a non-writable storage medium (eg, read in a computer such as a CD-ROM disc readable by a CD-ROM drive). A dedicated device) and (ii) modifiable information stored on a writable storage medium (eg, a floppy disk in a diskette drive or hard disk drive), or (iii) a computer or telephone network Information transmitted to the computer via a communication medium including wireless communication. The latter embodiment includes information downloaded from the Internet and other networks.

  In general, the routines executed to implement the embodiments of the invention may be part of an operating system or a specific application, component, program, module, object, or instruction sequence. The software of the preferred embodiment generally consists of a number of instructions that are translated into machine-readable form by a native computer and are therefore executable instructions. Further, the program is composed of variables and data structures that reside locally in the program or that exist in a memory or storage device. However, for convenience only, any particular nomenclature that follows will be used, and thus the present invention will be identified by any nomenclature and / or implied by such nomenclature It should be understood that the present invention should not be limited to use alone.

Environmental Physical Diagram FIG. 1 shows a block diagram of a networked system 100 in which embodiments of the present invention may be implemented. In general, a networked system 100 includes a client (eg, a user) computer 102 (three such client computers 102 are shown) and at least one server 104 (one such server 104). Including. The client computer 102 and the server computer 104 are connected via a network 126. In general, network 126 may be a local area network (LAN) or a wide area network (WAN) or both. In certain embodiments, network 126 is the Internet.

  Client computer 102 includes a central processing unit (CPU) 110 connected to memory 112, storage 114, input device 116, output device 119, and network interface device 118 via bus 126. Input device 116 may be any device that provides input to client computer 102. For example, a keyboard, keypad, light pen, touch screen, trackball, voice recognition device, audio / video player, or the like can be used. The output device 119 may be any device that provides output to the user, such as any conventional display screen. Although shown separately from input device 116, output device 119 and input device 116 may be combined. For example, a speech recognition device combined with a display screen with a built-in touch screen, a display with a built-in keyboard, or a text-to-speech converter can be used.

  Network interface device 118 may be any entry / exit device configured to allow network communication between client computer 102 and server computer 104 via network 126. For example, the network interface 118 may be a network adapter or other network interface card (NIF).

  Storage 114 is preferably a direct access storage device (DASD). Storage is shown as a single device, but fixed or removable, such as a fixed disk drive, floppy disk drive, tape drive, removable memory card, or optical storage It may be possible or a combination of both storage devices. Memory 112 and storage 114 may be part of one virtual address space that spans multiple primary and secondary storage devices.

  Memory 112 is preferably a random access memory large enough to hold the programming and data structures of the preferred embodiment of the present invention. Although memory 112 is shown as a single entity, it can actually contain multiple modules and can exist at multiple levels, from fast registers and caches to slower but larger DRAM chips. I want you to understand.

  As an example, the memory 112 includes an operating system 124. Exemplary operating systems that can be used for convenience include Linux and Windows® from Microsoft. More generally, any operating system that supports the functions disclosed herein can be used.

  The memory 112 also includes a browser program 122 that, when executed by the CPU 110, supports navigation between the various servers 104 and finding network addresses on one or more servers 104. Indicated. In one embodiment, the browser program 122 includes a web-based graphical user interface (GUI) that allows a user to display hypertext markup language (HTML) information. More generally, however, browser program 122 may be any GUI-based program that can render information transmitted from server computer 104.

  The server computer 104 is physically configured in the same manner as the client computer 102. Accordingly, the server computer 104 is shown to generally include a CPU 130, a memory 132, and a storage device 134 that are coupled together by a bus 136. Memory 132 may be a random access memory large enough to hold the programming and data structures of the preferred embodiment of the present invention located in server computer 104.

  Server computer 104 is generally under the control of operating system 138, which is shown to reside in memory 132. Examples of operating system 138 include IBM (R) OS / 400 (R), UNIX (R), Microsoft (R) Windows (R), and the like. More generally, any operating system that can support the functionality described herein can be used. (IBM and OS / 400 are trademarks of International Business Machines, Inc. in the United States and / or other countries. UNIX® is a registered trademark of OpenGroup in the United States and other countries. Microsoft and Windows ( R) is a trademark of Microsoft Corporation in the United States and / or other countries.)

The memory 132 further includes one or more applications 140 and an abstract query interface 146. Application 140 and abstract query interface 146 are software products that include multiple instructions that reside at various times in various memories and storage devices of computer system 100. When read and executed by one or more processors 130 of server 104, application 140 and abstract query interface 146 perform steps or elements in computer system 100 that implement various aspects of the preferred embodiment of the present invention. In order to execute, the necessary steps are executed. Application 140 (more generally, any requesting entity, including operating system 138 and, at a higher level, the user) issues a query to the database. For example, the queries that can be issued are collectively referred to as one or more databases 156-157, local databases 156 ₁ . . . 156 _N and the remote database 157 ₁ . . . 157 _N included. As an example, the database 156 is shown as part of a database management system (DBMS) 154 in the storage 134. More generally, as used herein, the term “database” represents any collection of data, regardless of a particular physical representation. As an example, the databases 156-157 can be configured according to a relational schema (accessible via SQL queries) or according to an XML schema (accessible via XML queries). However, the present invention is not limited to a specific schema, and considers extensions to schemas that are not currently known. As used herein, the term “schema” generally refers to a particular organization of data.

  In one embodiment, queries issued by applications 140 are defined according to application query specifications 142 included with each application 140. Queries issued by application 140 may be predefined (ie, hard coded as part of application 140) or generated in response to input (eg, user input) Good. In any case, a query (referred to herein as an “abstract query”) is constructed using logical fields defined by the abstract query interface 146. Specifically, the logical fields used for the abstract query are defined by the data repository abstraction component 148 of the abstract query interface 146. The abstract query is executed by the runtime component 150 that transforms the abstract query into a form that matches the physical representation of the data contained in one or more of the databases 156-157. Application query specification 142 and abstract query interface 146 are further described with reference to FIGS.

  In one embodiment, the elements of the query are specified by the user via a graphical user interface (GUI). The content of the GUI is generated by one or more applications 140. In certain embodiments, the GUI content is hypertext markup language (HTML) content that can be rendered on the client computer system 102 by the browser program 122. Accordingly, memory 132 includes a hypertext transfer protocol (http) server process 138 (eg, a web server) configured to respond to requests from client computer 102. For example, the process 138 can respond to a request to access one or more databases 156 residing on the server 104 as an example. Incoming client requests for data from databases 156-157 wake up application 140. When executed by the processor 130, the application 140 implements various aspects of the preferred embodiment of the present invention, including accessing the server computer 104 to one or more databases 156-157. Is executed. In one embodiment, application 140 includes a plurality of servlets configured to build GUI elements that are then rendered by browser program 122. When the remote database 157 is accessed via the application 140, the data repository abstraction component 148 is configured with a placement specification that indicates the database that contains the data to be retrieved. This latter embodiment is described in detail below.

  FIG. 1 is just one hardware / software configuration for networked client computer 102 and server computer 104. Embodiments of the present invention provide any comparable hardware, whether the computer system is complex, a multi-user computing device, a single user workstation, or a network device without its own non-volatile storage. It can also be applied to configurations. Further, while reference has been made to specific markup languages, including HTML, it is understood that the present invention is not limited to specific languages, standards, or versions. Thus, to those skilled in the art, the present invention is applicable to other markup languages as well as non-markup languages, and may be applied to future changes to certain markup languages as well as other languages not currently known. It will be understood that there is. Similarly, the http server process 138 shown in FIG. 1 is merely exemplary and is contemplated in other embodiments configured to support any known and unknown protocols.

Environmental Logic / Runtime Diagrams FIGS. 2-3 illustrate the interrelated components of the present invention, according to a preferred embodiment. The requesting entity (eg, one of the plurality of applications 140) issues a query 202 that is defined by the respective application query specification 142 of the requesting entity. Since the request is constructed according to the abstract (ie, logical) field without directly referencing the underlying physical data entities of the databases 156-157, the requesting query 202 is generally referred to herein as an “abstract query”. Called. As a result, abstract queries can be defined as independent of the particular underlying data representation used. In one embodiment, application query specification 142 includes both criteria used for data selection (selection criteria 204) and explicit specification of fields to be returned based on selection criteria 204 (return data specification 206).

  The logical fields specified by application query specification 142 and used to construct abstract query 202 are defined by data repository abstraction component 148. In general, the data repository abstraction component 148 specifies criteria for data selection and queries issued by the application 140 (eg, abstract query 202 to specify the format of result data returned from the query operation). ) Expose information as a set of logical fields that can be used in The logical fields are defined independently of the underlying data representation in use in the databases 156-157, thereby enabling the formation of queries that are loosely coupled to the underlying data representation.

In general, the data repository abstraction component 148 includes a plurality of field specifications 208 ₁ , 208 ₂ , 208 ₃ , 208 ₄ , and 208 ₅ (shown as an example of 5), collectively referred to as field specifications 208. Specifically, a field specification is provided for each logical field that can be used to construct an abstract query. Each field designation includes a logical field name 210 ₁ , 201 ₂ , 201 ₃ , 201 ₄ , and 201 ₅ (collectively referred to as field name 210) and an associated access method 212 ₁ , 212 ₂ , 212 ₃ , 212 ₄ , And 212 ₅ (collectively referred to as access method 212). The access method may include logical field names and specific physical data representations 214 ₁ , 214 ₂ . . . Associate with 214 _N (ie, map). As an example, two data representations of XML data representation 214 ₁ and relational data representation 214 _2. However, the physical data representation 214 _N indicates that any other data representation, whether known or unknown, is considered.

Any number of access methods are considered based on the number of different types of logical fields to be supported. In one embodiment, an access method is provided for single fields, filtered fields, and configured fields. Field designations 208 ₁ , 208 ₂ , and 208 ₅ exemplify simple field access methods 212 ₁ , 212 ₂ , and 212 ₅ , respectively. Simple fields are mapped directly to specific entities in the underlying physical data representation (eg, fields mapped to a given database table and column). As an example, the simple field access method 212 ₁ shown in FIG. 3 maps the logical field name 210 ₁ (“FirstName”) to the column name “f_name” of the table named “contact”. Field designation 208 ₃ illustrates filtered field access method 212 ₃ . The filtered field indicates the associated physical entity and provides rules used to define a specific subset of items in the physical data representation. In FIG. 3, the filtered field access method 212 ₃ maps the logical field name 210 ₃ (“AnytownLastName”) to the physical entity in the column named “1_name” in the table named “contact”; An example of defining a filter for an individual in the city of Anytown is shown. Another example of a filtered field is the New York ZIP code field that maps to a physical representation of the ZIP code and limits the data to only the ZIP code defined in New York State. Field specification 208 ₄ illustrates a composite field (composedfield) · access methods 212 _4. A compound access method computes a logical field from one or more physical fields using an expression provided as part of the access method definition. In this way, information that does not exist in the basic data representation can be computed. In the example shown in FIG. 3, the composite field access method 212 ₃ maps the logical field name 210 ₃ “AgeInDecades” to “AgeInYears / 10”. Another example is a compound consumption tax field by multiplying the sales price field by the consumption tax rate.

  It is contemplated that the format of the underlying data for any given data type (eg, date, decimal, etc.) can be different. Accordingly, in one embodiment, the field specification 208 includes a type attribute that reflects the format of the underlying data. However, in another embodiment, the data format of the field specification 208 is different from the associated underlying physical data. In this case, the access method is responsible for returning the data in the appropriate format assumed by the requesting entity. That is, the access method should preferably know what data format is assumed (ie, according to the logical field) and the actual format of the underlying physical data. In this case, the access method can convert the basic physical data into a logical field format.

As an example, field specification 208 of the data repository abstraction component 148 shown in FIG. 2 represents the logical field that is mapped to data represented in the relational data representation 214 _2. However, other instances of the data repository abstraction component 148 map logical fields to other physical data representations such as XML. Further, in one embodiment, the data repository abstraction component 148 is configured with an access method for procedural data representation. One embodiment of such a data repository abstraction component 148 is described below with reference to FIG.

  An exemplary abstract query corresponding to the abstract query 202 shown in FIG. As an example, the data repository abstraction 148 is defined using XML. However, for convenience, any other language may be used.

Table 1 Query example
001 <? Xmlversion = "1.0"?>
002 <!-Query stringrepresentation: (FirstName = "Mary" AND LastName =
003 "McGoon") OR State = "NC"->
004 <QueryAbstraction>
005 <Selection>
006 <Condition internalID = "4">
007 <Conditionfield = "FirstName" operator = "EQ" value = "Mary"
008 internalID = "1"/>
009 <Conditionfield = "LastName" operator = "EQ" value = "McGoon"
010 internalID = "3" relOperator = "AND"></Condition>
011 </ Condition>
012 <Conditionfield = "State" operator = "EQ" value = "NC" internalID = "2"
013 relOperator = "OR"></Condition>
014 </ Selection>
015 <Results>
016 <Field name = "FirstName"/>
017 <Field name = "LastName"/>
018 <Field name = "State"/>
019 </ Results>
020 </ QueryAbstraction>

  As an example, the abstract query shown in Table 1 includes a selection specification (lines 005 to 014) including selection criteria and a result specification (lines 015 to 019). In one embodiment, the selection criteria consists of a field name (for logical fields), a comparison operator (=,>, <, etc.), and a value expression (comparison field). In one embodiment, the result specification is a list of abstract fields that should be returned as the result of executing the query. An abstract query result specification can consist of field names and sort criteria.

  An example instance of the data repository abstraction component 148 corresponding to the abstract query in Table 1 is shown in Table 2 below. As an example, the data repository abstraction component 148 is defined using XML. However, any other language can be used for convenience.

Table 2 Example of data repository abstraction
001 <? Xmlversion = "1.0"?>
002 <DataRepository>
003 <Categoryname = "Demographic">
004 <Field queryable = "Yes" name = "FirstName" displayable = "Yes">
005 <AccessMethod>
006 <Simple columnName = "f_name" tableName = "contact"></Simple>
007 </ AccessMethod>
008 <Type baseType = "char"></Type>
009 </ Field>
010 <Field queryable = "Yes" name = "LastName" displayable = "Yes">
011 <AccessMethod>
012 <SimplecolumnName = "l_name" tableName = "contact"></Simple>
013 </ AccessMethod>
014 <Type baseType = "char"></Type>
015 </ Field>
016 <Field queryable = "Yes" name = "State" displayable = "Yes">
017 <AccessMethod>
018 <Simple columnName = "state" tableName = "contact"></Simple>
019 </ AccessMethod>
020 <Type baseType = "char"></Type>
021 </ Field>
022 </ Category>
023 </ DataRepository>

  FIG. 4 illustrates an example runtime method 300 that illustrates one embodiment of the operation of the runtime component 150. The method 300 begins at step 302 where the runtime component 150 receives an instance of an abstract query (such as the abstract query 202 shown in FIG. 2) as input. At step 304, the runtime component 150 reads and parses the abstract query instance to find the individual selection criteria and the desired result field. In step 306, the runtime component 150 processes each query selection criteria statement present in the abstract query, thereby creating a loop (steps 306, 308, 310, and 312 to build the data selection portion of the Concrete Query. Including). In one embodiment, the selection criteria consists of a field name (for logical fields), a comparison operator (=,>, <, etc.), and a value expression (comparison field). At step 308, the runtime component 150 uses the field name from the abstract query selection criteria to retrieve the field definition of the data repository abstraction 148. As described above, the field definition includes an access method definition that is used to access the physical data associated with the field. In this case, the runtime component 150 builds a ConcreteQuery Contributuion for the logical field being processed (step 310). As defined herein, ConcreteQuery Contribution is part of a concrete query that is used to perform data selection based on the current logical field. Specific queries are queries expressed in languages such as SQL and XML queries that match data in a given physical data repository (eg, a relational database or XML repository). Thus, the concrete query is used to find and retrieve data from the physical data repository represented by the databases 156-157 of FIG. In this case, the ConcreteQuery Contribution generated for the current field is added to the Concrete Query Statement. The method 300 then returns to step 306 to begin processing for the next field of the abstract query. Thus, the process initiated at step 306 is repeated for each data selection field of the abstract query, thereby providing additional content to the final query to be executed.

  After building the data selection portion of the specific query, the runtime component 150 indicates the information that should be returned as the result of executing the query. As described above, in one embodiment, an abstract query defines a list of abstract fields to be returned as the result of executing the query, referred to herein as a result specification. An abstract query result specification can consist of field names and classification criteria. Thus, the method 300 begins a loop at step 314 (defined by steps 314, 316, 318, and 320) to add the result field definition to the specific query being generated. At step 316, runtime component 150 uses the result field name (from the abstract query result specification) of data repository abstraction 148 to identify the physical location of the data to be returned for the current logical result field. Search and then retrieve the Result Field Definition from the data repository abstraction 148. The runtime component 150 then constructs a ConcreteQuery Contributuion (in step 318) for the logical result field (of a concrete query indicating the physical location of the data to be returned). At step 320, the ConcreteQuery Contribution is then added to the ConcreteQuery Statement. When each process of specifying the result of the abstract query is completed, the query is executed in step 322.

  One embodiment of a method 400 for constructing a Concrete QueryContribution for a logical field according to steps 310 and 318 is described with reference to FIG. At step 402, method 400 queries whether the access method associated with the current logical field is a simple access method. If it is a simple access method, a ConcreteQuery Contribution is constructed based on the physical data location information (step 404) and processing then continues according to the method 300 described above. If not, the process proceeds to step 406 where it is queried whether the access method associated with the current logical field is a filtered access method. If it is a filtered access method, a ConcreteQuery Contributuion is constructed based on the physical data location information for certain physical data entities (step 408). At step 410, the ConcreteQuery Contribution is extended with additional logic (filter selection) used for the subset data associated with the physical data entity. Processing then continues according to method 300 described above.

  If the access method is an unfiltered access method, processing proceeds from step 406 to step 412 where method 400 queries whether the access method is a complex access method. If the access method is a compound access method, at step 414, the physical data position for each subfield reference in the compound field expression is located and retrieved. At step 416, the physical field location information of the composite field expression is substituted into the logical field reference of the composite field expression, thereby generating a Concrete Query Contribution. Processing then continues according to method 300 described above.

  If the access method is not a complex access method, the process proceeds from step 412 to step 418. Step 418 represents any other type of access method that is considered an embodiment of the present invention. However, it should be understood that the embodiments assume that not all available access methods are implemented. For example, in certain embodiments, only simple access methods are used. In another embodiment, only simple and filtered access methods are used.

  As described above, if the logical field specifies a data format different from the basic physical data, it may be necessary to perform data conversion. In one embodiment, when constructing a Concrete Query Contribution for a logical field according to method 400, an initial conversion is performed for each access method. For example, this conversion may be performed as part of steps 404, 408, and 416, or immediately following. Subsequent conversion from the physical data format to the logical field format is performed after the query at step 322. Of course, if the format of the logical field definition is the same as the basic physical data, no conversion is necessary.

Other Embodiments of Data Repository Abstraction Component In one embodiment, a different single data repository abstraction component 148 is provided for each separate physical data representation 214 (as shown in FIG. 3). In the alternative, the single data repository abstraction component 148 includes field specifications for multiple physical data representations 214 (depending on the associated access method). In yet another alternative, multiple data repository abstraction components 148 are provided. In this case, each data repository abstraction component 148 exposes a different portion of the same underlying physical data (which may include one or more physical data representations 214). In this way, a single application 140 can be used simultaneously for multiple users to access the same underlying data. In this case, the specific portion of the underlying data published to the application is determined by the respective data repository abstraction component 148. This latter embodiment is described in a co-pending US patent application (reference number ROC920020088) entitled “DYNAMIC END USERSPECIFICCUSTOMIZATION OF AN APPLICATION'S PHYSICAL DATA LAYER THROUGH A DATAREPOSITORY ABSTRACTION LAYER” assigned to International Business Machines. .

  In any case, the data repository abstraction component 148 includes (or refers to) at least one access method that maps logical fields to physical data. For this purpose, as illustrated in the above embodiment, the access method describes means for finding and manipulating the physical representation of the data corresponding to the logical field.

  In one embodiment, the data repository abstraction component 148 extends to include descriptions of multiple data sources that may be local to the network environment, distributed throughout the network environment, or both. Is done. A data source can use a number of different data representations and data access technologies. In one embodiment, this constitutes an access method for the data repository abstraction component 148 with a location specification that defines the location of the data associated with the logical field in addition to the method used to access the data. Is achieved.

  Referring now to FIG. 6, a logical / runtime drawing of an environment 500 having multiple data sources (repositories) 502 is shown, which is a representation of the data repository abstraction component 148 in such an environment. 1 illustrates one embodiment of operation. The data source 502 to be accessed through the data repository abstraction component 148 may be local, remote, or both. In one embodiment, data source 502 represents databases 156-157 shown in FIG. In general, the data repository abstraction component 148 is configured similar to the above embodiment. Thus, the data repository abstraction component 148 has logical field definitions and associated access methods for each logical field definition. However, in contrast to other embodiments where only a single data source is accessed, this access method is configured by location specification in addition to physical representation specification. The location specification represents the location (ie, data source) where the data to be accessed (ie, data associated with the logical field definition) is found. However, in one embodiment, certain access methods contemplate that local data sources can be configured by default, with no location specified.

  In general, FIG. 6 illustrates an application 140, an abstract query specification 142 (also referred to herein as an application query specification), a data repository abstraction component 148 (used to map logical fields to access methods), and abstract. Shown is a runtime component 150 that is responsible for translating a query into one or more data access requests supported by a data repository 502 that includes the physical information being queried. In contrast to some of the embodiments described above, the data repository abstraction component 148 and runtime component 150 of FIG. 6 include multiple local and / or remote physical data repositories 502 (as used herein). Logical field definitions with associated data that can be distributed across multiple query-based and procedure-based interfaces and also referred to as local / remote data sources 502 Configured to support queries.

  For this purpose, application 140 defines data requirements for abstract query specification 142 that includes the logic of query selection and / or update based on logical fields, rather than the physical location or representation of the actual data involved. . Data repository abstraction component 148 includes logical field definitions 504 and access methods 506 for each logical field. The logical field definition 504 describes logical fields that can be used for use by the application 140. In one aspect, the data repository abstraction component 148 manages information that is available for use by the application 140. The addition of a new logical field is indicated in the new local or remote data source, which makes it available for use by the application. Each access method 506 defines a mapping between a logical field in the local / remote data source 502 and its physical representation. This relationship can be understood with reference to FIG.

FIG. 7 illustrates a plurality of logical fields 604 ₁ . . . An exemplary abstract query 602 is shown, including 604 _N. Each of the logical fields 604 is associated with an access method 608 ₁ ... (Collectively referred to as access method 608) by definition of a particular data repository abstraction component 148. . . 608 _N related. The physical representation information of the access method 608 is passed to the name of the access method to be used (referred to herein as “F1 access method”, “F2 access method”, etc.) and the named access method. Includes a plurality of parameters that describe how to access the physical data associated with the logical field. In general, such parameters are referred to as locator parameters 610 ₁ ... (Collectively referred to as locator parameters 610, also referred to herein as location specifications). . . 610 _N and other access parameters needed to access the data. A given data repository abstraction component instance can represent information managed by multiple local and remote physical data repositories.

  Illustrative embodiments in which a data repository abstraction component instance can be configured with location and other access parameters required to access data are shown in FIGS. Referring first to FIG. 8, a field specification 700 for a data repository abstraction component configured with a relational access method is shown. The field designation 700 is specific to a particular logical field, indicated by a field name (Field Name 702) “CreditRatingDescription” and having an associated access method. The associated access method name (AccessMethod 704) is “Simple-Remote”. This indicates that the access method is a simple field access method in which logical fields are directly mapped to specific entities in the underlying physical data representation and that data is located remotely. In this case, the logical field is mapped to a given database table “credit_t” and column “desc”. “URL” is a position designation (locator parameter) that designates the position of physical data. In this case, “URL” includes the identifier of the JDBC driver to be used, the name of the remote system that holds the data (remotesystem.abc.com), and the database schema (creditschema) that contains the data. “JDBCDriver” is the name of the Java® class that implements SQL access to this type of remote database.

  Referring now to FIG. 9, a field specification 800 for a data repository abstraction component configured with a procedure access method is shown. Field designation 800 is specific to a particular logical field, indicated by a field name (Field Name 802) “CreditRating” and having an associated access method. The associated access method name (AccessMethod 804) is “Procedural” indicating that the access method is a procedure access method. “Service Spec” indicates a definition of a web service description language (WSDL) related to a web service to be accessed. WSDL is a standard interface definition language for web services. A web service uses an established web infrastructure for communication and uses a standard data representation technique such as XML to represent information passed between the calling application and the web service to be invoked. And is a standard method used to call software applications. “ServiceName” indicates the name of the web service to be accessed from the set of possible services defined in the “Service Spec”. “Port Name” indicates the port name for the service to be accessed from the set of possible port names defined in “ServiceName”. The named port defines the network address for the service. “Operation” is the name of the operation to be called. A web service may support one or more functions referred to as “Operation”. “Input” indicates an input required when calling a web service. In this case, the last name value is provided as input to the service. “Output” indicates an output data item associated with this logical field. A service can return some output when invoked. Thus, the “Output” identification defines a plurality of output data associated with the current logical field.

  Note that for the procedural access method, the field specification of the data repository abstraction component for local data looks virtually identical to the field specification 800 shown in FIG. 9 for accessing remote data. The only difference is that in the local case, the referenced WSDL document has a URL pointing to the local server running the service.

  Referring again to FIG. 6, one embodiment of the operation of the runtime component 150 will now be described. In general, runtime components are responsible for building and executing executable queries based on abstract queries. To this end, at block 510, the runtime component 150 converts references to one or more logical fields to their corresponding physical locations and access methods (collectively referred to herein as access methods 506). In order to map to, the abstract query is parsed and the data repository abstraction component 148 is used. In one embodiment, the runtime component 150 divides the entire physical data query requirement into groups (referred to as “subgroups” 514) that represent accessing the same physical resource using the same access method (referred to as “subgroup” 514). Block 512). A “subquery” is then executed (block 516). The results of each subquery 514 are combined and normalized before the overall query result 520 is returned to the application 140 (block 518). In one aspect, this query partitioning scheme allows multiple runtime queries to be executed in parallel by the runtime component 150 utilizing multiple CPU hardware architectures.

  In one embodiment, runtime component 150 also manages local data cache 522. The local data cache 522 contains data retrieved for a particular logical field, and as a first choice for reference to the logical field indicated as a cache enabled in the data repository abstraction component. Used during subsequent queries. A logical field that is advantageously managed in a cache manner is a logical field whose value is relatively static and / or receives a large overhead for access (some information is pay-per- (If overhead is managed by the use model, overhead is measured by the time required to fetch the data or the cost of accessing the data).

  In various embodiments, a number of advantages over the prior art are suitably provided. In one aspect, the advantages are preferably achieved by defining a loose coupling between the application query specification and the underlying data representation. Rather than encoding the application with specific tables, columns, and related information as is the case when SQL is used, the application is in a more abstract manner that is then tied to a specific physical data representation at runtime. Define data query requirements. Loose query data joins can occur when the underlying data representation is modified, or even when the requesting entity uses a completely new physical data representation than was used when the requesting entity was developed. It preferably allows the requesting entity (eg, application) to function. When a given physical data representation is modified or reconstructed, the corresponding data repository abstraction is preferably updated to reflect the changes made to the underlying physical data model. The same set of logical fields is available for use by the query and is simply tied to different entities or locations in the physical data model. As a result, the requesting entity written to the abstract query interface will continue to function without modification, even if the corresponding physical data model undergoes major changes. If the requesting entity uses a completely new physical data representation than was used when the requesting entity was developed, the new physical data model uses the same technology (eg, relational database) Can be implemented according to different strategies for naming and configuration information (eg, different schemas). The new schema will contain information that can be mapped to a set of logical fields required by the application using a simple, filtered and assembled field access method technology. Alternatively, the new physical representation can use alternative techniques for representing similar information (eg, using an XML-based data repository versus a relational database system). In any case, the existing requesting entity written to use the abstract query interface will map the fields referenced in the query with the location and physical representation of the new physical data model, an alternative data repository abstraction Can be easily migrated to use a new physical data representation.

  In another aspect, simplified use by application builders and end users is facilitated. The use of an abstraction layer to represent logical fields in the underlying data repository allows application developers to focus on key application data requirements without considering the details of the underlying data representation. Thus, during application development, productivity is improved and errors are reduced. For the end user, the data repository abstraction exposes the relevant data and hides unnecessary and urgent content that is not needed for a particular class of end users who are developing a given query. Provide suitably.

  Furthermore, the presence of multiple data sources can be advantageously used. Whether the data source is local or remote, multiple data sources can be favorably accessed by configuring the data repository abstraction component by location. In this way, an infrastructure is provided that can take advantage of the currently popular distributed environment.

  Solutions that implement this model use the provided abstract query specification to describe their information requirements regardless of the location or representation of the data involved. The query is provided to a runtime component that uses the data repository abstraction component to determine the location and method used to access each logical part of the information represented in the query. In one embodiment, the runtime component also includes the data caching function described above for accessing the data cache.

  This model allows solutions to be easily deployed in different data topologies and allows the solution to work when data is relocated or reconfigured over time, It preferably allows the development of a solution regardless of the physical location or representation of the data used by. This scheme also simplifies the task of extending the solution to take advantage of additional information. Extensions are done at the abstract query level and do not require the addition of unique software to the location or representation of new data being accessed. This method advantageously provides a specific method used to access the data and a common data access method for software applications independent of the location of each item of referenced data. Represent physical data accessed via abstract queries in association (in an existing relational database system) or in a hierarchical format (like XML) or in some other physical data representation model Can do. Methods based on existing data query methods such as SQL and XQuery, methods involving policy-based access to information, such as Web Service calls (eg using SOAP) or retrieval of data via HTTP requests A number of data access methods are also supported, including

  Note that any references herein to specific values, definitions, programming languages, and examples are for illustrative purposes only. Accordingly, the present invention is not limited by any particular illustration and example. Furthermore, although aspects of the present invention are described with reference to SELECTION operations, other input / output operations are also envisioned, including well-known operations such as ADD, MODIFY, INSERT, DELETE, and the like. Of course, a particular access method may impose restrictions on the types of abstract query functionality that can be defined using fields that utilize that particular access method. For example, the fields involved in the combined access method are not viable targets for MODIFY, INSERT, and DELETE.

Figure 2 is a computer system utilized for illustration by a preferred embodiment of the present invention. FIG. 3 is a related diagram of software components. FIG. 4 illustrates one embodiment of an abstract query and data repository abstraction for relational data access. 4 is a flow diagram illustrating the operation of a runtime component, according to one embodiment of the invention. 4 is a flow diagram illustrating the operation of a runtime component, according to one embodiment of the invention. FIG. 4 is a relationship diagram of software components accessible by multiple sources of data. FIG. 6 illustrates an abstract query 602 that includes multiple logical fields. FIG. 7 is a diagram showing field specification of a data repository abstraction component configured by a relational access method. It is a figure which shows the field specification of the data repository abstraction component comprised by the procedure access method.

Claims (10)

In a method for accessing data in multiple data repository environments:
Receiving, from the requesting entity, an abstract query according to a requesting entity's query specification, wherein the query specification provides definitions for a plurality of logical fields it has;
In accordance with an access method that maps the logical field to the physical entity of the data by defining a method of accessing each of the physical entities and a location of each of the physical entities, the abstract query is sent to a specific physical of the data Transforming the query to match the data representation.   The method of claim 1, wherein transforming the abstract query into the query that matches the specific physical data representation comprises dividing the abstract query into subqueries grouped according to type of access method. Method.   The method according to claim 1 or 2, wherein the type of access method is selected from the group comprising an SQL query type, an XML query type, and a procedure request type.   4. A method according to any of claims 1 to 3, further comprising the step of accessing a data repository specified by the location relative to a physical entity of the data for a particular logical field of the plurality of logical fields.   5. A method as claimed in any preceding claim, wherein the abstract query includes at least one selection criterion and a result specification. Determining whether the physical entity of the data is located in a local cache for a physical entity of the data for a particular logical field of the plurality of logical fields;
6. A method according to any of claims 1 to 5, further comprising the step of accessing a data repository specified by the location in a method for accessing the physical entity of the data if not located.   A computer program comprising program code means adapted to perform the method of any of claims 1 to 6 when executed on a computer. In the computer,
A data repository abstraction component comprising: (i) a query specification that provides a definition for an abstract query that includes a plurality of logical fields; and (ii) a mapping rule that maps the logical fields to physical entities of data. The mapping rule includes a location specification for each of the at least some of the logical fields of the abstract query, each location specification specifying a location of a data source that includes a physical entity to be accessed; A memory including a data repository abstraction component; and (iii) a runtime component for transforming the abstract query into a query that matches the physical entity of data according to the mapping rules;
And a processor configured to execute the contents of the memory.   The computer of claim 8, wherein a first portion of the data source specified by the respective location specification is local and a second portion is remote. 10. The method of claim 8 or 9, wherein transforming the abstract query into the query that matches the particular physical data representation comprises dividing the abstract query into subqueries grouped according to type of access method. The listed computer.

Images