Re: Foreign superkey support

Marshall wrote:
> paul c wrote:
> >
> > Perhaps all I'm saying is that the basic relational algebra doesn't need
> > a foreign key concept which I admit is a deviation from the specific
> > question.
>
> I don't think of constraints as being part of the algebra per se.
> Constraints
> are a useful mechanism for ensuring integrity of variables, whereas the
> algebra is a way of constructing values from other values. (Including
> the values in variables.) Note that the algebra is what you do queries
> with, but constraints are relevant only when doing DML: insert, update,
> delete. (Although we may use the algebra to construct values that
> we then insert, for example.)

I don't know whether constraints are part of the algebra, but it's easy to see them as helping to define a domain - albeit a domain understood by the DBMS rather than entirely defined by the user.

These constraints are on a database variable (dbvar), defining what sets of relation values are valid for the database variable's relvars; any foreign key constraints is of this type. You can (although perhaps uselessly) think of a database value (dbval) as a single-tuple relation, where each attribute is the value of a relvar, and the heading defines the type of each constituent relval.

Some database constraints restrict only the domain of tuples allowed in a specific relvar, so are relation constraints (i.e. they are expressions over only the attributes of a single relvar). Other more specific constraints are type constraints and attribute constraints (expressions over a single attribute or attribute type).

I think all of this is orthogonal to the algebra - unless perhaps there's a higher-order algebra to define relational models? This is all too heavy for me right after lunch... pardon the mental gas.

> It is quite interesting to consider the idea of constraints as
> descriptive entities for values, in addition to being prescriptive
> for variables. We can then consider propogation of these
> descriptions through the algebraic operations.

I think that if you consider constraints as part of the definition of a database or relation type, then you're in the semantic vicinity of system catalog operations. Are these then "higher-order" in some sense?

Again, pardon the mental flatulence.

> Frankly I think there's too much emphasis on foreign keys. I
> think we should emphasize the use of domestic keys wherever
> possible, and use foreign keys only when the domestic variety
> is not available.

I prefer to use the term "homeland keys."

Offshoring is the future, though - I'm told you can define and enforce something like 5-10 foreign keys for the cost of a single domestic key. Ergo, ipso fatso, foreign keys are better.

Maybe we should just replace all those keys with RFIDs, so we can track the pesky tuples as god intended.

• erk