You may have noticed than when an object type is the result of a nested predicate, you can specify extra information on the "Nested Roles" tab of the "Database Properties" window. This is provided in case you wish to add extra semantics between the relationship of the nested object type and the object types that make up the fact type that was nested.

For example, consider the following ORM model:

While the combination of a Lot and Street comprise the notion of a Location, we may wish to express more detail about the relationship between Lot and Location or between Street and Location. For example, we may wish to note that a Location is assigned a Lot or that a Street contains a Location. We can do this, via nested role readings, as illustrated below.

However, recall that a nested object type can be transformed into a co-referenced object type. Further, I’d say that if you need to include these sorts of semantics, then you are better off co-referencing anyway, as in the model below.

Thus, while conceptually speaking either one works, the latter model is less semantically awkward. Further, there is no real tool or technical advantage to either option as they both map to the same table and column structures. Nor will adding these nested role readings alter the related column names: in either case they will usually end up being LotNbr and StreetName and/or LocationLotNbr and LocationStreetName depending on how other facts use the Location object type (perhaps a topic for another post).