Re: header part of the value?
- From: JOG <jog@xxxxxxxxxxxxx>
- Date: Sun, 24 Feb 2008 16:28:57 -0800 (PST)
On Feb 24, 9:12 pm, Marshall <marshall.spi...@xxxxxxxxx> wrote:
On Feb 24, 12:26 pm, JOG <j...@xxxxxxxxxxxxx> wrote:
On Feb 24, 6:48 pm, Marshall <marshall.spi...@xxxxxxxxx> 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
Ok, then if it helps forget functions, with their associated use and
semantic connotations, merely view the db-tuples in my example as sets
of ordered pairs. The first elements of said pairs appear to be role
names and the second elements role values to us on the outside, but as
far as the set theory is concerned they are both just common garden
constants.
I'm not seeing the need for adding the extra 'header' component, and
of course would refer to ol' occam as backup.
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 header just seems a superfluous structure to me atm. But then as
you'll see below, I agree with everything else your saying, and I'm
not sure headers are actually the major issue (I may be wrong of
course).
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.
How so?
Let me bend your ear for a minute and show you how I'd represent joins
- given the representation I used in my examples, a natural join of R
and S (using their lowercase equivalents to represent the tuples they
possess) on attribute a, can be written set theoretically as:
Join(R,S) = { p: ∃r∈R, ∃s∈S [ p=r∪s ∧ ∃(a,v)∈r,s ] }
In fact I can generalize to a theta join by just generalizing the
final clause in the set definition:
Θ-Join(R,S) = { p: ∃r∈R, ∃s∈S [ p=r∪s ∧ Θ(r,s) ] }
Clean, and purely set theoretic. I shoot... I score?
(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.")
bound is good.
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."
Aye, you picked the one I intended. It must be a residual V for
Vendetta thing.
- 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!
I too 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 utterly and totally agree. I actually doctored the example I gave in
my last post from my own work, to separate out the 'predicate' from
'constraints' because I thought it would be a step too far from the
normal view of predication cdt. In the original version there was no
separation, and both were 'constraints'.
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.)
Sure but it is only required as part of the definition of the
referring set of valid relation values no? As such it is still
'pinned' on one relvar (perhaps I've misunderstood what you were
getting at though).
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
We are in dizzying accordance there.
and/or drop either constraint.
Or do even crazier things like using disjunctive predicates,
existential quantifiers for missing data, etc...
Marshall
.
- References:
- header part of the value?
- From: Marshall
- Re: header part of the value?
- From: JOG
- Re: header part of the value?
- From: Marshall
- header part of the value?
- Prev by Date: Re: header part of the value?
- Next by Date: Re: Value (was: Mixing OO and DB)
- Previous by thread: Re: header part of the value?
- Next by thread: Re: header part of the value?
- Index(es):
Relevant Pages
|
