G.W.
The wizard cloned the table reference to create a 'permanent' self-referential relationship that the Lookup field thought it needed. (One reason why we don't like Lookup fields on this forum.) The reference is benign in that it is only a pointer. As long as you have the lookup field, though, you probably should not delete it. The lookup field wizard created it for a reason.
(Edit: I see that Minty and I were answering at about the same time.)
The relationship reference is benign but the lookup field in the table might not be. These lookup fields cause all types of headaches as you go forward. Within the last month we've had a couple of folks who found that building a query against a table with a lookup field was a non-updateable query even though under any other circumstances it might have been. The lookup field causes an ambiguity that prevents the query from allowing an update. It is the ambiguity that is the problem because there is now an implicit JOIN to a multi-valued table behind the table that has the lookup field. Stated another way, a lookup field carries baggage with it, and it is not always good baggage.
Ridders
The benefit of having a duplicate entry in the relationships window has to do with self-referential data elements where the central theme of the database is the relationships between/among like objects.
Example: In a genealogical database, you have a list of people. You have relationships between records such as "record 196 is the father of record 231 IN THE SAME TABLE" (and the converse "child" declaration, of course). In such a database, you will probably have lots of queries that need to exploit that self-referential type of relationship.
Example: In a project management database you have milestones, but you quickly find that there are dependencies such that Milestone X cannot even start until Milestone W has finished. Again, the interdependence of the various Milestones leads to a self-referential relationship in the relationship window. If you have a lot of queries to write that will exploit the interdependence, then you make it permanent in the master window rather than in the individual query design window. Not to mention the implied documentation value that comes when you have such a relationship staring you in the face.
3rd (and last) example: Sometimes we get people who have an inventory database for things that they make on site, and they sell both the things they make AND the raw materials that a crafts person might use to make such things themselves. They have relationships for the "assembled" items that reference the components that made them, and the junction table that itemizes components of an assembly needs two references to the same inventory table, one for the assembly and one for the components. Again, you need the double reference, though in this case it is to support the junction table rather than a direct reference in the inventory table itself.
In all cases, if the physical relationship of self-referentiality exists (despite what my spell-checker says), then by all means document it in the relationships window!
