# Re: Lots of Idiotic Silly Braces?

Date: Mon, 16 Jul 2007 16:29:06 -0300

Message-ID: <469bc6df$0$8841$9a566e8b_at_news.aliant.net>

> 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}
*

This represents it as one table.

> (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}
*

This represents it as one table.

> 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
*

Huh?!? See above.

> 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.
*

That's exactly what views deliver.

> 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}.
*

Not equal. Derivable but not equal.

> 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!
*

See above. Received on Mon Jul 16 2007 - 21:29:06 CEST