"Each" developer would hopefully not have their own representation, but a developer in one group might be using different representations than a developer in another group. This can happen because the data models they work with evolved at different times. The cable industry used to regard a premise and a customer as being the same thing, whereas today it sees a customer as related to any number of premises.
Ideally, you would define a common canonical form that every team has to work with, at least in its external interfaces. This usually entails working directly with business units to reconcile their differing definitions of customers, supplies, products, and so forth.
When this is not possible, either because such a form does not adequately describe the business realities, or because of other factors like politics, there are several potential compromises:
1) You could define a 'superset' form, with elements from each competing view. The problem here is that a sparsely populated data set might be insufficient for some required processing.
2) You could define a set of rules for working across the boundaries, in other words processing that can translate between views. This is not uncommon, but leads to many, many more translation possibilities than defining a canonical form with translations defined for each non-compliant form.
Finally, when "several make sense", I would suspect that when viewed from a broad enough business perspective, one would make more sense than others.
This was first published in July 2008