Проектиране на база данни за система за набиране на персонал

Искате ли да научите как да проектирате система за база данни и да съпоставите бизнес процес с модел на данни? Тогава тази публикация е за вас.

В тази статия ще видите как да проектирате проста схема на база данни за компания за набиране на персонал. След като прочетете този урок, ще можете да разберете как схемите на бази данни са проектирани за приложения в реалния свят.

Бизнес процесът на системата за набиране на персонал

Преди да проектирате каквато и да е база данни или модел на данни, е наложително да разберете основния бизнес процес за тази система. Схемата на базата данни, която ще създадем, е за въображаема компания или екип за набиране на персонал. Нека първо да видим стъпките, свързани с наемането на нови служители:

Компаниите се свързват с агенции за набиране на персонал, за да наемат работа от тяхно име. В някои случаи компаниите набират служители директно.
Лицето, отговорно за набирането, започва процеса на набиране. Този процес може да има няколко стъпки, като първоначален скрининг, писмен тест, първо интервю, последващо интервю, действително решение за наемане и т.н.
След като наемателите се споразумеят за конкретен процес – и това може да се промени в зависимост от клиента, компанията или въпросната работа – свободното място се обявява на различни платформи.
Кандидатите започват да кандидатстват за работа.
Кандидатите са включени в списъка и са поканени на тест или първоначално интервю.
Кандидатите се явяват на теста/интервюто.
Тестовете се оценяват от наемателите. В някои случаи тестовете се изпращат на специалисти за оценяване.
Интервютата на кандидатите се оценяват от един или повече наематели.
Кандидатите се оценяват въз основа на тестове и интервюта.
Решението за наемане е взето.

Схема за база данни на системата за набиране на персонал

С оглед на гореспоменатия процес, нашата схема на база данни е разделена на пет тематични области:

Process
Jobs
Application, Applicant, and Documents
Test and Interviews
Recruiters and Application Evaluation

Ще разгледаме подробно всяка от тези области, в реда, в който са изброени. По-долу можете да видите целия модел на данни.

Процес

Категорията процес съдържа информация, свързана с процесите на набиране на персонал. Той съдържа три таблици:process , step и process_step . Ще разгледаме всеки един.

process таблицата съхранява информация за всеки процес на набиране на персонал. Всеки процес ще има специален идентификатор, код и description на този процес. Ще имаме и recruiter_id на лицето, което инициира процеса.

step таблицата съдържа информация за стъпките, следвани по време на този процес на набиране. Всяка стъпка има id и code име. Колоната с име може да има стойности като „първоначална проверка“, „писмен тест“, „Човешко интервю“ и т.н.

Тъй като един процес може да има няколко стъпки и една стъпка може да бъде част от много процеси, имаме нужда от справочна таблица. process_step таблицата съдържа информация за всяка стъпка (в step_id ) и процеса, към който принадлежи (в process_id ). Ние също имаме статус, който ни казва състоянието на тази стъпка в този процес; това може да бъде NULL, ако стъпката все още не е стартирана. И накрая, имаме priority , което ни казва в кой ред да изпълним стъпките. Стъпките с най-висок priority стойност ще се изпълни първо.

Работни места

След това имаме Jobs тематична област, която съхранява цялата информация, свързана с работата(ите), за която набираме. Схемата за тази категория изглежда така:

Нека обясним подробно всяка една от таблиците.

job_category таблицата описва най-общо вида работа. Можем да очакваме да видим категории работни места като „ИТ“, „мениджмънт“, „финанси“, „образование“ и т.н.

job_position таблицата съдържа действителното заглавие на длъжността. Тъй като едно заглавие може да бъде рекламирано за множество работни места (например „ИТ мениджър“, „Мениджър продажби“), създадохме отделна таблица за работни позиции. Можем да очакваме да видим стойности като „Ръководител на ИТ екип“, „Вицепрезидент“ и „Мениджър“ в тази таблица.

job_platform таблицата се отнася до носителя, използван за рекламиране на свободните работни места. Например, работа може да бъде публикувана във Facebook, онлайн табло за работа или в местен вестник. В description може да се добави връзка към тази обява за работа поле.

organization таблицата съхранява информация за всички компании, които някога са използвали тази база данни като част от процеса на наемане. Очевидно тази таблица е важна, когато се извършва набиране на персонал за друга компания.

Последната таблица в тази тематична област, job , съдържа действителната длъжностна характеристика. Повечето от атрибутите се обясняват сами. Трябва да отбележим, че тази таблица има много външни ключове, което означава, че може да се използва за търсене на категорията, позицията, платформата, организацията за наемане и процеса на набиране на персонал, свързан с това свободно място.

