Re: foreign key constraint versus referential integrity constraint

On Oct 28, 1:41 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> Marshall wrote:

> > Consider relations A and B each with a single, common attribute.
> > Natural join and inner union will behave much like intersection
> > and union in this case. If the result type of the join isn't an
> > intersection type, then we lose the property:
>
> > A = A join (A union B)
>
> > because the type of the attribute of the expression is different
> > than the type of the attribute of A.
>
> I don't see that you do. The type will be the MST of the resulting join.
> Because you will join A with a supertype of A, the MST will be the same
> as the type of A. This is different from the case joining an integer
> with a string because the MST is the universal supertype.

I agree with Bob, although use of the definite article in "the type" is potentially confusing because a value may have many types (only one of which is the MST).

Properties like

    A = A join (A union B)

are true because it concerns equality of values on the two sides of the equation, and has nothing to do with static type analysis. It is similar to how D&D talk about an ellipse variable that inadvertently holds a circle value when the width and height happen to be equal. Obviously for every A and B, the MST of

        A join (A union B)

will match the MST of A.

> > More generally, the values in the result of a join are the
> > intersection
> > of the values in the operands; why wouldn't the result type be the
> > intersection type?
>
> I am not sure what you mean by the intersection type.

I cannot see any reason not to allow the type system to form a lattice, i.e. for any two given types there is a well defined "union type" and "intersection type".

Static type analysis of an expression containing a natural join could assume that its static type is either the intersection type or the union type of the static types of the operands. I would suggest the former is more useful than the latter because statically typed languages make upcasts implicit and downcasts explicit - so a more specialised static type is favourable.

Of course at "run time" a particular join result (i.e. value) may have a dynamic type (i.e. its MST) that is more specific than its static type. Received on Wed Oct 28 2009 - 06:01:56 CET