MongoDB Overview / Data Modeling and MongoDB

5:21
One of the key benefits of MongoDB is that its flexible schema lets you design a data model that fits your application specific needs. To do this, you need to consider how your data relates and how you'll access it. In this video, we'll cover some foundational concepts in data modeling for MongoDB. First, we'll review the core principle of data modeling with MongoDB. Next, we'll define two key terms in data modeling, entities and attributes, and how these correspond to documents and collections. Then we'll focus on types of relationships among data, one to one, one to many, and many to many. We'll also explore how to model these relationships by using approaches called embedding and referencing. Throughout this video, we'll be applying these data modeling concepts to a movie application. Let's get started. As you set up your data model with MongoDB, remember the core principle. Data access together should be stored together. If you keep this in mind, it will help you design efficient schemas. Now let's take a closer look at how to organize your data effectively. This starts with understanding entities and attributes. Each piece of information in our database can be related to the other pieces. We call these pieces of information entities. An entity is a unique and independent object or concept in your application, like a user, a product, or a blog post. In MongoDB, entities are typically represented as documents and are organized into collections. For example, in our movies application, we might have entities such as movies, users, and comments. Each of these would correspond to a collection of documents. Entities are described by attributes, which are characteristics that define them. For a movie entity, its attributes could include title, genre, and rating. In MongoDB, attributes are represented as field value pairs within a document. An attribute can also be a subdocument that groups related data. For instance, a movie document may have a subdocument that lists all of the cast members. Now we know entities and attributes. Let's talk about how we model our data based on relationships that exist among entities. There are three primary types of data relationships, one to one, one to many, and many to many. A one to one relationship is the most common in MongoDB. One to one relationships exist when one entity is related to exactly one other entity. In the database for a movie app, the relationship between a movie and a movie studio is a one to one relationship. A one to many relationship is when one entity is related to multiple other entities. For example, a movie typically has multiple cast members. Finally, a many to many relationship is when multiple entities are related to multiple other entities. A movie may be shown in many theaters, and a theater typically shows many different movies at a time. With MongoDB's flexible schema, we can model these relationships by either embedding or referencing data within documents. Embedding is the practice of storing related data within a single document, like how we've embedded the movie cast in an array here. Referencing, on the other hand, is the practice of linking documents by storing a reference to another document's ID similar to the concept of a foreign key in a relation in database. So how do we know which approach to use? This is where understanding your access patterns is really important. Embedding is the best approach when data is accessed together, like displaying a movie and its cast on a single page. This strategy minimizes the number of operations needed to retrieve your data, improving performance. On the other hand, if data is accessed independently, like if movies and actors need their own distinct pages, referencing is the better choice. In this case, you would add actor IDs to the movie document, linking them to their own separate documents. In addition to access patterns and relationships, there are a few other factors to consider. When embedding data, we need to watch array and document size because we don't want either to grow too large. And when referencing data, it's important to remember that we will have to use multiple queries or a lookup operation to retrieve related data, which can cause latency issues if we aren't careful. You can also use schema design patterns to model your data effectively with MongoDB. These patterns can help you optimize data storage, streamline queries, and improve application performance based on your application's specific access patterns and workload requirements. Nice work. Let's recap what we covered in this video. We discussed some foundational principles of data modeling, including the key idea that data accessed together should be stored together. We defined entities, attributes, and types of relationships that exist among them in our data. One to one, one to many, and many to many. We also discussed the differences between embedding and referencing, the importance of understanding your access patterns, and how to choose the right approach to data modeling for your application.