Re: atomic

#51

On Nov 6, 12:16 pm, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote:

Quote:

paul c wrote:
Bob Badour wrote:

paul c wrote:

Bob Badour wrote:

paul c wrote:

paul c wrote:
...

if those make sense, by the D&D definition of "cartesian product",
I think r1 |x| r2 would be empty and I presume so would I(r1 |x| r2).

Sorry, let me take that back, I think I should have said
intersection, not cartesian product.

The join is empty. The intersection is empty. If one renamed one of
the "car" attributes to something else, the join would have 4 rows.

I think it would have 20!

r1:

Name Car
----------- ------------
{bill} {car1,car2,car4}
{john,fred} {car3}

r2:

Car Colour
---------------- ---------
{car1,car3,car4} {red}
{car2} {green}

r1 join ( r2 rename Car as Vehicle ):

Name Car Vehicle Colour
------------- ------------------ ----------------- ---------------
{bill} {car1,car2,car4) {car1,car3,car4} {red}
{bill} {car1,car2,car4) {car2} {green}
{john,fred} {car3} {car1,car3,car4} {red}
{john,fred} {car3} {car2} {green}

I count 4 rows.

Okay, I thought you were using the sources from David B's post about his
"I" function which would have 20.

I don't bother reading David's posts. I only see what you excerpt, and
when I replied to you this time, I was replying to you.- Hide quoted text -

- Show quoted text -

I wish Bob would read my posts; his insights would be valuable.

#52

"Bob Badour" <bbadour (AT) pei (DOT) sympatico.ca> wrote

Quote:

paul c wrote:
I think it would have 20!

r1:

Name Car
----------- ------------
{bill} {car1,car2,car4}
{john,fred} {car3}

r2:

Car Colour
---------------- ---------
{car1,car3,car4} {red}
{car2} {green}

r1 join ( r2 rename Car as Vehicle ):

Name Car Vehicle Colour
------------- ------------------ ----------------- ---------------
{bill} {car1,car2,car4) {car1,car3,car4} {red}
{bill} {car1,car2,car4) {car2} {green}
{john,fred} {car3} {car1,car3,car4} {red}
{john,fred} {car3} {car2} {green}

I count 4 rows.

