Re: Possible bridges between OO programming proponents and relational model

From: Cimode <cimode_at_hotmail.com>
Date: 16 Jun 2006 12:47:44 -0700
Message-ID: <1150487264.780172.150490_at_h76g2000cwa.googlegroups.com>


As I was suspecting...

The non response from BB to the posts made totally proves my point. I rest my case... His attitude was clear response to all questions I was asking myself...

I will make a pleasure debunking his and his peer's incoherence in future posts.

Cimode wrote:
> Alvin Ryder,
>
> Thank you for helping adress this complex issue...
>
> //Actually the relational model (RM) allows for and expects "user
> defined
> types", a user defined type without operators is useless so it also
> expects user defined operators. Operators are also called functions or
> methods and that is what OOP proponents refer to as "behavior".//
> I am not convinced functions and methods are sufficient to adress the
> RM issue of RTabme representation and manipulation. Operators are just
> a part of what a data type is. My understanding is that *behavior*
> (through methods and functions) may address the issue of manipulation
> but not sufficiently the issue of adequate representation of relvar.
> SQL table on the other hand address the representation in a clear but
> limited manner.
>
> Data+code.
>
> // But most commercial DBMS don't make it easy to create user
> (programmer)
> defined attribute types. You can easily use the vendor supplied types
> but defining your own is another story. However this limitation was
> never imposed by the RM.// Yes no doubt about that. Limitation comes
> clearly from current implementation of SQL. My guess is that this
> limitation is bound to the current in memory addressing schemes that
> fail to represent and therefore to manipulate adequately relvar. What
> kind
>
> //In earlier editions of "Introduction to Databases ..." he uses the
> word
> "atomic" and gives clear examples where a Set is *not* allowed as an
> attribute (column). The set elements {A, B, C} had to be "decomposed
> and normalized.//
>
>
> But later, in books like "Database in Depth", this definition was
> "clarified" - "domains are types", now you *can* have an attribute
> (column) of type Array, Set and whatever else. As long as you only
> have
> a single value or instance of a type like Set it's OK.
>
> For example: Set instances like {A, B, C} are allowed in a column,
> other tuples (rows) might have {A, B}, {A}, {} in that same column.
> But
> none can have {A, B, C} + {X, Y Z} because that isn't a /single/ value
> or instance.
>
> You can even have an attribute of type Relation and plug an entire
> relation into an attribute (RVA). Now since we already have operators
> to handle relations why not allow it to be decomposed?
>
> I hope it can be seen this "reclarified" definition is no small step
> in
> bridging OOP and the RM. If you use relational keys instead of in
> memory pointers, in theory, you now have enough to support "object
> based" programming (ie OOP with no inheritence)!
>
> In "The Third Manifesto" we go one step further, sub-types are covered
> which opens up the inheritence door as well.
>
> In practice most people I've encountered are stuck on the earlier
> "Intro to databases" definitions, they'll get a shock when they see
> ADT's in SQL 3. But all SQL aside, in theory the gap between OOP and
> RM
> is much smaller.//
>
> Yes. What would be the consequences onto defining physical schemes in
> memory. How should these look like to optimize decompositions and
> normalization? At present time most RAM are cut out in Row/Column
> Adresses and the 64 bit architectures tend to add Memory Blocks
> addressing schemes. What correlations are possible into representing
> RTables (logical tables)?
Received on Fri Jun 16 2006 - 21:47:44 CEST

Original text of this message