Database
 sql >> база данни >  >> RDS >> Database

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

По целия свят сайтът на портала за работа е добре позната характеристика на интернет пейзажа. Големи играчи като Indeed и Monster превърнаха търсенето на работа и набирането на работа в истинска онлайн индустрия. Нека се потопим в елементарните функции, използвани от порталите за работа, и да изградим модел на данни, който може да ги поддържа.

Хората обичат да спестяват време, като използват технологични иновации; онлайн порталът за работа е друга версия на работа по-интелигентна, а не по-трудна. Търсещите работа и компаниите осъзнават стойността на търсенето си онлайн:те получават по-добър обхват при по-висока скорост и по-ниски разходи.

Индустрията на порталите за работа е доста стабилизирана сега, поне по отношение на обемите на трафика. Търсещите работа използват тези портали, за да намерят позиции в много индустрии, преминавайки отвъд ИТ към сектори като инженеринг, продажби, производство и финансови услуги. Въпреки това, те стават тежка конкуренция от социалните медии и професионални мрежови сайтове като LinkedIn. Но все още има възможности за проучване, като например разширяване на проникването им в селските райони и по-малките градове.

Така че, както казахме, ще проучим тази тема от гледна точка на дизайна на база данни. Нека започнем с изброяване на основните очаквания за портал за работа.

Какво очакват хората от онлайн портал за работа?

И работодателите, и търсещите работа очакват следните функционалности от онлайн сайт за работа:

  • Хората могат да се регистрират като търсещи работа, да създават профили и да търсят работни места, съответстващи на техните умения.
  • Потребителите могат да качват съществуващите си автобиографии. Ако нямат такъв, те трябва да могат да попълнят формуляр и да създадат автобиография за тях.
  • Хората могат да кандидатстват директно за публикувани работни места.
  • Компаниите могат да се регистрират, да публикуват работни места и да търсят профили на търсещи работа.
  • Множество представители от една компания трябва да могат да се регистрират и публикуват работни места.
  • Представителите на компанията могат да видят списък с кандидати за работа и да се свържат с тях, да инициират интервю или да извършат някакво друго действие, свързано с тяхната позиция.
  • Регистрираните потребители трябва да могат да търсят работни места и да филтрират резултатите въз основа на местоположение, необходими умения, заплата, ниво на опит и т.н.

Изграждане на модела на данните

След като разгледах горните изисквания, измислих три широки функционални категории:

  1. Управление на потребители – Как порталът управлява потребители, т.е. търсещи работа, HR персонал и независими или консултантски служители. (За целите на този модел отделните представители на човешките ресурси и независимите или консултантски служители се третират като компании, поне по отношение на начина, по който използват портала.)
  2. Създаване на профили – Как порталът позволява на търсещите работа и организациите да създават профили и автобиографии.
  3. Публикуване и търсене на работни места – Как порталът улеснява процеса на публикуване, търсене и кандидатстване за работа.



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

1. Управление на потребители

Има предимно два типа потребители на онлайн портала за работа:индивидуални търсещи работа и хора, набиращи персонал (или независими консултанти по набиране на персонал). Нека създадем таблица с име user_type за съхраняване на тези записи. Като начало ще има два записа – един за търсещи работа и друг за наематели. (Винаги можем да създадем допълнителни типове записи, ако е необходимо.)

Потребителите трябва да се регистрират, преди да могат да използват портала. user_account таблицата съхранява техните основни данни за акаунта. По-рано обмислях да назова тази таблица „user“, но тъй като user е системно дефинирана ключова дума в почти всички бази данни, предпочитам да се придържам към „user_account“.

user_account таблицата има следните колони:

  • идентификатор – Това е както първичен ключ на таблицата, така и уникален идентификатор за всеки потребител. Този идентификатор ще бъде посочен от други таблици в модела на данни.
  • user_type_id – Това означава дали потребителят е търсещ работа или наемател.
  • имейл – Тази колона съдържа имейл адреса на потребителя. Той действа като друг потребителски идентификатор за портала.
  • парола – Това съхранява криптирана парола за акаунт (създадена от потребители по време на регистрация).
  • дата_на_раждане и пол – Както подсказват имената им, тези колони съдържат датата на раждане и пола на потребителите.
  • е_активен – Първоначално тази колона ще бъде „Y“, но потребителите могат да зададат своя профил на неактивен или „N“. Тази колона съхранява техния избор.
  • номер за_контакт – Това е телефонният номер (обикновено мобилен), предоставен по време на регистрацията. Потребителите могат да получават SMS (текстови) известия на този номер. Може да бъде същият номер (или не) като единия търсещ работа, изброен в своя профил или автобиография.
  • sms_notification_active и email_notification_active – Тези колони съхраняват предпочитанията на потребителите относно получаването на известия чрез текст и/или имейл.
  • потребителско_изображение – Това е атрибут от тип BLOB, който съхранява изображението на потребителския профил на всеки потребител. Тъй като този портал позволява само едно изображение на потребителски профил, има смисъл да го съхранявате тук.
  • дата_на_регистрация – Тази колона съхранява запис кога потребителят се е регистрирал в портала.

