Human

Resource Prepared By:

•Meti Abera ……. ……………………... UGR/9108/15
Database •Abel Tewodros………………………... UGR/0414/15
Manageme •Cherinet Kebede ……………..……... UGR/9075/15

nt System •Daniel Yohannes …… . ……………… UGR/7453/15

•Yeabsira Moges ………………………..
UGR/8254/15
• Hailemariam Kifleyohannes..........UGR/1407/15
Introduction

• This is a presentation for the human

resource database management system
that we created for Oromia Investement
and Industry Group.
Background

• Oromiya Investment Group: established

1993.
• Located in Sarbet, Ethiopia.
• Dedicated to regional economic
development.
Purpose of the System

The main propose of the system includes:

• Streamline data management processes.
• Enhance precision and accessibility.
• Address internal HR affairs effectively.
• Ensure adaptability and responsiveness.
• Foster seamless, resilient data environment.
Statement of the problem

Why is the new database needed?

- Challenges in existing data management.
- Excel files prone to corruption.
- Inefficiencies in data retrieval.
- Difficulties in data editing and access.
- Risks to data accuracy and security.
Objective of the project

1. General Objective
o Develop comprehensive HR database system
2. Specific Objectives
• Collect, design, prepare, implement, test.
• Improve HR tasks handling.
• Enhance organizational efficiency.
• Provide dynamic data management solution.
Database Development methdology

During the database development we mainly

foucuses on:
• Exsisting data like Excel files, questionnaires.
• Use standard database design methodology.
• Conceptual, logical, physical design stages.
• Focus on transparency and data-driven decisions.
• Aim for improved HR processes.
Deliverables of the project

After the database development we will provide:

• Developed HR database management system.
• Actual database, SQL scripts.
• Documentation demonstrating design phase.
• Improved data management system.
• Enhanced operational efficiency.
Project time • This is the time plan we proposed to use to
do this project
plan
Requirement Analysis

1. Data Requirement
• Employees' information storage.
• Includes names, genders, birthdates, contact
details.
• Attendance, payroll, promotion, transfer records.
• Job and department details storage.
• Employee termination and rehiring tracking.
Requirement Analysis – Transaction Requirement

1. Data Entry
• Employees' information storage.
• Includes names, genders, birthdates, contact
details.
• Attendance, payroll, promotion, transfer
records.
• Job and department details storage.
• Employee termination and rehiring tracking.
Requirement Analysis – Contd....

2. Data Retrieval
o Retrieve employee details like name, gender , DOB e.t.c
o Access academic qualifications and certification
o Obtain job details
o Access to the terminated employees e.t .c
Requirement Analysis – Contd....

3. Data Updating and Removal

oUpdate employee personal detail
oAdjust employees salary
oCorrect Data entry errors
oUpdate HR policies and procedures
oRemove outdated or irrelevant data
Conceptual Design

• Entities and Attributes

o Job: JobID, JobName, JobDescription, Salary, Rank.
o Address: AddressID, City, SubCity, Woreda, Kebele
o Employee: EmployeeID, EmpName, Gender, DOB,
DOE, Age, PhoneNo, Experience, Status, TaxPayerTinNo,
Certification
o TermiationHistory: TerminationID, TerminationDate,
TerminationReason.
o Payroll: PayrollID, Salary, MonthEndDate, OvertimePay,
TaxDeduction, PenalityDeduction, NetSalary
Conceptual Design - Contd....

• More Entities
o Attendace: Month, TotalDaysPresent, AllowedBreaks,
TotalDaysAbscent
o RehiredEmployees: RehiringID, RehiringDate, RehiringReas
on
o Department: DepartmentID, DepartmentName
o PromotionDemotion: PD_ID, Date, JobTo, Type
o TransferHistory:TransferID, Date, DepartmentTo
Conceptual Design – Contd...

• Relationship between entities

• Employees are associated with Job, Addres, Department
• Employees may have multiple TerminationHistory records.
• Employees may have multiple Payroll records
• Employees may have Attendance Records
• Employees may have Rehired Employee Records
• Departments may have many employees
• Employees may have multiple PromotionDemotion records
• Employees may have multiple TransferHistory records
Conceptual Design – Er Model

The ER Diagram
for the project.
 Logical Design
• In this stage we map the previous ER Model into a
logical Data Model and It looks like the following.
Employee (EmployeeID, EmpName, Gender, DOB, DOE, TerminatedEmployees (TerminationID,
Age, PhoneNo, Experiance, Role, YearOfExperiance, Status,
DepartmentID, JobID, AdressID, TaxPayerNo)
TerminationDate, TerminationReason,
Primary Key (EmployeeID) EmployeeID )
Alternate Key (IDCardNo) Primary Key (TerminationID)
Foreign Key (DepartmentID) Alternate Key (EmplyeeID, TerminationDate)
References Department (DepartmentID)
Foreign Key (JobID) Foreign Key (EmployeeID)
References Job (JobID) References Employee (EmployeeID)
Derived Age (GETDATE()-DOB)

Attendance (Month, totalDayPresent, PromotionDemotion ( PD_ID, EmployeeID,

allowedBreaks, totalDaysAbsent, Date, JobFrom, JobTo, Type)
EmployeeID) Primary key PD_ID
Primary Key (EmployeeID, Month) Foregin key JobFrom References Job(JobID)
Foreign Key JobTo References Job(JobID)
Foreign Key (EmployeeID) Foreign Key EmployeeID References
References Employee (EmployeeID) Employee(EmployeeID)
 Logical Design – Contd...
Job (JobID, JobName, JobDescription, Salary, Rank) Address (AddressID, City, Subcity, Woreda, Kebele, )
Primary Key (JobID) Primary Key (AddressID)

