Re: Multi Valued Interface Models?

JOG wrote:
> dawn wrote:
> > 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.
>
> Apologies for cutting off the quote on the first line - but I think
> this is perhaps an important point of contention. A user interface is
> just an interface - I just don't see how it can be a data model? It is
> just a single representation or view of complex, interrelated
> information - and it is this very interconnectivity that we need a data
> model for in the first place. I don't know, perhaps theres a
> terminology barrier here.
>
> > 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.
>
> Ok, consider the following MV XML data for a farmyard, ready for a web
> interface i might be writing to summarize the fields of my farm:
>
> <field>
> .....<location>north</location>
> .....<farmed_by>tom</farmed_by>
> .....<produce>turnips</produce>
> </field>
> <field>
> .....<location>west</location>
> .....<farmed_by>dick</farmed_by>
> .....<farmed_by>harry</farmed_by>
> .....<produce>carrots</produce>
> </field>
> <field>
> .....<location>east</location>
> .....<farmed_by>harry</farmed_by>
> .....<produce>potatoes</produce>
> .....<produce>carrots</produce>
> </field>
>
> This is great for extracting into an interface where some of the
> options are MV. Nice, quick and easy. It also corresponds nicely to a
> UML representation of a field entity, similar to the example you
> blogged. So far so good.
>
> Now a month later I want an interface that specifies different produce.
> Manipulating that previous interface is going to be a pain indeed -

This is a point of disconnect between us. There are logical data models everywhere throughout software. We can talk about the "data model" employed with each, which would be an abstraction of the programming language used for the logical data model.

For example, if one software component is passing an SQL query to a DBMS, the interface between the software and the DBMS has a model implemented in SQL. That model could be grouped under a broad heading of the RM, recognizing that the implementation deviates from the theory a bit. So, when I talk about the data model of a user interface, I am not talking about exactly the same uses for that data as if this were a database interface. There would be no need to manipulate the previous interface for use with a new one, for example.

I will move on to the model used for "large shared data banks" which is where Codd was directing his work. My blog this week noted that a relational model cannot be used as the model behind the implementation of a user interface. That does not mean that it cannot be used as the model behind the implementation of a database interface. It can.

> rather I want something like this for it to be directly in line with my
> new page's interface:
>
> <produce>
> .....<name>turnips</name>
> .....<farmed_by>tom</farmed_by>
> </produce>
> <produce>
> .....<name>carrots</name>
> .....<farmed_by>dick</farmed_by>
> .....<farmed_by>harry</farmed_by>
> </produce>
> <produce>
> .....<name>potatoes</name>
> .....<farmed_by>harry</farmed_by>
> </produce>
>
> This is the exact same data as I had originally packaged into a
> different hierarchy.

Yes, you are getting at the "shared" aspect. That is not required with the UI interface in the same way as with a database interface. I am claiming that you cannot use the RM as the model, and therefore an implementation of that model as the langauge, FOR (not "behind") the data model of the user interface. You must use another model. That, in itself, does not imply anything about whether the RM should be employed in the interface to databases.

> Should I replicate the data just because here my
> interface has changed? Or should I go through unwieldy xquery
> processing of the original hierarchy to extract and collate the
> information for a produce entity? Or should I have just used a
> flexible, representation independent data model in the first place?

There is NO SUCH THING as a representation-independent-data-model. The data model is about the representation of the data in an interface. The RM is about the representation of data in the interface between the person or process accessing a database and the database. If the RM is not about representation, then give me an interface to the database that represents the data as I want it (e.g. non-1NF, ordered lists, and no unvalues/NULLS) and do that RM thing behind the scenes. At the point that the RM is completely gone from representation in the interface, it is completely gone.

I suspect I'm still not saying this in a crystal clear way. I'll mull over the disconnect but if you have some insight on where we are talking past each other (x is in your boat on that one), let me know. I'm trying to get you to free your minds of the data model for the database for starters and look at modeling data elsewhere in software. This requires a common understanding of what a data model is. I don't think we have that yet.

Thanks for engaging in this dialog. I think if I can communicate this point so that you and x understand what I'm saying, it will be a breakthrough for me. Since my point here is not about the interface to the database (yet), we should be able to get to some agreement, I think. --dawn Received on Thu Feb 09 2006 - 22:03:15 CET