Re: An object-oriented network DBMS from relational DBMS point of view

(Unlikely to our numerous "relational" friends, I welcome OP's attempt to annotate RA with types. As I said by many occasions I see no opposition between RA and OO.)

On 11 Mar 2007 12:11:00 -0700, Daniel Parker wrote:

> On Mar 10, 6:11 am, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de>
> wrote:

>>
>>> Lets examine data interfaces more elaborately. Interface implemented
>>> by the row consists of the definition of signatures of methods, which
>>> are applicable to this row, and also of the definition of fields (=
>>> columns) which were inherited by this row from base tables.
>>
>> Forget first about tables. Tables are just unordered sets of rows. You can
>> have different sorts of collections. Unordered set is just one case of.
>>
>> When you want to derive, do it from a type (row). The type of the table is
>> another thing. You can get it from some abstract collection type
>> constrained by the class of rows (=the type of the element). The iterator
>> (index) is another parameter.
>>
>> Nothing in a type system should prevent you to derive from any type. Tables
>> and rows are distinct types. Derivation from a row and from a table are two
>> sufficiently different things.
>>

I think that static typing should not hinder projections. It depends on how tuples are built. If bare aggregation were used then yes, any traces to commonalities between different types of rows would probably be lost. But there is inheritance to make types related, which is in fact the same relation under a different name.

For example: Customer derived from Age, Name, Location, Height.

Let tuples be built using multiple inheritance, as above, then a projection constraint would be a plain supertype:

   Customer_Prj derived from Age, Name.

This supertype might be imaginary, for which reason it is important to have ad-hoc supertypes, which would close the types algebra for the projection for Customer [*]. I.e. we could declare Customer_Prj after Customer as a supertype of, with the properties that it too inherits from Age and Name.

Another important issue is the diamond diagram. Because types would identify the elements of the tuple instead of names as in RA, then the conflicts between them need to be resolved. Type cloning can be handy here, clearly Age and Height are different types even if the underlying implementation type is same. The advantage is that all such conflicts are detected statically at compile time.

Once we have declared Customer_Prj, we will observe that

   Customer_Prj :> Customer

and therefore

   class Customer_Prj contains class Customer

So any operation defined on Customer_Prj would work on Customer (let LSP put issues aside, for awhile)

Having finished with tuples we are ready define a projection operation on the containers of Customer yielding containers of Customer_Prj. This is rather trivial, of course all base types of Customer have to be comparable [**].

A more interesting problem is parallel types hierarchies, like when the container of subtypes would be a subtype of a container of the base type. But if the projection operation would have a syntax sugar, that would not be an issue.

• As for closed types algebra, clearly the projection operation cannot be defined on *all* types. Neither it is in RA! For example, what is the projection of Integer? Nor it is required, provided there is an identifiable class of types which have this operation defined.
  • Actually this is too strog, The requirement is that Customer_Prj would be comparable. If all bases have "=", then Customer_Prj's "=" can be generated. If they don't the compiler will ask the programmer to define and implement it. And surely one should be able to override "=" of Customer_Prj before making a projection!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de