Creating a Single View Part 2: Schema Development

< View all blog posts
Eric Holzhauer
March 13, 2015
Category: Business

In part 1 of this series on single views, we discussed how to revise the mental model of your data in order to create a single view with MongoDB. Our example scenario is a retailer that sells both on the Internet and in stores. As a reminder, the old data model might like like this:

Traditional Mental Model

… while the new model we proposed looks like this:

MongoDB Mental Model

Keep those in mind as we get into some of the details of implementing this new model.

Single View Schema

In the first post in this series, we asked the required questions about how you want to use your single view, and we designed a data model around that. In our example, the Customer and Product documents might look something like this:

Document Structures

Pretty straightforward. Here are a few tips:

  • Use arrays for multiple relationships – a single customer has multiple locations, and might be affiliated with multiple organizations.
  • Store data in a way that makes sense and provides flexibility. Instead of a field called “home address” and a field called “work address”, we’re using a single field that can store an array of all relevant locations.
  • Tags can be used to profile a customer. E.g., you could label a customer top_10_percent or flight_risk, and drive actions based on that.
  • The Actions array is a generic container that allows for related objects to be managed with the profile and be used in the appropriate context. What does that mean? Well, it might store the top information that sales or service reps need for their interactions, for example.
  • Within the Customer document, we can store purchases and engagement details in the Product array.
  • BUT we can link out to Product documents for all the product details.
  • Similarly, Product documents can store comments/reviews, and link out the Customers that left them.

What might that look like in JSON? Here’s an example for a Customer document:

Not too difficult. You can clearly see the main sections of the document: customer metadata, actions, and products (just like in the diagram).

Great, you’ve built a working prototype. But remember what we said in part 1 about prototyping and then iterating quickly? Suppose you want to add sentiment analysis to this first version. No problem. With a dynamic schema, evolving your data model is easy. Here’s a first version of how you might integrate some sentiment analysis:

Document Structure + Sentiment

In this diagram, we’ve added two fields to the Customer document – one for personal sentiment (how the customer is generally predisposed to feeling) and one for the specific sentiment towards your company. In the Product document, we’re using an array to store more details about specific interactions.

Once again, JSON. Here’s the new customer document:

As you can see, this first implementation is very simple. We’ve summarized sentiment at a high level – the customer is either friendly (1) neutral (0) or unfriendly (-1), and either likes us (1), doesn’t have an opinion (0) or actively dislikes us (-1). Again, as you add more detail and gradation to your sentiment analysis, we can easily evolve the way we store it in MongoDB.

Wrap It Up for Me

Here’s a throwback to some of the questions in part 1. The specific way you design your schema will, of course, depend on your data. But you should always return to the guiding questions in order to design something that makes sense for your own use case. If you’ve read all of the above and have gotten lost – or if you just skipped down to here for the summary – you should take away these two principles for designing a Single View:

  • What is at the center of your single view? Is it the customer? The product? Or, like in our example, both – with appropriate linking and embedding?
  • What questions are you asking of your data? Access patterns should drive the data model. The questions you can’t answer today will become your queries once you’ve built your single view in MongoDB, and your data model should be optimized for them.

Of course, there’s another big question that wasn’t addressed in the first two parts. Your data is currently all over the place – how do you actually get it into MongoDB? Stay tuned for the upcoming part 3 for some answers to that question.

While you’re waiting, you can download a white paper to learn more about how MetLife built a single view of the customer with MongoDB.

Read about MetLife Now

<< Read Part 1

Read Part >>



About the Author - Eric
Eric Holzhauer is a Product Marketing Manager at MongoDB

comments powered by Disqus