Consider the case of Ikea and the hexagonal socket-head screw.

In this case, the case is designing the database — the database containing the case of furniture held together by a particular hexagonal socket-head screw, and the case of all the socket-head screws used by a particular piece of furniture.

This calls for a “many-to-many relationship.” It’s something hierarchical DBMSs like IBM’s old IMS product can’t easily handle.

That’s one reason … and by the way, the least-interesting reason … I called IMS obsolete in last week’s KJR.

I shouldn’t have made reference to “batch mainframe COBOL systems,” when I did, though, because except in historical contexts, mainframe has no meaning. I should have left it at “batch systems.” Batch describes architecture. Mainframe COBOL merely describes lineage.

In any event, its inability to easily handle routine data design requirements does make IMS obsolete, although in an uninteresting way. As last week’s column emphasized, the lack of interest the best IT talent has in working on IMS systems is, the most important reason.

Most important, but not the most interesting (to your loyal author, at least).

What is most interesting is that it’s on the wrong side of an ongoing trend — the replacement of static relationships with dynamic ones.

This played out in DBMS-land when relational technology began to compete with CODASYL network-model DBMSs. Unlike hierarchical DBMSs, CODASYL DBMSs could handle all of the data design situations relational technology could handle.

But CODASYL DBMSs handled them with fixed relationships implemented through DBMS-managed pointer chains. Relational DBMSs handle them dynamically through SQL JOIN statements.

The next stage of DMBS evolution — the rise of NoSQL — continues the trend. Most of what you read about the subject would lead you to believe NoSQL’s ability to handle “big data” is what makes it interesting. Most of what you read is … what’s the word I’m looking for? … oh yes, “wrong.”

NoSQL is interesting because it replaces static relationships with dynamic ones too. In this case it replaces traditional data warehouses’ fixed OLAP schemas with “schema on demand.” That’s what makes Hadoop implementations so much quicker than traditional data warehouse projects.

And that makes Hadoop implementations much more like Agile methodologies, when contrasted with traditional data warehouse projects, which resemble traditional (and obsolete in parallel ways) waterfall methodologies, as data design (specifications) has to be completed before storing any data in the warehouse.

And by the way, the rise of Agile is another example of dynamicism supplanting fixed relationships, in this case replacing waterfall’s fixed-at-the-start specifications with Agile’s dynamically discovered just-in-time ones.

Abandoning fixed relationships in favor of dynamically defined ones applies to application development tools, too.

Back in the days of batch mainframes, the notion of coding logic into callable subroutines was something renegade FORTRAN monks preached into the deaf ears of the COBOL priesthood. When several different COBOL programs needed the same business logic, this was accomplished through the use of (I’m not making this up!) the COPY verb, which literally copied source code from a library into the target program.

Any change to business logic meant recompiling all programs that used the copy code — compile-time binding, unlike FORTRAN and more modern object-oriented technologies that bind logic contained in callable subroutines or objects during the linking process … link-time binding.

More modern, that is, but not modern, because modern computer languages dispense with all of that. Binding, such as it is, happens dynamically at run time.

Add Wifi to the list. It replaces fixed location-based relationships (cables run to offices and cubicles) with dynamic ones (wherever the computer happens to be within a facility). Add VPN or Cloud and things become even more dynamic — “anywhere” replaces “within a facility.”

And then … here’s the punch line. It isn’t about technology at all. It’s about the relationship between companies and their workforces.

Following World War II, the relationship between employees and their employers was mostly fixed, from the day they entered the workforce until retirement.

This relationship became temporary a long time ago, and we’re rapidly entering an age in which it’s becoming purely dynamic — independent workers engaged on a contractual basis.

Not only is this basic relationship becoming dynamic, but increasingly, even team memberships come and go, as who reports to whom gives way to who does what best.

The driving force is the same as with the technological trend, too: increased flexibility.

Is this good or bad? It doesn’t really matter. Lamenting the passing of fixed employee/employer relationships is about as productive as lamenting the passing of the hierarchical DBMS. You can argue the virtues of either one all you like.

It won’t change a thing.