Lambda the Ultimate

Modeling data as binary relations shows up frequently in semantic data modeling. Take a look at this survey, section 3.3 is on binary models.

You would probably be interested in more recent research in this area. It's difficult to know where to start. If you put any four experts into a room you will get five different modeling languages (paraphrasing an old joke). I recommend ORM. Terry Halpin's book on Information Modeling is very good. The website for the book is www.orm.net.

Translating queries from these languages into SQL has been done. But it has not been commercially viable. No one really cares to use a non-standard language even if it is "better".

OTOH, translating SQL into a binary model has worked well in some cases. SybaseIQ is based on binary relations under the covers. There are others too. A DBMS with this design is usually called vertically partitioned or column-oriented. Moa is a current research project encompassing this.

Um, the relational model is also quite thoroughly "mathematical"; if you want to compare like with like, it may be better to think in terms of relations and relvars rather than tables, and Codd's relational algebra and relational calculus rather than SQL.

The folks over at Database Debunkings seem to be of the opinion that RDF/OWL is a reborn "binary relations" model (brief discussion here). I don't know if they're right about that or not, but I did notice that some of the diagrams on the Andrew Girov site looked distinctly like RDF (directed labelled) graphs. There is work afoot on developing query languages for RDF - see eg. Euler and RIL.

I'm a little bothered by Girov's characterisation of RDBMSs as "record based". Seems like getting off on the wrong foot to me.

A table is almost exactly a n-ary mathematical relation over the basic datatypes, or primitive sets. In fact, *most* SQL concepts have a straightforward interpretation in Set Theory. (Even if that gets lost under the many bells and whistles that have added to SQL over the years.)

If you are really interested in exploring different query languages, I highly reconmmend the book Principles of Database and Knowledge-base systems by Jeffrey Ullman (of Hopcroft-Ullman and Aho-Hopcroft-Ullman fame) It covers the Heirarchical, Network, Relational, and Object-Oriented database models, as well as giving you a flavor for the query languages ISBL, QUEL (which is PostgreSQL's original query language), Query-by-Example, QBE, SQL, DBTG, IMS, and OPAL. Sadly, you'd be hard pressed to come up with actual database software to toy with most of these languages.

The rest of the book gets into all the gory details and many of the algorithms used in an actual database implementation. Cool stuff, if you are interested. I've never really understood why relational database software does not have a "logical" schema which would be completely normalized and that all your queries would be based around, and a "physical" schema where the tables could be flexibly de-normalized as appropriate. Instead we get stuck in writing database triggers/stored procedures/extra program code to try to maintain integrity in a denormalized database, and if we want to tweak the schema, we often need to tweak our programs.

One of the more interesting aspects of the book is that it details the link between logic programming languages, such as Prolog, and databases. Basically, it calls databases equivalent to Prolog as a "knowledge base" system, and gives a restriction of Prolog, which Ullman calls "Datalog", that is basically equivalent to SQL. In fact, other than where Ullman touches on the other query languages, Datalog is usually used as the basis of discussion.

But as Prolog is a Turing-complete and database query languages aren't, implementing knowledge-base systems efficiently is a fundamentally harder (and in many cases intractable) problem, whereas database systems are relatively easy. And of course, Turing-complete languages don't have straightforward set-theoretic interpretations.