Re: Movies at Cinema Design help

"Garuda" <garuda_at_spammers.bye> wrote in message news:an55io$c4e$1_at_news.cscoms.com...
> Hello,
> I have to design a database that handles the movies displayed in a cinema
> with multiple rooms.
>
> It means that a movie could be displayed in multiple rooms at the same
time,
> and different movies can be displayed in the same room at different times.
>
> How it's done?
> If I try to make it normalized, to eliminate redundancy, I start to don't
> understand anything.
>
> It should be a M:M relationship between the movie and the room, and a 1:M
> between the movie and the time. And, oh.. what a mess!

Ok, lets start with the main entities, using top-down approach. From your description it sounds like you have the following:

• CINEMA: A place that shows movies. I'm assuming this system can handle multiple cinemas?
• ROOM: A place in the cinema where movies are shown
• MOVIE: A movie that can be shown in a room at the cinema

Looking at the relationships:...

• A CINEMA contains many zero or more ROOMS
• A ROOM is contained by 1 cinema
• A ROOM can display many MOVIES
• A MOVIE can be displayed in many ROOMS -- eek!

Now, as you say, there's something fishy about these last two because obviously a ROOM only has one screen, and can't display two films at once. We might need another entity to allow us to enforce these constraints. Basically, it is clear that we need to put more information against the relationship between MOVIES and ROOMS, so it would be a good idea to introduce a new entity here to hold this information. How about calling it SHOWING? This might have start time, end time etc.

So (scrapping the last 2 relationships above)...

• A MOVIE can appear in many SHOWINGS
• A SHOWING only has one movie
• A SHOWING is allocated to one ROOM
• A ROOM can have many SHOWINGS

In short....

MOVIE -------I--< SHOWING >--I-------ROOM

( note, a the 'I' characters mean dependency, which basically means a showing can't exist without a movie and a room - which sort of makes sense!). You could then use a PK's or some other mechanism on the SHOWING table to enforce the constraint (or rule) that dictates that a room can't have more than one showing in any given time window.

Ok, I don't want to complete your assignment, but hopefully this has given you a few ideas. Your course may have indicated how you can convert m:m relationships into entities - I seem to remember that there is a fairly standard process for doing so. Look this up, and this may make a little more sense.

HTH Tobin

> Can somebody please give me some help?
> Thank you,
> Garuda
>
>
Received on Sun Sep 29 2002 - 15:17:02 CDT