Re: Distributed foreign keys (was Re: Category Types)

"Marshall Spight" <mspight_at_dnai.com> wrote in message news:VfDNa.110647$R73.12405_at_sccrnsc04...
> "Bob Badour" <bbadour_at_golden.net> wrote in message
news:o1pNa.287$_T1.36633719_at_mantis.golden.net...
> >
> > I am not sure how a database algebra would affect the catalog.
Representing
> > types, type generators and operations seems like the tricky part to me;
> > although, I have a few ideas germinating. Type generators seem
particularly
> > tricky because they could instantiate a type that changes the known type
of
> > some value already in the database.
>
> Why would they?

Some type generators would and some type generators would not. Why wouldn't they? If the dbms suddenly knows about a new type, it knows that information about all the values of the type.

> Why should something change its type just because it
> can?

The value does not change its type; the set of known types changes. The value was always a member of the newly instantiated type, but the dbms does not know this fact until it instantiates the type.

> TTM seems to assume this, but never presents a decent argument
> for it.

The type of a value does not change. Logically and conceptually, the value has its type regardless of the types declared to the dbms. Thus the natural number 5 is also a whole number, an integer number, a prime number, a fibonacci number, an odd number, a rational number, a real number and a complex number. When a type generator instantiates a new type, it does not change the types of a value, but it does change the represented knowledge about the types of values.

> This is related to their "most specific type unique" rule, but that
> always struck me as just being there to make implementation of SbyC
> easier.

The most specific type of a value just is--regardless whether the dbms knows anything about the type.

> So value X could belong to either of two possible subtypes; what's the
> problem? If we buy that function *semantics* (as opposed to
implementation)
> for subtypes is the same, then it doesn't matter.
>
> Put another way, why couldn't I have the following types:
>
> T1 = {a, b, c} // a, b, c are values
> T2 <: T1 = {a, b}
> T3 <: T1 = {b, c}
>
> ( The <: operator means "is a subtype of.")
>
> So the most specific type of a is unquely T2, but the value b could be
> of type T1, T2, or T3, and the most specific type is not unique.
>
> So why is that a problem?

Because the value b is a proper subset of T2 and a proper subset of T3 and has a proper superset of the operations of T2 and a proper superset of the operations of T3, it defines a subtype of T2 and T3 regardless whether we name the subtype. Without a name, we cannot easily identify or use the type even though we have defined the type.

Without a known MST, the question: "What is the type of this value?" has no (unique) answer.

If one says: "Well, we could still ask the question and get a relation valued answer." Then I would say that the identifiers for types are relation valued, and the most specific type of b is { T2, T3 } which defines a unique set of values { b } and operations { Operations(T2) UNION Operations(T3 ) }. { T2, T3 } is a direct subtype of { T2 }, of { T3 } and an indirect subtype of { T1 }. Received on Sat Jul 05 2003 - 21:14:27 CEST