A form can have only one table or query as it's record source.  You can use
multiple tables to create a query for a form, but in many cases, queries
built from multiple tables cannot be updated.  You can tell if a query is
updatable or not by opening it. If the navigation button to the right with
the * on it is greyed out, you can't edit, add, or delete any records.  So
you have to be sure you can edit the recordset for you form.

If you need to update multiple tables, there are two situations to consider.
If the tables are not logically related to each other, then you will
probably want to use a different form for each table.  If the tables have
some relationship.  For example, you have a table of Clients and a table of
Contacts for each of the Clients, then the Contacts table will need to have a
field that defines which Client the Contact belongs to.  This is done by
using the Client's primary key value in a field in the Contact table.  This
is known as a foreign key.

In this case, you can use a form/subform.  You would use the Client table as
the record source for the form and the Contact table as the record source for
the subform.  To use a subform on a form, you put a subform control on the
form. There are 3 important properties for a subform control.
Source Object - This property is the name of the form to use as the subform
Link Master Field(s) - In this case, it would be the Client table's primary
key field.
Link Child Field(s) - In this case, it would be the name of the foreign key
field in the Contact table.  That is the field that has the value of the
primary key field in the Client table that defines which Client the Contact
belongs to.

I can assure you of one thing: designing your table structures to fit your
form will pretty much guarantee a flawed design.

Designing a relational database is a bit like building a house. The Tables and
their relationships are the foundation; Forms are the doorframes and windows.
You build the foundation FIRST. Data is stored in tables, and only in tables;
a Form is simply a tool to display and edit that data.

If you're using the word "form" in the common sense of a printed document of
fixed format, then I think you really want a Report. Access Forms are for
onscreen interaction with the data; Reports are for printing.

Design your tables based on the logical relationships between the Entities
(real-life people, things, or events) of importance to your application; then
design the forms and reports to fit the logical structure of the data - not
vice versa.

For some tutorials see

Jeff Conrad's resources page:
http://www.accessmvp.com/JConrad/accessjunkie/resources.html

The Access Web resources page:
http://www.mvps.org/access/resources/index.html

A free tutorial written by Crystal (MS Access MVP):
http://allenbrowne.com/casu-22.html

MVP Allen Browne's tutorials:
http://allenbrowne.com/links.html#Tutorials