Employee Management ER Diagram
The code
erDiagram
DEPARTMENT ||--o{ EMPLOYEE : employs
EMPLOYEE ||--o{ TIMESHEET : logs
PROJECT ||--|{ TIMESHEET : collects
EMPLOYEE ||--|{ ASSIGNMENT : holds
PROJECT ||--|{ ASSIGNMENT : requires
DEPARTMENT {
string name
string cost_center
}
EMPLOYEE {
string full_name
string email
date hired_on
}
PROJECT {
string code
string title
}
TIMESHEET {
date work_date
int hours
}
How this template works
Workforce data is some of the most connected data in any company, and this diagram lays out the core of it. Departments employ people, employees log hours against projects, and assignments record who is staffed where. Human resources, engineering managers, and finance can all read the same picture, which is what makes a shared schema diagram worth maintaining.
Read the relationship lines from left to right. DEPARTMENT ||--o{ EMPLOYEE : employs means every employee belongs to exactly one department, while a department can be empty during a reorg. EMPLOYEE ||--|{ TIMESHEET : logs uses the one-or-many symbol because an employee with no timesheet entries is usually a data problem. The pair EMPLOYEE ||--|{ ASSIGNMENT : holds and PROJECT ||--|{ ASSIGNMENT : requires form a classic resolution pattern: the ASSIGNMENT entity carries the staffing relationship between people and projects, and it is the natural home for attributes like start and end dates. Attribute blocks follow the same rules as the other ER templates, one type name line per field, such as date hired_on under EMPLOYEE.
The gotcha in this template is self-reference. The moment you add a manager relationship from EMPLOYEE back to EMPLOYEE, the renderer has to draw a loop, and crowded layouts can make the arrowheads hard to read. It works, but test it early. Also note that attribute types are free text; Mermaid will happily render varchar or uuid, but it will not validate them, so keep the vocabulary consistent with your actual database.
To extend the model, add a SALARY entity for compensation history, an OFFICE entity for locations, or a LEAVE_REQUEST entity for absence tracking. Each one is a single relationship line plus an attribute block, and the diagram stays legible long past a dozen entities.
Related templates to explore next: the banking ledger ER diagram for strict financial integrity rules, the e-commerce ER diagram for high-volume transactional data, and the blog CMS ER diagram for a smaller schema to practice on. The ER diagram guide collects the full notation reference.
Variations to try
- Add a SALARY entity linked to EMPLOYEE if compensation history needs to be tracked over time.
- Connect EMPLOYEE to itself with a manager relationship once you are comfortable reading the cardinality symbols.
- Add an OFFICE entity and link it to DEPARTMENT to model multiple locations.
