Re: header part of the value?


"Marshall" <marshall.spight@xxxxxxxxx> wrote in message
news:1d6e51c8-8c77-4ae1-8847-c0f357a3c5b8@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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

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


.

Relevant Pages

  • Re: header part of the value?
    ... as a <header, body> tuple. ... Given specialization by constraint, the only data type for which that is true is the universal supertype. ... gets simpler if we say that the predicate, ...
    (comp.databases.theory)
  • Re: predicate, constraints, header, relvar, and relation
    ... Does a predicate apply to a relvar or a relation? ... While the concept of constraint it meaningless for values, every constraint basically describes some property of consistent values. ... because a relation literal must have a header. ...
    (comp.databases.theory)
  • Re: header part of the value?
    ... as a <header, body> tuple. ... *Why* is the predicate not itself a constraint? ... Do we *have* to have a predicate? ... a relvar is a name bound to a relation value. ...
    (comp.databases.theory)
  • Re: header part of the value?
    ... as a <header, body> tuple. ... *Why* is the predicate not itself a constraint? ... Do we *have* to have a predicate? ... a relvar is a name bound to a relation value. ...
    (comp.databases.theory)
  • Re: Constraint on an aggregate?
    ... The constraint is on the header table. ... business rules in the server. ... orders) cannot exceed the user-entered credit limit. ...
    (comp.databases)