More than one relational path

[frinholp]

I have got myself in a situation where I am trying to create more than one relational path between two tables in a graph.

I'm aware that I can't do this but I can't see any other solution to my problem.

Basically I am setting up a database for an art gallery where each peice of art has a category. A client can purchase a peice of art so therefore has a relationship with a peice of art. Also I want to enable a client to register an interest in a particular art category so again therefore creating a relationship between the two. This leaves me with the dilemma of more than one relationship between category and client.

I have included a screenshot of my relationship graph to clarify my situation.

Can anyone shed any light on the matter please?

Thanks in advance.

[Fenton]

First. Any given table can appear mulitple times, in multiple "table occurrences" (TO) on the graph. That is normal. They can have several reasons for existence, for functionality like filtering, or just because you need access again, and cannot create a loop (as you've found).

Your problem is a good simple example of why the "anchor-buoy" method, of breaking the graph into "table occurrence groups" (TOG) was invented. With that method, your chart would be broken into 2 or 3 TOGs; (Art, Orders, Clients) or just (Art, Client-Orders). In your case I would think just 2. But 3 would give it ultimate expansion cabablity; you could add tons of stuff for each, without this problem arrising again.

However, yours is simple enough (they all are to start with -) that one TOG may suffice. The problem is, as I see it, that ClientInterests should be coming off of Client (not Categories). Yes, it needs to connect to a Categories table occurrence, but only to see the Category name; it does not need to hang off the original Categories TO.

So, after putting ClientInterests off of Client, add ANOTHER instance of Categories off of it, at the end of that chain.

At some point you're going to need to review your naming convention. As you will see, just plain functional names can (eventually) have 3 major problems. 1. You cannot tell where any given TO is in the structure, nor what it is connected to. 2. They do not sort alphabetically when viewed in a list. 3. A TO may be used for more than one thing.

I use "structural" naming. Which is often longer, and perhaps less apparent in some ways. But, in my opinion, is the best method for large complex graphs, with many TOGs. It is often more important to know how something is connected than exactly what you've used it for (though I will sometimes add a word to describe that, like "VL" (used only for Value List), etc..

[frinholp]

Thankyou for pointing this out Fenton. I was treating the relationship graph as an ER diagram. I didn't know that you could have more than one occurrence of a table.

After I was made aware of this, I found the following post quite useful:

http://www.fmforums.com/forum/showtopic.php?tid/209662/

Thanks again