5.5 Navigability

The UML defines the direction of an association as navigability. Object-oriented programming languages allow you to choose the direction of references freely by placing them in either the one or the other class. In the relational model the direction of a relationship is mostly implicit, depending on the relationship type and cardinality.

Navigability is paradigm-dependent by nature. It doesn't make sense to put navigabilities into conceptual diagrams (of any notation), since any assumption on "who references who" implies some kind of paradigm behind the model. Default ER diagrams don't have arrows for referential relationships. Neither classic Chen nor crow foot notation have any.

Navigabilities are a logical and physical level feature. They may help undestand who references who, but aren't necessary. The following table shows the applicability for navigabilities in dependence of the modeling level and paradigm:

Navigability in Dependence of Modeling Level and Paradigm
Paradigm
Level NoneRelationalObject-Oriented
Conceptualno paradigmrelatively uselessnot important
Logical n.a.mostly implicitfreely choosable
Physical n.a.mostly implicitfreely choosable

Fowler wrote in his book "UML Distilled, 3rd Ed.": In conceptual models, navigability isn't an important issue, so I don't show any navigability arrows on conceptual models. What he means here is, that in object-oriented models you can freely choose who references who and consequently isn't important on the conceptual level yet. In the relational model, the foreign keys are implicit, that is, they can't be chosen freely. This makes using navigabilities in conceptual models somewhat useless, especially for in relational diagrams. I usually use navigabilities in my models, but it's mostly because I don't deal with a lot of conceptual models.

Sloppily expressed, navigabilities are reversed for the relational model when compared to the object-oriented paradigm. In object-oriented models references usually originate from the higher-level aggregated classes/objects to the parts. In the relational model the logic is reversed: the foreign keys must go from the "many" to the "one" table. You can freely choose the direction of references with one-to-one cardinalities on them. Note however, that, as an example, a car has one engine, and the engine clearly represents the part from which the navigability should originate. This also allows cars to have more than one engine without redesign, e.g. a carburetor and an energy cell.

For many-to-many relationships using the relational paradigm, the navigability will always go from the "join table" to the interconnected entity types. For many-to-many relationships using the object-oriented model, the navigability depends on the implementation choice: either the two interconnected classes refer to each other directly, resulting in bidirectional navigability, or they use an intermediate associative class, which basically results in two bidirectional navigabilities.

Note, that there are other directions associated with relationships, like the reading direction of the relationship name. The reading direction of a relationship name/label has nothing to do with navigability and is the domain of naming conventions.

Last updated: 2010-10-13