Okay, before we do anything in this course, we need to understand what the MongoDB document model really is. If you're familiar with JSON, JSON makes a great mental model for what records in MongoDB look like. In a relational database, you simply store rows in a table, and each row is a record. MongoDB is a document database, and the type of record that's stored in MongoDB, or a document, is a hierarchical data structure that matches the type of data structure you'll see in high level programming languages like Python. You can think of MongoDB as storing JSON documents, so if you're familiar with JSON, you'll be very comfortable with what's possible in terms of a structure for documents in MongoDB. A MongoDB document consists of fields. Each field has a key and a value. So here, these are keys, and these are values. Where things get interesting is that values can be integers, they can be strings, they can be floating point numbers, but they can also be arrays, embedded documents, or documents, or arrays that contain embedded documents. There are essentially three different structures that values in MongoDB can take on. Those are scalar values such as an integer, or floating point number, or string. Dates would be another type of scalar value. Then there are arrays, and finally, as values, you can have documents, here's another example here. The idea here is that MongoDB allows application developers to model their data in a way that makes the most sense for an application. Here, we have an example drawn from the e-commerce space, and this data is modeled so that reads and writes to the database are as efficient as possible. As a data scientist, you will both have to work with application data that is stored in a MongoDB database, especially with the increasing popularity of MongoDB. But there are also advantages as a data scientist in storing your data in MongoDB and those advantages align pretty closely with the reason why developers use MongoDB. You have the ability to interact with the database in a much more efficient manner than you can with a relational database because we can construct complex structures like this and the MongoDB query language, secondary indexes, and built-in analytics tools such as the MongoDB aggregation framework all support these data models. So here we have an example that represents a particular type of shoe, and what's interesting here is that we're able to represent all of the attributes of the shoe and all of the variants for the shoe. So what we mean by variants here are all of the different choices you can make as a consumer for the shoe. So, size, color, and so on, and the way this data model is designed, we can construct an index that would allow us to query for all shoes for which we actually had a size six in orange in stock, for example. From the application developer's standpoint, the idea here is that we can store everything we need to store in a single document so that we can render a web page with a single request to the database. So rather than doing joins across multiple tables, which is necessarily less efficient, we do a simple request, all of the data is stored sequentially in the same place on disk and in memory, and the request ends up being very fast. Note that here in this data model, we're actually including the reviews in with the product data itself, again, so that we can do a single request to the database to produce the webpage that would be generated by this particular document. As a data scientist, especially as you get more and more comfortable with the MongoDB query language and the aggregation framework, you can leverage this same query efficiency for the different types of analysis that you'll want to do on whatever data set it is you're working with. So again, the takeaways for the MongoDB document model are, think of it as JSON or think of it as a dictionary in Python. And within that dictionary, values can be scalers, they can be arrays, or they can themselves be dictionaries. And you can have any level of embedding and nesting that makes sense for your particular application. Now of course, you could have a completely flat data model if you so desired, with simply keys and values and all of the values being scalar, but there's usually a good reason to have some level of hierarchy in your data model. And typically that reason is one of efficiency or simplicity in terms of working with the data.
