Ict704 The Relational Databases Answers Assessment Answers

Indexes Created: - 

We have created two indexes in our database. So that searches are faster when various queries are made on our database.

1. db.MoviesDB.createIndex ({"Director":1}); : -

This is the first index created by us. This index is created on the basis of Director. When we went through the queries, we came to know that there are various searches associated with the Director name. Making an index on the basis of the Director will make the searches associated with it faster. 1 father the Director denotes that we are using Ascending order while creating the index. The search results are noticeable and easily affected by indexes when we have the bulky database and there is the very large number of documents in our Collection.

1. db.MoviesDB.createIndex ({"RatingsArr":-1}); : -

This is the second index created on the MoviesDb collection. This index is created on the basis of RatingsArr. We have a number of queries on the basis of RatingsArr. -1 denotes that the index is created in descending order. Making an index on the basis of ratingsArr will make the searches associated with it faster.  The search results are noticeable and easily affected by indexes when we have the bulky database and there is the very large number of documents in our Collection.

Handling of relationship in our Database: - 

 We have used Embedded Relationship in our database design. All the rating documents are embedded inside the Movies documents. So each movie document contains its own relationship. We are using ZERO to MANY relationships in this document. So each movie may have one or more ratings associated with it. But each rating can only be associated with one and only one movie document. Also, as the Rating documents are embedded inside the movie document, they have a direct relationship.

No Rating document can exist without his Parent movie document, but a parent movie document can exist even without a rating document. If a parent movie document is deleted then all its child rating documents are also deleted with it as they are embedded inside it. But even if a Rating document is deleted, its parent movie document will continue to exist without it also.

Potential Alternatives of relationships could have been modelled and implemented in MongoDB: - 

There are two typeset relationships possible in MongoDB.

1. Embedded Relationship: -

 We have already used this type of relationship approach in our database design. In this type of database design approach, the child documents are stored inside the parent document. There may be One to One or One to Many relationships among the documents. The child documents are embedded inside the parent document. So they can't even exist without them. They are deleted as soon as the parent document is deleted. 

Advantages of using Embedded Approach: - 

1. a) Performance: The main advantage of using the embedded approach is performance. The queries run faster when all the data is present in one document as compared to the case where it is spread over multiple documents. 

1. b) Easier: It is easier to write queries when using the embedded approach. 

1. c) Atomicity: MongoDB ensures atomicity at a document level. Document updates for a single document are always atomic as compared to document updates on multiple documents. 

1. d) Correctness: When multiple users are using MongoDB parallel, two or more users may try to update the same document with different data. In such a case mongo DB can ensure that no conflict occurs if the data is contained in a single document, but this can't be ensured in case of multiple documents. 

Disadvantages of using Embedded Relationship: 

1. a) Size: In mongo DB the maximum allowed size of a document is 16 MB. When one document contains several documents, then this limit might exceed. 

1. b) When the same data is needed across multiple documents, it is better to use Referenced Relationship. 

1. Referenced Relationship: - 

This is the second type of relationship that exists in MongoDB. In this instead of embedding the child documents inside parent document, we will just store the references to these documents inside the parent document and these child documents can be stored as a separate parent document. As we are just storing references, so they will continue to exist even when the parent document is deleted.

Advantages of using Referenced Relationship: - 

1. a) No Duplicity: For conditions where the same document is to be referenced or used from multiple documents. We can use the referenced relationship approach and we just need to store the reference of this child document. 

1. b) Consistency: As the same document is shared among all the documents, and all the documents just have the reference to this document. Any change to this document is reflected in all the parent documents. 

1. c) Size: As the child comments are stored in separate documents, they have their own size. It helps in moving over the limitation of 16MB document size in MongoDB. 

Disadvantages of using Referenced Relationship: - 

1. a) Complex Queries: Queries are complex in referenced relationship approach as compared to the queries in the embedded approach. 

1. b) Performance: Referenced relationship approach takes more time to fetch results as compared to the embedded approach.

Recommendations to Movie maniacs for additional functionality of the database: - 

1. Trailers: We can also store the movie trailers or link to the trailer of a movie inside our database. So it will become very easy for anyone using database to go and access that trailer. 

1. Cast: We can store the information about the main cast in the movie. 

1. Posters: We can store the posters of a movie or link to the posters for easy access by anyone using the database.

1. Description: We can add a column description, which will store the information about the movie. So that anyone using the database can read it and have a brief idea about the movie.

 Stores: We can store the information about online Movie rentals or stores where the user can find this movie. 

Bibliography:

Alam, M. (2014) Oracle NoSQL database. New York: McGraw-Hill Education/Oracle Press.

Celko, J. (2014) Joe Celko's complete guide to NoSQL. Waltham, MA: Morgan Kaufmann.

Copeland, R. (2013) MongoDB applied design patterns. Sebastopol, CA: O'Reilly Media, Inc.

Dayley, B. (2015) Sams Teach Yourself NoSQL with MongoDB in 24 hours. Indianapolis, Ind.: Sams.

Eliot, G. and Ashton, R. (2018) The mill on the floss. [Nederland]: Penguin Books.

Francia, S. (2012) MongoDB and PHP. Beijing: O'Reilly.

McCreary, D. and Kelly, A. (2014) Making sense of NoSQL. Shelter Island: Manning.

Mehrabani, A. (2014) MongoDB high availability. Birmingham: Packt Publishing.

Mongodb. (2012) [Place of publication not identified]: Betascript Publishing.

Perkins, L., Redmond, E. and Wilson, J. (2018) Seven databases in seven weeks. Raleigh, N. C.: The Pragmatic Bookshelf.

Vaish, G. (2013) Getting started with NoSQL. Birmingham: Pack