I agree with gls858 that you would be helped by studying a few basic
tutorials. That is how I started, and if you are in the mood to pay a
little money, the site 599cd.com was helpful to me in this initial phase as
well, offering some very cheap hands-on beginner to intermediate classes in
Access
that allowed me to watch and learn. I have no relationship with this
company and do not endorse it in any way other than as a person who
purchased a couple of their cds and was extremely satisfied with the help
these provided. I seem to learn best by doing, and these cds allowed me to
do that.
Aside from that -- I will give you some information about how I set up my
initial class occurance/curriculum/students/teachers tables, and established
their relationships.
Each of these tables has a (unique) primary key field (studentID in the
StudentTable, teacherID in the TeacherTable, OccurID, ClassID, etc. in
each of the tables). In my tables, these are "autonumber" fields, set
as the primary key in each table.
If I have many occurances of a single class, several tutors who might
teach a given occurance of any class, and many students that might take many
different classes, I might structure my tables somewhat like this (please
note
that I have put the "T" after each name to indicate it is a table, although
my db is
structured with names tblStudent, tblTeacher, tblClass, etc., which is a
more standard way of naming tables -- and you will discover more about the
reason for this if you study some tutorials) the names below are for your
understanding: (PK =Primary Key FK=Foreign Key)
Table Names
StudentT TeacherT ClassT OccursT
RegisterT
Fields
StudID (PK TeachID(PK) ClasID(PK) OccurID(PK) RegID(PK)
STName TeName ClName ClassID (FK) OccurID(FK)
STAddress TeEmail ClLength TeachID(FK) StudID(FK)
STPhone TEPhone Descript OcDate RegHow
etc etc Credits OcTime
RegWhen
etc
RmNumber etc
etc
Please note that the fields in other tables that are not primary keys that
have the same name (for example, ClassID in the OccuranceTable, are datatype
"number fields" that serve as "foreign keys" but these are not autonumber or
unique). In this way, I store detailed, unique information about a
particular student ONLY in the StudentTable, detailed, unique information
about a about a particular Class ONLY in the ClassTable, and detailed
information about a particular occurance of a class ONLY
in the Occurs Table.
The best advice/insight about table structure and
relationships that I came across in my many wanderings is this: An
_occurance_ of a class might have a specific "RoomNumber", but the class
itself might not, as it can occur in many places. A student may have an
email, but an occurance of a class probably will not. In choosing what
information to place in which tables, consider this question: "Does the
"Student/Class/Teacher/Occurance/Registration" have a ________ ?" ( email
address, time/date, cost, or whatever information you are considering adding
to the table). This helps you choose where information belongs in different
tables.
At this point, My StudentTable is the only place where a student's actual
name
appears -- in any other table, they appear only as a unique number
(StudentID, in this case, in the registration table, which ties them to the
particular class occurance they have registered for through the OccuranceID
in the RegistrationTable ). Remember that primary and foreign key fields
must
be the same datatype (ie number, text, etc) to relate correctly.
(autonumber
is a number type, so if your PKs are autonumber, FKs must be set as number)
So, how do you see this information and figure out who Student #323 is, if
all that is entered in a class occurance and you only see the number? In
forms, queries, and reports, which you use to pull the information together.
Hope that's helpful.
Carol
I thought it would be easy. I