As I play with Ruby on Rails, I am percieving that the thing that makes it so powerful is the formalization of the ORM, the Object-Relational Model. I can't speak directly to the specifics of what it is, but the reason prototyping seems to be a breeze is because that work is done. So now there is a kind of algorithmic representation of the data to be used and the possible relations between it. Having an object oriented shell (Ruby) around query generation thus seems to be a no-brainer. That is to say things that were once done painstakingly are now easy. I say this having done it the hard way back in 91.
In 91 I was building star schemas, before the term had been formalized. Or put another way, I built my first star schema in 1990 or 89 thereabouts just a few weeks after having learned SQL. In those days, client-server was brand new in the corporate IT and what we were doing was considered unique. Mind you, these were the days before Powerbuilder, when DB2 was still king and Sybase hadn't quite become dominant.
By the time I was on my third big multidimensional-relational project, I had a good sense of what made sense and what didn't - to the point at which I was confident that I could replace systems build by Liddle's old company Metaphor, which at the time was in the process of devolution being sold to IBM. My concept was a 'navigation set'. Having scoped out the application quite well, (in those days there was no such thing as a legal ad-hoc query), we understood every implication to every click on the screen. And since I was working in a 4GL-based front-end (this was in the days just prior to visual programming), I had to write code to dynamically generate SQL. The result was a big hairy array with 100 elements which described the current state of the application in terms of all the dimensions. For all I know, this is what's at the core of all such general purpose OLAP front-ends. I'd have to ask my boys at Pentaho.
The Navigation Set, once established by the operations (click, pivot, drill, select, etc) of the front-end operator would then, at the press of a 'Go' button, send it's parameters to the Query Module which would assemble fragments of SQL. My navset was smart enough to know when to to subselects as well. The Query Module would then have an interface to the DB2 on the back side and through a dynamic bind, query the appropriate fact table(s) and bring back a screenful of data.
This might be the basis of an object-analytical model, and an OAM would be the touchstone of development of a new set of tools that can make analytical applications easier to build. Of course people would have to understand the fundamental performance characteristics of multidimensional databases (right now there just seems to be Essbase and MSAS) but this could be a good thing. The issue is, of course, the rapidity with which repetitive questions can be asked - the fundamental stuff of OLAP.
Comments