zumbrunn.com - Tutorial D, Industrial D and the relational model

Tutorial D, Industrial D and the relational model

[...] But the trouble with the relational model is, it's never been implemented--at least, not in commercial form, not properly, and certainly not fully. So while it's true that there have been a couple of developments in the marketplace over the past few years that I do quite like, I like them primarily because I see them as attempts to implement pieces of the relational model that should have been implemented years ago but weren't. I refer here to (a) "business rules" and (b) "object/relational DBMSs." I'll take them one at a time.

Business rules: Business rule systems are a good idea, but they certainly aren't a new idea. Without going into a lot of detail, business rule systems can be seen as systems that attempt to implement the integrity piece of the relational model (which today's mainstream SQL products still--over 35 years after the model was first described!--so signally fail to do).
Object/relational DBMSs: To a first approximation, "object/relational" just means the domains over which relations are defined can be of arbitrary complexity. As a consequence, we can have attributes of relations--or columns of tables, if you prefer--that contain geometric points, or polygons, or X rays, or XML documents, or fingerprints, or arrays, or lists, or relations, or any other kinds of values you can think of. But this idea too was always part of the relational model! The idea that the relational model could handle only rather simple kinds of data (like numbers, and strings, and dates, and times) is a huge misconception, and always was. In fact, the term object/relational, as such, is just a piece of marketing hype ... As far as I'm concerned, an object/relational system done right would simply be a relational system done right, nothing more and nothing less.

[...] The next thing I want to say is that, while the relational model is certainly the foundation for "doing databases right," it's only the foundation. There are various ways we can build on top of the relational model, and various attempts have been made to do such a thing over the past 25 years or so. Here are a couple of examples:

Higher-level interfaces: It was never the intention that every user should have to wrestle with the complexities of something like SQL (or even the complexities, such as they are, of the relational algebra). I always rather liked the visual interfaces provided by Query-By-Example and the "visual programming" front-ends to Ingres, for instance. And there are many other attractive front-ends that simplify the business of building applications on top of a relational (or at least SQL) DBMS. 4GLs too can be regarded as a higher-level interface--but I was never very impressed by 4GLs as such, in part because they never seemed to be precisely defined anywhere; the idea might have been OK, but without a formal definition of the semantics of the language some very expensive mistakes can be (and were) made. Natural-language systems are another example; I still have an open mind about these, but I don't think anyone could claim they've been a huge success as yet.
Special-purpose applications: I think the right way to view things like OLAP and data mining is as special-purpose applications that run on top of the DBMS. I mean, I don't think these things should be part of the core DBMS (I could be wrong). Either way, however, I do want to complain about the CUBE stuff in SQL, which takes one of the worst aspects of SQL--its support for nulls--and "exploits" it to make it even worse. But that's a particular hobbyhorse of mine ... I think I'd better stop right here.

19.12.2005, 0:01

I love E4X

As a reality check of my proposal for skins in Helma 2 , I so far came up with the following prototype. The idea seems to work quite nicely already with current builds of Helma 2. I thought E4X could make implementing these kinds of mocha objects very easy, but I was surprised that it really turned out that way in practice.

(Topic Name)	(Comment Count)
Peter	(No comments yet)
Wolf	(2 comments)
John	(1 comment)
Andy	(8 comments)

(This list is empty)

19.12.2005, 10:28

ECMAScript - The Switzerland of development environments

Jon Udell points out that with the ongoing debate in programming circles about the pros and cons of static vs dynamic typing and class vs prototype based languages, and with ECMAScript gaining new respect and evolving at a faster pace, perhaps these styles will turn out more complementary than we suspect: a programming language can stay neutral to coding practices.

" When you already know what your types should be, [...], declare them. When you don't, don't. One language, two styles, complementary benefits. Good idea!"

29.12.2005, 13:45

Sketching image queries and reinventing email

A first sneak peek at the things we can expect from System One in 2006: Retrievr lets you find flickr images by drawing rough sketches of them.

" This article is not intended as a proposal for a replacement for email. [...] Nevertheless, in understanding how the move to REST improves email, you will hopefully come to see how moving your own web services to it would improve them ."

In other news...

Subversion hits 1.3.0 and brings us path-based authorization for svnserve.

In case you've been looking for it: Venkman for Firefox 1.5

And one more puzzle piece for building Mocha heaven: Banteng - leveraging GCJ and Rhino to build cross-platform native applications in Javascript.

3.1.2006, 9:23