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

.

Relevant Pages

  • Re: Foreign superkey support
    ... I don't think of constraints as being part of the algebra per se. ... database, and while their enforcement during DML operations is critical, I ... Frankly I think there's too much emphasis on foreign keys. ...
    (comp.databases.theory)
  • Re: Foreign superkey support
    ... I don't think of constraints as being part of the algebra per se. ... Frankly I think there's too much emphasis on foreign keys. ... think we should emphasize the use of domestic keys wherever ...
    (comp.databases.theory)
  • Re: Generalized user-friendly constraint enforcement
    ... logic into the database" but who really mean "into a database engine ... This means things like triggers, foreign keys, check constraints. ... database engine worth its salt doesn't support these - if you enforce ...
    (comp.databases)
  • Canonical quantization and covariance
    ... provided that we use a covariant formalism. ... let me discuss how the constraint algebra acts on it. ... quantities which are gauge invariant, i.e. which only depend on orbits. ... making the constraints second class. ...
    (sci.physics.research)
  • Re: choice of character for relational division
    ... constructing a calculus or an algebra? ... forall (SupplierNo', PartNo) in SupplierParts: ... The algebra seems the clearest to me, ... seems the easiest way to write constraints. ...
    (comp.databases.theory)