Re: candidate keys in abstract parent relations

"Forrest L Norvell" <spankysyourpal_at_gmail.com> wrote in message news:1137794973.660236.90460_at_g44g2000cwa.googlegroups.com...
>
> David Cressey wrote:
> > ... [I]f you have a table with no candidate keys (two rows mean
> > something different, but are duplicates of each other) then you haven't
got
> > a relational model, yet.
>
> I think I'm almost there, though. Or at any rate, I'm a lot closer than
> I was when I started this thread!
>
> > It seems to me that the OP has yet to identify a
> > track.
>
> No, the Track is one of the few entities I really am sure about: a
> Track is an indexed element of a Side

OK. Sorry about that.

> (of a Disc (of an Album)) that is
> associated with a Performance, with its own name and duration. The same
> Performance may be included on different albums as a separate Track,
> but a Track is ALWAYS tied to specific Side->Disc->Album. Sides and
> Discs are logical groupings, and could probably be denormalized to
> albums if it weren't for things like run-out groove etchings (on Sides)
> and named Discs (and CD pressing plant codes (look at the inner ring on
> the bottom of a CD sometime)) in multi-disc sets.
>
> I just realized that this even further muddies the waters between
> Releases and Albums, because run-out groove etchings are specific to
> the release. So I can fold Releases, Albums, and AlbumVersions into one
> entity called Album, or maybe I just need to rejigger which attributes
> are on which of those tables. I probably don't need three tables to
> model that relationship, though.

Maybe an "Album" isn't really an entity at all, but instead a "reified" relationship between tracks and releases. Received on Fri Jan 20 2006 - 23:32:23 CET