Learn More about the Master Data Management Use Case of Graph Databases in the EnterpriseMaster data is the lifeblood of your enterprise.

The umbrella of “master data” includes vital data such as:
    • Users
    • Customers
    • Products
    • Accounts
    • Partners
    • Sites
    • Business units
Many business applications use master data and it’s often held in many different places, with lots of overlap and redundancy, in different formats, and with varying degrees of quality and means of access.

Master Data Management (MDM) is the practice of identifying, cleaning, storing, and – most importantly – governing this data.

MDM best practices vary along the spectrum of merging all master data into a single location to managing data assets for easy access from a single service or application. In both cases (or any hybrid solution), enterprise data architects need a data model that provides for ad hoc, variable and exceptional structures as business requirements change.

That sort of rapidly evolving model fits best with a graph database.

In this “Graph Databases in the Enterprise” series, we’ll explore the most impactful and profitable use cases of graph database technologies at the world’s leading organizations. In past weeks, we’ve examined both fraud detection and real-time recommendation engines.

This week, we’ll take a closer look at master data management.

The Key Challenges in Master Data Management:

Today’s enterprises are drowning in “big data” – most of which is mission-critical master data – and managing its complex relationships can be quite a challenge. Here are some of the most complicated hurdles in MDM that enterprise’s must face:

    • Complex and hierarchical datasets
    • Master data, such as organizational and product data, has deep hierarchies with top-down, lateral and diagonal connections. Managing such data models with a relational database results in complex and unwieldy code that is slow to run, expensive to build and time-consuming to maintain.

    • Real-time storage and query performance
    • The master data store must integrate with and provide data to a host of applications within the enterprise – sometimes in real time. However, traversing a complex and highly interconnected dataset to provide real-time information is a significant challenge.

    • Dynamic structure
    • Master data is dynamic in nature, making it harder for developers to design systems that accommodate its evolution.

Why Use a Graph Database for Master Data Management?

Because master data is highly connected and shared, poorly built MDM systems cost business agility in a way that ripples throughout your enterprise. Most legacy MDM systems rely on a relational database which isn’t optimized for traversing relationships or rapid responsiveness.

These data connections and relationships in your master datasets are essential to competitive advantage as business analytics evolve. The good news is that graph databases are ideal for modeling, storing and querying the hierarchies, metadata and connections in your master data.

With graph databases, your master data is much easier to model, costing you fewer resources (modelers, architects, DBAs and developers) than building a relational solution. In addition, with a graph database, you don’t have to migrate all of your master data into a single location. Graph relationships easily connect your siloed data between CRM systems, inventory systems, accounting and point-of-sale systems to provide a consistent vision of your enterprise data.

Example: Employee Hierarchy Data

In your master data, a hierarchy is any structure where nodes have other nodes above and below them, possibly with multiple branches. One example of a master data hierarchy is employee reporting and supervisory structures like the one pictured below.

A master data hierarchy illustrating employee reporting and supervisory structures. Traditionally, this hierarchy would serve as a model in a relational database.

A master data hierarchy illustrating employee reporting and supervisory structures. Traditionally, this hierarchy would serve as a model in a relational database.

A small hierarchy such as the figure above is easy enough to model and maintain in a relational database. But as soon as we model a much larger set of employees, both querying and maintaining the data gets more expensive.

For example, if an employee gets a promotion, every relationship must be reset for every hierarchy in which the employee participates.

Of course, such pure hierarchies rarely exist in the real world. Employees often report to a multiple people, and sometimes reporting relationships exist only for transitional reasons (such as job shadowing or coverage).

In fact, most business hierarchies are actually networks filled with real-life complexities and many kinds of relationships.

See the figure below as an example of our earlier hierarchy re-envisioned as a more realistic network (or graph).

A master data network detailing employee reporting and supervisory relationships, this time with more real-life complexity. This network would serve as a model in a graph database.

A master data network detailing employee reporting and supervisory relationships, this time with more real-life complexity. This network would serve as a model in a graph database.

Traditional hierarchies need to be reimagined as networks that are easier and more flexible to model with a graph database as business needs change.

While the example discussed has to do with employee reporting relationships, the same principle of master data networks applies to product listings, document relationships and sales or customer data.


The best data-driven business decisions aren’t based on stale information silos. Instead, you need real-time master data with information about data relationships.

Graph databases are built from the ground up to support data relationships. With more efficient modeling and querying, organizing your master data in a graph yields relevant answers faster and with more flexibility than ever before.

Download your copy of this white paper, The Top 5 Use Cases of Graph Databases, and discover how to tap into the power of connected data at your enterprise.

Download the White Paper

Catch up with the rest of the “Graph Databases in the Enterprise” series:



About the Author

Jim Webber & Ian Robinson , Chief Scientist & Senior Engineer

Jim Webber & Ian Robinson Image

Jim Webber is Chief Scientist at Neo Technology working on next-generation solutions for massively scaling graph data. Prior to joining Neo Technology, Jim was a Professional Services Director with ThoughtWorks where he worked on large-scale computing systems in finance and telecoms. Jim has a Ph.D. in Computing Science from the Newcastle University, UK.

Ian Robinson is an Senior Engineer at Neo Technology. He is a co-author of ‘REST in Practice’ (O’Reilly) and a contributor to the forthcoming books ‘REST: From Research to Practice’ (Springer) and ‘Service Design Patterns’ (Addison-Wesley). He presents at conferences worldwide on the big Web graph of REST, and the awesome graph capabilities of Neo4j.

Leave a Reply

Your email address will not be published. Required fields are marked *