sql >> Database >  >> RDS >> Database

Een database ontwerpen voor een wervingssysteem

Wil je leren hoe je een databasesysteem ontwerpt en een bedrijfsproces in kaart brengt naar een datamodel? Dan is dit bericht iets voor jou.

In dit artikel ziet u hoe u een eenvoudig databaseschema voor een wervingsbureau kunt ontwerpen. Na het lezen van deze zelfstudie zult u begrijpen hoe databaseschema's zijn ontworpen voor toepassingen in de echte wereld.

Het bedrijfsproces van het wervingssysteem

Voordat u een database of gegevensmodel ontwerpt, is het noodzakelijk om het basisbedrijfsproces voor dat systeem te begrijpen. Het databaseschema dat we zullen maken, is voor een denkbeeldig wervingsbureau of -team. Laten we eerst eens kijken naar de stappen bij het aannemen van nieuwe medewerkers:

  1. Bedrijven nemen contact op met wervingsbureaus om namens hen mensen in te huren. In sommige gevallen werven bedrijven werknemers rechtstreeks.
  2. De persoon die verantwoordelijk is voor werving start het wervingsproces. Dit proces kan uit meerdere stappen bestaan, zoals de eerste screening, een schriftelijke test, het eerste gesprek, het vervolggesprek, de daadwerkelijke aanwervingsbeslissing, enz.
  3. Zodra de recruiters overeenstemming hebben bereikt over een bepaald proces - en dit kan veranderen afhankelijk van de klant, het bedrijf of de baan in kwestie - wordt de vacature op verschillende platforms geadverteerd.
  4. Sollicitanten beginnen te solliciteren.
  5. De kandidaten worden op de shortlist geplaatst en uitgenodigd voor een test of een eerste gesprek.
  6. De kandidaten verschijnen voor de test/het interview.
  7. De tests worden beoordeeld door de recruiters. In sommige gevallen worden tests doorgestuurd naar specialisten voor beoordeling.
  8. Interviews met sollicitanten worden beoordeeld door een of meer recruiters.
  9. Aanvragers worden beoordeeld op basis van tests en interviews.
  10. De aanwervingsbeslissing is genomen.

Een databaseschema voor het wervingssysteem

Met het oog op het bovengenoemde proces is ons databaseschema onderverdeeld in vijf onderwerpen:

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

We zullen elk van deze gebieden in detail bekijken, in de volgorde waarin ze worden vermeld. Hieronder ziet u het volledige datamodel.




Proces

De procescategorie bevat informatie met betrekking tot de wervingsprocessen. Het bevat drie tabellen:process , step , en process_step . We zullen ze allemaal bekijken.

Het process tabel slaat informatie op over elk wervingsproces. Elk proces heeft een speciale id, een code en een description van dat proces. We hebben ook de recruiter_id van de persoon die het proces initieert.

De step tabel bevat informatie over de stappen die tijdens dat wervingsproces zijn gevolgd. Elke stap heeft een id en een code naam. De naamkolom kan waarden hebben zoals "initiële screening", "schriftelijke test", "HR-interview", enz.

Aangezien één proces meerdere stappen kan hebben en één stap deel kan uitmaken van vele processen, hebben we een opzoektabel nodig. De process_step tabel bevat informatie over elke stap (in step_id ) en het proces waartoe het behoort (in process_id ). We hebben ook een status, die ons de status van die stap in dat proces vertelt; dit kan NULL zijn als de stap nog niet is gestart. Ten slotte hebben we een priority , die ons vertelt in welke volgorde de stappen moeten worden uitgevoerd. De stappen met de hoogste priority waarde wordt eerst uitgevoerd.

Vacatures

Vervolgens hebben we de Jobs onderwerpgebied, waarin alle informatie is opgeslagen met betrekking tot de functie(s) waarvoor we rekruteren. Het schema voor deze categorie ziet er als volgt uit:

Laten we elk van de tabellen in detail uitleggen.

De job_category tabel beschrijft in grote lijnen het soort baan. We zouden functiecategorieën kunnen verwachten zoals "IT", "management", "financiën", "onderwijs", enz.