Заявление, кандидат и документи

Третата част на схемата се състои от таблиците, които съхраняват информация за кандидатите за работа, техните кандидатури и всички документи, които идват с заявленията.

Първата маса, applicant , съхранява лична информация на кандидатите, като тяхното име, фамилия, имейл, телефонен номер и др. Полето за обобщение може да се използва за съхраняване на кратък профил на кандидата (т.е. параграф).

Следващата таблица съдържа информация за всяко application , включително неговата дата. Таблицата съдържа също experience и education колони. Тези колони може да са част от applicant таблица, но кандидатът може или не може да иска да покаже определена образователна квалификация или професионален опит във всяко заявление, което подава. Следователно тези колони са част от application маса. other_info колоната съхранява всякаква друга информация, свързана с приложението. В application таблица, jobs_id и applicant_id са външни ключове съответно от таблиците на заданието и кандидата.

Тъй като може да има множество приложения за всяка работа, но всяко приложение е само за една работа, ще има връзка един към много между jobs и applications маси. По същия начин един кандидат може да подаде множество заявления (т.е. за различни работни места), но всяко заявление е само от един участник; внедрихме друга връзка един към много между applicants и applications таблици за справяне с това.

document table управлява подкрепящите документи, които кандидатите могат да приложат към заявлението си. Това могат да бъдат автобиографии, автобиографии, референтни писма, мотивационни писма и т.н. Имайте предвид, че тази таблица има двоична колона с име документ, която ще съхранява файла в двоичен формат. Връзка към документа може да се съхранява в url поле; колоната за име съхранява името на документа и last_update означава най-новата версия, качена от заявителя. Имайте предвид, че и двата document и url са нулеви; нито едното не е задължително и кандидатът може да избере да използва единия или двата метода, за да добави информация към своето заявление.

Не всяко заявление ще има прикачен документ. Един документ може да бъде прикачен към множество приложения, а едно заявление може да има множество подкрепящи документи. Това означава, че има връзка много към много между application и document маси. За да управлявате тази връзка, справочната таблица application_document е създаден.

Тестове и интервюта

Сега ще преминем към таблиците, които съхраняват информация за тестовете и интервютата, свързани с процеса на набиране на персонал.

test таблицата съхранява подробности за теста, включително нейния уникален id , code име, неговата duration в минути и maximum възможен резултат за този тест.

Едно приложение може да бъде свързано с множество тестове, а един тест може да бъде свързан с множество приложения. Още веднъж имаме справочна таблица, за да приложим тази връзка:application_test . start_time и end_time колоните са нулеви, тъй като тестът може да няма конкретна продължителност, начален или краен час.

Един тест може да бъде оценен от множество специалисти по набиране на персонал и един наемател може да оцени множество тестове. answers таблицата е таблицата, която прави това възможно. total_grades колоната записва колко добре се е справил кандидатът на теста, а колоната за успешно показва просто дали този човек е издържал или не е успял. Спецификите на всеки отделен тест се записват в answer_details колона. Имайте предвид, че тези три колони са нулеви; тест за кандидатстване може да бъде назначен на наемател, който все още не го е оценил. Освен това на наемателя може да бъде назначен тест, преди да бъде положен.

interview таблицата съхранява основна информация (start_time , end_time , уникален id и съответния application_id ) за всяко интервю. Едно интервю може да бъде свързано само с едно заявление. От друга страна, едно приложение може да има няколко интервюта. Следователно съществува връзка един към много между таблицата за кандидатстване и интервюто.

Едно интервю може да се проведе от множество рецензенти, а един рецензент може да вземе няколко интервюта. Това е друга връзка много към много, така че създадохме таблицата за справка interview_note . Той съхранява информация за интервюто (в interview_id ), наемателят (в recruiter_id ) и бележките на наемателя за интервюто. Наемателите могат също да записват дали кандидатът е преминал интервюто или не в колоната за преминаване, която е нулева.

Оценка и статус на кандидатстване за набиратели

Последната част от нашия модел за набиране на персонал съхранява информация за наемателите, статусите на кандидатурата и оценките на кандидатурата.

recruiters таблицата съхранява first_name на всеки наемател , last_name и уникален id номер.

