On Oct 28, 1:41 am, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote:
I agree with Bob, although use of the definite article in "the type"
is potentially confusing because a value may have many types (only one
of which is the MST).

Properties like

A = A join (A union B)

are true because it concerns equality of values on the two sides of
the equation, and has nothing to do with static type analysis. It is
similar to how D&D talk about an ellipse variable that inadvertently
holds a circle value when the width and height happen to be equal.
Obviously for every A and B, the MST of

A join (A union B)

will match the MST of A.

I cannot see any reason not to allow the type system to form a
lattice, i.e. for any two given types there is a well defined "union
type" and "intersection type".

Static type analysis of an expression containing a natural join could
assume that its static type is either the intersection type or the
union type of the static types of the operands. I would suggest the
former is more useful than the latter because statically typed
languages make upcasts implicit and downcasts explicit - so a more
specialised static type is favourable.

Of course at "run time" a particular join result (i.e. value) may have
a dynamic type (i.e. its MST) that is more specific than its static
type.

On Oct 27, 9:33*am, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
Heh. I think that's a fair question.

I think absorption, (the above property) is in fact something
with practical use, to the optimizer anyway. But I guess
my point is more general, which is to say that the behavior
of the type system ought to match the behavior of the
runtime system. If join puts attribute values together with
AND, then the type system should put type values together
with AND.


Marshall

On Oct 27, 12:41*pm, TroyK <cs_tr... (AT) juno (DOT) com> wrote:
I don't think he's going to like that advice; Bob has gone on record
repeatedly saying mean things about Dawn.


Marshall

On Oct 27, 9:41*am, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote:
Ack! Out of time for news this morning. Hope to reply later.


Marshall

Marshall wrote:

I am actually allergic to Dawn. I use Sunlight. I started with Sunlight
to wash out as much of the oil as possible before I used the peroxide
and baking soda.

Mr. Scott wrote:
Forgot to mention that I don't see that a "a constraint defined on a
join" would necessarily be "of the form (p /\ q) -> r". I had thought
that many people think it could be any truth-valued expression such as
"(p /\ q) = r".

This leads me to think that most, if not all, view definitions can be
interpreted as constraints. It is interesting to me to then ask what
makes a view different from a base. Is it enough to say that a view
always has one constraint (of possibly several) that is an equality and
a view may be 'updated' without reference to the view?

A more opaque way but perhaps less useful way of saying this is that a
relation's definition in the first place amounts to nothing more than a
constraint.

Snipped

As for the headers being less relevant in the context of domain
analysis, I meant that domain analysis clearly focuses on the body of
each un-ary relation being primarily a domain subset (*before*
relation level constraints are applied; I use the term with great
caution !) to be considered an attribute of a specific relation. It
is only once domain requirements are met that the assignment of a
specific header defines the attribute (then the header set defining
the relation).

My observation is that a lot of work has been done into defining
relations in order to algebrically operate them as relations but very
little has been done to use domains to clarify relational algebra.
`
My conclusion is that the relational consensus that constraint
specialization through domain analysis could be in any way orthogonal
to relation structural definitions restricts the possibility of
clarifying further relational model operations and implementations.

But that is only my opinion.

Regards...

On Oct 28, 10:41*am, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
Is view definition a constraint? IMO it's purely terminological
matter. Consider relations x and y defined by some algebraic
identities. Is adding new view z (as a function of x and y) adding a
constraint to the system?

Let's analyze a simpler example. Consider two real values constrained
by the equality:

x + y = 5

Is introducing a new variable z, say

z = x - 2y

a new constraint imposed onto the system? Not really, because,
variable z is redundant and can be eliminated, and it doesn't affect
the formal property of the system of being under constrained.

Tegiri Nenashi wrote:
....
That is a form of argument that I've seen quite often regarding various
RM questions, not just this one. I'd have no problem with it were it
not called an "example". Since it is about arithmetic, it's at best a
mere analogy to relations and we need to decide whether the analogy
should apply. To try to answer that I would ask when do we ever record
"extensions" of arithmetic equations? In other words, just because we
have abstract operations for both numbers and relations doesn't mean one
should mimic the other. If that's so, maybe somebody else can put it
better.

Tegiri Nenashi wrote:
I would say not exactly. More exactly it is adding another relation and
constraining the resulting system (aka the resulting database). That is
different from merely constraining an existing system/database.