You computer people speak in "computerese" (lol). I hope to be one of you
someday and be able to answer questions.

we're talking *relationships*, because Access is a relational database
management system (RDMS). you need to understand the basic principles of
relational design, so that you can structure your tables and relationships
correctly and build a solid foundation to support your queries, forms,
reports. (the common analogy is building a house: solid foundation = solid
house, shaky foundation = house falls apart and needs frequent patches,
work-arounds, partial rebuilding to correct problems, etc. = ongoing
nightmare.) i strongly urge you to read up/more on relational design
principles, then re-examine your tables/relationships and make adjustments
as needed. for more information, see
http://home.att.net/~california.db/tips.html#aTip1, and when you're ready,
go back to the site and read the rest of the tips.

to answer your immediate question: from your response, looks like there is
a many-to-many relationship between infractions and consequences. one
infraction may result in many consequences being assigned, and a single
consequence may be assigned to cover many infractions.

but frankly, your business model may be more complex that is apparent here.
are consequences codified (detention, banned from group sports, etc) or
off-the-cuff (clean the teachers blackboards - are blackboards used in
schools anymore? - do this, don't do that) or a mixture of the two? frankly,
you're in the best position to figure out the appropriate structure, *once
you've studied relational design principles*. suggest you do that, then
re-examine your tables/relationships, then post to this newsgroup with
specific questions you may have. or you can post your new
tables/relationships with an explanation of your business model, and ask for
feedback.

as for your concern about forms and users, don't worry about it. get the
basic structure right first; Access has powerful tools to build a user
interface (forms, reports, queries) and there's a way to build pretty much
whatever your users will need to handle the work flow. folks here can help
with specific issues that may arise in building the interface, once the
foundation is set.

hth


"DUNNER7" wrote in message
...

You computer people speak in "computerese" (lol). I hope to be one of you
someday and be able to answer questions. After reading your reply several
times, I think I see what you are saying.

Student could have a minor infractions (discipline incident) be assinged
detention (consequence incident) 1:1 Student could blow-off detention and
need stronger consequence. Does that get added to the original infraction
or
does that incident of "blowing-off" detention get assigned a new
consequence...meaning the first incident was never technically resolved?
Right?

Or student could come down to your office after 3 seperate incidents and
you
just get to them before the day ends and assign one consequence to all 3
incidents.
Many:Many?

So I guess you are recommending the two table approach one for discipline
incidents and one for the dispositions?

Then if I was to run a report for a student's discipline history I would
need to do a query to take the relevant infraction information and pair it
with the disposition information to form the report. Correct?

I was designing my discipline table and it goes like this:

DisciplineID (pk) auto
StudentID (lookup student ID in Demographics table)
Violation (lookup violation table)
TimeOccured (date/time)
Location (lookup in location table)
ReportedBy (lookup in staff table)
Narrative (memo)

Does that seem right should I use all of the lookups from other tables?

Thanks,
Del Dobbs

"tina" wrote:

well, you need to analyze your real-world process. will a single
instance of
an infraction ever result in more than one consequence being assigned?
for
instance, what if detention is assigned, and perhaps started, but not
completed for some reason? and will multiple infractions ever be
assigned a
single punishment? you'll know the possible variations best, of course.

once you've defined the situations that the table structure needs to
support, then define the relationship between infractions and
consequences:
is it one-to-one, one-to-many, or many-to-many? when you've defined the
relationship, you'll know what table(s) you need to support it.

just a tip: you'll probably want to find a middle ground between what
happens most of the time, and what could *conceiveably* happen. it's not
realistic to build a structure that will support EVERY possible
scenario;
but you need to draw the line at the point where you can see a
reasonable,
workable way to "squeeze" or "tweak" highly unusual real-world events a
bit,
so they fit into the standard parameters you've defined.

hth


"DUNNER7" wrote in message
...

I am progressing with my student database, thanks for all help so far,
my
next problem is this. I want to record student discipline
infractions.
This
means that I will have a table to record each individual incident as
reported
by a staff member and the table will contain basic info, ie. time,
location,
rule violated, brief description of event. I will probably design a
form
based on the table for the staff member to enter each incident. I
want
this
information stored into the table and sent to whomever will deal with
the
infraction & cc. to me (principal).

Person who deals with the actual consequence/punishment for each
infraction
will have to enter relevant information ie. date, punishement type,
length
of punishment, parent contact made, brief description. This
information
has
to be sent back to the referring staff member and stored in a table.

Question is: Do I need two tables? ex. 1: "Violation" and 2:
"Disposition"? Or can I have one table: "Discipline" and each party
staff
member and disciplinarian can enter their data piece into the specific
incident on the one (1) table?

If I need two tables the studentID would be the link between the two.
Each
incident and Each disposition would have it own unique number (auto
number)?

Thanks,
Del Dobbs