i should have specifically answered your EmployeeID question - wherever you want to relate a record from one table to your employees, you will need to include the EmployeeID. the idea of the EmployeeID is that you don't have to write out all the employee's details in every table in every record - instead you just put the one ID.
(e.g., "1" vs "Mr. Harry John Ferris, 12/2356 Unit Drive Alabama USA").
The idea here is that "1" will always be Mr Ferris, regardless of whether he changes is address, see.
This was a rather simplistic example, but it holds true for other things - the point being that the PK ID ought to always be autonumber, in case other parts in that record change (a Miss A could get married and become a Mrs B - she's still the same person, and her records are still hers, and her PK ID will remain unchanged, but if you use Employee Name as your PK what would you do about Miss A?).
one very good example is when ISBN standards changed from ISBN-10 to ISBN-13: i don't think anyone thought it would ever change, it was soooooo standard. but it did. and if you used autonumber ID, you'd be fine - but if you use ISBN as your primary key you'd be stuffed b/c you'd have to change it not only at the PK site, but in all the FK sites too, so that access (or other relational DBs) could still tell that it was the same book, but just that the standard reference to it had changed.