Re: Lots of Idiotic Silly Braces?

paul c wrote:

> 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