Navigability means according to the UML specifications:
that instances participating in links at runtime (instances of an
Association) can be accessed efficiently from instances at the other
ends of the Association. The precise mechanism by which such efficient
access is achieved is implementation specific. If an end is not
navigable, access from the other ends may or may not be possible, and
if it is, it might not be efficient.
In your example, this means that:
the association can be read in both ways; navigability does not change the fact that there is an association with two sides;
an instance of
OrderDetail can easily and efficiently find the associated
it is not guaranteed that
Item could find all its associated
OrderDetails, and if it could, it might not be efficient;
navigability has nothing to do with the multiplicity.
There is no rule about how to implement such a link. This is completely implementation dependent. Examples for your case:
- In a RDBMS, an
OrderDetailTable would have a mandatory
ItemId column with the
Id of the related
Item, and the
ItemTable would have
Id as primary key. As a consequence, it would be extremely efficient to find the
Item fir navigation. It would also be possbile to find all the
OrderDetails that are related to an
Item, but it might not be as efficient if the necessary indexes are not created.
- In Java, the
OrderDetail class could have a integer member
ItemId. You could have an
ItemRepository class with a method
findById() that would return for a given integer the corresponding
- In C++ you could have in the
OrderDetail class a member that points to a specific
Item. In this case, the opposite navigation is practically impossible if there isn't a pointer in the other direction.
As you see, this in very dependent of the implementation language, the related idioms and techniques chosen (e.g. integer id vs pointer). It also depends on the multiplicities, the kind of ownership, as well as access path designed for other associated classes.