Table Design and Efficiency Help

mfk5331

New member
Local time
Today, 13:58
Joined
Dec 1, 2025
Messages
2
Hi, I am new to Access and working my way through some online courses to learn everything I can about using it. I am in the process of trying to create a database to use for my work to track monthly productivity stats and annual goals (measured quarterly). Once everything is done, my goal is to have a database where other supervisors who may have little or no knowledge of Access will be able to use various forms to add/edit information, and run reports to see the data.

A little bit about what exactly I’m wanting to do. My company has 31 different stats that we use to measure employees’ productivity each month. I want to be able to track productivity for employees for those stats, then run reports to see those stats by employee, shift, by position, by assignment, etc. We also have 5 annual goals that we track quarterly. These goals do change slightly from year to year, so they are not constant. Our goals are tracked by our fiscal year, which runs from September to August, and broken down into Q1 to Q4, Q1 being September through November. To make it even more complicated, some of our goals have to be met quarterly, some of them have to be met annually. All of the data would be entered by each shift supervisor.

Here is how I have things broken down so far for my tables. I have several reference tables to establish the breakdown of our shifts, positions, different assignments and training. For these, I have tblPositions, with columns PositionID (PK) and Position. Then I have tblShiftList, with columns ShiftID (PK) and ShiftName. Next is tblSpecializedAssignments, with AssignmentID (PK) and SpecializedAssignment columns, then tblSpecializedTraining with TrainingID (PK) and SpecializedTraining columns. Those are all reference tables that I use in tblEmployeeList. This table has EmployeeID (PK), LastName, FirstName, Position, Shift, SpecializedAssignment, SpecializedTraining, Active (checkbox) columns. The Position, Shift, SpecializedAssigment and SpecializedTraining columns are linked to the other reference tables so they are simple drop down menus.

I’m not entirely sure what the best way would be to set up my stats and goals tables would be. My thought would be to have reference tables for those, such as tblStatsList with something like columns StatID (PK) and StatName, then tblGoalsList with columns GoalID (PK) and GoalName. Then have tblStats which would have ID (PK), EmployeeID, StatID, StatValue, and Month/Year columns. In tblGoals, I would have ID (PK), EmployeeID, GoalID, GoalValue, StartDate, and EndDate columns. Since we track the goals quarterly, I’m guessing the Start and End Dates should be by quarter?

My thought is by using reference tables for so many things, I am future proofing the database so as things grow and change, it will be easier to add and change things in the database to keep up. My plan is to have forms set up so even if I move to a different part of the company, other supervisors will be able to keep things updated without needing any kind of special knowledge on Access.

Am I on the right track so far to make everything work the way I’m wanting it to work? I’m looking for any suggestions or advice on how to make this as complete and efficient as possible.
 
It's quite a story (and one that sounds familiar to me).

One of the main problems is that you only think in terms of static personnel data, while it's actually dynamic. In tblStats, you record the EmployeeID. The employee table contains various attributes (position, assignment, and others) you want to track.
But you only know an employee's current value. What if an employee had position A at the beginning of the year and B at the end? How can you still report on the beginning of the year at the end of the year? And what if the position changes during a quarter?
 
Is there anything I can do to prevent that?
 
Part of the solution could be to store the current employee data in the tblStats.
But before thinking about solutions, you need business rules. Like: how to deal with employee data that changes during a quarter.
It's a common problem that inexperienced developers start building a database too quickly. First, analyze the information needs and the possible situations that might arise.
Also consider the environment. I can't imagine that the 31 stats aren't already registered elsewhere. It wouldn't make sense to manually enter them again into another system.
 
You have a great understanding for a first post. So obviously the below Entity Relationship Diagram (ERD) is not going to be fully correct (no doubt massively wrong knowing me) but a gist. Pretty much everyone on the forum is more capable than myself, but in trying to lend a helping hand; I would think that only certain Employees could work certain shifts based on qualifications/ training. So consider coming from that angle to optimize normalization.

Regarding timescales of different goals... that is all going to be down to querying data, which appears you may not have done yet. You'll be restricting combo-boxes to show only suitable employees whom are qualified to do the work. Restricting combo-box selections to Assignments that are only Live (not past completed assignments)... with countless permutations & possibilities.

All based on forms... that is exactly how a db should be.

