I was peacefully pottering away at my workstation, contentedly spawning a daughter thread or something similar, when Robyn popped in. She’d been wrestling with the Grouping Workbench and trying to come up with a copper-bottomed explanation for what the GROUP BY statement does. I’d been trying to help out in my usual arrogant paternalistic way. This time she innocently asked me to interpret the following passage, which is an explanation of Grouping in O’Reilly’s Relational Database Dictionary. (‘helping to ensure the success of your database projects’ gushes the back cover)

Grouping 

Let r be a relation and let the heading of r be partitioned into subsets {X} and {Y}. Let the attributes of {Y} be Yl, Y2, …, Yn; also, let {X} not contain any attribute called YR. Then the grouping r GROUP ({Y} AS YR) is another relation s. The heading of s consists of {X} extended with an attribute YR of type RELATION {Y}. The body of s is defined as follows: first, let z be the result of r WRAP ({Y} AS YT). Second, for each distinct X value x in z, (a) let yr be the relation whose tuples are all and only those YT values from tuples in z in which the X value is x; (b) let t be a tuple with X value x and YR value yr (and no other attributes); then, and only then, t is a tuple of s. Note: Given a relation r and some grouping of r, there’s always an inverse ungrouping that will yield r again; however, the converse is not necessarily true.
Example: The following expression denotes a grouping of the relation that’s the current value of relvar SP:

SP GROUP ( { P#, QTY } AS PQ_REL )

That grouping is a relation spq of type RELATION {S# S#, PQ_REL RELATION {P# P#, QTY QTY}}. Relation spq contains one tuple for each distinct S# value currently appearing in. relvar SP, and no other tuples.

You might be thinking ‘Phew, hot stuff’, but I couldn’t make much sense of it. In fact, were I ever to be abducted by extraterrestrial aliens, I will expect them to address me in similar unfathomable clicks and whirrs before conducting their foul experiments upon my person.

It was whilst I was fruitlessly re-reading the definition for the fifth time trying to gather some meaning from it, I began to wonder whether, in fact, it was a poem. I give the first two resonant stanzas

Let r be a relation and I will tell you why

let the heading of r be partitioned into subsets {X} and {Y}.

Let the attributes of {Y} be Yl, Y2, …, Yn; also,

let {X} not contain any attribute called YR though.

The heading, now,  of s consists of {X} extended by

an attribute YR of type RELATION {Y}.

 The body of s is defined as follows: See!
first, let z be the result of r WRAP ({Y} AS YT).
Second, for each distinct X value x in z,
(a) let yr be the relation whose tuples be
 all and only those YT values, as anyone expects
from tuples in z in which the X value is x;

…and so on. Quite the sort of output one might expect of a Post-modernist Poet.

But then, after having extracted as much amusement out of the paragraphs as I could, I felt a certain twinge of sadness. Set theory is so simple that it can be taught to Primary School children. SQL is merely a formalised dialect of English that describes action. I firmly believe that a relational database can be made so simple that any educated person can use it. Codd formalised the theory for the automation of existing processes that existed long before the first computers. It is the language of information retrieval.

Robyn is a firm believer in the idea that there is nothing in Relational Database Theory or practice that cannot be explained to an interested child. If so, then I shall have to watch out for the next generation of Database consultants.

I have  bullied the editor of Simple-Talk to offer a Simple-Talk Goodie-bag, and a signed printed copy of my book, to the best interpretation of the passage I’ve quoted that is comprehensible to him. If anyone can turn the entire passage into a Bob-Dylan protest song, then a Phil Factor Excellence Award will be made.