Il tuo problema dei dati storici è in effetti abbastanza comune: i dati relativi al business sono spesso correlati al tempo.
Approccio Snaphsot
Un modo per gestirlo è quello di scattare istantanee. È la soluzione proposta da @CandleOrange. Ma sembra anche essere la tua ipotesi: nel tuo dimensionamento ti aspetti di avere un evento diverso per ciascuna combinazione per ogni mese (completamente equivalente all'approccio istantaneo). Ma pensi di tenerlo nel database.
Ad esempio, un pacchetto software business leader gestisce le cifre di vendita in questo modo: per ogni mese, riassume le vendite di quel mese, per ogni combinazione di categoria di clienti, gruppo di prodotti e area geografica. In questo modo può produrre cifre di vendita in base ai criteri e per un determinato periodo di tempo, senza dover leggere milioni e milioni di transazioni sottostanti.
In effetti, qui non c'è differenza tra dati e dati storici. Dal punto di vista del business, il mese è parte integrante dei dati gestiti. Ed è frequente confrontare i dati di vendita di un anno rispetto all'anno precedente, ma anche di un mese al mese precedente o del primo trimestre di quest'anno con il primo trimestre dei 2 ultimi anni.
Data dell'approccio di validità (controllo delle versioni dipendente dal tempo)
Ma l'approccio dell'istantanea non sempre si adatta alle necessità. Molto spesso i dati possono dipendere dal tempo. Ad esempio, il venditore X può essere responsabile di una regione dal 1 ° marzo al 18 agosto e per un'altra regione dal 19 agosto ad oggi. Quindi quale regione si tiene per lui per agosto? Nessuno è più esatto dell'altro.
Per le relazioni grafiche è peggio. Perché ci sono aspetti dipendenti dal tempo in ogni dato e in ogni relazione. Facciamo un esempio: il manager A è responsabile del dipartimento X dal 20 gennaio al 20 settembre. Il dipendente B è assegnato al dipartimento X dall'anno scorso al 22 gennaio e il dipendente C viene assegnato a quel dipartimento da quando è entrato nell'azienda e si trova qui. Quindi chi gestisce il Manager A? Dipende completamente dalla data.
Ora, qual è la dimensione del database se si confronta l'approccio dipendente dal tempo e l'istantanea? Per l'istantanea devi clonare ogni valore rilevante ogni mese. Quindi per le 3 persone e 1 reparto del nostro esempio, avrai 36 record in un anno. E tu non sei ancora in grado di mantenere la piena verità. Per l'approccio dipendente dal tempo, hai i tuoi dati grezzi 3 record e hai solo dati aggiuntivi quando si verifica una modifica, quindi sei record in generale.
Il controllo delle versioni dei dati dipendente dal tempo rappresenta quindi molto accuratamente il mondo reale e lo spazio risparmiato. Ma rende la progettazione delle query molto più complessa.
Per evitare un incubo completo di query, è possibile lavorare per impostazione predefinita con la versione corrente di ciascun oggetto (ad esempio la validità finale è vuota) e creare cloni a tempo limitato (set di date di validità iniziale e finale) ogni volta che si modificano dati importanti. Dovresti quindi accedere a questi cloni e alle loro date di validità solo per la coppia di query dipendenti dal tempo che lo richiedono.
Supporto per sistemi di database
Per la maggior parte dei sistemi di database, devi prenderti cura degli aspetti dipendenti dal tempo. La dipendenza temporale degli elementi di dati deve essere identificata dall'inizio e si tratta di un lavoro di progettazione caso per caso.
Ma come già detto: è una sfida comune. Quindi fortunatamente c'è un po 'di supporto in giro: