Re: header part of the value?

From: Brian Selzer <brian_at_selzer-software.com>
Date: Wed, 27 Feb 2008 19:06:22 -0500
Message-ID: <2Wmxj.3135$pl4.2115_at_newssvr22.news.prodigy.net>


"Marshall" <marshall.spight_at_gmail.com> wrote in message news:1d6e51c8-8c77-4ae1-8847-c0f357a3c5b8_at_d21g2000prf.googlegroups.com...
> On Feb 24, 12:26 pm, JOG <j..._at_cs.nott.ac.uk> wrote:
>> On Feb 24, 6:48 pm, Marshall <marshall.spi..._at_gmail.com> wrote:
>>
>> > Of course, that then leads me to think of a relation value
>> > as a <header, body> tuple.
>>
>> Woaaaah, hold on a tootin minute there cowboy...why would it lead you
>> to think that? Why is a db-relation value not merely a set of finite
>> partial functions (db-tuples), mapping attribute names onto values?
>
> "body" = a set of finite partial functions f: a -> v
> "header" = the domain of f
>
> I don't see any contradiction here.
>
> Or maybe it would be better if I said Relation is an ADT
> with a way to extract a header from it. Just because
> I say <header, body> doesn't mean there's physical
> memory dedicated to the header. <header, body> is
> a possrep, not a C struct.
>
> The point that changed my thinking was the realization
> that there is no way to write natural join without a
> way to extract the header from the operands.
>
>
>> > (Let us omit column type
>> > information for the present discussion.) Then one imagines
>> > an updatable relation variable in a database as holding
>> > a value of this tuple type. BUT then we notice that we
>> > have this restriction that the header must not be updated.
>> > Why is that?
>>
>> Well, a relation variable is defined as representing (at any given
>> point in time) a value from a set of valid relations
>
> Yes. (Although lately I like "bound to" better than "representing.")
>
>
>> lets call it V
>
> Let's call *what* V? You used three things that start with v in
> that sentence. I guess you mean the "set of valid relations."
>
>
>> - as defined by the predicate and constraints.
>
> Yeah, that's what I'm proposing thinking of differently.
> *Why* is the predicate not itself a constraint? We don't
> *have* to have any constraints--the constraint set could
> be empty.
>
> Do we *have* to have a predicate? I say NO! The
> math doesn't change any. In fact the whole system
> gets simpler if we say that the predicate, which we
> usually think of as being a separate, required piece,
> is just another ordinary mundane run-of-the-mill
> constraint.
>

I think that you can't completely eliminate predicates. You can isolate parts of predicates, but every relation has an implicit predicate just because of the juxtaposition of the attributes in the header.

Suppose that a relation has a predicate P(x, y, z). (Let's continue to omit column types since column types /can/ be thought of as just another kind of constraint.)

Due to the Closed World Assumption,

P(x, y, z) implies x /\ y /\ z.

In other words, there cannot exist a tuple that satisfies P(x, y, z) without first satisfying x /\ y /\ z.

In this case, x /\ y /\ z is the predicate implied by just juxtaposing the attributes in the header of the relation with the predicate P(x, y, z). If the following holds,

P(x, y, z) iff x /\ y /\ z /\ p,

then p can be a simple constraint that may involve zero or more of x, y or z..

A further thought on the need for a predicate. A constraint specifies what /can be/ the case, and while each tuple in the relation satisfies that constraint, there may be other tuples that also satisfy the constraint but do not also appear in the relation. Just take a look at an EMPLOYEE table before and after you insert a row for a new employee. Obviously, the row for the new employee satisfies all of the constraints of the EMPLOYEE table, or it couldn't have been inserted, but just because a row satisfies all constraints doesn't mean that it is also /in/ the table. My point is that there must be some mechanism that states not only what /can be/ the case, but also what /is/ the case.

> So: a relvar is a name bound to a relation value. Period.
> We might also have some constraints that reference
> that variable.
>
> (Another point: constraints cannot always be pinned
> on a particular variable, no more so than a method
> can always be pinned on a particular OOP class.
> Same problem. A foreign key constraint for example
> is a constraint on *two* relations.)
>
>
>> So, for instance,
>> continuing the above example we had a relvar R, that had to match the
>> predicate P(x, y, z) and enforce the constraint that c is less than
>> 10
>
> What if we change that to:
>
> "we had a relvar R, that had to enforce the constraints 1) that
> c is less than 10 and 2) R has the predicate P(x, y, z)"
>
> And then of course we could add more constraints, and/or
> drop either constraint.
>
>
> Marshall
Received on Thu Feb 28 2008 - 01:06:22 CET

Original text of this message