Thiết Kế Cơ Sở Dữ Liệu Quản Lý Nhân Sự Dựa trên cá...

Thiết Kế Cơ Sở Dữ Liệu Quản Lý Nhân Sự
Dựa trên các yêu cầu chức năng của hệ thống quản lý nhân viên được mô tả trong tài liệu của bạn
1
, dưới đây là đề xuất thiết kế các bảng cơ sở dữ liệu (Database Schema) tối ưu, được xây dựng để đáp ứng trọn vẹn logic nghiệp vụ của dự án:

1. Bảng departments (Quản lý phòng ban)
   Bảng này lưu trữ thông tin về các phòng ban trong công ty. Root account có toàn quyền thêm, sửa, xóa phòng ban
   1
   .
   Tên trường
   Kiểu dữ liệu
   Thuộc tính
   Mô tả
   id
   BigIncrement
   Primary Key
   ID tự tăng của phòng ban.
   name
   VARCHAR(100)
   Unique, Not Null
   Tên phòng ban (ví dụ: Nhân sự, Công nghệ...).
   description
   TEXT
   Nullable
   Mô tả ngắn về phòng ban.
   manager_id
   BigInteger
   Foreign Key
   ID của nhân viên làm Trưởng phòng
   1
   . Liên kết tới users.id (Có thể Null nếu phòng ban chưa có quản lý).
   created_at / updated_at
   Timestamp
   Thời gian tạo và cập nhật phòng ban.

---

2. Bảng users (Quản lý tài khoản & Nhân viên)
   Bảng này lưu trữ toàn bộ thông tin tài khoản của hệ thống (bao gồm cả Root, Quản lý, và Nhân viên)
   1
   .
   Tên trường
   Kiểu dữ liệu
   Thuộc tính
   Mô tả
   id
   BigIncrement
   Primary Key
   ID tự tăng của nhân viên.
   name
   VARCHAR(255)
   Not Null
   Họ và tên nhân viên
   1
   .
   email
   VARCHAR(255)
   Unique, Not Null
   Email dùng để đăng nhập và nhận thông tin xác thực/reset mật khẩu
   1
   .
   email_verified_at
   Timestamp
   Nullable
   Thời gian xác thực email khi tài khoản được tạo mới hoặc reset
   1
   .
   password
   VARCHAR(255)
   Not Null
   Mật khẩu đã được mã hóa an toàn bằng thuật toán băm (Hashing) của Laravel
   1,2
   .
   role
   ENUM
   Not Null
   Phân quyền hệ thống: root, manager (quản lý), employee (nhân viên)
   1
   .
   department_id
   BigInteger
   Foreign Key, Nullable
   ID phòng ban mà nhân viên thuộc về
   1
   . Liên kết tới departments.id (Tài khoản Root sẽ để Null).
   must_change_password
   Boolean
   Default: true
   Cờ đánh dấu bắt buộc đổi mật khẩu trong lần đầu đăng nhập hoặc sau khi bị reset password bởi Root
   1
   .
   created_at / updated_at
   Timestamp
   Thời gian tạo tài khoản và cập nhật thông tin
   1
   .

---

3. Bảng attendances (Quản lý chấm công hàng ngày)
   Bảng này lưu lại lịch sử Check-in và Check-out hàng ngày của nhân viên, phục vụ trực tiếp cho việc tính toán và xuất báo cáo Excel về số ngày/giờ làm việc của quản lý
   1
   .
   Tên trường
   Kiểu dữ liệu
   Thuộc tính
   Mô tả
   id
   BigIncrement
   Primary Key
   ID lịch sử chấm công.
   user_id
   BigInteger
   Foreign Key, Not Null
   ID nhân viên thực hiện chấm công
   1
   . Liên kết tới users.id.
   date
   DATE
   Not Null
   Ngày chấm công (Y-m-d). Đảm bảo một nhân viên chỉ có 1 bản ghi chấm công mỗi ngày (Unique cho cặp user_id và date).
   check_in_at
   TIME
   Nullable
   Giờ thực hiện Check-in
   1
   .
   check_out_at
   TIME
   Nullable
   Giờ thực hiện Check-out
   1
   .
   total_hours
   DECIMAL(4,2)
   Default: 0.00
   Số giờ làm việc thực tế trong ngày (được tính toán khi nhân viên thực hiện Check-out để tiện xuất Excel báo cáo giờ làm việc hàng tháng)
   1
   .

---

