PROGETTAZIONE DEL DATAWAREHOUSE PER IL MAGAZZINO VIRTUALE

PREMESSA

Una volta affrontato il discorso generale del reporting per i vari tipi di Distretti, è necessario personalizzare il progetto per lo scenario del Magazzino Virtuale.
Questo tipo di progetto ha bisogno più di altri della personalizzazione degli utenti, oltre che delle idee del progettista.
Per ora il progetto del MV è ancora allo stadio iniziale, quindi il presente lavoro si è limitato ad immaginare i bisogni informativi di chi dovrà gestire gli approvvigionamenti, i trasportatori, le scorte dei magazzini e così via, basandosi sulle specifiche richieste da chi sta portando avanti questo progetto, ovvero la Unitec.

SCELTA DELL'ARCHITETTURA E DELLA TIPOLOGIA

La scelta che si è voluto portare avanti in questo lavoro di tesi è stata quella di progettare un data mart, piuttosto che un Datawarehouse nella sua completezza.
La scelta è stata peraltro obbligata dal fatto stesso che il Magazzino Virtuale si occupa di una specifica funzione aziendale, ovvero la Logistica e gli Approvvigionamenti.
Per Datamart si intende un sottoinsieme od un'aggregazione di dati, contenente l'insieme delle informazioni rilevanti per una particolare area del business, una particolare divisione dell'azienda, una particolare categoria di soggetti.
L'architettura scelta per il modello è un'architettura a due livelli.
Nella realtà del progetto in analisi i livelli sono quattro:

  1. Livello delle Sorgenti
  2. Livello di Alimentazione
  3. Livello Datamart
  4. Livello di Analisi

Graficamente i passaggi sono di facile comprensione, come si può vedere dalla figura. Un'ultima scelta che bisogna fare è quella sull'implementazione del Datamart, ovvero la scelta tra Sistema ROLAP (Relational OLAP) e MOLAP (Multidimensional OLAP).

La scelta effettuata in questo lavoro è quella di adottare un sistema ROLAP.
Questa idea è ben motivata dal fatto che è stato svolto un'enorme lavoro in letteratura sul modello relazionale (lo stesso del Database del MV) e che esso è il sistema più utilizzato a livello aziendale; questo grande utilizzo in ambito aziendale implica una maggiore conoscenza dell'utilizzo e dell'amministrazione.
Tuttavia, il modello relazionale non include il concetto di dimensione, misura e gerarchia, che sono tipici delle architetture MOLAP, e che sono alla base delle analisi multidimensionali.
Per superare questo problema si utilizzano tipologie specifiche di schemi che permettano di traslare il modello multidimensionale sui mattoni base costituiti da attributi, relazioni e vincoli di integrità.
Questo ruolo è svolto da un particolare tipo di schema, utilizzato nel presente lavoro, ovvero lo schema a stella o star schema.

Il problema principale di questi sistemi è quello delle prestazioni, che soffrono della necessità di eseguire numerose operazioni di collegamento (join) sulle tabelle che solitamente sono di dimensioni elevate.
La soluzione a questo problema è quello di denormalizzare gli schemi di partenza in funzione del volume di dati utilizzati e dalla frequenza di utilizzo e quindi riscrivere gli stessi dati più volte nello stesso database (ridondanze), con conseguente aumento dello spazio utilizzato, ma anche miglioramento delle prestazioni di accesso.

Da un punto di vista architetturale, l'adozione di ROLAP richiede di avere uno stadio intermedio (middleware) che fa da interprete tra il server relazionale, dove è presente il Datamart, e l'utente finale che è il cosiddetto front-end.
Questo ruolo permette di tradurre le interrogazioni OLAP formulate dall'utente e tradurle in istruzioni SQL per il Datamart.
Nel presente lavoro questo ruolo è svolto dal pacchetto "Analysis Service" contenuto "di serie" in SQL Server 2000.

Se invece fosse stato scelto un sistema MOLAP, sicuramente l'implementazione sarebbe stata più difficoltosa, considerando la scarsità di strumenti commercialmente reperibili, oltre che una maggiore difficoltà di progettazione sul quale la letteratura è decisamente più avara.

Un vantaggio sicuro sarebbe stato quello che le operazioni multidimensionali sono realizzabili in modo semplice e naturale, senza necessità di ricorrere a complesse e costose (in termini di prestazioni) associazioni tra tabelle, proprio perché questi sistemi sono concepiti in modo multidimensionale, ad hoc per l'analisi. Le prestazioni sono quindi ottime.

 


Top| Sommario| << Precedente | Successiva >>
>> Home Page www.elogistic.it <<