Relationships and lookup tables.

C

CC

OK, I thought I had this straight after going through all the online
tutorials, but now I'm actually implementing, and I'm confused about
relationships and lookup fields. I'm doing an Orders database. I have:

TblCustomers
TblOrders
TblOrderDetails

OK, so these are all related. So in the Orders Table, there is a column for
Customers, to show which customer made that order, right? So I created a
CustomerID column in the Orders Table and one to many relationship to the
Customers Table for that. But I'm NOT supposed to set the properties of that
column to Lookup the Customers table? I'm supposed to let the data for that
field be entered by a Form?

I guess the confusion is that I don't feel like the tables are really linked
unless I see that drop-down list in the table. But is that the wrong way to
think of it? I went through the MS online tutorials, and all their sample
databases are full of lookup fields. Is that wrong?
 
L

Larry Daugherty

If you're planning to do any serious development then when you see
that dropdown list in a table you are truly screwed.

You haven't yet gotten the idea behind how the relations (not
linkages) between the tables are managed. It is all counter-intuitive
as you start. The parent table does not maintain a list of its
children. Each child record maintains a copy of its parent's Primary
Key as a long integer (called a Foreign Key - more confusing because
there is no help or reference about Foreign Keys). If you use
Referential Integrity and draw a line in the Relationships window
between the Primary Key in tblCustomer to the ForeignKey in tblOrder
then the system will take care of writing in the Foreign Key value for
you. Do the same between the Primary Kdy of tblOrder and the Foreign
Key of tblOrderDetail. Notice that each table has its own Primary
Key.

Remember, Lookup Fields are an abomination. Lookup tables are a good
thing. Lookup tables are simply normal tables whose values are
'looked up' for use elsewhere.

In the early days of getting going
microsoft.public.access.tablesdesign is a useful place to lurk. There
are lots of Access newsgroups. There is also an extremely valuable
site to check out: www.mvps.org/access

HTH
 
J

John Vinson

OK, I thought I had this straight after going through all the online
tutorials, but now I'm actually implementing, and I'm confused about
relationships and lookup fields. I'm doing an Orders database. I have:

TblCustomers
TblOrders
TblOrderDetails

OK, so these are all related. So in the Orders Table, there is a column for
Customers, to show which customer made that order, right? So I created a
CustomerID column in the Orders Table and one to many relationship to the
Customers Table for that. But I'm NOT supposed to set the properties of that
column to Lookup the Customers table? I'm supposed to let the data for that
field be entered by a Form?

Exactly. What you want to *store* in that field is the numeric
CustomerID. When you open the table in datasheet view you'll see that
number.
I guess the confusion is that I don't feel like the tables are really linked
unless I see that drop-down list in the table. But is that the wrong way to
think of it? I went through the MS online tutorials, and all their sample
databases are full of lookup fields. Is that wrong?

That's the wrong way to think of it, and yes, it IS wrong, in my (and
lots of others) opinion. Tables should be used FOR DATA STORAGE, and
for no other purpose (well, occasionally you'll open a table datasheet
for debugging).

Forms are very useful tools. They let you use tools such as a Combo
Box, which might have the numeric CustomerID as its bound column, and
a human-readable customer name as its visible column. This lets the
computer see meaningless but unique and unambiguous ID numbers, while
the user sees a meaningful customer name. It is NOT necessary to have
a table datasheet do this in order for a Form to do it!

The relationship is NOT intended to make related-table data appear in
the main table. The intention of the relationship is to enforce
referential integrity - that is, to prohibit the user from entering an
order for a nonexistant customer; and to make Queries which link the
two tables run more efficiently (since creating the relationship
creates an index on the joining field).

John W. Vinson[MVP]
 
C

CC

Thanks so much for your replies! OK, so I think I understand it. I need to
create the relationships so that the data relationships hold true - this
customer is related to this order, which is related to this product, etc. But
I shouldn't actually be inputting this data into the tables. I should create
a form that allows the user to input the data in a format that is
understandable to him, and then Access will take care of putting the data
into the proper tables using the relationships.

e.g., when I create the Orders table, it will contain the CustomerID column
(fk from the Customers table). However, it will just be a text box field and
not a combo or list box with lookup.

And a lookup table is different from a lookup field. A lookup table is a
table I can create, like PaymentTerms, that will give my user a list of items
to choose from in a Form.

Is this right? Phew! OK... this is my first Access database. I want to make
sure I get into the right frame of mind. Thanks again!
 
L

Larry Daugherty

You're getting there.

