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
LVL 23

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 23

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.
Use Case: Protecting a Hybrid Cloud Infrastructure

Microsoft Azure is rapidly becoming the norm in dynamic IT environments. This document describes the challenges that organizations face when protecting data in a hybrid cloud IT environment and presents a use case to demonstrate how Acronis Backup protects all data.

LVL 57
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 84
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 23

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 35

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

Announcing the Most Valuable Experts of 2016

MVEs are more concerned with the satisfaction of those they help than with the considerable points they can earn. They are the types of people you feel privileged to call colleagues. Join us in honoring this amazing group of Experts.

Question has a verified solution.

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

Introduction When developing Access applications, often we need to know whether an object exists.  This article presents a quick and reliable routine to determine if an object exists without that object being opened. If you wanted to inspect/ite…
Overview: This article:       (a) explains one principle method to cross-reference invoice items in Quickbooks®       (b) explores the reasons one might need to cross-reference invoice items       (c) provides a sample process for creating a M…
Familiarize people with the process of utilizing SQL Server views from within Microsoft Access. Microsoft Access is a very powerful client/server development tool. One of the SQL Server objects that you can interact with from within Microsoft Access…
Familiarize people with the process of utilizing SQL Server functions from within Microsoft Access. Microsoft Access is a very powerful client/server development tool. One of the SQL Server objects that you can interact with from within Microsoft Ac…

813 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

Need Help in Real-Time?

Connect with top rated Experts

10 Experts available now in Live!

Get 1:1 Help Now