Conceptual Queries

Formulating non-trivial queries in relational languages such as SQL or QBE can prove daunting to end users. ConQuer?, a new conceptual query language based on ObjectRoleModeling, enables users to pose complex queries in a readily understandable way, without needing to know how the information is stored in the underlying database.

See http://www.orm.net/queries.html

Example of a query (from http://www.orm.net/pdf/ConceptQueries.pdf, the model can be seen on page 6):

In english:

List each employee who lives in the city that is the location of branch 52

In ConQuer?:

Employee +-lives in City +- is location of Branch 52

Equivalent Sql query:

select X1.empnr from Employee as X1, Branch as X2 where X1.cityname = X2.cityname and X1.statecode = X2.statecode and X1.country = X2.country and X2.branchnr = 52

Since ConQuer? queries are at the ConceptualLevel?, they are not affected by changes in multiplicity relationships, we can change the schema to allow an employee to live in more than one city, and the ConQuer? query remains the same (while the Sql query must be altered to reflect the new database structure). In other words, ConQuer? offers full AccessPathIndependence.

The author of the ConQuer? wrote:

Last year I taught advanced SQL to a group of 4th year university students who already had years of experience with SQL. I then gave them a simple introduction to ConQuer?, followed by a list of varied questions in English that they had to translate into both ConQuer? and SQL. Even without tool support, they had little trouble with the ConQuer? formulations, but they experienced great difficulty with the SQL. I admit the SQL questions were pretty nasty (lots of correlated subqueries and functions), but I set a wide range of questions without trying to bias them in favor of either language. At any rate, the relative performance was so dramatic that it reinforced my impression that ConQuer? is much easier to learn than SQL. Of course, more extensive trials are needed for a reliable empirical evaluation of the language.

I wonder how does it compare with TutorialDee or TopsQueryLanguage (it certainly looks much better than Sql for complex queries)...

{Most of the bulk of the SQL example above is the join "keys". If a dialect supports something similar to a NaturalJoin, then it could look more like:}

 SELECT emp.*
 FROM Employee as emp 
   NATURAL JOIN Branch 
 WHERE branch.branchNum = 52

{Natural joins can pre-define common relationships between entities so that one doesn't have to keep reinventing the relationship wheel. Views can also do such, but are more limited. If the employee-to-branch relationship is common enough to justify a view, then we could have SQL as short as:}

 SELECT * FROM emp_branch WHERE branchNum=52

{Thus, brevity alone doesn't tell us about the total effort and flexibility of managing relationship. --top}

Note that if the DB supports SQL NaturalJoins, the join code for the above is often unnecessary. There are a handful of things can could improve SQL such that going to an entirely different language may not be necessary to get simpler SQL.

Simpler queries is just one of the features of ConceptualQueries, and not the one I am more interested in, the feature that makes me think Conceptual Queries are interesting is they are not affected by changes in multiplicity relationships. They achieve one of the things that I believe was promised (but not entirely achieved) by the relational model (or maybe by existing pseudo-relational model implementations?): AccessPathIndependence. (Something, that BWT, ObjectRelationalMappers? with their OO based queries languages have also failed to provide us with: They may access paths explicit, and in some ways, easier to navigate, but the queries needed to navigate them are not independent from multiplicity changes)

OTOH it of course it is possible to get AccessPathIndependence in the relational query lenguage getting help from virtual relvars (views) but while normalization give us rules on how our base relvars should be structured, I do not remember reading anywhere about a set of rules that should be followed to achieve AccessPathIndependence using virtual relvars (views). Are those rules written in some unknown book? Please see ConceptualQueryExampleOfAdvantages for a more detailed example of the advantages of AccessPathIndependence.