MOVIE DATABASE SYSTEM

DOCUMENT DESIGN

AMBER SINGH(2018BCS-005)

AVANISH PANDEY(2018BCS-014)

TANAY SAXENA(2018BCS-055)

TAPAS SAHA(2018BCS-056)

VAIBHAV MISHRA(2018BCS-061)
 TABLE OF CONTENTS

1. Design Consideration
1.1. Assumption
1.2. Constraints
1.3. System Environment
1.4. Design Methodology
2. Architecture
2.1. System Design
3. Data Design
3.1. Data Description
3.2. DFD Diagrams
3.3. Data Dictionary
1. Design Considerations : -

​ 1.1. Assumptions:-

Since the project describes an online movie review system, the

following assumptions were made:

1. End Users are sufficiently skilled for basic web browsing activities
and can navigate the website intuitively .

2. The End Systems from which the website will be used, are
relatively modern
(Support JavaScript from ECMAScript5(JS5) and above , for
ReactJS) .

3. End-Users have sufficiently fast Internet Connectivity to be able to

load content from the website.

4. It is assumed that end users had already watched the movie which
is being rated.

5. It is unknown what particular platform the website will be viewed

on.

1.2. Constraints:-

1. Rating of a movie by users is constantly updating .Furthermore, it

might be possible a particular movie is watched and being rated
frequently, Therefore the database for storing and updating these
must be fast to update and fetch results from.
 2. Scalability is a major consideration, as the platform is meant to
serve several users concurrently, at an unpredictable rate. It is
necessary to ensure Quality of Service doesn’t degrade at scale.
3.There might be the possibility that data provided by end users (
Name , Email Id etc. ) can be misused and hence data security is a
major concern . This requires handling and storing encrypted data.

1.3. System Environment:-

1. The back-end of the system runs remotely on a server, accessible

only by developers and administrators. The server is in a barebones
configuration, simultaneously also containing the Database for the
Movie rating system as well as the Recommender System. All of
these modules are exposed to the backend via different ports
accessible internally only. This server can be worked on by admins
via SSH.

2. Front-End of the systems runs on Web Browsers, running on

unknown/random platforms. These may be any devices that contain
internet browsers that support JavaScript. These systems must have
displays, and input methods in the form of mouse and keyboard.

1.4. Design Methodology:-

For the development of the platform, we are using the Iterative

Waterfall Model.
Since our project has different aspects, like Front End, Backend and
Machine Learning, usage of the Iterative Waterfall Methodology
would be ideal.
 The linear nature of the waterfall development method makes it easy
to understand and manage. All the three modules would be
developed independently, going through all the steps of the waterfall
method and then these modules would be merged by going back
through all the steps and making the required changes in each
step.As the modules are completed, they are integrated to the main
platform, and then tested. If testing reveals any problems, then we go
back to the previous step of the iterative waterfall, and change what ​is
necessary to ensure seamless integration.Thus, after all modules are
added we are left with the fully-featured platform, ready for
production.

2. Architecture
2.1. System design

System design is the process of designing the elements of a system such

as the architecture, modules and components, the different interfaces of
those components and the data that goes through that system. The
purpose of the System Design process is to provide sufficient detailed data
and information about the system and its system elements to enable the
implementation consistent with architectural entities as defined in models
and views of the system architecture. In this phase, the complex activity of
system development is divided into several smaller sub-activities, which
coordinate with each other to achieve the main objective of system
development.
 ​Figure 1.1

Context diagram
3.Data Design
Data description The data used in the application is either received from
the user or is requested from the API server. All of this data is of
alpha-numeric form and is input into the application either from user
interface or from the reply from the API server in response to the request.
Google Firestore is used to store information related to the user, including
the 4 login credentials and the categories selected by the user. The data
relating to polls created by the admin is also stored in the Google Firestore.
All the data stored is relevant for the application for it’s functioning, from
logging into the app to accessing news articles.

3.1. DATA DESCRIPTION

Our data is divided mainly into 3 tables, viz. users, Movies, Feedback.The
users table contains only the necessary information required from a user to
store login information. The user can watch multiple movies and can make
a playlist of their own by adding or deleting a movie .
The Movie table has all necessary details about a movie like
genre,cast,Director etc. according to which a user can choose a movie as
per their liking. Users can choose movies listed by specific
Director/Cast/Genre as any type can have multiple movies. It is updated by
Admin whenever required or when a new movie has to be uploaded in the
database.
Finally, the feedback table is to maintain the rating system by users so that
it can be recommended to others. The users can review the movie in detail.
3.2. DFD Diagrams

Level 0 DFD Level 0 DFD captures various entities external to the system
and interacting with it. Data flow occurring between the sLEVystem and the
external entities. Level 0 DFD is also called context diagram. A context
diagram establishes the context of the system, i.e. data sink and data
sources.

LEVEL 0 DFD:
LEVEL 1 DFD:

Process movie rating

Process movie review

Process updating movie detail
LEVEL 2 DFD:

Process movie rating

Process movie review

Process updating movie detail
3.3. Data dictionary

Field Type Null Default

Users Id Int NO AUTO_INCR

E MENT

Name String YES NULL

Email String NO -

Password String YES NULL

Field Type Null Default

Movie Id Int NO AUTO_INCR

E MENT

Name Varchar NO -

ImagePath Varchar NO -

Director Varchar NO -

Producer Varchar NO -

Cast Varchar NO -
 Duration Int NO -

Story Varchar YES NULL

Type Varchar NO -

Field Type Null Default

Feedback Feedback Id Int NO AUTO_INCR

E MENT

UserName Varchar NO -

Email Id Varchar NO -

Feedback Varchar YES NULL

Rating Int NO -