Re: header part of the value?
Date: Sun, 24 Feb 2008 17:59:44 -0400
>>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.
Isn't that like saying there is no way to write multiplication without a way to extract the digits from the operands?
>>- 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.
Given specialization by constraint, the only data type for which that is true is the universal supertype.
> 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
And given specialization by constraint, that is synonymous with saying the data type is important. What is the data type if not the predicate?
> So: a relvar is a name bound to a relation value. Period.
> We might also have some constraints that reference
> that variable.
Which is synonymous with the variable having a declared data type.
> (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.)
Two relation variables but a single database variable.
>>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.
And this has the effect of changing the declared data type of the variable. Received on Sun Feb 24 2008 - 22:59:44 CET