Master Data Management – Five Things to Know

In the world of master data management, silos are a tremendous challenge.

When enterprises try to process information from disparate systems, they too often use sub-optimal applications and initiatives laden with errors and misinformation, not to mention blown timelines and budgets. But master data management (MDM) is actually more than just the breaking down of data silos. It’s about efficiency and service, innovation and security, clarity and perspective. It’s about getting the most of your most valuable resource: your data.

Here are the five things you need to know about MDM:

The Challenge of Multiple Data Systems

For existing enterprises, one of the largest hurdles to developing an MDM system is the multiplicity of databases and applications usually involved. What’s more, Enterprise Resource Planning and Customer Relationship Management systems rely on structured data, whereas the proliferation of IoT devices has created exponential growth in unstructured data.

Take the example of Enel, which is one of the largest power utilities in Europe. Enel was struggling to provide analytics and reporting across all of its power generation plants and equipment. They see data flowing in from multiple systems, including IoT devices on power generation equipment, plant maintenance systems, scheduling applications, and other sources. Each of these data sources has its own data types. Enel was exporting data to csv files and manually aligning the data to generate reports and analytics.

Other companies in similar scenarios might invest in expensive integration bus systems to support a polyglot persistent environment.

Enel found a solution in a native multi-model database. This allowed them to bring all data into a single database. This means no more worrying about different data types or keeping the different systems in sync. The result was real-time data analysis across all sites and multiple data systems. No more month-long manual processes to manually generate reports.

Master Data Management Really is for Everyone

All companies are now digital enterprises. Since all systems rely on data, MDM is a discipline in which all organizations need to remain competitive. Master data powers everything from financial reporting to real estate transactions to fraud protection. The ultimate results are faster and better decisions, improved customer satisfaction, enhanced operational efficiency, and a better bottom line.

Redundancy Elimination is Only Part of It

Most people who’ve heard of MDM immediately link it to one of its primary objectives: the elimination of redundant data. Yes—having a central repository of data will eliminate data redundancies, as long as it’s done correctly. But the benefits of MDM extend beyond redundancy elimination. Namely: data consistency, data flexibility, data usability, and data security (from role-based access).

Mergers and Acquisitions Don’t Have to Mean a Master Data Management Nightmare

Mergers and acquisitions can be rough on data consistency. Reconciling several master data systems brings headaches from different data system taxonomy and structures. This usually results in two systems remaining separate and linked only through a special reconciliation process.

As more acquisitions and mergers occur, the problem compiles into a labyrinth of siloed systems and data. This brings you back the problem that spurned you to invest in MDM in the first place.

The answer lies in the database management system and vendor you choose for your master data MDM system. Make sure to choose a vendor that offers a flexible, multi-model database that allows you to easily develop a single data taxonomy.

The Database that Backs Your Master Data Management System is Key

The most powerful and effective MDM systems run on databases that fit the business model in question.

As an example, Xima Software uses networks that are like graphs. As such, for a telco, an MDM system via a multi-model graph database is the most effective MDM strategy because the database allows for easy visualization of the network since it uses the same graph model.

Master Data Management is Evolving

If there were a fifth thing you needed to know about MDM, it’s that it’s rapidly evolving to meet the needs of today’s enterprises and their customers. Retailers are using it to improve time-to-market and address their customers’ growing expectations to deliver a true omnichannel experience. The consumer packaged goods industry is using it to ensure the accuracy of nutritional information and comply with local disclosure regulations. And every industry is using it to break down data silos.

Gerard (Jerry) Grassi, P.E.
Senior Vice President – OrientDB
SAP

OrientDB is a Graph Database “on steroids” because it supports concepts taken from both the Document Database and Object-Oriented worlds.

Take a look at this use case:  Creating a graph to map the relationships between Person and Cars.  We’re going to use the just-released OrientDB version 1.5.  

Let’s open a shell (or command prompt in Windows) and launch the OrientDB Console (use console.bat on Windows):

> cd $ORIENTDB_HOME/bin
> ./console.sh

Now we’re going to use the console to create a brand new local database:

orientdb> create database plocal:../databases/cars admin admin plocal graph

Ok, now let’s create the first graph schema with “Person” and “Car” as 2 new Vertex types and “Owns” as an Edge type:

