Re: Multi Valued Interface Models?

"dawn" <dawnwolthuis_at_gmail.com> wrote in message news:1139516551.663182.169400_at_g47g2000cwa.googlegroups.com...

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

Why not having an SQL interface for all high level software components ?

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

Why ?

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

If you have to organize a meeting with N peoples talking different languages how many translators would you need ? Received on Fri Feb 10 2006 - 10:30:40 CET