Source: http://www.google.com/patents/US20080168042?dq=6373188
Timestamp: 2014-07-28 17:21:33
Document Index: 769562676

Matched Legal Cases: ['art� 209', 'art� 209', 'art� 209', 'art� 209', 'arts 492', 'art 492', 'art 492', 'art 494', 'art 494', 'art 492', 'art 494', 'art 496', 'art 496', 'art 496', 'arts 492']

Patent US20080168042 - Generating summaries for query results based on field definitions - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign in<nobr>Advanced Patent Search</nobr>PatentsEmbodiments of the invention provide techniques for generating summaries for query results based on field definitions. The summaries are generated automatically according to specifications in the field definitions of the fields included in the query results. Each result field may include one or more...http://www.google.com/patents/US20080168042?utm_source=gb-gplus-sharePatent US20080168042 - Generating summaries for query results based on field definitionsAdvanced Patent SearchPublication numberUS20080168042 A1Publication typeApplicationApplication numberUS 11/621,301Publication dateJul 10, 2008Filing dateJan 9, 2007Priority dateJan 9, 2007Publication number11621301, 621301, US 2008/0168042 A1, US 2008/168042 A1, US 20080168042 A1, US 20080168042A1, US 2008168042 A1, US 2008168042A1, US-A1-20080168042, US-A1-2008168042, US2008/0168042A1, US2008/168042A1, US20080168042 A1, US20080168042A1, US2008168042 A1, US2008168042A1InventorsRichard D. Dettinger, Frederick A. KulackOriginal AssigneeDettinger Richard D, Kulack Frederick AExport CitationBiBTeX, EndNote, RefManReferenced by (2), Classifications (10), Legal Events (1) External Links: USPTO, USPTO Assignment, EspacenetGenerating summaries for query results based on field definitionsUS 20080168042 A1Abstract Embodiments of the invention provide techniques for generating summaries for query results based on field definitions. The summaries are generated automatically according to specifications in the field definitions of the fields included in the query results. Each result field may include one or more summaries that are designed to summarize the type of data of the particular field.
receiving the query search results for a query executed against a database, wherein the search results include result fields and corresponding values for the result fields and wherein the result fields have respective field definitions that define attributes of the respective result fields and wherein at least one of the field definitions includes a data summary specification; identifying one or more data summary specifications defined in the respective field definitions of the result fields of the query search results; and generating a summary for each of the identified one or more data summary specifications. 2. The method of claim 1, wherein the field definitions are included in a database abstraction model, and wherein each field definition specifies an access method for accessing data in the database corresponding to the field definition, and wherein the executed query is a transformed instance of an abstract query composed on the basis of the database abstraction model and wherein the abstract query includes the result fields.
receiving search results for a query executed against a database, wherein the search results include result fields and corresponding values for the result fields and wherein the result fields have respective field definitions that define attributes of the respective result fields and wherein at least one of the field definitions includes a data summary specification; identifying one or more data summary specifications defined in the respective field definitions of the result fields of the query results; and generating a summary for each of the identified one or more data summary specifications. 10. The computer readable medium of claim 9, wherein the field definitions are included in a database abstraction model, and wherein each field definition specifies an access method for accessing data in the database corresponding to the field definition, and wherein the executed query is a transformed instance of an abstract query composed on the basis of the database abstraction model and wherein the abstract query includes the result fields.
a database abstraction model of data stored in a physical database that defines a plurality of logical fields that each specify an access method for accessing data in the physical database, wherein one or more of the logical fields include data summary specifications applied to generate summaries for query results that include the respective logical field; and a runtime component configured to receive an abstract query composed from the plurality of logical fields, and further configured to generate a resolved query corresponding to a schema of the underlying physical database, and further configured, upon receiving any query results, to generate a summary for one or more result fields of the abstract query according to the respective data summary specifications of the result fields. 17. The system of claim 16, further comprising a query building interface for composing the abstract query from the plurality of logical fields, wherein the interface is configured to display an initial query result to a user, and further configured to display the generated summaries.
a database abstraction model of data stored in a physical database that defines a plurality of logical fields that each specify an access method for accessing data in the physical database, wherein one or more of the logical fields include data summary specifications applied to generate summaries for query results that include the respective logical field. 22. The system of claim 21, wherein generating the summary for a given data summary specification comprises invoking an executable plug-in configured to generate the respective summary, wherein the plug-in is invoked using a reference to the plug-in in the given data summary specification.
CROSS-REFERENCE TO RELATED APPLICATIONS This application is related to the following: commonly assigned, co-pending, U.S. Pat. No. 6,996,558, filed Feb. 7, 2006, titled �Application Portability and Extensibility through Database Schema and Query Abstraction;� commonly assigned, co-pending U.S. Pat. No. 7,054,877, filed May 30, 2006, titled �Dealing with Composite Data through Data Model Entities;� and commonly assigned, co-pending application titled �Abstract Query Plan,� Ser. No. 11/005,418, filed Dec. 6, 2004, each of which is incorporated by reference herein in its entirety.
Because of this complexity, users often turn to database query applications to assist them in composing queries of a database. One technique for managing the complexity of a relational database, and the SQL query language, is to use database abstraction techniques. Commonly assigned U.S. Pat. No. 6,996,558, filed Feb. 7, 2006, (the '075 application) entitled �Application Portability and Extensibility through Database Schema and Query Abstraction,� discloses techniques for constructing a database abstraction model over an underlying physical database.
SUMMARY OF THE INVENTION One embodiment of the invention includes a method of generating summaries for database query results, the method including executing a database query, identifying one or more data summaries specified in the field definitions of the result fields of the query results, and executing the one or more data summaries.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Embodiments of the invention provide techniques for generating summaries for query results based on field definitions. In general, the summaries are generated according to specifications in the field definitions of the fields included in the query results. Each result field may include one or more summaries that are designed to summarize the type of data of the particular field.
The Database Abstraction Model: Physical View of the Environment FIG. 1 illustrates a networked computer system using a client-server configuration. Client computer systems 105 1-N include an interface that enables network communications with other systems over network 104. The network 104 may be a local area network where both the client system 105 and server system 110 reside in the same general location, or may be network connections between geographically distributed systems, including network connections over the Internet. Client system 105 generally includes a central processing unit (CPU) connected by a bus to memory and storage (not shown). Each client system 105 is typically running an operating system configured to manage interaction between the computer hardware and the higher-level software applications running on the client system 105 (e.g., a Linux� distribution, a version of the Microsoft Windows� operating system IBM's AIX� or OS/400�, FreeBSD, and the like). (�Linux� is a registered trademark of Linus Torvalds in the United States and other countries.)
In one embodiment, users interact with the server system 110 using a graphical user interface (GUI) provided by an interface 115. In a particular embodiment, GUI content may comprise HTML documents (i.e., web-pages) rendered on a client computer system 105 1 using web-browser 122. In such an embodiment, the server system 110 includes a Hypertext Transfer Protocol (HTTP) server 118 (e.g., a web server such as the open source Apache web-server program or IBM's Web Sphere� program) configured to respond to HTTP requests from the client system 105 and to transmit HTML documents to client system 105. The web-pages themselves may be static documents stored on server system 110 or generated dynamically using application server 112 interacting with web-server 118 to service HTTP requests. Alternatively, client application 120 may comprise a database front-end, or query application program running on client system 105 N. The web-browser 122 and application 120 may be configured to allow a user to compose an abstract query, and to submit the query to the runtime component 114 for processing.
In one embodiment, the runtime component 114 may be configured to receive an abstract query, and in response, to generate a �resolved� or �concrete� query that corresponds to the schema of underlying physical databases 214. For example, the runtime component 114 may be configured to generate one or more SQL queries from an abstract query. The resolved queries generated by the runtime component 114 are supplied to DBMS server 116 for execution. Additionally, the runtime component 114 may be configured to modify the resolved query with additional restrictions or conditions, based on the focus of the abstract query.
In one embodiment, the database abstraction model 148 provides a set of logical field definitions 208 and model entity definitions 225. Users compose an abstract query 202 by specifying selection criteria 203 and result fields 204. An abstract query 202 may identify a selected model entity 201 from the set of model entities 225. The resulting query is generally referred to herein as an �abstract query� because it is composed using logical fields 208 rather than direct references to data structures in the underlying physical databases 214. The model entity 225 may be used to indicate the focus of the abstract query 202 (e.g., a �patient�, a �person�, an �employee�, a �test�, a �facility� etc). Additional examples of model entities 225 are described in commonly assigned, co-pending U.S. Pat. No. 7,054,877, filed May 30, 2006, titled �Dealing with Composite Data through Data Model Entities,� incorporated herein by reference in its entirety.
Illustratively, the abstract query 202 indicates that the abstract query 202 is focused on instances of the �patient� model entity 201. The abstract query 202 further includes selection criteria 203 indicating that data for patients with a �hemoglobin_test>20� should be retrieved in response to processing the abstract query 202. The selection criteria 203 are composed by specifying a condition evaluated against the data values corresponding to a logical field 208 (in this example, the �hemoglobin_test� logical field). The operators in a condition typically include comparison operators such as =, >, <, >=, or, <=, and logical operators such as AND, OR, and NOT. Result fields 204 indicate that data retrieved for abstract query 202 should return data for the �name,� and �hemoglobin_test� logical fields for each instance of the �patients� entity that have data satisfying selection criteria 203 in the underlying physical database.
Further, depending on the access method specified for a logical field 208, the runtime component 114 may generate a query of many different underlying storage mechanisms. For example, for a given logical field, the runtime component may be generate an XML query that queries data from database 214 1, an SQL query of relational database 214 2, or other query composed according to another physical storage mechanism using �other� data representation 214 3, or combinations thereof (whether currently known or later developed). Particular types of access methods and embodiments for executing abstract queries are further described in commonly assigned, co-pending, U.S. Pat. No. 6,996,558, filed Feb. 7, 2006, titled �Application Portability and Extensibility through Database Schema and Query Abstraction;� and commonly assigned, co-pending application titled �Abstract Query Plan,� Ser. No. 11/005,418, filed Dec. 6, 2004, both of which are incorporated herein in their entirety.
Summaries for Query Results Based on Field Definitions In one embodiment, the logical field definitions 208 may include a set of summary specifications 209. The summary specifications 209 of a logical field 208 specify the summaries that are available for an abstract query 202 which includes the logical field 208 as a result field 204. Thus, if an abstract query 202 is performed which includes a logical field 208 with a given summary specification 209, the specified summary may be generated to summarize the query results for the abstract query 202.
In one embodiment, each logical field 208 may include one or more summary specifications 209. The specified summaries are designed to summarize the type of data of the logical field 208 containing the summary specifications 209. For example, a logical field 208 may store an identifier that classifies each record into one of several discrete groups (e.g., �small�, �medium�, �large�.) Thus, a set of query results that include the logical field 208 may have a summary in the form of a pie chart representing the proportion of query results in each of the discrete groups.
FIG. 2B illustrates an exemplary abstract query 202, relative to the database abstraction model 148, according to one embodiment of the invention. In this example, the abstract query 202 includes selection criteria 203 indicating that the query should retrieve instances of the patient model entity 201 with a �Patient ID� value greater than �4999.� The particular information retrieved using abstract query 202 is specified by result fields 204. As shown, the abstract query 202 retrieves the ID, gender, marital status, age, and mortality of the patient.
Once the abstract query 202 is composed, a user may submit it to a runtime component 114 for processing. In one embodiment, the runtime component 114 may be configured to process the abstract query 202 by generating an intermediate representation of the abstract query 202, such as an abstract query plan. An abstract query plan is composed from a combination of abstract elements from the data abstraction model and physical elements relating to the underlying physical database. For example, an abstract query plan may identify which relational tables and columns are referenced by the access methods of the logical fields included in the abstract query. The runtime component may then parse the intermediate representation in order to generate a physical query of the underlying physical database (e.g., an SQL statement(s)). Abstract query plans and query processing are further described in a commonly assigned, co-pending application entitled �Abstract Query Plan,� Ser. No. 11/005,418, filed Dec. 6, 2004, which is incorporated by reference herein in its entirety.
A simple access method specifies a direct mapping to a particular entity in the underlying physical database. Logical field definitions 208 2, 208 3, and 208 5 each provide a simple access method, 212 2, 212 3, and 212 5, respectively. For a relational database, the simple access method maps a logical field to a specific database table and column. For example, the simple field access method 212 3 shown in FIG. 2B maps the logical field name 210 3 �Marital status� to a column named �Marital_Status� in a table named �Demographics.�
Logical field definition 208 1 exemplifies a filtered field access method 212 1. Filtered access methods identify an associated physical database and provide rules defining a particular subset of items within the underlying database that should be returned for the filtered field. Consider, for example, a relational table storing medical records for both employees and patients of a medical facility. A logical field for a patient identifier may be defined by using a filter to separate employee records from patient records. For example, a logical field definition 208 1 defines a logical field �Patient ID.� The access method for this filtered field 212 1 maps to the �ID� column of a �Demographics� table and defines a filter �Type=PATIENT.� Only data that satisfies the filter is returned for this logical field. Accordingly, the filtered logical field 208 1 returns a subset of data from a larger set, without the user having to know the specifics of how the data is represented in the underlying physical database, or having to specify the selection criteria as part of the query building process.
Logical field definition 208 4 exemplifies a composed access method 212 4. Composed access methods generate a return value by retrieving data from the underlying physical database and performing operations on the data. In this way, information that does not directly exist in the underlying data representation may be computed and provided to a requesting entity. For example, logical field access method 212 4 illustrates a composed access method that defines the logical field �Age� 208 4 as composed from the current system date (�Currentdate�) and a field named �Birthdate.� The field �Birthdate� is a column in a demographics table of relational database 214 2. In this example, data for the logical field �Age� 208 4 is computed by retrieving data from the underlying database using the field �Birthdate,� and subtracting the birth date value from a current date value to calculate an age value returned for the logical field 208 4.
As shown in FIG. 2B, each logical field definition 208 includes a summary specification 209. However, it is also contemplated that each logical field definition 208 could include multiple summary specifications 209, or alternatively could not include any summary specifications 209. Illustratively, logical field definition 208 1 includes a summary specification 209 1 which specifies a �Basic_Results� summary. Further, logical field definitions 208 2-5 include summary specifications 209 2-5, which all specify a �Pie_Bar_Charts� summary. In one embodiment, the summary plug-ins 250 may be executable classes, module programs or routines configured to generate the summaries specified in the summary specifications 209. When an abstract query 202 is performed, the summary plug-ins 250 are called to implement any summary specifications 209 specified in the logical field definitions 208 of the result fields 204.
FIG. 3 illustrates a method 300 for generating summaries for query results based on field definitions, according to one embodiment of the invention. The method 300 begins at step 310, where a query (e.g., abstract query 202) is executed. At step 320, the method 300 enters a loop (defined by steps 320, 340, and 350) for processing each result field present in the abstract query, thereby evaluating all query results. At step 340, a determination is made of whether a result field includes a summary specification. That is, for each result field the respective logical field definition is accessed to determine whether the logical field definition contains a summary specification(s). If not, the result field is skipped. Otherwise, the method 300 continues to step 350. At step 350, the method 300 enters a loop (defined by steps 350, 360, and 370) for processing each summary specification defined in a respective logical field definition for a given result field. At step 360, a summary is generated on the basis of the summary specification. It is contemplated that a summary specification may include conditions that must be met in order to generate the summary. For example, a given summary specification may require that the query results include more than a minimum number of records before the summary is generated. In another example, a query of a medical database may include a �Terminal Diagnosis� field, containing the diagnosis codes for the query results. A summary specification included in the logical field definition for the �Terminal Diagnosis� field may have a condition that a field storing the patient age at diagnosis is also part of the query. If so, a summary of the average life expectancy of the patients in the query results may be generated. Otherwise, the summary is not generated. At step 370, the generated summary is appended to the query results. Once all summaries for a given result field are completed, the method 300 returns to step 320 in order to evaluate the next result field. Once all result fields have been completed, the method 300 ends.
FIGS. 4A-F illustrate an exemplary graphical user interface screen 400 displaying a set of query results and data summaries, according to one embodiment of the invention. Of course, the examples shown in FIGS. 4A-F are for illustrative purposes only, and in no way limits the scope of the invention. The exemplary screen 400 illustrated in FIGS. 4A-E corresponds to the database abstraction model 148 of FIG. 2B, and is generated according to the method 300 of FIG. 3. The screen 400 is a graphical user interface (GUI) that presents the user with multiple selectable views that can be selected by a labeled tab. Hereafter, the selectable views are referred to as �screen tabs� or �tabs.�
As shown, the �Patient ID� tab 414 includes a summary 440 and a set of query results 430. Illustratively, the query results 430 include a column for each result field 204 of the abstract query 202. The summary 440 includes text descriptions of the number of returned rows and the number of unique patient IDs for the query results 430. As described, a summary is generated when that summary is specified for a result field. Referring back to FIG. 2B, the logical field definitions 208 of the result fields 204 are illustrated, including the summary specifications 209. Illustratively, the logical field definition 208, for the result field �Patient ID� includes a summary specification of �Basic_Results� 209 1. Thus, the summary 440 is of the summary type �Basic_Results.� In one embodiment, the �Basic_Results� summary may be generated by a summary plug-in 250 that is configured to calculate the number of returned rows and number of unique patient IDs, and to present the numbers in a text summary 440.
FIG. 4B illustrates the �Gender� tab 415 of the screen 400, according to one embodiment of the invention. The tab 415 includes the query results 430 and a summary 450. The summary 450 is composed of a pie chart and a bar chart, with each chart providing a graphic representation of the proportion of male and female patients in the query results 430. As shown in FIG. 2B, the logical field definition 208 2 for result field �Gender� includes a specification of summary �Pie_Bar_Chart� 209 2. Thus, the summary 450 is generated (e.g., by an appropriate plug-in) according to the summary specification 209 2 included in the field definition 208 2.
FIG. 4C illustrates the �Marital Status� tab 416 of the screen 400, according to one embodiment of the invention. The tab 416 includes the query results 430 and a summary 460. Similarly to the summary 450 of the �Gender� tab 415, the summary 460 of the �Marital Status� tab 416 is composed of a pie chart and a bar chart. In this case, each chart provides a graphic representation of the proportion of patients in the query results 430 in the marital status categories of married, single, divorced, widowed, legally separated, or unknown. The summary 460 is generated (e.g., by an appropriate plug-in) according to the specification of the summary type �Pie_Bar_Chart� 209 3 in the logical field definition 208 3 for result field �Marital Status.�
In another example, FIG. 4D illustrates the summary 470 of the �Age� tab 418, which is composed of a pie chart and a bar chart. In this case, each chart provides a graphic representation of the proportion of patients in the query results 430 in the age categories of adult, youth, children, or senior. The summary 470 is generated (e.g., by an appropriate plug-in) according to the specification of the summary type �Pie_Bar_Chart� 209 4 in the logical field definition 2084 for result field �Age.� Likewise, FIG. 4E illustrates the summary 480 of the �Alive� tab 419, which is also composed of a pie chart and a bar chart. In this case, each chart provides a graphic representation of the proportion of patients in the query results 430 that are either alive or dead. The summary 480 is generated according to the specification of the summary type �Pie_Bar_Chart� 209 5 in the logical field definition 2085 for result field �Alive.�
Multiple Summaries for Query Results Grouped by Different Fields In some situations, the records in a database may be structured so they could be grouped by more than one field. If so, a set of query results from the database could be summarized differently, depending on the fields that are grouped in generating the summary.
FIG. 4F illustrates the query results 430 and a set of multiple summaries 490, according to one embodiment of the invention. The summaries 490 include three pie charts 492, 494, 496. The first pie chart 492 is labeled �Records,� and provides a graphic representation of the proportion of patient records in the query results 430 by gender. As shown, the �Records� pie chart 492 includes 54 male records and 65 female records. The second pie chart 494 is labeled �Selected Patients,� and provides a graphic representation of the proportion of unique patients in the query results 430 by gender. As shown, the �Selected Patients� pie chart 494 includes 42 male patients and 49 female patients. Importantly, the number of records in the �Records� pie chart 492 is larger than the number of unique patients in the �Selected Patients� pie chart 494, even though both are filtered by the same query conditions. In this example, some patients have had more than one diagnostic test, and thus have multiple records in the database. The disparity in numbers is due to the different fields grouped in the two summaries.
In one embodiment, the summaries 490 also include a third pie chart 496 labeled �Warehouse.� As shown, the �Warehouse� pie chart 496 includes 239 female records and 297 male records. In this example, the �Warehouse� pie chart 496 represents the total records of a patient database, including those records that do not meet the current query conditions. It is contemplated that presenting a user with summaries of various aspects of the data (e.g., pie charts 492, 494, 496 of FIG. 4F) may advantageously enable the user to quickly compare and evaluate the query results.
CONCLUSION As described, embodiments of the invention provide techniques for generating summaries for query results based on field definitions. In one embodiment, summaries are generated automatically according to specifications in the field definitions of the fields included in the query results. In one embodiment, each result field may include one or more summaries that are designed to summarize the type of data of the particular field.
Referenced byCiting PatentFiling datePublication dateApplicantTitleUS8019783May 19, 2009Sep 13, 2011Oracle International CorporationSearch interface for finding data items of interest from a database systemUS20100131498 *Nov 26, 2008May 27, 2010General Electric CompanyAutomated healthcare information composition and query enhancement* Cited by examinerClassifications U.S. Classification1/1, 707/E17.07, 707/999.004International ClassificationG06F17/30Cooperative ClassificationG06F17/30424, G06F17/30554, G06F17/30595European ClassificationG06F17/30S8R, G06F17/30S4V, G06F17/30S4PLegal EventsDateCodeEventDescriptionJan 9, 2007ASAssignmentOwner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW YFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DETTINGER, RICHARD D.;KULACK, FREDERICK A.;REEL/FRAME:018732/0372;SIGNING DATES FROM 20070104 TO 20070105RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services©2012 Google