Let's say you have an event content type that points to a person content type and you want to show a list of people in all events. So you create a view with the event as the base type, then add a relationship to the people references by the events. You try it out and find some people show up multiple times.
No problem! We'll just check the "Distinct" checkbox on the query settings. So you do this, but find you're still getting repeats. Looking at the query, you see the DISTINCT is applying to the event node.nid database column, so it's show each person once for each event she shows up in. Even after removing all field, filter, and sort references to the base event, that nid still shows in the query, so the results aren't really distinct.
You can solve this problem by reversing the relationship. If you want distinct people, start with the person content type and point back to the events. This would be a pain if you had to go through and reverse the node reference field, especially if you already have a lot of content entered. Fortunately, changing the field isn't necessary, as the References module has solved this problem with relationships that follow node references (and user references) backward rather than forwards. Unlike a few previous solutions to this problem, the Feferences solution doesn't create any redundant data to capture the reference going both directions. It just uses the existing reference and some clever Views code.
This should solve more than the distinct problem, making it easier to create a variety of complex views based with relationships. Currently the backward reference functionality is only available in the development version of References, but it should show up soon in a stable release.