Expert design help - for NOOB - Long winded

  • Thread starter Thread starter PA-OAG
  • Start date Start date
P

PA-OAG

I have recently been xferd from a 'Tech' unit to a 'Fraud' unit.
I know it can be done, and our IT people are 'unresponsive' to say the least.
Me - 15+ years in LE, an additional 5 in Comp Forensics, and now back into
Investigations.
The Fraud unit has been using Excel for what I believe is a Access function,
and I'd like to change that. I'd like to construct a DB and give them acces
to forms only where they can enter the follwoing - date, time in, time out
'encounter' (who/where), and service provided. There would be no need to
enter the suspect data, because each DB would be saved locally to the
Investigator's respective suspect investigative folder.
Function - to document a suspect's 'encounters' over multiple years and show
'overlaps' which indicate Fraud....(you cant be in more than 1 place at a
time).
The Fraud unit has, and are using calanders (handwriting or typing) and
entering 'encounter' info on suspects regading where (or with whom), the
date, time in, time out, and encounter type, then entering it into Excel...
Background - There is 1 suspect, numerous encounter times on single dates
which overlap over multiple years.
EX - suspect works for a 'company' BUT does side (various tasks) work for
various people on various dates....we have time info for all.
We are looking to charge the 'overlaps' as Fraud.
I truly apologize for the LONG post, and know that wrapping my head around
'relations' would help....and am self teaching....
Thanks in advance..
 
Sounds like an ideal situation to use Access. There is one thing in your
post that I would disagree with:
"There would be no need to enter the suspect data, because each DB would be
saved locally to the Investigator's respective suspect investigative folder"

With that statement, you have already violated good database design.

The correct way to do this would be to create a split database. A split
database is where you have a front end mdb that contains all the forms,
reports, queries, modlues, and macros. Each user should have a copy of the
front end mdb on their own computer. The data is held in the back end mdb.
It should contain nothing but your tables. You then use the linked table
manager to link to the data in the back end.

You should develop a relational data model. For a quick example, you would
want a Suspect table that has all the demographic data about the suspect.
You should have an Investigator table that has demographic information about
the investigators. Then you should have a SuspectInvestigator table the
contains information about which investigators worked on which suspects case.
Then an encounter table with information on the encounter. And a table that
relates to the encounter table that shows the date information and any other
info about the specific incident.

Good luck. As you go along, please feel free to post back with any more
questions you have.
 
Dave,
Thank you !
YES ! While I have never heard of a 'split database',
your explanation of one is exactly what is needed!!!
That in and of itself is a HUGE help for this noob.

I get caught up in wrapping myself around how to relate tables without
over/under doing both the tables and the fileds within them.
I know that once I can grasp 'relations' it will go a long way to making
this happen.

I'll keep you posted on the development.

Thank you again.
 
Looking forward to staying in touch with you. This is an interesting project.

Do some googling on relational database design. Here is a link to one of the
better books for learning it:

http://books.google.com/books?id=dk...S_enUS241US241&q=database+design+for+mere+mor

In case the link doesn't work, I googled "Database Desing for mere Mortals",
the name of the book.

IMHO, I would read this book before doing anything else. The quality of an
application depends on a good data structure. With a poor structure, coding
the applcation become much more difficult.

Let me know how it goes.
 
Back
Top