?
Solved

MS Access Relationships

Posted on 2014-10-07
7
Medium Priority
?
196 Views
Last Modified: 2014-10-08
I am creating a Database in MS Access to capture all Field Interviews for a police department so they can track everytime they interact with a subject.  It will be relatively simple, however I am wondering if there is a need for relationships and referential integrity or is it easier to just have all of my fields in one table.  I want to be able to make any of the fields that I have listed below searchable to anyone accessing the DB.  Here are the fields:

Date, Officer name, Subject Name, case ID #'s, DOB, Race, SSN, Location of Contact, Subject Address, Phone #, Vehicle info, Reason for contact, HT, Weight, Hair.

The only fields that will have to be filled out 100% of the time are the Officer's name and subject's name and possibly the case ID's as most of the contact will be made regarding a case #. As of now, I am just using one table and creating my forms based off of that.  I just want to make sure that I will not run into any issues later down the road when trying to search all records relating to a DOB for example.  Thanks for you time.
0
Comment
Question by:K K
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
7 Comments
 
LVL 24

Accepted Solution

by:
Eirman earned 1500 total points
ID: 40367981
If I was designing a database with the above list of fields, I would certainly create a separate table and relationship  for "officer name".  This list  of officers would change from time to time and adding/removing/editing names would be much easier with a table rather than using lookups.

A Field like "race" are unlikely to have added options, so it wouldn't need it's own table.

Fields like DOB and Address , would have quite unique information and would not need their own table.

So in summary, a basic "flat" database (with the exception of Officer Name) should do just fine.

Note: In the officer name table, I would add and extra field called "status" so that only officers who have not retired come up during data entry (but retired officers would be there for searches).
You also could also store other relevant information such as up to date contact info for officers in the officer table. This extra information could be edited without affecting the integrity of the main table.
0
 
LVL 1

Expert Comment

by:foxymoron7
ID: 40368015
Based on the info that you say you want to collect there is no need for additional tables; all of the data can be collected in one table.  Any field/column can be searched in MS Access if I remember correctly, though fields of type MEMO can't be indexed and searches may be slow(?).

The big thing to think about is how the data will be searched.  Will only one person perform the search?  Will the search be performed in Access via query by competent Access users or by a parameterized query run by casual users?  Will the search be performed via some software front end written over top of Access; i.e. a intranet web app written in PHP/VB/ASP/etc?

If you can provide more details about how the user(s) will search the data, then we can give you more specific advice regarding searches.
0
 
LVL 24

Assisted Solution

by:Eirman
Eirman earned 1500 total points
ID: 40368030
Having read your question more carefully, it might be worth creating a table for subjects/interviewees.

I wouldn't do it if the the database consisted mostly of different subjects/interviewees.

However ....
If there are many interviews with the same subjects/interviewees, then a separate table would definitely be worthwhile. This would save repeatedly entering the same information (DOB etc.) and would make for better searching.

You could then design a useful form with the Subject's details at the top of the form, and a scrollable list of interview times, dates, officer etc. at the bottom of the form.
0
Migrating Your Company's PCs

To keep pace with competitors, businesses must keep employees productive, and that means providing them with the latest technology. This document provides the tips and tricks you need to help you migrate an outdated PC fleet to new desktops, laptops, and tablets.

 
LVL 58
ID: 40368049
<<however I am wondering if there is a need for relationships and referential integrity or is it easier to just have all of my fields in one table. >>

  Your mixing up some things here; what your talking about is if you want to normalize or not and the answer is YES.

  Access is a relational database product and is designed to work with a properly designed DB.   If you flat file everything, you'll have problems.

 At a minimum, you'll want a table for the officers, subjects, cases, and interviews.

Jim
0
 
LVL 85
ID: 40368054
I disagree with foxymoron7 - you should NOT store everything in one table. An Officer is not an Interview, and so data regarding an Officer should be stored in an Officer table, and data regarding an Interview should be stored in an Interview table.

Instead, do as Eirman suggests: Setup the tables for a properly normalized database. Storing all data in one table is a bad idea in a relational database engine like Access. You will quickly find yourself hampered when creating Forms, Queries and Reports, and you'll be back at the drawing board before you know it. In short, if you're going to store everything in a single table, just use Excel and save yourself a lot of time.

Data should be stored to correspond with real-world "entities". In your case, some of those Entities might be Officer, InterviewSubject and Interview. There may be more, of course, and you'll discover those as you work through the basics of the design.

Don't put yourself (and your project) behind the eight ball by adopting a denormalized approach, just because it's easier on the front side. Take the time to do things right NOW, and you'll be glad you did later ...
0
 
LVL 24

Expert Comment

by:Eirman
ID: 40368056
Yes Jim you are right .... I forgot about "cases" .... that would need it's own table.
One could frequently interview many people about the one case.

and of course the main table could be called "interviews"
0
 
LVL 38

Expert Comment

by:PatHartman
ID: 40368443
Let me also add that as you create the application, you use a best practices method for naming objects.  Names should only include the characters a-z, A-Z, 0-9, _ (underscore).  NOTHING else.  Some people prefer the CamelCase style where each word is capitalized and others prefer to use the_underscore as a separator.  Pick a style and stick with it.  You also need to be careful to avoid Function names and other reserved words as you name things.  Unless you like to memorized lists containing hundreds of items, the simplest method is to use compound words such as SaleDate or CustName.  Prefixes are appropriate for object names but not for column names.  So, you would prefix tables with t, tbl, t_ or something that identifies the object as a table. q, qry, q_ for queries, etc.  Again, consistency is very important.
0

Featured Post

Ransomware-A Revenue Bonanza for Service Providers

Ransomware – malware that gets on your customers’ computers, encrypts their data, and extorts a hefty ransom for the decryption keys – is a surging new threat.  The purpose of this eBook is to educate the reader about ransomware attacks.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

It’s the first day of March, the weather is starting to warm up and the excitement of the upcoming St. Patrick’s Day holiday can be felt throughout the world.
Did you know that more than 4 billion data records have been recorded as lost or stolen since 2013? It was a staggering number brought to our attention during last week’s ManageEngine webinar, where attendees received a comprehensive look at the ma…
In Microsoft Access, learn how to use Dlookup and other domain aggregate functions and one method of specifying a string value within a string. Specify the first argument, which is the expression to be returned: Specify the second argument, which …
Visualize your data even better in Access queries. Given a date and a value, this lesson shows how to compare that value with the previous value, calculate the difference, and display a circle if the value is the same, an up triangle if it increased…
Suggested Courses

777 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question