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