De job_position tabel bevat de werkelijke functietitel. Aangezien één titel voor meerdere vacatures kan worden geadverteerd (bijvoorbeeld "IT-manager", "Verkoopmanager"), hebben we een aparte tabel voor vacatures gemaakt. We zouden waarden als 'IT-teamleider', 'vice-president' en 'manager' in deze tabel kunnen verwachten.

Het job_platform tabel verwijst naar het medium dat wordt gebruikt om de vacature te adverteren. Een vacature kan bijvoorbeeld op Facebook, een online vacaturesite of in een lokale krant worden geplaatst. Een link naar die vacature kan worden toegevoegd in de description veld.

De organization table slaat informatie op over alle bedrijven die deze database ooit hebben gebruikt als onderdeel van hun wervingsproces. Uiteraard is deze tabel belangrijk wanneer er gerekruteerd wordt voor een ander bedrijf.

De laatste tabel in dit onderwerpgebied, job , bevat de eigenlijke functiebeschrijving. De meeste attributen spreken voor zich. We moeten er rekening mee houden dat deze tabel veel externe sleutels heeft, wat betekent dat deze kan worden gebruikt om de categorie, positie, platform, de wervingsorganisatie en het wervingsproces met betrekking tot die vacature op te zoeken.

Aanvraag, aanvrager en documenten

Het derde deel van het schema bestaat uit de tabellen met informatie over sollicitanten, hun sollicitaties en alle documenten die bij de sollicitaties worden geleverd.

De eerste tabel, applicant , slaat de persoonlijke informatie van sollicitanten op, zoals hun voornaam, achternaam, e-mail, telefoonnummer, enz. Het samenvattingsveld kan worden gebruikt om een ​​kort profiel van de sollicitant op te slaan (d.w.z. een alinea).

De volgende tabel bevat informatie voor elke application , inclusief de datum. De tabel bevat ook de experience en education kolommen. Deze kolommen kunnen deel uitmaken van de applicant tabel, maar een sollicitant kan al dan niet een bepaalde onderwijskwalificatie of werkervaring vermelden bij elke sollicitatie die hij indient. Daarom maken deze kolommen deel uit van de application tafel. De other_info kolom slaat alle andere toepassingsgerelateerde informatie op. In de application tabel, de jobs_id en sollicitant_id zijn refererende sleutels uit respectievelijk de job- en sollicitantentabellen.

Aangezien er voor elke vacature meerdere sollicitaties kunnen zijn, maar elke sollicitatie slechts voor één vacature is, is er een één-op-veel-relatie tussen de jobs en applications tafels. Evenzo kan één sollicitant meerdere sollicitaties indienen (d.w.z. voor verschillende banen), maar elke sollicitatie is afkomstig van slechts één deelnemer; we hebben nog een een-op-veel-relatie geïmplementeerd tussen de applicants en applications tabellen om dit aan te pakken.

Het document table beheert de bewijsstukken die aanvragers bij hun aanvraag kunnen voegen. Dit kunnen cv's, cv's, referentiebrieven, begeleidende brieven, enz. zijn. Merk op dat deze tabel een binaire kolom heeft met de naam document, waarin het bestand in binair formaat wordt opgeslagen. Een link naar het document kan worden opgeslagen in de url veld; de naamkolom slaat de naam van het document op, en last_update betekent de meest recente versie die door de aanvrager is geüpload. Merk op dat zowel document en url zijn nullable; geen van beide is verplicht, en een aanvrager kan ervoor kiezen om een ​​of beide methoden te gebruiken om informatie aan zijn aanvraag toe te voegen.

Niet elke aanvraag heeft een bijgevoegd document. Eén document kan aan meerdere aanvragen worden toegevoegd en één aanvraag kan meerdere ondersteunende documenten hebben. Dit betekent dat er een veel-op-veel-relatie is tussen de application en document tafels. Om deze relatie te beheren, gebruikt de opzoektabel application_document is gemaakt.

Tests en interviews

Nu gaan we verder met de tabellen met informatie over de tests en interviews met betrekking tot het wervingsproces.

