Professional Analysis of Database Structure and Relationship Model

Contents

TOC o “1-3” h z u REPORT PAGEREF _Toc19996228 h 2Database Structure description: PAGEREF _Toc19996229 h 2Datamodel(Relationship) PAGEREF _Toc19996230 h 5Alternative modeling discussed: PAGEREF _Toc19996231 h 7Recommendations: PAGEREF _Toc19996232 h 8References PAGEREF _Toc19996233 h 9

REPORTDatabase

In MongoDB, database known as physical container of many collections. Each and all databases is saved as file in the file system. Multiple databases will contained by single MongoDb server.

Collection

Many of Documents can made a single collection in MongoDB. Same can we found in RDBMS tables where table made from many attributes.

In a collection with in a database every documents fields may differ. ideally, all the documents within a collection will use for the related or similar purposes.

Document

For Defining the Document there is a key-value pair set is taken. Schema of document is usually dynamic.By the meaning og dynamic schema is that every document can have some different fields set and their datatypes can also differ.

Datamodelling main challenge is to balancing the application requirements and database engine performance attribute and pattern of data access.

When we design the database models we need to keep in mind the usage of data of application like data processing, queries and updates and also the built-in structure of the data itself. (Sadalage and Fowler, 2012) .In SQL databases we must needs to determine declare the database and table schema before insertion of data but in MongoDB database collections and its documents represents the same schema. These are:

Reference relationship made easy to access data between many collections in a database.

This flexibility smoothes documents mapping to or an object an entity.

Matching of data fields for the created entity for every document have performed, when document varied from another documents with in the collection. (Vaish, 2013)

Figure shows the database creation.

Below we represent the one document for collection movies in mongoDB database schema:

db.game.insert(

{“_id” : “1207472156”,”title” : “Wordscapes”, “description” : “Get the incredibly addicting word game that everyone is talking about! Starts off easy but gets challenging fast. Can you beat the game?”,”mainGenre” : “Games”,”genre2″ : “Education”, “genre3″ :”Word”, “genre4” : “Puzzle”, “gameCenterEnabled” : “FALSE”, “releaseDate”: “2017-06-14T14:39:50Z”,”supportedDevices” : “iPad”, “contentAdvisoryRating” : “4+”, “language1” : “EN”, “language2” : “”, “language3” : “”, “language4” : “”, “language5” : “”, “language6” : “”, “language7” : “”,”language8″ : “”, “fileSizeBytes”:170917888,”minOsVersion”:”9″,”developerID”:”517840947″,”developerName”:”PeopleFun, Inc.”,”developerUrl”:” “price”:5.99, “currency”:”USD”, “averageUserRating”:”5″, “userRatingCount”:”413922″, “currentVersion”:”1.1.7″, “currentVersionReleaseDate”:”2019-08-05T20:49:20Z”, “currentVersionNotes”:”Bug fixes”, “averageUserRatingForCurrentVersion”:”5″, “userRatingCountForCurrentVersion”:”16782″})

Creation and insertion Of collection Game:

Datamodel(Relationship)Here we will discussed about how the relationships were handled in the database

The Schema of database is very flexible in MongoDB. In this database can have multiple collection and collection can have many documents and every document may differ in fields and data types for a single collection.

Some considerations will keeping in the mind while we design the Schema for a database in MongoDBWe must fulfill the user requirement when we design the schema of a database.

Objects should be combined in a document if we needs to use the altogether, else separation needs to be done but there should be no need of joins

We can entered duplicated data ,yet in limited amount because disk space is cheaper than computed time.

Joins should be performs on write operation not on read operation.

When we found repeated use cases we should optimize our schema.

Can perform complex aggregation.

The important decision for designing the data models for application of MongoDB depends on the structure of the documents and also depends on how the relationship maintains between document/data in any application. (Plugge and Membrey, 2014)

In MongoDB relationships are defined on the basis of matching data in columns in different collections. These relationships are defined on the basis of semantics. The MongoDB engine does not impose this relationship, this is completely dependent on the application how to implement and respect this relationship while we perform reading and writing data in collections for any database.

References must stores the relationships between data by references or links between documents. With these reference relationship Application Database can retrieve or access the related field/data. So we can say these data model are normalized. In our database creation we have maintained the relationship by referencing the GameID(_id) from “game” Table to other needed.

Example shown below for movie and ratings tables:

References relationship should be used:

For implementation of one-to-many(1:N) relationships between documents.

For implementation of many-to-many(N:N) relationships between documents.

When the referenced entities are updated frequently.

When the referenced entities indefinitely growing.

Movies table contains the MoviesID as Primary key

Ratings Table contains the MovieID as foreign key which create the relationship between the tables

Alternative modeling discussed:

Here we will discuss potential alternatives to how the relationships could have been modeled and implemented in MongoDB and the benefits/issues of each

We can also reference the document by embedding documnents , but in this relationship the database will be denormalized. In this type of relationship related data is stored within a single document, so the data retrieval and maintenance would be easy. This type of data model is known as denormalized data model. By this model manipulation and retrieval of related data for an application can be perform in a single database operation. But today the database is growing very fast, in this situation we need to deal with large databases,so this approach is inefficient to handle. (Chodorow and Dirolf, 2010).

Embedded documents should be used when:

Contained relationship is existing between entities.

The embedded entities are not updated repeatedly.

The embedded entity is an essential part of the document.

Relationships range from one to a few, between embedding and embedded entities.

The embedded entities do not grow indefinitely.

Recommendations:

We used here the director name as index whist is text based searching but we can also use phrase searching by creating index for phrase like a sentence like comments field to make as an index. (Hoberman, 2014)

As an example we taka a collection messages and make index for content which contains a phrase,

db.messages.find({$text: {$search: “animal who cook”}}, {score: {$meta: “text Score”}}).sort({score:{$meta:”text Score”}})

The ouput will show the result

{ “_id” : ObjectId(“55f5289cb592880356441ead”), “subject” : “Animals can be cook”,

“content” : “Birds do not eat rats”,

“likes” : 50, “year” : 2015, “location” : “Chicago”, “language” : “english”, “score” : 3 }

{ “_id” : ObjectId(“55f5289bb592880356441eab”), “subject” : “Cats eat rats”,

“content” : “Rats do not cook food”,

“likes” : 60, “year” : 2015, “language” : “english”, “score” : 0.77777777777777}

ReferencesSadalage, P., S. and Fowler, M.(2012) NoSQL Distilled. USA: Addison-Wesley.

Chodorow,k. and Dirolf, M.(2010)MongoDB:The Definitive Guide. 2nd ed. USA: O’Reilly Media.

Banker, K. (2011) MongoDB in Action. USA: O’Reilly Media.

Plugge,E. and Membrey,P.(2014) MongoDB Basics. USA: Apress.

Hoberman,S. (2014) Data Modeling for MongoDB: Building WellDesigned and Supportable MongoDB . USA: Technics Publication.

Vaish,G. (2013) Getting Started with Nosql. UK: Packt Publishing.