Re: Design relational
- From: "Jeff Boyce" <JeffBoyce_IF@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 30 Mar 2005 18:25:40 -0800
Roger
It sounds like the design you described uses a single field (duties
performed) to hold multiple facts (Cooking, Washing, ...). This is contrary
to good data design practices urging one fact-one field. In an instance
like you are describing, you have a one-to-many relationship. One
Householder can have zero, one or many "duties performed". You need a third
table to hold "duties performed by Householder.
This brings up a second potential issue. If your record holds two people
(Householder1 and Householder2), which one of these is the one performing
the duties?
A more normalized design would use one row/record per person, so you could
then use that person's ID in the "duties performed by Householder" table to
indicate who is doing it.
Is there a need for you to keep Householder1 and Householder2 associated
with each other? If so, you probably need a table to hold that
relationship.
--
Good luck
Jeff Boyce
<Access MVP>
"Roger" <Roger@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:0ed301c53591$75024420$a601280a@xxxxxxxxxx
> I have a simple data base with a Householder1 field and
> Householder2 field and a field for duties that each
> householder performs eg: Cooking, Washing etc. I have a
> seperate table that lists all the duties. How do I
> design a form or subforms where the Householders names
> are listed and all the duties they perform. I am confused
>
> Thanks in advance
>
.
- Follow-Ups:
- Re: Design relational
- From: Roger
- Re: Design relational
- References:
- Design relational
- From: Roger
- Design relational
- Prev by Date: Re: One Table Relates to Many Fields In Other Table
- Next by Date: Re: Compact database
- Previous by thread: Design relational
- Next by thread: Re: Design relational
- Index(es):
Relevant Pages
|
