I’ve put together a simple database for storing information on awards and nominations. I’ve tried to remove as much data redundancy as possible. Here’s how it’s presently looking:

The reason for the Nominated table is that I realised that one nomination would have many nominees. For example, the award Best Screenplay could go to Ken Levine and David Isaacs or Woody Allen or Joss Whedon, Andrew Stanton, Joel Cohen and Alec Sokolow.
Note: Award.name is the name of the award, e.g. Best Actor.
Thanks for pointing out any possible improvements.
Minor notes
I prefer singular for table and column names so
NomineesbecomesNominee,AwardsbecomesAward, etc.Renaming the
Awardtable asAwardCategoryas @wildplasser suggested in comments.Major notees
As @Olivier points out, the
m::nrelationships intermediate tables, like theNominatedone, will have aUNIQUEconstraint on the compound(NomineeId, NominationId). So, it’s better to drop the auto generated (surrogate) key and make the compound key thePRIMARY KEY. This is the natural key of the relation and there are several advantages of using it as the Primary Key. The surrogate key serves no purpose at all in this case except for having wider row and one more useless index. The two parts of the natural keys will be used for joining anyway.The same thing applies for the
Nominationtable! The compound(FilmId, AwardCategoryId, EventId)will be aUNIQUEkey, to ensure that no film gets 2 nominations for the same award category for the same event, so it’s again better to drop the surrogate key and make this compound the primary key. Rethinking, we may have 2 nominations for the same AwardCategory for the same Film, say for two'Best Supporting Actor'so we add aNominatioNoin the Primary Key (this can be handy later if we want to restrict the nominations for a certain category or for all to say the constant 5).Now, the (funny and interesting) thing is that the
Nominatedtable has to be re-examined and have a compound(NomineedId, FilmId, AwardCategoryId, EventId)Primary Key – and just these 4 columns as attributes.I’m not sure of what exactly the
EventandCeremonytable are meant to store, but lets assume that theCeremonytable is meant to store information about different ceremonies (e.g.'Oscar Awards','Strawberry Awards') and theEventtable is to store information about a year’s ceremony (e.g.('Oscar', 2011), ('Oscar', 2012), ('Starwberry Awards', 2012)). So i’ll move theYearto theEventtable and make the(CeremonyId, EventYear)the Priamry Key of Event. (I could very well be wrong this, you know your data better.).So, the
Nomination.EventIdis replaced byCeremonyIdandEventYearand the Primary Keys of bothNominationandNominatedget even longer! (that’s one drawback of using natural keys as Primary Keys). Lets see what we’ve got so far:Database Design 1 http://img594.imageshack.us/img594/9592/oscarw.png
You can easily add a
NominationWinner(as a table with1:1relationship toNomination) to store which nomination won which category (a Unique constraint on(CeremonyId, EventYear, AwardCategoryId)would enforce that). The design would be like this:Database Design 1 http://img845.imageshack.us/img845/2108/oscar3x.png
Having so complex primary keys may look clumsy but it helps when joining tables. Imagine you want to find all Winners for the ‘Strawberry Awards’ for the 50s and 60s and only for the ‘Actresses’ categories and also show for what film the award was for. You don’t have to join all intermediate tables. Instead, you can retrive data using only the
NominationWinner,Nominee,Ceremony,FilmandAwardCategorytables (and using only theNominatedintermediate table):