Case Sample: Cinema Application ER Diagrams

Cinema ER Diagrams

Product or Service design is one of the most important steps on engineering. It's the step where you graphically create the specifications, features, goals and the main notes of the product/service requirements. In Software Development we have Software Design which is the activity after the setting of requirements and before programming implementation.

As we already know, the human brain captures better the pictures than words. Defining system features, concepts and complexes through some sort of standardized diagramming tools is far more better than describing it with words.In this case sample we will try to build ER Diagrams for Cinema Application. As previously explained  the design step is primary during the Software Development Process, in turn the step of Database Design is one of primary importance for the logical construction of Databases.


With the help of ER diagrams we will try to conceptualize some main entities and relationships of our Cinema Database. It's clear that the main and only business model of cinemas revolves around movies. So we have a Movie entity, a cinema can have several Halls where the movies are watched. In turn we create a Hall entity, for the sake of marketing we keep records for actors that will play at movies, each Hall have several seats which one client during  a specific time reserves to watch a movie, the Cinema can define some types of clients in order to target the prices more specifically, for example we can have price discounts for students and children younger than 12 years old, lastly, we have the Employers who perform the registration of the seats.

Above, we have the figure with the ER Diagrams for our Cinema Application. Now, let's explain the relationships between the entities.

Movie entity:  The movie entity is related with the Hall entity. Which means that one movie can be played in several halls and one hall can have several movies, in this relationship we have two important attributes, that of start time and end time of the movie where we include complete date and time information.

A movie has information about the actors which perform at the show. One movie can have several actors and one actor can play at several movies. So the relationship is many to many. And lastly, the movie entity is related with the client entity in such a way that the client entity maintains record about the types of clients like students, youngsters or elders and the price of the movie depending in the type of the client.

Hall entity: We have already defined the relationship of the hall entity with the movie entity so we focus on explaining the relationship of the hall entity with the seat entity. Each Hall can have several Seats and one recorded seat should belong to only one hall. So the relationship should be one to many. One seat belongs to only one hall and one hall can have several seats.

Client entity:  As already explained the client entity keeps record for the types of client in order to target the prices specifically for a specific movie. For example we will have a price discount for Students for "The Hobbit".

Employer entity: Employer entity is important for our application because it's the employers who make the ticket registrations for the clients.

Explaning the dashed boxes-aggregation.

You have probably realized that that the Movie and Hall relationship is enclosed by dashed box. That's called aggregation and it defines a new relationship which associates some entity with some other existing relationship. We identified an existing relationship set by enclosing it in a larger dashed box, in our case the Plays relationship between Movies and Hall, and then we will allow it to participate in another relationship with the Seat entity which is the Reservation relationship. In this case the Movie and Hall relationship through aggregation can be defined let's say as a Play Show entity which is in relationship with the Seat entity. That's it, a Play Show is aggregation and has information about which movie plays at which hall and at what time.

When we have information about Reservation relationship which is composed by Play Show aggregation (relationship between Movie and Hall entities) and the Seat entity then we can put it in dash box and define it as Reservation aggregation which has a relationship with the employer. One Employer can make several reservations while one reservation can be made only by one employer, so we have a one to many relationship. To explain it one more time the Employer is in relationship with the Reservation aggregation which is an aggregation composed of Play Show aggregation (composed of relationship of Hall and Movies entities) and the Seat entity.

Conclusion

As conclusion, i hope i have clarified things good enough. I have tried to capture as many relationship as possible which define the daily business activities of a cinema.

Browse More Articles

Tweet

Written by Leo

Thank you for taking your time to browse through our blog. We try to build as much rich content base as we can. We focus in modern technologies, computer science design and business.