MS Access Relationships

Posted on 2014-10-07
Medium Priority
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 24

Accepted Solution

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.

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 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.
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

LVL 59
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 40

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

Become an Android App Developer

Ready to kick start your career in 2018? Learn how to build an Android app in January’s Course of the Month and open the door to new opportunities.

Question has a verified solution.

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

Sometimes MS breaks things just for fun... In Access 2003, only the maximum allowable SQL string length could cause problems as you built a recordset. Now, when using string data in a WHERE clause, the 'identifier' maximum is 128 characters. So, …
Beware when using the ListIndex and the Column() properties of a listbox in Access 2007.  A bug has been identified in the Access 2007 listbox code which can cause the .ListIndex property to return a -1, and the .Columns(#) property to return a NULL…
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…
The Relationships Diagram is a good way to get an overall view of what a database is keeping track of. It is also where relationships are defined. A relationship specifies how two tables connect to each other. As you build tables in Microsoft Ac…
Suggested Courses

621 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