Database
 sql >> Database >  >> RDS >> Database

Modello di dati sui salari

Un modello di dati sulle buste paga ti consente di calcolare facilmente lo stipendio dei tuoi dipendenti. Come funziona questo modello?

Non importa se gestisci una piccola o grande azienda, hai bisogno di una sorta di soluzione per le buste paga. È qui che una domanda di busta paga torna utile. Inoltre, più grande è l'azienda, più difficile diventa gestire i calcoli salariali dei dipendenti; qui, una domanda di busta paga diventa una necessità. Per aiutarti a comprendere tutti i dati richiesti per tale applicazione, ti guideremo attraverso un modello di dati correlato.

Vediamo come funziona il nostro modello di dati sui salari!

Modello di dati

Con la creazione di questo modello di dati, ho cercato di creare un modello generalmente applicabile per ogni azienda. Naturalmente, ci saranno sempre differenze nelle normative, nelle politiche aziendali, ecc. che richiederanno la personalizzazione del modello per coprire le esigenze di una specifica busta paga. Tuttavia, i principi stabiliti in questo modello dovrebbero essere rilevanti per la maggior parte delle organizzazioni.

Va notato che questo modello è stato creato con diverse ipotesi:

  • Le retribuzioni stabilite dal contratto di lavoro sono annuali.
  • Gli stipendi netti (cioè con determinati importi detratti per le tasse, ecc.) sono pagati ai dipendenti.
  • Gli stipendi vengono pagati mensilmente.

Il modello dati è composto da quattordici tabelle ed è suddiviso in due aree tematiche:

  • Employees
  • Salaries

Per comprendere meglio il modello, è necessario esaminare a fondo ogni area tematica.

Dipendenti

Questa area tematica contiene informazioni dettagliate sui dipendenti. Si compone di nove tabelle:

  • employee
  • employment_terms
  • job_title
  • job_title_history
  • department
  • department_history
  • city
  • country
  • gender

La prima tabella che esamineremo è il employee tavolo. Contiene un elenco di tutti i dipendenti e i relativi dettagli. Gli attributi della tabella sono:

  • id – Un ID univoco per ogni dipendente.
  • first_name – Il nome del dipendente.
  • last_name – Il cognome del dipendente.
  • job_title_id – Fa riferimento al job_title tabella.
  • department_id – Fa riferimento al department tabella.
  • gender_id – Fa riferimento al gender tabella.
  • address – L'indirizzo del dipendente.
  • city_id – Fa riferimento alla city tabella.
  • email – L'e-mail del dipendente.
  • employment_start – La data di inizio del rapporto di lavoro di questa persona.

Nota che le colonne job_title_id e department_id sono ridondanti, poiché è possibile accedere alle informazioni sui titoli di lavoro e sui reparti attuali da job_title_history e department_history tavoli. Tuttavia, manterremo queste due colonne in questa tabella per un accesso più rapido alle informazioni.

Quello che segue è il employment_terms tavolo. Memorizza i dati sulla retribuzione di ciascun dipendente, come concordato nel contratto di lavoro, e su come è cambiata nel tempo. Gli attributi della tabella sono:

  • id – Un ID univoco per ogni serie di termini di lavoro.
  • employee_id – Fa riferimento al employee tabella.
  • agreed_salary – La retribuzione indicata nel contratto di lavoro.
  • salary_start_date – La data di inizio della retribuzione concordata.
  • salary_end_date – La data di fine del salario concordato. Questo può essere NULL perché uno stipendio potrebbe non avere alcuna modifica pianificata.

Il job_title tabella è un elenco dei titoli di lavoro che possono essere assegnati a vari dipendenti dell'azienda, ad es. analista, autista, segretario, direttore, ecc. La tabella ha i seguenti attributi:

  • id – Un ID univoco per ogni titolo di lavoro.
  • job_title – Il nome del titolo di lavoro. Questa è la chiave alternativa.

Abbiamo anche bisogno di una tabella per memorizzare la cronologia dei titoli di lavoro di ciascun dipendente. Ne abbiamo bisogno perché i dipendenti possono essere promossi, retrocessi o riassegnati all'interno dell'azienda. Il job_title_history table gestirà queste informazioni e sarà composta dai seguenti attributi:

  • id – Un ID univoco per la voce storica del titolo di lavoro.
  • job_title_id – Fa riferimento al job_title tabella.
  • employee_id – Fa riferimento al employee tabella.
  • start_date – La data in cui il dipendente ha ricoperto per la prima volta quel titolo di lavoro.
  • end_date – Quando il dipendente ha smesso di avere quel titolo di lavoro. Questo può essere NULL perché il dipendente potrebbe attualmente detenere quel titolo di lavoro.