orientdb> create class Person extends V
orientdb> create class Car extends V
orientdb> create class Owns extends E
And let’s go populate the database with the first Graph elements:
orientdb> create vertex Person set name = ‘Luca’

Created vertex ‘Person#11:0{name:Luca} v1’ in 0,012000 sec(s).

orientdb> create vertex Car set name = ‘Ferrari Modena’

Created vertex ‘Car#12:0{name:Ferrari Modena} v1’ in 0,001000 sec(s).

orientdb> create edge Owns from (select from Person) to (select from Car)

Created edge ‘[e[#11:0->#12:0][#11:0-Owns->#12:0]]’ in 0,005000 sec(s).
Ok, now we can traverse vertices. For example, what is Luca’s car? Traverse from Luca vertex to the outgoing vertices following the “Owns” relationships:
orientdb> select name from ( select expand( out(‘Owns’) ) from Person where name = ‘Luca’ )

—-+—–+————–
#   |@RID |name
—-+—–+————–
0   |#-2:1|Ferrari Modena
—-+—–+————–
Perfect. 
Now we have the location of Person and we need another Vertex type called “Country” to connect to the person with a new “Lives” Edge type:

orientdb> create class Country extends V
orientdb> create class Lives extends E


orientdb> create vertex Country set name = ‘UK’

Created vertex ‘Country#14:0{name:UK} v1’ in 0,004000 sec(s).

Next, let’s associate Luca to the UK Country:

orientdb> create edge Lives from (select from Person) to (select from Country)

Created edge ‘[e[#11:0->#14:0][#11:0-Lives->#14:0]]’ in 0,006000 sec(s).

So far so good.  Our graph has been extended. 
Now, try to search the country where there are “Ferrari” cars in our database.

orientdb> select name from ( select expand( in(‘Owns’).out(‘Lives’) ) from Car where name like ‘%Ferrari%’ )

—-+—–+—-
#   |@RID |name
—-+—–+—-
0   |#-2:1|UK
—-+—–+—-

Setting constraints on Edges

Now we’ve modeled our graph using a schema without any constraints. But it would be useful to require an Owns relationship to exist only between the Person and Car vertices. So, let’s create these constraints:

orientdb> create property Owns.out LINK Person
orientdb> create property Owns.in LINK Car

The MANDATORY setting against a property prevents OrientDB from using a lightweight edge (no physical document is created).  Be sure to pay attention and not put spaces between MANDATORY=true.

orientdb> alter property Owns.out MANDATORY=true;
orientdb> alter property Owns.in MANDATORY=true;

If we want to prohibit a Person vertex from having 2 edges against the same Car vertex, we have to define a UNIQUE index against out and in properties.

orientdb> create index UniqueOwns on Owns(out,in) unique

Created index successfully with 0 entries in 0,023000 sec(s).

Unfortunately, the index tells us 0 entries are indexed. Why?  We have already created the Owns relationships between “Luca” and “Ferrari Modena.”  In that case, OrientDB had already created a lightweight edge before we set the rule to force creation documents for Owns instances. So, you need to drop and recreate the edge.

orientdb> delete edge from #11:0 to #12:0
orientdb> create edge Owns from (select from Person) to (select from Car)

Now check that the record has been created.

orientdb> select from Owns

—-+—–+—–+—–
#   |@RID |out  |in
—-+—–+—–+—–
0   |#13:0|#11:0|#12:0

—-+—–+—–+—–

So far so good.  The constraints works.  Now try to create a “Owns” edge between Luca and UK (Country vertex):

orientdb> create edge Owns from (select from Person) to (select from Country)

Error: com.orientechnologies.orient.core.exception.OCommandExecutionException: Error on execution of command: sql.create edge Owns from (select from Person) to (sel…
Error: com.orientechnologies.orient.core.exception.OValidationException: The field ‘Owns.in’ has been declared as LINK of type ‘Car’ but the value is the document #14:0 of class ‘Country’

Now we have a typed graph with constraints. 

The next part will cover how to use polymorphism feature in the graph.

Luca Garulli, CEO

Orient Technologies, the Company behind OrientDB
http://about.me/luca.garulli




Take your enterprise to the next level with OrientDB