Video : ER/Studio Data Architect
Model Data for MongoDB
MongoDB is a popular open-source, document-oriented NoSQL database developed by MongoDB Inc. Its design enables it to store and manage unstructured data across multiple servers, making it a scalable and high-performance database solution. MongoDB uses a flexible document data model, which allows data to be stored in a semi-structured format as a document, rather than in traditional tables and rows, like a relational database. This makes it easier to manage and manipulate large amounts of data in real-time and also allows for faster and more efficient querying and indexing. We often use MongoDB for web and mobile applications, content management systems, and real-time analytics, among other use cases.
The benefits of MongoDB include its scalability, flexibility, ease of use, and cost-effectiveness compared to traditional relational databases. Some advantages of using MongoDB include:
- Full cloud-based developer data platform
- Flexible document schemas
- Widely supported and code-native data access
- Change-friendly design
- Powerful querying and analytics
- Easy horizontal scale-out with sharding
- Simple installation
Data modeling is important for MongoDB because it ensures better database planning, design, and implementation, which leads to improved application performance. Modeling of data promotes faster application development through easier object mapping and better discovery, standardization, and documentation of multiple data sources. Data modeling allows data to be stored more easily in a database and has a positive impact on data analytics. MongoDB documents make it possible to embed document structures in a field or array within a document, and these denormalized data models allow applications to retrieve and manipulate related data in a single database operation. For many use cases in MongoDB, the denormalized data model is optimal.
Watch this video to learn how to model data for MongoDB with ER/Studio Data Architect.
Hello, and thanks for joining.
During this video, we’ll take a look at ER/Studio’s support for MongoDB, which began with ER/Studio XE6. Now, I know one of the questions you’re asking: “How does a tool that’s been used for relational database modeling go about modeling a NoSQL platform like MongoDB?” Well, we went ahead and used slightly different notation and we’ll take a look at that as soon as we get into the data model. But first, let’s start by reverse engineering a MongoDB database.
We’ll begin by launching ER/Studio Data Architect, and we’ll reverse engineer MongoDB the same way we would reverse engineer Oracle. We’ll go to File > New > Reverse Engineer and we’ll choose the native direct connection. Once you’ve done that, you’ll see MongoDB in the dropdown menu, alongside Oracle, SQL Server, and other supported platforms. We’ll enter the data source host name and our database credentials here. Clicking ‘Next’ will connect to that MongoDB, and we’ll want to choose a specific database out of that MongoDB to reverse engineer, Library in this case. And then what type of collections do we want to pull in, User and/or System, and in this case we’ll just choose User. On Page 3, we can be very specific as to which collections we want to bring into our model, so if we wanted to remove ‘Patron’, for instance, we could unselect it from the page. We’ll want to bring in all three of these for our example. On Page 4, you’ll see some greyed out options because they’re relational database specific. However, you can still infer domains and choose a layout option. Let’s stick with Orthogonal for this example.
Once it’s complete, we’ll have both a logical and physical model. We’re not too interested in the logical model because it’s database independent. So let’s go to the physical MongoDB model and take a look at what we have here. We’ll slightly spread the objects out a little bit, then we’ll take a look at the model. At this point, you’re likely asking two questions: Where did the address and checkout options come from, and what do these relationships mean? We’ll take a look at the MongoDB JSON code in a moment to better answer that question, but basically MongoDB collections have the ability to embed other collections within them. That’s what these relationships are referring to. In the case of Patron to Address, what we have here is a collection, Patron, that embeds an array of Address collections. The star on the Address side refers to that array, where within Publisher we only have one instance of Address, and therefore we see a one in place of the star.
Let’s open up the JSON in a text file and take a look. First, let’s look at the insert statement for Patron. If we look inside of this insert statement, we see Address and we see two instances of Addresses. Therefore, we have an array of embedded Address collections. Where in Publisher we also see Address, but we only see one instance of an Address, and therefore we have a single Address collection within Publisher. In the code, you’ll also notice that the Address section of Address code is slightly different between Publisher and Patron. In Patron, we have the square brackets that don’t exist up in Publisher. ER/Studio Data Architect reads those square brackets and realizes that there’s an array of embedded collections within the object that contains those brackets and therefore lays down the relationship line that we see between Patron and Address.
Now you also see typical IE-Crow’s Feet notation in this model. That’s because collections can also reference other collections. A good example of that is between Publisher and Book. If we look at the Book insert statement, you see that it references the Publisher ID. And of course you would read this relationship the same way you’d read a relationship in a relational model with IE notation. A publisher may have one or many books associated with them.
That’s it! That’s how ER/Studio Data Architect supports MongoDB.
- Webcast: 10 ER/Studio Productivity Tips to Help You Love Your Data Models
- Webcast: Making Connections: Enhance Data Models with ER/Studio 2016+
- Video: Agile Change Management in ER/Studio Data Architect Professional
- Video: Build a Logical Data Model with ER/Studio Data Architect
- Video: Data Modeling for Hadoop Hive with ER/Studio Data Architect
- Video: Data Modeling Techniques for Teradata Users
- Video: Document a Database As Part of a Broader Data Modeling Initiative with ER/Studio
- Video: Why Should A Data Modeler Care About Business Processes?
- Datasheet: Model Hadoop Hive for the Hortonworks Data Platform (HDP)
- Solution Brief: MongoDB Data Modeling with ER/Studio
- Solution Brief: Enterprise Data Modeling: 7 Mistakes You Can’t Afford to Make
- Solution Brief: Importing ER/Studio Data Models into WhereScape 3D
- Case Study: Global Financial Services Organization Turns to ER/Studio for High-Performance Data Modeling
- Case Study: Microsoft Deploys ER/Studio to Establish an Enterprise Data Model
- Case Study: Newmont Mining Standardized their Data Modeling Practices with ER/Studio
Topics : Data Modeling,
Products : ER/Studio Data Architect,ER/Studio Enterprise Team Edition,