MS Access Relationships

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.
K KAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

EirmanChief Operations ManagerCommented:
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.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
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.
EirmanChief Operations ManagerCommented:
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.
Active Protection takes the fight to cryptojacking

While there were several headline-grabbing ransomware attacks during in 2017, another big threat started appearing at the same time that didn’t get the same coverage – illicit cryptomining.

Jim Dettman (Microsoft MVP/ EE MVE)President / OwnerCommented:
<<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.

Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
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 ...
EirmanChief Operations ManagerCommented:
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"
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.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Access

From novice to tech pro — start learning today.