Re: Relational vs. PICK/Object DBMS

From: x <x-false_at_yahoo.com>
Date: Wed, 21 Apr 2004 17:35:07 +0300
Message-ID: <408685f2$1_at_post.usenet.com>

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

"Albert D. Kallal" <kallal_at_msn.com> wrote in message news:Ksuhc.183598$Pk3.21287_at_pd7tw1no...
> First, you want to understand that a Multi-Valued system (pick for
example)
> is NOT to confused with a object dbms.

I'm sorry for putting Object and PICK DBMS together, but I have worked only with RDBMSs.
I am interested if other DBMSs are better on queries similar to the ones in my post.

> I like the link you gave us. The tables defined in that link are:
>
> employee' (man#, name, birlhdate)
> jobhistory' (man#, jobdate, title)
> salaryhistory' (man#, jobdate, salarydate, salary)
> children' (man#, childname, birthyear)

This example does not fit the problems I stated because there are only a few relations (4 of them).

> Lets use the above. This makes the whole discussion easier when we have a
> set of defined tables already!
>
> Given the above:
> >
> > 1) Suppose you have a bunch of attributes that describes the entities
in
> > your database.
> > Suppose any attribute is optional for any entity.

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

Here I think I made a mistake using the word ANY instead of EVERY. I intended something like:

select employee.man#, employee.Name, salaryhistory.salarydate, children.birthyear
from employee,salaryhistory,children
where employee.man#=salaryhistory.man#
AND employee.man#=children.man#

but notice that we have to supply 3 (possibly long) lists:

- one for the attributes
- one for the tables
- one for the AND constraints

and this perform poorly on some RDBMSs.

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

> Hum, the above is not quite clear. When you say "find"...do you actually
> mean just show the child records? In a mv system since we have no
> joins..then you just list the fields in your query.

This is similar to a) but instead of supplying the list of attributes, we supply the entity (man# in the example) and - ask what attributes apply to it .
- ask what are the values for the above attributes

For a relational solution, this would imply the use of the RDBMS catalog. This means that the solution would require the use of dynamic SQL or other language.

For this schema
> employee' (man#, name, birlhdate)
> jobhistory' (man#, jobdate, title)
> salaryhistory' (man#, jobdate, salarydate, salary)
> children' (man#, childname, birthyear)
the attributes for a given man# are:

- name
- birthdate
- jobhistory(jobdate, title, salaryhistory(salarydate,salary))
- children(childname, birthyear)

but this does not match the problem because - not all attributes are optional
- there are only a few number of attributes

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

• 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 - 16:35:07 CEST