general structure of a database

[Leaf]

Hello,

I am constructing a database to capture test information.
The same test is administered to Reader 1, Reader 2, and
Reader 3. Should I construct one table with choice of
reader type (1,2,3)? That means I will have duplicate IDs.

Is it a better way to have 3 tables, one for each Reader
Type. In addition, when constructing 3 tables, do I need
to differentiate the variables from each table by adding
prefix to each test variables such as R1_RCA to stand for
RCA reading from Reader 1. The analysis is to compare how
much the 3 readers differ in capturing the information.

Thanks,

leaf

 

[PC Datasheet]

TblReader
ReaderID
FName
LName

TblTestCore
TestScoreID
ReaderID
TestDate
TestScore


--
PC Datasheet
A Resource for Access, Excel and Word Applications
(e-mail address removed)
www.pcdatasheet.com

· Design and basic development for new applications
· Additions, Modifications and "Fixes" for existing applications
· Mentoring for do-it-yourselfers who want guidance
· Complete application design and development
· Applications Using Palm Pilot To Collect Data And
Synchronize The Data Back To Access Or Excel

 

[leaf]

Hello Ed,
Thank you for your reply. I only have these variables on
a form that I have constructed: patientid, readertype
(response values 1,2,3) linked to a table tblreadertype,
testtype(MRI, ECHO, EKG)linked to a table tbltesttype, RCA
(response values: normal, abnormal) and some other similar
disease measurement variables. My question is whether it
would be too complicated for a beginner to handle one to
many relationships. Would not it be easier to contruct
separate forms for each readertype and testtype
combination? At least it will be easier for dataentry
people, because when you choose a different test type for
a same patient id the measurement values do not disappear
on a form when the values are entered for a different
testype for example.
Thank you.
leaf

 

[John Vinson]

My question is whether it
would be too complicated for a beginner to handle one to
many relationships.

No it would not. It takes a mental "leap" to get used to the concept,
but it makes a great deal of sense and makes using the program much
easier.

Would not it be easier to contruct
separate forms for each readertype and testtype
combination?

NO. It would be a great deal harder for you as the developer, and much
more confusing for the user.

 

[leaf]

John,
Thanks for the reply.
After I enter data such as id, testtype, readertype,
disease variables, if I change testtype to a different
one, the values of all the other variables do not
dissappear. That is room for making mistakes.
I will have repeated ids nine times in the same table,
each for a unique combination of testtype and readertype.
leaf

 

[John Vinson]

John,
Thanks for the reply.
After I enter data such as id, testtype, readertype,
disease variables, if I change testtype to a different
one, the values of all the other variables do not
dissappear.

Well... yes. Exactly. If you had made a mistake entering the testtype,
then you want to be able to change it. Fields are generally
updateable; you can make special provisions for preventing mistakes,
but at the cost of inconvenience!

That is room for making mistakes.
I will have repeated ids nine times in the same table,
each for a unique combination of testtype and readertype.

If you set up your Form correctly - perhaps with a Form on which each
record is a unique combination of testtype and readertype, selectable
from an unbound combo box or other suitable control, and a Subform for
the values for that combination, you should be OK.