How to correctly create a fact table and dimension tables?

Question

Database design

Source database tables:
n. Table_name: attributes.
1. Positions: employee_id (FK), position, occupied (date), left (date);
2. Employees: employee_id (PK), date of birth, first name, last name, gender, hired (date);
3. Departments: department_id (PK), department_name;
4. Department-Employee: employee_id (FK), department_id (FK), from_date, to (date);
5. Payments: employee_id (PK), amount (year), from_date, to_date;
What follows is just my guess on how to do it.
Fact table: employee_id, department_id, position_id, payment_date (month), payment_amount Dimension
tables:
Position: position_id (PK), position name...
Dimension Department: department_id (PK), department name...
Dimension Employee: ?
In the dimensions Position, Department, attributes from_date (date of entry) and to_date (date of departure) will be redundant (because there is a payment date in the fact table)?
Employee is a dimension? What will be the gender, date_of_birth, hire_date attributes in this case? Separate hierarchies?

Answer 1

-- Level of sources --
Tables in the form in which the uni is already in the database sources.
In fact, you may have some event with a set of information sufficient to identify it - (Date of payment, Amount of payment, Employee ID).
Everything else is measurements. Gender, date of birth, hired_date are attributes of the Employee dimension. All validity dates (from, to) are stored in dimension tables and determine the state of the attributes of a particular record for sampling on the date of the commission of some fact or on the date of the report.
Here you, based on your detailed level (facts and dimensions), assemble the cube.
(DateYear, DateMonth, Pay Amount, Employee_ID, Department_ID, Position_ID, ... )
This is an example of a variant. There may be options without a detailed level. with pouring from sources directly into the cube. Yes, and many more options.