confusing relationships



Hi All,

Firstly thank you for helping me with the initial hurdle of how to set up a
DSN etc. Now i have done that successfully and am in the process of designing
a database. I seem to have been stuck in a place i cant get out of.
The situation is like this..

Tables
---------
A contact table - Usual stuff here
An Insurance Table - All Insurance details
Spouse Table - Info about spouse
Child table - Child Info

Requirements
------
contact can have multiple insurances, children and spouses..
Each Child can have multiple insurances
Each spouse can have multiple insurances

Contact is the primary table....with insurance, spouse and child tables
linked in 1 - many relationships

Relationships
-------
Contact linked to Insurance with Contact ID (Primary key) and Foreign key in
Insurance 1-many
Contact linked to Spouse with Contact ID (Primary key) and Foreign key in
Spouse 1-many
Contact linked to child with Contact ID (Primary key) and Foreign key in
Child 1-many

Simillarly Spouse and Child are linked to Insurance with Spouse ID , Child ID
and Foreign key with 1-many

The problem.....I dont know if this is the right way of doing it??

Can someone please advice me on this...

Regards,

kingnothing

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/access-tablesdbdesign/200603/1
.



Relevant Pages

  • Re: confusing relationships
    ... You could include some other fields, such as foreign keys back to the same Table to identify an insured person's spouse, or parent, etc. Trying to maintain this personal information in several separate Tables is likely to create headaches for you, as you'll have to do the same work several times in designing and using those Tables. ... How you should identify multiple spouses I'm not sure, but I can see tricky situations, such as to which of several spouses a particular child should be linked. ... Does your 1-to-many to [Insurance] relationship correspond to multiple beneficiaries, or would it be a sequence of policies covering different time periods? ... If one person has multiple policies, it might make sense to just have the PolicyHolderID foreign key field in the Insurance table, and have all the other family information in a different table. ...
    (microsoft.public.access.tablesdbdesign)
  • Re: confusing relationships
    ... Let's concentrate for a moment on the Insurance table. ... A person could be a spouse and a child (of his or her ... Child table - Child Info ... Contact linked to Insurance with Contact ID and Foreign key ...
    (microsoft.public.access.tablesdbdesign)
  • Re: confusing relationships
    ... Not sure I would use separate tables for contact, spouse, and child. ... PolicyHolderID foreign key field in the Insurance table, ...
    (microsoft.public.access.tablesdbdesign)
  • Re: Inconsistent Democrats?
    ... >>> a child or not have a child. ... Yet these very same democrats are also ... >>> saying that when it comes to getting health insurance, ... > child have health insurance coverage. ...
    (soc.retirement)
  • Re: Inconsistent Democrats?
    ... >>> a child or not have a child. ... Yet these very same democrats are ... >>> saying that when it comes to getting health insurance, ... > child have health insurance coverage. ...
    (soc.retirement)