Progettazione database - Sistema di ingresso e uscita per i dipendenti

Question

Desidero sviluppare il sistema di ingresso e uscita per dipendenti (sito Web).

mi riguarda due cose:

• Se il personale dimenticato di 'Clock Out' da ieri e hanno 'Clock In' oggi, dovrebbe bandiera per il manager.

• Il personale può funzionare nel tempo, ad esempio: Orologio In Lunedi 11:00 Per Martedì 01:30 (dopo la mezzanotte). Non voglio che il sistema pensi che il personale abbia dimenticato di uscire ..

  • Il personale può effettuare l'orologio in entrata e l'uscita più volte al giorno.

come risolvere questo problema e che cosa può essere migliorata su Database Design?

tavolo degli insegnanti:

+-------------+--------------+------+-----+---------+----------------+ 
| Field  | Type   | Null | Key | Default | Extra   | 
+-------------+--------------+------+-----+---------+----------------+ 
| id   | int(11)  | NO | PRI | NULL | auto_increment | 
| name  | varchar(50) | NO |  | NULL |    | 
| password | varchar(50) | NO |  | NULL |    | 
| hourly_rate | decimal(6,2) | NO |  | NULL |    | 
+-------------+--------------+------+-----+---------+----------------+ 

tavolo clocking:

+----------------+----------+------+-----+---------+----------------+ 
| Field   | Type  | Null | Key | Default | Extra   | 
+----------------+----------+------+-----+---------+----------------+ 
| id    | int(11) | NO | PRI | NULL | auto_increment | 
| staff_id  | int(11) | NO |  | NULL |    | 
| clock_in_date | datetime | NO |  | NULL |    | 
| clock_out_date | datetime | NO |  | NULL |    | 
+----------------+----------+------+-----+---------+----------------+ 

Answer 1

la struttura del database sembra che vada bene. Dovrebbe registrare solo i tempi di entrata e di uscita. Da qualche altra parte nella tua applicazione dovresti programmare le tue regole aziendali. You may read this article on wikipedia sulla separazione dei dubbi.

Answer 2

Questo non è completamente corretto dal punto di vista del dominio.

ins orologi o uscite/punzoni sono necessari ai fini della revisione o risoluzione di problemi. Quindi, è necessario memorizzare la cronologia dei singoli pugni per tutti i dipendenti.

Il cronometro nel tuo caso potrebbe essere un dato derivato.

La tabella di clock dovrebbe essere

+----------------+----------+------+-----+---------+----------------+ 
| Field   | Type  | Null | Key | Default | Extra   | 
+----------------+----------+------+-----+---------+----------------+ 
| id    | int(11) | NO | PRI | NULL | auto_increment | 
| staff_id  | int(11) | NO |  | NULL |    | 
| clock_type  | int(1) | NO |  | 0  | 0-in, 1-out | 
| clock   | datetime | NO |  | NULL |    | 
+----------------+----------+------+-----+---------+----------------+ 

Answer 3

dovrai consentire NULL su clock_out_date. In questo modo, puoi registrare un check-in al momento in cui si verifica e lasciare semplicemente il clock_out_dateNULL per indicare che l'utente non ha ancora effettuato il check-out.

Se si prevede di sostenere a più check-in/out per evento/giorno, allora si avrà bisogno anche di una colonna ID evento/giorno nella tabella clock in modo che è possibile raggruppare le archiviazioni di eventi/giorno. Come hai notato, la data non può essere utilizzata per raggruppare i check-in che si estendono a mezzanotte. Usiamo un event_id, ma forse vuoi un payroll_date.

Sto utilizzando la stessa struttura di tabella di clocking per un sistema simile. È in produzione da un anno e non cambierei nulla. Archiviamo tutti i tempi in UTC.

Si noti che non si utilizza questo sistema per il libro paga, e non ci può essere significativo requisiti di controllo per un sistema del libro paga.

Answer 4

Non vedo davvero un problema con il tuo progetto tanto quanto vedo un problema con i requisiti scarsamente definiti.È necessaria una migliore definizione di quando il gestore viene modificato per tenere conto dei turni che si verificano in più giorni. Forse la regola migliore sarebbe che se qualcuno non ha esaurito il tempo per 24 ore o se provano a cronometrare una seconda volta, il supervisore viene avvisato. Potrebbe inoltre essere necessario un trigger sul database che non consenta un clock in se manca un clock. Oppure è possibile consentire l'ingresso e inviare il clockout mancante al supervisore per l'azione.

Una cosa di cui hai particolarmente bisogno è il controllo (una tabella separata) in modo che tu possa vedere chi ha cambiato i record quando. Ti piacerebbe essere in grado di dire chi ha cambiato il record e qual era il valore precedente in caso di domande sul tempo di qualcuno.

Il cronometraggio (e presumo che vengano pagati in base alle ore di clock) è un'attività che richiede seri controlli interni (a livello di database non nell'applicazione! I controlli interni non devono mai essere a livello di applicazione se si sta provando a prevenire le frodi.) Nessuno dovrebbe avere accesso diretto al tavolo. Dovrebbero essere in grado di cambiare solo attraverso una procedura memorizzata che impone esattamente quello che possono fare.

Si consiglia di disporre di regole specifiche per i supervisori vice non supervisori. Generalmente qualsiasi cosa legata al tempo dovrebbe essere autorizzata a essere modificata da un supervisore della persona dopo il fatto. Avrei un trigger che impone questo, la persona che entra nella scheda attività dovrebbe solo essere autorizzato a cambiare l'orologio nei dati e solo se è nullo. Tutti gli altri cambiamenti dovrebbero essere da un supervisore della persona. Quindi potrebbe essere necessario un tavolo per memorizzare la struttura organizzativa o almeno un campo che mostri chi è il supervisore della persona dello staff.