La combinazione di job_title_id , employee_id e start_date è la chiave alternativa per la tabella sopra. Un dipendente può avere un solo titolo di lavoro assegnato in una determinata data.

La tabella successiva è il department tavolo. Questo elencherà semplicemente tutti i dipartimenti dell'azienda, come IT, Contabilità, Legale, ecc. Contiene due attributi:

  • id – Un ID univoco per ogni reparto.
  • department_name – Il nome di ogni dipartimento. Questa è la chiave alternativa.

I dipendenti possono anche cambiare reparto all'interno dell'azienda. Pertanto, dobbiamo avere un department_history tavolo. Questa tabella memorizzerà quanto segue:

  • id – Un ID univoco per la voce storica del reparto.
  • department_id – Fa riferimento al department tabella.
  • employee_id – Fa riferimento al employee tabella.
  • start_date – La data in cui un dipendente ha iniziato a lavorare in un reparto.
  • end_date - La data in cui un dipendente ha smesso di lavorare in quel reparto. Questo può essere NULL perché il dipendente potrebbe ancora lavorare lì.

La combinazione di department_id , employee_id e start_date è la chiave alternativa. Un dipendente può lavorare in un solo reparto alla volta.

La prossima tabella di cui parleremo è la city tavolo. Questo è un elenco di tutte le città rilevanti. Ha i seguenti attributi:

  • id – Un ID univoco per ogni città.
  • city_name – Il nome della città.
  • country_id – Fa riferimento al country tabella.

Il country la tabella è la prossima nel nostro modello. È semplicemente un elenco di paesi e contiene le seguenti informazioni:

  • id – Un ID univoco per ogni Paese.
  • country_name – Il nome del paese. Questa è la chiave alternativa.

L'ultima tabella in questa area tematica è il gender tavolo. Questa tabella elenca tutti i sessi. Contiene i seguenti attributi:

  • id – Un ID univoco per ogni sesso.
  • gender_name – Il nome del genere.

Analizziamo ora la seconda area tematica.

Stipendi

Questa area tematica è composta da tabelle che contengono tutti i dati che influenzano direttamente il calcolo della retribuzione per ciascun periodo nonché l'importo da erogare. È composto da cinque tabelle:

  • salary_payment
  • working_hours_log
  • working_hours_adjustment
  • adjustment
  • adjustment_amount

Ora diamo un'occhiata a ciascuna tabella.

