It does sound to me as if you are introducing redundancy.  This is not
merely inefficient, it is risky as it undermines the integrity of the
database and leaves it open to inconsistent data.  Essentially each
'fact' must be stored once and once only in a database, e.g. in a
table of addresses my address includes the town of Stafford which is
in the county of Staffordshire, which is in the UK.  To have columns
for town, county and country in the addresses table would be wrong;
this is what's meant by redundancy.  All that's necessary is to have a
column for townID (not the name as these can be duplicated).  This is
because the fact that Stafford is in Staffordshire is recorded in the
Towns table and that Staffordshire is in the UK is recorded in the
Counties table.  There will also be a Countries table at the top of
this hierarchy as this allows 'referential integrity' to be enforced,
preventing an invalid country being entered in the Counties table.

So the question arises, is the 'fact' that task A is always, without
exception, associated with area B recorded somewhere in a 'referenced'
table?  If so then in a 'referencing' table which records tasks you
only need a column for task, not for area.  Once the task is known the
area is known; in the jargon its said that area is 'functionally
dependent' on task.

If on the other hand task A could also be associated with area C or
area D, then area is not functionally dependent on task, so its
legitimate to have both task and area columns in a referencing table.
This in turn brings us to your other point, that the Area_ID value is
being stored in the 'referencing' table, not the area name.  This is
how it should be.  Knowing the Area_ID we automatically know the area
name, again because the latter is 'functionally dependent' on the
former.  It doesn't matter that you need to show the area name in
reports, because all you have to do is base the reports on a query
which joins the tables on Area_ID and include the area name in the
columns returned by the query.  You can then bind a control to the
area name column in the report.  Joining tables in queries like this
to return whatever columns you need from different tables is how you
can show the data you require without introducing any redundancy into
the database.

Ken Sheridan
Stafford, England

On Apr 30, 4:49 pm, Chantel33 <Chante...@discussions.microsoft.com>
wrote: