# Re: Constraints and Functional Dependencies

Date: 24 Feb 2007 08:41:27 -0800

Message-ID: <1172335287.661796.61940_at_8g2000cwh.googlegroups.com>

On Feb 24, 7:35 am, mAsterdam <mAster..._at_vrijdag.org> 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?
*

That works, although I find the "it is true that" can usually be dropped. I'd probably read it as

for all a in R there exists a b in S such that a equals b

> > In the context of relations with named attributes, it is not necessary

*> > to declare or make up logic variable names, the way we have to when we
**> > are using sets of ordered pairs. We can use the existing attribute
**> > names as the names of the logic variables. However that raises the
**> > question of what happens when we want to quantify over an attribute
**> > more than once in a given formula. In that case let a primed attribute
**> > name be considered a second instance of a logic variable quantified
**> > over the attribute.
**> > So if we want to say that for every row of R
**> > with attribute a there exists a row of R with an unequal value
**> > for attribute a, we can say:
**>
**> > forall R(a): exists R(a'): a != a'
**>
**> This looks like setting up a (unintended) trap of mixing attributes
**> and attribute values.
**> Why not prime the first instance^W^W^W all instances?
**>
**> forall R(a): exists R(a'), exists R(a''): a' != a''
**> ?
**> (saying that R has at least two rows with different
**> values for a, just like above.)
*

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.) Many constraints will not quantify over a given relatin more than once, for example, and they are a lot more readable without the primes. 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.

> > What about candidate keys? Suppose we have a relation R with

*>
**> ... only the ...
**>
**> > *sets* of attributes A and B: R{A, B}.
*

My intent is to express that with R{A, B}.

*> > [...]
**> Very nice :-)
*

Yeah, aren't those cute?

Marshall Received on Sat Feb 24 2007 - 17:41:27 CET