You can choose to take a simple approach but doing so tends to lead to later headaches. Before you choose the path of development, decide whether this has any potential for growth. If it does, you need to take "leave hours as inventory" approach because of normalization issues. DB normalization is incredibly important as your DB grows. Your current approach is fine for smaller companies but as you grow, this will become limiting - and technically incorrect.
On the other hand, if there is no chance in any of the seven blazing levels of Hell that this could ever grow, you can take a more simplified approach and I will even bless the idea, despite my occasional tendency to be somewhat of a purist.
In the latter case, you track Sick, Vacation, and Holiday time as three numeric fields in the employee's base record. (Trust me, this is a normalization thing... it belongs with the employee.) I would track them as hours, not days, since there are such things as half-a-day sick leave to visit a doctor or dentist, etc. And I would make the numbers SINGLE (real, floating) numbers because you are dealing with things that can be fractional but are unlikely to get very large. Like, when I was a tried and true workaholic, I never had more than 440 hours on the books at one time. A single can handle that amount with no sweat.
Each time you want to change a person's totals, you probably will want a little form that allows you to accrue (Sick, Vacation, Holiday) or charge time to one of those accounts. This action form might be frightening to new users, but keep reading.
As a matter of safety, I would still ALWAYS ALWAYS ALWAYS write a transaction log of what was done to each account. It is a matter of fiduciary responsibility to do so. In the USA, most states actually have laws governing some of the higher-level details of how this is kept. Like, you cannot allow yourself to lose the records of a person's benefits transactions (leave being a benefit, of course) for X number of years. If it is a USA/Federal situation, X is a two-digit number.
As to HOW you would do this, it gets more complex. I think you need some VBA programming. But here is a simple secret on how to get into this a bit deeper without instantaneously getting in over your head.... Wizards.
First, you can create the form itself with a wizard. It will be ugly. It will be "boxy" and plain. It will, however, have everything on it that you need to get the job done. You can drag'n'drop fields around, touch up backgrounds, foregrounds, text colors, box styles, labels, drop in a picture logo, ... with the wizard-grown form as the starting point for your operation.
If you create this form (by wizard or by hand) , you can delete the box with the employee number and build a Combo Box to select your employee. (Enable the control wizards first...) The combo box wizard will ask you what you want to do with the results of selecting an entry. You have choices, one of which is "find this record and display it" - hint hint.
OK, if you want to enter a transaction for that employee, you can use a pushbutton wizard to build an action button AND THE ONCLICK EVENT CODE AT THE SAME TIME!!!! So you can see how things are done. Then you can use the VBA editor to completely change what the button does, if that floats your boat.
Use the wizards to do some of the stuff for you, then peek under the hood, so to speak. Look at what they built. You will start to gather some appreciation for the methods Access uses. A final word of warning... the wizards are truly GREAT as a starting point. But they are also truly DUMB. So use the wizards to get started, but don't stop there. Don't trust the wizards entirely.
I strongly suggest that you start looking into VBA Recordset operations, because if you want to build a log file, you would probably need to open a recordset, do a .AddNew to get a new record, load up the fields (like employee number, date, your name/initials/userID, amount of leave, type of transaction: accrue or use, type of leave: Sick, Vacation, Holiday, etc.), and then do an update of the VBA-opened recordset to include the new record. You would then ALSO update the (form-opened) employee record to include the results of the transaction you just defined.
If forced to keep it simple, I might take the approach of having one text-box with the amount of leave to transact plus six action buttons, ALL of which save the current employee record. The buttons would be { Add/Subtract } { Sick/Vacation/Holiday } and the amount would be in the text box. All six buttons save the employee record, true, but each one applies a different action to the leave totals.
The wizard will build a DoCmd action for you to save the DISPLAYED employee record. (Not the transaction I described earlier.) Before it does so, you can write the transaction to the log recordset and then modify the data shown in the employee record. Then let the record get updated.
For small numbers of employees, this might be totally adequate.
