Re: Multi Valued Interface Models?

"dawn" <dawnwolthuis_at_gmail.com> wrote in message news:1139499842.414737.143380_at_f14g2000cwb.googlegroups.com...
>
> x wrote:
> > "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 ?

> The User Interface could be specified with any tools in the
> implementation. I figured UML was generally acceptable at this point
> for showing a model of data using a class diagram.

You have not shown a complete model of the interface. HTML and XML are not UML.
I don't think UML is generally acceptable.

> > Why not using a real example of an application interface ?

> I'm looking at the model of data for a user interface and then said
> that same model could be implemented in xml, for example, for data
> exchange.

You are not looking at a relational model of data. You talk about data copying.

> > HTML/XML/HTTP is a poor low level complex way to describe an interface.

> I thought of it as a high level way. I wasn't intending to bring HTTP
> into the picture, only to take an example of an arbitrary UI. Without
> loss of generalization...

If they were high level tools you would have found them easy to use.

> > Are
> > you trying to use a high level tool to model a low level one ? (like
> > implementing assembler in Pascal or Prolog )

> No.

Then you have done that by mistake.

> > One does not need to model all interfaces with RM.

> OK, now we are getting somewhere. In fact one cannot model all
> interfaces using the RM, right?

> > Just the ones at the highest level.

> I'm not tracking on this.

If you need to integrate N high level software components it would be better if all of them would have the same interface (a relational one :-).

> > If you want to use the same model for
> > all interfaces you can always use assembler programming for that.

> Yes, given a programming language as the implementation of a data
> model, I would agree with that. What are other options for that data
> model (and implementations thereof)? One model we cannot use is the
> RM. Languages that implement the RM cannot be used as the exclusive
> language for the user interface. Any disagreement with me on this one
> likely stems from some difference in understanding of <em>data
> model</em> or a common understanding of a data model for an interface.

> SQL is the language used to interface with an RDBMS and the model is
> attempts to employ is the RM. What models can be employed with the
> interface to the user (replace the dbms with a user and model the
> data).

Something based on logic like RM because peoples use proposition when they affirm or deny something in writing.
I would prefer a multimedia communication but the today largely available computers are not able to understand this kind of communication yet.

> > Have you noticed how hard is to write all the HTML&Co code by hand ?

> Very painful, yes. And then I had problems with putting xml in html
> across browser platforms and ended up replacing < with &lt; Ugh!

How is this for a high level language ?

> > Have
> > you noticed how hard is to maintain this code when you have to use
reverse
> > engineering for it ?

> I'm not sure I understand what you mean with that.

This is the same as translating some code to assembler/object code and losing the source.

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

> Did you mean "do" or "do not" in the last sentence?

I mean do. :-) But I don't see yet how this means to completely replace/hide the RM instead of extending it.

I'm only argue with you to show some weak points in your argumentation and hoping to learn something in the process. I'm Gemini, remember ? It seems you are failing to take advantage of the assumptions made by the RM to show its weak points.

Let's give it a try.
Suppose all your relations are all key. Suppose all attributes are complex (0NF). How can one normalize this ?
Suppose all your (lots of them) relations have at most one tuple. How an SQL DBMS would handle that ?
Try to use relational division with an SQL DBMS and see how long it take. And of course your ripple delete :-)

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

> Yes, QBE has its charm.

Unlike HTML&Co who are ugly.
Have you noticed that in MS Access one can use QBE to generate SQL ? HTML&Co are usually used the same way (as a target of some tool).

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

> Dang, I still didn't explain it well. I'm going to have to find new
> ways to say this. The RM is the model behind-ish SQL (for our purposes
> we lose nothing by saying this). SQL is a language to interface with
> the database. We have other needs for interfaces, such as the
> interface with the user. SQL and its model cannot fill the bill there
> if you think of the software using a data model to talk to the UI like
> it uses a data model to talk to the database. It lacks any ability to
> handle the example I gave in the blog.

If the RM can capture the data to be retained for a long time I don't understand why it cannot capture the data from an user interface. There is data in a user interface that cannot be stored in an SQL database ? Even so, what deny us to extend RM to handle that instead of completely hidding or replacing it ?

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

> Again, clearly I will have to come up with a new way to say this.

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

> Data models back interfaces, such as the data model used to interface
> between one piece of software or a human being and a SQL-DBMS. Look at
> the data model behind an arbitrary user interface.

I've looked and I've seen RM ;-)

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

> They don't need to be. However, if you want to use the same data model
> for both, you cannot use the RM.

Why ? ;-)

> But you have read each of my blog
> entries and you are not tracking with me on that point, so I'll keep
> working on how to say it. It is not (yet) an argument against using
> the RM for the interface to large shared data banks, as Codd was
> working on. I am right now showing that it cannot be the data model
> behind a UI. I'm not sure which part of the argument does not resonate
> yet, but I will see what I can do to make it clearer. Thanks. --dawn

Best luck! I hope we will learn something from all that. Received on Fri Feb 10 2006 - 11:43:31 CET