Re: Multi Valued Interface Models?

From: dawn <dawnwolthuis_at_gmail.com>
Date: 8 Feb 2006 22:13:18 -0800
Message-ID: <1139465598.886815.75750_at_g43g2000cwa.googlegroups.com>


JOG wrote:
> This post is primarily directed at the latest
> http://www.tincat-group.com/ blog, but is also at heart comment on
> other recent non-RM work as well as Pick.
>
> Dawn, I am not sure about the argument you follow in your latest blog -
> the logic as I read it appeared to be that because an interface might
> contain data in non-1NF, then the RM is not preferable as the
> underlying model. (I am happy to be rectified if I have misconstrued
> the angle).

OK, no, my argument is that it is not possible to employ the RM as the data model for a general user interface. Surely you can use the RM to persist data that makes its way to a UI, but you cannot use the RM as the data model of the interface to the user. You need an understanding of what a data model is (e.g. from my blog entry The Naked Model). Then separate yourself from thinking about the data model for the database (that is the model of the interface to the database) and focus on the data model of the interface to the user. It simply is not possible for the RM to be the data model for that interface.

> Now this is the same underlying logic I hear in the promotion of XML
> and OO databases.

It makes sense that they would use the same argument, but when I came to this conclusion I thought it to be original (in that I didn't read it anywhere). That is likely because I didn't have the patience to work through theory arguments (and notation) and the practical arguments were not very tight or clear. So if you know of some URLs to point me to that give basically the same argument that I'm giving here, I would love to read them.

> But it appears to me that this neglects the point
> that RM takes the principal that its model is interface independant -

Come up with a definition for data model as in the term "relational data model." What do you mean that it is interface independent. It is all about an interface.

> the data model does not know if you are going to represent the data in
> an "entity" format as you specify in the UML of your blog or some
> differing format - perhaps an interface that lists every possible
> colour of an animal, perhaps something else...who knows? Not the data
> model that's for sure.

I'm not talking about the data model of the database in this case. That might be what you are referring to as "the data model." I'm talking about the data model of the interface.

I'll read the rest tomorrow so I can turn in, but this is such a critical point that I want to be sure that it is understood. I might have to do another blog entry on this topic just because people seem to want to think only about a data model as it relates to stored data.

Let me know if you are starting to tap into what I'm saying with this. Thanks a bunch. --dawn Received on Thu Feb 09 2006 - 07:13:18 CET

Original text of this message