SEQUEL: A Structured English Query Language

Comments on:

Chamberlin, D. D. and Boyce, R. F. (1974). SEQUEL: A Structured English Query Language Proceedings of the 1974 ACM SIGFIDET Workshop on Data description, Access and Control, May 1974.

Comments from: Peter Brown, Michael Claveria, Davis Hart, Alex Leach (-), Brad Miller, Angeline Namai (*), Mark Nettling, Dimitar Tasev, Dave Ventresca.

General Questions

The reading suggests some advantages of declarative languages. According to the authors, programming in the declarative paradigm is less involving and therefore reduces the cost of software production and maintenance (250). If this is the case, why are the declarative languages not as popular as their imperative counterparts (I believe OOLs are imperative in style)?

SQL is certainly more popular than almost any programming language (as is Excel). Why have the declarative languages not succeeded? I'm not sure about all the reasons. One is that declarative programs are usually less efficient, and we continue to worry about efficiency. Another is that, well, many programmers can't grasp the subtleties of declarative programming. Success in declarative programming usually requires a good sense of formal logic and of mathematics. I hate to say it, but I'm not confident that the average programmer has either.

The authors contrast declarative programming with procedural programming. Based on this contrast, is procedural programming a synonym for imperative programming? Moreover, since we seem to use the terms procedure and function interchangeably, could we also say that procedural programming is the same as functional programming? What exactly is the difference between a procedure and a function?

Good try. You are correct that procedural and imperative are the same. You are also correct that we often use the terms procedure and function interchangably. However, the focus of procedural programming and the focus of functional programming are quite different. (The important thing is the central concept, not the word we use for that concept.)

Given that SEQUEL is specialized as a database language, should we refer to it as a programming language? It seems to me that it must be embedded within another language in order to be useful on the scale of other general-purpose languages. I have only used SQL as a subordinate/helper language to Scheme, so I am not really sure how useful it is when it stands alone.

Well, if we believe that it is equivalent in power to the first-order predicate calculus and we believe that the first-order predicate calculus is equivalent to the Turing machine, then SEQUEL can serve as a general purpose programming language. However, you are correct that it serves better as a special-purpose language, given that most modern SQL implementations add a more traditionally programming language.

On pg 251 Chamberlin writes that Knuth has shown that the majority of statements in FORTRAN are rather simple. Did he actually prove this?

Prove is a difficult word for this kind of question. My guess is that Knuth gathered a wide variety of FORTRAN programs and found that the majority of statements were rather simple. Is this a proof? Probably not. Is it evidence? Certainly.

Codd's language in the relational model of data paper is mentioned in the article. Did the makers of SEQUEL form the language based on data table observations and statements in Codd's paper?

Yes, it is pretty clear that SEQUEL descends directly from Codd's work, particularly since all of these folks were in the databases group at IBM.

A lot of the expressions in SEQUEL remind me of R, the statistical language I used this summer at Iowa State. I assume that the target audience of this paper is the new class of users who are "not willing to learn a query language." Since SEQUEL and SQUARE deal with data tables, I'm thinking that statisticians might fall under this category. Are there other groups of people who might need to work with data bases and not want to learn a query language?

At the time, almost anyone who wanted to explore data fell into that category. Query languages were pretty close to programming languages, and fairly low-level languages at that.

Specific Questions

When the ALL function is called what kind of data structure is returned? I'm refering specifically to the example Q3.1

ALL is not really a function, it's a quantifier over relations (at least in the examples give). SAL > ALL is SEQUEL-ese for for all x in results of the subquery, SAL > x.

Is the notation of SQUARE really supposed to be on two lines as is? It's a little confusing that way. I assume they are supposed to be on the same line inserted into the blank spaces, but i can't be sure if there's not some weird notation of SQUARE that is not readily aparent.

I'm pretty sure that they intended the multiple-line notation to look more like subscripts and superscripts.

The reading was pretty straightforward, since I've used SQL before. I just had a little trouble following example Q7. Why have a "group by mgr", if we're already selecting mgr from emp?

The GROUP BY MGR affects the evaluation of COUNT (NAME) > 10.

