Re: Possible bridges between OO programming proponents and relational model

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 Sun Jun 04 2006 - 11:41:32 CEST