Ще създадем още една таблица, user_log , който съхранява запис на последното влизане на потребителите и датата на последното им кандидатстване за работа. Има много функции, които могат да бъдат изградени от това знание. Например, можем да използваме тази информация, за да отговорим на въпроса Потребител X активно ли търси работа ? Ако е така, може да им бъде предложен продукт за създаване на ефективна автобиография. Потребители, които не търсят активно работа, няма да получат такава оферта.

2. Изграждане на профили

Можем допълнително да разделим този раздел на две области:профили на фирма или организация и профили на търсещи работа.

Профили на компанията

Обикновено HR екипите изграждат фирмени профили, като въвеждат подробности за тяхната организация и изображения на своите офиси, сгради и т.н. Основната им цел е да привлекат добри таланти. Когато набиращите персонал се регистрират в портала, те също могат да изграждат профили на своите компании (или на личната си марка, ако са независими), като предоставят някои основни подробности като колко време са в бизнеса, тяхното местоположение и основния си бизнес поток ( например производство, ИТ услуги, финансови и т.н.).

Порталът позволява на HR и консултантите да качват толкова изображения, колкото им харесва (за разлика от търсещите работа, които могат да качат само едно). Затова създадохме company_image таблица за съхраняване на множество изображения за всеки акаунт на наемател. company_id колоната в тази таблица е външен ключ, който се отнася до уникалния идентификатор, използван в company таблица.

В company таблица, имаме следните колони:

  • идентификатор – Първичният ключ на тази таблица се използва и за уникално идентифициране на компании.
  • име_на_компания – Както подсказва името на колоната, това съдържа юридическото име на компания.
  • описание_профила – Това съдържа кратко описание на всяка компания.
  • business_stream_id – Тази колона изобразява към кой бизнес поток принадлежи дадена компания. Например, компания за проучване на нефт и газ може да наеме ИТ инженери, но основният им бизнес поток остава „Нефт и газ“.
  • дата_на_установяване – Тази колона ви казва на колко години е една компания.
  • URL_адрес на_фирмения_сайт – Това е задължителна колона (без нула). Той съдържа указател към официалния уебсайт на компанията, така че търсещите работа да могат да научат повече информация.

И накрая, business_stream таблицата има само два атрибута, идентификатор, който е основният ключ за тази таблица, и описание на основния бизнес поток на компанията (business_stream_name ).

Профили на търсещите работа

Това е най-критичният раздел на портала за работа. Освен ако порталът не улови възможно най-много подробности от търсещите работа, е трудно за наемателите да изберат профилите или кандидатите.

seeker_profile таблицата съдържа допълнителни подробности, които не са били заснети по време на процеса на регистрация. Той съдържа следните полета:

  • user_account_id – Тази колона се препраща от user_account таблица и действа като първичен ключ за тази таблица. Това гарантира, че ще има максимум един профил на търсещ работа.
  • собствено_име и фамилно_име – Както подсказват имената, тези колони съдържат името и фамилията на търсещия работа.
  • текуща_заплата – Този атрибут съдържа текущата заплата на търсещия работа. Той е нулев, защото хората може да не искат да го разкриват.
  • е_годишно_месечно – Това определя дали размерът на заплатата им е на година или на месец.
  • валута – Това съхранява валутата на заплатата.

education_detail таблицата съхранява образователната история на всеки търсещ работа, както е предоставено от тях. Той има съставен първичен ключ, съставен от user_account_id , име_на_степен на_сертификат и майор колони. Това гарантира, че потребителите въвеждат само един запис за всяка степен или сертификат. Таблицата съдържа следните атрибути:

  • user_account_id – Тази колона се препраща от user_account таблица и служи като първичен ключ за тази таблица.
  • име_на_степен на_сертификат – Това е типът сертификат или степен; напр. гимназия, висше средно образование, дипломирано, следдипломно или професионално свидетелство.
  • майор – Тази колона съдържа основния курс на обучение за сертификат или степен – напр. бакалавърска степен със специалност компютърни науки.
  • име_на_университет – Това е институтът, училището или университетът, който е присъдил степента или сертификата.
  • начална_дата – Този атрибут съхранява датата, на която потребителят е бил приет в образователна програма.
  • дата_на_завършване – Това е датата, на която е присъдена степента или сертификатът. Този атрибут обаче е нулев; хората може да все още завършват програмата си, докато си търсят работа, или може да са отпаднали изцяло от програмата.
  • процент и cgpa – Тези колони съхраняват процента на оценка или CGPA (кумулативна средна оценка), постигнат от потребителите в тяхната степен или курс за сертификат.

