(Business) data is relatively stable. A customer always has a name, a number, some contact info and an address, among others. An address always has certain fields, etc.

Navigational patterns are relatively unstable. The way you want to navigate the data varies from application to application, from day to day. Today, you want to know the customer's address, tomorrow, you want to search for an address, and then find the customer for it. The next day, you need statistical data about your customers grouped by the zip code of their addresses, the day after that, you need to know all customers that live in the same area as your top accounts.

'''Therefore''', decouple data and navigational information.

Don't make navigational patterns part of the data representation (at least not of it's published interface known to its clients; putting navigational information in as an implementation detail to improve performance is fine as long as it's transparent to the users).

Instead, provide an api or query language to the clients of the data representation that allows them to define how to navigate the data in whatever way becomes necessary.

'''Known uses:''' RelationalDatabase''''''s [any other?]

------

Isn't this another way to say avoid ReinventingTheDatabaseInApplication? ''It's also a pattern for the design of databases themselves.''
 
You mean if you set out to build your own Oracle or MySql?

----
CategoryInformation