Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>For inspiration, there are five established approaches I know of:</p> <ul> <li><p><em>Attribute List</em>. For a given table, you (the designer) provide a list all attributes for which the user specifies the query attribute value. Sometimes the user also specifies the operators (e.g., Like, &lt;, >, etc.); otherwise it’s fixed by you depending on the data type (strings use Like, numeric and date attributes use ranges). All criteria between attributes are combined by a logical AND. If you allow the user to list values for a single attribute, they are joined by a logical OR. Users generally assume that a blank attribute value implies that that attribute is not included in the criteria. Generally, you specify the table(s) that are likely to be of primary interest to users and hard-wire the Joins. Because the tables, joins, and Boolean possibilities are fixed, this has limited ad hoc flexibility, but for most cases it’s more than adequate. It’s the most common approach out there.</p></li> <li><p><em>Query by Example</em>. Users select the table(s) they want to query and you provide an empty multi-record form (e.g., grid) that includes all the attributes of the joined tables; that is, an empty query result (in some cases, the user selects the attributes to show too). The user completes the attribute values as if they were example records, where a blank attribute is assumed to vary. Thus, if Priority and Status values are entered for the same record, their attributes are combined by a logical AND. If they are entered on different records, they are combined by a logical OR. In some cases, the user may also specify operators for each attribute (e.g., to specify ranges of values). This provides a very high level of flexibility and seems to be relatively intuitive for users.</p></li> <li><p><em>Diagrammatic Query</em>. Tiziana Cararci’s Query by Diagram approach allows users to specify sophisticated Joins and Boolean by graphically manipulating an entity-relationship diagram. For more details, Google for:</p> <ul> <li><p>Catarci T &amp; Santucci G (1995). Diagrammatic Vs Textual Query Languages: A Comparative Experiment. Proceedings of the IFIP Work Group. 2.6 Working Conference on Visual Databases, (March).</p></li> <li><p>Catarci T, Costabile M F, Levialdi S, &amp; Batini C. (1997). Visual Query Systems: Analysis and Comparison. Journal of Visual Languages and Computing, 8(2), 215-260, (June).</p></li> </ul></li> <li><p><em>Graphic Filter Query</em>. Ben Shneiderman’s Filter Flow approach allows users to specify sophisticated Boolean by constructing visual networks of operators and criteria, leveraging a plumbing or electrical metaphor. Google for:</p> <ul> <li><p>Shneiderman B (1991). Visual User Interfaces for Information Exploration. Proceeding of the 54th Annual Meeting of The American Society for Information Sciences, 28 (Washington, DC, October).</p></li> <li><p>Murray NS, Paton NW, Goble CA, Bryce J (2000). Kaleidoquery: A flow-based visual language and its evaluation. Journal of Visual Languages &amp; Computing, 11(2), 151-189 (April).</p></li> </ul></li> <li><p><em>Natural Language Query</em> There’s been a lot of effort to try to parse natural language or semi-natural language into a structured query, but it hasn’t had much success, partly due to the ambiguity of natural language (e.g., in “Commission income of all salespersons assigned to Great Britain and Ireland,” the “and” could be interpreted as either a logical OR or AND). You could try returning multiple results (one for each interpretation) for the user to choose (sort of like Google). This approach may be adequate for unskilled users and for when a sufficing rather than perfectly correct result is sufficient.</p></li> </ul>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload