2 corrected compound PK info
source | link

Following the question and your comment - I'm not sure that I remember correctly, but I think that MS Access doesn't allow for a primary key with multiple columns, so you'd better add an auto-increment (autonumber in Access) integer column as PK, and add the other needed columns: EmployeeID, Date, Performance, Quality, Attendance. I'm sure that the Employee table could benefit from having a EmployeeID column (simply just use an int that's autonumber or use the SSN of that person..or whatever id you think you have and it's unique). This EmployeeID column would then be used as a reference in other tables (as the one with gathered values for P, Q and A).

Also, I wouldn't make a separate Manager table, but add a column called ManagerID to the Employee table and make it reference the EmployeeID (eg: for EmployeeID = 5, the ManagerId = 1, and based on the IDs you will get their names).

Later edit: found out I'm a dumb Access user, MS Access allows multi column PKs :-). Anyway, it's still much more simple to manage users and reference them by an ID, and not by a compound PK.

In your current situation I'd make 2 tables:

  • Employee - EmployeID, FirstName, LastName, Email, ManagerId; and a second with
  • History: ID, EmployeeID, Date, Performance, Quality, Attendance.

Should be enough for what data you want to gather now.

Following the question and your comment - I'm not sure that I remember correctly, but I think that MS Access doesn't allow for a primary key with multiple columns, so you'd better add an auto-increment (autonumber in Access) integer column as PK, and add the other needed columns: EmployeeID, Date, Performance, Quality, Attendance. I'm sure that the Employee table could benefit from having a EmployeeID column (simply just use an int that's autonumber or use the SSN of that person..or whatever id you think you have and it's unique). This EmployeeID column would then be used as a reference in other tables (as the one with gathered values for P, Q and A).

Also, I wouldn't make a separate Manager table, but add a column called ManagerID to the Employee table and make it reference the EmployeeID (eg: for EmployeeID = 5, the ManagerId = 1, and based on the IDs you will get their names)

Following the question and your comment - I'm not sure that I remember correctly, but I think that MS Access doesn't allow for a primary key with multiple columns, so you'd better add an auto-increment (autonumber in Access) integer column as PK, and add the other needed columns: EmployeeID, Date, Performance, Quality, Attendance. I'm sure that the Employee table could benefit from having a EmployeeID column (simply just use an int that's autonumber or use the SSN of that person..or whatever id you think you have and it's unique). This EmployeeID column would then be used as a reference in other tables (as the one with gathered values for P, Q and A).

Also, I wouldn't make a separate Manager table, but add a column called ManagerID to the Employee table and make it reference the EmployeeID (eg: for EmployeeID = 5, the ManagerId = 1, and based on the IDs you will get their names).

Later edit: found out I'm a dumb Access user, MS Access allows multi column PKs :-). Anyway, it's still much more simple to manage users and reference them by an ID, and not by a compound PK.

In your current situation I'd make 2 tables:

  • Employee - EmployeID, FirstName, LastName, Email, ManagerId; and a second with
  • History: ID, EmployeeID, Date, Performance, Quality, Attendance.

Should be enough for what data you want to gather now.

1
source | link

Following the question and your comment - I'm not sure that I remember correctly, but I think that MS Access doesn't allow for a primary key with multiple columns, so you'd better add an auto-increment (autonumber in Access) integer column as PK, and add the other needed columns: EmployeeID, Date, Performance, Quality, Attendance. I'm sure that the Employee table could benefit from having a EmployeeID column (simply just use an int that's autonumber or use the SSN of that person..or whatever id you think you have and it's unique). This EmployeeID column would then be used as a reference in other tables (as the one with gathered values for P, Q and A).

Also, I wouldn't make a separate Manager table, but add a column called ManagerID to the Employee table and make it reference the EmployeeID (eg: for EmployeeID = 5, the ManagerId = 1, and based on the IDs you will get their names)