View Single Post
  #4  
Old February 11th, 2010, 03:44 PM posted to microsoft.public.access.tablesdbdesign
Lee Ann[_2_]
external usenet poster
 
Posts: 38
Default Table & Relationship Advice

Fred & Jeff:

Thanks for the advice and I'll try my best to lay out what I have without
getting into too much detail. I'm not trying to solicit extra duty from
anyone, just trying to find a way to provide all the information to get
clearer answers. I have posted a couple of questions on this in recent weeks
and each answer has led to more questions to the point that I doubt my design
is correct.

I have a TblIncident:

TblIncident
IncidentID (PK)
IncidentNumber (this is actually a unique number which should never be
repeated - makes me believe it should be a PK)
IncidentDate
IncidentTime
SubjectID (FK)
LocationID (FK)
CaseworkerID (FK)
CallerName
CallerContactNumber

**Note: Each incident will include one or more subjects and one location.

TblLocation
LocationID(PK)
LocationName
LocationStreetAddress
LocationCity
LocationState
LocationContactNumber

**Note: One location will be used per incident. We have particular
locations whose information will already be loaded into this table (this will
not be information the user will be adding).

TblSubject
SubjectID (PK)
SubjectLastName
SubjectFirstName
SubjectMiddle
Additional identifying information will follow

**Note: Each subject entered will be involved in one incident at one
location. There may be more subjects involved in the same one incident.
It's conceivable that they will be involved in another incident at another
location on a different (later) date.

TblCaseWorker
CaseWorkerID (PK)
CaseWorkerLastName
CaseWorkerFirstName
etc.

**Note: One case worker will be involved in one incident at a time.

I was also contemplating another table where further information on the
subject was entered that was specific to only them. I'm not sure why I feel
I need to do this and was looking at the number of fields that would be in
the one table (23) and felt that would be to excessive.

I think where I'm running into the problems is not being really sure where
the FK fields should be in the related tables. I'm trying to think of the
"main" purpose of the DB and that is to capture these incidents. The other
information (location, subject, case worker) is related to this main
(incident) table and it makes me want to put a FK from each of these tables
into the TblIncident, but this doesn't seem to be working correctly for me.

Hope all of this makes sense and I do appreciate all the help that is given
here.



"Jeff Boyce" wrote:

Lee Ann

Typically, you'll find the folks here volunteer their time (the Code of
Conduct prohibits solicitation). So if you ask folks to take on extra duty,
outside the 'groups, you may want to seek out paid assistance.

Rather than take that step, could you obfuscate your data (if the data is
what's sensitive)? If it is the design itself that's proprietary, could you
use an analogy? For example, here's a simplistic design for a registration
database:

tblPerson
PersonID
FName
LName
DOB

tblClass
ClassID
ClassTitle

trelRegistration
RegistrationID
PersonID
ClassID
RegistrationDate

One record from tblPerson could have many trelRegistration records.

One record from tblClass could have many trelRegistration records.

--

Regards

Jeff Boyce
Microsoft Access MVP

Disclaimer: This author may have received products and services mentioned in
this post. Mention and/or description of a product or service herein does
not constitute endorsement thereof.

Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.

"Lee Ann" wrote in message
...
Is it possible to post my tables and relationships for advice and to do so
privately? I posted a couple questions on this DB and based on responses,
I'm beginning to doubt my entire design. Unfortunately, this DB is of a
sensitive nature and posting the entire information to be captured on an
open
forum is not an option.

Thanks in advance.



.