MS Access Relationships

Posted on 2014-10-07
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.
Question by:K K
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
LVL 24

Accepted Solution

Eirman earned 500 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.

Expert Comment

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.
LVL 24

Assisted Solution

Eirman earned 500 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.
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

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.

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 ...
LVL 24

Expert Comment

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"
LVL 37

Expert Comment

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.

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

Describes a method of obtaining an object variable to an already running instance of Microsoft Access so that it can be controlled via automation.
As tax season makes its return, so does the increase in cyber crime and tax refund phishing that comes with it
In Microsoft Access, learn how to “cascade” or have the displayed data of one combo control depend upon what’s entered in another. Base the dependent combo on a query for its row source: Add a reference to the first combo on the form as criteria i…
Polish reports in Access so they look terrific. Take yourself to another level. Equations, Back Color, Alternate Back Color. Write easy VBA Code. Tighten space to use less pages. Launch report from a menu, considering criteria only when it is filled…

724 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