Yes.  You use a junction table to resolve two tables in m:m into two pairs
of tables joined 1:m (the junction table goes in the middle, so you have 1:m
and m:1).

Datasheet views can be ... challenging.  A common way to handle the data
entry/edit for a junction table is to use a main form (and a combobox) to
select one of your "1"s (say, to pick a person), then use a sub-form based
on the junction table to allow you to associate the other (?roles) that goes
with that person.

Regards

Jeff Boyce
Microsoft Office/Access MVP

You need the following tables:
TblProgram
ProgramID
ProgramDesc
<Other fields about a program>

TblProgramAdminType
ProgramAdminTypeID
ProgramAdminType    '"Program Director," "Assoc. Program Director," "Program
Coordinator,"
"Assoc. Program Coordinator"

TblProgramPersonnel
ProgramPersonnelID
<Contact fields for personnel>

TblProgramAdministrator
ProgramAdministratorID
ProgramID
ProgramPersonnelID
ProgramAdminTypeID

Steve

You might find it easier to visualise the model if, instead of thinking of
the relationship type as a many-to-many one, you think of it as a 3-way
relationship type (in the jargon its called a ternary relationship type).  
What you have here are three 'referenced' entity types, Programs, Personnel
and Roles and a 3-way relationship type between them, which is modelled by a
fourth table.

It would also make things clearer I think if you name the tables Programs,
Personnel, Roles and ProgramPersonnel, the last being the table modelling the
relationship type between the other three, a so-called 'junction' table.  
Using plural or collective nouns for table names reflects the fact that a
table is a set, and making them as close as possible to real English words
which describe the entity types makes it easier to 'read' the objects
(particularly when writing queries) .  Giving their columns single nouns as
their names reflects the fact that each column represents an attribute of the
entity type which the table models (a relationship type is just a special
kind of entity type BTW, so the ProgramPersonnel table also models an entity
type, which in this case happens to be a relationship type).

The tables would thus be like this:

1.  Personnel

PersonnelID (primary key)
FirstName
LastName
etc

This table is self explanatory I think.  Note that a unique PersonnelID
surrogate key column is necessary as names can be duplicated and are
therefore unsuitable as keys.

2.  Roles

Role (primary key)

This table would have four rows with values "Program Director" "Assoc.
Program Director" etc.  More rows can be added later of course if necessary.  
As each of these values is unique a numeric surrogate RoleID key is not
needed here, but you can use one if you wish.

3.  Programs

Program (primary key)

Again as the program names will presumably be unique a ProgramID surrogate
key is not necessary, but can be used if you prefer.  More columns
representing other attributes of the programs entity type would probably be
added.

4.  ProgramPersonnel

PersonnelID
Role
Program

This table models the ternary relationship type between the other three
entity types.  Each of the three columns is a foreign key referencing the
primary key of the other three tables.  The primary key of this table is the
three columns in combination.  If you do use 'natural' Role and Program keys,
in the relationships with the Roles and Programs tables, as well as enforcing
referential integrity you should also enforce cascade updates; this ensures
that if a value in the primary key column of Roles or Programs is changed the
values in all matching rows in ProgramPersonnel will also change.

For data entry a suitable set-up would be a programs form, based on a sorted
query on the programs table, and within this a program personnel subform
based on the ProgramPersonnel table, the subform being linked to the parent
form on the Program columns.  The subform would best be in continuous form
view and would have two combo boxes, bound to the PersonnelID and Role
columns respectively.  The latter simply needs a RowSource of:

SELECT Role FROM Roles ORDER BY Role;

The former should be set up to hide the bound PersonnelID column and show
the names, so its properties would be:

RowSource:     SELECT PersonnelID, FirstName & " " & LastName FROM Personel
ORDER BY LastName, FirstName;

BoundColum:   1
ColumnCount:  2
ColumnWidths  0cm;8cm

If your units of measurement are imperial rather than metric Access will
automatically convert the last one.  The important thing is that the first
dimension is zero to hide the first column and that the second is at least as
wide as the combo box.

Ken Sheridan
Stafford, England