Subtyping as an alternative to references

From: Cimode <cimode_at_hotmail.com>
Date: Wed, 25 Jul 2007 14:21:36 -0700

Hi,

I have given some thought about what characteristics a relational language have when considering that it should support some form of subtyping and what would be the consequences of such support.

For instance, considering relation R0: {A1, A2, A3...AN} of tuples noted 1 to N from which R1{A1, A2, A3...AN} restricts by constraints tuples M1 to P1, such as M1 > = 1 and P1 < = N. A unique set of constraints noted C {c1, c2, ...cN} carrying on attributes {A1, A2, A3...AN} allows such subtyping.

When you think about it, type defined as R1 is a subtype of type defined by R0 (set of all possible tuples)..From that, comes the idea that subtyping can be described as restricting with a *unique* combination set of constraints .

Now it's interesting to define R1 as having a M:1 cardinality to R0 such as by using a the superkey {A1, A2, A3...AN} *only*...Considering that, it somehow brings the idea the concept of foreign key in R1 may be defined differently.

For instance, defining R1 as being of type R0 associated to set of constraint C helps defining a foreign key without the pointer inspired approach. So I start thinking about the following grammar to define the relation R1 and implicitly creating a reference.

First the possibility to create a unique set of constraint applied on a specific set of attributes:

CREATE CONSTRAINT_SET C AS
{A1 > 20 AND A1 < 200}
{A2 <> 'A' AND A2 <> 'B'}

...
{AN <> 'A' AND AN <> 'B'} --> one could of course generalize such
concept considering A1 to AN as unary relations with user defined operator...

then subtyping could be obtained declaratively as

CREATE RELATION R1
{TYPE R0 WITH C} The above line would indicate that R1 defines a subtype if R0 by application of CONSTRAINT_SET C. The advantage of such approach is that one could define REFERENCES more explicitely and allow operations between set of constraints...

For instance, consider 3 relations for a system tracking incidents that have been first opened then treated and finally closed. Such relations would be (using only superkeys)

```INCIDENT_OPENNED{INCIDENT_NUMBER, DATEOFOPENNING},
INCIDENT_TREATED{INCIDENT_NUMBER, DATEOFOPENNING, DATEOFTREATMENT} and
INCIDENT_CLOSED {INCIDENT_NUMBER, DATEOFOPENNING, DATEOFTREATMENT,
```
DATECLOSED} as one can see each relation is derived from one another by applying a new set of constraints...An incident closed was necessariliy treated and an incident treated was necessarily openned at some point in time...

In this case, one could define a subtyping as

CREATE CONSTRAINT_SET C1
AS {DATEOFTREATMENT > DATEOFOPENNING} CREATE CONSTRAINT_SET C2
AS {DATEOFOPENNING > DATECLOSED} CREATE RELATION INCIDENT_TREATED AS TYPE INCIDENT_OPENNED WITH C1 CREATE RELATION INCIDENT_CLOSED AS TYPE INCIDENT_TREATED WITH C2 OR alternatively...

CREATE RELATION INCIDENT_CLOSED AS TYPE INCIDENT_OPENNED WITH (C1 + C2)

The question is what would that bring extra to simply using REFERENCES. Well for one, it would allow centralize constraints expression and allow reutilization for several purposes. For two, it would add some serious expressive power to decomposition.

I am curious about your thoughts on that... Received on Wed Jul 25 2007 - 23:21:36 CEST

Original text of this message