Re: Multi Valued Interface Models?

"dawn" <dawnwolthuis_at_gmail.com> wrote in message news:1139465598.886815.75750_at_g43g2000cwa.googlegroups.com...

> OK, no, my argument is that it is not possible to employ the RM as the
> data model for a general user interface.

Why not ? And why are you using HTML and XML as an example ? Why not using a real example of an application interface ? What is a general user interface ?

HTML/XML/HTTP is a poor low level complex way to describe an interface.Are you trying to use a high level tool to model a low level one ? (like implementing assembler in Pascal or Prolog )

One does not need to model all interfaces with RM. Just the ones at the highest level. If you want to use the same model for all interfaces you can always use assembler programming for that.

Have you noticed how hard is to write all the HTML&Co code by hand ? Have you noticed how hard is to maintain this code when you have to use reverse engineering for it ?

The RAM for the computer we use is seen as random access arrays. This is the lowest level. The C language allow one to see a sequence of memory cells as a numbers or a string and to build sequences (struct), iterations (arrays) and variants (union) of typed sequences of memory cells.

This is not enough. Enter the marvelous world of dynamic memory allocation and pointers. Suddenly the memory is not a sequence anymore.

How could one represent such data with XML/HTML ? Why is this superior to the solution proposed by the RM ? What has been lost with the extention of binary relations to n-ary ones ?

For the normalization algorithm from "0NF" to 1NF Codd made two hypotheses:
1) the keys are not complex
2) the graph of the domains is not complex

I would add another one: there are keys. I don't understand the hypothese 2) and I do understand your ripple delete example.

Personally I have found SQL to be hard to learn in comparation with the QBE interface from Borland Paradox desktop DBMS for DOS for example. I liked the "bidimensional" "query" language embeded in PAL language.

SQL proved to be impossible to teach to some highschool graduate unlike the QBE interface from MS Access.

I also like Quel language but I prefer QBE (the one written in ASCII).

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

Why not ?

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

Why not ?

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

"You can paint it any color, so long as it's black "

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

How are those data models different ? Received on Thu Feb 09 2006 - 10:36:52 CET