A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Access » Database Design
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

Assistance with Many-to-Many Relationships



 
 
Thread Tools Display Modes
  #1  
Old February 24th, 2010, 04:21 PM posted to microsoft.public.access.tablesdbdesign
Lee Ann[_2_]
external usenet poster
 
Posts: 38
Default Assistance with Many-to-Many Relationships

I'm looking into correcting a previously developed database that was
originally done and works like an excel spreadsheet (all fields are currently
in one table). In looking at it, there appear to be many many-to-many
relationships involved. This is used to keep records relating to force used
against suspects by police. In one incident, there could be 1 or more
suspects involved, 1 or more officers involved, 1 or more types of force
involved (possibly different force by each officer involved), none/one/more
charges placed on the suspect, and a final disposition on each suspect
involved (jail, hospital, etc). To further confuse the scenario, the shift
that the officer is on at the time of the incident is captured - however if
the same officer is involved in another incident down the road, he/she may be
on a different shift.

I know I will need a linking table to establish the many to many
relationships and am unsure how many tables are required and which fields
should be contained in them. I currently have the following tables relating
to the above information:

TblSuspect
SuspectID (PK)
(identifying information fields)

TblOfficer
OfficerBadgeNumber (PK)
(Officer's first and last name fields)

TblTypeofForce
TypeofForceID (PK)
TypeofForce

TblCharges
ChargesID (PK)
Charges

TblShift
ShiftID (PK)
Shift

TblDisposition
Disposition(PK)
Disposition

I have a main incident table containing information related to the incident:

TblIncident
IncidentID (PK)
CaseNumber
DateandTimeofIncident
NatureofIncident
StreetAddress
City
AreaofIncident
LocationTypeID (FK)
Summary
OfficerBadgeNumber (FK)
SuspectID (FK)

Thanks in advance.




  #2  
Old February 24th, 2010, 04:55 PM posted to microsoft.public.access.tablesdbdesign
BruceM via AccessMonster.com
external usenet poster
 
Posts: 448
Default Assistance with Many-to-Many Relationships

I think Disposition is an attribute of Incident. There can be a lookup table
for dispositions, but no need I can see for a junction table.

From what I can see, there would be junction tables for:

IncidentSuspect
IncidentOfficer
IncidentCharges

Since the type of force used is specific to an officer at an incident, the
ForceUsed table would be related to the IncidentOfficer table. The Shift
could be a linking field to a Shift table, or you could just store the value
(1st, 2nd, etc.). Here is an idea of what the IncidentOfficer table could
look like:

tblIncidentOfficer
IO_ID (primary key, or PK)
IncidentID (link to tblIncident)
OfficerID (link to tblOfficer)
Shift

Here is a listing of types of force:

tblForce
ForceID (PK)
Description

Here is the Force Used listing (also a junction table):

tblForceUsed
ForceUsedID (PK)
IO_ID (link to tblIncidentOfficer)
ForceID (link to tblForce)
Comments

Incident is the top-level table, so it does not contain foreign key fields
for Officer and Suspect. One incident: many officers and one officer: many
incidents, so there is a many-to-many relationship between officers and
incidents. The foreign key (linking) field is in the table on the many side
of the relationship (the junction table in the case of many-to-many). I'm
not sure what LocationTypeID is. However, I suspect it would be stored as an
attribute of the Incident: one LocationType could be in many incidents, so it
would be a foreign key field in the top-level table. One Incident would
involve just one Location Type (I suppose), in which case there is no need to
resolve a many-to-many relationship.

Lee Ann wrote:
I'm looking into correcting a previously developed database that was
originally done and works like an excel spreadsheet (all fields are currently
in one table). In looking at it, there appear to be many many-to-many
relationships involved. This is used to keep records relating to force used
against suspects by police. In one incident, there could be 1 or more
suspects involved, 1 or more officers involved, 1 or more types of force
involved (possibly different force by each officer involved), none/one/more
charges placed on the suspect, and a final disposition on each suspect
involved (jail, hospital, etc). To further confuse the scenario, the shift
that the officer is on at the time of the incident is captured - however if
the same officer is involved in another incident down the road, he/she may be
on a different shift.

I know I will need a linking table to establish the many to many
relationships and am unsure how many tables are required and which fields
should be contained in them. I currently have the following tables relating
to the above information:

TblSuspect
SuspectID (PK)
(identifying information fields)

TblOfficer
OfficerBadgeNumber (PK)
(Officer's first and last name fields)

TblTypeofForce
TypeofForceID (PK)
TypeofForce

TblCharges
ChargesID (PK)
Charges

TblShift
ShiftID (PK)
Shift

TblDisposition
Disposition(PK)
Disposition

I have a main incident table containing information related to the incident:

TblIncident
IncidentID (PK)
CaseNumber
DateandTimeofIncident
NatureofIncident
StreetAddress
City
AreaofIncident
LocationTypeID (FK)
Summary
OfficerBadgeNumber (FK)
SuspectID (FK)

Thanks in advance.


--
Message posted via http://www.accessmonster.com

  #3  
Old February 24th, 2010, 05:11 PM posted to microsoft.public.access.tablesdbdesign
Daryl S[_2_]
external usenet poster
 
Posts: 881
Default Assistance with Many-to-Many Relationships

Lee Ann -

You have a great start with the separate tables for the officers, suspects,
types of force, charges, and shifts.

You will need to break down the Incident table a little more, since you can
have multiple officers or suspects involved. So here goes:

TblIncident
IncidentID (PK)
CaseNumber
DateandTimeofIncident
NatureofIncident
StreetAddress
City
AreaofIncident
LocationTypeID (FK)
Summary

tblIncidentOfficers
IncidentOfficerID (PK)
IncidendID (FK)
OfficerBadgeNumber (FK)
OfficerShift (FK)

tblIncidentSuspects
IncidentSuspectID (PK)
IncidentID (FK)
SuspectID (FK)
FinalDisposition (FK) 'this assumes only one final disposition per suspect

tblIncidentOfficerForceUsed
IncidentOfficerForceID (PK)
IncidentOfficerID (PK)
SuspectForceUsedOn (PK) ' suspectID

tblIncidentSuspectCharges
IncidentSuspectChargeID (PK)
IncidentSuspectID (FK)
Charges (FK)
OutcomeOfCharges???

--
Daryl S


"Lee Ann" wrote:

I'm looking into correcting a previously developed database that was
originally done and works like an excel spreadsheet (all fields are currently
in one table). In looking at it, there appear to be many many-to-many
relationships involved. This is used to keep records relating to force used
against suspects by police. In one incident, there could be 1 or more
suspects involved, 1 or more officers involved, 1 or more types of force
involved (possibly different force by each officer involved), none/one/more
charges placed on the suspect, and a final disposition on each suspect
involved (jail, hospital, etc). To further confuse the scenario, the shift
that the officer is on at the time of the incident is captured - however if
the same officer is involved in another incident down the road, he/she may be
on a different shift.

I know I will need a linking table to establish the many to many
relationships and am unsure how many tables are required and which fields
should be contained in them. I currently have the following tables relating
to the above information:

TblSuspect
SuspectID (PK)
(identifying information fields)

TblOfficer
OfficerBadgeNumber (PK)
(Officer's first and last name fields)

TblTypeofForce
TypeofForceID (PK)
TypeofForce

TblCharges
ChargesID (PK)
Charges

TblShift
ShiftID (PK)
Shift

TblDisposition
Disposition(PK)
Disposition

I have a main incident table containing information related to the incident:

TblIncident
IncidentID (PK)
CaseNumber
DateandTimeofIncident
NatureofIncident
StreetAddress
City
AreaofIncident
LocationTypeID (FK)
Summary
OfficerBadgeNumber (FK)
SuspectID (FK)

Thanks in advance.




  #4  
Old February 24th, 2010, 05:56 PM posted to microsoft.public.access.tablesdbdesign
Lee Ann[_2_]
external usenet poster
 
Posts: 38
Default Assistance with Many-to-Many Relationships

Thanks Daryl and Bruce for your quick response(s).

For Bruce, would your comment on the disposition still be true if there is
more than one suspect, both of them having a different disposition (i.e., two
suspects with one going to the hospital and one going to jail) within the
same incident?

Correct - LocationTypeID is the type of locale where the incident occurs
(bar, street, residence, etc.) and there will only be one location per
incident.

"BruceM via AccessMonster.com" wrote:

I think Disposition is an attribute of Incident. There can be a lookup table
for dispositions, but no need I can see for a junction table.

From what I can see, there would be junction tables for:

IncidentSuspect
IncidentOfficer
IncidentCharges

Since the type of force used is specific to an officer at an incident, the
ForceUsed table would be related to the IncidentOfficer table. The Shift
could be a linking field to a Shift table, or you could just store the value
(1st, 2nd, etc.). Here is an idea of what the IncidentOfficer table could
look like:

tblIncidentOfficer
IO_ID (primary key, or PK)
IncidentID (link to tblIncident)
OfficerID (link to tblOfficer)
Shift

Here is a listing of types of force:

tblForce
ForceID (PK)
Description

Here is the Force Used listing (also a junction table):

tblForceUsed
ForceUsedID (PK)
IO_ID (link to tblIncidentOfficer)
ForceID (link to tblForce)
Comments

Incident is the top-level table, so it does not contain foreign key fields
for Officer and Suspect. One incident: many officers and one officer: many
incidents, so there is a many-to-many relationship between officers and
incidents. The foreign key (linking) field is in the table on the many side
of the relationship (the junction table in the case of many-to-many). I'm
not sure what LocationTypeID is. However, I suspect it would be stored as an
attribute of the Incident: one LocationType could be in many incidents, so it
would be a foreign key field in the top-level table. One Incident would
involve just one Location Type (I suppose), in which case there is no need to
resolve a many-to-many relationship.

Lee Ann wrote:
I'm looking into correcting a previously developed database that was
originally done and works like an excel spreadsheet (all fields are currently
in one table). In looking at it, there appear to be many many-to-many
relationships involved. This is used to keep records relating to force used
against suspects by police. In one incident, there could be 1 or more
suspects involved, 1 or more officers involved, 1 or more types of force
involved (possibly different force by each officer involved), none/one/more
charges placed on the suspect, and a final disposition on each suspect
involved (jail, hospital, etc). To further confuse the scenario, the shift
that the officer is on at the time of the incident is captured - however if
the same officer is involved in another incident down the road, he/she may be
on a different shift.

I know I will need a linking table to establish the many to many
relationships and am unsure how many tables are required and which fields
should be contained in them. I currently have the following tables relating
to the above information:

TblSuspect
SuspectID (PK)
(identifying information fields)

TblOfficer
OfficerBadgeNumber (PK)
(Officer's first and last name fields)

TblTypeofForce
TypeofForceID (PK)
TypeofForce

TblCharges
ChargesID (PK)
Charges

TblShift
ShiftID (PK)
Shift

TblDisposition
Disposition(PK)
Disposition

I have a main incident table containing information related to the incident:

TblIncident
IncidentID (PK)
CaseNumber
DateandTimeofIncident
NatureofIncident
StreetAddress
City
AreaofIncident
LocationTypeID (FK)
Summary
OfficerBadgeNumber (FK)
SuspectID (FK)

Thanks in advance.


--
Message posted via http://www.accessmonster.com

.

  #5  
Old February 24th, 2010, 06:52 PM posted to microsoft.public.access.tablesdbdesign
Fred
external usenet poster
 
Posts: 1,451
Default Assistance with Many-to-Many Relationships

I suspect that there might be one more more element to be addressed in the
above plans. In your "use of force" recordkeeping requirement, do you need
to record the suspect that it was used on or just the incident where it was
used? I think that all of the responses wer based on the latter.

One thing that I find useful for designing/analyzing structures covering M:M
relationships is to consider the junction table to be a table of entities
rathr than a junction table. For example, considering the
tblIncidentSuspect table to be not a junction table between Insidents and
Suspects but rather a table of "Instances of a Suspect Being Involved in an
Incident". Since yours is unusually complicated in this respect, this might
be helpful.
  #6  
Old February 24th, 2010, 07:10 PM posted to microsoft.public.access.tablesdbdesign
BruceM via AccessMonster.com
external usenet poster
 
Posts: 448
Default Assistance with Many-to-Many Relationships

I missed that one. It would change what I said. However, if there is one
disposition per suspect per incident, I think disposition would be a field in
tblIncidentSuspect. You could (and probably should) have tblDisposition as a
lookup table, and store the key field in tblIncidentSuspect. If there could
be more than one disposition (e.g. hospitalized, then arrested) you would use
a junction table such as I showed for ForceUsed in my previous posting. In a
similar vein, in my previous posting I assumed there could be more than one
type of force used, which is why I suggested the junction table rather than a
single field.

Lee Ann wrote:
Thanks Daryl and Bruce for your quick response(s).

For Bruce, would your comment on the disposition still be true if there is
more than one suspect, both of them having a different disposition (i.e., two
suspects with one going to the hospital and one going to jail) within the
same incident?

Correct - LocationTypeID is the type of locale where the incident occurs
(bar, street, residence, etc.) and there will only be one location per
incident.

I think Disposition is an attribute of Incident. There can be a lookup table
for dispositions, but no need I can see for a junction table.

[quoted text clipped - 100 lines]

Thanks in advance.


--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...esign/201002/1

  #7  
Old February 24th, 2010, 08:13 PM posted to microsoft.public.access.tablesdbdesign
Lee Ann[_2_]
external usenet poster
 
Posts: 38
Default Assistance with Many-to-Many Relationships

Fred - You're correct that it is possible that there would be more than one
type of force used per suspect. Your description/view of the junction table
vs. table of entities is also helpful and will be useful in the future.

Bruce - Although I wasn't clear on the Force issue, the advice you
originally gave is correct for the situation and I'll keep with the
TblForceUsed.

Thank you!

"BruceM via AccessMonster.com" wrote:

I missed that one. It would change what I said. However, if there is one
disposition per suspect per incident, I think disposition would be a field in
tblIncidentSuspect. You could (and probably should) have tblDisposition as a
lookup table, and store the key field in tblIncidentSuspect. If there could
be more than one disposition (e.g. hospitalized, then arrested) you would use
a junction table such as I showed for ForceUsed in my previous posting. In a
similar vein, in my previous posting I assumed there could be more than one
type of force used, which is why I suggested the junction table rather than a
single field.

Lee Ann wrote:
Thanks Daryl and Bruce for your quick response(s).

For Bruce, would your comment on the disposition still be true if there is
more than one suspect, both of them having a different disposition (i.e., two
suspects with one going to the hospital and one going to jail) within the
same incident?

Correct - LocationTypeID is the type of locale where the incident occurs
(bar, street, residence, etc.) and there will only be one location per
incident.

I think Disposition is an attribute of Incident. There can be a lookup table
for dispositions, but no need I can see for a junction table.

[quoted text clipped - 100 lines]

Thanks in advance.


--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...esign/201002/1

.

 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 06:26 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.