You'll base your form on a table (usually better if it's on a query
based on the table) and present the form such that it makes sense to
your user. If you're just getting started, the best thing to do is to
design your tables first and then click the Autoform icon to have a
wizard step you through creating a form based on the table. It will
present you with lots of choices. You can run through that process as
many times as you like until you get a form that looks good enough to
begin. You can then change the labels from the field names into
something more useful. You will probably go through a lot of trial
and error iterations and get better at it as you go.

Again, for getting started, this is a great newsgroup to lurk. You
might also look into tablesdesign, queries, forms and formscoding.
Post back when you have problems you can't solve or issues you don't
understand.

HTH
 
C

CC

Thank you both so much for your kind and helpful replies! So, I should
disregard that whole part of the Northwind database. I've been using that as
a reference. It's so misleading!

OK, one more question. Does it make sense to have a table for every field on
the form? Like, for Payment Terms, Shipper, Shipping Type, etc? Each of these
tables would really only have one column and would only be used to populate
that field's pull-down list. Is that right?

This newsgroup is the best! :)
 
L

Larry Daugherty

Your question assumes that you design your tables to fit your forms.
In fact, it's the other way around. When it comes to the actual
design of your application, the tables are the first things to design.
Tables are created to represent entities in the real world: people,
orders, order details, cars, books, ideas. Each record in a table
deals with just one instance of that entity type. You provide a field
in the table for each attribute of that entity that you want to track.

The whole process begins with a definition of the problem area and the
subsequent solution statement, usually in the form of a Product
Specification. It's only when you understand what you intend to do
that you can really identify the entities in play and design the
tables accordingly.

Not only do you not design tables to fit your forms you definitely
don't crate a kajillion single column ("field" actually) tables.

If you haven't already done so, get a beginning book or two on Access.
Some of your questions here indicate that you'd also do well to lurk
microsoft.public.access.tablesdesign

HTH
 
C

CC

I'm not really designing my tables to fit my forms. It's just that with my
new understanding of how the tables and forms work, I'm trying to figure out
how my data should really be stored. I am designing my tables first - I
haven't even touched forms or queries.

So my question is - I have all these different items, like CustomerType,
PaymentTerms, Shipper, etc. that aren't related to each other, but are
related to other tables, like Orders or OrderDetails. So does CustomerType
get its own table? That way, if customer types change, I just change that
data in that table. If CustomerType does not get its own table, then can my
user enter a CustomerType using a drop-down list? Where would that list come
from?

I do have some books on Access, and I've gone through a lot of online
training. But it seems that the online training is different from what people
tell me here - and I trust you people more. Sorry for all the questions - I
did go to the tabledesign group, but it's very difficult to find what I need.

Thanks again for everyone's help!
CC
 
L

Larry Daugherty

Aha! Yes. Tables that simply hold a list of variations on a
single attribute are highly recommended. They are referred to as
Lookup tables (not to be confused with the dreaded LookupFields) and
go a long way in reducing typing, therefore typing errors and, when
LimitToList is true, significantly reduce spelling errors. Sure
enough, those entities stored in lookup tables are not likely to have
been given a thought at the higher levels of the product. Customer
Type could well get it's own table - your call. The dropdown list
(combobox) would be based on a query based on your lookup table. You
have the concept down pat.

HTH
 
F

ffisher

Hi Larry
Would you clarify this for me please. Your Quote:
"then the system will take care of writing in the Foreign Key value for
you."

At what point can I expect then to see the value of the PK from the Parent
table showing in the FK of the Child table?

My understanding is that one should first create tables, add fiields,create
the PKs, then duplicate PK names for fields in the child tables (they become
the FKs) then link then via the relationship window.
All this done BEFOR adding data.

Data can then be added either via direct table entry OR via a form.

When should I start seeing the values in the FK during the above process?

ffisher
 
V

Vincent Johns

ffisher said:
Hi Larry
Would you clarify this for me please. Your Quote:
"then the system will take care of writing in the Foreign Key value for
you."

At what point can I expect then to see the value of the PK from the Parent
table showing in the FK of the Child table?

My understanding is that one should first create tables, add fiields,create
the PKs, then duplicate PK names for fields in the child tables (they become
the FKs) then link then via the relationship window.

Sort of. You can use the Relationships window to SPECIFY that certain
fields be linked, but the actual linking takes place when you add
records to the Tables.
All this done BEFOR adding data.

Some of it is done before adding data. Creating the keys and copying
the values, however, is usually done at the same time as data are added.
Data can then be added either via direct table entry OR via a form.

OR via a Query. Of these, Forms are the most versatile, but they take a
bit of extra effort to set up. (There is a Form Wizard available to
help with that.)

