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

Paul Vernon wrote:
> "Bob Badour" <bbadour_at_golden.net> wrote in message
>
> 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???
>

Don't worry, you're already on the wrong path (provably going into a dead end with no result). Basically you will end up rewriting set theory when what you need is type theory. Types are not sets nor are they predicates. For sets and predicates we already have, well, sets and predicates.

In order to avoid this trap you have to ask yourself what is the purpose for which you want to construct a type system.

It seems to me you are trying to do it the other way around, meaning to approach from the platonistic ideals that there are some eternal truths about mathematics that you'll want to discover. So you risk ending up in the eternal all circles are ellipses problems. You have to look the other way around: you can construct any formal system you want as long as it have the properties needed for you to solve problems. Types as you defined them above (or even as Date defines them in TTM) are not particularly useful, since they don't have certain desirable properties while they have certain undesirable properties.

The ultimate judgement on any formalism is how effective it is in solving a particular problem or a class of problems. As such, trying to attack the theory of types without having a problem in mind is not going to bear fruits. So again, rather than thinking on "what types are " you should be thinking on "what [my unspecified] types could be useful for".

You might also give it a try with introductory papers such as "type systems" by Cardelli or Naive Type theory by Constable and of course the wonderful book Types and Programming Languages.

> Regards
> Paul Vernon
> Business Intelligence, IBM Global Services
>
>

Best,
Costin Cozianu Received on Sun Jul 06 2003 - 02:09:24 CEST