De test tabel slaat testdetails op, inclusief de unieke id , code naam, de duration in minuten, en het maximum score mogelijk voor die test.

Eén applicatie kan aan meerdere tests worden gekoppeld en één test kan aan meerdere applicaties worden gekoppeld. Nogmaals, we hebben een opzoektabel om deze relatie te implementeren:application_test . De start_time en end_time kolommen zijn nullable, omdat een test mogelijk geen specifieke duur, starttijd of eindtijd heeft.

Een test kan door meerdere recruiters worden beoordeeld en één recruiter kan meerdere tests beoordelen. De answers tafel is de tafel die dit mogelijk maakt. De total_grades kolom registreert hoe goed de kandidaat het op de test heeft gedaan, en de kolom geslaagd geeft eenvoudig aan of die persoon geslaagd of gezakt is. De bijzonderheden van elke individuele test worden vastgelegd in de answer_details kolom. Merk op dat deze drie kolommen nullable zijn; een sollicitatietest kan worden toegewezen aan een recruiter die deze nog niet heeft beoordeeld. Bovendien kan een recruiter een test worden toegewezen voordat deze daadwerkelijk wordt afgelegd.

Het interview tabel slaat basisinformatie op (de start_time , end_time , een unieke id , en de relevante application_id ) voor elk gesprek. Eén sollicitatiegesprek kan aan slechts één aanvraag worden gekoppeld. Aan de andere kant kan een aanvraag meerdere interviews hebben. Daarom bestaat er een één-op-veel-relatie tussen de aanvraag- en interviewtabel.

Eén interview kan door meerdere reviewers worden afgenomen en één reviewer kan meerdere interviews afnemen. Het is weer een veel-op-veel-relatie, dus hebben we de opzoektabel interview_note . Het slaat informatie over het interview op (in interview_id ), de recruiter (in recruiter_id ), en de aantekeningen van de recruiter over het interview. Recruiters kunnen ook opnemen of de sollicitant het sollicitatiegesprek heeft doorstaan ​​of niet in de pass-kolom, die nullable is.

Evaluatie en status van sollicitaties

Het laatste deel van ons wervingsmodel slaat informatie op over recruiters, sollicitatiestatussen en sollicitatie-evaluaties.

De recruiters tabel slaat de first_name van elke recruiter op , last_name , en unieke id nummer.

De application_evaluation tabel bevat informatie over toepassingsevaluaties. Naast de application_id en recruiter_id , het bevat feedback van de recruiter (in notes ) en de uiteindelijke aanwervingsbeslissing, indien van toepassing, in hired . Eén sollicitatie kan door meerdere recruiters worden beoordeeld en één recruiter kan meerdere sollicitaties beoordelen, dus zowel de recruiter en de application tabel hebben een een-op-veel-relatie met de application_evaluation tafel.

Een sollicitatie kan tijdens het wervingsproces meerdere fasen doorlopen, b.v. "niet ingediend", "onder beoordeling", "wacht op beslissing", "besluit genomen", enz. Een aanvraag krijgt de status "niet ingediend" wanneer de gebruiker een aanvraag heeft gestart maar deze niet heeft ingediend voor beoordeling door de recruiters. Zodra de aanvraag is ingediend, wordt de status gewijzigd in "in behandeling", enzovoort. De application_status tabel wordt gebruikt om dergelijke informatie op te slaan.

De application_status_change tabel wordt gebruikt om statuswijzigingen bij te houden voor alle ingediende aanvragen. De date_changed kolom slaat de datum van de statuswijziging op. Deze tabel kan handig zijn als u de verwerkingstijd voor elke fase van verschillende toepassingen wilt analyseren. Bovendien kan de status van een bepaalde kolom worden opgehaald met behulp van de application_id kolom uit de application_status_change tafel.

Een eenvoudige use-case voor werving

Laten we eens kijken hoe onze database het wervingsproces kan helpen.

