Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Use of Rule Defined Query Partitions to Manipulate On Demand Data Access

IP.com Disclosure Number: IPCOM000145733D
Original Publication Date: 2007-Jan-24
Included in the Prior Art Database: 2007-Jan-24
Document File: 1 page(s) / 34K

Publishing Venue

IBM

Abstract

This invention provides a method for retrieving database information via a set of configurable documents containing database query statements. This allows for easier application maintenance when source data is either unknown or volatile during the design phase of the application.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 82% of the total text.

Page 1 of 1

Use of Rule Defined Query Partitions to Manipulate On Demand Data Access

The core idea of the invention is that different pieces of a data load from a specific data source may not be needed all at the same time. For instance, maybe information describing an employee's organizational information is updated every day, but the workstation information is only updated every week since that is when the data is available. Since both sets of data are available from the same source database for efficiency reasons, we would want to do the organizational information load separate from the workstation information load. Therefore, partitioned queries of this type might have an execution schedule that is not known during the time when a project is designed.

Accordingly, we need to get these queries out of the hard-coded design of an application and into documents stored within the application. Using the end-user interface, they are then editable only by system administrators.

The invention allows each rule to state whether a specific data load is to occur automatically or manually. If automatically, the rule could state if the query is currently enabled and when the query would run. Finally, each rule would contain the query to be executed itself.

Our implementation is based on a database where we were able to create a set of configuration mapping documents...