La prima tabella è salary_payment . Contiene tutti i dettagli rilevanti sullo stipendio pagato a ciascun dipendente e presenta i seguenti attributi:

  • id – Un ID univoco per ogni stipendio.
  • employee_id – Fa riferimento al employee tabella.
  • gross_salary – Lo stipendio lordo, che sarà la base per ulteriori adeguamenti.
  • net_salary – La retribuzione netta (ovvero l'importo percepito dal lavoratore al netto delle varie trattenute).
  • salary_period – Il periodo per il quale viene calcolato e pagato lo stipendio.

Il secondo è il working_hours_log tavolo. Contiene dati sul numero di ore lavorate da ciascun dipendente, che possono influenzare determinati adeguamenti salariali. Questa tabella ha i seguenti attributi:

  • id – Un ID univoco per ogni voce del registro.
  • employee_id – Fa riferimento al employee tabella.
  • start_time – L'ora in cui il dipendente ha effettuato l'accesso, ovvero ha iniziato a lavorare per la giornata.
  • end_time – Quando il dipendente si è disconnesso. Può essere NULL perché non conosceremo l'ora esatta fino a quando il dipendente non si disconnette.

La prossima tabella che analizzeremo è working_hours_adjustment . Questa tabella verrà utilizzata solo nel calcolo degli aggiustamenti in base alle ore lavorate, ovvero quelle che hanno un valore TRUE in is_working_hours_adjustment nella adjustment tavolo. Gli attributi sono i seguenti:

  • id – Un ID univoco per ogni regolazione.
  • working_hours_log_id – Fa riferimento al working_hours_log tabella.
  • adjustment_id - Fa riferimento alla adjustment tabella.
  • salary_payment_id – Fa riferimento al salary_payment tavolo. Questo valore può essere NULL perché salary_payment_id verrà utilizzato solo una volta al mese, quando avvieremo il calcolo dello stipendio.
  • adjustment_amount – L'importo della rettifica.
  • adjustment_percentage – L'importo percentuale della rettifica. Questo verrà utilizzato per scopi storici, poiché la percentuale può cambiare nel tempo.

La prossima tabella di cui parleremo è la adjustment tavolo. Contiene informazioni su tutte le rettifiche utilizzate per il calcolo dello stipendio, ovvero tutte le tasse e i contributi che incidono sull'importo dello stipendio. Inoltre, conterrà tutti gli adeguamenti che dipendono dalle ore lavorate e non lavorate, come bonus, straordinari, congedo per malattia e congedo di maternità/paternità. Per questo, abbiamo bisogno dei seguenti dati:

  • id – Un ID univoco per ogni regolazione.
  • adjustment_name – Un nome che descrive tale adeguamento.
  • adjustment_percentage – L'importo percentuale del particolare aggiustamento.
  • is_working_hours_adjustment – Questo è un contrassegno se una regolazione dipende direttamente dall'orario di lavoro, ad es. straordinari, assenze per malattia, ecc.
  • is_other_adjustment – Questo è un contrassegno che contrassegna le regolazioni che non dipendono direttamente dalle ore lavorate, come detrazioni fiscali, contributi previdenziali, contributi del datore di lavoro, ecc.

Dopodiché, abbiamo bisogno di adjustment_amount tavolo. Verrà utilizzato per calcolare tutti gli adeguamenti salariali tranne quelli già presenti nel working_hours_adjustment , ovvero quelli che hanno un valore TRUE in is_other_adjustment nella adjustment tavolo. La tabella contiene i seguenti attributi:

  • id – Un ID univoco per ogni voce di importo di rettifica.
  • salary_payment_id – Fa riferimento al salary_payment tabella.
  • adjustment_id – Fa riferimento alla adjustment tabella.
  • adjustment_amount – L'importo di ciascuna rettifica calcolata.
  • adjustment_percentage - L'importo percentuale della rettifica. Verrà utilizzato per scopi storici, poiché la percentuale può cambiare nel tempo.

Lascia che ti faccia un esempio di come le tabelle working_hours_log , working_hours_adjustment , adjustment e adjustment_amount lavorare insieme per calcolare uno stipendio. Ogni giorno, il dipendente registra quando arriva al lavoro e quando esce. Questi dati possono essere visualizzati nel working_hours_log tavolo. Diciamo che un nostro dipendente ha fatto 10 ore di straordinario per un mese e, secondo la policy aziendale, verrà pagato il 20% in più all'ora per ogni ora di straordinario. Facendo riferimento alla adjustment tabella, potremo trovare il conguaglio richiesto, ovvero lo straordinario, che avrà un determinato importo percentuale (20%). Avremo anche is_working_hours_adjustment impostato su VERO. Utilizzando i dati di queste due tabelle, saremo in grado di calcolare l'adeguamento e memorizzarlo nel working_hours_adjustment tavolo.

Ora possiamo calcolare tutti gli altri aggiustamenti che non dipendono dalle ore lavorate. Questo sarà fatto in adjustment_amount tavolo. Proprio come abbiamo fatto sopra, faremo riferimento alla adjustment tabella e trovare le regolazioni di cui abbiamo bisogno, ad es. detrazioni fiscali, contributi previdenziali o contributi del datore di lavoro e le relative percentuali. Il is_other_adjustment flag nella adjustment la tabella verrà impostata su TRUE per queste regolazioni.

Sulla base di questi calcoli, possiamo memorizzare i dati sullo stipendio lordo e sullo stipendio netto nel salary_payment tavolo.

Ripercorrendo questo esempio, abbiamo coperto tutto nel nostro modello di dati!

Ti è piaciuto il modello di dati sui salari?

Ho cercato di creare un modello che potesse essere utilizzato in quasi tutte le situazioni. Tuttavia, è impossibile includere tutti i parametri specifici che influenzano il calcolo dello stipendio in un articolo di questa lunghezza. Trattando i principi generali, ho cercato di rendere questo modello utile come base solida per il tuo modello di dati sui salari.

Cosa ne pensi del modello di dati sui salari? È applicabile come soluzione per le tue esigenze di busta paga? Ti è venuto in mente qualcosa di diverso? Ci sono problemi specifici che hai riscontrato che cambierebbero in modo significativo il modello di dati? Dì la tua nella sezione commenti.