My advice (warning: not everyone here agrees with me) is to set up a
Query for each primary key that you plan to use as a foreign key. For
example, suppose you have the following Tables:

[Parent] Table:
ParentID Mother Father
---------- ------ ----------
1521310868 Mary Joe
1947344352 Zelda Murgatroyd

[Child] Table:
ChildID Name ParentID
----------- ------ -----------
1188153275 Susan 1947344352
724657378 Jim 1521310868
-223986171 John 1521310868

Then you can define a lookup Query on the [ParentID] field that might
have this SQL:

[Q_LookupParent]
SELECT Parent.ParentID,
[Parent]![Mother] & " and "
& [Parent]![Father] AS Parents
FROM Parent
ORDER BY Parent.Father;

In Query Datasheet View, it would look like this:
ParentID Parents
----------- ---------------------
1521310868 Mary and Joe
1947344352 Zelda and Murgatroyd

In the [Child] Table, you could then set the properties of the foreign
key [ParentID] as follows (after selecting the Lookup tab):

Display Control: List Box
Row Source: Q_LookupParent
Column Count: 2
Column Widths: 0;2

Having done that, the appearance of [Child] in Table Datasheet View
would look like this:

[Child]
ChildID Name ParentID
---------- ------ --------------------
1188153275 Susan Zelda and Murgatroyd
724657378 Jim Mary and Joe
-223986171 John Mary and Joe

.... and I would be inclined to hide the primary key fields of both
Tables ([Child].[ChildID] and [Parent].[ParentID]), since the key values
are meaningless to human beings. Incidentally, the underlying data are
not changed ([Child].[ParentID] still contains those long numbers); only
the appearance has changed to make reading & data entry easier.

If you link the two [ParentID] fields in the Relationships window,
Access will likely set up a subdatasheet in the [Parent] Table (small +
sign at the left end of each record) allowing you to quickly display the
linked records in [Child].

With primary keys hidden in both Tables and with subdatasheets enabled
and expanded, the result might look a bit like this:

Mother Father
------ ------
Mary Joe
Name
-----
John
Jim
Zelda Murgatroyd
Name
-----
Susan
When should I start seeing the values in the FK during the above process?

ffisher

If you do as I suggested, you'd see them when you click on the (empty)
[ParentID] field in a new record in [Child]. A list will appear from
which you can choose the desired value, or you may type the name (not
the key number) there.

As I mentioned above, once you have this working, I suggest setting up a
Form to facilitate your data entry, as that will give you more freedom
in specifying how data can be entered. But entering directly into a
Table will give you a quick-and-dirty basic capability, and sometimes
that's all you'll need.

-- Vincent Johns <[email protected]>
Please feel free to quote anything I say here.
 
T

tina

Larry was referring to the automatic setting of the foreign key value in a
subform record, which occurs when the mainform and subform are correctly
linked in the subform control's LinkChildFields and LinkMasterFields
properties. the primary key value from the mainform's underlying table is
automatically assigned to the linked foreign key field in the subform's
underlying table *when you begin entering a record in the subform*.
My understanding is that one should first create tables, add fiields,create
the PKs, then duplicate PK names for fields in the child tables (they become
the FKs) then link then via the relationship window.
All this done BEFOR adding data.

the above process is correct.

btw, if you do a search of these newsgroups, you'll find that the consensus
is overwhelmingly *against* using Lookup fields in tables. see
http://www.mvps.org/access/lookupfields.htm for details.

hth
 
V

Vincent Johns

tina said:
Larry was referring to the automatic setting of the foreign key value in a
subform record, which occurs when the mainform and subform are correctly
linked in the subform control's LinkChildFields and LinkMasterFields
properties. the primary key value from the mainform's underlying table is
automatically assigned to the linked foreign key field in the subform's
underlying table *when you begin entering a record in the subform*.




the above process is correct.

