Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: The Myth of relational algebra (was Re: Clean Object Class Design -- What is it?)

Re: The Myth of relational algebra (was Re: Clean Object Class Design -- What is it?)

From: Bob Badour <bbadour_at_golden.net>
Date: 8 Sep 2001 13:00:30 -0700
Message-ID: <cd3b3cf.0109081200.517d6127@posting.google.com>


Joseph Bacanskas <jbacanskas_at_home.com> wrote in message news:<w77m7.48168$MK5.27966187_at_news1.sttln1.wa.home.com>...
> Vadim Tropashko wrote:
>
> > In article <9na529$6u5$1_at_wrath.news.nacamar.de>, Adrian Veith says...
> >>
> >>6. Not shown but obvious: Queries are much easier to formulate in an OODB,
> >>than in a RDBMS
> >
> > Thre is a famous example for you to crack: find all managers who earn more
> > than sum of their employees.
> >
> >>Another myth states, that RDBMS are much more effective and quicker than
> >>an OODB. Often this myth is explained with relational algebra and the
> >>possibility to optimize queries in an RDBMS.
> >>
> >>As with all myths, there is true part:
> >>Relational algebra gives you the possibility to transform a query in order
> >>to optimize it.
> >>
> >>Wrong is:
> >>1. That all optimizations of a query are done with relational algebra. The
> >>most common optimization is to use an index. Relational algebra is used to
> >>transform the query to use the index. But the index in itself is not
> >>defined by relational algebra. (Since an index is normally a
> >>tree-structure, it has more in common with an OODB if you want)
> >
> > Not quite: materialized views work much the same way as indexes with query
> > rewrite. They allow to speed up complex queries with joins and aggregates.
> > How can you leverage materialized view technique in OODB without
> > relational closure?
>
> Hi Vadim:
>
> Sorry, I couldn't resist. Code from a system in GemStone/S a Smalltalk
> OODBMS.
>
> This code conforms closely to an in production object model
>
> a Party has a collection of roles. The roles we need are the employeeRole
> and managerRole. Suffice it to say we have an EmployeeCollection. The
> EmployeeCollection implements the message managers, the manager implements
> directReports and the employeeRole implements salary. Employees and
> managers are Party objects with the appropriate Role object(s).
>
> ^EmployeeCollection soleInstance managers select: [ :eachManager |
> (eachManager directReports
> inject: 0 into: [:sum :eachEmployee |
> eachEmployee employeeRole salary + sum])
> > eachManager employeeRole salary]
>
> A fairly typical OODBMS solution to the problem using a Smalltalk OODBMS.
>
> Cheers!

(mgr_payroll | mgr_salary > annual_ee_pay)[mgr]

I assume that mgr_payroll is a view that states facts regarding payroll information grouped by manager. Since your solution presupposes certain methods (message implementations), I assume it is fair to presuppose views of comparable complexity.

I have used the vertical bar as the restriction operator and square brackets to denote projection.

I think it is a fairly typical relational solution. Received on Sat Sep 08 2001 - 15:00:30 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US