Re: Constraints and Functional Dependencies

Marshall wrote:
> mAsterdam wrote:

>> Hi Marshall,

:-)

>> [snip intro]
>>
>>> With such a system, a relation R with attribute a (which I will
>>> write as R(a)) having a as a foreign key into S(b) is expressed
>>> as follows:
>>>   forall R(a): exists S(b): a = b
>> Just to be sure notationally: the first colon reads
>> ' it is true that ', the second ' such that it is true that ', right?

Thank you. Teletype is no substitute for a blackboard :-(

> Oh, that reminds me: there might be some use to
> expressing "constraints" on constants! They wouldn't
> be runtime constraints necessarily but they might
> be useful because of constraint propogation through
> views, for example. Instead of "constraints" they
> would be static properties of the constants that the
> compiler could verify. In fact, I generally quite like
> the idea of having a uniform way of specifying
> such properties, and having it be a separate concern
> whether the properites are checked statically or
> dynamically.

About the other side of this medal:
just a few days ago (feb 21, nntp.perl.org) Steve Lukas wrote in perl.per6.language:

 > My approach is:
 > In terms of writeability a variable/reference can be
 > (1) a variable, (2) a constant or (3) a "final"
 > (Don't wonder if you never heard of that "final", just my proposal)
 > That means it can be writeable (1),
 > not writeable since compile time (2) or
 > not writeable since that moment in runtime when it gets "final" (3).

[snip suggestion to prime all instances]

> I am sensitive to the concern you mention, however I
> think it will be okay as is. (Although I admit I am not
> a teacher.)

Yes you are.

> Many constraints will not quantify over a
> given relatin more than once, for example, and they
> are a lot more readable without the primes.

Yes, that would be a serious drawback.
Since you are aware of the possibility for confusion I trust you to emphasize the distinction wherever it is necessary.

> Also,
> it's not that different than issues one runs into with
> SQL. When one says
>
> select * from R where a > b
>
> the "a > b" part is using attribute names as variables
> in an expression that is evaluated for every tuple in
> the relation.

Since when is that an argument? (for others: just kidding)

>>> What about candidate keys? Suppose we have a relation R with
>> ... only the ...
>>
>>> *sets* of attributes A and B:  R{A, B}.

ISTM making this one explicit goes better with the minimalist approach. The less is to be assumed ... grmpf!
I just saw a razor blade fly by :-) Received on Sat Feb 24 2007 - 18:25:48 CET