Re: Argument for 1NF by counter-example

"Marshall Spight" <mspight_at_dnai.com> wrote in message news:<eqGgd.23408$HA.19911_at_attbi_s01>...
> "Tony Douglas" <tonyisyourpal_at_netscape.net> wrote in message news:bcb8c360.0410281320.496ab93a_at_posting.google.com...

Hi Marshall,

<agreeable snip>

> If we are talking about *typed* relations (and we pretty much always
> are, but untyped relations are possible) then relations may be
> relations across any number of any type. In other words, relation
> is a type generator, that is parameterized by zero or more attribute
> types. Which is to say, relation is parametrically polymorphic,
> with the attribute types being the parameters.
>

Ok, relations as type generators - I like that.

> With such a powerful facility at the core, it's not clear to me
> whether any *further* parametric polymorphism is necessary.
> After all, pretty much 100% of the example uses of parametric
> polymorphism are container classes. Do we need parametric
> functions or modules if we have relations? Dunno.
>

If I'm thinking of a programming language that happens to do relations, it's not totally evident to me that everything that I might want to write in that language would deal with relations. Apart from which, why throw something away ?  

> I'm strongly against 3VL, but I have a slightly different take.
> In my mind, "missing" information is different than any
> of the other things that 3VL is usually used for, such as "N/A"
> or what have you. I think of missing information as a cardinality
> issue; the data is merely absent, as opposed to using a special
> marker, such as one might use for N/A or NAN.
>

Hmm. I'm not sure on this; I would probably tend to have an alternative in my data type definition which says the data is absent. Roy H knows someone who can come up with about 50 different interpretations for NULL, which could make for some very broad data definitions... ;)  

> There was a very interesting paper out of MS Research a few
> years ago, "Unifying Tables, Objects, and Documents."
>
> http://citeseer.ist.psu.edu/577443.html
>
> I'm not thrilled with everything in the paper (they have XML on
> the brain, like almost everyone else these days) but there was
> one thing that really stood out for me, which was their
> cardinality annotations, which can be verified statically. That is,
> you could say of a int variable that it had either 0 or 1 int
> values in it, which would roughly correspond to SQL's NULLABLE.
> Or you could indicate it had exactly 1, or zero or more, or 1 or
> more. Pretty cool.
>

Ah, you were going well until you said the "c" word :) I'll try taking a look at that sometime soon.

> > Well, Prolog is a start, but it would need several issues sorting
> > before progressing, the main two being the ordering of functor
> > arguments and the ordering of facts/clauses affecting the evaluation
> > of a predicate. Types would be nice too ;)
>
> [Did you mean "sorted out" instead of "sorting"?]
>

Yes. Sorry.  

> Yes, being able to assert facts more than once, and having the
> order be significant is just wrong. Still, the idea of having rules
> in the language is a good one.
>

Indeed. I think there are possibilities here, but a lecturer friend of mine has had a long running undergrad dissertation proposal for adding some sort of type system to Prolog, and is becoming increasingly certain that types and Prolog don't really mix. Unfortunately, the order of evaluation comes out of the execution model for Prolog. Eventually we'd probably have to replace so many bits of Prolog that the Prolog-ness will probably go away too.

> This sort of gets back to the part about relational algebra at the
> start of this post. I would like to see an operator like <OR> from
> TTM's A algebra. In fact, I have a vague idea for a framework
> for describing all possible relational operators, analogous to
> the complete set of 16 boolean operations. (Although there
> are more than 16 for relations.)
>
> I tend to shy away from <NOT>.
>

Thanks for the clarification. The time is coming when I'll have to buy a copy of TTM, I fear.

<snip>  

> > Firstly, the object oriented languages don't seem to agree on what
> > *precisely* an object is; the views of say, Java, C++, Simula and
> > Smalltalk seem to differ, albeit sometimes subtly, on this.
>
> I dunno; I think this whole line of argumentation is a snow job from
> the dbdebunk camp. In some ways it is a *good* thing that the OO
> languages each have their particular semantics; it's a sign that the
> field is vital and active, and trying out new ideas. In contrast,
> relational languages are stultifyingly stuck under the mighty thumb
> of SQL.
>

It may be a good thing that they disagree with each other if you like an empirical model of things (ie. "chuck some stuff at the wall and see what sticks") but it means you can't really have a general purpose object database; you could have a C++ object database, or a Smalltalk object database, but putting a Smalltalk object in a C++ database might end up with some interesting issues.

(I can understand the point about dbdebunk, and yes I am a reader and purchaser of papers. But my fundamental wariness of object orientation goes back before I started dealing with databases to about 1987, and to a 1984 book by David Harland called "Polymorphic Programming Languages", published by Addison Wesley, which was the starting point for my undergrad dissertation.)

> And in fact, the basic idea of what an object is is fairly clear; it's
> a data structure with both a value and an identity, and an
> associated dynamic dispatch mechanism. The details vary,
> but AFAIK all "OO" languages have these features.
>

But then, some have "everything" is an object; some have "most things" are objects; some discern between "mutable" and "immutable" objects and others don't, etc. etc. etc. The devil is, as ever, in the detail.

> Furthermore, the specific semantics of each OO language are
> quite well nailed down; there is little or no fuzziness in the
> Java spec, or the C++ report, etc.
>

Hmm ! When I see some denotational semantics for them, then I'll agree with you. For the moment, I'll restrict myself to "hm!" (Although there might be some operational semantics for Java out there. Anything involving C, as C++ does, is on shaky ground though.)

>
> > If they
> > can't agree on what an object is/means, how can we agree on what it
> > means to store an object in a database?
>
> Why do we have to agree? Why can't we try out lots of different
> ideas and see which ones work best?
>

There has to be *some* sort of theoretical model behind all this; if there isn't then it's just experimentation in the vague hope of finding an answer. And if you're not sure what the answer is, how do you know when you've found it ?

Something solid must direct the experiments, and we're probably better off critiquing the "something solid" before expending effort on the experiment. Or worse, unleashing the experiment on an unsuspecting public and asking them what works (for some vague definition of "works").

>
> > Also, the objects have, for
> > me, a very particular application - modeling dynamic interacting
> > processes. What does it mean to store one of these things in a
> > database? If we're using them for, effectively, abstract data typing,
> > then there are better, simpler, more conceptually robust answers than
> > object orientation for that.
>
> As far as what makes a good abstract data type mechanism, I'd
> say objects are it. They've pushed out every other way of
> doing things, and with good reason.
>

Think about most things in IT that have achieved dominance; have they done it for good reason ? And following on from the point you make below, why bother with objects in databases ? Are we doing anything with them that we couldn't do with abstract data types in Modula-2 or Ada ?

> As to the question of what it means to store an object in a database,
> the only real question is what do you do about variables inside
> objects, and pointers. And I don't think it's out of the question to
> say that they just get flattened, and go away, subsumed by the
> "variable-ness" of the database itself, in which case
> the answer is very simple indeed.
>

Yes. They stop being objects and become ordinary, if complex, values.

Cheers,

• Tony