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.