experience_detail таблицата съхранява записи за миналия и текущия професионален опит на потребителите. Той съдържа следните важни колони:

  • user_account_id – Тази колона се препраща от user_account таблица и е първичният ключ за тази таблица.
  • текуща_работа – Това е индикаторна колона, която обозначава текущата работа на потребителя. Тази колона също играе важна роля при извличането на текущите местоположения на потребителите и колко дълго са заели текущата си позиция.
  • начална_дата – Това се съхранява, когато потребителят започне работа.
  • крайна_дата – Това се съхранява, когато потребителят приключи задание.
  • job_title – Съдържа информация за длъжностната роля на потребителя.
  • име_на_компания – Този атрибут съдържа съответното име на фирма, свързано с дадена работа.
  • место_на_работа – Това означава града, в който се намира работата.
  • състояние_место_на_работа – Това означава държавата, в която се е намирала работата.
  • местоположение_държава – Това означава държавата, в която се е намирала работата.
  • описание – Тази колона съхранява подробности за работните роли и отговорности, предизвикателства и постижения.

Търсещите работа могат да притежават множество умения. За да съхраняваме записи за всички тези набори от умения, ще създадем таблицата seeker_skill_set . Колоните са:

  • user_account_id – Тази колона се препраща от user_account таблица и е първичният ключ за тази таблица.
  • идентификатор_на_набор на умения – Този идентификатор означава кой набор от умения притежава потребителят.
  • ниво_на_умение – Този цифров атрибут определя количествено опита на търсещите работа в определено умение. Число от 1 (начинаещ) до 10 (експерт) показва нивото им на опит.

И накрая, skill_set таблицата съдържа описания на всички умения, посочени в skill_set_id на горната таблица атрибут. Той съдържа само две колони, име_на_набор на умения и свързания с него идентификатор .

3. Публикуване и търсене на работни места

Това е основният USP (Unique Selling Point) на портала за работа. Само регистрирани наематели могат да публикуват работа в портала и само регистрирани търсещи работа имат право да кандидатстват за тях.

job_post таблицата е основната таблица в тази предметна област. Както може би се досещате, той съдържа подробности за обявите за работа. Всички останали таблици в този раздел са създадени около него и са свързани с него.

  • идентификатор – Това е първичният ключ на тази таблица. На всяка длъжност се присвоява уникален номер и този номер се споменава в други таблици.
  • публикувано_от_идентификатор – Тази колона съдържа register_user_id на наемателя, който е публикувал работата.
  • идентификатор на_тип_работа – Тази колона показва дали продължителността на работата е постоянна или временна (договор).
  • company_id – Тази колона съхранява идентификационния номер на компанията, свързана с длъжността. Това е препратка към company маса.
  • име_на_компанията_скрито е – Това е колона с флаг, която показва дали името на компанията трябва да се показва на търсещите работа. Наемателите може да предпочетат да не показват имената на фирмите в публикацията си. Вместо това те използват термини като „глобална автомобилна компания“, „базирана в Калифорния IT компания“ и т.н.
  • дата_на_създаване – Това съхранява датата, на която е публикувана заданието.
  • описание на длъжността – Това съдържа кратко описание на работата.
  • id_job_location_id – Това се отнася до атрибут в job_location таблица, която съхранява действителното местоположение на заданието:адрес, град, щат, държава и пощенски код.
  • е_активен – Това означава дали дадена работа все още е отворена. Работодателите могат да маркират своите постове като неактивни веднага щом позициите бъдат заети.

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

И последната таблица в този раздел, job_post_activity таблица, съдържа подробности за това кои търсещи работа кандидатстват за работа и кога.

Какво бихте добавили към този модел на данни на онлайн портала за работа?

Днешните онлайн портали за работа правят повече от това да предоставят платформа за публикуване и кандидатстване за работа. Те често включват други професионални услуги като:

  • Лично табло за проследяване на заявленията за работа
  • Актуализации в реално време за приложения
  • Съставители на видеобиография
  • Експертни услуги за писане на автобиография
  • LinkedIn или други създатели на профили в социалните медии
  • Отчети за заплатите по длъжности, компании, индустрии или географски местоположения

Ако искаме да вградим тези функции в нашата система, какви допълнителни промени ще трябва да направим? Сещате ли се за други задължителни неща в портала за работа?

Моля, уведомете ни вашите мнения в секцията за коментари.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Как да създадете таблица с множество чужди ключове и да не се объркате

  2. Филтрирани индекси и принудителна параметризация (редукс)

  3. Как да поръчате по дата в T-SQL

  4. Всичко, което трябва да знаете за стандартите за кодиране на SQL заявки

  5. Как да гарантираме, че базите данни се архивират редовно