Re: Multi Valued Interface Models?

From: dawn <dawnwolthuis_at_gmail.com>
Date: 10 Feb 2006 12:03:04 -0800
Message-ID: <1139598896.676278.14030@g44g2000cwa.googlegroups.com>

x wrote:
> "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.

A complete model? Maybe we need to look at what a model is. A model is a metaphor or a, well, model of the real thing. It is not the real thing. A model car doesn't usually have a working engine. It might not have working brakes or even any brakes.

> HTML and XML are not UML.
> I don't think UML is generally acceptable.

Nothing is completely acceptable everywhere. Prototypes might come as close as possible to be generally acceptable, but you always get comments about how it is not a "complete prototype" which I gather would be, well, the final product. What diagramming specification is more commonly accepted than UML? That is not a rhetorical question. I'd be happy to use something else for showing a diagram of a logical model of data.

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

I am looking at what data models could be used for modeling the data. In the case of a UI, you cannot model the exact data in the interface using the RM.

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

So Dreamweaver and GoLive are high level tools and HTML is a low level tool? OK. I use GoLive and only bring up the source code panel and code raw xhtml. So, perhaps mid-level for the html and xml.

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

Sorry, x, I'm just not tracking with you.

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

I agree on the first part. I don't see how that would be possible using the RM, however. How could you specify an arbitrary UI, such as the example I gave, using the RM?

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

Yes and I think that is good. I want to model a proposition of

I would like a pizza with pepperoni and sausage on it

like this

I would like a pizza (foodItem) with pepperoni and sausage (toppingList) on it.

with a predicate

I would like a <foodItem> with <toppingList> on it.

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

OK. Yes, no fun.

> > > 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 don't care how you get there, but the RM as implemented and used today is what I think needs to be different. It seems to me that as soon as you remove 1NF as originally defined, you have something other than the RM. But if we add in relation-valued attributes, then one thing we are missing is ordered lists. We also need a 2VL (yes, yes, I'll agree that is outside the scope of the RM so from a theory perspective you can have this and SQL Server might even have a switch to permit use of it with a 2VL?)

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

I didn't recall that, but I can handle a Gemini ;-)

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

The question is not whether it can capture the data, but whether it can be the model behind the interface, which would mean that an implementation of that model could be used to code the interface.

> There is data in a user interface that cannot be stored in an SQL database ?

Suspend all thoughts of storage from your mind in this discussion. This not about persisting data using a data model, but providing a UI with a data model. It is the interface that uses a language whose abstraction is a data model. So I'm talking about the data model OF the UI.

> Even so, what deny us to extend RM to handle that instead of completely
> hidding or replacing it ?

I am not opposed to set-based processing, so if you want to call it changes to the RM that's fine with me. Once you hide it, however, you are no longer using it as the model for the interface.

> > > > 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 ;-)

Can you sketch an RM-based language (that is, an implementation of the RM) where using only this language, you could output a web page from the UML class shown?

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

I'm working on how to state the argument another way. If anyone has suggestions, please jump in.

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

I'm sure I will. Already I have learned I am stupid and ignorant (if you are a follower of Fabian Pascal you might have read that). smiles. --dawn Received on Fri Feb 10 2006 - 14:03:04 CST