Re: OO versus RDB

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Wed, 28 Jun 2006 20:58:36 GMT
Message-ID: <04Cog.3422$pu3.83147@ursa-nb00s0.nbnet.nb.ca>

Christian Brunschen wrote:

> In article <eZxog.3346$pu3.80765_at_ursa-nb00s0.nbnet.nb.ca>,
> Bob Badour <bbadour_at_pei.sympatico.ca> wrote:
>

>>Christian Brunschen wrote:
>>
>>>In article <1151501485.755962.108350_at_p79g2000cwp.googlegroups.com>,
>>>erk <eric.kaun_at_gmail.com> 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 =
>>>>theOrder.lineItems.where(item.status==Status.SHIPPED);
>>>
>>>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 
>>><www.metaobject.com/papers/Higher_Order_Messaging_OOPSLA_2005.pdf>, 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 <http://en.wikipedia.org/wiki/Generalized_selection>
> and <http://www.cse.ohio-state.edu/~gurari/course/cse670/cse670Ch4.html>)?

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 - 15:58:36 CDT