Leave Management মডিউলের প্রতিটি টেবিলের জন্য ফিল্ড সহ একটি উন্নত ডেটাবেজ ডিজাইন প্রদান করা হলো। প্রতিটি টেবিলের কাজ, ফিল্ডের বিবরণ, এবং রিলেশন দেওয়া হয়েছে যা জটিল Leave Management সিস্টেমের জন্য কার্যকর হবে।
Leave Management Database Design with Field Details
স্টেপ ১: Leave Types Creation
1. leave_types টেবিল:
এই টেবিলটি প্রতিটি কোম্পানির জন্য বিভিন্ন ধরনের ছুটির শ্রেণী সংরক্ষণ করবে।
| Field Name | Data Type | Description |
|---|---|---|
| leave_type_id | INT (PK) | প্রতিটি ছুটির ধরণের জন্য ইউনিক আইডি |
| company_id | INT (FK) | কোম্পানির আইডি (যার সাথে ছুটির ধরন সম্পর্কিত) |
| leave_type_name | VARCHAR(50) | ছুটির ধরণ (যেমন, Casual Leave, Sick Leave) |
| leave_code | VARCHAR(20) | ছুটির কোড (ইউনিক আইডেন্টিফায়ার) |
| max_days_per_year | INT | প্রতি বছরে ছুটির সর্বোচ্চ সংখ্যা |
| carry_forward | BOOLEAN | ছুটি পরবর্তী বছরে নেয়া যাবে কিনা (True/False) |
| created_at | TIMESTAMP | তৈরি করার তারিখ |
| updated_at | TIMESTAMP | আপডেট করার তারিখ |
রিলেশন:
company_idcompanies টেবিলের সাথে সংযুক্ত থাকবে, যা নিশ্চিত করবে যে প্রতিটি ছুটির ধরন নির্দিষ্ট কোম্পানির অধীনে রয়েছে।
স্টেপ ২: Define Leave Policies
2. leave_policies টেবিল:
এই টেবিলটি প্রতিটি leave_type এর জন্য কোম্পানির নির্দিষ্ট নীতিমালা সংরক্ষণ করবে।
| Field Name | Data Type | Description |
|---|---|---|
| policy_id | INT (PK) | ছুটির নীতিমালার জন্য ইউনিক আইডি |
| company_id | INT (FK) | কোম্পানির আইডি (যার সাথে নীতিমালা সম্পর্কিত) |
| leave_type_id | INT (FK) | ছুটির ধরণ আইডি (leave_types থেকে) |
| applicable_for | VARCHAR(50) | কারা এই নীতিমালা পাবে (যেমন, All Employees, Managers) |
| description | TEXT | নীতিমালার বিবরণ |
| effective_date | DATE | নীতিমালার কার্যকরী তারিখ |
| created_at | TIMESTAMP | তৈরি করার তারিখ |
| updated_at | TIMESTAMP | আপডেট করার তারিখ |
রিলেশন:
company_idcompanies টেবিলের সাথে এবংleave_type_idleave_types টেবিলের সাথে সংযুক্ত থাকবে, যা নিশ্চিত করবে যে প্রতিটি ছুটির নীতিমালা নির্দিষ্ট কোম্পানির অধীনে একটি নির্দিষ্ট ছুটির ধরনকে প্রযোজ্য।
স্টেপ ৩: Employee Leave Applications
3. employee_leaves টেবিল:
এই টেবিলটি কর্মীদের ছুটির আবেদন সংরক্ষণ করবে।
| Field Name | Data Type | Description |
|---|---|---|
| leave_id | INT (PK) | ছুটির জন্য ইউনিক আইডি |
| employee_id | INT (FK) | কর্মীর আইডি (যে কর্মী ছুটি চেয়েছেন) |
| leave_type_id | INT (FK) | ছুটির ধরণ (যেমন, Sick Leave, Casual Leave) |
| start_date | DATE | ছুটি শুরুর তারিখ |
| end_date | DATE | ছুটি শেষের তারিখ |
| total_days | INT | মোট ছুটির দিন |
| reason | TEXT | ছুটির কারণ |
| status | ENUM | ছুটির অবস্থা (Pending, Approved, Rejected) |
| applied_on | TIMESTAMP | ছুটি আবেদন করার তারিখ |
| created_at | TIMESTAMP | তৈরি করার তারিখ |
| updated_at | TIMESTAMP | আপডেট করার তারিখ |
রিলেশন:
employee_idemployees টেবিলের সাথে এবংleave_type_idleave_types টেবিলের সাথে সংযুক্ত থাকবে, যা নিশ্চিত করবে যে প্রতিটি ছুটি আবেদন নির্দিষ্ট কর্মী এবং ছুটির ধরনের সাথে সম্পর্কিত।
স্টেপ ৪: Approval Workflow Setup
4. approval_workflow টেবিল:
এই টেবিলটি প্রতিটি leave_type এর জন্য অনুমোদন ওয়ার্কফ্লো এবং এর ধাপ নির্ধারণ করবে।
| Field Name | Data Type | Description |
|---|---|---|
| workflow_id | INT (PK) | অনুমোদনের ওয়ার্কফ্লো আইডি |
| company_id | INT (FK) | কোম্পানির আইডি |
| leave_type_id | INT (FK) | ছুটির ধরণ আইডি |
| approver_level | INT | অনুমোদনের স্তর (যেমন, ১ = প্রথম স্তর, ২ = দ্বিতীয় স্তর) |
| approver_role | VARCHAR(50) | অনুমোদকের ভূমিকা (যেমন, Department Head, HR Manager) |
| escalation_days | INT | কত দিন পর এটি পরবর্তী স্তরে যাবে |
| created_at | TIMESTAMP | তৈরি করার তারিখ |
| updated_at | TIMESTAMP | আপডেট করার তারিখ |
রিলেশন:
company_idcompanies এবংleave_type_idleave_types টেবিলের সাথে সংযুক্ত থাকবে। প্রতিটি ছুটি ওয়ার্কফ্লো নির্দিষ্ট কোম্পানি এবং ছুটির ধরন অনুযায়ী থাকবে।
স্টেপ ৫: Leave Approvals
5. leave_approvals টেবিল:
এই টেবিলটি প্রতিটি ছুটির আবেদনের বিভিন্ন স্তরের অনুমোদন সংরক্ষণ করবে।
| Field Name | Data Type | Description |
|---|---|---|
| approval_id | INT (PK) | ছুটি অনুমোদনের জন্য ইউনিক আইডি |
| leave_id | INT (FK) | ছুটির আইডি (employee_leaves থেকে) |
| approver_id | INT (FK) | অনুমোদকের আইডি |
| approval_level | INT | অনুমোদনের স্তর |
| approval_status | ENUM | অনুমোদনের অবস্থা (Approved, Rejected, Pending) |
| approval_date | TIMESTAMP | অনুমোদনের তারিখ |
| remarks | TEXT | মন্তব্য (যদি থাকে) |
| created_at | TIMESTAMP | তৈরি করার তারিখ |
| updated_at | TIMESTAMP | আপডেট করার তারিখ |
রিলেশন:
leave_idemployee_leaves টেবিলের সাথে এবংapprover_idemployees টেবিলের সাথে সংযুক্ত থাকবে, যা প্রতিটি অনুমোদন স্তরের তথ্য সংরক্ষণ করবে।
স্টেপ ৬: Leave Escalations
6. leave_escalations টেবিল:
এই টেবিলটি নির্দিষ্ট সময়ে অনুমোদন না হলে, ছুটির আবেদন পরবর্তী স্তরে স্বয়ংক্রিয়ভাবে এস্কেলেট করা হবে।
| Field Name | Data Type | Description |
|---|---|---|
| escalation_id | INT (PK) | এস্কেলেশনের জন্য ইউনিক আইডি |
| leave_id | INT (FK) | ছুটির আইডি |
| current_level | INT | বর্তমান অনুমোদনের স্তর |
| escalated_to_level | INT | এস্কেলেট করা স্তর |
| escalation_date | TIMESTAMP | এস্কেলেশনের তারিখ |
| reason | TEXT | এস্কেলেশনের কারণ |
| created_at | TIMESTAMP | তৈরি করার তারিখ |
| updated_at | TIMESTAMP | আপডেট করার তারিখ |
রিলেশন:
leave_idemployee_leaves টেবিলের সাথে সংযুক্ত থাকবে, যা নিশ্চিত করবে যে কোনো নির্দিষ্ট স্তরে অনুমোদন না হলে, স্বয়ংক্রিয়ভাবে পরবর্তী স্তরে এস্কেলেশন করা যায়।
স্টেপ ৭: Leave Balance Update
7. leave_balance টেবিল:
এই টেবিলটি কর্মীদের ব্যবহৃত ও অবশিষ্ট ছুটির হিসাব সংরক্ষণ করবে।
| Field Name | Data Type | Description |
|---|---|---|
| balance_id | INT (PK) | ছুটির ব্যালেন্সের জন্য ইউনিক আইডি |
| employee_id | INT (FK) | কর্মীর আইডি |
| leave_type_id | INT (FK) | ছুটির ধরণ |
| total_allocated_days | INT | বরাদ্দকৃত মোট ছুটির দিন |
| used_days | INT | ব্যবহৃত ছুটির দিন |
| remaining_days | INT | অবশিষ্ট ছুটির দিন |
| last_updated | TIMESTAMP | সর্বশেষ আপডেটের তারিখ |
| created_at | TIMESTAMP | তৈরি করার তারিখ |
| updated_at | TIMESTAMP | আপডেট করার তারিখ |
রিলেশন:
employee_idemployees টেবিলের সাথে এবংleave_type_idleave_types টেবিলের সাথে সংযুক্ত থাকবে, যা নিশ্চিত করবে যে প্রতিটি কর্মীর ছুটির ব্যালেন্স নির্দিষ্ট ছুটির ধরন অনুযায়ী সংরক্ষিত।
সারসংক্ষেপ
এই আপডেটেড Leave Management Database Design এ প্রতিটি টেবিলের ভূমিকা, ফিল্ডের বিবরণ এবং স্টেপ-বাই-স্টেপ প্রক্রিয়ার মাধ্যমে ছুটির আবেদন থেকে চূড়ান্ত অনুমোদন পর্যন্ত পুরো প্রক্রিয়াটি সুসংহতভাবে সম্পন্ন করা যায়। এতে বহু-স্তরের অনুমোদন, এস্কেলেশন, এবং ছুটির ব্যালেন্স আপডেট সহজ এবং কার্যকরভাবে সম্পাদন করা সম্ভব, যা বড় ও জটিল প্রতিষ্ঠানের Leave Management এর জন্য আদর্শ।
একটি গার্মেন্টস কোম্পানি “ABC Garments Ltd.” এর জন্য Leave Management মডিউলটি কিভাবে কাজ করবে, তা নিচে বিস্তারিতভাবে ব্যাখ্যা করা হলো।
ABC Garments Ltd. কোম্পানির ছুটি ব্যবস্থাপনা উদাহরণ
“ABC Garments Ltd.” কোম্পানির বিভিন্ন কর্মী, ডিপার্টমেন্ট, এবং পদবী রয়েছে। কোম্পানিটি একটি Leave Management সিস্টেম ব্যবহার করছে, যেখানে কর্মীরা বিভিন্ন ধরনের ছুটি আবেদন করতে পারেন, এবং প্রত্যেকটি আবেদন নির্দিষ্ট স্তরের অনুমোদনের মাধ্যমে প্রক্রিয়াকরণ করা হয়। এখানে প্রতিটি স্টেপ ব্যাখ্যা করা হয়েছে, যা মডিউলের প্রতিটি টেবিলের ভূমিকা ও কার্যকারিতা বুঝতে সাহায্য করবে।
স্টেপ-বাই-স্টেপ Leave Management উদাহরণ
স্টেপ ১: ছুটির ধরন তৈরি করা (Leave Types Creation)
leave_types টেবিল:
ABC Garments Ltd. এর অ্যাডমিন প্রথমে ছুটির বিভিন্ন ধরনের শ্রেণী তৈরি করেন।
- উদাহরণস্বরূপ:
- Casual Leave (CL): প্রতি বছরে ১০ দিন।
- Sick Leave (SL): প্রতি বছরে ৮ দিন।
- Annual Leave (AL): প্রতি বছরে ১৫ দিন।
| leave_type_id | company_id | leave_type_name | leave_code | max_days_per_year | carry_forward |
|---|---|---|---|---|---|
| 1 | 1 | Casual Leave | CL | 10 | No |
| 2 | 1 | Sick Leave | SL | 8 | No |
| 3 | 1 | Annual Leave | AL | 15 | Yes |
বিঃদ্রঃ
company_idনিশ্চিত করবে যে প্রতিটি leave_type নির্দিষ্ট কোম্পানির জন্য ব্যবহার করা হচ্ছে।
স্টেপ ২: ছুটির নীতিমালা নির্ধারণ (Define Leave Policies)
leave_policies টেবিল:
ABC Garments Ltd. এর HR ম্যানেজার প্রতিটি leave_type এর জন্য একটি নীতিমালা নির্ধারণ করেছেন।
- উদাহরণস্বরূপ:
- Casual Leave শুধুমাত্র
StaffএবংTechnicianপদে থাকা কর্মীদের জন্য প্রযোজ্য। - Sick Leave সব কর্মীর জন্য প্রযোজ্য।
- Annual Leave শুধুমাত্র
Managerএবং তার উপরের স্তরে প্রযোজ্য।
- Casual Leave শুধুমাত্র
| policy_id | company_id | leave_type_id | applicable_for | description | effective_date |
|---|---|---|---|---|---|
| 1 | 1 | 1 | Staff, Technician | CL পদের কর্মীদের জন্য প্রযোজ্য | 2023-01-01 |
| 2 | 1 | 2 | All Employees | SL সব কর্মীদের জন্য প্রযোজ্য | 2023-01-01 |
| 3 | 1 | 3 | Manager+ | AL ম্যানেজার এবং তার উপরের জন্য | 2023-01-01 |
বিঃদ্রঃ
leave_type_idএবংcompany_idএর মাধ্যমে প্রতিটি leave_policy নির্দিষ্ট leave_type এবং কোম্পানির সাথে সংযুক্ত থাকবে।
স্টেপ ৩: কর্মীর ছুটির আবেদন (Employee Leave Application)
employee_leaves টেবিল:
Employee ID: 101 (নাম: মোঃ আরিফ) Sick Leave (SL) এর জন্য ৩ দিনের ছুটি আবেদন করেছেন।
| leave_id | employee_id | leave_type_id | start_date | end_date | total_days | reason | status |
|---|---|---|---|---|---|---|---|
| 1 | 101 | 2 | 2023-02-10 | 2023-02-12 | 3 | Fever and cough | Pending |
বিঃদ্রঃ কর্মীর ছুটির আবেদন করার পর,
statusফিল্ডের মান Pending থাকবে, যা প্রথম স্তরের অনুমোদনকারী (যেমন, ডিপার্টমেন্ট হেড) এর অনুমোদনের অপেক্ষায় থাকবে।
স্টেপ ৪: অনুমোদন ওয়ার্কফ্লো (Approval Workflow Setup)
approval_workflow টেবিল:
ABC Garments Ltd. এর জন্য Sick Leave এর অনুমোদন ওয়ার্কফ্লোটি নিম্নরূপ:
- প্রথম স্তরে Department Head অনুমোদন দেবেন।
- দ্বিতীয় স্তরে HR Manager অনুমোদন দেবেন, যদি Department Head অনুমোদন দেন।
| workflow_id | company_id | leave_type_id | approver_level | approver_role | escalation_days |
|---|---|---|---|---|---|
| 1 | 1 | 2 | 1 | Department Head | 2 |
| 2 | 1 | 2 | 2 | HR Manager | 2 |
বিঃদ্রঃ এই টেবিলটি নিশ্চিত করবে যে প্রতিটি ছুটি সঠিকভাবে স্তরে স্তরে অনুমোদিত হচ্ছে এবং নির্দিষ্ট সময়ে অনুমোদন না হলে পরবর্তী স্তরে এস্কেলেট হবে।
স্টেপ ৫: Leave Approvals
leave_approvals টেবিল:
Department Head প্রথম স্তরে মোঃ আরিফের Sick Leave অনুমোদন করেছেন, এবং এটি এখন HR Manager এর অনুমোদনের অপেক্ষায় রয়েছে।
| approval_id | leave_id | approver_id | approval_level | approval_status | approval_date | remarks |
|---|---|---|---|---|---|---|
| 1 | 1 | 201 | 1 | Approved | 2023-02-09 | Approved by Department Head |
বিঃদ্রঃ প্রতিটি স্তরের অনুমোদন তথ্য
leave_approvalsটেবিলে সংরক্ষিত থাকবে এবং কর্মীর ছুটির আবেদন চূড়ান্ত অনুমোদন না পাওয়া পর্যন্ত এভাবে স্তরে স্তরে অনুমোদনের জন্য অপেক্ষা করবে।
স্টেপ ৬: Leave Escalations
leave_escalations টেবিল:
যদি নির্দিষ্ট সময়ে approval_workflow অনুযায়ী অনুমোদন না হয়, তাহলে সিস্টেমটি স্বয়ংক্রিয়ভাবে ছুটি আবেদনের স্তরটিকে পরবর্তী স্তরে এস্কেলেট করবে।
উদাহরণস্বরূপ: যদি Department Head নির্দিষ্ট সময়ের মধ্যে ছুটি অনুমোদন না করেন, তবে এটি স্বয়ংক্রিয়ভাবে HR Manager এর স্তরে চলে যাবে।
| escalation_id | leave_id | current_level | escalated_to_level | escalation_date |
|---|---|---|---|---|
| 1 | 1 | 1 | 2 | 2023-02-11 |
বিঃদ্রঃ
leave_escalationsটেবিল নিশ্চিত করবে যে অনুমোদন না হলে তা পরবর্তী স্তরে চলে যাচ্ছে।
স্টেপ ৭: Leave Balance Update
leave_balance টেবিল:
কর্মী আরিফের Sick Leave (SL) এর ৩ দিন ছুটি ব্যবহারের পর leave_balance আপডেট করা হবে। ধরুন, শুরুতে তার ৮ দিন Sick Leave ছিল।
| balance_id | employee_id | leave_type_id | total_allocated_days | used_days | remaining_days | last_updated |
|---|---|---|---|---|---|---|
| 1 | 101 | 2 | 8 | 3 | 5 | 2023-02-12 |
বিঃদ্রঃ
leave_balanceআপডেট করে কর্মীর অবশিষ্ট ছুটির হিসাব রাখবে।
সারসংক্ষেপ
এই উদাহরণে, “ABC Garments Ltd.” কোম্পানির Leave Management মডিউলে প্রতিটি স্তরে ছুটির ধরন, নীতিমালা, অনুমোদন এবং এস্কেলেশন যুক্ত করা হয়েছে। এতে কর্মীরা ছুটি আবেদন করতে পারেন এবং নির্দিষ্ট স্তরের অনুমোদন প্রক্রিয়ার মাধ্যমে আবেদনটি প্রক্রিয়াকৃত হয়। এই পদ্ধতি নিশ্চিত করে যে প্রতিটি ছুটির আবেদন সঠিকভাবে অনুমোদিত ও ট্র্যাক করা হচ্ছে।