M
M Davidson
Hello All,
First, I'd like to say I've learned a lot from just lurking in this
forum. (After reading this question, you might not think so... but I have.)
A heartfelt "Thanks" to the knowledgeable few that take the time to lend
assistance to less knowledgeable strangers. Your time and assistance is
greatly appreciated.
This is probably a really stupid question... it stems from my struggle
with fully understanding normalization. But through numerous failed
attempts, many hours of struggling though what turned out to be simple
tasks, and the guidance of this forum, I've come to appreciate it's
importance. I'm trying to avoid emulating a spreadsheet.
Currently I have the skeleton for a Trainee evaluation database. The
Trainees are graded daily in 30 separate categories. The grade is a numeric
value. During different phases of the training period, the trainee will
have different instructors. All 30 categories have to be assigned a numeric
value for each day of observation. If a category is not observed, then a
value of 0 *must* be entered.
-------------
I have separate tables for the following:
tblTraineeInfo - PK Employee ID Number
tblInstructorInfo- PK Employee ID Number
tblDailyEvaluation---This is where the scores are logged at this time
tblSuperSched --- Supervisor's planned training schedule for each Trainee
------------------
The tblTraineeInfo and tblInstructorInfo are related one to many to
tbleDailyEvalution via Employee numbers. (they are automatically unique)
The tblDailyEvaluation is autonumbered for Primary Key. I'm (attempting) to
use a "find unmatched query" comparing tblSuperSched to tblDailyEvaluation
to allow the supervisor to find Daily Evaluations for trainees that have not
been completed.
***Question*** My concern is that I have 30 fields in each Daily evaluation
(tbleDailyEvaluation) that correspond to the 30 categories (in addition to
other identifying and necessary information, i.e.. shift, specific
assignment, etc...). Should I create two tables, one called
tblDailyEvaluations and another for the categories that holds the scores
(tblScores). With tblDailyEvaluations housing the extraneous identifying
information for the training day and tblScores just housing the scores by
category?
I think the way I have it set up now is proper, but I've read (here) that
"records are cheap, fields are expensive" What would be the most efficient
way to house the scores and relate them to the training day without having a
table with 30+ columns. Like I said, I may be way off base and have been
staring at the screen too long... but 30+ columns seems inefficient... it
even looks like a spreadsheet. **A key point, I can't let the end user
select the category in the scoring process, they have to be forced to enter
a score for each of the 30 categories from 0-7.** This is what's causing
me the greatest concern. If I create a table that has a lookup field for
category and a field for score, I don't see how I'll be able to force an
entry for each category. I also have this sinking feeling that it could be
easily solved through some programatic looping process that cycles through
each scoring category... But I'm still very confused by VB. A
non-programatic solution would probably keep me from breaking out in
hives...<grin>. I've only cut and pasted some very basic code. I have
bought some reference material on VB though, and I am trying to learn.
Thanks for any help, and I apologize for being so verbose... it's a
personality flaw and it get's worse with age. In addition, I thought about
posting this in the "tables" forum, but considering the basic nature of the
question, I thought it best to stay in the shallow end of the pool.
Mike D.
First, I'd like to say I've learned a lot from just lurking in this
forum. (After reading this question, you might not think so... but I have.)
A heartfelt "Thanks" to the knowledgeable few that take the time to lend
assistance to less knowledgeable strangers. Your time and assistance is
greatly appreciated.
This is probably a really stupid question... it stems from my struggle
with fully understanding normalization. But through numerous failed
attempts, many hours of struggling though what turned out to be simple
tasks, and the guidance of this forum, I've come to appreciate it's
importance. I'm trying to avoid emulating a spreadsheet.
Currently I have the skeleton for a Trainee evaluation database. The
Trainees are graded daily in 30 separate categories. The grade is a numeric
value. During different phases of the training period, the trainee will
have different instructors. All 30 categories have to be assigned a numeric
value for each day of observation. If a category is not observed, then a
value of 0 *must* be entered.
-------------
I have separate tables for the following:
tblTraineeInfo - PK Employee ID Number
tblInstructorInfo- PK Employee ID Number
tblDailyEvaluation---This is where the scores are logged at this time
tblSuperSched --- Supervisor's planned training schedule for each Trainee
------------------
The tblTraineeInfo and tblInstructorInfo are related one to many to
tbleDailyEvalution via Employee numbers. (they are automatically unique)
The tblDailyEvaluation is autonumbered for Primary Key. I'm (attempting) to
use a "find unmatched query" comparing tblSuperSched to tblDailyEvaluation
to allow the supervisor to find Daily Evaluations for trainees that have not
been completed.
***Question*** My concern is that I have 30 fields in each Daily evaluation
(tbleDailyEvaluation) that correspond to the 30 categories (in addition to
other identifying and necessary information, i.e.. shift, specific
assignment, etc...). Should I create two tables, one called
tblDailyEvaluations and another for the categories that holds the scores
(tblScores). With tblDailyEvaluations housing the extraneous identifying
information for the training day and tblScores just housing the scores by
category?
I think the way I have it set up now is proper, but I've read (here) that
"records are cheap, fields are expensive" What would be the most efficient
way to house the scores and relate them to the training day without having a
table with 30+ columns. Like I said, I may be way off base and have been
staring at the screen too long... but 30+ columns seems inefficient... it
even looks like a spreadsheet. **A key point, I can't let the end user
select the category in the scoring process, they have to be forced to enter
a score for each of the 30 categories from 0-7.** This is what's causing
me the greatest concern. If I create a table that has a lookup field for
category and a field for score, I don't see how I'll be able to force an
entry for each category. I also have this sinking feeling that it could be
easily solved through some programatic looping process that cycles through
each scoring category... But I'm still very confused by VB. A
non-programatic solution would probably keep me from breaking out in
hives...<grin>. I've only cut and pasted some very basic code. I have
bought some reference material on VB though, and I am trying to learn.
Thanks for any help, and I apologize for being so verbose... it's a
personality flaw and it get's worse with age. In addition, I thought about
posting this in the "tables" forum, but considering the basic nature of the
question, I thought it best to stay in the shallow end of the pool.
Mike D.