World Library  
Flag as Inappropriate
Email this Article

QUEL query languages

Article Id: WHEBN0033661295
Reproduction Date:

Title: QUEL query languages  
Author: World Heritage Encyclopedia
Language: English
Subject: PostgreSQL, Query language, SQL, Tuple relational calculus, ISBL
Publisher: World Heritage Encyclopedia

QUEL query languages

QUEL is a relational database query language, based on tuple relational calculus, with some similarities to SQL. It was created as a part of the Ingres DBMS effort at University of California, Berkeley, based on Codd's earlier suggested but not implemented Data Sub-Language ALPHA. QUEL was used for a short time in most products based on the freely available Ingres source code, most notably PostgreSQL. As Oracle and DB2 gained market share in the early 1980s, most companies then supporting QUEL moved to SQL instead. QUEL continues to be available as a part of the Ingres DBMS, although no QUEL-specific language enhancements have been added for many years.


QUEL statements are always defined by tuple variables, which can be used to limit queries or return result sets. Consider this example, taken from one of the first original Ingres papers:[1]

Example 1.1. Compute salary divided by age-18 for employee Jones.
range of E is EMPLOYEE
retrieve into W
(COMP = E.Salary / (E.Age - 18))
where E.Name = "Jones"
Here E is a tuple variable which ranges over the EMPLOYEE relation, and all tuples in that relation are found which satisfy the qualification E.Name = “Jones.” The result of the query is a new relation W, which has a single domain COMP that has been calculated for each qualifying tuple.

An equivalent SQL statement is:

 select (e.salary / (e.age - 18)) as comp
 from employee as e
 where = "Jones"

QUEL is generally more "normalized" than SQL. Whereas every major SQL command has a format that is at least somewhat different from the others, in QUEL a single syntax is used for all commands.

For instance, here is a sample of a simple session that creates a table, inserts a row into it, and then retrieves and modifies the data inside it and finally deletes the row that was added (assuming that name is a unique field).

create student(name = c10, age = i4, sex = c1, state = c2)
range of s is student
append to s (name = "philip", age = 17, sex = "m", state = "FL")
retrieve (s.all) where s.state = "FL"
replace s (age=s.age+1)
retrieve (s.all)
delete s where"philip"

Here is a similar set of SQL statements:

 create table student(name char(10), age int, sex char(1), state char(2))
 insert into student (name, age, sex, state) values ("philip", 17, "m", "FL")
 select * from student where state = "FL"
 update student set age=age+1
 select * from student
 delete from student where name="philip"

Note that syntax varies significantly between commands, and that even similar commands like insert and update use different styles.

Another feature of QUEL was a built-in system for moving records en-masse into and out of the system. Consider this command:

copy student(name=c0, comma=d1, age=c0, comma=d1, sex=c0, comma=d1, address=c0, nl=d1)
into "/student.txt"

which creates a comma-delimited file of all the records in the student table. The d1 indicates a delimiter, as opposed to a data type. Changing the into to a from reverses the process. Similar commands are available in many SQL systems, but usually as external tools, as opposed to being internal to the SQL language. This makes them unavailable to stored procedures.

QUEL has an extremely powerful aggregation capability. Aggregates can be nested, and different aggregates can have independent by-lists and/or restriction clauses. For example:

 retrieve (a=count(y.i by y.d where y.str = "ii*" or y.str = "foo"),b=max(count(y.i by y.d)))

This example illustrates one of the arguably less desirable quirks of QUEL, namely that all string comparisons are potentially pattern matches. y.str = "ii*" matches all y.str values starting with ii.

See also


  1. ^ Stonebraker, Michael; Wong, Eugene; Kreps, Peter; Held, Gerald (1976). "The Design and Implementation of INGRES". ACM Transactions on Database (TODS) Systems (ACM) 1 (3): 191.  

Further reading

  • C. J. Date: A Critique of the SQL Database Language. SIGMOD Record 14(3): 8-54, 1984.
This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.

Copyright © World Library Foundation. All rights reserved. eBooks from Project Gutenberg are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.