Re: Introducing PlayDB (The Model, The Language, The DBMS)

"Bob Badour" <bbadour_at_golden.net> wrote in message news:<ZvCdnetWkJcDhxuiU-KYvw_at_golden.net>...
> Read Date's and Darwen's _The Third Manifesto_, the book and not the 1995
> paper, for a sound type inheritance model.

Thanks, Bob. I was able to find the relevant chapter here: http://www.hughdarwen.freeola.com/TheThirdManifesto.web/CHAP13.pdf And a presentation based on the same topic: http://www.hughdarwen.freeola.com/TheThirdManifesto.web/taamoti.paper.pdf

The scheme seems too rather complicated :-( but I am looking at it still.

What I am considering here is to get rid of the notion of type inheritance altogether and allow each object to simply be (or not be) a member of any combination of recognized classes as long as it satisfies basic requirements of each class it wants to a member of.

One implication of this is that object creation queries will not be of the form INSERT RELATION_XXX SET ATTRIBUTE = .... Instead it will be like CREATE OBJECT WITH ATTRIBUTES .... ... ... [MEMBER OF CLASSES PPP, QQQ, RRR]. Objects are inserted into "the system" and not into tables.

In the relational model the attributes served as means of differentiating one tuple within a relation, but in the model I am tending towards the attributes of an object must be able to differentiate it from all other objects on the system. That's a challenge.

Looking at a class as simply a subset of objects in the system, if it can be implemented efficiantly, offers maximum flexibility and yet we can still create an inheritance model (hierarchical or DAG) by defining certain _constraints_ such as:
A. "every object that joins class CIRCLE must also join class ELLIPSE" B. "every object in MANAGERS should also be in EMPLOYEE"

So if the company now takes up a policy of allowing non-employees to be MANAGERS no problem. We simply drop rule A. If Mathematicians redefine an ELLIPSE to no longer include CIRCLE we simply drop rule A and tell every CIRCLE to no longer be an ellipse.

Of course this means in the implementation special structures to store info about which object is in what class would be necessary. But I think its a more natural model of reality.

Since types are dynamic, it turns out that the only way to point from one object to the other is to have an typeless pointer. I will reread some article I stumbled accross about what's wrong with OIDs. Yuck. With this "dynamic typing" maintaining indices will be very messy.

I am also thinking of reducing most joining/querying to a process of class definition.

Instead of select * from EmpTable where department = "home"; I may simply define an Employees_at_Home class and add all employees at home to that class and set up rules that automatically add newly created employees to the class when their department = "home" and remove them when the case is different.

Seun Osewa Received on Fri Oct 10 2003 - 10:01:17 CEST