Re: object algebra

From: Eric Kaun <ekaun_at_yahoo.com>
Date: Mon, 23 Feb 2004 12:20:56 GMT
Message-ID: <Iem_b.27227$Fz.10943_at_newssvr16.news.prodigy.com>


"Neo" <neo55592_at_hotmail.com> wrote in message news:4b45d3ad.0402222141.3cd35a14_at_posting.google.com...
> > > TDM is a more general model than RDM.
> >
> > Since the RDM is fully general, it seems a difficult task.
>
> RDM isn't fully general. If it is, why does it need NULLs?

It is fully general, and it doesn't need nulls.

> RDM's fundamental design ensures NULLs will occur in some
> applications.

No, it doesn't. Which applications are you talking about?

> IMO, one simple way to judge which data model maybe more generic, is
> to count the occurance of NULLs. The model which utilizes the least
> NULLs is probably more general.

Not sure whether this has any relevance, but certainly the relational community agrees that nulls are a bad idea.

> The presence of NULLs is usually a red
> flag of some type of mismatch (chapter 20 of Date's "Intro to DB
> Systems"). TDM has no NULLs. In theory, RDM can eliminate all NULLs,
> but requires non-standard techniques that are impractical (ie generic
> modelling, where all the data is in one table with one column).

So in what way does TDM eliminate nulls in "standard techniques", whatever that means?

> Another more significant way to judge which data model is more
> generic, is to analyze degree of closure over basic operations
> (intersection, union, negation). Under RDM, closure requires meeting
> rather strict criteria (chapter 6) in comparision to criteria for
> closure in TDM.

What strict criteria? I just finished reading the 8th edition of his book, and have no idea what you mean. What are the "criteria for closure" in TDM? I simply thought closure was a result of operations over type T yielding values of type T.

> NULLs hinder closure which in turn hinders recursion.

Agreed, but relational doesn't allow nulls.

> According to Date's 6th Ed, "missing information is not fully
> understood", "no fully satisfactory solution is known", "incorporation
> into model is premature" but "Codd now regards NULLs as an integral
> part of RDM".

Codd was wrong in that statement, and many relational proponents support the non-use of nulls.

> If we model various data examples, we should find less NULLs with TDM
> than with RDM. For example, modelling 10 persons, each with different
> properties. Or the following problem:

Each with different properties? You're simply talking about an attribute of type PERSON, and the existence of multiple subtypes of PERSON. What does TDM allow you to do with those differing properties?

> Allow user to create any hierarchy of things.
> Each thing in the hierarchy can be of different type/class.
> Each thing can have 1 to many parents in the hierarchy.
> For all possible combinations of 2 children in the hierarchy
> find the closest ancestor.

> A solution to the above using TDM is shown at
> www.xdb1.com/Example/Ex075.asp

It's impossible to tell from that page what's going on.

> Note, that although the example shows a hierarchy of similar things
> and each thing has exactly 2 parents, the solution works with
> hierarchy of different kinds of things with different number of
> parents.
>
> If someone can show a solution for the above problem using RDM, the
> genericness of the models will become clearer.

This seems obvious - I don't have time right now (at least until I see a real explanation of the XDb "example"), but a Thing relation and a ThingParent relation would allow any number of parents as well. Adequate domain support would enable the Thing relation to hold any type you like, including subtypes - and the type could just be ANYTHING. Finding all possible combinations of 2 children is ludicrously simple.

  • erk
Received on Mon Feb 23 2004 - 13:20:56 CET

Original text of this message