Graph DB for PLM : Schema evolution

Graph DB for PLM : Schema evolution


Yoann Maingon
Yoann Maingon
@yoannmaingon
Graph DB for PLM : Schema evolution

One of the characteristics of PLM is the need for flexible data models. You can argue that and tell me that everyone should follow standards so you don’t have to build your own model and you don’t have to make any change. But believing that is letting Excel or other spreadsheets win. Rely on a fixed schema and you will get an excel based underground PLM.

Therefore once you acknowledge you need a flexible datamodel, we can cover some technological comparaison to see what is the best technology out there to support these concepts. Today I want to compare two datamodel changes one with an SQL database and the other with a graph database.

One use-case that I had to handle in the past is a change of type for a collection of objects. The customer use to have all its parts handled with a “part” class, makes sense. A classification was done to define if the part was mechanical, electronic or software. But at some point the management of software information became a lot different than the part information. Therefore we were asked to takes these softwares and migrate them to a new “software” class.

Updating a datamodel with a SQL database

This is not an exact process because each PLM system will have its own mecanisms and tools to play with data. But basically in terms of db data manipulation you will need to do the following:

  • identify the data to change = could be the result of a SQL query.
  • Identify the relationships impacting this change. a Part to Document relationship will result in a new relationship between a software and a document. Your PLM system will make it easy to create the new relationship but not to transfer the existing instances of this relationship.
  • Create the new table = hopefully your PLM system does that for you
  • Modify the extracted data to fit with the new Software class table. (and the new relationship as well)
  • Re import the data, hoping you made all the right modification to fit with the new datamodel.

Updating a datamodel with a Graph database

For the graph database we will take neo4j as the example.

  • identify the data to change = could be the result of a SQL query
  • identify the relationships, to potentially update their name.
  • Change the label of your nodes from Part to Software
  • Change the label of the relationships you wanted to rename
  • Done !

That’s the beauty of it. The indexation will work then to create a new index for software and update the one for parts, but that’s it. Many software editors will claim that this is too technical and never happens. Well, talk to the integrators, if they’ve worked with a customer for multiple years they know it happens.

Related Articles

Going to GraphConnect 2018
Databases

Going to GraphConnect 2018

Looking at the picture you can tell that I am in the NYC area to attend GraphConnect 2018. GraphConnect is a major conference organized by Neo4J, the graph database. During a bit...

Posted on by Yoann Maingon
db-engines.com : selecting your data storage layer
Databases

db-engines.com : selecting your data storage layer

Data is the essence of most applications and this is particularly true for PLM. How you store the data is a key aspect of your PLM application. It will define how much data you...

Posted on by Yoann Maingon