The real world if full of context that introduces meaning into our data. DBMS systems can benefit from the management of these contexts and a representional approach to defining what the meaning related contexts are.
What is a relationship? There are two parties, and a rolle that describes the relationship. So a customer could be related to an address with the roll of billing address. But the same customer could be related to another address with a different role called sales address. There could be even more address-customer relationships with different roles. So what if you just said customer has an address. and that is all you need to know (as a user of "customer")? The role of the relationship is describing it's context.
There are two sides to this situation. There is the user of an information model, and the author of the information model. Both want it simplest for themself. Traditional techniques for defining relationships with many roles or contexts are that the structure contains the names of the role as the field name defining the relationship. There are maybe totally seperate models for a sales domain and for a billing domain, so sometimes the model never even integrates these concepts together.
Why not try to have the best of both worlds? That is for a user, just refer to th4e address as the address, and the author can determine what the various kinds of customer-address relationships can exist. This is a ternary relationship. If this is to be used in SQL, the queries to navigate such a model would become too burdensom to be usable to a wide audience.
Posts
