Pookie, relationships always give me trouble too. (Oh, wait, you were talking about TABLE relationships....)
I have to give you my generic "object model" advice. Start by identifying entities that can exist in isolation. Each such object becomes the focus of a table.
I see customers, policies, agents, and underwriting companies (?). Four tables. Each has some prime key (PK). These PKs will become foreign keys (FK) in other tables. When table A's PK becomes an FK in table B, it is table B that references table A.
I'm thinking likely that your customer would be autonumbered since names are not likely to be unique. The customer table will tell you data unique to each of your customers. The PK of the table might also double up as a customer number, with the understanding that if it is an autonumber, you are NOT going to have contiguously numbered customers.
Policies? If policy numbers are inherently unique, there is your PK. If not, autonumber. (But I've yet to see an insurance policy that didn't have a number of its own...)
Agents? If they have some unique insurance industry identifying number, there is your possible PK. Otherwise, autonumber. I'm thinking about medical doctors who have special numbers that register them with the State of Louisiana Board of Medicine, so that prescription fraud/abuse can be tracked. That kind of numbering is what I mean by industry identifying number.
Underwriters? If there is an industry-wide identifying number,that could be your PK. If not, autonumber.
OK, lets go back and look a relationships.
If a customer can have more than one policy, you put the customer number as FK in the policy entries. This is a many/one//policy/customer case. BUT if a single policy can also cover more than one customer then you need something called a junction table between the two. The Search function of the forum will help you there. A junction table can be as simple as two FKs and nothing else. Also, a junction table inherently has two many/one relationships - one each for the two tables joined by the junction table.
If the policy can only be issued by a single agent, the issuing agent's PK becomes FK in the policy table. If the policy can be issued jointly, you have another junction table. Same logic as before.
If the policy can only be underwritten by a single company, the issuing company' PK becomes a FK in the policy table. If a single policy can be jointly underwritten, you have another junction table on your hands.
If you have more entities than this, refer to the above for the kinds of questions you ask to set up the relationships.
