Organizational chart represented in a table

Question

I have an Access application, in which I have an employee table. The employees are part of several different levels in the organization. The orgranization has 1 GM, 5 department heads, and under each department head are several supervisors, and under those supervisors are the workers.

Depending on the position of the employee, they will only have access to records of those under them.

I wanted to represent the organization in a table with some sort of level system. The problem I saw with that was that there are many ppl on the same level (for example supervisors) but they shouldn't have access to the records of a supervisor in another department. How should I approach this problem?

Answer 1

One common way of keeping this kind of hierarchical data in a database uses only a single table, with fields something like this:

1. userId (primary key)
2. userName
3. supervisorId (self-referential "foreign key", refers to another userId in this same table)
4. positionCode (could be simple like 1=lakey, 2=supervisor; or a foreign key pointing to another table of positions and such)
5. ...whatever else you need to store for each employee...

Then your app uses SQL queries to figure out permissions. To figure out the employees that supervisor 'X' (whose userId is '3', for example) is allowed to see, you query for all employees where supervisorId=3.

If you want higher-up bosses to be able to see everyone underneath them, the easiest way is just to do a recursive search. I.e. query for everyone that reports to this big boss, and for each of them query who reports to them, all the way down the tree.

Does that make sense? You let the database do the work of sorting through all the users, because computers are good at that kind of thing.

I put the positionCode in this example in case you wanted some people to have different permissions... for example, you might have a code '99' for HR employees which have the right to see the list of all employees.

---

Maybe I'll let some other people try to explain it better...

• Here's an article from Microsoft's Access Cookbook that explains these queries rather well.
• And here is a somewhat chunky explanation of the same.
• Here's a completely different method (the "adjacency list model") that you might find useful, and his explanation is pretty good. He also points out some difficulties with both methods (when he talks about the tables being "denormalized").