This post is part of a series on managing and analyzing graph data. Posts to date include:
- Graph data model basics
- Relationship analytics definition (this post)
- Relationship analytics applications
- Analysis of large graphs
In late 2005, I encountered a company called Cogito that was using a graphical data manager to analyze relationships. They called this “relational analytics”, which I thought was a terrible name for something that they were trying to claim should NOT be done in a relational DBMS. On the spot, I coined relationship analytics as an alternative. A business relationship ensued, which included a short white paper. Cogito didn’t do so well, however, and for a while the term “relationship analytics” faltered too. But recently it’s made a bit of a comeback, having been adopted by Objectivity, Qlik Tech, Yarcdata and others.
“Relationship analytics” is not a perfect name, both because it’s longish and because it might over-connote a social-network focus. But then, no other term would be perfect either. So we might as well stick with it.
In that case, “relationship analytics” could use an actual definition, preferably one a little heftier than just:
Analytics on graphs.
At the risk of sounding circular, I’ll try:
Relationship analytics is analytics that focuses upon relationships encoded in data.
Notes on that proposed definition include:
- The more directly the relationships are encoded — for example by a node-edge-node graph data model — the more applicable the term is likely to be.
- It can still be relationship analytics if the nodes of the graph are ultimately more important than the edges. The edges just have to be central — no pun intended — to the analytics.
- “Analytics” is a vague term, and “relationship analytics” inherits the vagueness. That said, I think of relationship analytics as being more about investigative analytics than the operational kind.
So what do you think — does this definition of “relationship analytics” work?