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

"Bob Badour" <bbadour_at_golden.net> wrote in message news:o1pNa.287$_T1.36633719_at_mantis.golden.net...
> I apologize for the length and meandering nature of the following. It
> represents a train of thought that has to back off a couple of dead-end
> sidings.
>
> 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.

Types and Operators look reasonably easy to me. Briefly,

A type is defined by a relation (a relational constant, aka relcon) in the catalog with one set of attributes for the components of each possible representation of the type, and with one tuple for every value of the type. A subtype is a view over the supertype's relation with a restriction that corresponded to the definition by constraint of the subtype, and optionally an extension expression that defines sets of attributes for any possible representations unique to the subtype.
The relation names could be used as the type names. Poss representation names might have to use some attribute name prefix scheme, or some other metadata relation that says which attribute names are part of which possible representation. Each set of attributes that are the components of each poss representation would define a candidate key on the relation. Further, instead of enumerating all the values of a type in a relation literal, types can alternatively be defined by a named relational expression, probably over the relcon(s) of the components of the possible representation of the type.

Operators are again relation constants or views in the catalog. The relation name can be used as the operator name. A convention such as the attribute with either a standard name such as 'result' or as the same name as the operator could distinguish the operator result from the operands. Any operators that are functions would have a functional dependence constraint on their catalog relation. Functions that have properties such as being commutive, associative, reflexctive, identity etc would have corresponding relcon constraints.

So those two seem a lot easier to get a grip on compared to the ideas around database algebra (as I think you nicely demonstrated ;-)

Type generators? Maybe 'meta programming' has something to say on this one. Not sure.

P.S. I've not gone all that far down the database algebra path, although one thing does look clear; that it works better if relvar names are dropped. Maybe I'll post my ideas here, although as I said I'm not sure that this newsgroup is the ideal outlet. Is there a sourceforge.net for logical models???

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Sat Jul 05 2003 - 23:45:38 CEST