4. Bảng leave_requests (Yêu cầu nghỉ phép)
   Bảng này quản lý quy trình gửi yêu cầu xin nghỉ phép của nhân viên và trạng thái phê duyệt của Root hoặc Quản lý phòng ban
   1
   .
   Tên trường
   Kiểu dữ liệu
   Thuộc tính
   Mô tả
   id
   BigIncrement
   Primary Key
   ID của yêu cầu nghỉ phép.
   user_id
   BigInteger
   Foreign Key, Not Null
   ID nhân viên tạo yêu cầu nghỉ phép
   1
   . Liên kết tới users.id.
   reason
   TEXT
   Not Null
   Lý do xin nghỉ phép
   1
   .
   start_date
   DATE
   Not Null
   Ngày bắt đầu nghỉ phép.
   end_date
   DATE
   Not Null
   Ngày kết thúc nghỉ phép.
   status
   ENUM
   Default: pending
   Trạng thái yêu cầu: pending (đang chờ), approved (đã duyệt), rejected (bị từ chối)
   1
   .
   approved_by
   BigInteger
   Foreign Key, Nullable
   ID của người thực hiện phê duyệt (chỉ có thể là Root hoặc Quản lý trực tiếp của phòng ban)
   1
   . Liên kết tới users.id.
   status_note
   TEXT
   Nullable
   Ghi chú lý do phê duyệt hoặc từ chối (nếu có).
   created_at / updated_at
   Timestamp
   Thời gian tạo yêu cầu và thời gian phê duyệt.

---

Mối quan hệ giữa các bảng (Eloquent Relationships trong Laravel)
2
:
User & Department:
Một phòng ban (Department) có nhiều nhân viên (User) -> Quan hệ HasMany
2
.
Một nhân viên (User) thuộc về một phòng ban -> Quan hệ BelongsTo
2
.
Department & Manager:
Một phòng ban có một Trưởng phòng (User) quản lý -> Quan hệ BelongsTo
2
.
User & Attendance:
Một nhân viên có nhiều lượt chấm công (Attendance) -> Quan hệ HasMany
2
.
User & LeaveRequest:
Một nhân viên có nhiều yêu cầu nghỉ phép (LeaveRequest) -> Quan hệ HasMany
2
Project Intern: Hệ thống quản lý nhân viên

1. Chức năng cho root account
   Có thể đăng nhập sử dụng root account với username/password mặc định.
   Cho phép tạo các account nhân viên, gửi email xác thực tài khoản
   Cho phép thêm, sửa, xóa các phòng ban
   Cho phép thêm, sửa, xóa các nhân viên
   Cho phép điều chỉnh nhân viên phụ thuộc bộ phận nào, quản lý phòng ban nào.
   Cho phép reset password của mộ hoặc nhiều account cùng 1 lúc
   Phê duyệt/ Từ chối yêu cầu nghỉ phép

2. Chức năng cho nhân viên
   Có email xác thực khi được tạo tài khoản hoặc reset passowrd bởi root account
   Có thể đăng nhập. Yêu cầu đổi mật khẩu trong lần đầu đăng nhập hoặc reset password
   Có thể xem thông tin cá nhân của mình
   Check in/Check out hàng ngày
   Tạo yêu cầu xin nghỉ phép, gửi mail cho root và quản lý phòng ban (1 trong 2 approve )