I have been on the fence about RVAs for years. I can see why Date and
others (including you guys) want to talk about them for the purpose of
understanding where the theory takes you. But this little exchange shows me
that I never want to see RVAs implemented in any product. (I am not talking
about paul's confusion about the relations in question.)

I don't care if there is a problem that can be solved only with RVAs, the
misery they would invite just wouldn't be worth it. The old joke says if we
ever teach computers to understand English we will find out that programmers
can't write it. If we ever produce a product that supports RVAs we will
find out programmers are wanting in that area too.

Roy

#53

paul c wrote:

Quote:

paul c wrote:
...

along with a constraint such as B REFERENCES R.

and umpteen+1: ... such as B REFERENCES R.A.

B cannot reference R.A because A and B have different types.

#54

On Nov 6, 3:45 pm, David BL <davi... (AT) iinet (DOT) net.au> wrote:

Quote:

On another note, I've been thinking of an interesting partial ordering
on mv-tuples that is associated with information redundancy :

t1 <= t2 if
attribs(t1) is a subset of attribs(t2) and
for each attrib a in attribs(t1), t1(a) is a subset of t2(a)

t1 <= t2 means that t1 is (information) redundant with respect to t2.

This isn't quite right. Instead the definition should be

t1 <= t2 if both the following

for each attrib a in (attribs(t1) intersect attribs(t2)),
t1(a) is a subset of t2(a)

for each attrib a in (attribs(t1) \ attribs(t2)),
t1(a) = {}

Quote:

Definition: Let attribs(t) be a subset of X. Let t' = extend(t,X)
represent the extension of t onto X by defining

for all a in attribs(t), t'(a) = t(a)
for all a in X\attribs(t), t'(a) = {}

Note that extending a tuple with empty sets doesn't change the
information content. More formally

extend(t,X) <=> t

It seems more useful to define a project/extend operator in one
step...

Projection
----------

Definition: Let X be any set of attributes and t be an mv-tuple. Let
t' = project(t,X)
represent the projection of t onto X where t' is an mv-tuple
satisfying

attribs(t') = X
for all a in (X intersect attribs(t)), t'(a) = t(a)
for all a in X\attribs(t), t'(a) = {}

Definition: Let X be any set of attributes and r be an mv-relation.
Let r' = project(r,X) where r' is an mv-relation satisfying

attribs(r') = X
tuples(r') = { project(t,X) | t in tuples(r) }

It should be possible to prove the following

t => project(t,X)
if attribs(t) is a subset of X then project(t,X) <=> t

Information comparisons between mv-relations
--------------------------------------------

Definition: Let r1,r2 be mv-relations. we write r2 => r1 (or
equivalently r1 <= r2) if

I(r1) is a subset of I( project(r2, attribs(r1) )

Definition. We say r1,r2 are information equivalent (written r1 <=>
r2) if r1 => r2 and r2 => r1.

I think it would be possible to show that (r1 intersect r2) is
uniquely characterised (up to information equivalence) as the largest
amount of information consistent with

r1 => (r1 intersect r2) and
r2 => (r1 intersect r2)

ie there is no mv-relation r satisfying

r1 => r and
r2 => r and
not ( (r1 intersect r2) => r )

There is a corresponding characterisation of (r1 union r2).

#55

On Nov 7, 1:44 am, paul c <toledobythe... (AT) ooyah (DOT) ac> wrote:

Quote:

paul c wrote:
David BL wrote:
...
Is this what you mean (in Prolog):

r(Name,Car,Colour) :- Name owns Car with Colour.

r1'(Name,Car) :- r(Name,Car,Colour).

or in natural language

r1'(Name,Car) :- there exists Colour such that r(Name,Car,Colour).
...

I think so.

By the same token,

r1'(Colour) :- there exists Name, Car such that r(Name, Car)

I assume you mean

r1'(Colour) :- there exists Name, Car such that r(Name, Car,
Colour)

Quote:

et al, ie., applies to all combinations of projections.

I think of these as symmetrical REFERENCE'ing statements and they are
implicit from the choice of attributes of a relation. For me, this
means that the orthodox view is that the form of optional data must
involve more than one relation. So if set-valued attributes are
eligible in the orthodox framework, I think I'd want to be able to say
similar sentences about them.

Are you saying you want to make statements about sets without those
statements being reinterpreted as instead applying to the elements of
the sets?

Quote:

The snippet above doesn't mention the types of Name, Car, Colour. I
think there is a difference between saying the type of Car is set of
elements and the type of Car is a subset of those elements and if I
understand correctly, David is talking about a Car attribute which
allows subsets as values (as I have been too).

Are you alluding to the distinction between

r1(Name) :- Name is a valid name
r2(Name) :- It is known there is a person called Name.

r1 is defining the domain type. Let's assume that the domain type is
any finite string. Then r1 has an infinite extent and essentially
information-less because it can be algorithmically compressed.

By contrast r2's extent is finite and far less compressible than r1,
and so only r2's extent deserves to be explicitly recorded in a DB.

In the case of r1 the bad news is that we can't physically store the
infinite extent. The good news is that we don't need to.

I'm not sure how the distinction between information-less-type and
information-full-type relates to the discussion about how to interpret
multi-valued attributes.

I've read your post a few times, but I'm afraid I don't understand the
point you're making.

#56

On Nov 7, 11:39 am, paul c <toledobythe... (AT) ooyah (DOT) ac> wrote:

Quote:

David BL wrote:
On Nov 6, 3:45 pm, David BL <davi... (AT) iinet (DOT) net.au> wrote:
On another note, I've been thinking of an interesting partial ordering
on mv-tuples that is associated with information redundancy :

t1 <= t2 if
attribs(t1) is a subset of attribs(t2) and
for each attrib a in attribs(t1), t1(a) is a subset of t2(a)

t1 <= t2 means that t1 is (information) redundant with respect to t2.

This isn't quite right. Instead the definition should be

t1 <= t2 if both the following

for each attrib a in (attribs(t1) intersect attribs(t2)),
t1(a) is a subset of t2(a)

for each attrib a in (attribs(t1) \ attribs(t2)),
t1(a) = {}

...

Sorry if I missed something but does "\" mean divide? (If so, which
divide, Codd's or another one?) (not saying I understand the rest,
because I'm a slowpoke, but I do think the first version can be
expressed with D&D "semijoin".)

No "\" means set difference.

attribs(t1) \ attribs(t2) are the attributes in t1 that don't also
appear in t2.

t1 <= t2 (or equivalently t2 => t1) can be thought of as meaning that
t2 implies t1, in the sense that all the facts implied by t1 are a
subset of all the facts implied by t2.

I haven't yet bothered to prove many of my claims yet because it's a
lot or work and I actually have a 9-5 job!

Here is an example:

Claim: if t1 => t2 & t2 => t3 then t1 => t3
Proof:
if a in (attribs(t1) intersect attribs(t3)) then

if a in attribs(t2) then
a in (attribs(t1) intersect attribs(t2)) so t1(a) is a
subset of t2(a)
a in (attribs(t2) intersect attribs(t3)) so t2(a) is a
subset of t3(a)
so t1(a) is a subset of t3(a)
else
a in (attribs(t1) \ attribs(t2)) so t1(a) = {}
so t1(a) is a subset of t3(a)

else if a in (attribs(t1) \ attribs(t3)) then

if a in attribs(t2) then
a in (attribs(t1) intersect attribs(t2)) so t1(a) is a
subset of t2(a)
a in (attribs(t2) \ attribs(t3)) so t2(a) = {}
so t1(a) = {} (because subset of empty set is empty)
else
a in (attribs(t1) \ attribs(t2)) so t1(a) = {}

I don't know about you but writing out these sorts of proofs is not my
idea of fun!

#57

On Nov 7, 12:25 pm, paul c <toledobythe... (AT) ooyah (DOT) ac> wrote:

Quote:

David BL wrote:

...

I think of these as symmetrical REFERENCE'ing statements and they are
implicit from the choice of attributes of a relation. For me, this
means that the orthodox view is that the form of optional data must
involve more than one relation. So if set-valued attributes are
eligible in the orthodox framework, I think I'd want to be able to say
similar sentences about them.

Are you saying you want to make statements about sets without those
statements being reinterpreted as instead applying to the elements of
the sets?
...

I'm not sure if I understand you but at first glance I'd say no, that's
not what I "want". I think if there is missing information then we
can't express that in a conventional RM theory without multiple
relations.

I agree.

I'm assuming you are referring to the idea of going to 6NF to allow
for missing information.

Quote:

Maybe I'm misunderstanding, but I think RM allows sets to
make statements about something we're interested in whereas statements
about those sets are something else.

I was thinking of when you were saying in another post that r1 |x| r2
is empty, I regard that as reasonable on the assumption that
statements are being made about the sets, thought of as single values,
rather than the elements of the sets, and this indeed is appropriate
for D&D definitions.

I'm hoping that you'll see mv-relations as a distinct formalism which
avoids the need for 6NF, but has its own disadvantages that may make
it unpalatable.

#58

Quoth paul c:

Quote:

Jon Heggland wrote:
I see no need for presumption. Without RVAs, an AMI would probably be in
order, and by not associating any attributes with it, one would have an
explicitly empty key, no?

I'd see it exactly as an application presumption if the catalog had a
value in the "AMIS" table that wasn't in the "KEYS" table (unless the
dbms didn't support empty headers as keys.)

It would be in the "KEYS" relvar, but not in the "KEYATTRIBUTES" relvar,
I think... though it makes little sense to discuss this without
specifying the design completely.

Quote:

The single table/relvar
allowing RVA's seems neater to me, more exact than using two relvars.

Neater, definitely. (I'm not sure what you mean by "exact".) But wasn't
your argument that RVAs are messy because of (perceived) possibility of
inconsistency? Anyway, the structural design is neater, but the
constraint to ensure that the key attributes are in fact attributes in
the key's relvar, might be more complicated.
--
Jon

#59

Quoth Roy Hann:

Quote:

I have been on the fence about RVAs for years. I can see why Date and
others (including you guys) want to talk about them for the purpose of
understanding where the theory takes you. But this little exchange shows me
that I never want to see RVAs implemented in any product. (I am not talking
about paul's confusion about the relations in question.)

I don't care if there is a problem that can be solved only with RVAs, the
misery they would invite just wouldn't be worth it.

What misery, exactly? It's easy to design relvars with confusing
predicates using them, but that goes for boolean-valued attributes as
well.

If people just stopped thinking of RVAs as special in any way, and just
thought of relations as perfectly normal values, a lot of confusion
would go away.
--
Jon

#60

Quoth paul c:

Quote:

One thing that annoys me about them is how they allow two attributes
with the same name to be thought of as "in the same outer relation", if
you will.

What do you mean? That an RVA might have an attribute with the same name
as an attribute in the enclosing relation? If you think of these as "in
the same outer relation", it is your thinking that is faulty, I'd say. I
don't see the difference between this and an attribute having a possrep
with a component name that is the same as a different attribute. But
perhaps I'm misinterpreting you.

Quote:

But I'd like to suggest that even though I throw the term RVA around,
pretty loosely too, I'm not sure all these posts have been about RVA's
but rather something else, even if that something else is not well
defined in the context of the rest of RT. Perhaps "set-valued
attributes" describes it better.

Definitely; all the examples I've bothered to read (and write) have been
using unary "RVAs" without attribute names, so one might as well talk
about SVAs (which don't seem to be in dire need of better definition).
And I find this amusing, as I've gotten the impression that there has
been established a tentative consensus here that SVAs and indeed all
kinds of XVAs /except/ RVAs are fine and dandy, and don't violate 1NF;
but that RVAs are dangerous, and lead to second-order logic,
inconsistency, confusion and excessive renaming---apparently because the
relational engine "understands" them. Pish and tosh, I say. Cumbersome,
yes. Mostly useless, yes. Fundamentally different from other data types, no.
--
Jon