Database Structure

NoSQL or “Not Only SQL” is the modern generation alternative for the traditional database management systems that were run using the relational model. NoSQL databases are characteristically useful in case of working with massive datasets and in needs of data analysis and scalability (MongoDB, 2018). Mongo DB is a NoSQL database that is used as a document based storage platform with higher flexibility and storage abilities. It is very flexible with indexing and querying as required for normal to complex database functionalities.

All organizations around the world are scoping their business databases to support NoSQL technologies which are well supported over the cloud servers and also allow tremendous scalable and agile performances when it comes to data storage and accessibility. In this report the MongoDB database for Movie Maniacs will be discussed. Their database structure will be explained alongside explaining the indexes that were created and how the relationships were handled. Alternative relationship techniques will be mentioned and the pros and cons of the same too will be critiqued. Finally, a set of recommendations will be suggested to Movie Maniacs to improve the performance of their database and also add better functionalities to it.

Database Structure

            Arora and Aggarwal (2013), says that the use of a MongoDb database seeks the use of a JSON-like document set which are flexible. Flexibility by the means of allowing to create database entities that do not specifically have any pre-defined structure. Unlike RDBMS or Relational Database Management System databases where the database schema needs to be defined beforehand, database collections here are more tangible and can be used as necessary (Gy?rödi et al. 2015). A particular field that is a part of one of the documents in a collection, may or may not be present in all other documents. This allows the easy alteration of data structure. MongoDB’s document makes it easier to work with data as it assists in the mapping of objects in application codes.

            The one and only collection that was used in this MOVIEMANIACS_DB database is MOVIES. This collection is what a table stands for in a relational database system. This collection has been used for the purpose storing the movie data of all the necessary movies from the system. Each document within this collection is meant to hold the data about a particular movie. The collection consist of basic data like the movies name and release year. It also has the movie’s director name and the list of leading actors who has worked in them.

Indexing Choices

This list has been embedded into the respective. Embedding is a special relationship establishing technique which will be discussed in details in a later section. Furthermore, the collection also holds data about the number of Oscars won by the movies. Interestingly, movies that have not won any Oscar at all, do not have the Oscar field in their document, within the collection. This is as mentioned earlier is one of the most important use cases of the NoSQL based MongoDb database systems. The reviews section is also trapped by this database.

Reviewers register their reviews with a data, comment and rating. These ratings are further embedded into array data structures within the MOVIES collection. Here too, only the movies that have reviews made by the audience has the Ratings array embedded, the rest are aloof of the array’s existence. This technique of the NoSQL not only allows better programming concepts but also helps in the reduction of program memory consumption.

Indexing Choices

            The indexing technique is an extremely crucial database accessibility feature of any database management system. In MongoDB, indexing allows an efficient mode of query resolution. Indexes are special data structures that segregate the indexed key fields and help in the retrieval of crucial data from the collections (Chodorow 2013). In this database collection of Movie Maniacs, the Movie Id field and the Ratings array has been indexed. This has been done keeping in mind the frequency of using these data fields in order to query specific results from the database collection.

Movie Id, being the unique identity key within the collection is certainly expected to be queried in the conditional clauses for the most number of times. The Ratings array field is however a tricky implementation within the collection and is hence segregated using the indexes. This has been by keeping in mind the rising complexity of the database when it grows, as more and more users are expected to put in their comments.

Relationship Techniques

            The embedding relationships have been established within the collection between the movies, actors and the ratings data. This makes the database more flexible as all data about the embedded entities can directly be sorted out within the same database collection and there is actually not any specific need for separated collection maintenance (Jia et al. 2016). However, the traditional reference relationship could have been utilized between the ratings and the movie collection. This would be more meaningful and would allow in easy readability of the database data. However, since there is no current need of other collections trying to link to the ratings data, the referencing procedure will not be as good a Mongo choice as embedding already is.

Recommendations

            The database should be enriched with more data about the respective movies. This includes the languages in which the movies were shot, the county of origin and also a graphical representation of the image through a poster or trailer cover. Furthermore, the database should also allow the separate maintainability of actors and directors’ collection. These collections will be able to store the details about each actor and director and also establish reference based relations with the MOVIES collection.

Conclusion

            The Movie Maniacs database can be better handled with a NoSQL database than with a RDBS structure. The tools and concepts of NoSQL and Mongo DB allows loads of big data analysis functionalities which will suffice to the future needs of the database and also help it to be more scalable and data retrieval friendly. The clever use of indexes and choice of relationship techniques have allowed in the better standardization of the collection within the database.

References

Arora, R. and Aggarwal, R.R., 2013. Modeling and querying data in mongodb. International Journal of Scientific and Engineering Research, 4(7), pp.141-144.

Bergamaschi, S., Po, L. and Sorrentino, S., 2014. Comparing Topic Models for a Movie Recommendation System. In WEBIST (2) (pp. 172-183).

Chodorow, K., 2013. MongoDB: The Definitive Guide: Powerful and Scalable Data Storage. ” O’Reilly Media, Inc.”.

Copeland, R., 2013. MongoDB Applied Design Patterns: Practical Use Cases with the Leading NoSQL Database. ” O’Reilly Media, Inc.”.

Gy?rödi, C., Gy?rödi, R., Pecherle, G. and Olah, A., 2015, June. A comparative study: MongoDB vs. MySQL. In Engineering of Modern Electric Systems (EMES), 2015 13th International Conference on (pp. 1-6). IEEE.

Jia, T., Zhao, X., Wang, Z., Gong, D. and Ding, G., 2016, June. Model Transformation and Data Migration from Relational Database to MongoDB. In Big Data (BigData Congress), 2016 IEEE International Congress on (pp. 60-67). IEEE.

Lv, Q. and Xie, W., 2014. A real-time log analyzer based on MongoDB. In Applied Mechanics and Materials (Vol. 571, pp. 497-501). Trans Tech Publications.

MongoDB. (2018). NoSQL Databases Explained. [online] Available at: https://www.mongodb.com/nosql-explained [Accessed 1 Oct. 2018].