Are your non-employees still there?

LATEST TWEETS

Graph Databases for Enterprise Master Data Management

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.

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.

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.

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).

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

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.