Stel dat een bedrijf u heeft toegewezen om een ​​IT-manager met programmeerervaring in te huren. Onze database kan ons helpen zo'n persoon aan te nemen door de volgende stappen uit te voeren:

  1. De eerste stap is het starten van een nieuw wervingsproces. Hiervoor worden gegevens ingevoerd in het process en steps tafels. Een recruiter kan zoveel stappen toevoegen als nodig is.
  2. Tijdens de bovenstaande taak kan de recruiter een nieuwe baan maken en de details invoeren in de job , job_category , job_position , en organization tafels. Ten slotte wordt er een vacature geplaatst op een van de platforms die zijn opgeslagen in het job_platform tafel.
  3. Vervolgens zullen sollicitanten een profiel maken door hun gegevens in te dienen bij de applicant tafel. Vervolgens lanceren ze een nieuwe applicatie door meer gegevens in te voeren in de application tafel.
  4. Aanvragers kunnen ook documenten bij hun aanvraag voegen. Deze gegevens worden opgeslagen in het document en application_document tabellen.
  5. Als een gebruiker op meer dan één vacature wil solliciteren, herhaalt hij stap 3 en 4.
  6. Zodra de aanvraag is ingediend, wordt de status van de aanvraag ingesteld op 'ingediend' (of een andere statusnaam gekozen door de recruiter).
  7. De recruiter beoordeelt de sollicitatie en voert zijn/haar feedback in de application_evaluation tafel. In dit stadium bevat de gehuurde kolom geen informatie.
  8. Zodra een voldoende aantal sollicitaties is ontvangen, voert de recruiter de volgende stap uit die wordt weergegeven in de process_step tafel.
  9. Als de volgende stap het afnemen van een soort test is, maakt de recruiter een test door gegevens toe te voegen aan de test tafel.
  10. De test(s) die in stap 9 zijn gemaakt, worden toegewezen aan een bepaalde toepassing. De informatie die elke test aan elke applicatie toewijst, wordt opgeslagen in de application_test tafel. Houd er rekening mee dat tijdens elke fase de status van de aanvraag blijft veranderen. Dit wordt vastgelegd in de application_status_change tafel.
  11. Zodra de sollicitant de test heeft voltooid, worden de cijfers voor elke sollicitatietest door de recruiter beoordeeld en ingevoerd in het answer tafel.
  12. Zodra de test is gedaan, de volgende stap van de process_step tafel zal worden uitgevoerd. Laten we zeggen dat de volgende stap het interview is.
  13. De interviewgegevens worden ingevoerd in het interview tafel. De recruiter zal hun opmerkingen invoeren en zeggen of de persoon het interview heeft doorstaan ​​of niet. Dit wordt opgeslagen in de interview_note tafel.
  14. Als het process tabel bevat verdere interview- en teststappen, deze worden uitgevoerd totdat de laatste stap is bereikt.
  15. De laatste stap in de process_step tafel is normaal gesproken de aanwervingsbeslissing. Als de sollicitant slaagt voor zijn tests en sollicitatiegesprekken en het bedrijf besluit hem in dienst te nemen, worden de gegevens ingevoerd in de kolom 'Aanwerving' van de application_evaluation tafel en de persoon is aangenomen.

Wat vindt u van ons gegevensmodel voor het wervingssysteem?

In dit artikel hebben we gezien hoe je een heel eenvoudig databaseschema voor een wervingssysteem kunt maken. We verdeelden het schema in vier categorieën en legden ze elk in detail uit. Ten slotte hebben we een use-case uitgevoerd om aan te tonen dat ons schema daadwerkelijk kan helpen bij het werven van een werknemer.

Databaseontwerp banen zijn booming. Wilt u uw databasevaardigheden uitbreiden? Of u nu een nieuwkomer bent die de basisbeginselen van SQL wil leren of een doorgewinterde professional die zich wil verdiepen in het maken van tabellen in SQL | Interactieve cursus | Vertabelo Academy" target="_blank">database-ontwerp, bekijk de cursussen op eigen tempo van LearnSQL.com.


  1. KRUIS/BUITEN TOEPASSEN in MySQL

  2. Oracle-instelling per gebruiker standaardschema (geen sessie wijzigen)

  3. SQL Tabel vullen met willekeurige gegevens

  4. SQLiteDatabase-fout, nutteloos logboek