Introduction to data modeling - MongoDB Tutorial

- [John] In this course, we're going to dig into the process of modeling data in a NoSQL database, specifically with MongoDB. We'll be working with a simplistic data model as a concept, a social media service. And we'll use that to navigate our way through some of the basic mechanics of modeling, including describing our entity, including building relationships, applying some validation rules to our model, understanding deeper how those relationships may work, including one to one, one to many and many to many relationships. We use a modeling tool to help visualize our data. And finally, we'll create some data in our Mongo database. And we do some example queries to assert how those relationships can work. Let's go ahead and get started with a preview of what we're about to learn in this course. What is a data model? And why do we care? Well, in applications, users want to work with tangible things, like their bank account, their shopping cart, their email address, their social media posts, their grades, whatever. But in computers, as coders, we need ways to reference these things. In object-oriented programming, we define objects which have tangible proper and inherent abilities or methods, which often include ways to change them. OOP concepts are interlocked with the database. In a database, we need to store these things for later retrieval so that the app can manipulate them, so that, in turn, the users can interact with them. Data modeling is a way to describe an object in a way that all three of these forces can use them in a similar way that makes some logical sense. As an example, here's a look at a simple data point, a customer. This is a good preview of where we're going to go in this course. In addition to other bits of data, we know that customers typically have many addresses that we might need to ship things to, like their home address or their work address or a family members address, and so on. At its core, a NoSQL database is made up of collections of documents, each, which is simply adjacent object that represents the composed data model. Look at here, how we fully described a customer, exactly as you as a human would visualize them. Modeling in NoSQL becomes an exercise in translating your metal model of something directly into data. Not only trying to pick it apart and separate into smaller and smaller related bits and normalize everything to pieces. Think of it this way. If you can describe it in English, you can write it in JSON, and then you can model it directly into MongoDB. It's a beautiful thing. Let's take a look at what this a simple data model looks like in an ERD tool that's designed specifically for this purpose. And here's our ERD for that same customer model as created through a visual modeling tool called Moon Modeler. This gives us a nice high level view of the shape of the objects that we're modeling. It'll looks similar to other ERDs that you've probably seen, but notice how we're able to describe some of the depth of the object in ways that traditional database simply cannot do. Here, the customer addresses property is actually an array of address objects. Again, representing the entity as it would be talked about or seen in the real world. Now, how does that visual look in code at the database level? Without getting into too much detail, here's how this looks in code. On the left, we have our model definition which provides some basic information about the shape of our data, including the field names, their data types, and so on. And on the right, we see our record as it was stored in the database using this data model. We've gone now from a JSON view of the data that we want to work with in our application code to a visual drawing to definition code, and finally, live data. How does all of that come together in a large application? Let's dig into it as we continue this course on data modeling with MongoDB.