Whilst learning (& still am learning massively) I can recommend the following books. I like yourself started working on something for work. I ended up quitting my job & working on the project full time; so watch out; Access is addictive. @arnelgp & @Mike Krailo recommended books, which was an excellent suggestion. I got a far deeper understanding from the books in a well written manner. Opposed to searching the net for scraps; often on ill-conceived basis'. The books got me there so much quicker. But still we're talking around 5,000 pages in them books to absorb (I've only done the first two fully). It's been 14 months since I quit my job & I keep going deeper, now onto MSSQL Server, so be careful, it really is addictive :ROFLMAO:. An even better resource is this forum, where users advise on advanced techniques not available in any books but he books are helpful to grasp basic priniciples (and some advanced also).
  • Access 2010 Inside Out - By Jeff Conrad & John L. Viescas
  • Access 2010 VBA Programming Inside Out - By Andrew Couch
  • Microsoft Jet Database Engine Programmer's Guide 2nd Edition - By Dan Haught & Jim Ferguson


1764584339064.png
 
Last edited:
Here is how I have things broken down so far for my tables. I have several reference tables to establish the breakdown of our shifts, positions, different assignments and training. For these, I have tblPositions, with columns PositionID (PK) and Position. Then I have tblShiftList, with columns ShiftID (PK) and ShiftName. Next is tblSpecializedAssignments, with AssignmentID (PK) and SpecializedAssignment columns, then tblSpecializedTraining with TrainingID (PK) and SpecializedTraining columns. Those are all reference tables that I use in tblEmployeeList. This table has EmployeeID (PK), LastName, FirstName, Position, Shift, SpecializedAssignment, SpecializedTraining, Active (checkbox) columns. The Position, Shift, SpecializedAssigment and SpecializedTraining columns are linked to the other reference tables so they are simple drop down menus.

I’m not entirely sure what the best way would be to set up my stats and goals tables would be. My thought would be to have reference tables for those, such as tblStatsList with something like columns StatID (PK) and StatName, then tblGoalsList with columns GoalID (PK) and GoalName. Then have tblStats which would have ID (PK), EmployeeID, StatID, StatValue, and Month/Year columns. In tblGoals, I would have ID (PK), EmployeeID, GoalID, GoalValue, StartDate, and EndDate columns. Since we track the goals quarterly, I’m guessing the Start and End Dates should be by quarter?
Your post mentions "SpecializedAssignment columns, Active (checkbox), and columns Month/Year columns". This implies you are storing data as field names which goes against normalization. For instance, if you have column names like "DaysTardy", "DaysExcused", "DaysNotExcused" then you are creating a spreadsheet, not a relational database and you need to read about normalization.
 
My advice is dive in.

Seems like you have a good enough grasp of things to get started. Open up Access and set up the tables and fields you think you will need. Then complete the Relationship Tool in Access, expand all tables in it so you can see all the fields, take a screenshot of it and post it back here and we can help you fine tune it to the structure you need.
 
As there will not be any data in it, you could even upload the DB?
 
I'm going to join the "Normalization" bandwagon with a specific suggestion.

Stop designing anything until you have read up on and are comfortable with "Database Normalization" - except that you can certainly search this forum for "Normalization" because we ARE a database site. However, on the general web, you must qualify the search because normalization occurs in math, chemistry, politics and international relations, medicine, social studies, ... you get the idea.

When you search online for tutorials on database normalization, start with items from the .EDU domain for the first couple of articles. Once you start to see what is going on, .COM domain is OK. I say don't start with .COM because often they have something to sell or talk about proprietary products that wouldn't be of general use. When working on an Access database, if you can get whatever you are building to 3rd-normal form (which you would learn about from tutorials), that is usually good enough to operate efficiently with Access. And all of those "grouped" reports you talked about - by quarterly, by employee, by position, by department, etc. - would be EASILY supported.

One side-effect of normalization is that to gather all the data you wanted to analyze, you might sometimes need to perform what is called a JOIN query. This is a natural side-effect of normalization and is a GOOD thing. Be sure that you also study JOINs - but not until you understand WHY you split tables.

Having said the above, you appear to be deeply delving into the problem, and that is good. Here is a link to an old post of mine that might also be helpful. Or not, but that will be up to you.

 

Users who are viewing this thread

Back
Top Bottom