Relationships between user and task (1 Viewer)

Good morning everyone,

I was just hoping to get a little feed back because I am unsure If I am normalizing too much or not enough. So I have Tables:

Inventory
Boxes
Files

Now I need to record what has been done to each specific file through my other tables:

Task: Action one, Action two, Action three
User: one, two, three

So each box has many files, and each file has many tasks that need to be performed. I was going to use a junction between task and file to keep track of what has and has not been done(tasks completed). I am unsure how I build these tables, and then relate them to the file.

For the Task table would I just put a column for task and then list the different options in the row? Or do I create multiple columns for each task? Or just a table per every task? LOL I thought this would be a easy going into it with my Access for Dummies but this is quite the head spinner when you stare at it for days.

So the inventory part seems pretty easy to me as far as data entry goes. Its keeping track of who is doing what and when. Could anyone let me know if I am on the right track or if I need to rethink my design. Any help appreciated.

I don't know if this matters, but, my initial data-entry point of origin is my file details themselves. Once those are entered, I am trying to track the tasks that take place afterwards.

and each file has many tasks that need to be performed

Click to expand...

presumably each task is applied to many files as well, so you have a many to many relationship. To handle this you need a junction table e.g.

tblFiles
FilePK
BoxFK
FileName
...
...

tblTasks
taskPK
TaskName
...

tblJunctionFileTask
FileTaskPK
FileFK
TaskFK
UserPK
CompleteByDate
CompletedDate
...
...

Thanks CJ London. I was thinking the same thing, just go teally confused when I started making forms and wanted to scrap the whole design. I will try this and let you know. Thank you!

.....
tblJunctionFileTask
FileTaskPK
FileFK
TaskFK
UserPK
CompleteByDate
CompletedDate
...
...

Click to expand...

Another question CJ_London. So this junction box, I already had a junction for User to Task, haven't tested yet. Should I get rid of that and relate my all three File, Task, and User to the same junction box?

You need a clearer, fuller description of WHAT you are trying to accomplish. You are confusing How with What.

Box Files and Tasks for what purpose. Do these relate to a Project, or a worker who will perform the Task?? What sort of info do you need to retrieve from this proposed database?

Thanks for your response Jdraw.

So the goal of the project is to inventory, prep, and document each step thats been taken per file, and by whomever carried out that task. I guess the whole point was instead of tracking everything by separate excel sheets, we wanted to streamline it into one simple process where each step can be documented by each user, per file.

Please let me know if that made sense. I am starting to confuse myself.

Makes sense generally, but it's best to tell us about " a day in the life of your business" that puts all the pieces on paper and gives readers (and you) some context.

This is the first we hear " by whomever carried out that task"

You may get some ideas/insight from this article (just trying to put some ideas forward and you can determine if they are relevant).

Another question CJ_London. So this junction box, I already had a junction for User to Task, haven't tested yet. Should I get rid of that and relate my all three File, Task, and User to the same junction box?

Click to expand...

As mentioned by others you need to clarify what you are trying to achieve.

I included a UserPK field as an example because I'm assuming tasks don't happen by themselves - someone has to do it - so you have a three way junction table. Perhaps it needs to be a four way junction table - a file, a task, a user who sets the task and a user who completes it.

CJ

I think you nailed it with your table structure in #2 (although I use UserFK rather than PK) as shown in attachment

yeah - typo on my part, should have been FK