Graph Databases for Enterprise Master Data Management


Jim Webber & Ian Robinson, Neo Technology

image

Master data is the lifeblood of any enterprise.

Yet, it’s often isolated in many different silos across your organization, with varying degrees of quality, accessibility, overlap, redundancy and different data formats.

The practice of master data management (MDM) identifies, cleans, stores and – most importantly – governs the growing volumes of master data in the enterprise. The umbrella of master data includes mission-critical information such as users, customers, products, accounts, partners, sites and business units.

Best practices for MDM vary along a wide spectrum of approaches. On one end, some MDM professionals believe all master data should be merged into a single location; while on the other end, some merely recommend managing data assets from a single service or application, even as data is stored in several separate locations.

In both cases (or any hybrid solution), enterprise data architects need a data model that’s flexible and fluid as exceptions arise and business requirements change.

That model is a graph database.

The Key Big Data Challenges in Master Data Management:

Today’s enterprises are drowning in ‘big data’, most of which is essential master data. Managing the complex relationships between all of these data points is possibly the biggest challenge facing today’s enterprise data architects. Others include:

  • Data complexity:  Master data is integrally connected with hierarchical, lateral and diagonal connections at every turn. Managing such complex data models with a relational database requires unwieldy code that is slow to run and time-consuming to maintain.
  • Real-time performance issues: Master data stores must integrate with and provide data to a host of business applications within the enterprise – often in real time. However, traversing these complex datasets for real-time insights is a significant challenge.
  • Dynamic data model: Master data is inherently dynamic, making it difficult to model and maintain using relational databases.

The Solution: Graph Databases

The cost of a poorly built MDM system ripples throughout your enterprise since master data is so highly connected and shared. In fact, most legacy MDM systems are built with a relational database that isn’t optimized for traversing this highly connected data.

Yet, relationships within your master data are essential to sustainable competitive advantage as business analytics evolve.

The good news: Graph databases utilize the ideal data model for storing and querying highly connected master data.

With graph databases, modeling your master data is simpler and more straightforward, costing you fewer modelers, DBAs and developers than you would need with a relational database.

Furthermore, a graph database doesn’t require you to migrate all of your enterprise’s master datasets into a single location. Graph database relationships can easily connect data that’s siloed in Customer Relationship Management (CRM) systems, inventory systems and financial systems to provide a consistent view of your master data.

Case Study: Personnel Hierarchy Data

Within the world of master data, a hierarchy is defined as any structure with nodes that have related nodes above and below them, possibly with multiple branches.

For example, one master data hierarchy would be personnel reporting and supervisory structures like the one pictured below.

image1

Figure 1. A master data hierarchy showing personnel reporting and supervisory structures. This hierarchy model would traditionally serve as a model with a relational database.

A small hierarchy like the one above is easy enough to model and maintain with a relational database, but as soon as you need to model a much bigger set of employees, both querying and maintaining the dataset gets prohibitively more expensive.

Consider this: What if one employee gets a promotion? Every relationship must now be reset for every personnel hierarchy in which the employee participates. This is a relational modeling nightmare waiting to happen.

In reality, pure hierarchies rarely exist. Enterprise personnel report to multiple people, not just one, and sometimes reporting relationships are transitional or seasonal.

Instead of pure hierarchies, most enterprise personnel are actually arranged as networks with plenty of real-life complexity and different kinds of reporting relationships.

Here’s what our earlier hierarchy might look like if it was re-envisioned as a network (or graph).

image2

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

Business needs change and personnel reporting relationships are just one example of why traditional hierarchical data must be reimagined as graphs. Once data is reorganized within a more flexible model, tracking it all within a graph database is incredibly easy.

While this case study examined personnel hierarchies, the same idea of master data networks can apply to product listings, document relationships and sales or customer data.

Conclusion

Today’s enterprise-grade data-driven decisions aren’t based on siloed information. Rather, your master data management solution needs to give you real-time insights into data relationships.

Graph databases are built precisely to support those essential data relationships. A graph database’s more efficient master data model and query language means you’ll find more relevant answers faster and with greater flexibility than ever before.

Have more questions about using a graph database for your enterprise master data? Click here to download this The Top 5 Use Cases of Graph Databases white paper.