UGISS Community

Ciao,

 una domanda da absolute beginner in tema "BI/OLAP".

Sto disegnando un piccolo datamart riguardante l'organico in forza ad una azienda di medie dimensioni (diciamo 100 addetti) : in base alla registrazioni di assunzioni, dimissioni, spostamenti di ruolo, mi si chiede di produrre un cubo dal quale sia possibile "spaccando" per mese vedere il numero degli addetti, ulteriormente poi analizzabile per la dimensione "business unit"

Nella mia idea l'evento che mi genera il "fatto", è l'assegnazione di una persona ad una data business unit.

Pensavo di caricare come fatto questa "associazione" tra persona e bu, con una fact table di questo tipo

ID_DIPENDENTE | ID_AREA | DATA_INIZIO | DATA_FINE

 però mi trovo in difficoltà nel gestire la dimensione tempo..! :-|

Ad esempio supponendo di avere come dipendente:

ALBERTO NERI assunto a gennaio 2008 nell'area "commerciale" ed assegnato a marzo 2008 all'area "contabilità"

lo caricherei nella fact table con due record con le due FK verso la tabella DIPENDENTI e verso la tabella BU e le rispettive date (con DATA_FINE magari impostata  a 31/12/2999 nel record che riguarda l'attuale incarico).

Però una volta che "spacco" per mese, come posso fare in modo che questo signore entri nel conteggio dell'area "commerciale" per gennaio e febbraiio e a partire da marzo invece rientri correttamente nell'organico "contabilità"??

E più in generale... come si strutturano casi come questo? Tutti gli esempi che vedo in giro sulla manualistica considerano come fatti degli eventi "puntuali" come ad esempio la classica "data di vendita" e non fatti che occupano un certo time-span? Questo significa che sto sbagliando approccio e che devo rivedere la logica di fondo (usando come fatto un momento puntuale tipo la "data di assunzione"), magari trasformando pensantemente la logica del dato in sede di trasferimento ETL?

 Please help! :-)

Grazie,

 Matteo

Matteo,

la cosa migliore è seguire Kimball in un caso simile - nella metodologia Kimball tu definisci uno star schema con fatti puntuali. Se vuoi valutare lo stato "a una certa data" di una serie di entità, la cosa migliore è creare una tabella dei fatti chiamata "snapshot fact table" che con una cadenza che decidi tu (per es. mensile, ma puoi anche farla giornaliera) fa la "fotografia" di ogni addetto. In questo modo il tuo "fatto" diventa "lo stato" di un addetto in un certo giorno (o mese). Quella è la misura, quello è "l'evento". Da lì in poi è tutto in discesa.

Ciao,

 prima di tutto grazie mille per la risposta.

Quindi se ben capisco dovrei creare UNA fact table che periodicamente (diciamo mensilmente) vado a popolare in maniera incrementale con i dati che mi rappresentano le "associazioni" tra persone e business unit correnti?

Naturalmente per fare questo dovrei fare una trasformazione durante la fase ETL dal momento che nel db OLTP sono strutturati all'incirca come dicevo nella mail iniziale, naturalmente in forma normale: anagrafica soggetti, "anagrafica" delle unità e poi una molti a molti con le "associazioni" tra queste due entità e che presenta anche i campi data_inizio e  data_fine. Beh, questo direi che si può fare. ;-)

Quindi, concludendo, avrei una fact table che ogni mese si popola con queste 100 righe aggiuntive che rappresentano l'impiego "nel momento" del personale e che come "dato" contengono soltanto il riferimento al mese in cui è presa questa snapshot (come si sarà capito la mia fact non contiene chissà quali elementi da misurare, in pratica devo solo fare il conteggio delle assegnazioni...), giusto?

Grazie!

 Matteo

Esattamente come hai detto.