Modellazione di database per la domanda e l'offerta di personale

TL; DR - Sto cercando una guida per la progettazione del mio database. Sono preoccupato che il mio design esistente sia inefficiente e non sarà in grado di gestire un numero elevato di dipendenti.

Questo sarà molto lungo, quindi per favore portami con me. Sono in procinto di creare un'applicazione JEE per il personale della domanda, dell'offerta e del tipo di applicazione web di utilizzo.

Finora, ho fatto quanto segue (la parte facile) Modelli Core DB come Employee, department, location ecc.

Punti chiave sulla struttura della domanda e dell'offerta:

1. L'assegnazione per ciascun dipendente può avvenire tra 0,1 e 1,0.
   2. Ogni nuovo dipendente viene automaticamente assegnato a un progetto di pool per 1.0
   3. È necessario monitorare l'allocazione di un dipendente in una granularità dell'allocazione di una settimana. Potrebbe essere richiesto di avere tracciamento dell'allocazione giornaliera in futuro.
   4. Un dipendente può essere assegnato parzialmente (tra 0,1 a 1,0) o completamente (1,0) per una richiesta.
   5. La domanda viene ulteriormente suddivisa in settimane e occorre tenere traccia dell'allocazione effettiva per ciascun dipendente in ciascuna di queste settimane. Un impiegato assegnato a una domanda può essere assegnato interamente o parzialmente ad alcuni o tutte le settimane per questa richiesta.

Sto pianificando di costruire la presentazione DB richiesta come 3 tabelle.

Demand Master (DM): Conterrà la voce per ogni nuova richiesta creata. Fondamentalmente il numero di dipendenti richiesti e la durata complessiva della domanda.

DemandLineItem (DLI) : è il livello 2 dei dati della domanda che memorizza i requisiti dei dipendenti per la domanda.

DemandLineItemDetails(DLID) : è il livello 3 di dettagli, che mantiene i dettagli di ciascuna allocazione per un dipendente a livello di settimana.

La relazione che immagino per queste 3 tabelle è come questa

DemandMaster(DM) <-- 1 to many --> DemandLineItem (DLI) <-- 1 to many --> DemandLineItemDetails (DLID)

Quindi ecco un set di dati fittizio:

Table DM:
DemandId <--> StartDate <--> EndDate
Demand1  <--> 10 Feb 2014 <--> 24 Feb 2014

Table DLI:
DemandId <--> DliId <--> EmployeeRoleRequirement
Demand1  <--> Dli1  <--> Foreman
Demand1  <--> Dli2  <--> LineManager
Demand1  <--> Dli3  <--> Manager

Table DLID:

DLIID <--> DLID_ID <--> allocationstart <--> allocationend
Dli1  <--> DLIID1  <--> 10 Feb 2014 <--> 17 feb 2014
Dli1  <--> DLIID2  <--> 18 feb 2014 <--> 24 feb 2014
Dli2  <--> DLIID3  <--> 18 feb 2014 <--> 24 feb 2014
Dli3  <--> DLIID4  <--> 10 Feb 2014 <--> 17 feb 2014

L'affermazione del problema:

1. Questo è un modo inefficiente di creare un monitoraggio di una domanda, a causa del numero di join coinvolti.
2. Con il numero di richieste aumentate, i dati DLI e DLID aumenteranno e sarà difficile eseguire operazioni CRUD veloci.
3. Se trasferisco una struttura simile alla struttura di fornitura, il numero di settimane di dati per un impiegato attuale sarà enorme, soprattutto perché la struttura dell'offerta deve ospitare almeno 2 anni di dati in futuro come "non utilizzati" OPPURE " disponibili "allocazioni.
4. Il fatto che anche le allocazioni impegnate in una richiesta debbano essere sottratte dal pool "non utilizzato" o "disponibile" di cui sopra rende più complesso.

Esiste un modo migliore per conservare dati come questo (dati di livello settimanale / giornaliero per ciascun dipendente)?
Forse un modello DB migliore O un approccio diverso?

Sto usando mysql-workbench e il database mysql per la progettazione. Pianificazione per l'utilizzo di JPA (provider di ibernazione) come ORM.