Patent Application
20090299984
1. Field of the Invention
The present invention generally relates to data processing and more particularly to allowing a client having limited system resources to access a relatively large data model, residing on a server, as if the data model was resident on the client.
2. Description of the Related Art
Databases are computerized information storage and retrieval systems. A relational database management system is a computer database management system (DBMS) that uses relational techniques for storing and retrieving data. The most prevalent type of database is the relational database, a tabular database in which data is defined so that it can be reorganized and accessed in a number of different ways. A distributed database is one that can be dispersed or replicated among different points in a network. An object-oriented programming database is one that is congruent with the data defined in object classes and subclasses.
Regardless of the particular architecture, in a DBMS, a requesting entity (e.g., an application or the operating system) demands access to a specified database by issuing a database access request. Such requests may include, for instance, simple catalog lookup requests or transactions and combinations of transactions that operate to read, change and add specified records in the database. These requests are made using high-level query languages such as the Structured Query Language (SQL). Illustratively, SQL is used to make interactive queries for getting information from and updating a database such as International Business Machines' (IBM) DB2, Microsoft's SQL Server, and database products from Oracle, Sybase, and Computer Associates. The term “query” denominates a set of commands for retrieving data from a stored database. Queries take the form of a command language that lets programmers and programs select, insert, update, find out the location of data, and so forth.
Queries are constructed of query conditions that serve to filter results returned from the query. Accordingly, a query may be thought of as group of filters put together to sift out only the data in which they are interested. Query conditions are typically constructed by specifying conditional operations on one or more fields in the targeted database. To facilitate query building, some client applications may include a graphical user interface (GUI) that exposes these fields to a user in an organized manner (e.g., as a hierarchical data model with categories and subcategories of fields). A typical query building session may involve loading the data model from the server and exposing portions of the data model as the user navigates the hierarchical data model, via the GUI, to select fields to involve in a query.
As the relative size and complexity of the underlying database increases, the size of the data model and number of fields to expose to the user via the GUI will grow accordingly. Conventional client systems (e.g., desktop or laptop computers connected to the database server via a network) used to run the GUI typically have sufficient system memory to allow the larger data model to be loaded on the client. However, it may also be desirable to run the GUI on non-conventional client systems having limited system memory, such as handheld computing devices (e.g., personal digital assistants and the like). These devices may have insufficient system memory to allow the entire data model to be loaded. Further, these devices may also rely on wireless data connections to a network, which may have lower bandwidth than conventional “wired” network connections. Therefore, even if a device has sufficient memory, network latency may prevent the entire data model from being loaded on the device in an acceptable amount of time.
Accordingly, there is a need for an improved method for exposing, on a client device having limited resources, fields of a data model representing an underlying database.
The present invention generally provides methods, articles of manufacture and systems for exposing, on a client device having limited resources, fields of a data model representing an underlying database for use in building queries against the database.
For some embodiments, a method for use by a client in building queries against a database represented by a data model generally includes receiving a request from a user to display one or more entities of the data model, retrieving, in response to the request, a portion of the data model related to the one or more entities, storing the retrieved portion of the data model in a cache, and displaying the one or more entities to the user.
For some embodiments, a method for accessing a hierarchical tree structure of nodes generally includes receiving a request from a user to access one or more entities associated with a first node, in response to the request, retrieving a portion of the tree structure related to the first node, storing the retrieved portion of the tree structure in a cache, and presenting, to the user, the one or more entities associated with the first node.
For some embodiments, the article of manufacture generally includes a computer-readable medium containing a program which, when executed by a processor, performs operations for building queries against a database represented by a data model. The operations generally include providing a user with an interface for building a query against the database, receiving, via the interface, a request from a user to display one or more entities of the data model, retrieving, in response to the request, a portion of the data model related to the one or more entities, storing the retrieved portion of the data model in a cache, and displaying the one or more entities to the user.
For some embodiments, the system generally includes a database, a data abstraction model comprising logical fields representative of physical fields of the database, and a client device. The client device generally includes a cache and an executable component configured to maintain a limited portion of the data abstraction model in the cache, the limited portion comprising one or more logical fields determined by input from a user, and expose, to the user, for use in building queries, one or more of the logical fields maintained in the cache.
So that the manner in which the above recited features, advantages and objects of the present invention are attained and can be understood in detail, a more particular description of the invention, briefly summarized above, may be had by reference to the embodiments thereof which are illustrated in the appended drawings.
It is to be noted, however, that the appended drawings illustrate only typical embodiments of this invention and are therefore not to be considered limiting of its scope, for the invention may admit to other equally effective embodiments.
The present invention generally provides methods, articles of manufacture and systems for exposing, on a client device, fields of a data model representing an underlying database for use in building queries against the database. For some embodiments, the client device may be a device having limited resources, such as a handheld computing device. Therefore, rather than load and expose the entire data model on the client at once, a limited portion of the data model may be exposed on a client in a “just in time” (JIT) basis. For example, the particular portion exposed may depend on a user's input (e.g., a navigation request), while the size of the exposed portion may depend on system parameters, such as the system memory and network bandwidth available to the client.
In other words, embodiments of the present invention may provide a mechanism to intelligently cache portions of the data model on the client device, allowing a user to navigate through the complete data model as if it was loaded on the device, although the device may have insufficient resources to actually hold the completed data model. By not loading portions of the data model on the client device until requested by a user, client resources, such as system memory and network bandwidth may be conserved.
According to some embodiments, the data model may be a hierarchical structure of nodes, each node representing a field or category of fields. As used herein, the term node generally refers to any point in a hierarchical tree structure, including parent nodes and leaf nodes. As used herein, the term parent node generally refers to a point in a tree structure at which subordinate items (or children nodes) originate, while the term leaf node (or childless node) generally refers to an end point in the tree structure. Accordingly, leaf nodes in the structure may represent actual fields of the database, while parent nodes may represent categories of fields. Nodes that are both parent nodes and children of another node or nodes themselves may represent subcategories of fields.
As an illustration, a data model representing a database used in a medical research facility, may be organized as a tree structure including separate category nodes for demographic patient information, patient diagnoses, and test results. Each of these category nodes may have, as children, subcategory nodes. For example, the demographic category node may have, as children, subcategory nodes for name, address, and age related subcategories. The age related subcategory may have as children leaf nodes for a birth date, age in years, age in decades, etc. While embodiments of the present invention may be applied in a wide variety of environments, to facilitate understanding, the description below may refer to a medical research environment as a specific, but not limiting example of a suitable environment. Of course, the number of levels in the tree structure (e.g., the number of categories and subcategories) may depend on a particular database modeled.
In one embodiment of the present invention, the data model is implemented as a data repository abstraction (DRA) component containing a collection of abstract representations of physical fields of the database. Thus, this data abstraction model provides a logical view of the underlying database, allowing the user to generate “abstract” queries against the data warehouse without requiring direct knowledge of its underlying physical properties. A runtime component (e.g., a query execution component) performs translation of abstract queries (generated based on the data abstraction model) into a form that can be used against a particular physical data representation.
The concepts of data abstraction and abstract queries are described in detail in the commonly owned, co-pending application Ser. No. 10/083,075, entitled “Improved Application Portability And Extensibility Through Database Schema And Query Abstraction,” filed Feb. 26, 2002, herein incorporated by reference in its entirety. While the data abstraction model described herein provides one or more embodiments of the invention, persons skilled in the art will recognize that the concepts provided herein can be implemented without such a data abstraction model while still providing the same or similar results.
The program(s) of the program product defines functions of the embodiments (including the methods described herein) and can be contained on a variety of signal-bearing media. Illustrative signal-bearing media include, but are not limited to: (i) information permanently stored on non-writable storage media (e.g., read-only memory devices within a computer such as CD-ROM disks readable by a CD-ROM drive); (ii) alterable information stored on writable storage media (e.g., floppy disks within a diskette drive or hard-disk drive); or (iii) information conveyed to a computer by a communications medium, such as through a computer or telephone network, including wireless communications. The latter embodiment specifically includes information downloaded from the Internet and other networks. Such signal-bearing media, when carrying computer-readable instructions that direct the functions of the present invention, represent embodiments of the present invention.
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 sequence of instructions. The software of the present invention typically is comprised of a multitude of instructions that will be translated by the native computer into a machine-readable format and hence executable instructions. Also, programs are comprised of variables and data structures that either reside locally to the program or are found in memory or on storage devices. In addition, various programs described hereinafter may be identified based upon the application for which they are implemented in a specific embodiment of the invention. However, it should be appreciated that any particular nomenclature that follows is used merely for convenience, and thus the invention should not be limited to use solely in any specific application identified and/or implied by such nomenclature.
As illustrated in
As illustrated by the client 1021, the client computers 102 generally include a Central Processing Unit (CPU) 110 connected via a bus 130 to a memory 112, storage 114, an input device 116, an output device 119, and a network interface device 118. The input device 116 can be any device to give input to the client computer 102. For example, a keyboard, keypad, light-pen, touch-screen, track-ball, or speech recognition unit, audio/video player, and the like could be used. The output device 119 can be any device to give output to the user, e.g., any conventional display screen. Although shown separately from the input device 116, the output device 119 and input device 116 could be combined. For example, the PDA 1023 may include a display screen with an integrated touch-screen or a display with an integrated keyboard.
The network interface device 118 may be any entry/exit device configured to allow network communications between the client 1021 and the server 104 via the network 126. For example, the network interface device 118 may be a network adapter or other network interface card (NIC). For a handheld device, such as PDA 1023, the network interface device 118 may comprise any suitable wireless interface to provide the wireless connection 127 to the network 126.
Storage 114 is preferably a Direct Access Storage Device (DASD). Although it is shown as a single unit, it could be a combination of fixed and/or removable storage devices, such as fixed disc drives, floppy disc drives, tape drives, removable memory cards, or optical storage. The memory 112 and storage 114 could be part of one virtual address space spanning multiple primary and secondary storage devices.
The memory 112 is preferably a random access memory (RAM) sufficiently large to hold the necessary programming and data structures of the invention. While the memory 112 is shown as a single entity, it should be understood that the memory 112 may in fact comprise a plurality of modules, and that the memory 112 may exist at multiple levels, from high speed registers and caches to lower speed but larger DRAM chips.
Illustratively, the memory 112 contains an operating system 124. Illustrative operating systems, which may be used to advantage, include Linux and Microsoft's Windows®, as well as any operating systems designed for handheld devices, such as the PDA 1023 (e.g., Palm OS®, Windows® CE, and the like). More generally, any operating system supporting the functions disclosed herein may be used.
The memory 112 is also shown containing a query interface 122, such as a browser program, that, when executed on CPU 110, provides support for building queries based on the data repository abstraction component 148. In one embodiment, the query interface 122 includes a web-based Graphical User Interface (GUI), which allows the user to display Hyper Text Markup Language (HTML) information. More generally, however, the query interface 122 may be any program (preferably GUI-based) capable of exposing a portion of the DRA component 148 on the client 102 for use in building queries. As will be described in greater detail below, queries built using the query interface 122 may be sent to the server 104 via the network 126 to be issued against one or more databases 156.
The server 104 may be physically arranged in a manner similar to the client computer 102. Accordingly, the server 104 is shown generally comprising a CPU 130, a memory 132, and a storage device 134, coupled to one another by a bus 136. Memory 132 may be a random access memory sufficiently large to hold the necessary programming and data structures that are located on the server 104.
The server 104 is generally under the control of an operating system 138 shown residing in memory 132. Examples of the operating system 138 include IBM OS/400®, UNIX, Microsoft Windows®, and the like. More generally, any operating system capable of supporting the functions described herein may be used.
In one embodiment, elements of a query are specified by a user through the query interface 122 which may be implemented as a set of GUI screens. The content of the GUI screens may be generated by the application(s) 140. In a particular embodiment, the GUI content is hypertext markup language (HTML) content which may be rendered on the client computer systems 102 with the browser program 122. Accordingly, the memory 132 may include a Hypertext Transfer Protocol (http) server process 138 (e.g., a web server) adapted to service requests from the client computer 102. For example, the server process 152 may respond to requests to access the database(s) 156, which illustratively resides on the server 104. Incoming client requests for data from a database 156 invoke an application 140 which, when executed by the processor 130, perform operations necessary to access the database(s) 156. In one embodiment, the application 140 comprises a plurality of servlets configured to build GUI elements, which are then rendered by the query interface 122.
Referring back to the client 1021, the memory 112 may also include a content manager 128 generally configured to control portions of the DRA component 148 exposed on the client 102. For example, the content manager 128 may retrieve portions of the DRA component 148, from the server 104, based on user input (e.g., navigation requests received via the query interface 122). As will be described in greater detail below, for some embodiments, the content manager 128 may be designed to optimize the portions of the DRA component loaded on the client 102, in an effort to minimize the frequency with which new portions are retrieved from the server 104, for example, in an effort to eliminate or reduce lengthy network transactions. Before describing operation of the content manager 128 in detail, however, operation of the abstract query interface 146 will be described with reference to
The query execution component 150 is generally configured to execute the abstract query 202 by transforming the abstract query 202 into a concrete query compatible with the physical data representation (e.g., an XML query, SQL query, etc). The query execution component 150 may transform the abstract query 202 into the concrete query by mapping the logical fields of the abstract query 202 to the corresponding physical fields of the physical data representation 214, based on mapping information in the DRA component 148. For example, as illustrated in
An illustrative DRA representation corresponding to a portion of the DRA component 148 (as shown, logical field specifications 2081 and 2082) shown in
The listing above illustrates how, for some embodiments, the DRA component 148 may be implemented as a hierarchical data structure of nodes, in this case including categories, subcategories, and fields. As will be described below, this hierarchical structure may be exploited to seemingly present to the user the entire DRA component 148 while actually loading only limited portions of the DRA component 148 at any given time.
As previously described, logical fields of the DRA component 148 may be loaded on the client 102 and exposed to the user via the query interface 122 for query building purposes. For example, the illustrated information listed (in TABLE II above) for each of the fields (e.g., whether a field is queryable and/or displayable) may be used by the query interface 122 to determine how a field may be used in a query. However, because the amount of available system memory may be insufficient to feasibly hold the entire DRA component 148 (particularly in the case of handheld devices, such as the PDA 1023 shown in
For some embodiments, the portions loaded on the client may be determined by user input, such as navigation requests, as the user is working with the query building interface 122. In other words, as a user navigates the hierarchical structure of the DRA component 148, portions may be retrieved, only as needed (or as their need is anticipated). As previously described the portions (or content) of the DRA component 148 that is resident on the client at any given time may be managed by a software component referred to as a content manager 128.
As a user is navigating through the categories and fields of the DRA component 148 via the user interface 122, the content manager 128 may be configured to perform exemplary operations 300, for example, to continuously update the selected nodes 162, in an effort to facilitate the navigation. The operations 300 may best be described with reference to
The operations 300 begin at step 302, when the content manager 128 receives a user selection, such as a request to view a different set of fields or a different set of categories. For example, the user may be presented with a query building GUI screen 500, such as that shown in
At step 304, the content manager 128 retrieves a portion of the data model (implemented as the DRA component 148) based on the user selection. At step 306, the content manager 128 stores the retrieved portion of the data model in the cache 160. Detailed operations for retrieving and storing portions of the data model in the cache 160 are described in greater detail below with reference to
In a similar manner, if the user selected one of the subcategories shown in
In general, the content manager 128 may be configured to intelligently cache portions of the DRA component 148, in an effort to allow the user to navigate through the nodes (e.g., categories and fields), as if the complete structure was stored on the client. As indicated in
At step 604, once a new node is selected, the children for the selected node are retrieved. At step 606, a determination is made as to whether the retrieved children nodes will fit in the cache 160 (i.e., if there is sufficient available space in the cache 160 to store the retrieved nodes). If there is sufficient available space, the children nodes are placed in the cache, at step 608.
For example, referring to
Referring now to
Therefore, referring now to
As previously described, retrieving nodes from the DRA component 148 residing on the server requires a network transaction and the client may have a limited bandwidth network connection. Therefore, for some embodiments, nodes may be retrieved in an effort to minimize the effects of network latency. For example, rather than retrieve only the children of a selected node, the content manager may anticipate future node selections and “pre-fetch” additional nodes (e.g., larger portions of a branch originating from a selected node possibly including grandchildren). This pre-fetching may occur in the background, for example, after the children nodes of the selected node have been presented (displayed) to the user by the query interface 122.
In other words, the children of the node selected by the user may already be resident in the cache 160, and may therefore, be promptly displayed to the user as the content manager 128 pre-fetches additional nodes (e.g., subordinate to the displayed children), in an effort to stay one step ahead of the user and provide the query interface 122 with a “look and feel” as if the entire DRA component 148 is resident on the client. As a user makes selections, pre-fetched nodes not in a selected path may be removed to make room for other nodes to be pre-fetched. For some embodiments, the algorithm utilized to remove nodes from the cache 160 may also be chosen in an effort to minimize the number of times nodes must be retrieved from the DRA component 148. For example, the algorithm may chosen according to a prediction of which nodes presently in the cache a user is likely to select in the future.
It should also be noted that, in the illustrated example, preference is given to nodes in a direct (ancestral) path from the root node to the selected node. In other words, nodes in the direct path are not removed until all other nodes have been removed. This approach may be taken in an effort to maintain, in the cache, nodes that a user is likely to select. As an example, node F may represent a category having two related subcategories (nodes I and J). A user building a query involving fields in the subcategory (I), may also be likely to involve fields from the related subcategory J. Therefore, maintaining both nodes I and J in the cache 160 may reduce an additional retrieval, across the network, of the node J and any children nodes thereof.
The operations begin at step 612, by locating the newly selected node (as illustrated, node I), to use as a starting point. At step 614, the content manager 128 moves up one level in the tree (to node F). At step 616, a loop of operations (618-624) are performed for each sibling of the current node (F), but not for node F itself, as it is in the direct ancestral path from selected node I.
At step 618, the content manager 128 traverses (down) the branch of the tree beginning at the current sibling node to leaf nodes (if any). At step 620, the lowest level leaf node is removed. For example, assuming the content manager selects siblings from left to right, sibling node E will be selected first, at step 616. Therefore, at step 618, the content manager will traverse the branch from node E down to node H and remove node H first, at step 620.
At step 622, the content manager performs a test to determine if, after removing the node at step 620, there is now sufficient space in the cache 160 for the children of the selected node (I). If there is sufficient space, the children of selected node I are loaded into the cache 160, at step 626, and the operations are exited, at step 628.
On the other hand, if there is not sufficient space in the cache 160, the content manager 128 determines, at step 624, if there are any more leaf nodes for the branch beginning with the current sibling. If there are more leaf nodes, processing returns to step 620, to remove the leaf nodes. For example, as illustrated, after removing the node H, the sibling node E now becomes a leaf node. Therefore, the node E may be removed next. Assuming there is still not enough space in the cache 160, processing may then proceed to step 616, to select the next sibling (G) at the current level. As illustrated, G is a leaf node and is, therefore, removed next.
If there is still not enough room in the cache 160, having performed the loop of operations for (and removing) each sibling of the current level (F), the content manager 128 proceeds to step 614, to again move up a level (to node D). For this iteration, performing the operations of steps 616-624 results in the removal of node C. If there is still not enough room in the cache 160, the content manager 128 moves up a level (to node A) and removes node B.
At this point, the root node is reached. As described above, in the illustrated example, preference has been given to nodes in the direct ancestral path from the selected node I. However, once the root node is reached, the only nodes remaining are in the direct ancestral path (nodes A, D, F and the child J of node F). Therefore, if there is still not sufficient space in the cache 160, these remaining nodes may now be removed. For example, the operations of
Of course, the exemplary operations of
Client-side caching of portions of a large data abstraction model may allow a client having limited resources, such as a handheld device, to effectively present a relatively large data model to a user. By selectively choosing, based on user input, the portions of the data model to load in the cache, a query interface may allow the user to seamlessly navigate the data model as if it were resident on the client.
While the foregoing is directed to embodiments of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof, and the scope thereof is determined by the claims that follow.
This application is a continuation of co-pending U.S. patent application Ser. No. 10/392,642, filed Mar. 20, 2003, which is herein incorporated by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10392642 | Mar 2003 | US |
| Child | 12537980 | US |
