Re: Modelling Disjoint Subtypes

On Mar 22, 4:19 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:

>

Yeah, we've mentioned this in the past.

type T = {subtype1, subtype2}

P(id, t:T, ...) -- Parent table has id, t of type T, and other columns
S1(id, t:T, ...) -- Subtype1 table has id, t of type T, and other columns
(S2 omitted)

Constraints on P
  primary key(id, t)

Constraints on S1

  constraint c1: primary key(id, t)
  constraint c2: t = subtype1
  constraint c3: foreign key(id, t) references P(id, t)

  constraint c3: foreign key(id, t) references P(id, t)

Having declared to the system that the type of S1.t is a unit type (meaning the type has exactly one value) the system is free not to store anything for the t column. This is possible because the number of bits needed to represent a value of a given type is the log2 of the number of possible values. Since T1 has 1 value, the number of bits needed is log2(1) = 0.

So the system can use 0 bits to store values of type T1. (Of course, it will need zero bits for each row, so we have to multiply the 0 by the number of rows to determine the total cost for the relation.)

Something else that's occurred to me since is that the constant doesn't necessarily have to be considered part of the relation; it could instead be considered part of the constraint.

type T = {subtype1, subtype2} -- T is a type with two values

P(id, t:T, ...) -- Parent table has id, t of type T, and other columns
S1(id, t:T, ...) -- Subtype1 table has id, t of type T, and other columns
(S2 omitted)

We can combine c1 and c2 to rewrite the primary key   constraint c1': primary key(id)

We can combine c2 and c3 to rewrite the fk that enforces the subtype relationship.

  constraint c3': foreign key(id, subtype1) references P(id, t)

Expressing c3' in predicate calculus:
  forall S1(id): exists P(id', t): id = id' && t = subtype1

An amusing Saturday morning post-pancake diversion.

Marshall Received on Sat Mar 24 2007 - 20:13:12 CET