DB modeling help

[nikola]

Hello everybody, I'm begginer in graph db world and I basically understand whole concept, but I need a little help with concrete problem.
I'm working on one EMS solution which will be used for controlling network devices. Spring data will be used on project.
The initial idea is to have 3 node types (entities):

1. Device model
2. Action
3. Command
   Command can be part of any action many times, one command should exist in many actions with different order of execution.
   Device model will be in relation with commands which are supported by that device.
   Action is set of commands in some specific order.
   Same action should be set of different commands and differently ordered based on device type. Order is important.
   Relationship will be created when some device supports action, and action should be in relation with commands, but based on device model.
   Does someone have an idea which is the best graph model for this kind of problem?
   Many thanks

[david_allen]

Before diving into a data model, it's best to consider what kinds of questions you want to ask of your data. Ideally, the data model should be constructed with this in mind, so that you know whatever you pick will be well-suited to the questions you need to ask of the data.

So why do you want this data, what kinds of questions do you intend to throw at it?

[koji]

Hi nikola,

I'm using Neo4j for a large network configuration. I don't know the details, but I've made a small sample graph to help.
It with 4 nodes. Device, Action, ActionCommand and Command.

The "Device" has 2 actions. "Create Something" and "Change Something".

"Create Something" has commands. "Set Param" > "Create Config" > "Execute Config"
"Change Something" has commands. "Set Param" > "Execute Config"

"Set Param" is "set a,b,c" command.
"Create Config" is "create some.conf" command.
"Execute Config" is "execute some.conf" command.

CREATE (d1:Device {name:'Dev 1'}),
       (d1a1:Action {name:'Create Something'}),
       (d1a2:Action {name:'Change Something'}),
       (ac1:ActionCommand {name:'Set Param'}),
       (ac2:ActionCommand {name:'Create Config'}),
       (ac3:ActionCommand {name:'Execute Config'}),
       (ac4:ActionCommand {name:'Set Param'}),
       (ac5:ActionCommand {name:'Execute Config'}),
       (d1)-[:ACTION]->(d1a1),
       (d1a1)-[:NEXT]->(ac1),
       (ac1)-[:NEXT]->(ac2),
       (ac2)-[:NEXT]->(ac3),
       (d1)-[:ACTION]->(d1a2),
       (d1a2)-[:NEXT]->(ac4),
       (ac4)-[:NEXT]->(ac5),
       (c1:Command {name:'Set Param', command:'set a,b,c'}),
       (c2:Command {name:'Create Config', command:'create some.conf'}),
       (c3:Command {name:'Execute Config', command:'execute some.conf'}),
       (ac1)-[:DO_COMMAND]->(c1),
       (ac2)-[:DO_COMMAND]->(c2),
       (ac3)-[:DO_COMMAND]->(c3),
       (ac4)-[:DO_COMMAND]->(c1),
       (ac5)-[:DO_COMMAND]->(c3)

[llpree]

Welcome to the community! One of the phrases you'll hear in the Neo community is "whiteboard friendly". The idea, and this relates to the "what questions will you ask of this graph", is relationships and the entities that enjoy those relationships are just real things - whether it's people in a social network, machines in a technology network, or just an intense conversation around philosophy/religion/politics, anyone with knowledge about the domain can begin to model on that "whiteboard".

BUT, make sure your model is of the entities and relationships - the "what" in the architecture and not the "how". What Euler discovered in his famous bridge problem, was how powerful graph principles are. But if you just create a spreadsheet in a graph, you'll loose the advantages. If you just put a workflow in a graph, again, you'll probably not uncover the weakness in an established "how".

So, while "device model" is a good attribute, a great architecture will be in designing the relationships in this network such that you can ask your graph questions that offer insights beyond attribution benefits. You might want to study how Neo has addressed physical network clients. There are some good whitepapers.

Just to offer you a hint at the power a graph can offer, in the model @koji shared, just looking at the shortest path between Dev 1 and Execute Config (there are two paths with one being shorter than the other - is that "good", "of interest" - and what about the dead ends in this graph?) begins to show how a graph looks at problem spaces differently. And once you get data into a moving, transactional system, how that data will support centrality (important entities/nodes) and other graph questions whose answers are trivial to calculate in a graph while often impossible or silly complex in a sql model - all this will begin to show you how a graph managing any network, will reap rewards. Maybe, because your "network" is so "physical", you might use metaphors of non-physical networks to expand your creativity. Make sense?

Advice on how to proceed? ...just begin to create an initial graph - remembering you're modeling what's real. The nodes and relationships are NOT abstractions, they are actual entities and relationships. You can adjust as you mature your model.

Oh, and don't forget that a "path" is a form of uniqueness. E.g., in @koji ...Dev 1 -> Set Param. There are 2 paths but are they distinct. Yes in the action, but is that right? Not saying one way or the other, rather showing how one can create a perfectly good model as this is, and yet begin to consider changes without that effort being some monumental task. One can even bring in non-tech folks to think things through.

HTH.

[llpree]

...and if you didn't know about it, use http://www.apcjones.com/arrows/# as an easy to use modeler. DO NOT PUT SECURE info in this but outside of that warning, this is a nice way to get going modeling.