Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]

In article <I4Cxe.135796$Bh7.7066690_at_phobos.telenet-ops.be>, jan.hidders_at_REMOVETHIS.pandora.be says...
> > I did not ask for query languages, I asked for operators.
>
> Why would you need them?

To quote myself: "I want to know whether the operators they define (if they do) are logically different from the relational operators, and if so, whether they are orthogonal, sound, closed and complete.

"Syntactical sugar on top of SQL or relational algebra is all well and good---I don't object to raising the level of abstraction in that manner. But that does not mean that the RM is inadequate or 'crippled'---quite the opposite!"

The first query language described in the links you sent me was ConQuer. It is implemented by translation to SQL. The techniques it uses can trivially be applied to a relational database (a TTM-style DB, not an SQL one). It implicitly uses relational operators (or SQL's bastardised versions of them), though Halpin's writing is marred by a failure to distinguish between SQL and the RM (or alternatively, to realise that "attribute-based approaches" can also have proper domain support---it is really just a different point of view).

> >>No. In ORM NOLOTs are abstract. It is more correct to say that the RM is
> >>basically ORM restricted to LOTs. A very grave and crippling restriction
> >>indeed.
> >
> > What does "abstract" mean?
>
> Come on, Jon. I've taught several classes on ORM modelling and even
> bussiness students understood the distinction between LOTs and NOLOTs.
> What is that you find so difficult to understand?

I have a theory that the understanding of your students is nothing but blind acceptance that numbers, strings and booleans are LOTs, and everything else NOLOTs, without questioning the logical difference, the reason for the distinction, or the determination of the boundary between them. If it is so simple, why is it so hard to explain in a precise manner?

> > As I asked earlier: If we renamed the RM terms to match, would it then
> > be an ER-like model?
>
> The anwers is still no.

I then must assume that you think the difference between ER-like and non-ER-like models is the distinction between LOTs and NOLOTs, since that by your own admission is the main (or only?) difference between ORM and RM. And again I quote myself: "In that case, the 'classic' ER model is not ER-like!---it does not speak of identity separate from keys." Or do you disagree?

And I ask you: What difference do NOLOTs make? What can ORM with NOLOTs do that the RM cannot do, that constitutes such a "grave and crippling restriction indeed" on the RM's part? And relatedly, what is non-trivial about mapping ORM to RM? (Note: I'll agree that mapping ORM to *SQL* might be non-trivial, but that is irrelevant.)

> > I note that ORM does not use the term "entity", and
> > that Nijssen and Halpin's original(?) book used "fact type" instead of
> > "relationship type".
>
> Different names, essentially the same concept.

And essentially the same concepts as "value" and "relvar" in TTM. You can quibble over "value" using the LOT/NOLOT distinction, but hardly "relvar". ORM literature even talks about predicates in exactly the same way as Date! (Except that ORM does not seem to realize or care that you then can apply predicate logic to them...?)

I also note that Halpin takes great pains to distinguish ORM from ER--- to the point of apologising for "bashing" ER.

> > Not personally, but what more do you need than definitions of value,
> > domain, tuple and relation, and a minimal set of algebra operators?
>
> The notions of database schema, database constraints, database instances
> and how they are exactly related.

Is your point that this is not needed for formalisation of ER-like models, or that it is simpler to formulate them for ER-like models?

-- 
Jon