Look, in the sky! It’s a Relation; It’s an Object System; No, It’s a Graph!
Sometimes when dealing with OO design in conjunction with relational persistence (RDBMS), it becomes difficult to reconcile the differences between the two and still maintain a consistent approach.
The problem that I seem to run into time and again is that I’m an OO programmer first. I tend to think of things top-down. What’s the overall system look like? What are the large pieces? What fits “in” those large pieces?
When you work this way, you tend to end up with a tree of objects or even more complex graph of objects. The interesting thing about a graph of objects is that it is, above all else, a graph, and there are many ways to represent graphs.
Fundamentally, all graphs are a set of Nodes and (directed) Edges, lets examine a few common ways to represent nodes and edges.
- Each node knows which other nodes it connects to. In other words, the nodes know there out-going edges. This is close to how most common OO programming languages work; an object is the node, and any reference to another object is a one-way edge.
- Each node knows which other node connects to it. The nodes know about there in-coming edges. This is the strict opposite of the above. It is also common in relation models with one-to-one relationships.
- A list of nodes and a list of edges are maintained independently from each other. This is common in relational models with many-to-many relationships.
- A combination of all of the above.
Any graph can be represented in any one of the above ways (as well as many others). This is important to realize, because it gives you the ability to refactor an OO design into something that better fits the relational model. There will always be a disconnect between OO and RDBMS, because they look at design in fundamentally different ways, but that doesn’t mean you can’t work with both of them in the same system, leveraging their individual strengths.
Tags: graph theory, graphs, object system, OO, rdbms, relational