Re: foreign key constraint versus referential integrity constraint

Keith H Duggar <dug..._at_alum.mit.edu> wrote:

> what is the common name for the semantic constraint
>that "attribute RV1:X and RV2:Y are sematincally

Concerns about "semantic joinability" are confused.

Relation operators, attributes and expressions correspond to logic operators, (bindable) variables and expressions. So predicates of relation variables plus predicates corresponding to functions determine the semantics of relation expressions. (Note that you need an EQUALS function with two appropriately typed parameters whenever a relation operator evaluation uses an attribute's values to remove duplicate tuples or to compare tuples from multiple arguments.)

The predicates entirely determine the possible queries and their meanings. If you don't make mistakes in understanding predicates then you will never want to write a query that can't be expressed in terms of the predicates and answered in terms of relations.

The predicates entirely determine valid database states. Attribute types and constraint expressions are logically redundant. What they do is constrain updates to valid database states. If you don't make mistakes in observing the modeled world and evaluating the predicates in it then you will never want to make an update that violates a constraint.

Your problem is you don't know that you should be given the predicates. Your difficulties arise from this.

> why shouldn't the RM allow us to further constrain what domains
> permit for both values AND [relational] operations?

I hope it is now clear that "semantic" limiting of relation expressions is confused.

There is actually a limit on logic expressions, namely those that correspond to relation expressions. You can only write those that involve AND, AND NOT, OR of expressions with the same free variables, EXISTS, RENAME and functions (which must include implicitly needed EQUALSs). Otherwise evaluation cost is a function of type cardinalities instead of just the number of tuples in the database.

philip Received on Mon Oct 26 2009 - 10:51:26 CET