Well, OK, Access will ALLOW you to create all the keys first, leaving
the rest of each record empty, but that doesn't mean it makes sense to
do it that way. (Sometimes it does, usually for me it doesn't.) I
think it's usually easier to add the keys as you add the records
(especially when it's done automatically for you).
btw, if you do a search of these newsgroups, you'll find that the consensus
is overwhelmingly *against* using Lookup fields in tables. see
http://www.mvps.org/access/lookupfields.htm for details.

hth

Whatever floats your boat. The objections cited here look valid, but
some of them can easily be avoided. For example, if you give your key
values distinctive names (such as ending them with "ID"), you're not too
likely to try to use them as sort keys. A Query attempting to sort on
the displayed value would normally include the linked Table or Query,
and sort on that instead.

Some of the objections don't seem to make good sense, such as that the
"lookup fields mask what is really happening". Of course I want to mask
what is really happening when I'm dealing with keys -- the key values
are usually meaningless to a human being. (When they actually do mean
something, I don't need a lookup field.) I often use random Autonumbers
as keys specifically to help remind me not to use them for anything else.

And, assuming that I can keep track of which fields contain key values,
as I normally do, having visible reminders (via lookup fields) of what
the linked records contain can save lots of time and trouble. Raw key
values often aren't at all informative, and I think they should normally
stay hidden unless something goes awry with the database. :-(

Whether you choose to use lookup fields (with discretion) or not, the
choice is up to you (or your customer/boss), not Access. Access makes
the tools available -- it's up to you to use them wisely.

-- Vincent Johns <[email protected]>
Please feel free to quote anything I say here.
 
T

tina

My understanding is that one should
Well, OK, Access will ALLOW you to create all the keys first, leaving
the rest of each record empty, but that doesn't mean it makes sense to
do it that way.

we're not talking about creating records, hon - we're talking about creating
tables and relating them to each other. as ffisher said, all of that is done
before any records are added to the tables.

hth
 
C

Craig Alexander Morrison

Well, OK, Access will ALLOW you to create all the keys first, leaving the
rest of each record empty, but that doesn't mean it makes sense to do it
that way. (Sometimes it does, usually for me it doesn't.) I think it's
usually easier to add the keys as you add the records (especially when
it's done automatically for you).

The above is, with the greatest possible respect, TOTAL BOLLOX! (vbg)

Failure to design the correct schema at the outset (or as good as you can
get) is like building a house before the groundworks are complete and the
foundations are laid.

Of course if you are building a tent....


--
Slainte

Craig Alexander Morrison
Crawbridge Data (Scotland) Limited


<see excerpt above>
 
V

Vincent Johns

tina said:
we're not talking about creating records, hon - we're talking about creating
tables and relating them to each other. as ffisher said, all of that is done
before any records are added to the tables.

hth

You're right; I assumed ffisher was talking about the key values, not
the key-field definitions.

And I agree that it's a good idea to do a lot of the design before
populating the Tables. But the structure won't all come crashing down
if you later decide to modify it by adding new kinds of information,
linking them to the old. One of the strengths of an RDBMS like Access
is its flexibility -- few of your decisions, IMHO, are cast in concrete.
If you don't like the way something looks or works, there's often an
easy way to change it. As an aid to thinking, one may want to start
with a proposed design, add a few sample records, and then play with the
database, perhaps modifying the design before fully populating the Tables.

-- Vincent Johns <[email protected]>
Please feel free to quote anything I say here.
 
B

Ben Bamford

As a novice developer (and to this use of "communities"), I am hoping to gain
guidance on the subject of this thread. I think I've understood "CC"'s
question because it seems the same as mine and my experimentation with the
answers has not produced a correct result.

I have a Parent Table "Employee" with PK "EmpID" and 3 other fields in that
table.
I have a Related Table "EmployeeInfo" with PK "EmpID" and 1 other field
("Salary")in that table.
I related "tblEmployee" to "tblEmployeeInfo", enforcing referential
integrety, and cascade update and cascade delete.
I entered 4 employee records in "tbl Employee" (all fields).
The "EmpID" values in "tblEmployee" DO NOT appear in the "EmpID" field of
"tblEmployeeInfo". Why not?

Opening "tblEmployee" and expanding to see the subdatasheet of
"tblEmployeeInfo", I see only the "Salary" field, not the "EmpID" field. If
I enter a salary value in the subdatasheet, I do see the "EmpID" values in
tblEmployeeInfo".

I just do not get why I do not automatically see values in both tables when
I enter them in the Parent table. I will continue to seek other resources to
answer this, but this seems SO BASIC and I'm having such a hard time with it.
 
D

Damon Heron

I don't see a thread for CC, but I think I can answer your question.
If you have no data in the tblEmployeeInfo, then why would you expect to see
a relation to the employeeID?
You noted that when you enter salary in the tblEmpInfo, then the EmpID shows
up. So there is your relation.
Next, are you entering data from a form or directly to the table? If a form
then you probably should have the mainform's record source as the
tblEmployee, and add a subform with the source as tblEmployeeInfo. The link
between the two is the EmpID.

Finally, when you look at tables and related tables using the little plus
sign, it doesn't show the EmpID, because the record you click on is
associated with the EmpID. If the Info table is blank for that record, it
still shows the blank record.

Damon
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top