Re: Relational vs. PICK/Object DBMS

From: x <x-false_at_yahoo.com>
Date: Wed, 21 Apr 2004 11:13:49 +0300
Message-ID: <40862c96_at_post.usenet.com>


  • Post for FREE via your newsreader at post.usenet.com ****

"Ross Ferris" <ross_at_stamina.com.au> wrote in message news:26f6cd63.0404202228.3244c15c_at_posting.google.com...
> For the sake of someone like me that lacks the rigour to readily read
> your relational set notation, could you possibly restate the problem
> at hand in English, which tends to be the language of choice of my
> users (and me!)

I will try, but you will have to excuse my english, because it is not the language of choice for me.

> Can you map this to a real world requirement, or is this an obtuse
> theoretical device that has little relevance to the everyday world of
> the programmer that you are trying to measure the productivity of, as
> your relationships would surely be part of the DBMS in the first
> instance (though become relevant in some environments when trying to
> optimise an arbitrary query against Rik(A,Aik)

Sorry for the notation. I will try to restate the problems in English.

  1. Suppose you have a bunch of attributes that describes the entities in your database. Suppose any attribute is optional for any entity.
  2. For a given set of attributes - find all the entities that for any attribute in the given set have at least one value. - also find the values of the given attributes
  3. For a given entity - find all the attributes that have at least one value for the given entity - also find the values of the attributes for the given entity
  4. This problem is maybe "an obtuse theoretical device that has little relevance to the everyday world of the programmer" as you said.

There are relations for which normalisation is impractical. See http://www.acm.org/classics/nov95/s1p4.html

Citation:

"If normalization as described above is to be applicable, the unnormalized collection of relations must satisfy the following conditions:

  • The graph of interrelationships of the nonsimple domains is a collection of trees
  • No primary key has a component domain which is nonsimple.

The writer knows of no application which would require any relaxation of these conditions.
Further operations of a normalizing kind are possible. These are not discussed in this paper."

I am interested to find if someone knows an application that "would require a relaxation of
these conditions" and if there is a DBMS that can handle these relations in an efficient manner.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

  • Usenet.com - The #1 Usenet Newsgroup Service on The Planet! *** http://www.usenet.com Unlimited Download - 19 Seperate Servers - 90,000 groups - Uncensored -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Received on Wed Apr 21 2004 - 10:13:49 CEST

Original text of this message