David Hare-Scott wrote:
> TotalNewb wrote:
>> On Friday, June 1, 2012 8:14:29 AM UTC-4, Bob Barrows wrote:
>>> BadnBull_Options wrote:
>>>> Sorry for being a newb, for whatever reason I just can't wrap my
>>>> head around this. I need some help in figuring out the entities and
>>>> their relationships here, I already sent in a couple of
>>>> submissions, and I get the impression my professor is getting a bit
>>>> ticked off.
>>>>
>>
>> Here's my third submission, apparently it's still has some issues,
>> for instance restricting the rating of a particular movie to only one
>> rating, the Actor entity restricts an actor to only one film in his
>> entire career,
Do you see why? What do you think you would need to do to correct it? Think
about what a key does: it uniquely identifies each row in a table. Look at
the key you chose for the Actor entity. How many rocords is it allowing for
each actor?
In the real world, I would have two tables: one for Actors, keyed by actor
(one record per actor) so I could include all the other interesting details
about the actor (DOB, etc.), and the other would be called something like
ActorsMovies, which is keyed by the keys for both actors an movies. It would
have two foreign key relationships: one to Actors, and the other to Movies.
> also the first 3 relationships are incorrect. Also,
>> I'm a little puzzled as how to approach the Count and Price
>> relations. Any feedback would be great guys?
Similar thinking is required.
I agree - the requirement, "Do not add *any* data items to the 21 items
shown." does seem to make this insoluble ... unless that horribly named
"Date" data element actually refers to the movie's release date rather than
the date that it is shown in a theatre. Hmmm, yes, the "Time of Showing"
element could store both the date and time of showing, so "Date" could be
used to indicate the release date of the movie. This would allow a natural
primary key of
MovieName, Date, Director
To the OP:
I would modify the movie key as above, as well as the relationships and the
keys of the other tables where you have used Date to indicate the date of a
movie's screening.
A similar objection applies to the key you have chose for theatre - I can
think of several Showcase Cinemas located within 25 miles of my location.You
need to include at least Town to uniquely identify a theatre.
In the real world, it is possible for there to be two actors with the same
name - for example, two actors named Colin Farrell are currently working.
The elder one appeared in "A Bridge Too Far". The younger one of course is
famous for his roles in "Minority Report", "Alexander", "Daredevil",
etc.Other examples include Peter Graves and Richard Denning.
So the problem definition has failed to include enough data elements to
properly identify the actors - be sure to point out this flaw to the
professor, but don't let that stop you from providing a theoretical
solution - you can use parenthesized numerals as part of the actors' names
to differentiate actors with the same name (similar to what IMDB does). It's
not an ideal solution but it will make the problem soluble.
Think about the key you've chosen for Showings. Don't theatres routinely use
sequential numbers to identify their screens? Screen 1, screen 2, etc. Have
you selected the proper key for that table?
I am going to stop here, I think you have enough direction now to revisit
each of your enitities in your model and make sure you provide proper keys
for each. Once you have done that, show us what you have.