Home -> Usenet -> comp.databases.theory -> Re: Multi Valued Interface Models?

Re: Multi Valued Interface Models?

From: JOG <jog_at_cs.nott.ac.uk>
Date: 9 Feb 2006 08:16:29 -0800
Message-ID: <1139501789.169256.228910_at_g43g2000cwa.googlegroups.com> 






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 -
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. 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?



Clearly I favour the latter (a no brainer in my eyes) - If I use XML I
am using a model that only makes my data amenable to one single,
imprisoning interface. You only have to browse the XML boards for a
while to see hundreds of posts struggling with how to deal with this
exact same issue.



all best, Jim.
Received on Thu Feb 09 2006 - 17:16:29 CET












Original text of this message