3. Chức năng cho quản lý phòng ban
   Có chức năng giống nhân viên
   Cho phép xem, chỉnh sửa thông tin các nhân của mình
   Cho phép xem thông tin của cấp dưới của mình
   Xuất danh sách nhân viên của phòng ra file excel
   Phê duyệt/ Từ chối yêu cầu nghỉ phép
   Xuất báo cáo số ngày làm việc, giờ làm việc trong tháng của mỗi nhân viên ra excel
   Tìm hiểu specs
   (Issue #1)

4. Q&A
   (Issue #2)

5. PTTK - TopDown Design
   (Issue #3)

6. PTTK - Vẽ biểu đồ Use Case
   (Issue #4)

7. PTTK - Sequence diagram
   (Issue #5)

8. Thiết kế Database
   (Issue #6)

9. Mockup Layouts
   (Issue #7)

10. Estimate
    (Issue #8)

11. Init project Laravel with Docker
    (Issue #9)

12. DB - Model - Migration - Seeder
    (Issue #10)

13. Auth with Sanctum
    (Issue #11)

14. Feature - Quản lý nhân viên
    (Issue #12)

15. Feature - Quản lý phòng ban
    (Issue #13)

16. Feature - Quản lý request
    (Issue #14)

17. Feature - Checkin / Checkout
    (Issue #15)

18. Feature - Gửi Timesheet hàng tháng
    (Issue #16)
    tạo 1 báo cáo đầy đủ làm đủ các issue, kiểm tra lại database của tôi, nhận xét và góp ý, báo cáo có đầy đủ usecase, sequence diagram, mockup layout ,

19. Đối với biểu đồ Use Case (UC)
    Biểu đồ Use Case dùng để thể hiện phạm vi hệ thống và quyền hạn của các tác nhân
    .
    Không vẽ: Từng nút bấm hay từng hành động đơn lẻ (ví dụ: không tách "Xem phòng ban", "Thêm phòng ban", "Sửa phòng ban", "Xóa phòng ban" thành 4 Use Case riêng biệt)
    .
    Nên làm: Gom nhóm chúng lại thành các Use Case tổng quát
    . Ví dụ:
    Gom các tác vụ thêm, sửa, xóa thành một Use Case duy nhất là "Quản lý phòng ban (CRUD)" hoặc "Quản lý nhân viên (CRUD)"
    .
    Giữ các Use Case mang tính chất đặc thù đứng độc lập như: "Check-in/Check-out hàng ngày", "Yêu cầu nghỉ phép", "Xuất báo cáo Excel"
    .

20. Đối với Sequence Diagram (Biểu đồ tuần tự)
    Sequence Diagram thể hiện sự tương tác theo thời gian giữa các thành phần (Vue.js, Nginx, Laravel, Database, Redis, MinIO)
    .
    Không vẽ: Cho các chức năng đọc/ghi dữ liệu đơn giản (như "Xem thông tin cá nhân" chỉ là một lệnh GET API lấy dữ liệu từ DB rồi hiển thị lên màn hình)
    .
    Chỉ vẽ cho các luồng nghiệp vụ phức tạp, có nhiều logic kiểm tra (Validation), hoặc có sự tham gia của các dịch vụ bên thứ ba (Redis, MinIO)
    .
    Đối với các chức năng thêm/sửa/xóa (CRUD) cơ bản, bạn chỉ cần vẽ đúng 1 biểu đồ Sequence mẫu đại diện (ví dụ: "Luồng xử lý CRUD tiêu chuẩn") và ghi chú rằng các chức năng CRUD khác sẽ áp dụng tương tự
    .
    Đề xuất 4 luồng nghiệp vụ CẦN vẽ Sequence Diagram trong dự án này:
    Để đồ án của bạn đạt điểm tối đa về mặt thiết kế hệ thống, bạn chỉ cần tập trung vẽ cụ thể biểu đồ tuần tự cho 4 luồng cốt lõi sau:
    Luồng Đăng nhập & Đổi mật khẩu lần đầu:
    Tại sao cần: Vì luồng này có logic kiểm tra cờ must_change_password từ DB
    . Nếu là true, Laravel Backend yêu cầu Vue.js phải chuyển hướng người dùng sang trang đổi mật khẩu trước khi cho phép truy cập các chức năng khác
    .
    Luồng Check-in / Check-out hàng ngày:
    Tại sao cần: Thể hiện cách Vue.js gửi yêu cầu, Laravel nhận request, ghi nhận thời gian vào bảng attendances, kiểm tra điều kiện ràng buộc (một nhân viên chỉ được phép chấm công 1 bản ghi/ngày) và tính toán số giờ làm việc thực tế
    .
    Luồng Tạo đơn xin nghỉ phép & Phê duyệt (Có Queue + Redis):
    Tại sao cần: Đây là luồng thể hiện kiến trúc nâng cao của bạn
    . Nhân viên gửi yêu cầu xin nghỉ -> Laravel lưu vào DB -> Đẩy tác vụ gửi Email xác thực vào hàng đợi Redis để gửi mail ngầm cho Root/Quản lý -> Quản lý nhận mail và thực hiện Phê duyệt/Từ chối trên giao diện
    .
    Luồng Xuất báo cáo ngày/giờ làm việc ra file Excel (Có MinIO):
    Tại sao cần: Thể hiện cách Quản lý yêu cầu xuất file -> Laravel truy vấn dữ liệu chấm công hàng loạt -> Sử dụng thư viện xuất tệp Excel -> Đẩy file Excel lưu trữ trực tiếp lên MinIO -> Trả về đường link tải file an toàn cho giao diện Vue.js
    .