The paper keeps a positive view of the capabilities of SEQUEL, however, I am not extremely sure that holds nowadays as well, as the paper had been written years ago.

SQL remains quite popular. I'm not sure that non-programmers can really use it, unless we limie non-programmers to folks with some good technical understanding (which they seem to: accountants, engineerings, architects, and urban planners).

The paper claims advantage of SEQUEL over square in terms of the expressibility of the language (e.g. SEQUEL does not need to declare temporary variables in some cases where SQUARE needs to). But how does this functionality affect the speed of the language? Does it not mean that SEQUEL would be using more complex data structures, and hence require higher times for data manipulations?

Presumably, the SEQUEL interpreter can introduce the variables. SQUARE is also quite high level, so it's not clear that SEQUEL introduces much of a disadvantage of SQUARE.

Questions for Class

I am not sure how to read the mappings Q1, and Q2. Rather, I don't know how to interpret the way they are written.

I assume you mean Q1 and Q2 on p. 252, rather than Q1 on 253 and Q2 on 254. They correspond directly to the other Q1 and Q2. I'll try to draw a picture on the board of the way SQUARE expressions would look if we had real formatting.

Comments

This reading was straightforward and clearly formed the base for modern-day SQL. I was left wondering when the standard of displaying all duplicate rows in a query came about as both Boyce's and Codd's methods remove duplicates by default. Considering his goal was to make a query language accessible to the masses, I was surprised to find set notation in Q9 rather than something like

            SELECT          DEPT

            FROM             EMP

            WHERE           NAME MEMBER_OF { 'SMITH','JOHNSON','HUGHES' }

            AND                MGR = 'JONES'

Although, it seems that something like this would be allowed, no?

You should be able to answer that question by looking at the syntax.

I seems to me that SEQUEL is mostly just a direct translation from "English" into SQUARE. I already knew much of what was possible in SEQUEL through use of MySQL; however, I was suprised to find that SQUARE is equivalant to first-order lambda calculus. I also find it interesting that one of the main purposes of SEQUEL was to create a language enough like English that non-profesionals could use it, yet still complex enough to satisfy techies.

I did not find this reading anything but informative. I found it necessary, for I have poor database background knowledge. The formal syntax definition at the end of the paper allowed to better understand the capabilities of this language.

I thought that it is interesting how the authors choose to focus on the programmers writability as the primary goal of designing SEQUEL Along with this, it is interesting how the authors envisioned many different, non-computer people finding uses for their language, when in reality, most occupations they listed (especially urban planners) couldn't care less about how their data is managed and accessed as long as they can get the info they need, when they need it.

Well, urban planner often want to ask some pretty complex things, and may change their minds about the particular things they want as they explore the data, so perhaps they would be willing to write SEQUEL queries. Come back next year and ask Dr. Davis.

On a more technical level, I thought the paper made clear the advantages of SEQUEL over the predicate calculus based SQUARE. The use of the union and intersection characters were a little odd in the SEQUEL code (since the rest is keyboard characters, but I assume one could just as easily write union or something along those lines

I think I understand SEQUEL fairly well because we used it in our software design project from last semester. No further comments.

SEQUEL != SQL.

SEQUEL was created as an alternative to calculus-based query languages. The language was intended to serve the non-computer specialist whose occupation involved a considerable amount of data manipulation but did not require any profound knowledge of the implementations of database processes. Since neither the experienced programmer nor the CS academic was the targeted user, Chamberlin and Boyce decided to adapt an English-like syntax to replace the widespread mathematical notation of the predicate calculus. The English keyword syntax would be more successful, since it did not demand too much sophistication from ordinary users such as those in business and engineering.

Just so you know, predicate calculus is not the same as calculus.

The basic ideas behind SEQUEL seem to be to provide a programming language in which the syntax and functions are similar enough to spoken language that a common user will be able to understand it. Having used the language before, I would say they succeeded. I believe that anyone is able to use the language on a competent level just by learning about it for 15-30 minutes, whereas other programming language can take up to a month to learn enough to be comfortable using the language.

Well ... those with no programming experience take more than 15-30 minutes, and even competent programmers take a while to get the subtleties and complexities of SQL down. Note also that SQL != SEQUEL.