Progettazione del modulo di rilevazione presenze

Question

Progettazione del modulo di rilevazione presenze

#1 da (1 voti)
#2 da (1 voti)
#3 da (0 voti)

2

Sto lavorando sul modulo di rilevazione presenze e sono riuscito a leggere i dati dalla macchina di temporizzazione nel seguente formato:

Id      CheckIn            Type Status
0000142 5/15/2015 6:00 PM   2   OK
0000142 5/15/2015 2:00 PM   1   OK
0000142 5/15/2015 6:00 AM   1   OK
0000142 5/15/2015 3:00 PM   2   OK

dove scrivi [ 1 - stamped in , 2 - stamped out ]

Dovrei progettare una tabella per memorizzare queste voci tenendo in considerazione quanto segue

Ogni dipendente deve prima inserire un pugno e poi dare un pugno
Alcuni dipendenti hanno 2 turni al giorno: 09: 00-01: 00 e 17: 00-09: 00
Alcuni dipendenti hanno un servizio notturno dalle 09:00 alle 09:00 (il servizio inizia ieri sera)

quello che sto pianificando e ho bisogno del tuo gentile consiglio è il seguente:

Per creare tabella EmployeeCheckIn [ Id,CheckIn,Type,Status ]
Per creare un'altra tabella ManipulatedEmployeeCheckIn [ Id,FirstIn,FirstOut,SecondIn,SecondOut ] dove FirstIn e FirstOut è In e Out per il primo turno e SecondIn e SecondOut sono In e Out per il secondo turno.

le mie domande

Sto rompere la normalizzazione aggiungendo la seconda tabella?
La seconda tabella conterrà molti valori NULL, si tratta di una cattiva progettazione?
Come eliminare le voci multiple, ad esempio, alcuni dipendenti eseguiranno l'accesso due volte e usciranno 3 volte, quindi come rimuovere la duplicazione nelle voci ma con tempistiche diverse?
Ultima domanda che è l'incubo di me, gli orari che iniziano questa sera e terminano domani mattina, come controllarli dal momento che non posso controllarli tramite il DateIn CheckIn

Se hai bisogno di ulteriori spiegazioni, sono pronto. Di te in anticipo

sql database-design normalization

posta Hadi 01.08.2015 - 14:58

fonte

3 risposte

Leggi altre domande sui tag sql database-design normalization

I requisiti appartengono a un piano d'azione? Per DI, dove creare dipendenze (nuovi oggetti) specificamente all'interno del codice del framework?

score 1 · Answer 1

Sì se ManipulatedEmployeeCheckIn[Id,FirstIn,FirstOut,SecondIn,SecondOut] contiene dati ridondanti che si trovano anche in EmployeeCheckIn[ Id,CheckIn,Type,Status]
Sì, in generale, i valori NULL dovrebbero essere evitati se possibile
Dipende dalle tue intenzioni che sembrano contraddire la tua domanda. Se vuoi utilizzare EmployeeCheckIn[ Id,CheckIn,Type,Status] come cronologia come hai scritto nel tuo commento, dovresti tenerli in considerazione in quanto si verificano questi eventi e devi registrarti.
Se ho capito bene, devi semplicemente cercare l'ID del dipendente e cercare la voce successiva con questo ID. Quindi puoi controllare la parte CheckIn e Type per vedere se la voce è valida.

Avrei i seguenti suggerimenti per evitare i dati nulli. Basta usare una tabella per registrare i check-in EmployeeCheckIn[ Id,CheckIn,Type,Status,Valid] dove Marchi validi se la voce soddisfa le tue regole. Quindi, una volta entrati nel tavolo, controlla se tutto va bene e imposta Valid. Quindi puoi facilmente operare sulla tabella filtrando tutto ciò che è Valido = 0 (se 0 significa non valido) e hai i dati che avevi originariamente voluto mettere in ManipulatedEmployeeCheckIn[Id,FirstIn,FirstOut,SecondIn,SecondOut]

Vorrei fare la validazione in un trigger che viene attivato quando i valori sono inseriti.

score 1 · Answer 2

Non penso che sia un problema. Talormalizzazione a volte è necessaria per ragioni pratiche. Ad esempio, hai solo due Ins e Out, se questo aumenta, dovresti creare un'altra tabella come la tabella InOuts
Non penso che NULL sia una brutta cosa, per il tuo design non penso che sia una preoccupazione
Devi creare una nuova tabella come le tabelle InOut. EmployeeCheckin e InOut avrebbero molti e molti rapporti
Puoi usare datetime e hai bisogno di una modifica della data per assicurarti che lo spostamento sia fino al giorno successivo

Spero che questo aiuti

grazie,

Johan

score 0 · Answer 3

Non capisco perché ManipulatedEmployeeCheckIn sia addirittura richiesto; sembra che i due record nella prima tabella descrivano adeguatamente due successive coppie di eventi check-in / check-out.

Considera anche i tentativi di check non riusciti (alcuni Status = "Access Denied" ). È necessario registrarne parecchi in breve tempo se si desidera registrarli. Un errore del lettore o un'autenticazione non preparata per un nuovo dipendente. Un altro tentativo, una chiamata al servizio di sicurezza, "OK, abbiamo risolto il problema, per favore riprova", un altro tentativo, successo. Come lo si registra?

In generale, sceglierei lo schema più semplice, più logico e più compatto con le disposizioni minime (o zero) per i casi speciali attuali. Mi limiterei a registrare gli eventi e qualsiasi raggruppamento di questi eventi potrebbe esserci, appartenere al livello applicazione / segnalazione.