Se le persone stanno per essere basate su ritardi di clock e operazioni, quindi si potrebbe voler verificare con le persone contabili e i loro revisori di essere finalizzare le regole di business. Il controllo interno per questo tipo di cose può essere molto complesso e difficile da correggere.

Un problema di progettazione che vedo è la colonna della tariffa oraria, questo cambia nel tempo e vorrete essere in grado di dirlo (specialmente se il tasso cambia nel mezzo di un periodo di paga- namento per qualche motivo), quindi vorrei spezzare questo fuori ad una tabella correlata. Ancora una volta, i diritti su questa tabella devono essere rigorosamente applicati. Nessuno esonera una persona delle risorse umane dovrebbe essere in grado di inserire i dati nel campo della tariffa oraria.

Answer 5

Che enorme lattina di vermi si sta aprendo qui amico. Dopo aver lavorato per un'azienda che fa solo sistemi di clock, è qualcosa che non vorrò più fare!

Mi rendo conto che la mia risposta è molto concettuale e affronta alcuni aspetti al di fuori della portata normale della domanda, ma questo è per delineare la progettazione del database e i concetti strutturali in questo tipo di applicazione. Questa informazione deriva dal recente sviluppo specialistico che ho fatto in questo settore, quindi non è solo ipotetico, ma dimostrato nella pratica.

Quando si guarda a questo tipo di sistema, è preferibile utilizzare inizialmente indicatori come indicatori, in genere si tratta della quantità di punzoni rispetto al confronto di ogni record. Confrontare ogni record con 1.000 dipendenti non è la cosa migliore!

Ad esempio, se l'utente ha in un periodo di 24 ore 8 pugni (inizio della giornata, inizio pausa mattutina, fine pausa mattutina, inizio pranzo, fine pranzo, inizio pausa pomeridiana, fine pausa pomeriggio e fine giornata) può determinare che è improbabile che non ci siano stati pugni mancati nel periodo e che si siano verificati degli straordinari, tuttavia se ci sono stati 7 pugni nel periodo di 24 ore (inizio della giornata, inizio della pausa mattutina, fine della pausa mattutina, inizio del pranzo, fine del pranzo, pomeriggio pausa inizio e fine giornata) si sa che manca un pugno e la persona ha dimenticato di uscire per il giorno. Notate come la fine della pausa pomeridiana non c'è.

Tuttavia questo non è a prova di tutto e fornisce solo un riferimento indicativo, sarà necessario confrontare un programma di turno con i pugni per assicurarsi che nulla sia stato effettivamente perso. Perché è possibile che sia la fine del pranzo sia la pausa pomeridiana siano state entrambe perse lasciando 6 pugni che puoi impostare il tuo codice per segnalare tutto ciò che non è il numero X di pugni per quel dipendente. Quando viene segnalato, esegui il confronto effettivo su quel dipendente per quel periodo per capire cosa è effettivamente successo e cosa è mancato.

Questo non significa che non si confronta tutti i record, la cosa è comunque in funzione del numero di dipendenti che potrebbe causare alcuni grossi problemi a fare il confronto esatta su ogni record, è qui che è generalmente migliore per i numeri più grandi dei dipendenti di utilizzare 2 server, 1 solo per raccolta dati e solo interfaccia, il secondo per l'esecuzione di processi di confronto.

Come ho già detto, per questo tipo di applicazione e per lavorare con orari diversi, è anche necessario tenere in considerazione gli orari dei turni per confrontarli. Dovrai tenere un record di riempimento per ogni dipendente che darà uguale tempo prima di un turno di inizio e dopo un turno di fine. Ciò significa che le probabilità di straordinari che si estendono oltre 1 periodo di tempo saranno minime. Il formulare di base è molto semplice: numero di ore nel turno - 24 ore/2 = tempo di riempimento

Ora si posiziona il tempo di riempimento prima e dopo il programma di turni per quell'utente. Ma devi ancora gestire uno scambio di turno, cambiare o più di un turno di 24 ore. Questo è dove diventa davvero difficile. Dovrai cercare di tenere una tabella di tempi di sovrapposizione (padding, shift e punch) che possono essere riconciliati con eventuali aggiustamenti futuri ai programmi, poiché le modifiche dei fatti non sono rare nel tempo.

Ora vorrai anche tenere una tabella di periodi di assenteismo per assenze per malattia e ferie, questi dati dovranno quindi essere segnalati generalmente all'interno della tabella di punch-in/punch-out in quanto questo è ciò con cui ti confronti. Quando viene impostato un flag per un periodo, il record può essere saltato in confronto e una nota lasciata sul report senza dover eseguire ulteriori operazioni per controllarlo.

Quasi alla fine, si noti come è necessario dimenticare le convenzioni di data/ora normale per misurare questo per un intervallo di variabili? Per non parlare di lavorare in modo efficace ed efficiente in più date? Per questo motivo generalmente è meglio lavorare solo con i tempi di inizio e di fine di gg/mm/AAAA hh: mm: ss, per le misurazioni usare il tempo UNIX per calcolare quanto tempo è trascorso. Dicendo che per essere in grado di controllare la maggior parte dei sistemi è necessario un record "data stamp", quindi è probabile che l'elaborazione lato server di questo sia richiesta quando si inseriscono i report.

Infine, vorrei anche consigliare di tenere una tabella dei risultati, questo darebbe i risultati di reporting per ogni utente, in questo modo quando si desidera fornire record storici è possibile generare dinamicamente documenti tuttavia non si deve sprecare potenza di elaborazione confrontare i record ogni volta che viene richiesto un report.

Spero che questo aiuti!