application_evaluation таблицата съдържа информация за оценките на приложенията. В допълнение към application_id и recruiter_id , съдържа обратната връзка на наемателя (в notes ) и окончателното решение за наемане, ако има такова, в hired . Едно приложение може да бъде оценено от множество наематели, а един наемател може да оценява множество приложения, така че и recruiter и application таблицата има връзка едно към много с application_evaluation маса.

Приложението може да премине през няколко етапа по време на процеса на наемане, напр. „не е изпратено“, „в процес на преглед“, „чака се решение“, „взето решение“ и т.н. Заявлението ще има статус „not_submitted“, когато потребителят е стартирал заявление, но не го е подал за преглед от наемателите. След като заявлението бъде подадено, статусът се променя на „в процес на преглед“ и т.н. application_status таблицата се използва за съхраняване на такава информация.

application_status_change таблицата се използва за поддържане на запис на промените в статуса за всички подадени заявления. date_changed колона съхранява датата на промяна на състоянието. Тази таблица може да бъде удобна, ако искате да анализирате времето за обработка за всеки етап от различни приложения. Освен това, състоянието на всяка конкретна колона може да бъде извлечено с помощта на application_id колона от application_status_change маса.

Прост случай за набиране на персонал

Нека видим как нашата база данни може да помогне на процеса на набиране на персонал.

Да предположим, че една компания ви е възложила да наемете ИТ мениджър с опит в програмирането. Нашата база данни може да ни помогне да наемем такъв човек, като изпълним следните стъпки:

Първата стъпка е да започнете нов процес на наемане. За целта данните се въвеждат в process и steps маси. Наемателят може да добави толкова стъпки, колкото са му необходими.
По време на горната задача наемателят може да създаде нова работа и да въведе подробностите в job , job_category , job_position , и organization маси. И накрая, обява за работа ще бъде поставена в една от платформите, съхранявани в job_platform маса.
След това кандидатите ще създадат профил, като изпратят своите данни на applicant маса. След това те ще стартират ново приложение, като въведат повече данни в application маса.
Кандидатите могат също да прикачат документи към заявленията си. Тези данни ще се съхраняват в document и application_document таблици.
Ако потребител иска да кандидатства за повече от една работа, той ще повтори стъпки 3 и 4.
След като заявлението бъде изпратено, статусът на заявлението ще бъде зададен на „подадено“ (или друго име на статус, избрано от наемателя).
Наемателят ще оцени приложението и ще въведе отзивите си в application_evaluation маса. На този етап наетата колона няма да съдържа информация.
След като бъдат получени адекватен брой кандидатури, наемателят ще изпълни следващата стъпка, показана в process_step маса.
Ако следващата стъпка е администриране на някакъв вид тест, наемателят ще създаде тест, като добави данни в test маса.
Тестовете, създадени в стъпка 9, ще бъдат присвоени на конкретно приложение. Информацията, която присвоява всеки тест на всяко приложение, ще се съхранява в application_test маса. Имайте предвид, че по време на всеки етап състоянието на приложението ще продължи да се променя. Това ще бъде записано в application_status_change маса.
След като кандидатът завърши теста, оценките за всеки тест за кандидатстване ще бъдат маркирани от наемателя и ще бъдат въведени в answer маса.
След като тестът бъде направен, следващата стъпка от process_step таблицата ще бъде изпълнена. Да кажем, че следващата стъпка е интервюто.
Данните за интервюто ще бъдат въведени в interview маса. Наемателят ще въведе техните коментари и ще каже дали лицето е преминало интервюто или не. Това ще бъде съхранено в interview_note маса.
Ако process таблицата съдържа допълнителни стъпки за интервю и тест, те ще се изпълняват до достигане на последната стъпка.
Последната стъпка в process_step таблицата обикновено е решението за наемане. Ако кандидатът премине своите тестове и интервюта и компанията реши да го наеме, данните се въвеждат в колоната за наемане на application_evaluation маса и лицето е наето.

Какво мислите за нашия модел на данни от системата за набиране на персонал?

В тази статия видяхме как да създадем много проста схема на база данни за система за набиране на персонал. Разделихме схемата на четири категории и след това обяснихме всяка от тях подробно. И накрая, изпълнихме случай на употреба, за да покажем, че нашата схема всъщност може да помогне за наемане на служител.

Работата по проектиране на бази данни процъфтява. Искате ли да добавите към вашата база данни умения? Независимо дали сте новодошъл, който иска да научи основите на SQL, или опитен професионалист, който иска да се разклони в Създаване на таблици в SQL | Интерактивен курс | Vertabelo Academy" target="_blank">Дизайн на база данни, вижте курсовете на LearnSQL.com за самостоятелен ход.