 Now things are not very nice in the context that they can fit nicely into tables into rows and columns, single valued that may not always be the case. The data may be multi valued and for example if you look at a book the book has chapters the chapters have sections and sections have sub sections this is true for documents also. Now these things don't fit nicely into the relational model. Similarly maybe in certain cases the metadata has to go inside the table where the main data is stored. So these are the challenges which are difficult and complex for the relational model. So that's why we are using and we are people are using the NoSQL database solution. So in this module I will talk of the current trends, the problems with the conventional model and some of the precautions also. So this is kind of an ambitious module which I will be covering over here. So what are the trends? The data which is which is being generated it is unstructured. As I mentioned before and I will mention again like the tweets they are unstructured there is lot of data behind the tweet which is not as a matter of fact visible to the users and then their Facebook posts also. So of course email has been around for a while and the search engines can use and act as per our requirement. We can use the search engines but the search engines cannot differentiate between what we are actually looking for why because by nature the search engines are not precise they are not exact. So we have to write the queries which either should not queries in double quotes the terms which should not generates thousands of results which are not related or the results which are the links generate are very few. So for handling this massive task and emerging problems we need to have other solutions but as of yet there is no killer solution of NoSQL but we hope that the solution will come. So these are the challenges these are the issues of the relational model schema redesign overhead so if there is a slight change in the process or in the database that ripples throughout the schema and lots of changes have to be made and but the problem is that if you look at Twitter there are many very different ways of writing the message. So how can you ensure that the database which you had designed today is going to work tomorrow or maybe after six months and of course then there is the examples of XML also. So this is one issue which is the schema redesign. Then is the unstructured data explosion maybe a decade ago 80% of the data was unstructured and now that number is more. Businesses gather the data public data government data other data which is available from the tweets for sentiment analysis from other external sources to get a wholesome picture and that data is heterogeneous that data is not structured that data doesn't fit well as a matter of a doesn't fill in the relational model. So the boundary between the search engine and the databases is blurring but databases in the context of no SQL also remember that search is not precise database as in the context of relational are very precise. So we may be also looking for frequent co-occurrence for example if people type a message then which things are going together for example in the case of medication which medication is proposed on a log on a web log with reference to which kind of ailment which is going together we are not going towards talking about the identifying the entities from the natural language processing this is a more complex problem. So then is the sparse data problem blank columns in RDVMS. For example people have few contacts and the table may have multiple spaces for the context so the space is wasted storing 99% nulls this space is wasted over here and why because the RDVMS has to allocate the disk space no SQL no nulls are stored no space is allocated more in in the next module. So you can see over here no space used no space used no space air marked no space air marked saving of space saving of space. So this is a no SQL solution this is a no SQL solution okay so you see the benefits then of course dynamically changing relationship discovering new levels of connection in LinkedIn in LinkedIn okay in the RDVMS then will be access many to many relationships and there will be complex relationships to handle for example what if you want to know all people within three degrees of separation of a person this is a common statistics on LinkedIn just writing the SQL gives you a headache return all people who are related to person one or have a relationship with person two okay or is related to person three who is related to person four who is related to person one and no duplicates okay no duplicates this is a very complex query triple and graph store news no SQL databases are designed with dynamically changing relationships in mind they specifically use a simpler data model but a terrific scale to ensure these questions can be answered quickly okay so this is not an RDVMS is not there this is no SQL okay triple store so you see that you can do wonderful things and no SQL benefits and precautions low cost alternative to quickly handle difficult problems right but look at the total cost of ownership look at the features which are not there for which the subscription has to be paid for which the support is to be required for which you have to combine multiple no SQL solutions to get the solution which you require and there are always new data types coming there are new challenges and there are new paradigms so that's all I have for this module thank you for your time