Browse Prior Art Database

A method to help user build query more efficienclly and verify the correctness of built query easily

IP.com Disclosure Number: IPCOM000237176D
Publication Date: 2014-Jun-06
Document File: 8 page(s) / 480K

Publishing Venue

The IP.com Prior Art Database

Abstract

This article will let user have a way to monitor whole process of query generated by query builder funciton. It will let product end user could determined the query they are building is the one they want. This article also will provide a method to let user verify the queries' semantics by themselves easily.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 47% of the total text.

Page 01 of 8

A method to help user build query more efficienclly and verify the correctness of built query easily

Currently, almost all applications, obtaining information from database, have provided the capability to let user customizes query based on their business requirements. It does make data presentation efficient, but there are still some disadvantages.

Before discussing the disadvantages, we'd better know usually there are two types of users caring about query. One is QA people who need to verify whether the function works as designed; another is real users who care how to use it to obtain data.

Many product provides Query builder function ,it will be used as an example to describe the problems existing in this kind of query building function.

1. Query builder has provided user an interface to build all kinds of queries. It's hard for users to decide what entities should be used without any guide when there are too many (tables or view) provided at the same time. It's also hard to know which entity should be selected as a base to meet their requirements at first.

2. Even though user builds a query successfully, he does not know whether the query is actually what they want. There is no way to verify semantic correctness.

a) Whether field, condition and entity from GUI are mapped to the correct counterpart of database objects. For QA people, now there is no way to display how a query building process works.

b) Entity (representing database table, view or set of join result of table or view), and a series of relations (joins) are pre-populated into product at the

1


Page 02 of 8

beginning. When a user adding fields from two or more entities, the relations between those entities will be detected and added to query automatically. But there is no way to tell whether it changes the semantic of user defined query or not.

3. System added conditions may cause unexpected result for a saved query.

With regard to those products,often after a query is saved, timestamp related condition will be added to the query to allow user shrinks the range of searching results. The problem is that many entities can have timestamp (db client has access time, session has connection time). If a user does not know which one is actually used for the query defined, unexpected result will be returned at last.

The invention will analyze user selected fields, conditions, entities, and relationships between entities, then displaying query definition in an intuitive way. With regard to entity relationship analyzing, it will provide a way to help users know what entities should be added while building to make sure no invalid query happens at last. At last but not least, telling users the background meaning of pre-defined conditions and joins to avoid unexpected data.

Our core idea includes three parts. first one is via obtaining user selected fields, conditions and entities, presenting users the mapping of user selections and database objects in a diagraph , second one is...