www.sixfingeredman.net
..................................................
::. .  .   .     .       .          .

associative model critique

This is an initial response to the Associative Data Model: http://www.lazysoftware.com/associativemodel/default.htm

After some thinking, I'm noticing the associative model is a good midpoint between keywords and relationships. It's closer to the keyword model, since every "object" is really a keyword. The difference is that it structures the use of keywords into words and meta-words ("associations"). I need to learn more about the keyword model.

To: Charlie Davenport Subject: Re: New Database

This is not a new data model, it is actually exactly the same as the relational model. Actually, so much so that this serves as a pretty good tutorial on the relational model for non-technical people. :)

So that's the number one point: this IS the relational model. They even go to the trouble of proving it by illustrating how every association can be translated into a relation (in SQL). All differences are superficial. It's kind of like repainting your car and then claiming you've invented a radical new form of transportation. Sure, the car looks a bit different -- maybe even prettier -- on the outside but it works exactly the same on the inside. And if you're someone who just wants to go somewhere, then it doesn't make the least bit of difference what color the paint is.

Let me borrow some quotes and comment on them:

"Entities are things that have discrete, independent existence. An entity's existence does not depend on any other thing.

"Associations are things whose existence depends on one or more other things, such that if any of those things ceases to exist, then the thing itself ceases to exist or becomes meaningless."

A relational model is exactly the same. An entity is any piece of data, like a name, or a date, etc. A relation (or "association") defines the relationship between one or more entities. Often we view relations as tables and entities as columns in those tables. In practice most entities in a relation are basic types like strings and integers, but there's no fundamental reason they can't be more complex objects like People.

"The associative model distinguishes entities and association for a simple and fundamentally important reason: data models constructed by following this principle are closer to reality"

What they are actually doing is distinguishing relations which define conceptual "objects" from relations which define relationships between those objects. For example, a "Person" is not really an entity; it is acutally made up of many separate entities, like a name, an age, a birthday, etc. We need a relation to tell us that these entities go together into one conceptual object that we call the "person." The associative model sort of glosses over this fact. We also need other relations which tell us how this person relates to other things in our database. These are "associations" in LazySoftware's lingo.

This approach does seem conceptually clearer, but the first thing to recognize is that it is not a new data model. You could very easily stick a Person object into a database column, instead of a string or an integer or so on as is usually done. Then all of your relations are just like "associations"; they only describe the relationships between concepts, and the concepts themselves are packaged in opaque objects. That's what the Object-Relational model does.

The reason this approach hasn't caught on is because it's more complicated and less powerful. There is no way to get at data inside the person object, or describe how it relates to other data. For example, how are you supposed to get all Person's whose name starts with "N"? The Associative Model doesn't have any way of describing the inside of a person, and hence no way of querying it.

If you do break apart the Person entity into separate entities -- as indeed they do in the whitepaper -- then you have the relational model all over again.

"The distinction between entities and associations is one that other data modelling systems ignore or regard as peripheral. Most other systems would model a customer as an independent entity or object, whilst in the associative model it is an association."

That's basically a lie, or at least it shows they don't understand what they're talking about. In "most other systems" (i.e. relational databases), you'd have a Customer table tying a Person to a Legal Entity. Exactly like they have in the associative model, except for them calling it something different.

I'm reminded of the quote: "Those who don't understand Linux are doomed to reinvent it, poorly." Except replace "Linux" with "the Relational Model."

I talked a lot about what's wrong with this, but I don't want to be all negative. This is an excellent conceptual approach to understanding the Relational Model (that being what it is). They rag on the fact that the relational model uses mathematical concepts as its foundation; they may be great for people who can understand that kind of thing. BUT they're not easy to grasp intuitively, while their definition -- even if vague and innacurate -- is.

Their schema language is obviously nicer than SQL in many ways. I'm not sure if it's actually as expressive as SQL. But clearly for simple situations it's much easier to read. If we wanted, Tif or Ian or I could write a parser in Perl in probably a couple hours to read their schema language and spit out SQL. But since all the programmers already know SQL, I'm not sure it'd be much use. :)

A lot of the points they make about industry problems are correct. But these have nothing to do with the relational model, and only a little bit to do with the implementations in currently available databases. Mainly they are issues of design, programming, and process. So it's good to recognize the issues and do what we can to avoid them. Unfortunately just using the "Associative Model" won't help much.

I also think we can learn from their user-friendly approach. I.e. if a programmer is trying to explain to a PM or a client why the database has to be a certain way, then the Associative Model might be a good way of helping the PM/client understand things.

Lastly, here's the one thing I think this technology is PERFECT for; consumer desktop databases. Like Access, except more user friendly. With their explanation and schema language, just about anybody could create a real database after half an hour of studying. This is really their market; the technology isn't any good for programmers, because at its heart it's the same as what we already use, i.e. relational databases and SQL.

I wrote most of that before reading the whitepaper. After reading the whitepaper, I was quite a bit more irritated, since just about every one of the points in it is either a flat-out lie or misleadingly stated.

Perfect example: "five data models have been developed." Actually, if you stretch things a bit then you get three data models: hierarchical, network (which is identical to the "object model"), and relational (which is identical to the "object-relational model"). In reality, however, hierarchical is a subset of network, which is a subset of relational, so there is, so far, only ONE data model: relational.

It's unfair to people who haven't had the chance to study other perspectives and will come away badly misinformed. I'm glad you came to me. ;)

Anyways, it would take me too long to go through all the whitepaper points, and I think I've already hit the really important ones indirectly. But if there are any in particular you're curious about I'd be happy to cover them.

Whew.