Department (DepartmentID, DepartmentName) RehiredEmployee (EmployeeID, RehiringDate,

Primary Key (DepartmentID) RehiringReason)
Primary Key (EmployeeID, RehiringDate)
Foreign Key (EmployeeID)
References Employee (EmployeeID)
Payroll (PayrollID, Salary, MonthEndDate, Transfer (TransferID, EmployeeID, Date,
OvertimePay, TaxDeduction, PenalityDeduction, DepartmentTo, DepartmentFrom)
TotalSalary) Primary Key (TransferID)
Primary Key (PayrollID) Foreign Key (DepartmetTo)
Alternate Key (EmployeeID, MonthEndDate) References Department(DepartmentID)
Foreign Key (EmployeeID) Foreign Key (DepartmentFrom)
References Employee (EmployeeID) References Department(DepartmentID)
Derived TotalSalary (Salary + OvertimePay- Foreign Key (EmployeeID)
TaxDeduction - PenalityDeduction) References Employee (EmployeeID)
Logical Design – Normalization

• Un-normalized form: created bymerging all the relations

found in the logical stages
EmployeeID, EmpName, Gender, DOB, DOE, Age, PhoneNo, Status, JobID,
JobName, JobDescription, Salary, Rank, AddressID, City, SubCity, Woreda, Kebele,
CertificationName, InstitutionName, TerminationID,
TerminationDate,TerminationReason, PayrollID, P_Month, OvertimePay,
TaxDeduction, PenalityDeduction, TotalSalary, TotalDayPresent, AllowedBreaks,
TotalDaysAbsent, Reason, RehiringDate, RehiringReason, PD_ID, PD_Date,
JobFrom, JobTo, PD_Type, TransferID, TransferDate, DepartmentFrom,
DepartmentTo, DepartmentID, DepartmentName

• By using flattening can be moved up to 1NF

Logical Design – Normalization Contd....

• Frist Normal From: is a case where each attributes has atomic

value.
EmployeeRecord ( EmployeeID, EmpName, Gender, DOB, DOE, Age, PhoneNo,
Status, JobID, JobName, JobDescription, Salary, Rank, AddressID, City, SubCity,
Woreda, Kebele, CertificationName, InstitutionName, TerminationID,
TerminationDate,TerminationReason, PayrollID, P_Month, OvertimePay,
TaxDeduction, PenalityDeduction, TotalSalary, TotalDayPresent, AllowedBreaks,
TotalDaysAbsent, Reason, RehiringDate, RehiringReason, PD_ID, PD_Date,
JobFrom, JobTo, PD_Type, TransferID, TransferDate, DepartmentFrom,
DepartmentTo, DepartmentID, DepartmentName)
Primary Key (EmployeeID, CertificationName, JobID, PayrollID, AttendanceID,
PD_ID, TransferID, TerminationID)
Logical Design – 2NF

• Second Normal Form

o At this stage all the following partial
dependencies were removed
• {JobID} à {JobName, JobDescription ,Salary, Rank} (Partial dependency)
• {TerminationID} à {TerminationDate, TerminationReason} (Partial dependency)
• {TransferID} à { DepartmentFrom ,DepartmentTo, TransferDate} (Partial dependency)
• {PayrollID} à {P_Month, OvertimePay, TaxDeduction, PenalityDeduction, TotalSalary}
(Partial dependency)
• {PD_ID} à {PD_Date, JobFrom, JobTo, PD_type} (Partial dependency)
• {AttendanceID} à {RecordingMonth, totalDaysPresent, allowedBreaks, totalDaysAbscent}
(Partial dependency)
• {EmployeeID, CertificationName} à {InstitutionName} (Partial dependency)
Logical Design - 3NF

• Third Normal From

o At this stage the following transitive
dependencies were removed
§ {EmployeeID} à {AddressID} à {City, SubCity, Woreda, Kebele}(Transitive dependency)
§ {EmployeeID} à {DepartmentID} à {DepartmentName } (Transitive dependency)
§ {EmployeeID} à {EmployeeID, RehirementDate} à {RehirementReason} (Transitive
dependency)
o Now all of the relations are in 3NF so we can
move to the physical design
 Logical Design – Relational Shema with
referential Integrity

JobID JobName JobDescription Salary Rank

TerminationID TerminationDate TerminationReason TerminatedEmployee

AttendanceID EmployeeID RecordingMonth totalDaysPresent totalAllowedBreaks totalDaysAbsent

EmployeeID CertificationName InstitutionName

PD_ID PD_Date EmployeeID JobFrom JobTo PD_Type

TransferID TransferDate DepartmentFrom DepartmentTo EmployeeID

 Logical Design – Refer.... Contd....

PayrollID EmployeeID P_Month OvertimePayment TaxDeduction Penality NetSalary

EmployeeID EName Gender DOB DOE Age PhoneNo JobID EDepID Status JobID

AddressID City SubCity Woreda Kebele

DepartmentID DepartmentName

EmployeeID RehirementDate RehirementReason

Physical Design

• DBMS Specification
o We have selected Microsoft Sql Server with SQL Server
Management Studio because it has the following fetures:
§ Comphrensive TDBMS
§ Data Integiry Enforecment
§ Constraiint support
§ Empowers Admins and developers
§ Ensures Industry Standards

• File Organization
o Due to the SQL Server that we are using the database
uses the B+ File Organization
Physical Design Contd....

• Indexes
o Used primary index for unique record
identification
o We used it to enhance query performance
• Estimated Size of the Database
o Total Estimated Size = 0.335595MB
o Growth rate = 10% per year
Database Implementation

• Database is implemented by using SQL

• Code is linked below
o Code to create the database and the base relation

o Code to create views of the database

o Test Cases with crud operation
 Database Diagram snapshot

Figure: The database diagram for HRMS

Thank You