Re: OO versus RDB

From: Bob Badour <>
Date: Wed, 28 Jun 2006 20:58:36 GMT
Message-ID: <04Cog.3422$>

Christian Brunschen wrote:

> In article <eZxog.3346$>,
> Bob Badour <> wrote:

>>Christian Brunschen wrote:
>>>In article <>,
>>>erk <> wrote:
>>>>topmind wrote:
>>>>>[...] (Unlike OO, where encapsulation
>>>>>encourages each object/class to reinvent its own
>>>>>add/change/delete/cross-reference/search rules and interfaces so that
>>>>>they are all different for each project or shop.
>>>>Agreed. I wouldn't have a problem with inconsistencies if the languages
>>>>just offered some powerful basic operations. You can't even write
>>>>something in Java like this, which would be completely type-safe:
>>>>Set<LineItem> items =
>>>Perhaps somewhat interestingly, in a dynamic OO language such as 
>>>Smalltalk, Objective-C or Ruby, you can use the technique of Higher-Order 
>>>Messaging (HOM), as described in the 2005 OOPLSA paper 
>>><>, to do 
>>>something quite similar; in Objective-C syntax something like
>>>  NSSet *lineItems =
>>>    [[[[order lineItems] selectWhere] status] equals:STATUS_SHIPPED];
>>You have given an example involving only restriction. 

> If I interpret things correctly, this is what is called 'selection' in
> some places (suh as <>
> and <>)?

Suggesting a synonym for restrict does not answer my question. The relational algebra also has union, join, project, extend, quantification etc.

>>Does the method work for project, extend and join as well?

> Caveat: I am an OO developer, and use relational databases a lot, but I
> there is a lot of precise terminology with which I am not conversant, and
> I *will* make mistakes. but they will be just that, mistakes.

[lengthy example using objects, dictionaries, higher-order-methods snipped]

In the case of a join it could be argued whether the
> result should be a set of NSDictionaries containing just the attributes
> extracted from each joined pair of objects (i.e., trying to emulate as
> closely as possible the real relational model), or something like a set of
> pair of objects, where each such pair would simply identify the objects
> fromthe original A and B sets that were thus joined together (since we
> are, after all, working with objects rather than tuples). Of course, we
> could simply offer both operations and let the programmer decide which is
> appropriate to use.

With all due respect, you have just broken one of the most fundamental properties of the relational algebra/calculus: closure. (Actually, you have proposed two alternates that both break closure.) I cannot stress enough the importance of closure and nesting. Without that, your proposal falls flat.

> I am uncertain what the 'extend' operation is that you refer to; I didn't
> recall it from my database classes at university, and googling for
> 'relational algebra extend' doesn't seem to give anything that seems
> immediately enlightening. Would you care to elucidate?

Extend derives new attributes from existing attributes. Thus given a relation including a date_of_birth attribute, one might derive a new relation that extends the original relation with an age attribute. Received on Wed Jun 28 2006 - 22:58:36 CEST

Original text of this message