Your names may not be confusing now or ever (to you) but ssanfu's suggestion has merit anyway, because you have to guess whether or not a field is a foreign key or not, or you have to open the relationships window and check there, assuming you have created the relationships. What wasn't commented on is that after cautioning you about reserved names, you have a field called Date. This is so common it's not funny. Being lazy, I like DeptID for a field name, and Dept as the department field name. Point is,if you make up abbreviated field names you will almost never fall into this trap. Make Date field name Dte, or ComplDte for example. The alternative is to further identify how Date relates, such as TaskDate, WoDate. In both cases, notice I employed a convention that switches UpperAndLowerCase between distinctive parts. Helps for when double letters don't look right. You should now be able to guess what ComplDte means. Back to the suggestion: I try not to use the underscore (I said I was lazy) so I might use fkTaskID though to be honest I haven't made identifying foreign keys a priority, which is being too lazy, I guess. Now for the normalization part (I am going to call your field TaskID).
Is TaskID related to a table of departments? No! So it should not be there. The task is its own entity so it belongs in its own table. Why have tblDepts in the first place? Because if you add a dept or it's name changes, you simply add another row or change the dept name. Since the DeptID does not change, the name matters not because you will be using DeptID everywhere in order to relate, NOT the name. This is how data is supposed to be organized and related.
tblTask is where DeptID should be for TaskID 1234. Which dept was that assigned to? 5 is what you'd see there, which is whatever department name is on row 5 of tblDepts. What you show in your forms/reports is not 5, but the name that you have included in the query results.
As for tblTaskStatus, TaskID (PK) Status (e.g. Unapproved, Approved, Fini, Complete, Cancel, etc.) and maybe TaskSort (sort order if situation warrants). What status would appear in any given record for a task in the task table? Complete? No, the PK from the status table (maybe 4 for "Complete"). Understanding normalization a bit better? Note: Sort order could be very valuable here. F'rinstance, if you want to enforce that someone cannot choose "Complete" for a combo box IF the task is not even Approved yet, you'd use some type of validation that does not allow a status if its sort value = 1 AND doesn't allow if less than the current sort value AND doesn't allow if the difference > 1. Try doing that by sorting alphabetically!
Tip: I often used Excel to map out a project if it had a lot going on, but I don't suppose that's for everyone. The column headers are table properties. Sometimes, it became evident that a previously defined data type/size was not going to work somewhere else, so it was easier to go back, find it, and correct it. Probably was more useful maintaining consistent data properties when FK creating fields in other tables. Here's what one row might have looked like.
tblName
|
Fld Name |
Desc |
Caption |
Data Type |
PKey |
FKey |
Ind |
Req'd |
Dupes |
Fld Size |
Dflt |
Zero Length |
courseHdr |
courseID |
|
|
TXT |
Y |
|
Y |
Y |
|
15 |
NULL |
|
Only then would I start creating tables.
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.