Lots of Idiotic Silly Braces?

From: paul c <toledobythesea_at_oohay.ac>
Date: Mon, 16 Jul 2007 19:14:14 GMT
Message-ID: <asPmi.123158$NV3.2515_at_pd7urf2no>



No big reason for wondering about this, the uses may seem obscure but also seem interesting to me, David C and his notation thread has sent me off on what could be another wild goose chase. Gave this post a different subject so as not to usurp his.

I think that some relations, once grouped and then projected, can't be presented as a single table.

Eg.,

ShipmentParts{S,P} // (ie., Shipment number, Part number): S P
1 3
1 4
2 3

If we group on Part, we produce a relation that has two tuples instead of the three above and I might make it graphic like so:

S {P}:
1 {3,4}
2 {3}

(Here, if you'll indulge me, I've been a bit sloppy with an abbreviated notation, using {P} to mean an attribute that has values that are sets of parts, not individual parts and not mentioning any relation names.)

The predicate somebody intends by this grouping could be "Shipment S included the set of parts {P}". If we then ask "what combinations of parts have been shipped?", a knee-jerk reation might be to project away the S attribute:

{P}:
{3,4}
{3}

I wouldn't know how to present this to a user except with two "tables", perhaps like so:

Parts Combination (a):
P
3
4

Parts Combination (b):
P
3

I have the impression that Codd was not interested in forming an answer to such a query in this way, perhaps he would have said that it's unnecessary since without grouping or projecting, the same (ie., equivalent) information could be presented by sorting the original relation by Shipment number. That's fine by me, I'm not trying to suggest there is any inconsistency between his model and sorting to give the answer because the "information" was there all along, it just might not have been arranged to suit the nuance of the query.

Still, several other threads on various topics here have sometimes made me wonder what would happen if it were understood that when users see a single value in any column of a row in a table, underlying that value in the dbms is a relation that uses values which are non-empty sets.

For one thing, this might allow a system that for many apps, would not need to introduce rva's and the nested syntax they require.

Switching gears a little, suppose S stands for Suppliers and {S} stands for a set of suppliers. As far as the result to the query "who are the suppliers?", there seems no material difference in the information presented by

S
1
2

and

{S}
{1,2}.

As tables they are cosmetically different, they have different numbers of rows and one mentions Suppliers while the other mentions sets of Suppliers but they could represent the same relation under the covers. Most implementations seem to echo the table with two rows but it seems to me just as reasonable to echo the one that has only one row, ie.,

{S}
{1,2},

and when the system is asked to present it, it appears as

S
1
2.

(The reason I say that as "tables", S and {S} are only different in a cosmetic way, is that I prefer to think that it is not tables that a dbms operates on, rather only relations.)

But I can see no reason why there couldn't be an {S} relation that looked like:

{S}
{1}
{2}

and no other way (in the scheme I have in mind) to present it as a table than:

S
1
2

So, in this example, the relation "form"

{S}
{1}
{2}

happens to be equal (in information) to the "form"

{S}
{1,2}.

However, if I were to insert {1} to the latter "form", I think this relation "form" results:

{S}
{1,2}
{1}

My reason is simply that as "tuples", {1,2} and {1} are different. Now the the first two "forms" aren't equal to the one with the inserted tuple.

I don't know how to present this "relation" as a table any more than the   projection of the grouping I started out with so many lines above. All I have done so far is try to show why I think grouping doesn't always need to introduce new attribute names.

I'm trying to lead up to a notation and interpretation that combines group and project as we know them and maybe avoids ungroup entirely, but I'll stop here for now and invite attacks on any grounds except for the one that Codd already thought about this and rejected it!

p Received on Mon Jul 16 2007 - 21:14:14 CEST

Original text of this message