Data warehouse ed Enterprise Resource Planning | DWH ed ERP

ARCHIVIO DATI CENTRALE : STORIA ED EVOLUZIONI

I due temi dominanti della corporate technology negli anni 90 sono stati i data warehouse e l’ERP. Per molto tempo queste due potenti correnti sono state parti della corporate IT senza mai avere intersezioni. Era quasi come se fossero materia ed anti-materia. Ma la crescita di entrambi i fenomeni ha portato inevitabilmente a una loro intersezione. Oggi le aziende stanno affrontando il problema di che cosa fare con ERP e data warehouse. Questo articolo illustrerà quali sono i problemi e come vengono affrontati dalle aziende .

ALL’INIZIO…

All’inizio c’era il data warehouse. Data warehouse è nato per contrastare il sistema applicativo di elaborazione delle transazioni. Nei primi tempi la memorizzazione dei dati era pensata per essere solo un contrappunto alle applicazioni di elaborazione delle transazioni. Ma al giorno d’oggi ci sono visioni molto più sofisticate di quello che può fare un data warehouse. Nel mondo odierno il data warehouse è inserito all’interno di una struttura che può essere chiamata Corporate Information Factory.

LA CORPORATE INFORMATION FACTORY (CIF)

La Corporate Information Factory ha dei componenti architetturali standard: un livello di trasformazione e di integrazione del codice che integra i dati mentre i dati si muovono dall’ambiente di applicazione verso l’ambiente del data warehouse dell’impresa; un data warehouse dell’azienda dove vengono memorizzati i dati storici dettagliati e integrati. Il data warehouse dell’azienda serve da fondamento sul quale possono essere costruite tutte le altre parti dell’ambiente del data warehouse; un operational data store (ODS). Un ODS è una struttura ibrida che contiene alcuni aspetti del data warehouse e altri aspetti di un ambiente OLTP; data marts, in cui i differenti reparti possono avere loro propria versione del data warehouse; un data warehouse di esplorazione in cui i “filosofi”(thinkers) dell’azienda possono presentare le loro queries di 72 ore senza effetto nocivo sul data warehouse; e una memoria near line, in cui dati vecchi e dati bulk detail possono essere memorizzati a buon mercato.

DOVE SI UNISCE L’ERP CON LA CORPORATE INFORMATION FACTORY

L’ERP si unisce con la Corporate Information Factory in due punti. Innanzitutto come un’applicazione di base (baseline) che fornisce i dati dell’applicazione al data warehouse. In questo caso i dati, generati come sottoprodotto di un processo di transazione, vengono integrati e caricati nel data warehouse dell’azienda. Il secondo punto di unione tra ERP e CIF e l’ODS. In effetti, in molti ambienti l’ERP è utilizzato come un ODS classico.

Nel caso in cui ERP è utilizzato come applicazione di base, lo stesso ERP può essere anche utilizzato nella CIF come ODS. In ogni caso, se l’ERP deve essere utilizzato in entrambi i ruoli, ci deve essere una netta distinzione tra le due entità. In altre parole, quando l’ERP svolge il ruolo di applicazione di base e di ODS, le due entità architetturali devono essere distinte. Se una singola implementazione di un ERP prova a svolgere entrambi i ruoli contemporaneamente ci saranno inevitabilmente dei problemi nella progettazione e nell’implementazione di tale struttura.

SEPARARE ODS E APPLICAZIONI DI BASE

Ci sono molte ragioni che portano alla divisione dei componenti architetturali. Forse la questione più eloquente per separare i diversi componenti di un’architettura è che ogni componente dell’architettura ha la propria vista. L’applicazione baseline serve per uno scopo differente di quello dell’ODS. Provare a sovrapporre

una vista di applicazione baseline sul mondo di un ODS o viceversa non è un modo giusto di lavorare.

Di conseguenza, il primo problema di un ERP nella CIF è quello di verificare se c’è una distinzione fra le applicazioni baseline ed il ODS.

DATA MODELS NELLA CORPORATE INFORMATION FACTORY

Per realizzare una coesione fra i differenti componenti dell’architettura della CIF, ci deve essere un modello di dati. I modelli di dati servono da legame tra i vari componenti dell’architettura come ad esempio le applicazioni baseline e l’ODS. I modelli di dati diventano la “carta stradale intellettuale” per avere il giusto significato dai differenti componenti architettonici della CIF.

Andando di pari passo con questa nozione, l’idea è che ci dovrebbe essere un grande e unico modello di dati. Ovviamente ci deve essere un modello di dati per ciascuno dei componenti e inoltre ci deve essere un percorso sensato che collega i modelli differenti. Ogni componente dell’architettura – ODS, applicazioni baseline, data warehouse dell’azienda, e così via.. – necessita del proprio modello di dati. E quindi ci deve essere una definizione precisa di come questi modelli di dati si interfacciano a vicenda.

SPOSTARE I DATI DELL’ERP NEL DATA WAREHOUSE

Se l’origine dei dati è un’applicazione baseline e/o un ODS, quando l’ERP inserisce i dati nel data warehouse, tale inserimento deve avvenire al più basso livello di “granularity”. Ricapitolare o aggregare semplicemente i dati così come vengono fuori dall’applicazione baseline dell’ERP o dall’ODS dell’ERP non è la cosa giusta da fare. I dati dettagliati sono necessari nel data warehouse per costituire le basi del processo di DSS. Tali dati saranno rimodellati in molti modi dai data marts e dalle esplorazioni del data warehouse.

Lo spostamento dei dati dall’ambiente dell’applicazione baseline dell’ERP all’ambiente del data warehouse dell’azienda è fatto in un modo ragionevolmente disteso. Tale spostamento accade dopo che circa 24 ore dall’aggiornamento o dalla creazione nel ERP. Il fatto di avere un movimento “pigro” dei dati nel data warehouse dell’azienda permette ai dati provenienti dall’ERP di “depositarsi”. Una volta che i dati sono depositati nell’applicazione baseline, allora è possibile spostare in modo sicuro i dati dell’ERP nell’impresa. Un altro obiettivo raggiungibile grazie al movimento “pigro” dei dati è la chiara delimitazione fra processi operazionali e DSS. Con un movimento “veloce” dei dati la linea di demarcazione tra DSS e operazionale rimane vaga.

Il movimento dei dati dall’ODS dell’ERP al data warehouse dell’azienda viene fatto periodicamente, solitamente settimanalmente o mensilmente. In questo caso il movimento dei dati è basato sulla necessità di “pulire” i vecchi dati storici. Naturalmente, l’ODS contiene i dati che sono molto più recenti rispetto ai dati storici trovati nel data warehouse.

Lo spostamento dei dati nel data warehouse non è quasi mai fatto “all’ingrosso” (in a wholesaler manner). Copiare una tabella dall’ambiente ERP al data warehouse non ha senso. Un approccio molto più realistico è lo spostamento di unità selezionate dei dati. Solo i dati che sono cambiati dall’ultimo aggiornamento del data warehouse sono quelli che dovrebbero essere spostati nel data warehouse. Un modo per sapere quali dati sono stati modificati dall’ultimo aggiornamento è quello di guardare i timestamp dei dati trovati nell’ambiente ERP. Il progettista seleziona tutti i cambiamenti che si sono presentati dall’ultimo aggiornamento. Un altro approccio è quello di usare tecniche di acquisizione di cambiamento dati. Con queste tecniche vengono analizzati log e journal tapes in modo da determinare quali dati devono essere spostati dall’ambiente ERP a quello del data warehouse. Queste tecniche sono le migliori in quanto i log e i journal tapes possono essere letti dai file dell’ERP senza ulteriori effetti sulle altre risorse dell’ERP.

ALTRE COMPLICAZIONI

Uno dei problemi dell’ERP nella CIF è quello che accade ad altre fonti dell’applicazione o ai dati dell’ODS che devono contribuire al data warehouse ma non fanno parte dell’ambiente di ERP. Data la natura chiusa dell’ERP, specialmente SAP, il tentativo di integrare le chiavi dalle fonti esterne dei dati con i dati che vengono dall’ERP al momento di spostare i dati nel data warehouse, è una grande sfida. E quante sono esattamente le probabilità che i dati di applicazioni o ODS al di fuori dell’ambiente ERP saranno integrati nel data warehouse? Le probabilità sono effettivamente molto alte.

REPERIRE DATI STORICI DALL’ERP

Un altro problema con i dati dell’ERP è quello derivante dall’esigenza di avere dati storici all’interno del data warehouse. Solitamente il data warehouse ha bisogno di dati storici. E solitamente la tecnologia dell’ERP non memorizza questi dati storici, almeno non fino al punto in cui è necessario nel data warehouse. Quando una grande quantità di dati storici comincia ad aggiungersi nell’ambiente di ERP, tale ambiente deve essere ripulito. Per esempio si supponga che un data warehouse debba essere caricato con cinque anni di dati storici mentre l’ERP tiene al massimo sei mesi di questi dati. Finché la società è soddisfatta di raccogliere una serie di dati storici man mano che passa il tempo, allora non ci sono problemi nell’utilizzare l’ERP come sorgente per il data warehouse. Ma quando il data warehouse deve andare indietro nel tempo e prendere dei dati storici che non sono stati precedentemente raccolti e salvati dall’ERP, allora l’ambiente ERP diventa inefficiente.

ERP E METADATI

Un’altra considerazione da fare su ERP e data warehouse è quella sui metadati esistenti nell’ambiente ERP. Così come i metadati passano dall’ambiente ERP all’ambiente del data warehouse, i metadati devono essere spostati nello stesso modo. Inoltre, i metadati devono essere trasformati nel formato e nella struttura richiesti dall’infrastruttura del data warehouse. C’è una grande differenza tra metadati operazionali e metadati DSS. I metadati operazionali sono soprattutto per lo sviluppatore e per il

programmatore. I metadato DSS sono principalmente per l’utente finale. I metadati esistenti nelle applicazioni ERP o negli ODS devono essere convertiti e questa conversione non è sempre facile e diretta.

SOURCING THE ERP DATA

Se l’ERP è usato come fornitore di dati per il data warehouse ci deve essere una solida interfaccia che sposta i dati dall’ambiente ERP all’ambiente data warehouse. L’interfaccia deve:

• ▪  essere facile da usare
• ▪  permettere l’accesso ai dati dell’ERP
• ▪  prelevare il significato dei dati che stanno per essere spostati nel data warehouse
• ▪  conoscere le limitazioni dell’ERP che potrebbero nascere nel momento in cui viene effettuato l’accesso ai dati dell’ERP:
• ▪  integrità referenziale
• ▪  relazioni gerarchiche
• ▪  relazioni logiche implicite
• ▪  convenzione dell’applicazione
• ▪  tutte le strutture dei dati supportate dall’ERP, e così via…
• ▪  essere efficiente nell’accesso ai dati, fornendo:
• ▪  movimento diretto dei dati
• ▪  acquisizione di cambiamento dati
• ▪  essere di appoggio all’accesso tempestivo ai dati
• ▪  capire il formato dei dati, e così via… INTERFACCIARSI CON SAP L’interfaccia può essere di due tipi, homegrown o commerciale. Alcune delle principali interfacce commerciali includono:

• ▪  SAS
• ▪  Prims Solutions
• ▪  D2k, e così via… TECNOLOGIE DI ERP MULTIPLI Trattare l’ambiente ERP come se fosse un’unica tecnologia è un grosso errore. Ci sono molte tecnologie di ERP, ognuna con i suoi punti di forza. I vendor più conosciuti nel mercato sono:

• ▪  SAP
• ▪  Oracle Financials
• ▪  PeopleSoft
• ▪  JD Edwards
• ▪  Baan SAP SAP è il software di ERP più grande e più completo. Le applicazioni di SAP comprendono molti tipi di applicazioni in molte aree. SAP ha la reputazione di essere:

• ▪  molto grande
• ▪  molto difficile e costoso da implementare
• ▪  ha bisogno di molte persone e consulenti per essere implementato
• ▪  necessita di persone specializzate per l’implementazione
• ▪  ha bisogno di molto tempo per essere implementato Inoltre SAP ha la reputazione di memorizzare i suoi dati molto attentamente, rendendo difficile accedere a questi da parte di una persona esterna all’area SAP. La forza di SAP è quella di essere capace di catturare e memorizzare una grande quantità di dati. Recentemente SAP ha annunciato la sua intenzione di estendere le sue applicazioni ai data warehouse. Ci sono molti pro e contro nell’utilizzo di SAP come fornitore di data warehouse. Un vantaggio è che SAP è già installato e che la maggior parte dei consulenti già conosce SAP.
  Gli svantaggi di avere SAP come fornitore di data warehouse sono molti: SAP non ha esperienza nel mondo del data warehouse Se SAP è il fornitore di data warehouse, è necessario “portare fuori” i dati da SAP al data warehouse. Dato un SAP’s track record of closed system, è improbabile che sia facile ottenere i da SAP in esso (???). Ci sono molti legacy environment che alimentano SAP, come IMS, VSAM, ADABAS, ORACLE, DB2, e così via. SAP insiste in un approccio “not invented here”. SAP non vuole collaborare con altri fornitori per usare o creare il data warehouse. SAP insiste nel voler generare tutto il proprio software da solo.

Sebbene SAP sia una compagnia grande e potente, il fatto di tentare di riscrivere la tecnologia di ELT, OLAP, amministrazione del sistema e persino il codice di base del dbms è semplicemente folle. Invece di assumere un atteggiamento di cooperazione con i fornitori di data warehouse di vecchia data, SAP ha seguito l’approccio che loro “ne sanno di più”. Questo atteggiamento frena il successo che SAP potrebbe avere nell’area dei data warehouse.
Il rifiuto di SAP nel permettere ai fornitori esterni di accedere prontamente e con garbo ai loro dati. L’essenza stessa dell’uso di un data warehouse è l’accesso facile ai dati. L’intera storia di SAP è basata sul rendere difficile l’accesso ai dati.
La mancanza di esperienza di SAP nel trattare grandi volumi di dati; nel campo dei data warehouse esistono volumi di dati mai visti da SAP e per gestire queste grandi quantità di dati occorre avere una tecnologia adatta. SAP apparentemente non è informata di questa barriera tecnologica che esiste per entrare nel campo dei data warehouse.
La corporate culture di SAP: SAP ha creato un business nell’ottenere i dati dal sistema. Ma per fare questo bisogna avere una mentalità differente. Traditionally, software companies that were good at getting data into an environment have not been good at getting data to go the other way. Se SAP riesce a fare questo tipo di switch sarà la prima azienda a farlo.

In breve, è lecito chiedersi se un’azienda dovrebbe selezionare SAP come fornitore di data warehouse. Ci sono rischi molto gravi da una parte e molte poche ricompense dall’altra. Ma c’è un altro motivo che scoraggia la scelta di SAP come fornitore di data warehouse. Perché ogni compagnia dovrebbe avere lo stesso data warehouse di tutte le altre compagnie? Il data warehouse è il cuore del vantaggio competitivo. Se ogni compagnia adottasse lo stesso data warehouse sarebbe difficile, anche se non impossibile, raggiungere un vantaggio competitivo. SAP sembra pensare che un data warehouse può essere visto come un biscotto e ciò è un ulteriore segnale della loro mentalità di applicazioni “get the data in”.

Nessun altro fornitore di ERP è dominante quanto SAP. Indubbiamente ci saranno aziende che seguiranno la strada di SAP per i loro data warehouse ma presumibilmente questi data warehouse SAP saranno grandi, costosi e richiederanno molto tempo per la loro creazione.

Questi ambienti includono tali attività quali “bank teller processing”, processi per le prenotazioni aeree, processi per le lamentele assicurative, e così via. Più performante era sistema di transazione, più ovvio era il bisogno di separazione tra processo operazionale e DSS (Decision Support System). Tuttavia, con sistemi di risorse umane e personali, non ci si trova mai di fronte a grossi volumi di transazioni. E, naturalmente, quando una persona è assunta oppure lascia la compagnia questo è un record di una transazione. Ma relativamente ad altri sistemi, i sistemi di risorse umane e personali semplicemente non hanno molte transazioni. Perciò, nei sistemi di risorse umane e personali non è del tutto ovvio che ci sia bisogno di un DataWarehouse. In molti modi questi sistemi rappresentano l’accorpamento di sistemi DSS.

Ma c’è un altro fattore che deve essere considerato se si ha a che fare con datawarehouse e con PeopleSoft. In molti ambienti, i dati delle risorse umane e personali sono secondari rispetto al business primario della società. La maggior parte delle società svolgono attività manifatturiere, di vendita, forniscono servizi e così via. I sistemi di risorse umane e personali sono di solito secondari (o di supporto) alla linea principale di business della società. Perciò, è equivoco e poco conveniente un data warehouse separato per il supporto alle risorse umane e personali.

PeopleSoft è molto diverso da SAP a questo riguardo. Con SAP, è obbligatorio che ci sia un data warehouse. Con PeopleSoft, non è poi così chiaro. Un datawarehouse è opzionale con PeopleSoft.

La cosa migliore che si possa dire per i dati PeopleSoft è che il data warehouse può essere usato al fine di archiviare i dati relativi a vecchie risorse umane e personali. Una seconda ragione per la quale una compagnia vorrebbe usare un data warehouse a

discapito dell’ambiente PeopleSoft è di permettere l’accesso e l’accesso libero agli strumenti di analisi, ai dati di PeopleSoft. Ma oltre a queste ragioni, possono esserci casi in cui è preferibile non avere un datawarehouse per dati PeopleSoft.

In sintesi

Ci sono molti spunti che riguardano la costruzione di un data warehouse dentro ad un software ERP.
Alcuni di questi sono:

• ▪  Ha senso avere un data warehouse che somiglia a qualsiasi altro nell’industria?
• ▪  Quanto è flessibile un ERP data warehouse software?
• ▪  Un ERP data warehouse software può gestire un volume di dati che si trova in una “data warehouse arena”?
• ▪  Qual è la registrazione della traccia che il vendor ERP fa di fronte a facili e poco costosi, in termini di tempo, ai dati? (what is the ERP vendors track record on delivery of inexpensive, on time, easy to access data?)
• ▪  Qual è la comprensione dell’architettura DSS e della “corporate information factory” da parte del vendor ERP?
• ▪  I vendor ERP comprendono come ottenere dati all’interno dell’ambiente, ma comprendono anche come esportarli?
• ▪  Quanto aperto è il venditore dell’ERP a strumenti di data warehousing?
  Tutte queste considerazioni devono essere fatte nel determinare dove mettere il data warehouse che ospiterà i dati dell’ERP e altri dati. In generale, a meno ché non ci sia una ragione irresistibile per fare altrimenti, è raccomandato costruire data warehouse fuori dall’ambiente del vendor dell’ERP. CAPITOLO 1 Overview of the BI Organization Punti chiave:
  I depositi delle informazioni funzionano in modo contrario rispetto all’architettura di business intelligence (BI):
  La corporate culture e l’IT possono limitare il successo nella costruzione di organizzazioni di BI.

La tecnologia non è più il fattore che limita le organizzazioni di BI. Il problema per architetti e pianificatori di progetto non è se la tecnologia esiste, ma se possono implementare efficacemente la tecnologia disponibile.

Per molte aziende un data warehouse è poco più di un deposito passivo che distribuisce i dati agli utenti che ne necessitano. I dati sono estratti dai sistemi sorgenti e sono popolati in strutture target di data warehouse. I dati possono anche essere puliti con tutta la fortuna. Tuttavia nessun valore supplementare è aggiunto o raccolto dai dati durante questo processo.

Essenzialmente, il Dw passivo, nel migliore dei casi, fornisce soltanto i dati puliti e operativi agli associazioni di utenti. La creazione delle informazioni e la comprensione analitica dipendono interamente dagli utenti. Giudicare se il DW (Data warehouse) sia un successo è soggettivo. Se giudichiamo il successo sulla capacità di raccogliere, integrare e pulire efficientemente i dati corporativi su una base prevedibile, allora sì, il DW è un successo. D’altra parte, se guardiamo la raccolta, la consolidazione e lo sfruttamento delle informazioni l’organizzazione nell’insieme, allora il DW è un fallimento. Un DW fornisce poco o nessun valore delle informazioni. Di conseguenza gli utenti sono costretti ad arrangiarsi, creando cosi dei sili delle informazioni. Questo capitolo presenta una visione completa per ricapitolare l’ architettura di BI(Business Intelligence) dell’aziende. Cominciamo con una descrizione di BI e quindi ci muoveremo verso le discussioni sulla progettazione e sullo sviluppo delle informazioni, in contrasto con il semplice fornire i dati agli utenti. Le discussioni allora sono focalizzate sul calcolo del valore dei vostri sforzi di BI. Concludiamo con il definire come l’IBM richiama i requisiti architettonici di BI della vostra organizzazione.

Descrizione dell’architettura di organizzazione della BI

I potenti sistemi d’informazione transaction-oriented ora sono all’ordine del giorno in ogni grande impresa , in quanto livellano efficacemente il campo da giuoco per le società nel mondo.

Rimanere competitivi, tuttavia, ora richiede sistemi analiticamente orientati a che può rivoluzionare l’abilità dell’azienda riscoprendo ed utilizzando le informazioni che già possiedono. Questi sistemi analitici derivano dalla comprensione dalla ricchezza dei dati disponibili. La BI può migliorare le prestazioni in tutte le informazioni dell’impresa. Le aziende possono migliorare i rapporti tra cliente e fornitori, migliorare il profitto dei prodotti e dei servizi, generare nuove e migliori offerte , controllare il rischio e fra molti altri guadagni tagliano le spese drasticamente . Con BI la vostra azienda finalmente incomincia ad usare le informazioni del cliente come bene competitivo grazie ad applicazioni che hanno obiettivi di mercato.

Avere i giusti mezzi di Business significa avere risposte definitive a domande di chiave come:

• ▪  Quale dei nostri clienti ci fanno guadagnare di più, o ci mandano in perdita?
• ▪  Dove vivono I nostri migliori clienti in relazione al negozio/ magazzino che loro frequentano?
• ▪  Quali dei nostri prodotti e servizi possono essere venduti più efficacemente e a chi?
• ▪  Quali prodotti può essere venduto più efficacemente e a chi?
• ▪  Quale campagna di vendita è più riuscita e perchè?
• ▪  Quali canali di vendite sono più efficaci per quali prodotti?
• ▪  Come possiamo migliorare i rapporti con nostri migliori clienti? La maggior parte delle aziende hanno dati grezzi per rispondere a queste domande.
  I sistemi operazionali generano ampie quantità di prodotto, di cliente e di dati di mercato dai punti di vendita, dalle prenotazioni, dal servizio di cliente e dai sistemi di supporto tecnico. La sfida è estrarre e sfruttare queste informazioni. Molte aziende approfittano soltanto di piccole frazioni dei loro dati per le analisi strategiche.
  I dati restanti, uniti spesso con i dati derivanti fonti esterne come i “government reports” , e altre informazioni comprate, sono una miniera d’oro che attende solo di essere esplorata, e i dati devono essere solo raffinati nel contesto informativo della vostra organizzazione.

Questa conoscenza può essere applicata in diversi modi, varianti dal progettare una strategia corporativa generale alla comunicazione personale con i fornitori, attraverso call center, fatturazioni, Internet ed altri punti. L’odierno ambiente di affari detta che il DW e le soluzioni relative della BI si evolvono oltre l’esecuzione di tradizionali strutture di dati quali i dati normalizzati a livello-atomico ed “star/cube farms”.

Ciò che è necessario per rimanere competitivi è una fusione di tradizionale e tecnologie avanzate in uno sforzo per sostenere un vasto paesaggio analitico.
Per concludere, l’ambiente generale deve migliorare la conoscenza dell’impresa nell’insieme, accertandosi che le azioni intraprese come conseguenza di analisi condotte tornino utili affinchè tutti si avvantaggino.

Per esempio, diciamo che classificate i vostri clienti nelle categorie di alto o basso rischio.
Se queste informazioni sono generate da un modello estraente o altri mezzi, deve essere messo nel Dw ed essere reso accessibile a chiunque, per mezzo di qualsiasi strumento di accesso, quali i rapporti statici, fogli elettronici, tabelle, o elaborazione analitica in linea (OLAP).

Tuttavia, attualmente, molte di questo tipo di informazioni rimangono nei sili di dati degli individui o reparti che generano l’analisi. L’organizzazione, nell’insieme, ha poca o nessuna visibilità per la comprensione. Soltanto mescolando questo tipo di contenuto informativo nel vostro Dw di impresa potete eliminare i sili delle informazioni ed elevare il vostro ambiente di Dw.
Ci sono due ostacoli importanti per lo sviluppo di un’organizzazione della BI.
In primo luogo, abbiamo il problema dell’organizzazione in se e della relativa disciplina.
Anche se non possiamo aiutare con cambiamenti di politica dell’organizzazione, possiamo aiutare a capire i componenti di un’organizzazione della BI, la relativa architettura e come la tecnologia dell’IBM facilita il relativo sviluppo.
La seconda barriera da superare è la mancanza di tecnologia integrata e la conoscenza di un metodo che richiama l’intero spazio della BI in contrasto con solo un piccolo componente.

L’IBM sta venendo in contro ai cambiamenti di tecnologia d’integrata. È vostra la responsabilità di fornire una progettazione cosciente. Questa architettura deve essere sviluppata con tecnologia scelta per integrazione senza vincoli, o per lo meno, con tecnologia che aderisce agli standard aperti. Inoltre, la vostra gestione dell’azienda deve assicurare che l’impresa di Bi è effettuata secondo il programma e non quello di permettere lo sviluppo dei sili delle informazioni che derivano da self-serving ordini del giorno, o obiettivi.
Questo non vuol dire che l’ambiente della BI non è sensibile a reagire ai diversi bisogni e requisiti di diversi utenti; invece, significa che l’implementazione di quei bisogni dell’individuo e dei requisiti è fatto a vantaggio di intera organizzazione della BI.
Una descrizione dell’architettura dell’organizzazione della BI può essere trovata alla pagina 9 nella figura 1.1.L’architettura dimostra una miscela ricca delle tecnologie e tecniche.
Dalla vista tradizionale, l’architettura include i seguenti componenti di warehouse

Strato atomico(Atomic Layer).

Ciò è il fondamento, il cuore dell’intero Dw e quindi della segnalazione strategica.
I dati memorizzati qui conserveranno l’integrità storica, rapporti di dati ed includono la metrica derivata, come pure l’essere puliti, integrati, e memorizzati usando i modelli estraenti.
Tutto l’uso successivo di questi dati e delle relative informazioni è derivato da questa struttura. Questa è un eccellente fonte per estrazione di dati e per report con query SQL strutturate

Deposito operativo di dati o segnalare base di dati(Operational data store (ODS) or reporting database.)

Questa è una struttura di dati specificamente progettata per le segnalazione tecniche.

I dati memorizzati e riportati sopra queste strutture possono infine propagarsi nel warehouse tramite la zona di organizzazione(staging area), dove potrebbe essere usata per segnalazione strategica.

Staging area.

Il primo stop per la maggior parte dei dati destinati all’ambiente di warehouse è la zona di organizzazione.
Qui i dati sono integrati, puliti e trasformati in dati utili che popoleranno la struttura del warehouse

Data marts.

Questa parte dell’architettura rappresenta la struttura di dati usata specificamente per OLAP. La presenza dei datamarts, se i dati sono memorizzati negli star schema che sovrappongono dati multidimensionali in un ambiente relazionale, oppure negli schedari di dati riservati usati vicino la tecnologia specifica di OLAP, quale il server di DB2 OLAP, non è rilevante.

L’unico vincolo è che l’architettura facilita l’uso dei dati multidimensionali.
L’architettura comprende anche critiche tecnologie e tecniche di Bi che si distinguono come:

Analisi Spaziale(Spatial analysis)

Lo spazio è un bene inaspettato delle informazioni per l’analista ed è fondamentale per la risoluzione completa. Lo spazio può rappresentare le informazioni delle persone che vivono in una certa posizione, così come le informazioni circa dove quella posizione è fisicamente rispetto al resto del mondo.

Per effettuare questa analisi, dovete cominciare legando le vostre informazioni alle coordinate di latitudine e di longitudine. Ciò è indicato come “geocoding” e deve fare parte dell’estrazione, trasformazione, e del processo di caricamento (ETL) al livello atomico del vostro warehouse.

Data mining.

L’estrazione dei dati permette alle nostre aziende di far crescere il numero di clienti, di prevedere le tendenze di vendite e permettere la gestione dei rapporti con i clienti (CRM), tra altre iniziative della BI.

L’estrazione dei dati deve quindi essere integrata con le strutture di dati del Dwhouse e sostenuta da processi di warehouse per accertare sia l’uso efficace che efficiente del tecnologia e delle tecniche relative.

Come indicato nell’architettura della BI, il livello atomico del Dwhouse, così come i datamarts, è una eccellente sorgente di dati per l’estrazione. Quelle stesse strutture devono anche essere destinatari di risultati dell’estrazione per accertare la disponibilità ai più vasti pubblici.(broadest audience).

Agents.

Ci sono vari “agents” per esaminare il cliente per ogni punto come, i sistemi operativi dell’azienda e gli stessi dw. Questi agenti possono essere reti neurali avanzate addestrate ad apprendere sulle tendenze di ogni punto, come la richiesta futura del prodotto basata sulle promozioni di vendite, motori basati su regole per reagire ad un dato insieme di circostanze, o persino agenti semplici che segnalano le eccezioni ai “top executives”. Questi processi si presentano generalmente in tempo reale e, pertanto, devono essere accoppiati strettamente con il movimento degli stessi dati. Tutte queste strutture di dati, tecnologie e tecniche garantiscono che non passerete la notte a generare un’organizzazione della vostra BI.

Questa attività sarà sviluppata a passi incrementali, per piccoli punti.
Ogni passo è uno sforzo indipendente di progetto, ed è riferito come un iterazionenel vostro dw o iniziativa di BI. Le iterazioni possono includere l’implementazione di nuove tecnologie, per iniziare con le nuove tecniche, aggiungendo nuove strutture di dati , caricando i dati supplementari , o con l’espansione di analisi del vostro ambiente. Questo paragrafo è discusso più approfonditamente nel capitolo 3.

Oltre alle strutture tradizionali di Dw e strumenti di Bi ci sono altre funzioni della vostra organizzazione della BI per cui dovete progettare, come:

Punti di contatto del cliente(Customer touch points).

Come con tutta l’organizzazione moderna esiste un certo numero di punti di contatto del cliente che indicano come avere un esperienza positive per i vostri clienti. Ci sono i canali tradizionali quali i commercianti, i centralinisti, la posta diretta, multimedia e stampa pubblicitaria, così come i canali più attuali come email e web, i dati prodotti con qualche punto di contatto devono essere acquisiti, trasportati, puliti, trasformati ed poi popolati a strutture di dati della BI.

Basi di dati operative e associazioni di utenti (Operational

databases and user communities).
Alla fine dei punti di contatto dei clienti si trovano le basi di dati dell’applicazione della ditta e delle comunità di utenti. I dati esistenti sono dati tradizionali che devono essere riuniti e fusi con i dati che fluiscono dai punti di contatto per soddisfare le necessarie informazioni.

Analisti. (Analysts)

Il beneficiario principale dell’ambiente della BI è l’analista. È lui che trae beneficio dall’estrazione attuale di dati operativi , integrati con diverse fonti di dati , aumentate con caratteristiche quale analisi geografiche (geocoding) e presentato in tecnologie di BI che permettono di estrarre, OLAP, avanzati reporting di SQL e analisi geografiche. L’interfaccia primaria per l’analista per l’ambiente di reporting è il portal della BI.

Tuttavia, l’analista non è l’unico a beneficiare dall’architettura della BI.
Dirigenti, vaste associazioni di utenti, e perfino i soci, i fornitori ed i clienti dovrebbero trovare dei benefici nella BI di impresa.

Back-feed loop.

L’architettura della BI è un ambiente di apprendimento. Un principio caratteristico dello sviluppo è permettere persistenti strutture di dati da aggiornare mediante tecnologia della BI usata e mediante azioni intrapese dell’utente. Un esempio è la valutazione del cliente(customer scoring).

Se il reparto di vendita effettua un modello estraente (mining model) dello scores del cliente come per usare un nuovo servizio, allora il reparto di vendita non dovrebbe essere l’unico gruppo beneficiario del servizio.

Invece, il modello estraente dovrebbe essere effettuato come parte naturale del data flow dentro l’impresa e lo scores del cliente dovrebbe diventare una parte integrata del contesto informativo del magazzino, visibile a tutti gli utenti. La Suite dell’IBM di Bi-bI-centric compreso DB2 UDB, DB2 OLAP Server comprende la maggior parte dei componenti importanti di tecnologia, definita nella figura 1.1.

Noi usiamo l’architettura come appare in questa figura del libro per darci un livello di continuità e dimostrare come ogni prodotto dell’IBM si adattano allo schema generale della BI.

Fornire Il Contenuto Informativo(Providing Information Content)

Progettare, sviluppare ed implementare il vostro ambiente di BI è un’operazione ardua. La progettazione deve abbracciare tanto gli attuali che i futuri requisiti di business. Il disegno dell’architettura deve essere completo per includere tutte le conclusioni trovate durante la fase di progettazione. L’esecuzione deve rimanere impegnata per un singolo scopo: sviluppare l’architettura della BI come presentata formalmente nel disegno e fondata sui requisiti di business.

È particolarmente difficile sostenere che la disciplina assicurerà il relativo successo.
Ciò è semplice perché non si sviluppa un ambiente della BI tutto d’un tratto, ma si effettua in piccoli passi col tempo.

Tuttavia, identificare i componenti della BI della vostra architettura è importante per due motivi: Guiderete tutte le successive decisioni tecniche di architettura.
Potrete progettare coscientemente un uso particolare di tecnologia anche se potreste non ottenere una ripetizione che ha bisogno della tecnologia per parecchi mesi.

Il capire sufficientemente i vostri requisiti di business influirà il tipo di prodotti che acquisirete per la vostra architettura.
La progettazione e lo sviluppo della vostra architettura assicurano che il vostro warehouse sia

non un evento aleatorio, ma piuttosto un “well-thought-out”, attentamente costruito ad opera d’arte come un mosaico di tecnologia mescolata.

Progettare il contenuto informativo

Tutta la progettazione iniziale deve mettere a fuoco e identificare i componenti principali della BI che saranno necessari all’ambiente generale in presente e in futuro.
Conoscere i requisiti di Business è importante.

Anche prima che tutta la progettazione convenzionale cominci, il pianificatore di progetto può spesso identificare uno o due componente subito.
L’equilibrio dei componenti che potrebbero essere necessari per la vostra architettura, tuttavia, non può essere trovato facilmente. Durante la fase di progettazione, la parte principale dell’architettura lega la sessione di sviluppo dell’applicazione (JAD) su una ricerca per identificare i requisiti di business.

A volte questi requisiti possono essere affidati a strumenti di interrogazioni e di reporting .
Per esempio, gli utenti dichiarano che se desiderano automatizzare attualmente un report devono generare manualmente integrando due rapporti attuali ed aggiungendo i calcoli derivati dalla combinazione dei dati.
Anche se questo requisito è semplice, definisce una certa funzionalità della caratteristica che voi dovete includere quando comprate strumenti di reporting per l’organizzazione.

Il progettista deve anche perseguire i requisiti supplementari per ottenere un’immagine completa. Gli utenti desiderano abbonarsi a questo report?
I sottoinsiemi del report sono generati e spediti via email ai vari utenti? Desiderano vedere questo report nel portale aziendale? Tutti questi requisiti fanno parte della semplice necessità di sostituire un report manuale come richiesto dagli utenti. Il beneficio di questi tipi di requisiti è che ognuno, utenti ed i progettisti, hanno una conoscenza del concetto dei report.

Ci sono altri tipi di business , tuttavia, che dobbiamo programmare. Quando i requisiti di business sono dichiarati sotto forma di domande strategiche di Business, è facile per il progettista esperto discernere i requisiti di measure/fact e dimensionali.

Se gli utilizzatori di JAD non sanno come dichiarare i loro requisiti sotto forma di un problema di business, il progettista fornirà spesso degli esempi per saltare-avviare la sessione della raccolta dei requisiti.
L’esperto progettista può aiutare gli utenti a capire non soltanto il commercio strategico, ma anche come formarlo.
L”approccio della raccolta dei requisiti è discussa nel capitolo 3; per ora desideriamo soltanto indicare la necessità di progettare per tutti i tipi di requisiti della BI.

Una problema strategico di Business è, non soltanto un requisito di Business, ma anche un indizio progettuale. Se dovete rispondere ad una domanda multidimensionale, allora dovete memorizzare, presentare i dati dimensionali, e se avete bisogno di memorizzare i dati multidimensionali, dovete decidere che tipo di tecnologia o tecnica state andando impiegare.

Implementate uno star schema a cubo riservato, o entrambi? Come potete vedere, persino un semplice problema di business può influenzare in modo considerevole la progettazione. Però questi tipi di requisiti di business sono ordinari e beninteso, almeno dai progettisti e dai pianificatori con esperienza di progetto.

C’è stato dibattito sufficiente sulle tecnologie e sul supporto di OLAP, ed è disponibile una vasta gamma di soluzioni. Finora abbiamo accennato la necessità di riunire semplici reporting con i requisiti dimensionali di busineness, e come questi requisiti influenzano decisioni tecniche di architettura.

Ma che cosa sono i requisiti che non sono prontamente compresi dagli utenti o dal team di Dw ? Avrete mai bisogno dell’analisi spaziale(analysisi spatial)?
I modelli estraenti di dati saranno una parte necessaria del vostro futuro? Chi sa?

È importante notare che queste tipo di tecnologie non sono molto conosciute dalle comunità di utenti generali e membri del team di Dw, in parte, questo potrebbe accadere perché loro tipicamente sono trattate da alcuni tecnici esperti interni o di terze parti. È un caso limite dei problemi che questi tipi di tecnologie generano. Se gli utenti non possono descrivere i requisiti di business o inquadrarli in modo da fornire le linee guida ai progettisti, queste possono passare inosservate o,peggio, ignorate semplicemente.

Più problematico diventa quando il progettista e lo sviluppatore non possono riconoscere l’applicazione di una di queste avanzate ma critiche tecnologie.
Come spesso abbiamo sentito i Progettisti dicono, “bene, perchè non lo mettiamo da parte fino a che non otteniamo qust’altra cosa? “Sono realmente interessati alle priorità, o semplicemente evitano i requisiti che non capiscono? È molto probabilmente l’ultima ipotesi. Diciamo che il vostro gruppo di vendita ha comunicato un requisito di affari ,come dichiarato nella figura 1.3, come potete vedere, il requisito è inquadrato sottoforma di un problema di business. La differenza fra questo problema e il tipico problema dimensionale è la distanza. In questo caso, il gruppo di vendita desidera conoscere, su una base mensile, le vendite totali dai prodotti, i magazzini e i clienti che vivono entro 5 miglia dal magazzino dove loro acquistano.

Tristemente, i progettisti o gli architetti possono semplicemente ignorare la componente spaziale dicendo, “abbiamo il cliente, il prodotto ed i dati del deposito. Teniamo fuori la distanza fino ad un’altra iterazione.

“Risposta sbagliata. Questo tipo di problema di business riguarda interamente la BI. Rappresenta una comprensione più profonda del nostro business e di un spazio analitico robusto per i nostri analisti. La BI è oltre l’interrogazione semplice o la segnalazione standard, o persino OLAP. Questo non vuol dire che queste tecnologie non sono importanti per la vostra BI,ma da solenon rappresentano l’ambiente della BI.

Progettare per il contesto di informazioni (Designing for Information Content)

Ora che abbiamo identificato i requisiti di Business che distinguono vari componenti fondamentali, si devono includere in un disegno architettonico generale. Alcuni dei componenti della BI fanno parte dei nostri sforzi iniziali, mentre alcuni non saranno implementati per parecchi mesi.

Tuttavia, tutti i requisiti conosciuti sono riflessi nel progetto cosi che quando dobbiamo implementare una tecnologia particolare, siamo preparati a farlo. Qualcosa del progetto rifletterà il pensiero tradizionale.

Questo insieme di dati è usato per sostenere gli usi successivi di dati dimensionali guidati dalle problematiche di Business che abbiamo identificato. Poichè i documenti supplementari sono generati, come ad esempio lo sviluppo progettuale dei dati, noi inizieremo a formalizzare come i dati si propagano nell’ambiente. Abbiamo accertato la necessità di rappresentare i dati in modo dimensionale, suddividendoli (secondo delle esigenze specifiche determinate) in data marts.

La prossima domanda a cui rispondere è: come saranno costruiti questi data marts?
Costruite le stelle per sostenere i cubi, o solo cubi, o solo le stelle? (o cubi giusti, o stelle giuste). Generate l’architettura per i data marts dipendenti che richiedono uno strato atomico per tutti i dati aquisiti? Permettete ai data marts indipendenti acquisire i dati direttamente dai sistemi operativi?

Che Tecnologia di cubi proverete a standardizzare?

Avete quantità voluminose dei dati richiesti per analisi dimensionale o avete bisogno dei cubi della vostra forza vendite nazionale su una base settimanale o su entrambe? Costruite un oggetto potente come DB2 OLAP Server per la finanza o i cubi di Cognos PowerPlay per la vostra organizzazione di vendite o entrambe? Queste sono le grandi decisioni architettoniche di disegno che avranno effetto sul vostro ambiente della BI da qui in avanti. Sì, avete accertato una necessità di OLAP. Ora come effettuerete quel tipo di tecnica e tecnologia?

Come alcune delle tecnologie più avanzate interessano i vostri disegni? Presupponiamo che avete accertato una necessità spaziale nella vostra organizzazione. Ora dovete richiamare le edizioni architettoniche di disegno anche se non pianificate di effettuare componenti spaziali per parecchi mesi. L’architetto deve progettare oggi basandosi su ciò che serve. Prevedere l’esigenza di analisi spaziale che genera, memorizza, effettua e fornisce l’accesso ai dati spaziali. Ciò a sua volta dovrebbe servire da vincolo per quanto riguarda il tipo di specifiche di tecnologia e di piattaforma del software potete attualmente considerare. Per esempio, il sistema di amministrazione della base di dati relazionale (RDBMS) che effettuate per il vostro strato atomico deve avere un’estensione spaziale robusta disponibile. Ciò accerterebbe le prestazioni massime quando usate la geometria e gli oggetti spaziali nelle vostre applicazioni analitiche. Se il vostro RDBMS non può maneggiare i dati (spazial-centric) internamente, quindi dovrete stabilire una base di dati (spaziale-centric) esterna. Ciò complica la gestione delle edizioni e compromette le vostre prestazioni generali, per non accennare i problemi supplementari generati per il vostro DBAs, poiché probabilmente hanno una minima comprensione delle basi di dati spaziali pure. D’altra parte, se il vostro motore di RDMBS maneggia tutti i componenti spaziali ed il relativo ottimizzatore è informato dei bisogni speciali (per esempio, indexing) degli oggetti spaziali, allora il vostro DBAs può trattare prontamente la gestione delle edizioni e potete elevare le prestazioni.

Inoltre, dovete regolare la staging area (area di scena) e lo strato d’ambiente atomico per includere la pulizia degli indirizzi (un

elemento chiave ad analisi spaziale), così come il successivo salvataggio degli oggetti spaziali. Il susseguirsi delle edizioni di disegno continua ora che abbiamo introdotto la nozione di pulizia di indirizzo. Per una cosa, questa applicazione detterà il tipo di software necessario per il vostro sforzo di ETL.

Avete bisogno dei prodotti come Trillium per fornirgli un indirizzo pulito, o di un fornitore di ETL da voi prescelto per fornire quella funzionalità?
Per ora esso è importante che apprezzate il livello del disegno che deve essere completato prima che cominciate ad effettuare il vostro ambiente (warehouse). Gli esempi precedenti dovrebbero dimostrare la moltitudine di decisioni di disegno che devono seguire l’identificazione di tutto il requisito particolare di affari. Se fatte correttamente, queste decisioni di disegno promuovono l’interdipendenza fra le strutture fisiche del vostro ambiente, la selezione di tecnologia usata ed il flusso di propagazione del soddisfare di informazioni. Senza questa architettura convenzionale della BI, la vostra organizzazione sarà soggetta ad una miscela caotica di tecnologie esistenti, nel migliore dei casi, unite in modo non preciso per fornire una stabilità apparente.

Effettuare il soddisfare di informazioni

Portando il valore delle informazioni alla vostra organizzazione è un’operazione molto difficile. Senza una sufficiente comprensione ed esperienza, o progettazione e disegno adeguati, persino le squadre migliori fallirebbero. D’altra parte, se avete una grande intuizione e una progettazione dettagliata ma nessuna disciplina per l’esecuzione, avete appena sprecato i vostri soldi e il vostro tempo perché il vostro sforzo è destinato a fallire. Il messaggio dovrebbe essere chiaro: Se state mancando di una o più di queste competenze, comprensione/esperienza o progettazione/disegno o disciplina di implementazione,questo porterà a paralizzare o distruggere la costruzione dell’organizzazione della BI.

La vostra squadra sufficiente preparata? C’è qualcuno sulla vostra squadra della BI che capisce il vasto paesaggio analitico disponibile negli ambienti della BI, nelle tecniche e nelle tecnologie necessarie per effettuare quel paesaggio? C’è qualcuno sulla vostra squadra che può riconoscere la differenza di applicazione fra advanced

static reporting e OLAP,o le differenze fra ROLAP e OLAP? Uno dei membri della vostra squadra riconosce chiaramente il modo di estrarre e come esso potrebbe avere effetto sul warehouse o come il warehouse può sostenere le prestazioni estraenti? Un membro della squadra capisce il valore dei dati spaziali o la tecnologia basata su agenti? Avete qualcuno che apprezzi l’applicazione unica degli attrezzi di ETL contro tecnologia del mediatore del messaggio? Se non l’avete, ottenetene uno. La BI è molto più grande di uno strato atomico normalizzato, di OLAP, degli schemi a stella e di un ODS.

Avere la comprensione e l’esperienza per riconoscere i requisiti della BI e le loro soluzioni è essenziale alla vostra capacità di formalizzare correttamente le esigenze degli utenti e di progettare ed effettuare le loro soluzioni. Se la vostra comunità di utenza ha difficoltà a descrivere i requisiti, è compito della squadra di warehouse fornire quella comprensione. Ma se la squadra di warehouse

non riconoscel’applicazione specifica della BI -per l’esempio, data mining- allora non è la cosa migliore che gli ambienti della BI si limitino spesso ad essere depositi passivi. Tuttavia, ignorare queste tecnologie non diminuisce la loro importanza e l’ effetto che hanno sulla nascita di possibilità di business intelligence della vostra organizzazione, come pure l’assetto informativo che progettate promuovere.

La progettazione deve comprendere la nozione del disegno, ed entrambi richiedono un individuo competente. In più, il progettare richiede una filosofia di werehouse di squadra e l’osservazione degli standards. Per esempio, se la vostra azienda ha stabilito una piattaforma standard o ha identificato un RDBMS particolare che si desidera standardizzare per tutta la piattaforma, è incombente che sulla squadra tutti aderiscano a quegli standard. Generalmente una squadra espone l’esigenza della normalizzazione (to user communites), ma la squadra in se è poco disposta a aderire agli standard stabiliti anche in altre aree nell’azienda o forse anche nelle società simili. Non solo questo è iporcrita, ma accerta l’impresa non è capace di sfruttare le risorse e investimenti esistenti. Non significa che non esistono situazioni che garantiscono una piattaforma o una tecnologia non standardizzata; tuttavia, gli sforzi del warehouse

dovrebbero proteggere gelosamente gli standard dell’impresa fino a che i requisiti di business non dettino il contrario.

Il terzo componente chiave necessario per costruire una BI organization è la disciplina.
Dipende in totale, in uguale misura dagli individui e dall’ambiente. Project planners, sponsor, architetti, e utenti devono apprezzare la disciplina necessaria a costruire l’assetto informativo della società. I progettisti devono dirigere i loro sforzi di progetto in modo tale da completare altri sforzi necessari nella società.

Per esempio, supponiamo che la vostra società costruisca un applicazione ERP che ha un componente warehouse.
Quindi è la responsabilità dei progettisti ERP di collaborare con il team dell’ambiente di warehouse in modo da non competere o duplicare i lavori gia in iniziati.

La disciplina è anche un argomento che deve essere occupato dall’intera organizzazione ed è di solito stabilita e affidata a un livello esecutivo.
I dirigenti sono disposti ad aderire ad un approccio progettato? Un approccio che promette di creare contenuti di informazioni che alla fine porterà valore a tutte le aree dell’impresa, ma forse compromette singoli o departmental agendas? Ricordati il detto “Pensare a tutto è più importante di pensare a un’unica cosa”. Questo detto è vero per le organizzazioni BI.

Sfortunatamente molte warehouse concentrano i loro sforzi cercando di indirizzare e portare valore a un particolare reparto o a utenti specifici, con un piccolo riguardo all’organizzazione in generale. Supponete che il dirigente richieda assistenza al team di werehouse. Il team risponde con un lavoro durato 90 giorni che include non solo la consegna dei requisiti di notifica definiti dal dirigente ma assicura che tutti i dati base siano mischiati nel livello atomico prima di essere introdotto nella tecnologia di cubo proposta.
Questa aggiunta ingegneristica assicura che l’impresa di werehouse trarrà benefici dai dati necessari al dirigente.
Tuttavia, il dirigente ha parlato con ditte di consulenza esterne che hanno proposto una simile applicazione con consegna in meno di 4 settimane.

Assumendo che il team interno di werehouse sia competente, lo il dirigente ha una scelta. Chi può supportare la disciplina di ingegneria supplementare necessaria per coltivare il bene informativo impresa o può scegliere di realizzare la propria soluzione velocemente. L’ultimo sembra essere scelto veramente troppo spesso e serve solo per creare contenitori di informazioni di cui ne beneficiano in pochi o il singolo.

Obiettivi a Breve e Lunga scadenza

Gli architetti e i progettisti di progetto devono formalizzare una visione a lunga scadenza dell’architettura generale e piani per crescere in un’organizzazione BI. Questa combinazione di guadagno a breve scadenza e pianificazione a lunga scadenza rappresentano le due facce di sforzi BI. Il guadagno a breve scadenza è la sfaccettatura di BI che è associata a iterazioni del vostro warehouse.

È qui dove progettisti, architetti e sponsor si concentrano su soddisfare requisiti commerciali specifici. È a questo livello dove le strutture fisiche sono costruite, la tecnologia è acquistata e le tecniche sono implementate. Sono affatto fatte per affrontare requisiti specifici come definiti da particolare utente le comunità. Tutto è svolto in con lo scopo di affrontare requisiti specifici definiti da una particolare comunità.
La pianificazione a lunga scadenza, tuttavia, è l’altra sfaccettatura di BI. È qui in cui i piani e i progetti hanno assicurato che fosse costruita una qualsiasi struttura fisica, le tecnologie selezionate e le tecniche realizzate fatte con un occhio verso l’impresa. È la pianificazione a lunga scadenza che fornisce la coesione necessaria per assicurare che i vantaggi di impresa derivino da tutti i guadagni a breve scadenza trovati.

Giustificare il vostro sforzo di BI

Un data warehouse da solo non ha nessun valore inerente. In altre parole, non c’è nessun valore inerente tra le tecnologie di warehouse e le tecniche implementative.

Il valore di qualsiasi sforzo di warehouse è trovato nelle azioni eseguite a seguito dell’ambiente di warehouse e del contenuto informativo coltivato nel tempo. Questo è un punto critico da capire prima che tentiate mai di stimare il valore di qualsiasi iniziativa di wherehouse.

Troppo spesso, architetti e progettisti tentano di applicare valore ai componenti fisici e tecnici di warehouse quando infatti il valore si fonda con i processi commerciali che sono incisi positivamente dal warehouse e dalle informazioni bene acquisite.

Qui giace la sfida per fondare la BI: Come giustifichi l’investimento? Se la stessa wherehouse non ha un valore intrinseco, i progettisti di progetto devono indagare, definire e formalizzare i vantaggi conseguiti da quegli individui che utilizzeranno il warehouse per migliorare processi commerciali specifici o il valore delle informazioni protette o entrambi.

Per complicare argomenti, qualsiasi processo commerciale interessato da sforzi di magazzino potrebbe fornire vantaggi “considerevoli” o “lievi”. I vantaggi considerevoli forniscono una metrica tangibile per misurare il ritorno dell’investimento (ROI) – ad esempio, girare l’inventario un tempo aggiuntivo durante un periodo specifico o per costo minore di trasporto per spedizione. È più difficile definire i lievi vantaggi, come l’ accesso migliorato alle informazioni , in termini di valore tangibile.

Collegare il vostro progetto per conoscere le richieste di Business

Troppo spesso, i progettisti di progetto tentano di collegare il valore della warehouse con obiettivi amorfi dell’impresa. Dichiarando che “il valore dei una warehouse è basato sulla nostra capacità di soddisfare richieste strategiche” apriamo in modo gradevole il discorso. Ma da solo non è sufficiente per determinare se l’investimento nel magazzino ha senso. È miglio collegare ripetizioni di warehouse con richieste commerciali specifiche e note.

Misurare il ROI

Calcolare ROI in un’impostazione di warehouse può essere particolarmente difficile. È particolarmente difficile se il vantaggio

principale di una particolare ripetizione è qualcosa di non tangibile o facile da misurare. Uno studio ha trovato che gli utenti percepiscono i due principali vantaggi delle iniziative della BI:

• ▪  Creare l’abilità per creare decisioni
• ▪  Creare l’acceso alle informazioni
  Questi vantaggi sono vantaggi morbidi (o lievi). È facile vedere come possiamo calcolare un ROI basato su un vantaggio duro (o maggiore) tipo la riduzione del costo del trasporto, ma come misuriamo la capacità di prendere decisioni migliori?
  Questa è sicuramente una sfida per progettisti di progetto quando stanno tentando di convincere la società a investire in un particolare sforzo di warehouse. Le vendite crescenti o i costi che diminuiscono non sono più i temi centrali che guidano l’ambiente BI.
  Invece, state cercando nelle richieste di business un accesso migliore alle informazioni in modo che un particolare reparto possa prendere decisioni più veloci. Questi sono conducenti strategici a cui capita di essere ugualmente importante per l’impresa ma sono più ambigui e più difficili da caratterizzare in una metrica tangibile. In questo caso, calcolare ROI può ingannare, se non irrilevante.
  I progettisti di progetto devono essere in grado di dimostrare valore tangibile perché i dirigenti possano decidere se l’investimento in una particolare ripetizione vale. Tuttavia, non proporremo un nuovo metodo per il calcolo di ROI, né faremo qualche argomento pro o contro esso.
  Sono disponibili molti articoli e libri che discutono i fondamenti per calcolare ROI. Ci sono delle special value propositions come valore sull’investimento (VOI), offerto da gruppi come Gartner, che potete ricercare. Invece, ci concentreremo su aspetti di nucleo di qualsiasi ROI o altre proposizioni di valore che dovete considerare. Applicando ROI Oltre all’argomento sui benefici “duri” contro i benefici “leggeri” associati agli sforzi di BI là ci sono altri problemi da considerare quando applichiamo ROI. Per esempio:

Attribuire troppi risparmi agli sforzi del DW che verrebbero comunque
Diciamo che la vostra società passava da un’architettura di mainframe a un ambiente distribuito UNIX. Quindi qualsiasi risparmio che può (o non può) essere realizzato da quello sforzo non dovrebbe essere attribuito esclusivamente, se a tutto (?), al warehouse.

Non rendere conto di tutto costa. E ce ne sono molte di cose da tener conto. Considerate la seguente lista:

• ▪  Costo dell’avvio, tra cui la fattibilità.
• ▪  Costo di hardware dedicato con relativo storage e comunicazioni
• ▪  Costo del software, tra cui gestione dei dati ed estensioni client/server, software ETL, tecnologie DSS, strumenti di visualizzazione, applicazioni di programmazione e di flusso di lavoro e software di monitoraggio, .
• ▪  Costo di progettazione di struttura dati, con la realizzazione, e l’ottimizzazione di
• ▪  Costo di sviluppo software direttamente associato allo sforzo BI
• ▪  Costo di supporto a domicilio, compreso ottimizzazione di prestazioni, compreso controllo di versione software e operazioni di help Applicare “Big-Bang” ROI. La realizzazione della warehouse come sforzo singolo e gigantesco è destinato a non riuscire, così anche calcola il ROI per un’iniziativa di larga impresa L’offerta è sorprendere, e che i progettisti continuino a fare tentativi deboli per stimare il valore dell’intero sforzo. Perché i progettisti cercano di dare un valore monetario sull’iniziativa di impresa se è ampiamente saputo e accettato che stimare ripetizioni specifiche è difficile? Come è possibile? Non è possibile con poche eccezzioni. Non fatelo. Ora che abbiamo stabilito che cosa non fare quando calcoliamo ROI, ci sono qui alcuni punti che ci aiuteranno nella definizione di un processo affidabile per stimare il valore dei vostri sforzi BI.

Ottenimento del consenso di ROI. Indipendentemente dalla vostra scelta di tecnica per stimare il valore dei vostri sforzi BI, deve essere concordata da tutte le parti, incluso i progettisti di progetto, gli sponsor e i dirigenti aziendali.

Riducete ROI in parti identificabili. Un passo necessario verso in ragionevole calcolo di un ROI è concentrare quel calcolo su un progetto specifico. Questo quindi vi permette di stimare un valore basato su requisiti commerciali specifici che vengono soddisfatti

Definite i costi. Come citati, numerosi costi devono essere considerati. Inoltre, i costi devono includere non solo quelli associati alla singola iterazione ma anche ai costi di associati all’assicurazione di conformità agli standard di impresa..

Definite vantaggi. Collegando chiaramente il ROI a requisiti commerciali specifici, dovremmo essere in grado di identificare i vantaggi che porteranno a soddisfare i requisiti.

Riducete i costi e i vantaggi in guadagni imminenti. È il modo migliore per basare le vostre valutazioni sul valore attuale netto (NPV) diversamente dal tentativo di predire valore futuro in guadagni futuri.

Tenete al minimo la tempistica di suddivisione del vostro ROI. E’ ben documentato nel lungo periodo in cui è stato usato nel vostro ROI.

Utilizzate più di una formula ROI. Ci sono numerosi metodi per la previsione del ROI e voi dovreste pianificare se utilizzarne uno o più, compreso il valore attuale netto, la velocità interna del ritorno (IRR) e il recupero.

Definire il processo ripetibile. Questo è determinante per calcolare ogni valore a lunga scadenza. Dovrebbe essere documentato un singolo processo ripetibile per tutte le sottosequenze di progetto a seguire.

I problemi elencati sono quelli più comuni definiti da esperti dell’ambiente di werehouse. L’insistenza da parte della gestione di far fornire un “Big-Bang” ROI disorienta parecchio. Se avviate tutti i vostri calcoli ROI riducendoli in parti identificabili e tangibili, avete una buona possibilità stimare una valutazione precisa ROI.

Domande riguardo ai benefici del ROI

Qualunque sono i vostri benefici, morbidi o duri, voi potete utilizzare alcune domande fondamentali per determinare il loro valore. Ad esempio utilizzando un sistema di scala semplice, da 1 a 10, voi potete rilevare l’impatto di qualsiasi sforzo utilizzando le seguenti domande:

• Come valutereste la comprensione dei dati a seguito di questo progetto della vostra società?
• Come stimereste i miglioramenti di processo a seguito di questo progetto?
• Come misurereste l’impatto di nuove intuizioni e inferenze ora rese disponibili da questa iterazione
• Quale è stato l’impatto di ambienti di computer nuovi e performanti a seguito di quello che si era imparato? Se le risposte a queste domande sono poche, è possibile che l’impresa non valga l’investimento fatto. Le domande con un alto punteggio puntano a guadagni di valore significativi e dovrebbero servire come guide per ulteriore indagine. Ad esempio, un alto punteggio per miglioramenti di processo dovrebbe portare i progettisti a esaminare come i processi sono stati migliorati. Potete trovare che alcuni o tutti i guadagni ottenuti sono tangibili e quindi un valore monetario può essere prontamente applicato. Ottenere il massimo dalla prima iterazione del warehouse Il risultato più grande del vostro sforzo di impresa è spesso nelle prime poche iterazioni. Questi primi sforzi tradizionalmente stabiliscono il più utile contenuto informativo per il pubblico e stabilisce l’aiuto alla fondazione di tecnologia per le successive applicazioni della BI. Di solito ogni successiva sottosequenza di dati di progetto di warehouse portano sempre meno valore aggiuntivo all’impresa in generale. Questo è particolarmente vero se l’iterazione non aggiunge nuovi argomenti o non soddisfa le necessità di una nuova comunità di utenti.

Questa caratteristica di immagazzinare si applica anche alle pile crescenti di dati storici. Come gli sforzi successivi richiedono più dati e come più dati sono versati nel warehouse nel tempo, il più dei dati diventa meno attinente all’analisi utilizzata. Questi dati sono spesso chiamati dati assopiti ed è sempre costoso tenerli perché non vengono quasi mai utilizzati.

Cosa significa questo per gli sponsor di progetto? Essenzialmente, i primi sponsor condividono di più di quanto costa l’investimento. Questo è primario perché essi sono l’impeto per fondare lo strato di largo ambiente tecnologico e delle risorse del warehouse, compreso organico.

Ma questi primi passi portano il valore più alto e quindi i progettisti di progetto devono spesso giustificare l’investimento.
I progetti fatti dopo la vostra iniziativa BI possono avere costi inferiori ( comparati con la prima) e diretti, ma portano meno valore all’impresa.

E proprietari dell’organizzazione devono iniziare a considerare buttare l’accumulo di dati e di tecnologie meno rilevanti.

Data Mining : Estrazione Dati

Numerosi componenti architettonici richiedono variazioni di tecnologie e tecniche di data mining—
per esempio, i diversi “agenti” per l’esame dei punti di interesse del clienti, i sistemi operativi dell’azienda e per lo stesso dw. Questi agenti possono essere reti neurali avanzate addestrate alle tendenze del POT, quale la richiesta futura del prodotto basata sulle promozioni di vendite; motori basati sulle regole (rules-based) per reagire a un insieme dato di circostanze, ad esempio, diagnosi medica e raccomandazioni di trattamento; o persino agenti semplici col ruolo di riportare le eccezioni ai dirigenti superiori (top executives). Generalmente questi processi di estrazione dati si

verificano in tempo reale; quindi, essi devono essere uniti completamente con il movimento dei dati stessi.

Online Analytic Processing Elaborazione

Analitica Online

La capacità di affettare, spezzettare, arrotolare, trapanare giù (drill- down) ed effettuare l’analisi
cosa-se, è all’interno dell’ambito, dell’obiettivo della suite tecnologica IBM. Ad esempio, le funzioni di trattamento analitico online (OLAP) esistono per DB2 che porta l’analisi dimensionale nel motore del database stesso .

Le funzioni aggiungono l’utilità dimensionale a SQL mentre sfruttano tutti i benefici di essere una parte naturale di DB2. Un altro esempio di integrazione di OLAP è lo strumento di estrazione, DB2 OLAP Analizzatore Server. Questa tecnologia permette ai cubi del Server DB2 OLAP di essere rapidamente e automaticamente analizzati per individuare e riferire su valori dei dati insoliti o inattesi per tutto il cubo all’analista commerciale. E, infine, le funzioni del Centro di DW forniscono mezzi perché architetti controllino, tra le altre cose, il profilo di un cubo server DB2 OLAP come una parte naturale dei processi ETL.

Spatial Analysis Analisi Spaziale

Lo spazio rappresenta la metà delle ancore (conduzioni) analitiche necessarie per un panorama
analitico largo (il tempo rappresenta l’altra metà). Il livello atomico (atomic-level ) del magazzino, rappresentato nella Figura 1.1, include i fondamenti sia per tempo che per spazio. Le registrazioni dell’ora ancorano analisi per tempo e informazioni di indirizzo ancorano analisi da spazio. Le marcatura orarie (Timestamps) conducono l’analisi per tempo, e l’informazione di indirizzo conduce l’analisi per spazio. Il diagramma mostra geocoding–processo di conversione indirizzi a punti in una mappa o punti nello spazio cosicché i concetti come distanza e interno/esterno possano essere utilizzati nell’analisi–condotto a livello atomico e l’analisi spaziale che è messa a disposizione dell’analista. IBM fornisce estensioni spaziali, sviluppati con l’Istituto Ricerca Sistema Ambientale (ESRI), al database DB2 in modo che gli oggetti spaziali possano essere conservati come una parte normale del database relazionale. DB2

Spatial Extenders, forniscono anche tutte le estensioni SQL per sfruttare l’analisi spaziale. Ad esempio, le estensioni SQL da interrogare sulla
distanza fra indirizzi o se un punto è interno o esterno ad un’area poligonale definita, sono uno standard analitico con il Spatial Extender. Consultate il capitolo 16 per ulteriori informazioni.

Database-Resident Tools Strumenti Database-Resident

DB2 ha molte caratteristiche SQL BI-resident che assistono nell’azione di analisi. Questi includono:

• Le funzioni di ricorsione per eseguire analisi, come “trovare tutti i possibili percorsi di volo da San Francisco a New York”.
• Le funzioni analitiche per il ranking, funzioni cumulative, cubo e rollup per agevolare i compiti che normalmente si verificano solo con la tecnologia OLAP, sono ora una parte naturale del motore del database
• La capacità di creare tabelle che contengano risultati
  I venditori di database leader mischiano di più delle funzionalità BI nel database stesso.
  I fornitori principali della base di dati stanno mescolando più delle funzionalità della BI nel database stesso.
  Ciò fornisce le prestazioni migliori e più opzioni di esecuzione per le soluzioni della BI.
  Le caratteristiche e le funzioni di DB2 V8 sono discusse dettagliatamente nei seguenti capitoli:
  Technical Architecture and Data Management Foundations (Chapter 5)

• DB2 Fondamenti della BI (BI Fundamentals) (Chapter 6)
• DB2 Tabelle di query materializzate (Materialized Query Tables) (Chapter 7)
• DB2 Funzioni OLAP (OLAP Functions) (Chapter 13)
• DB2 Caratteristiche e funzioni potenziate di BI (Enhanced BI Features and Functions) (Chapter 15) Simplified Data Delivery System Sistema di consegna di dati semplificato

L’architettura rappresentata nella figura 1.1 include numerose strutture dati fisiche. Uno è il magazzino di dati operativo. Generalmente, un ODS è un oggetto orientato (subject oriented), integrato e corrente. Costruireste un ODS per sostenere, ad esempio, l’ufficio vendite. Le vendite ODS integrerebbero dati provenienti da numerosi sistemi diversi ma manterrebbe solo, ad esempio, le transazioni di oggi. L’ODS può essere aggiornato anche molte volte al giorno. Contemporaneamente, i processi spingono i dati integrati in altre applicazioni. Questa struttura è progettata specificatamente per integrare dati correnti e dinamici e sarebbe un candidato probabile a sostenere analisi in tempo reale, come fornire ad agenti di servizio clienti le informazioni di vendite correnti di un cliente estraendo informazioni di tendenza di vendite dal magazzino stesso. Un’altra struttura mostrata nella figura 1.1 è uno stato formale per il dw. Non solo questo è il luogo per l’esecuzione della necessaria integrazione, della qualità di dati, e della trasformazione dei dati di magazzino in arrivo, ma è anche un’area di deposito affidabile e provvisoria per dati replicati che potrebbero essere utilizzati in analisi in tempo reale. Se decidete di utilizzare un ODS o una zona di organizzazione (staging area), uno dei migliori strumenti per popolare queste strutture dati utilizzando diverse sorgenti operative è la query distribuita eterogenea di DB2. Questa capacità è consegnata dalla caratteristica opzionale di DB2 chiamata DB2 Relational Connect (solo query) e attraverso DB2 DataJoiner (un prodotto separato che consegna la domanda, l’inserto, l’aggiornamento e la possibilità di cancellazione a RDBMSs distribuito eterogeneo).

Questa tecnologia permette ad architetti di dati di legare dati di produzione con processi analitici. Non solo può la tecnologia adattarsi virtualmente a una qualunque delle richieste di replica che potrebbero presentarsi con l’analisi in tempo reale, ma esso possono anche collegare ad un’ampia varietà delle basi di dati più popolari, compreso DB2, Oracle, Sybase, assistente di SQL, Informix ed altri. DB2 DataJoiner può essere utilizzato per popolare una struttura dati formale come un ODS o anche una tabella permanente rappresentata nel magazzino progettata per ripristino rapido di aggiornamenti istantanei o per vendita. Naturalmente, queste stesse strutture dati possono essere popolate utilizzando

un’altra tecnologia importante progettata per replica di dati, IBM DataPropagator Relational. (DataPropagator è un prodotto separato per sistemi centrali. DB2 UNIX, Linux, Windows e OS/2 includono servizi di replica di dati come una caratteristica standard).
Un altro metodo per lo spostamento di dati operativi intorno all’impresa è un integratore di applicazione di impresa altrimenti noto come message broker(mediatore del messaggio).Questa tecnologia unica permette controllo impareggiabile per centrare (targeting) e spostare dati intorno all’impresa. IBM ha il mediatore del messaggio più ampiamente usato, MQSeries, o una variazione del prodotto che comprende i requisiti di e-commerce, IBM WebSphere MQ.
Per più discussione su come sfruttare MQ per sostenere un magazzino e un ambiente BI, visitare sito Web del libro. Per ora, è sufficiente dire che questa tecnologia è un mezzo eccellente per catturare e trasformare (utilizzando MQSeries Integrator) dati operativi centrati (targeted) reclutati per soluzioni della BI. La tecnologia MQ è stata integrata e impacchettata in UDB V8, il che significa che le code dei messaggi possono ora essere gestite come se esse fossero tabelle DB2. Il concetto di saldatura dei messaggi in coda e dell’universo di database relazionale si dirige verso un ambiente potente di consegna di dati.

Zero-Latency Latenza nulla

L’obiettivo strategico finale per IBM è analisi di latenza nulla (zero- latency). Come definito da
Gartner, un sistema BI deve essere in grado di dedurre, assimilare e fornire informazioni per analisti su richiesta. La sfida, naturalmente, sta nel come mescolare dati correnti e in tempo reale con informazioni storiche necessarie, quali i dati relativi modello/di tendenza, o la comprensione estratta, come delineamento del cliente.

Tali informazioni includono, ad esempio, l’identificazione di clienti ad alto o basso rischio o quali prodotti i clienti acquisteranno molto probabilmente se essi hanno già del formaggio nei loro carrelli di acquisti.

Ottenere latenza nulla è effettivamente dipendente da due meccanismi fondamentali:

• Unione completa dei dati che vengono analizzati con le tecniche stabilite e con gli strumenti realizzati dalla BI
• Un sistema di consegna di dati efficiente per assicurare che l’analisi in tempo reale sia realmente disponibile Questi prerequisiti per latenza nulla non sono differenti dai due obiettivi stabiliti da IBM e descritti precedentemente. L’accoppiamento stretto dei dati fa parte del programma di integrazione senza cuciture disposto dalla IBM. E creare un sistema di consegna di dati efficiente è completamente dipendente dalla tecnologia disponibile che semplifica il processo di consegna di dati. Di conseguenza, due dei tre obiettivi di IBM sono fondamentali a realizzare il terzo. IBM sta sviluppando coscientemente la sua tecnologia per assicurare che la latenza nulla sia una realtà per gli sforzi del magazzino. Summary / Sintesi L’organizzazione della BI fornisce una mappa di strada per realizzare il vostro ambiente
  iterativamente. Deve essere regolato per riflettere le necessità dei vostri affari, sia attuali che futuri. Senza una visione architettonica larga, le ripetizioni di magazzino sono poco più che delle implementazioni casuali del magazzino centrale che fanno poco per creare un’impresa larga, informativa. Il primo ostacolo per i responsabili di progetto è come giustificare gli investimenti necessari per lo sviluppo dell’organizzazione della BI. Benché il calcolo del ROI sia rimasto un sostegno principale per realizzazioni di magazzino, esso sta diventando più difficile da predire esattamente. Questo ha condotto ad altri metodi per la determinazione se state ottenendo il valore del vostro denaro. Il valore sull’ investmento2 (VOI), ad esempio, viene procacciato come una soluzione. È incombente sugli architetti di dati e sui pianificatori di progetto generare e fornire deliberatamente informazioni alle associazioni di utenti e non dare semplicemente un servizio sui dati. C’è una differenza enorme fra i due. L’informazione è qualcosa che fa una differenza nei processi decisionali e nell’efficacia; relativamente, i dati sono blocchetti di costruzione per derivare quelle informazioni.

Anche se critico alla sorgente dati per indirizzare richieste commerciali, l’ambiente BI dovrebbero servire un ruolo più grande nella creazione di contenuto delle informazioni. Dobbiamo prendere le misure supplementari per pulire, integrare, trasformare o diversamente creare un contenuto di informazioni secondo cui gli utenti possano agire, e quindi dobbiamo assicurarci che quelle azioni e quelle decisioni, dove ragionevole, abbiano un riscontro nell’ambiente BI. Se releghiamo il magazzino a servire solo su dati, è assicurato che le associazioni di utenti creeranno il contenuto delle informazioni necessarie per agire. Questo assicura che la loro comunità sarà in grado di prendere decisioni migliori, ma l’impresa soffre della mancanza di conoscenza che essi hanno utilizzato. Dato che gli architetti e i pianificatori di progetto iniziano i progetti specifici nell’ambiente BI, essi rimangono responsabili all’impresa nell’insieme. Un esempio semplice di questa caratteristica a due facce delle iterazioni della BI è trovato nella sorgente dati. Tutti i dati ricevuti per richieste commerciali specifiche devono essere popolati nel primo strato atomico. Questo garantisce lo sviluppo del bene di informazioni aziendale, così come gestire, indirizzare le richieste specifiche di utente definite nella iterazione.

WhatisaDataWarehouse?

Data warehouse è il cuore dell’architettura dei sistemi informative dal 1990 e supporta i processi informativi offrendo una solida piattaforma integrata di dati storici presi come base per successive analisi. I data warehouse offrono la facilità di integrazione in un mondo di sistemi applicativi non compatibili tra loro. Data warehouse si è evoluto fino a diventare una moda. Data warehouse organizza e memorizza i dati necessari per processi informativi e analitici sulla base di una lunga prospettiva storica temporale. Tutto ciò comporta un notevole e costante impegno nella costruzione e nel mantenimento del data warehouse.

Cos’è quindi un data warehouse? Un data warehouse è:

• ▪  orientato ai soggetti
• ▪  sistema integrato
• ▪  tempo variante
• ▪  non volatile ( non si cancella )

una collezione di dati usati in supporto a decisioni manageriali nella realizzazione dei processi.
I dati inseriti nel data warehouse derivano nella maggior parte dei casi da ambienti operazionali. Il data warehouse è realizzato da una unità di memorizzazione, fisicamente separata dal resto del sistema, che contiene dati precedentemente trasformati dalle applicazioni che operano sulle informazioni derivanti dall’ambiente operativo.

La definizione letterale di un data warehouse merita un’approfondita spiegazione poichè esistono importanti motivazioni e significati di fondo che descrivono le caratteristiche di una warehouse.

SUBJECT ORIENTATION ORIENTAMENTO TEMATICO

La prima caratteristica di un data warehouse è che è orientato ai maggior soggetti di un’impresa. La giuda dei processi attraverso i dati è in contrasto con il più classico metodo che prevede l’orientamento delle applicazioni verso i processi e le funzioni, metodo per la maggior parte condiviso dalla maggior parte dei meno recenti sistemi direzionali.

Il mondo operativo è progettato intorno ad applicazioni e a funzioni quali prestiti, risparmi, bankcard e la fiducia per un’istituzione finanziaria. Il mondo del dw è organizzato intorno a soggetti principali quali il cliente, il venditore, il prodotto e l’attività. L’allineamento intorno ad argomenti influisce sulla progettazione e sulla realizzazione dei dati trovati nel dw. In modo più rilevante, l’argomento principale influisce sulla parte più importante della struttura chiave.

Il mondo del applicazione è influenzato sia dal disegno del data base che dal disegno del processo (Process design). Il mondo del dw è concentrato esclusivamente sulla modellazione dei dati e sul disegno del database. Il disegno del processo (nella sua forma classica) non fa parte dell’ambiente del dw.

Le differenze fra la scelta di applicazione processo/funzione e scelta per subject si rivelano anche come differenze nel contenuto dei dati a livello dettagliato. I dati del dw non includono i dati che non saranno usati per il processo di DSS, mentre applicazioni

operazionali orientate ai dati contengono i dati per soddisfare immediatamente i requisiti funzionale/elaborazione che possono o meno avere qualsiasi uso per l’analista di DSS.
Un altro modo importante in cui applicazioni operazionali orientate ai dati differiscono da dati di dw è nei rapporti dei dati. I dati operativi mantengono un rapporto continuo tra due o più tabelle basato su una regola commerciale che è attiva. I dati di dw attraversano uno spettro di tempo e i rapporti trovati nel dw sono molti. Molte regole commerciali ( e corrispondentemente, molti rapporti di dati ) sono rappresentate nel magazzino di dati tra due o più tabelle.

(Per una spiegazione dettagliata di come le relazioni tra i dati sono gestiti nel DW, facciamo riferimento al Tech Topic su quella questione.)
Da nessuna altra prospettiva che quella della differenza fondamentale tra una scelta di applicazione functional/process e una scelta subject, c’è una maggiore differenza tra i sistemi operativi e i dati ed il DW.

INTEGRATION INTEGRAZIONE

L’aspetto più importante dell’ambiente di dw è che i dati trovati all’interno del dw sono integrati facilmente. SEMPRE. SENZA ECCEZIONI. L’essenza stessa dell’ambiente del dw è che i dati contenuti nei limiti del magazzino sono integrati.

L’integrazione si rivela in molti modi differenti – nelle convenzioni identificate consistenti, nella misura di variabili consistenti, nelle strutture codificate consistenti, negli attributi fisici dei dati consistenti, e così via.

Nel corso degli anni i progettisti di diverse applicazioni hanno fatto possesso di molte decisioni su come un’applicazione dovrebbe essere sviluppata. Lo stile e le decisioni progettuali individualizzate delle applicazioni dei progettisti si rivelano in cento modi: nelle differenze di codifica, struttura chiave, caratteristiche fisiche, identificazione convenzioni, e così via. La capacità collettiva di molti progettisti di applicazione di generare le applicazioni contradditorie è leggendaria. La figura 3 espone alcune delle differenze più importanti nei modi in cui le applicazioni sono progettate.

Encoding: Codificare:

I progettisti di applicazioni hanno scelto la codifica del campo – sesso- in diversi modi. Un progettista rappresenta il sesso come una “m” e “f”. Un altro progettista rappresenta il sesso come un “1” e uno “0”. Un altro progettista rappresenta il sesso come una “x” e “y”. Un altro progettista rappresenta il sesso come “maschio” e “femmina”. Non importa molto come il sesso arriva nel DW. La “M” e la “F” sono probabilmente buone quanto tutta la rappresentazione.

Cosa importa è che da qualunque origine derivi il campo sesso, quel campo arriva nel DW in uno stato integrato consistente. Di conseguenza quando il campo è caricato nel DW da un’applicazione dove esso è stato rappresentato fuori nel formato “M” e “F”, i dati devono essere convertiti al formato del DW.

Measurement of Attributes: Misura degli Attributi:

I progettisti di applicazione hanno scelto di misurare la conduttura in una varietà di modi nel corso degli anni. Un progettista memorizza i dati della conduttura in centimetri. Un altro progettista di applicazione memorizza i dati della conduttura in termini di pollici. Un altro progettista di applicazione memorizza i dati della conduttura in milione piedi cubi al secondo. E un altro progettista memorizza le informazioni della conduttura in termini di iarde. Qualunque sia la fonte, quando le informazioni della conduttura arrivano nel DW esse devono essere misurate nello stesso modo.

Secondo le indicazioni di figura 3 le questioni di integrazione interessano quasi ogni aspetto del progetto – le caratteristiche fisiche dei dati, il dilemma di avere più di una fonte dei dati, la questione di campioni identificati inconsistenti, formati dei dati inconsistenti, e così via.

Qualunque sia l’argomento di progettazione, il risultato è lo stesso – i dati devono essere memorizzati nel DW in una singolare e globalmente accettabile maniera anche quando i sistemi operativi di fondo memorizzano diversamente i dati.

Quando l’analista DSS guarda il DW, l’obbiettivo dell’analista dovrebbe essere lo sfruttamento dei dati che sono nel magazzino,

piuttosto che sul domandarsi circa la credibilità o la consistenza dei dati.

TIME VARIANCY

Tutti i dati nel DW sono precisi in qualche momento in tempo. Questa caratteristica base dei dati nel DW è molto diversa dai dati trovati nell’ambiente operativo. I dati dell’ambiente operativo sono precisi come nel momento dell’accesso. In altre parole, nell’ambiente operativo quando si accede ad una unità dati, ci si attendete che rifletterà valori precisi come nel momento di accesso. Perché i dati nel DW siano precisi come in qualche momento nel tempo (cioè, non “proprio adesso”), si dice che i dati trovati nel DW sono “time variancy”.
Il time variancy di dati di DW si riferisce in numerosi modi.
Il modo più semplice è che i dati di un DW rappresentano dati su un lungo orizzonte di tempo – da cinque a dieci anni. L’orizzonte temporale rappresentato per l’ambiente operativo è molto più breve dai valori correnti di oggi da fino a sessanta novanta
Le applicazioni che devono funzionare bene e devono essere disponibili per l’elaborazione delle transazioni devono portare la quantità minima di dati se esse ammettono qualsiasi grado di flessibilità. Quindi le applicazioni operative hanno un orizzonte temporale breve, come un argomento di progettazione di applicazioni audio.
Il secondo modo in cui ‘time variancy’ compare nel DW è nella struttura chiave. Ogni struttura chiave nel DW contiene, implicitamente o esplicitamente, un elemento di tempo, come giorno, settimana, mese, ecc. L’elemento di tempo è quasi sempre in fondo alla chiave concatenata trovata nel DW. In queste occasioni, l’elemento di tempo esisterà implicitamente, come il caso dove un intero file è duplicato alla fine del mese o del quarto.
Il terzo modo in cui time variancy viene visualizzato è che i dati del DW, appena correttamente registrati, non possono essere aggiornati. I dati del DW sono, per tutti gli scopi pratici, una lunga serie di snapshots(istantanea). Naturalmente se la snapshots è stata presa non correttamente, allora le snapshots possono essere modificate. Ma assumendo che le snapshots siano fatte correttamente, esse non vengono modificate appena fatte. In alcuni

casi può essere immorale o anche non valido che le snapshots nel DW siano modificate. I dati operativi, essendo precisi come nel momento di accesso, possono essere aggiornati come si presenta la necessità.

NON VOLATILE

La quarta importante caratteristica del DW è che è non-volatile.
Gli aggiornamenti, inserimenti, cancellazioni e modifiche, sono fatte regolarmente per gli ambienti operazionali record per record. Ma la manipolazione di base dei dati che occorrono nel DW è molto più semplice. Ci sono solo due generi di operazioni che si verificano nel DW – il caricamento iniziale dei dati e l’accesso ai dati. Non c’è alcun aggiornamento dei dati (nel senso generale di aggiornamento) nel DW come normale operazione di elaborazione. Ci sono alcune conseguenze molto potenti di questa differenza di base fra elaborazione operativa ed elaborazione del DW. Al livello di progettazione, la necessità di essere cauti sull’aggiornamento anomalo non è fattore nel DW, poiché l’aggiornamento di dati non è effettuato. Questo significa che a livello fisico di progettazione, possono essere prese delle libertà per ottimizzare l’accesso ai dati, in particolare nell’occuparsi degli argomenti di normalizzazione e di denormalizzazione fisica. Un’altra conseguenza della semplicità delle operazioni di DW è nella tecnologia sottostante utilizzata per eseguire l’ambiente di DW. Dovendo supportare aggiornamenti record per record in linea (così come è spesso il caso con elaborazione operativa) si richiede che la tecnologia abbia delle fondamenta molto complesse sotto una apparente semplicità.
La tecnologia che supporta copie di riserva e recupero, transazioni e integrità dei dati e la scoperta e il rimedio di condizione di stallo è abbastanza complessa e non necessaria per elaborazione di DW. Le caratteristiche di un DW, orientamento di progettazione, integrazione di dati all’interno del DW, time variancy e la semplicità di gestione dei dati, tutto induce ad un ambiente che è molto, molto diverso dall’ambiente operativo classico. La sorgente di quasi tutti i dati di DW sono l’ambiente operativo. È una tentazione pensare che ci sia una ridondanza massiccia di dati tra i due ambienti.
Infatti la prima impressione che molte persone hanno è quella di grande ridondanza di dati tra l’ambiente operativo e l’ambiente di

DW. Una tale interpretazione è superficiale e dimostra una mancanza nel capire che cosa accade nel DW.
Infatti c’è un minimo di ridondanza di dati tra l’ambiente operativo ed i dati del DW. Consideriamo quanto segue:I dati sono filtrati dato che si passa dall’ambiente operativo all’ambiente DW. Molti dati non passano mai fuori dall’ambiente operativo. Solo che i dati che sono necessari per l’elaborazione DSS trovano la loro direzione nell’ambiente

▪  l’orizzonte temporale dei dati è molto diverso da un ambiente all’altro. I dati nell’ambiente operativo sono molto freschi. I dati nel DW sono molto più vecchi. Solo dalla prospettiva dell’orizzonte temporale, c’è la sovrapposizione molto piccola tra l’ambiente operativo e il DW.

▪  Il DW contiene dati di riepilogo che non si trovano mai nell’ambiente

▪  I dati subiscono una trasformazione fondamentale dal momento che passano al La figura 3 illustra che la maggior parte dei dati sono significativamente modificati a condizione di essere selezionati e spostati nel DW. Detto in altro modo, la maggior parte dei dati viene modificata fisicamente e radicalmente come viene spostata nel DW. Dal punto di vista dell’integrazione non sono gli stessi dati che risiedono nell’ambiente operativo. Alla luce di questi fattori, la ridondanza di dati tra i due ambienti è un evento raro, che porta a meno dell’ 1% di ridondanza tra i due ambienti. THE STRUCTURE OF THE WAREHOUSE I DWs hanno una struttura distinta. Ci sono vari livelli riassuntivi e di dettaglio che demarcano i DWs.
I vari componenti di un DW sono:

• Metadata
• Dati di dettaglio correnti
• Dati di dettaglio vecchi
• Dati leggermente riassunti
• Dati altamente riassunti

Di gran lunga la preoccupazione principale è per i dati di dettaglio correnti. È la preoccupazione principale perché:

• I dati di dettaglio correnti riflettono gli avvenimenti più recenti, che sono sempre di grande interesse e
• i dati di dettaglio correnti sono voluminosi perché è memorizzato al livello più basso di granularità e
• i dati di dettaglio correnti sono memorizzati quasi sempre su memoria su disco, il quale è veloce ad accedere, ma caro e complesso da I dati di dettaglio più vecchi sono dati che sono memorizzati su qualche memoria di massa. Ha accesso sporadicamente ed è memorizzato a un livello di dettaglio compatibile con dati dettagliati correnti. Mentre non è obbligatorio memorizzare su un supporto di memoria alternativo, a causa del grande volume di dati uniti con l’accesso sporadico dei dati, il supporto di memoria per dati di dettaglio più vecchi non è di solito memorizzato su disco. I dati riassunti leggermente sono dati che sono distillati dal basso livello di dettaglio trovato al corrente livello di dettaglio. Questo livello del DW è memorizzato quasi sempre su memoria su disco. I problemi della progettazione che si presentano all’architetto dei dati nella costruzione di questo livello del DW sono:

• Quale unità di tempo è la summarization fatta sopra
• Quali contenuti, attributi riassumeranno leggermente il contenuto dei dati Il livello successivo di dati trovati nel DW è quello dei dati altamente riassunti. I dati altamente riassunti sono compatti e facilmente accessibili. I dati altamente riassunti sono talvolta trovati nell’ambiente DW e in altri casi i dati altamente riassunti sono trovati fuori dalle pareti immediate della tecnologia che ospita il DW. (in ogni caso, i dati altamente riassunti fanno parte del DW indipendentemente da dove i dati sono alloggiati fisicamente). Il componente finale del DW è quello dei metadata. Per molti aspetti i metadata siedono in una dimensione diversa rispetto ad altri dati del DW, perchè i metadata non contengono alcun dato direttamente preso dall’ambiente operativo. I metadata hanno un ruolo speciale e molto importante nel DW. I metadata sono utilizzati come:

• una directory per aiutare l’analista DSS ad individuare il contenuto del DW,
• una guida alla mappatura dei dati di come i dati sono stati trasformati dall’ambiente operativo all’ambiente di DW,
• una guida agli algoritmi usati per la summarization tra i dati di dettaglio correnti e i dati leggermente riassunti, i dati altamente riassunti, I metadata giocano un ruolo molto più importante nell’ambiente DW rispetto a quello che hanno mai avuto nell’ambiente operativo OLD DETAIL STORAGE MEDIUM Il nastro magnetico può essere utilizzato per conservare quel tipo di dati. Infatti c’è una larga varietà di strumenti di memorizzazione che dovrebbero essere considerati per la conservazione di vecchi dati di dettaglio. A seconda del volume dei dati, la frequenza di accesso, il costo degli strumenti e il tipo di accesso, esso è completamente probabile che altri strumenti avranno bisogno del vecchio livello di dettaglio nel DW. FLOW OF DATA C’è un flusso normale e prevedibile dei dati all’interno del DW.
  I dati entrano nel DW dall’ambiente operativo. (NOTA: ci sono alcune eccezioni molto interessanti a questa regola. Tuttavia, quasi tutti i dati entrano nel DW dall’ambiente operativo). Dato che i dati entrano nel DW dall’ambiente operativo, è trasformato come è stato descritto prima. A condizione di entrare nel DW, i dati entrano nel corrente livello di dettaglio, come mostrato. Risiede là ed è utilizzato finché uno dei tre eventi si verifica:

• è purificato,
• è riassunto, e/o ▪è Il processo obsoleto dentro un DW sposta i dati di dettaglio correnti a dati di dettaglio vecchi, in base all’età di dati. Il processo

summarization utilizza il dettaglio di dati per calcolare i dati leggermente riassunti e i livelli altamente riassunti dei dati. Ci sono alcune eccezioni al flusso mostrato (sarà discusso più tardi). Tuttavia, di solito, per la vasta maggioranza dei dati trovati all’interno di un DW, il flusso di dati è come rappresentato.

USING THE DATAWAREHOUSE

Non sorprendentemente i vari livelli di dati all’interno del DW non ricevono differenti livelli di utilizzo. Di regola, più è alto livello di summarization, più i dati sono utilizzati.
Molti usi si verificano nei dati altamente riassunti, mentre i vecchi dati di dettaglio sono utilizzati quasi mai. C’è una buona ragione nel spostare l’organizzazione al paradigma in utilizzo di risorsa. Più ha riassunto i dati, più rapido e più efficiente è per arrivare ai dati. Se un negozio trova che fa molti processi a livello di dettaglio dei DW, allora una grande quantità corrispondente di risorse di macchina viene consumato. È nei migliori interessi di ognuno processare come in un alto livello di summarization appena possibile.

Per molti negozi, l’analista DSS in un pre-ambiente DW ha utilizzato dati a livello di dettaglio. Per molti aspetti l’arrivo a dati dettagliati somiglia a una coperta di sicurezza, anche quando sono disponibili altri livelli di summarization. Una delle attività dell’architetto di dati è disabituare l’utente DSS da un utilizzo costante di dati al livello più basso di dettaglio. Ci sono due motivazioni a disposizione dell’architetto di dati:

• installando un sistema chargeback, dove l’utente finale paga le risorse consumate e
• che indicano che il tempo di risposta molto buono può essere ottenuto quando il comportamento con i dati è ad un alto livello di summarization, mentre il tempo di risposta povero deriva dal comportamento dei dati ad un basso livello di OTHER CONSIDERATIONS Ci sono alcune altre considerazioni di costruzione e gestione del DW.
  La prima considerazione è quella sugli indici. I dati ai livelli più alti di summarization possono essere liberamente indicizzati, mentre i dati

ai livelli inferiori di dettaglio sono così voluminosi che può essere indicizzato frugalmente. Dallo stesso token, i dati agli alti livelli di dettaglio possono essere relativamente ristrutturati facilmente, mentre il volume di dati ai livelli inferiori è così grande che i dati non possono essere ristrutturati facilmente. Di conseguenza, il modello dei dati e il lavoro formale fatto dalla progettazione pongono la fondazione per il DW applicata quasi esclusivamente al livello corrente di dettaglio. In altre parole, le attività di modellazione dei dati non si applicano ai livelli di summarization, in quasi ogni caso. Un’altra considerazione strutturale è quella della suddivisione dei dati di DW.

La partizione può essere fatta a due livelli – al livello di dbms ed al livello di applicazione. Nella divisione al livello dbms, il dbms è informato delle divisioni e le controlla di conseguenza. Nel caso di divisione a livello applicazione, soltanto il programmatore è informato delle divisioni e la responsabilità della loro amministrazione è lasciata a lui

Sotto al livello dbms, molto lavoro è fatto automaticamente. C’è molta inflessibilità connessa con l’amministrazione automatica delle divisioni. Nel caso delle divisione a livello applicazione dei dati del data warehouse, molto lavoro grava sul programmatore, ma il risultato finale è la flessibilità nell’amministrazione dei dati nel data warehouse

ALTRE ANOMALIE

Mentre i componenti del data warehouse funzionano come descritto per quasi tutti i dati, ci sono alcune eccezioni utili che devono essere discusse. Un’eccezione è quella dei dati sommari pubblici (public summary data). Questi sono dati sommari che sono stati calcolati fuori dal data warehouse ma sono usati dalla società. I dati sommari pubblici sono memorizzati e gestiti nel data warehouse, anche se come detto precedentemente sono calcolati fuori. I ragionieri lavorano per produrre trimestralmente tali dati come il reddito, le spese trimestrali, profitto trimestrale, e così via. Il lavoro fatto dai ragionieri è esterno al data warehouse. Tuttavia, i dati sono usati “internamente” alla società – dal marketing, dalle vendite, ecc. Un’altra anomalia, di cui non si parlerà, è quella dei dati esterni.

Un altro eccezionale tipo di dati che si possono trovare in un data warehouse è quello dei permanent detail data. Questi provocano la necessità di memorizzare in modo permanente i dati ad un livello dettagliato per i motivi etici o legali. Se una società sta esponendo i relativi operai a sostanze pericolose c’ è un’esigenza di dati dettagliati e permanenti . Se una società produce un prodotto che coinvolge la sicurezza pubblica, quali parti di un aeroplano, c’è l’esigenza di dati dettagliati permanenti, così come se una società stipula contratti pericolosi.

La società non può permettersi di trascurare i particolari perché durante i prossimi anni, nel caso di una causa, di un richiamo, di un difetto di costruzione disputato, ecc. l’esposizione dell’azienda potrebbe essere grande. Di conseguenza c’è un tipo unico di dati conosciuti come permanent detail data.

SOMMARIO

Un data warehouse è un oggetto orientato, integrato, variante di tempo, una raccolta di dati non volatile a sostegno dei bisogni di decisione dell’amministrazione. Ciascuna delle funzioni salienti di un data warehouse ha le relative implicazioni. In più ci sono quattro livelli di dati del data warehouse:

• Old detail
• Current detail
• Dati leggermente ricapitolati
• Dati altamente ricapitolati I metadati sono inoltre una parte importante del data warehouse. ASTRATTO Il concetto dell’immagazzinamento di dati recentemente ha ricevuto molte attenzioni ed è diventato una tendenza degli anni 90. Ciò è dovuto alla capacità di un data warehouse di sormontare le limitazioni dei sistemi di supporto dell’amministrazione quali i sistemi di ausilio decisionale (DSS) ed i sistemi d’informazione esecutivi (EIS). Anche se il concetto del data warehouse sembra promettente, implementare i data warehouse può essere problematico a causa dei processi d’immagazzinamento su larga scala. Malgrado la complessità dei progetti d’immagazzinamento di dati, molti fornitori e consulenti che immagazzinano dati sostengono che l’immagazzinamento di dati attuali non comporta problemi. Tuttavia, all’inizio di questo progetto di ricerca, quasi nessuna ricerca indipendente, rigorosa e sistematica era stata effettuata. Di conseguenza è difficile dire, che cosa realmente accade nell’industria quando si costruiscono data warehouse. Questo studio ha esplorato la pratica d’immagazzinamento di dati contemporanei che punta a sviluppare una comprensione più ricca della pratica australiana. L’analisi della letteratura ha fornito il contesto ed il fondamento per lo studio empirico. Ci sono un certo numero di risultati da questa ricerca. In primo luogo, questo studio ha rivelato le attività che si sono presentate durante lo sviluppo del data warehouse. In molte zone, i dati riuniti hanno confermato la pratica segnalata nella letteratura. In secondo luogo, le edizioni ed i problemi che possono avere effetto sullo sviluppo del data warehouse sono stati identificati da questo studio. Infine, benefici tratti dalle organizzazioni australiane connesse con l’uso dei data warehouse sono stati rivelati.

Capitolo 1

Contesto di ricerca

Il concetto del data warehousing ha ricevuto una diffusa esposizione e si è trasformato in una tendenza emergente negli anni 90 (McFadden 1996, TDWI 1996, Shah e Milstein 1997, Shanks ed altri. 1997, Eckerson 1998, Adelman e Oates 2000). Ciò può essere visto dal numero crescente di articoli sul data warehousing nelle pubblicazioni commerciali (Little e Gibson 1999). Molti articoli (vedere, per esempio, Fisher 1995, Hackathorn 1995, Morris 1995a, Bramblett e re 1996, Graham ed altri. 1996, Sakaguchi e Frolick 1996, Alvarez 1997, Brousell 1997, Clarke 1997, McCarthy 1997, O’ Donnell 1997, Edwards 1998, TDWI 1999) hanno segnalato notevoli benefici tratti dalle organizzazioni che implementano i data warehouse. Hanno sostenuto la loro teoria con la prova aneddotale delle implementazioni riuscite, l’alto ritorno sulle figure di investimento (ROI) e, anche, fornendo la guida di riferimento o le metodologie per lo sviluppo dei data warehouse

(Shanks ed altri. 1997, Seddon e Benjamin 1998, poco e Gibson 1999). In un caso estremo, Graham ed altri. (1996) hanno segnalato un ritorno medio su un investimento triennale del 401%.

Gran parte della letteratura attuale, tuttavia, ha trascurato le complessità coinvolte nell’intraprendere tali progetti. I progetti di data warehouse sono normalmente complesso e su grande scala e quindi implicano un’alta probabilità di non riuscire se non sono controllati con attenzione (Shah e Milstein 1997, Eckerson 1997, Foley 1997b, Zimmer 1997, Bort 1998, Gibbs e Clymer 1998, Rao 1998). Essi richiedono i vasti importi sia di risorse umane che finanziarie e, tempo e sforzo per costruirli (Hill 1998, Crofts 1998). Il tempo tipico ed i mezzi finanziari necessari sono rispettivamente di circa due anni e di due o tre milioni di dollari (Braly 1995, Foley 1997b, Bort 1998, Humphries ed altri. 1999). Questi tempi e mezzi finanziari sono richiesti per controllare e consolidare molti aspetti differenti del data warehousing (Cafasso 1995, Hill 1998). A lato delle considerazioni hardware e software, altre funzioni, che variano dall’estrazione di dati ai processi di caricamento di dati, dalla capacità di memoria per gestire gli aggiornamenti e dai meta dati per la formazione degli utenti, devono essere considerati.

Ai tempi dell’inizio di questo progetto di ricerca, c’era pochissima ricerca accademica condotta nel campo del data warehousing, specialmente in Australia. Ciò era evidente dalla penuria di articoli pubblicati sul data warehousing da giornali o altre scritture accademiche del tempo. Molte delle scritture accademiche disponibili descrivevano l’esperienza statunitense. La mancanza di ricerca accademica nella zona sl data warehousing ha causato la richiesta di ricerca rigorosa e studi empirici (McFadden 1996, Shanks ed altri. 1997, Little e Gibson 1999). In particolare, gli studi di ricerca sul processo di implementazione dei data warehouse necessitano di essere effettuati per estendere la conoscenza generale riguardo l’implementazione dei data warehouse e serviranno come base per un futuro studio di ricerca (Shanks ed altri. 1997, Little e Gibson 1999).

Lo scopo di questo studio, quindi, è studiare che cosa realmente accade quando le organizzazioni effettuano ed usano i data warehouse in Australia. Specificamente, questo studio coinvolgerà un’analisi di un intero processo di sviluppo di un data warehouse, iniziando dall’iniziazione e progettazione attraverso il design e l’inplementazione e il successivo uso all’interno delle organizzazioni australiane. In più, lo studio inoltre contribuirà al la pratica attuale identificando le aree in cui la pratica può essere ulteriormente migliorata e le inefficienze e i rischi possono essere minimizzati o evitati. Inoltre, servirà da base per altri studi sui data warehouse in Australia e colmerà il gap attualmente esistente in letteratura.

Domande di ricerca

L’obiettivo di questa ricerca è studiare le attività coinvolte nell’implementazione dei data warehouse e il loro uso da parte delle organizzazioni australiane. In particolare, sono studiati gli elementi riguardo alla pianificazione di progetto, allo sviluppo, al funzionamento, all’uso ed ai rischi in questione. Quindi la domanda di questa ricerca è:

“Com’è la pratica attuale dei data warehouse in australia?”

Per rispondere efficacemente a questo problema, sono richieste un certo numero di domande sussidarie di ricerca. In particolare, tre sotto-domande sono state identificate dalla letteratura, che è presentata nel capitolo 2, per guidare questo progetto di ricerca: Come sono implementati i data warehouse dalle organizzazioni australiane? Quali sono i problemi incontrati?

Quali sono i benefici sperimentati?
Nel rispondere a queste domande, è stato usato un disegno esplorativo di ricerca che impiega un’indagine. Come studio esplorativo, le risposte alle suddette domande non sono complete (Shanks ed altri. 1993, Denscombe 1998). In questo caso, è richiesta una triangolazione per migliorare le risposte a queste domande. Tuttavia, l’indagine fornirà un solido fondamento per futuri lavori che esaminano queste domande. Una dettagliata discussione sulla giustificazione del metodo di ricerca e sul design è presentata nel capitolo 3.

Struttura del progetto di ricerca

Questo progetto di ricerca è diviso in due parti: lo studio contestuale del concetto di datawarehousing e la ricerca empirica (si veda figura 1.1), ciascuno dei quali è discusso qui di seguito.

Parte I: Studio contestuale

La prima parte della ricerca è consistita nella riesaminazione della letteratura attuale sui vari tipi di data warehousing compresi i sistemi di ausilio decisionale (DSS), i sistemi d’informazione esecutivi (EIS), i case study di data warehouse ed i concetti di data warehouse. Inoltre, i risultati dei foum sui data warehouse e dei gruppi di incontro per esperti e professionisti condotti dal gruppo di ricerca Monash DSS, hanno contribuito a questa fase dello studio che è stato inteso per ottenere le informazioni sulla pratica dei data warehouse e per identificare i rischi coinvolti nella loro adozione. Durante questo periodo di studio contestuale, la comprensione dell’area del problema è stata stabilita per fornire la conoscenza di base per le successive investigazioni empiriche. Tuttavia, questo era un processo continuo durante lo svolgimento dello studio di ricerca.

Parte II: Ricerca empirica

Il concetto relativamente nuovo del data warehousing, specialmente in Australia, ha creato la necessità di eseguire un’indagine per ottenere una vasta immagine dell’esperienza di utilizzo. Questa parte è stata effettuata una volta che il dominio del problema fosse stato stabilito attraverso vasta revisione della letteratura. Il concetto di data-warehousing formato durante la fase di studio contestuale è stato usato come input per il questionario iniziale di questo studio. Dopo questo, il questionario è stato esaminato. Sei esperti di data warehouse hanno partecipato al test. Lo scopo del test del questionario iniziale era controllare la completezza e la precisione delle domande. Sulla base dei risultati del test, il questionario è stato modificato e la versione modificata è stata spedita ai partecipanti all’indagine. I questionari restituiti allora sono stati analizzati per i dati nelle tabelle, negli schemi ed in altri formati. I

risultati di analisi di dati formano una fotografia istantanea della pratica del data warehousing in Australia.

PANORAMICA DEL DATA WAREHOUSING

Il concetto di data warehousing si è evoluto con i miglioramenti della tecnologia dei computer.
Esso è finalizzato a superare i problemi incontrati dai gruppi di supporto delle applicazioni come Decision Support System (DSS) e Executive Information System (EIS).

Nel passato il maggiore ostacolo di queste applicazioni è stata l’incapacità di queste applicazioni di fornire una base di dati necessaria per l’analisi.
Questo è principalmente causato dalla natura del lavoro della dirigenza. Gli interessi della dirigenza di una società variano costantemente a seconda dell’area trattata. Perciò i dati fondamentali per queste applicazioni devono essere in grado di cambiare rapidamente a seconda della parte da trattare.
Questo significa che i dati devono essere disponibili nella forma adeguata per le analisi richieste. Infatti i gruppi di supporto delle applicazioni trovarono molte difficoltà in passato a raccogliere ed integrare dati da complesse e diverse sorgenti.

Il resto di questa sezione presenta una panoramica del concetto di data warehousing e tratta di come il data warehouse può superare i problemi dei gruppi di supporto delle applicazioni.
Il termine “Data Warehouse” fu diffuso da William Inmon nel 1990. La sua spesso citata definizione vede il Data Warehouse come collezione di dati orientati al soggetto,integrati,non volatili,e variabili col tempo,in supporto alle decisioni dirigenziali.

Usando questa definizione Inmon mette in rilievo che i dati residenti in un data warehouse devono possedere le seguenti 4 caratteristiche:

• ▪  Orientati al soggetto
• ▪  Integrati
• ▪  Non volatili
• ▪  Variabili col tempo Per Orientati al soggetto Inmon intende che i dati nel data warehouse nelle più grandi aree organizzative che sono state

definite nel modello dati. Per esempio tutti i dati riguardanti i clienti sono contenuti nell’area soggetto CLIENTI. Allo stesso modo tutti i dati relativi ai prodotti sono contenuti nell’area soggetto PRODOTTI.

Per Integrati Inmon intende che i dati provenienti da differenti piattaforme,sistemi e locazioni sono combinate e immagazzinate in unico posto. Di conseguenza dati similari devono essere trasformati in formati consistenti in modo da essere aggiunti e comparati facilmente.
Per esempio il genere maschile e femminile sono rappresentati dalle lettere M e F in un sistema,e con 1 e 0 in un altro. Per integrarli nella maniera giusta,uno o tutti e due i formati devono essere trasformati in modo che i due formati siano uguali. In questo caso potremmo cambiare M in 1 e F in 0 o viceversa. Orientati al soggetto e Integrati indicano che il data warehouse è progettato per fornire una funzionale e trasversale visione dei dati da parte dell’azienda.

Per Non volatile intende che i dati nel data warehouse rimangono consistenti e l’aggiornamento dei dati non occorre. Invece,ogni cambiamento nei dati originali è aggiunto al database del data warehouse. Questo significa che lo storico dei dati è contenuto nel data warehouse.

Per Variabili col tempo Inmon indica che i dati nel data warehouse contengono sempre gli indicatori di tempo e i dati normalmente attraversano un certo orizzonte temporale. Per esempio un
data warehouse può contenere 5 anni di valori storici dei clienti dal 1993 al 1997. La disponibilità dello storico e di una serie temporale dei dati permette di analizzare dei trend.

Un data warehouse può raccogliere i suoi dati da dei sistemi OLTP;da origini dati esterne all’organizzazione e/o da altri speciali progetti di sistema di cattura dati.
I dati estratti possono passare attraverso un processo di pulizia,in questo caso i dati vengono trasformati ed integrati prima di essere immagazzinati nel database del data warehouse. Poi, i dati

residenti dentro il database del data warehouse sono resi disponibili agli accessi degli utenti finali e agli strumenti di recupero. Usando questi strumenti l’utente finale può accedere alla vista integrata dell’organizzazione dei dati.

I dati residenti dentro il database del data warehouse sono immagazzinati sia dettagliatamente che in formati riassuntivi.
Il livello di riassunto può dipendere dalla natura dei dati. I dati dettagliati possono consistere in dati attuali e dati storici
I dati reali non sono inclusi nel data warehouse fino a quando i dati nel data warehouse vengono riaggiornati.
Oltre ad immagazzinare i dati stessi, un data warehouse può anche immagazzinare un differente tipo di dato chiamato METADATI che descrivono i dati residenti nel suo database.
Ci sono due tipi di metadati: metadati di sviluppo e metadati di analisi.
I metadati di sviluppo sono utilizzati per gestire ed automatizzare i processi di estrazione,pulizia,mappatura e caricamento dei dati nel data warehouse.
L’informazione contenuta nei metadati di sviluppo può contenere dettagli di sistemi operativi,dettagli degli elementi da estrarre,il modello dati del data warehouse e le regole aziendali per la conversione dei dati.

Il secondo tipo di metadati,conosciuti come metadati di analisi rende in grado l’utente finale di esplorare il contenuto del data warehouse per trovare i dati disponibili e il loro significato in termini chiari e non tecnici.

Perciò i metadati di analisi funzionano come un ponte tra il data warehouse e le applicazioni degli utenti finali. Questo metadata può contenere il modello aziendale, le descrizioni dei dati corrispondenti al modello aziendale,interrogazioni (queries) pre-definite e report, informazioni per gli accessi degli utenti e l’indice.

I metadati di analisi e sviluppo devono essere combinati in un unico integrato metadata di contenimento per funzionare correttamente.

Sfortunatamente molti degli strumenti esistenti hanno il proprio metadata e attualmente non ci sono degli standard esistenti che

permettono agli strumenti di data warehousing di integrare questi metadati. Per rimediare a questa situazione molti commercianti dei principali strumenti di data warehousing hanno formato il Meta Data Council divenuto poi Meta Data Coalition.

Lo scopo di questa coalizione è di costruire un set di metadati standard che permette a differenti strumenti di data warehousing di convertire i metadati
I loro sforzi hanno avuto come esito quello della nascita del Meta Data Interchange Specification (MDIS) che permetterà lo scambio di informazioni tra gli archivi Microsoft e i relativi MDIS files.

L’esistenza di dati sia riassunti/indicizzati che dettagliati dà all’utente la possibilità di effettuare un DRILL DROWN (trapanamento) dai dati indicizzati a quelli dettagliati e viceversa. L’esistenza di dati storici dettagliati permette la realizzazione di analisi di trend nel tempo. In aggiunta i metadati di analisi possono essere usati come directory del database del data warehouse per aiutare gli utenti finali a localizzare i dati necessari.

In confronto ai sistemi OLTP,con la loro capacità di supportare analisi di dati e reporting,il data warehouse è visto come un sistema più appropriato per processi di informazione come effettuare e rispondere a queries e produrre report. La prossima sezione evidenzierà le differenze dei due sistemi dettagliatamente.

DATA WAREHOUSE CONTRO SISTEMI OLTP

Molti dei sistemi di informazione all’interno delle organizzazioni hanno lo scopo di supportare le operazioni giornaliere. Questi sistemi conosciuti come SISTEMI OLTP, catturano le transazioni giornaliere continuamente aggiornate.

I dati all’interno di questi sistemi sono spesso modificati,aggiunti o cancellati. Per esempio un indirizzo di un cliente cambia appena egli si sposta da un luogo all’altro. In questo caso il nuovo indirizzo sarà registrato modificando il campo indirizzo del database. L’obiettivo principale di questi sistemi è quello di ridurre i costi delle transazioni e allo stesso tempo di ridurre in tempi di elaborazione. Esempi di Sistemi OLTP includono azioni critiche come scritture contabili di ordini,libri paga,fatture,fabbricazione,servizi ai clienti.

A differenza dei sistemi OLTP,che sono stati creati per processi basati su transazioni ed eventi, i data warehouse sono stati creati per fornire supporto ai processi basati su analisi di dati e su processi di decisione.

Questo è normalmente ottenuto integrando i dati da vari sistemi OLTP ed esterni in un unico “contenitore” di dati,come discusso nella sezione precedente.

Monash Data Warehousing Process Model

Il process model per data warehouse Monashè stato sviluppato dai ricercatori del Monash DSS Research Group, è basato sulla letterature dei data warehouse, sull’esperienza nel supporto allo sviluppo di campi di sistemi, su discussioni con vendors di applicazioni per l’uso su data warehouse, su di un gruppo di esperti nell’uso di data warehouse.

Le fasi sono: Inizio, Pianificazione, Sviluppo, Operazioni e Spiegazioni. Il diagramma spiega la natura iterativa o evoluzionistica dello sviluppo di un data warehouse process usando frecce a doppio senso collocate tra le diverse fasi. In questo contesto “iterativo” e “evoluzionistico” significano che, ad ogni passo del processo, le attività di implementazione si possono sempre propagare all’indietro verso la fase precedente. Questo è dovuto alla natura del progetto di un data warehouse nel quale subentrano in ogni momento richieste addizionali da parte dell’utente finale. Per sempio, durante la fase di sviluppo di un processo di data warehouse, viene richiesta dall’utente finale una nuova dimensione o area di soggetto, che non faceva perte del piano originale, questa deve essere aggiunta al sistema. Questo causa un cambiamento nel progetto. Il risultato è che il team di progettazione deve cambiare i requisiti dei documenti creati finora durante la fase di progettazione. In molti casi, il corrente stato del progetto deve tornare indietro fino alla fase di progettazione dove deve essere aggiunta la nuova richiesta e documentarla. L’utente finale deve poter vedere la documentazione specifica revisionata e i cambiamenti che sono stati fatti nella fase di sviluppo. Alla fine di questo ciclo di sviluppo il progetto deve ottenere ottimi feedback da entrambi i team, quello di sviluppo e quello degli utilizzatori. I feedback sono poi riutilizzati per migliorare un progetto futuro.

Pianificazione della capacità
I dw tendono a essere molto grandi in dimensione e a crescere molto velocemente (Best 1995, Rudin 1997a) a seguito della quantità di dati storici che essi conservano dalla loro durata. La crescita può essere causata anche da dati aggiuntivi richiesti dagli utenti per aumentare il valore dei dati che essi hanno già. Di conseguenza, i requisiti di immagazzinamento per dati possono essere significativamente potenziati (Eckerson 1997). Così, è essenziale assicurare, conducendo una pianificazione della capacità, che il sistema per essere costruito può crescere con la crescita delle necessità(Best 1995, LaPlante 1996, Lang 1997, Eckerson 1997, Rudin 1997a, Foley 1997a).
Nella pianificazione per scalabilità del dw, uno deve conoscere la crescita attesa della dimensione del magazzino, i tipi di domande probabili da effettuare, e il numero di utenti finali sostenuti(Best 1995, Rudin 1997b, Foley 1997a). Costruire applicazioni scalabili richiede una combinazione di tecnologie server scalabili e tecniche di progettazione di applicazioni scalabili (Best 1995, Rudin 1997b. Entrambe sono necessarie nella creazione di un’applicazione estremamente scalabile. Le tecnologie server scalabili possono renderlo facile e vantaggioso per aggiungere deposito, memoria e CPU senza degradare le prestazioni (Lang 1997, Telephony 1997).

Ci sono due tecnologie server scalabili principali: elaborazione multipla simmetrica (SMP) ed elaborazione in maniera massiccia parallela (MPP) ) (IDC 1997, Humphries et al. 1999). Un server SMP normalmente ha più processori che condividono una memoria, sistema bus e altre risorse (IDC 1997, Humphries et al. 1999). Processori supplementari possono essere aggiunti per aumentare la sua potenza computazionale. Un altro metodo per aumentare la potenza computazionale del server SMP, è combinare numerose macchine SMP. Questa tecnica è nota come clustering (Humphries et al. 1999). Un server MPP, d’altra parte, ha più processori ognuno con una propria memoria, sistema bus e altre risorse (IDC 1997, Humphries et al. 1999). Ogni processore è chiamato nodo. Un aumento della potenza computazionale può essere ottenuto

aggiungendo nodi supplementari ai server MPP (Humphries et al. 1999).

Una debolezza dei server SMP è che troppe operazioni input-output (I/O) possono congestionare il sistema bus (IDC 1997). Questo problema non si verifica all’interno dei server MPP poiché ogni processore ha il proprio sistema di bus. Tuttavia, le interconnessioni fra ogni nodo generalmente sono molto più lente del sistema bus dei SMP. Inoltre, i server MPP possono aggiungere un livello supplementare di complessità agli sviluppatori di applicazioni (IDC 1997). Così, la scelta tra server SMP e MPP può essere influenzata da molti fattori, tra cui la complessità delle domande, il rapporto prezzo/prestazioni, la capacità di trattamento richiesta, le applicazioni dw prevenute e l’aumento in dimensione dei database di dw e nel numero di utenti finali.

Numerose tecniche di progettazione di applicazione scalabile possono essere impiegate nella pianificazione della capacità. Uno utilizza vari periodi di notifica come giorni, settimane, mesi e anni. Avendo vari periodi di notifica, il database può essere diviso in pezzi raggruppati maneggevolmente (Inmon et al. 1997). Un’altra tecnica è utilizzare tabelle riepilogative che sono costruite riassumendo dati da dati dettagliati. Così, i dati riassunti sono più compatti del dettagliato, il quale richiede meno spazio di memoria. Quindi i dati di dettaglio possono essere archiviati in un’unità di memorizzazione meno cara, la quale salva ancora più deposito. Benché utilizzare tabelle riepilogative possa salvare spazio di memoria, essi richiedono molto sforzo per mantenerli aggiornati e in linea con le necessità commerciali. Tuttavia, questa tecnica è ampiamente utilizzata e spesso utilizzata insieme alla tecnica precedente(Best 1995, Inmon 1996a, Chauduri and Dayal
1997).

Defining Data Warehouse Technical Architectures Definizione delle tecniche di architetture di dw

Iniziali adottanti di data warehousing concepivano principalmente un’implementazione centralizzata del dw in cui tutti i dati, compreso i dati esterni, erano integrati in uno singolo,
deposito fisico (Inmon 1996a, Bresnahan 1996, Peacock 1998).

Il vantaggio principale di questo approccio è che gli utenti finali sono in grado di accedere alla vista su scala imprenditoriale (enterprise-wide view) dei dati organizzativi (Ovum 1998). Un altro vantaggio è che offre standardizzazione di dati attraverso l’organizzazione, che significa che c’è solo una versione o definizione per ogni terminologia utilizzata nel dw deposito (reposity) metadata (Flanagan and Safdie 1997, Ovum 1998). Lo svantaggio di questo approccio, d’altra parte, è che è caro e difficile da costruire (Flanagan and Safdie 1997, Ovum 1998, Inmon et al. 1998). Non molto dopo che l’architettura d’immagazzinamento dati centralizzata divenne popolare, si evolse il concetto di estrazione dei sottoinsiemi più piccoli dei dati per sostenere i bisogni di applicazioni specifiche (Varney 1996, IDC 1997, Berson e Smith 1997, peacock 1998). Questi piccoli sistemi sono derivati dal più grande data warehouse centralizzato. Sono denominati data warehouse dipartimentali dipendenti o data marts dipendenti. L’architettura del data mart dipendente è conosciuta come architettura tre-tiered in cui la prima fila consiste del data warehouse centralizzato, la seconda consiste dei depositi di dati dipartimentali ed il terzo consiste dell’accesso ai dati e dai tools di analisi (Demarest 1994, Inmon ed altri. 1997).

I data marts sono costruiti normalmente dopo che il data warehouse centralizzato è stato costruito per rispondere alle esigenze delle specifiche unità(White 1995, Varney 1996).
I data marts memorizzano i dati molto rilevanti relativi a particolari unità (Inmon ed altri. 1997, Inmon ed altri. 1998, IA 1998).

Il vantaggio di questo metodo è che non ci sarà nessun dato non integrato e che i dati saranno meno ridondanti all’interno dei data marts poiché tutti i dati provengono da un deposito di dati integrato. Un altro vantaggio è che ci saranno pochi collegamenti fra ogni data mart e le relative fonti di dati perché ogni data mart ha soltanto una fonte di dati. In più con questa architettura sul posto, gli utenti finali possono ancora accedere alla panoramica dei dati

organizzativi aziendali. Questo metodo è conosciuto come il metodo top-down, in cui i data marts sono costruiti dopo il data warehouse (peacock 1998, Goff 1998).
Aumentando la necessità di mostrare presto i risultati, alcune organizzazioni hanno cominciato costruire data marts indipendenti (Flanagan e Safdie 1997, White 2000). In questo caso, i data marts prendono i loro dati direttamente dalle basi di dati OLTP e non dal deposito centralizzato e integrato, eliminando così l’esigenza di avere il deposito centrale sul posto.

Ogni data mart richiede almeno un collegamento alle relative fonti di dati. Uno svantaggio di avere collegamenti multipli per ogni data mart è che, confrontato alle due architetture precedenti, la sovrabbondanza di dati aumenta significativamente.

Ogni data mart deve memorizzare tutti i dati richiesti localmente per non avere effetto sui sistemi di OLTP. Questo provoca che i dati sono immagazzinati in differenti data marts (Inmon ed altri. 1997). Un altro svantaggio di questa architettura è che conduce alla creazione di complesse interconnessioni fra i data marts e le loro fonti di dati che sono difficili da effettuare e controllare (Inmon ed altri. 1997).

Un altro svantaggio è che gli utenti finali non possono potere accedere alla panoramica delle informazioni aziendali poiché i dati dei differenti data marts non sono integrati (Ovum 1998).
Ancora un altro svantaggio è che potrebbe esistere più di una definizione per ogni terminologia usata nei data marts che genera inconsistenze di dati nell’organizzazione (Ovum 1998).
Malgrado gli svantaggi discussi sopra, i data marts indipendenti attraggono ancora l’interesse di molte organizzazioni (IDC 1997). Un fattore che li rende attraenti è che sono più rapidi da sviluppare e richiedono meno tempo e risorse (Bresnahan 1996, Berson e Smith 1997, Ovum 1998). Di conseguenza, servono principalmente come progetti-prova che possono essere usati per identificare rapidamente i benefici e/o le imperfezioni nel progetto (Parsaye 1995, Braly 1995, Newing 1996). In questo caso, la parte da implementare nel progetto pilota deve essere piccola ma importante per l’organizzazione (Newing 1996, Mansell-Lewis 1996).

Esaminando il prototipo, gli utenti finali e l’amministrazione possono decidere se continuare o fermare il progetto (Flanagan e Safdie 1997).
Se la decisione è di continuare, i data marts per altri settori dovrebbero essere costruiti una alla volta. Ci sono due opzioni per gli utenti finali basate sui loro bisogni nella costruzione dei data matrs indipendenti: integrated/federated ed unintegrated (Ovum 1998)

Nel primo metodo, ogni nuovo data mart dovrebbe essere costruito basandosi sui data marts attuali e sul modello dati utilizzato dall’impresa (Varney 1996, Berson e Smith 1997, Peacock 1998). La necessità di usare il modello dati dell’impresa fa si che bisogna accertarsi che esista soltanto una definizione per ogni terminologia usata attraverso i data marts, questo anche per accertarsi che data marts differenti possano essere uniti per dare una panoramica delle informazioni aziendali (Bresnahan 1996). Questo metodo è denominato il bottom-up ed è il migliore quando c’è un vincolo sui mezzi finanziari e sul tempo (Flanagan e Safdie 1997, Ovum 1998, peacock 1998, Goff 1998). Nel secondo metodo, i data marts costruiti possono soddisfare soltanto i bisogni di un’unità specifica. Una variante del federated data mart è il data warehouse distribuito in cui il database middleware hub server è utilizzato per unire molti data marts in un singolo deposito di dati distribuito (White 1995). In questo caso, i dati aziendali sono distribuiti in parecchi data marts. Le richieste dell’utente finale sono trasmesse al database middleware hub server , che estrae tutti i dati richiesti dai data marts e ritorna i risultati alle applicazioni dell’utente finale. Questo metodo fornisce le informazioni aziendali agli utenti finali. Tuttavia, ancora non vengono eliminati i problemi dei data marts indipendenti. C’è un’altra architettura che può essere usata che è chiamata il data warehouse virtuale (White 1995). Tuttavia, questa architettura, che è descritta nella figura 2.9, non è un’architettura d’immagazzinamento di dati reali poiché non sposta il caricamento dai sistemi OLTP al data warehouse (Demarest 1994).

Infatti, le richieste di dati dagli utenti finali sono passate sopra ai sistemi di OLTP che restituiscono i risultati dopo l’elaborazione delle richieste di utente. Anche se questa architettura permette agli utenti finali di generare i rapporti e formulare le richieste, non può fornire i

dati storici e la panoramica delle informazioni aziendali poiché i dati dai differenti sistemi di OLTP non sono integrati. Quindi, questa architettura non può soddisfare l’analisi di dati complessa quale ad esempio previsioni.

Selezione dell’applicativi di accesso e di recupero dei dati

Lo scopo della costruzione di un data warehouse è di trasmettere informazioni agli utenti finali (Inmon ed altri 1997, Poe 1996, McFadden 1996, Shanks ed altri 1997, Hammergren 1998); uno o più applicativi di accesso e recupero dati devono essere forniti. Ad oggi, esiste un’ampia varietà di questi applicativi tra cui l’utente può scegliere (Hammergren 1998, Humphries ed altri 1999). Gli applicativi selezionati determinano il successo dello sforzo d’immagazzinamento di dati in un’organizzazione perché gli applicativi sono la parte più visibile del data warehouse all’utente finale (Inmon ed altri 1997, Poe 1996). Per aver successo un data warehouse, deve potere sostenere le attività di analisi dei dati dell’utente finale (Poe 1996, Seddon e Benjamin 1998, Eckerson 1999). Quindi il “livello” di ciò che l’utente finale vuole deve essere identificato (Poe 1996, Mattison 1996, Inmon ed altri 1997, Humphries ed altri 1999).

In generale, gli utenti finali possono essere raggruppati in tre categorie: executive users, business analysts e power user (Poe 1996, Humphries ed altri 1999). Gli executive users necessitano di un facile accesso ad insiemi predefiniti di rapporti (Humphries ed altri 1999). Questi rapporti possono essere raggiunti facilmente con la navigazione dei menu (Poe 1996). In più, i rapporti dovrebbero presentare le informazioni usando la rappresentazione grafica come le tabelle ed i modelli per trasportare rapidamente le informazioni (Humphries ed altri 1999). I business analyst, che non possono avere le possibilità tecniche per sviluppare i rapporti da zero da soli, necessitano di potere modificare i rapporti attuali per soddisfare i loro bisogni specifici (Poe 1996, Humphries ed altri 1999). I power user, d’altra parte, sono il tipo di utilizzatori finali che hanno la capacità di generare e scrivere le richieste ed i rapporti da zero (Poe 1996, Humphries ed altri 1999). Sono quelli che

sviluppano i rapporti per gli altri tipi di utenti (Poe 1996, Humphries ed altri 1999).

Una volta determinati i requisiti dell’utente finale deve essere fatta una selezione degli applicativi di accesso e recupero dati tra tutti quelli disponibili (Poe 1996, Inmon ed altri 1997).
L’accesso ai dati e gli strumenti di retrieval possono essere classificati in 4 tipi: OLAP tool, EIS/DSS tool, tool di query e reporting e tool di data mining.

I tool OLAP permettono agli utenti di creare query ad hoc così come quelle fatte sul database del data warehouse. Inoltre questi prodotti consentono agli utenti di fare drill-down dai dati generali a quelli dettagliati.

I tool EIS/DSS forniscono reporting esecutivi come analisi “what if” e accessi ai reports organizzati a menu. I report devono essere predefiniti e uniti ai menu per una navigazione più facile.
I tool di query e reporting permettono agli utenti di produrre report predefiniti e specifici.

I tool di data mining sono usati per identificare relazioni che potrebbero fare nuova luce sulle operazioni dimenticate nei dati del datawarehouse.

Accanto all’ottimizzazione dei requisiti di ogni tipologia di utenti, i tool selezionati devono essere intuitivi, efficienti e di facile utilizzo. Inoltre devono essere compatibili con le altre parti dell’architettura e in grado di lavorare con i sistemi esistenti. È inoltre suggerito di scegliere data access e tool di retrieval con prezzi e performance ragionevoli. Altri criteri da considerare includono l’impegno del venditore del tool nel sostenere il loro prodotto e gli sviluppi che lo stesso avrà nelle future release. Per garantire l’impegno degli utenti nell’utilizzo del datawarehouse, il team di sviluppo coinvolge gli utenti nel processo della selezione del tool. In questo caso dovrebbe essere effettuata una valutazione pratica dell’utente.

Per migliorare il valore del datawarehouse il team di sviluppo può fornire anche un accesso web ai loro datawarehouse. Un datawarehouse web-enabled permette agli utenti di accedere ai dati da posti remoti o mentre si viaggia. Inoltre le informazioni possono

essere fornite a costi più bassi mediante una diminuzione dei costi di training.

2.4.3 Data Warehouse Operation Phase

Questa fase consiste di tre attività: definizione di strategie di data refresh, controllo delle attività del datawarehouse e gestione della sicurezza del datawarehouse.

Definizione di strategie di data refresh

Dopo il caricamento iniziale, i dati nel database del datawarehouse devono essere refreshati periodicamente per riprodurre i cambiamenti effettuati sui dati originali. Bisogna quindi decidere quando fare il refresh, ogni quanto tempo deve essere schedulato il refresh e come eseguire il refresh dei dati. Viene suggerito di fare il refresh dei dati quando il sistema può essere messo off- line. La frequenza del refresh è determinata dal team di sviluppo basandosi sui requisiti degli utenti. Ci sono due approcci per fare il refresh del datawarehouse: il refresh completo e il caricamento continuo dei cambiamenti.

Il primo approccio, il refresh completo, richiede il ricaricamento di tutti i dati da zero. Ciò vuol dire che tutti i dati richiesti devono essere estratti, puliti, trasformati ed integrati in ogni refresh. Questo approccio dovrebbe essere, per quanto possibile, evitato perché richiede molto tempo e risorse.

Un approccio alternativo è quello di caricare continuamente i cambiamenti. Questo aggiunge i dati che sono stati cambiati dall’ultimo ciclo di refresh del datawarehouse. L’identificazione di records nuovi o modificati riduce significativamente la quantità di dati che devono essere propagati al datawarehouse in ogni aggiornamento poiché solo questi dati saranno aggiunti al database del datawarehouse.

Ci sono almeno 5 approcci che possono essere usati per prelevare i dati nuovi o modificati. Per ottenere un’efficiente strategia di refresh dei dati può essere utile un misto di questi approcci che preleva tutti i cambiamenti nel sistema.

Il primo approccio, che usa i timestamp, suppone che viene assegnato a tutti i dati modificati e aggiornati un timestamp in modo da potere identificare facilmente tutti i dati modificati e nuovi. Questo approccio, però, non è stato molto usato nella maggior parte degli odierni sistemi operativi.
Il secondo approccio è quello di usare un delta file generato da un’applicazione che contiene soltanto i cambiamenti fatti ai dati. L’uso di questo file inoltre amplifica il ciclo di aggiornamento. Tuttavia, anche questo metodo, non è stato usato in molte applicazioni.
Il terzo approccio è quello di fare uno scan su un file di log, che fondamentalmente contiene informazioni simili al delta file. L’unica differenza è che un log file è creato per il processo di recovery e può essere difficile da capire.
Il quarto approccio è quello di modificare il codice dell’applicazione. Tuttavia la maggior parte del codice delle applicazioni è vecchio e fragile; perciò questa tecnica dovrebbe essere evitata.
L’ultimo approccio è quello di confrontare i dati sorgenti con il file principale dei dati.

Controllo delle attività del datawarehouse

Una volta che il datawarehouse è stato rilasciato agli utenti, è necessario monitorarlo nel tempo. In questo caso, l’amministratore del datawarehouse può impiegare uno o più tool di gestione e controllo per monitorare l’uso del datawarehouse. In particolare possono essere raccolte informazioni sulle persone e sul tempo in cui accedono al datawarehouse. Dai dati raccolti può essere creato un profilo del lavoro effettuato che può essere usato come input nell’implementazione del chargeback dell’utente. Il Chargeback permette agli utenti di essere informati sul costo di elaborazione del datawarehouse.

Inoltre, il controllo del datawarehouse può anche essere usato per identificare i tipi di query, la loro grandezza, il numero di query al giorno, i tempi di reazione alla query, i settori raggiunti e la quantità di dati processati. Un altro scopo di fare il controllo del datawarehouse è identificare i dati che non sono in uso. Questi dati possono essere rimossi dal datawarehouse per migliorare il tempo

di risposta di esecuzione delle query e controllare la crescita dei dati che risiedono all’interno della base di dati del datawarehouse.

Gestione della sicurezza del datawarehouse

Un datawarehouse contiene dati integrati, critici, sensibili che possono essere raggiunti facilmente. Per questo motivo dovrebbe essere protetto dagli utenti non autorizzati. Un modo per implementare la sicurezza è quello di usare la funzione del DBMS per assegnare i diversi privilegi ai diversi tipi di utenti. In questo modo, deve essere mantenuto per ogni tipo di utenti un profilo di accesso. Un altro modo per assicurare il datawarehouse è cifrarlo come è scritto nella base di dati del datawarehouse. L’accesso ai dati e i tool di retrieval devono decriptare i dati prima di presentare i risultati agli utenti.

2.4.4 Data Warehouse Deployment Phase

È l’ultima fase nel ciclo di implementazione del datawarehouse. Le attività da effettuare in questa fase includono l’addestramento degli utenti per utilizzare il datawarehouse e la realizzazione di reviews del datawarehouse.

Addestramento degli utenti

L’addestramento degli utenti dovrebbe essere fatto prima dell’accesso ai dati del datawarehouse e dell’uso dei tool di retrieval. Generalmente, le sessioni dovrebbero iniziare con l’introduzione al concetto dell’immagazzinamento di dati, al contenuto del datawarehouse, ai meta dati ed alle features di base dei tool. Poi, gli utenti più avanzati potrebbero inoltre studiare le tabelle fisiche e le features degli utenti dei data access e dei tool di retrieval.

Ci sono molti approcci per fare l’addestramento degli utenti. Uno di questi prevede una selezione di molti utenti o analisti scelti da un insieme di utenti, basandosi sulla loro leadership e abilità di comunicazione. Questi vengono addestrati a titolo personale su tutto quello che devono sapere per prendere confidenza con il sistema. Finito l’addestramento, questi ritornano al loro lavoro e iniziano a insegnare agli altri utenti come utilizzare il sistema. Sulla

base di quanto hanno imparato, gli altri utenti possono iniziare ad esplorare il datawarehouse.
Un altro approccio è quello di addestrare molti utenti nello stesso tempo, come se si stesse facendo un corso in aula. Questo metodo è adatto quando ci sono molti utenti che devono essere addestrati allo stesso tempo. Un altro metodo ancora è quello di addestrare individualmente ogni utente, ad uno ad uno. Questo metodo è adatto quando ci sono pochi utenti.

Lo scopo dell’addestramento degli utenti è quello di familiarizzare con l’accesso ai dati e i tool di retrieval così come i contenuti del datawarehouse. Tuttavia, alcuni utenti possono essere sopraffatti dalla quantità di informazioni fornita durante la sessione di addestramento. Quindi devono essere fatte un certo numero di sessioni di aggiornamento l’assistenza continua e per rispondere alle domande specifiche. In alcuni casi viene formato un gruppo di utenti per fornire questo tipo di supporto.

Gathering feedback

Una volta che il datawarehouse è stato rolled out, gli utenti possono usare i dati che risiedono nel datawarehouse per vari scopi. Principalmente, gli analisti o gli utenti utilizzano i dati nel datawarehouse per:

1. 1  Identificare le tendenze dell’azienda
2. 2  Analizzare i profili d’acquisto dei clienti
3. 3  Suddividere i clienti ed i
4. 4  Fornire i servizi migliori ai clienti – customizzare i servizi
5. 5  Formulare strategie di marketing
6. 6  Effettuare preventivi competitivi per cost analyses e help control
7. 7  Supportare decision-making strategiche
8. 8  Identificare occasioni per emergere
9. 9  Migliorare la qualità degli attuali business process
10. 10  Controllare il profitto

Seguendo la direzione di sviluppo del datawarehouse, si potrebbero condurre una serie di revisioni al sistema per ottenere dei feddback

sia da parte del team di sviluppo che da parte della comunità degli utenti finali.
I risultati ottenuti possono essere presi in considerazione per il prossimo ciclo di sviluppo.

Dal momento che il datawarehouse ha un approccio incrementale, è fondamentale imparare dai successi e dagli errori dei precedenti sviluppi.

2.5 Riassunto

In questo capitolo sono stati discussi gli approcci presenti in letteratura. Nella sezione 1 è stato discusso il concetto di datawarehouse e il suo ruolo nella scienza delle decisioni. Nella sezione 2 sono state descritte le principali differenze tra datawarehouse e sistemi OLTP. Nella sezione 3 si è discusso il modello di datawarehouse secondo Monash che è stato utilizzato nella sezione 4 per descrivere le attività coinvolte nel processo di sviluppo di un datawarehouse, queste tesi non sono state basate su una ricerca rigorosa. Quello che succede nella realtà può essere molto diverso da quello che riporta la letteratura, tuttavia questi risultati possono essere utilizzati per creare un bagaglio di base che sottolinei il concetto di datawarehouse per questa ricerca.

Capitolo 3

Metodi di ricerca e progettazione

Questo capitolo si occupa dei metodi di ricerca e progettazione per questo studio. La prima parte mostra una vista generica dei metodi di ricerca disponibili per il reperimento dell’informazione, inoltre vengono discussi i criteri per selezionare il miglior metodo per uno studio particolare. Nella sezione 2 vengono poi discussi due metodi selezionati con i criteri appena esposti; di questi ne verrà scelto ed adottato uno con le motivazioni esposte nella sezione 3 dove sono anche esposte le motivazioni per l’esclusione dell’altro criterio. La sezione 4 presenta il progetto della ricerca e la sezione 5 le conclusioni.

3.1 Ricerca nei sistemi informativi

La ricerca nei sistemi informativi non si limita semplicemente all’ambito tecnologico ma deve essere anche estesa per includere fini riguardanti il comportamento e l’organizzazione.
Questo lo dobbiamo alle tesi di varie discipline che vanno dalle scienze sociali a quelle naturali; questo porta alla necessità di un certo spettro di metodi di ricerca che coinvolgono metodi quantitativi e qualitativi da utilizzare per i sistemi informativi.
Tutti i metodi di ricerca disponibili sono importanti, infatti svariati ricercatori come Jenkins (1985), Nunamaker et al. (1991), e Galliers (1992) sostengono che non esista un metodo specifico universale per condurre ricerche nei vari campi dei sistemi informativi; infatti un metodo può essere adatto per una particolare ricerca ma non per altre. Questo ci porta la necessità di selezionare un metodo che sia adatto alla nostro particolare progetto di ricerca: per questa scelta Benbasat et al. (1987) affermano che si debbano considerare la natura e il fine della ricerca.

3.1.1 Natura della ricerca

I vari metodi basati sulla natura della ricerca possono essere classificati in tre tradizioni ampiamente conosciuti nella scienza dell’informazione: positivista, interpretativa e ricerca critica.

3.1.1.1 Ricerca positivista

La ricerca positivista è anche conosciuta come studio scientifico o empirico. Essa cerca di: “spiegare e prevedere cosa succederà nel mondo sociale guardando alle regolarità e alle relazioni causa- effetto tra gli elementi che lo costituiscono” (Shanks et al 1993).

La ricerca positivista è inoltre caratterizzata da ripetibilità , semplificazioni e confutazioni. Inoltre la ricerca positivista ammette l’esistenza di relazioni a priori tra i fenomeni studiati.
Secondo Galliers(1992) la tassonomia è un metodo di ricerca incluso nel paradigma positivista, che però non è limitato a questa, infatti sussistono esperimenti di laboratorio, esperimenti sul campo, casi di studio, dimostrazioni di teoremi, previsioni e simulazioni. Utilizzando questi metodi i ricercatori ammettono che i fenomeni studiati possano essere osservati oggettivamente e rigorosamente.

3.1.1.2 Ricerca interpretativa

La ricerca interpretativa, che è spesso chiamata fenomenologia o anti-positivismo viene descritta da Neuman (1994) come “l’analisi sistematica del significato sociale dell’azione attraverso la diretta e dettagliata osservazione delle persone in situazioni naturali, al fine di arrivare alla comprensione e all’interpretazione di come le persone creano e mantengono il loro mondo sociale”. Gli studi interpretative rifiutano l’assunzione che i fenomeni osservati possano essere osservati oggettivamente. Infatti essi sono basati su interpretazioni soggettive. Inoltre i ricercatori interpretativi non impongono significati a priori ai fenomeni che studiano.

Questo metodo comprende studi soggettivo/argomentativi, azioni di ricerca, studi descrittivo/interpretativi, ricerche future e giochi di ruolo. In aggiunta a questi indagini e casi di studio possono essere inclusi in questo approccio in quanto essi concernono gli studi degli individui o delle organizzazioni all’interno di complesse situazioni del mondo reale.

3.1.1.3 Ricerca critica

La ricerca critica è l’approccio meno conosciuto nelle scienze sociali ma di recente ha ricevuto l’attenzione dei ricercatori nell’ambito dei sistemi informativi. L’assunzione filosofica che la realtà sociale è storicamente prodotta e riprodotta dalle persone, così come i sistemi sociali con le loro azioni ed interazioni. La loro abilità, comunque, è mediata da un certo numero di considerazione sociali, culturali e politiche.

Cosi come la ricerca interpretativa, quella critica sostiene che la ricerca positivista non c’entra con il contesto sociale ed ignora la sua influenza sulle azioni umane.
La ricerca critica, d’altra parte, critica la ricerca interpretativa per essere troppo soggettiva e perché non si propone di aiutare le persone a migliorare le proprie vite. La più grossa differenza tra la ricerca critica e gli altri due approcci è la sua dimensione valutativa. Mentre l’oggettività delle tradizioni positivista ed interpretativa, è per predire o spiegare lo status quo o la realtà sociale, la ricerca critica punta a valutare criticamente e trasformare la realtà sociale sotto studio.

I ricercatori critici solitamente si oppongono allo status quo al fine di rimuovere le differenze sociali e migliorare le condizioni sociali. La ricerca critica ha un impegno ad una vista processuale dei fenomeni di interesse e, pertanto, è normalmente longitudinale. Esempi di metodi di ricerca sono gli studi storici a lungo termine e gli studi etnografici. La ricerca critica, tuttavia, non è stata ampiamente usata nella ricerca dei sistemi d’informazione

3.1.2 Scopo della ricerca

Assieme alla natura della ricerca, il suo scopo può essere utilizzato per guidare il ricercatore nella selezione di un particolare metodo di ricerca. Lo scopo di un progetto di ricerca è strettamente correlato alla posizione della ricerca rispetto al ciclo di ricerca che consiste di tre fasi: costruzione della teoria, test della teoria e affinamento della teoria. Così, basandosi sul momento rispetto al ciclo di ricerca, un progetto di ricerca può avere un fine di spiegazione, descrittivo, di esplorazione oppure predittivo.

3.1.2.1 Ricerca esplorativa

La ricerca esplorativa è finalizzata nell’investigare un argomento totalmente nuovo e formulare domande e ipotesi per la ricerca futura. Questo tipo di ricerca è utilizzato nella costruzione della teoria per ottenere dei riferimenti iniziali in una nuova area. Normalmente si utilizzano metodi di ricerca qualitativa, come i casi di studio o gli studi fenomenonologici.

Tuttavia è anche possibile impiegare tecniche quantitative come indagini esplorative od esperimenti.

3.1.3.3 Ricerca descrittiva

La ricerca descrittiva è finalizzata ad analizzare e descrivere in gran dettaglio una particolare situazione o pratica organizzativa. Questa è appropriata per costruire teorie e può essere anche usata per confermare o contestare ipotesi. La ricerca descrittiva solitamente comprende l’uso di misure e campioni. I metodi di ricerca più adatti comprendono indagini e analisi di antecedenti.

3.1.2.3 Ricerca esplicativa

La ricerca esplicativa cerca di spiegare perché succedono le cose. Essa è costruita su fatti che sono già stati studiati e cerca di trovare i perché di tali fatti.
Quindi la ricerca esplicativa è normalmente costruita sulla ricerca esplorativa o descrittiva ed è accessoria al fine di testare ed affinare le teorie. La ricerca esplicativa normalmente impiega casi di studio o metodi di ricerca basati sulle indagini.

3.1.2.4 Ricerca preventiva

La ricerca preventiva punta a predire gli eventi e i comportamenti sotto osservazione che si stanno studiando (Marshall and Rossman 1995). La previsione è il test scientifico standard della verità. Questo tipo di ricerca generalmente impiega indagini o analisi dei dati storici. (Yin 1989)

La suddetta discussione dimostra che c’è un certo numero di possibili metodi di ricerca che possono essere usati in uno studio particolare. Tuttavia, ci deve essere un metodo specifico più adatto degli altri per un tipo particolare di progetto di ricerca. (Galliers 1987, Yin 1989, De Vaus 1991). Ogni ricercatore, quindi, ha bisogno di valutare con attenzione i punti di forza e le debolezze di vari metodi, per arrivare ad adottare il metodo di ricerca più adatto e compatibile col progetto di ricerca. (Jenkins 1985, Pervan e Klass 1992, Bonomia 1985, Yin 1989, Himilton and Ives 1992).

3.2. Possibili metodi di ricerca

L’obiettivo di questo progetto era studiare l’esperienza nelle organizzazioni australiane con i dati immagazzinati con uno sviluppo di data warehouse. Dato che, attualmente, c’è una mancanza di ricerca nell’area di data warehousing in Australia, questo progetto di ricerca è ancora nella fase teorica del ciclo di ricerca ed ha uno scopo esplorativo. Esplorando l’esperienza nelle organizzazioni australiane che adottano il data warehousing richiede l’interpretazione della società reale. Di conseguenza, il l’assunzione filosofica alla base del progetto di ricerca segue l’interpretazione tradizionale.

Dopo un rigoroso esame dei metodi disponibili, sono stati identificati due possibili metodi di ricerca: indagini (surveys) e casi di studio (case studies), che possono essere usati per una ricerca esplorativa (Shanks et al. 1993). Galliers (1992) sostiene che l’idoneità di questi due metodi per questo particolare studio nella sua tassonomia rivisitata dicendo che sono adatti per la costruzione teorica. Le seguenti due sottosezioni discutono ogni metodo in dettaglio.

3.2.1 Metodo di ricerca di indagine

Il metodo di ricerca d’indagine proviene dall’antico metodo del censimento. Un censimento consta nel collezionare informazioni da un’intera popolazione. Questo metodo è costoso e poco pratico, in particolare se la popolazione è elevata. Quindi, rispetto al censimento, una indagine normalmente è concentrata sul collezionare informazioni per un piccolo numero, o campione, dei rappresentanti della popolazione (Fowler 1988, Neuman 1994). Un campione riflette la popolazione da cui è disegnato, con differenti livelli di accuratezza, secondo la struttura del campione, la dimensione e il metodo di selezione utilizzato (Fowler 1988, Babbie 1982, Neuman 1994).

Il metodo d’indagine è definito come “snapshots of practices, situations or views at a particular point in time, undertaken using questionnaires or interviews, from which inferences may be
made” (Galliers 1992:153) [fotografia istentanea delle pratiche, situazioni o viste in particolare punto temporale, intrapreso usando questionari o interviste, da cui possono essere fatte inferenze]. Le indagini si occupano della raccolta di informazioni su alcuni aspetti dello studio, da un certo numero di partecipanti, facendo delle domande (Fowler 1988). Anche questi questionari e interviste, che includono le interviste faccia a faccia al telefono e quelle strutturate, sono le tecniche di collezione di dati più comuni impiegate nelle indagini (Blalock 1970, Nachmias and Nachmias 1976, Fowler 1988), possono essere utilizzate osservazioni ed analisi (Gable 1994). Di tutti questi metodi di collezione dei dati, l’uso del questionario è la tecnica più popolare, poiché assicura che i dati

collezionati siano strutturati e formattati, e quindi facilita la classificazione delle informazioni (Hwang 1987, de Vaus 1991).

Nell’analizzare i dati, una strategia d’indagine impiega spesso le tecniche quantitative, come l’analisi statistica, ma possono essere impiegate anche tecniche qualitative (Galliers 1992, Pervan

and Klass 1992, Gable 1994). Normalmente, i dati raccolti sono usati per analizzare le distribuzioni e i modelli delle associazioni (Fowler 1988).

Anche se le indagini sono generalmente appropriate per ricerche che si occupano della domanda ‘che cosa?’ (what) o da essa derivanti, quali ‘quanto’(how much) e ‘quant’è’ (how many), esse possono essere poste tramite la domanda ‘perché’ (Sonquist and Dunkelberg 1977, Yin 1989). Secondo Sonquist e Dunkelberg (1977), l’indagine di ricerca punta ad ipotesi difficili, programme di valutazione, descrivendo la popolazione e sviluppando modelli del comportamento umano. Inoltre, le indagini possono essere usate per studiare un’opinione certa della popolazione, condizioni, opinioni, caratteristiche, aspettative e anche comportamenti passati o presenti(Neuman 1994).

Le indagini permettono al ricercatore di scoprire i rapporti tra la popolazione ed i risultato sono normalmente più generici rispetto ad altri metodi (Sonquist and Dunkelberg 1977, Gable 1994). Le indagini permettono ai ricercatori di riguardare una zona geografica più larga e di raggiungere tantissimi dichiaranti (Blalock 1970, Sonquist and Dunkelberg 1977, Hwang and Lin 1987, Gable 1994, Neuman 1994). Infine, le indagini possono fornire le informazioni che non sono disponibili altrove o nella forma richiesta per le analisi (Fowler 1988).

Ci sono, tuttavia, alcune limitazioni nell’eseguire un’indagine. Uno svantaggio è che il ricercatore non può ottenere molte informazioni a riguardo dell’oggetto studiato. Questo è dovuto al fatto che le indagini sono eseguite soltanto in un momento particolare e, quindi, c’è un numero limitato di variabili e di persone che il ricercatore può

studiare (Yin 1989, de Vaus 1991, Gable 1994, Denscombe 1998). Un altro svantaggio è quello che esegue un’indagine può essere molto costoso in termini di tempo e risorse, particolarmente se coinvolge le interviste faccia a faccia (Fowler 1988).

3.2.2. Metodo Di Ricerca Di Inchiesta

Il metodo di ricerca di inchiesta coinvolge lo studio approfondito su una particolare situazione all’interno del relativo contesto reale in un periodo di tempo definito, senza alcun intervento da parte del ricercatore (Shanks & C. 1993, Eisenhardt 1989, Jenkins 1985). Principalmente questo metodo è usato per descrivere i rapporti fra le variabili che si stanno studiando in una situazione particolare (Galliers 1992). Le inchieste possono coinvolgere singoli casi o multipli, a seconda del fenomeno analizzato (Franz e Robey 1987, Eisenhardt 1989, Yin 1989).

Il metodo di ricerca di inchiesta è definito come “un’inchiesta empirica che studia un fenomeno contemporaneo all’interno del relativo contesto reale, usando le fonti multiple raccolte da una o più entità quali la gente, i gruppi, o le organizzazioni” (Yin 1989). Non c’è netta separazione fra il fenomeno ed il relativo contesto e non c’è controllo o manipolazione sperimentale delle variabili (Yin 1989, Benbasat ed altri 1987).

C’è una varietà di tecniche per la collezione dei dati che possono essere impiegate nel metodo di inchiesta, che includono le osservazioni dirette, revisioni di record di archivi, questionari, revisione della documentazione ed interviste strutturate. Avendo una gamma varia di tecniche della raccolta di dati, le inchieste permettono ai ricercatori di occuparsi sia dei dati qualitativi che quantitativi allo stesso tempo (Bonoma 1985, Eisenhardt 1989, Yin 1989, Gable 1994). Com’è il caso con il metodo di indagine, un ricercatore di inchiesta funge da osservatore o ricercatore e non come partecipante attivo all’organizzazione allo studio.

Benbasat ed altri (1987) asseriscono che il metodo di inchiesta è particolarmente adatto per la costruzione della teoria di ricerca, che comincia con una domanda di ricerca e continua con la formazione

di una teoria durante il processo della raccolta di dati. Essendo adatto anche per la fase

della costruzione di teoria, Franz e Robey (1987) suggeriscono che il metodo di inchiesta può anche essere utilizzato per la complessa fase di teoria. In questo caso, basandosi sulle prove raccolte, una data teoria o ipotesi viene verificata o confutata. In più, l’inchiesta è anche adatta per ricerca che si occupa delle domande ‘come’ o ‘perché’ (Yin 1989).

Rispetto ad altri metodi, le inchieste permettono al ricercatore di catturare le informazioni essenziali più nel particolare (Galliers 1992, Shanks ed altri 1993). Inoltre, le inchieste permettono al ricercatore di capire la natura e la complessità dei processi studiati (Benbasat ed altri 1987).

Ci sono quattro svantaggi principali connessi con il metodo di inchiesta. Il primo è la mancanza di deduzioni controllate. La soggettività del ricercatore può alterare i risultati e le conclusioni dello studio (Yin 1989). Il secondo svantaggio è la mancanza di osservazione controllata. A differenza dei metodi sperimentali, il ricercatore di inchiesta non può controllare i fenomeni studiati poiché sono esaminati nel loro contesto naturale (Gable 1994). Il terzo svantaggio è la mancanza di replicabilità. Ciò è dovuto al fatto che il ricercatore ha poca probabilità di osservare gli stessi eventi, e non può verificare i risultati di un particolare studio (Lee 1989). Infine, come conseguenza della non replicabilità, è difficile generalizzare i risultati ottenuti da una o più inchieste (Galliers 1992, Shanks ed altri 1993). Tutti questi problemi, tuttavia, non sono insormontabili e possono, infatti, essere minimizzati dal ricercatore applicando azioni appropriate (Lee 1989).

3.3. Giustificare la metodologia di ricerca adottata

Dai due metodi di ricerca possibili per questo studio, il metodo di indagine è considerato come il più adatto. Quello di inchiesta è stato scartato in seguito ad un attenta considerazione dei relativi

meriti e debolezze. La convenienza o l’inappropriatezza di ogni metodo per questo studio è discussa in seguito.

3.3.1. Inappropriatezza del metodo di ricerca di inchiesta

Il metodo di inchiesta richiede lo studio approfondito circa una situazione particolare all’interno di una o più organizzazioni per un periodo di tempo (Eisenhardt 1989). In questo caso, il periodo può eccedere la struttura di tempo data per questo studio. Un altro motivo per non adottare il metodo di inchiesta è che i risultati possono soffrire da mancanza di rigore (Yin 1989). La soggettività del ricercatore può influenzare i risultati e le conclusioni. Un altro motivo è che questo metodo è più adatto a ricerche su domande del tipo ‘come’ o ‘perché’ (Yin 1989), mentre la domanda di ricerca per questo studio è del tipo ‘che cosa’. Infine, ma non meno importante, è difficile generalizzare i risultati da appena una o poche inchieste (Galliers 1992, Shanks ed altri 1993). Sulla base di questa spiegazione razionale, il metodo di ricerca di inchiesta non è stato scelto poiché inadatto per questo studio.

3.3.2. Convenienza del metodo di ricerca di indagine

Quando questa ricerca è stata condotta, la pratica di data- warehousing non era stata ampiamente adottata dalle organizzazioni australiane. Quindi, non c’erano molte informazioni per quanto riguarda la loro implementazione all’interno delle organizzazioni australiane. Le informazioni disponibili provenivano dalle organizzazioni che avevano implementato o utilizzato un data warehouse. In questo caso, il metodo di ricerca di indagine è il più adatto poiché permette di ottenere le informazioni che non sono disponibili altrove o nella forma richiesta per analisi (Fowler 1988). In più, il metodo di ricerca di indagine permette al ricercatore di ottenere una buona visione delle pratiche, delle situazioni, o delle viste in un determinato momento (Galliers 1992, Denscombe 1998). Una veduta d’insieme era stata richiesta per aumentare la conoscenza circa l’esperienza australiana di data warehousing.

Ancora, Sonquist e Dunkelberg (1977) dichiarano che i risultati di ricerca di indagine sono più generali di altri metodi.

3.4. Disegno Di Ricerca Di Indagine

L’indagine circa la pratica di data warehousing è stata eseguita nel 1999. La popolazione obiettivo era formata da organizzazioni australiane interessate agli studi di data warehousing, poiché erano probabilmente già informati circa i dati che immagazzinano e, pertanto, potrebbe fornire le informazioni utili per questo studio. La popolazione obiettivo è stata identificata con un’indagine iniziale di tutti i membri australiani del ‘The Data Warehousing Institute’ (Tdwi- aap). Questa sezione discute il disegno della fase di ricerca empirica di questo studio.

3.4.1. Tecnica di raccolta dei dati

Dalle tre tecniche usate comunemente nella ricerca di indagine (cioè questionario via posta, intervista del telefono ed intervista personale) (Nachmias 1976, Fowler 1988, de Vaus 1991), per questo studio è stato adottato il questionario via posta. Il primo motivo per l’adozione di quest’ultimo è che può raggiungere una popolazione sparsa geograficamente (Blalock 1970, Nachmias e Nachmias 1976, Hwang e Lin 1987, de Vaus 1991, Gable 1994). Secondariamente, il questionario via posta è adatto a partecipanti altamente istruiti (Fowler 1988). Il questionario via posta per questo studio è stato indirizzato ai project sponsors del data warehousing, direttori e/o responsabili di progetto. In terzo luogo, i questionari via posta sono adatti quando si ha a disposizione una lista sicura di indirizzi (Salant e Dilman 1994). TDWI, in questo caso, una associazione fidata di data warehousing ha fornito la lista di indirizzi dei relativi membri australiani. Un altro vantaggio del questionario via posta rispetto al questionario via telefono o alle interviste personali è che permette ai dichiaranti di rispondere con maggior esattezza, particolarmente quando i dichiaranti devono consultare le annotazioni o discutere le domande con altra gente (Fowler 1988).

Uno svantaggio potenziale può essere il tempo richiesto per condurre i questionari via posta. Normalmente, un questionario via posta è condotto in questa sequenza: spedire le lettere, aspettare le risposte e mandare la conferma(Fowler 1988, Bainbridge 1989). Quindi, il tempo totale può essere più lungo del tempo richiesto per le interviste personali o per le interviste al telefono. Tuttavia, il tempo totale può essere conosciuto in anticipo (Fowler 1988, Denscombe 1998). Il tempo speso per condurre le interviste personali non può essere conosciuto in anticipo poiché varia da un’intervista all’altra (Fowler 1988). Le interviste telefoniche possono essere più rapide dei questionari via posta e delle interviste personali ma possono avere un alto tasso di mancanza di risposta dovuto all’indisponibilità di alcune persone (Fowler 1988). In più, le interviste telefoniche sono limitate generalmente a liste di domande relativamente corte (Bainbridge 1989).

Un’altra debolezza di un questionario via posta è l’alto tasso di mancanza di risposta (Fowler 1988, Bainbridge 1989, Neuman 1994). Tuttavia, sono state prese delle contromisure, associando questo studio con un’istituzione fidata nel campo del data warehousing (cioè TDWI) (Bainbridge 1989, Neuman 1994), la quale trasmette due lettere di sollecito ai chi non ha risposto (Fowler 1988, Neuman 1994) ed include inoltre una lettera aggiuntiva che spiega lo scopo dello studio (Neuman 1994).

3.4.2. Unità di analisi

Lo scopo di questo studio è ottenere le informazioni circa l’implementazione del data warehousing e l’utilizzo dello stesso all’interno delle organizzazioni australiane. La popolazione obiettivo è costituita da tutte le organizzazioni australiane che hanno implementato, o stanno implementando, i data warehouse. In seguito vengono intestate le singole organizzazioni. Il questionario via posta è stato spedito alle organizzazioni interessate all’adozione di data warehouse. Questo metodo garantisce che le informazioni raccolte provengano dalle risorse più adatte di ogni organizzazione partecipante.

3.4.3. Campione di indagine

La “mailing list” dei partecipanti all’indagine è stata ottenuta da TDWI. A partire da questa lista, 3000 organizzazioni australiane sono state selezionate come base per il campionamento. Una lettera di aggiuntiva spiegava il progetto e lo scopo dell’indagine, insieme ad una scheda per le risposte e una busta prepagata per rinviare il questionario compilato sono state inviate al campione. Delle 3000 organizzazioni, 198 hanno accettato di partecipare allo studio. Era previsto un così piccolo numero di risposte dato il grande numero di organizzazioni australiane che allora avevano abbracciato o stavano abbracciando la strategia di data warehousing all’interno delle loro organizzazioni. Quindi, la popolazione obiettivo per questo studio consiste di sole 198 organizzazioni.

3.4.4. Contenuti del questionario

La struttura del questionario è stata basata sul modello di data warehousing Monash (discusso precedentemente nella parte 2.3). Il contenuto del questionario è stato basato sull’analisi della letteratura presentata nel capitolo 2. Una copia del questionario spedito ai partecipanti all’indagine può essere trovata nell’appendice B. Il questionario è composto da sei sezioni, che seguono le fasi del modello trattato. I seguenti sei paragrafi brevemente ricapitolano il contenuto di ogni sezione.

Sezione A: Informazioni di base sull’organizzazione
Questa sezione contiene le domande relative al profilo delle organizzazioni partecipanti. In più, alcune delle domande sono relative alla condizione del progetto di data warehousing del partecipante. Le informazioni confidenziali quale il nome dell’organizzazione non sono state rivelate nell’analisi di indagine.

Sezione B: Inizio
Le domande in questa sezione sono relative all’attività di inizio di data warehousing. Le domande sono state fatte per quanto riguarda gli iniziatori di progetto, garanti, abilità e conoscenza richieste, gli obiettivi dello sviluppo di data warehousing e le aspettative degli utilizzatori finali.

Sezione C: Progettazione
Questa sezione contiene le domande relative alle attività di pianificazione del data warehouse. In particolare, le domande sono state circa la portata di esecuzione, la durata del progetto, il costo del progetto e l’analisi di costi/benefici.

Sezione D: Sviluppo
Nella sezione di sviluppo ci sono le domande relative alle attività di sviluppo del data warehouse: raccolta di requisiti dell’utilizzatore finale, le fonti di dati, il modello logico dei dati, prototipi, la pianificazione di capienza, architetture tecniche e selezione dei tools di sviluppo del data warehousing.

Sezione E: Funzionamento
Domande di funzionamento relative al funzionamento ed all’estensibilità del data warehouse, come si evolve nella successiva fase di sviluppo. La qualità dei dati, le strategie di refresh dei dati, la granularità dei dati, scalabilità del data warehouse ed i problemi di sicurezza del data warehouse erano fra le tipologie di domande fatte.

Sezione F: Sviluppo
Questa sezione contiene le domande relative all’utilizzo del data warehouse da parte degli utenti finali. Il ricercatore era interessato allo scopo e all’utilità del data warehouse, la revisione e le strategie di addestramento adottati e la strategia di controllo del data warehouse adottata.

3.4.5. Tasso di risposta

Anche se le indagini via posta sono criticate per avere un tasso di risposta basso, sono state adottate delle misure per aumentare il tasso di rendimento (come discusso precedentemente nella parte 3.4.1). Il termine ‘tasso di risposta’ si riferisce alla percentuale di persone in un campione particolare di indagine che risponde al questionario (Denscombe 1998). E’ stata utilizzata la seguente formula per calcolare il tasso di risposta per questo studio:

Numero di persone che hanno risposto
Tasso di risposta = ——————————————————————————– X 100 Numero totale di questionari spediti

3.4.6. Prova Pilota

Prima che il questionario sia spedito al campione, le domande sono state esaminate effettuando le prove pilota, come suggerito da Luck e Rubin (1987), Jackson (1988) e de Vaus (1991). Lo scopo delle prove pilota è di rivelare tutte le espressioni scomode, ambigue e domande di difficile interpretazione, per chiarire qualunque definizioni e termini usati e per identificare il tempo approssimativo richiesto per compilare il questionario (Warwick e Lininger 1975, Jackson 1988, Salant e Dilman 1994). Le prove pilota sono state effettuate selezionando soggetti con caratteristiche simili a quelle dei soggetti finali, come suggerito Davis e Cosenza (1993). In questo studio, sei professionisti di data warehousing sono stati selezionati come i soggetti pilota. Dopo ogni prova pilota, sono state fatte le correzioni necessarie. Dalle prove pilota effettuate, i partecipanti hanno contribuito a rimodellare e reimpostar la versione definitiva del questionario.

3.4.7. Metodi di Analisi Di Dati

I dati di indagine raccolti dai questionari a domanda chiusa sono stati analizzati usando un pacchetto di programmi statistico denominato SPSS. Molte delle risposte sono state analizzate usando le statistiche descrittive. Un certo numero di questionari sono ritornati incompleti. Questi sono stati trattati con maggiore attenzione per accertarsi che i dati mancanti non fossero una conseguenza degli errori di data entry, ma perché le domande non erano adatte per il dichiarante, o il dichiarante ha deciso non rispondere ad una o più domande specifiche. Queste risposte mancanti sono state ignorate durante l’analisi dei dati e sono state codificate come ‘- 9’ per accertare la loro esclusione dal processo di analisi.

Nel preparare il questionario, le domande chiuse sono state precodificate assegnando un numero ad ogni opzione. Il numero allora è stato usato per preparare i dati durante l’analisi (Denscombe 1998, Sapsford e Jupp 1996). Per esempio, c’erano sei opzioni elencate nella domanda 1 della sezione B: consiglio d’amministrazione, esecutivo ad alto livello, dipartimento IT , unità di affari, i consulenti ed altro. Nello schedario di dati di SPSS, è stata generata una variabile per indicare ‘l’iniziatore di progetto’, con sei etichette di valore: ‘1’ per il ‘consiglio d’amministrazione’, ‘2’ per ‘l’esecutivo ad alto livello’ e così via. L’uso della scala di Likertin in alcune delle domande chiuse inoltre ha permesso un’identificazione che non richiede sforzo visto l’utilizzo dei valori numerici corrispondenti inseriti in SPSS. Per le domande con le risposte non esaustive, che non erano reciprocamente esclusive, ogni opzione è stata trattata come una singola variabile con due etichette di valore: ‘1 ‘ per ‘segnata’ e ‘2 ‘ per ‘non segnata’.

Le domande aperte sono state trattate diversamente dalle domande chiuse. Le risposte a queste domande non sono state inserite in SPSS. Al contrario, sono state analizzate a mano. L’uso di questo tipo di domande permette di acquisire informazioni circa le idee liberamente espresse e le esperienze personali nei dichiaranti (Bainbridge 1989, Denscombe 1998). Dove possibile, è stata fatta una categorizzazione delle risposte.

Per l’analisi dei dati, sono usati metodi di semplice analisi statistica, come la frequenza delle risposte, la media, la scarto quadratico medio e la mediana (Argyrous 1996, Denscombe 1998).
Il Gamma test era performante per ottenere misure quantitative delle associazioni tra dati ordinali (Norusis 1983, Argyrous 1996). Questi test erano appropriati perché le scale ordinali usate non avevano molte categorie e potevano essere mostrate in una tabella (Norusis 1983).

3.5 Sommario

In questo capitolo, sono stati discussi la metodologia di ricerca e il design adottati per questo studio.

La selezione del più appropriato metodo di ricerca per un particolare studio prende in
considerazione un certo numero di regole, inclusa la natura e il tipo della ricerca, così come i meriti e le debolezze di ogni possibile metodo(Jenkins 1985, Benbasat et al. 1097,Galliers e Land 1987, yin 1989, Hamilton e ives 1992, Galliers 1992, neuman 1994). Vista la mancanza di conoscenza e teoria esistenti a proposito dell’adozione di data warehousing in Australia, questo studio di ricerca richiede un metodo di ricerca interpretativo con una abilità esplorativa per esplorare le esperienze delle organizzazioni australiane. Il metodo di ricerca prescelto è stato selezionato per raccogliere informazioni riguardanti l’adozione del concetto di data ware-housing da parte delle organizzazioni australiane. Un questionario postale è stato scelto come tecnica di raccolta dati. Le giustificazioni per il metodo di ricerca e la tecnica di raccolta dati selezionati saranno fornite in questo capitolo. Inoltre è stata presentata una discussione sull’unità di analisi,il campione utilizzato, le percentuali di risposte, il contenuto del questionario, il pre test del questionario e il metdo di analisi dei dati.

Designing a Data Warehouse:

Combining Entity Relationship and Dimensional Modelling

ABSTRACT
Immagazzinare i dati è un problema attuale importante per molte organizzazioni. Un problema chiave nello sviluppo dell’immagazzinamento dei dati è il suo disegno.
Il disegno deve sostenere il rilevamento di concetti nel data warehouse a legacy system e le altre fonti di dati ed anche una facile comprensione ed efficienza nell’implementazione di data warehouse.
Molta della letteratura di immagazzinamento dei dati raccomanda l’uso di entity relationship modelling or dimensional modelling per rappresentare il disegno di data warehouse.
In questo giornale noi mostriamo come entrambe le rappresentazioni possono essere combinate in un approccio per il disegno di data warehouse. L’approccio usato è sistematicamente

esaminato in un caso di studio ed è identificato in un numero di importanti implicazioni con professionisti.

DATA WAREHOUSING

Un data warehouse di solito è definito come un “subject-oriented, integrated, time-variant, and nonvolatile collection of data in support of management’s decisions” (Inmon and Hackathorn, 1994). Subject-oriented and integrated indica che il data warehouse è progettato per attraversare i confini funzionali dei legaci system per offrire una prospettiva integrata dei dati.
Time-variant interessa lo storico o la natura time-series dei dati in un data warehouse, la quale abilita trend per essere analizzati. Non-volatile indica che il data warehouse non è continuamente aggiornato come un database di OLTP. Piuttosto è aggiornato periodicamente, con dati provenienti da fonti interne ed esterne. Il data warehouse specificatamente è disegnato per la ricerca piuttosto che per l’integrità degli aggiornamenti e le prestazioni delle operazioni.
L’idea di immagazzinare i dati non è nuova, è stato uno degli scopi di gestione dei dati fin dagli anni sessanta (Il Martin, 1982).
I data warehouse offrono l’infrastruttura dati per management support systems. Management support systems includono decision support systems (DSS) and executive information systems (EIS). Un DSS è un sistema di informazioni computer-based che è progettato per migliorare il processo e di conseguenza la presa di decisione umana. Un EIS è tipicamente un sistema di consegna di dati che abilita dirigenti d’azienda ad accedere facilmente alla vista dei dati.
L’architettura generale di un data warehouse evidenzia il ruolo del data warehouse nel supporto alla gestione. Oltre ad offrire l’infrastruttura dati per EIS e DSS, al data warehouse è possibile accedervi direttamente attraverso le query. I dati inclusi in un data warehouse si basano su un’analisi dei requisiti di informazioni di gestione e sono ottenuti da tre fonti: internal legacy systems, special purpose data capture systems and external data sources. I dati negli internal legacy systems sono frequentemente ridondanti, inconsistenti, di bassa qualità, e immagazzinati in diversi formati quindi devono essere riconciliati e puliti prima di poterli caricare nel

data warehouse (Inmon, 1992; McFadden, 1996). I dati provenienti da sistemi di immagazzinamento dati ad hoc e da sorgenti dati esterne sono speso usati per aumentare (aggiornare, sostituire) i dati da sistemi legacy.

Ci sono molte ragioni irresistibili per sviluppare un data warehouse, che includono una migliore presa di decisione attraverso l’uso effettivo di più informazioni (Ives 1995), il supporto per un focus sugli affari completi (Graham 1996), e la riduzione in costi di provvedimento di dati per EIS e DSS (Graham 1996, McFadden 1996).

Un recente studio empirico ha scoperto, in media, un ritorno degli investimenti per i data warehouse del 401% dopo tre anni (Graham, 1996). Comunque, gli altri studi empirici di data warehouse hanno trovato significanti problemi incluso la difficoltà nel misurare ed assegnare benefici, mancanza di un scopo chiaro, sottovalutando lo scopo e la complessità del processo di immagazzinare i dati, in particolare quanto riguarda le fonti e la pulizia dei dati. Immagazzinare i dati può essere considerato come una soluzione al problema di gestione dei dati fra le organizzazioni. La manipolazione dei dati come risorsa sociale è rimasto uno dei problemi chiave nella gestione di sistemi di informazioni in tutto il mondo per molti anni (Brancheau et al. 1996, Galliers et al. 1994, Niederman et al. 1990, Pervan 1993).

Un approccio popolare alla gestione dei dati negli anni ottanta era lo sviluppo di un modello dati sociale. Il modello dati sociale fu pensato per offrire una base stabile per lo sviluppo di nuovi sistemi applicativi e database e la ricostruzione e l’integrazione di legacy systems (Brancheau et al.

1989, Goodhue et al. 1988:1992, Kim and Everest 1994). Comunque, ci sono molti problemi con questo approccio, in particolare, la complessità e il costo di ogni task, ed il lungo tempo richiesto per avere risultati tangibili (Beynon-Davies 1994, Earl 1993, Goodhue et al. 1992, Periasamy 1994, Shanks 1997).

Il data warehouse è un databse separato che co-esiste coi legacy databases piuttosto che sostituirli. Esso perciò consente di indirizzare la gestione dei dati ed evitare la costosa ricostruzione dei legacy systems.

APPROCCI ESISTENTI AL DISEGNO DI DATA

WAREHOUSE

Il processo di costruzione e perfezionamento di un data warehouse va compreso più come un processo evolutivo piuttosto che un lifecycle di sviluppo di sistemi tradizionali (Desio, 1995, Shanks, O’Donnell and Arnott 1997a ). Ci sono molti processi coinvolti in un progetto di data warehouse come inizializzazione, pianificazione; informazioni acquisite dai requisiti chieste ai dirigenti d’azienda; fonti, trasformazioni, pulizia dei dati e di sincronizzazione da legacy systems e le altre fonti di dati; sistemi di consegna in sviluppo; monitoraggio dei data warehouse; e insensatezza del processo evolutivo e di costruzione di un data warehouse (Stinchi, O’Donnell ed Arnott 1997b). In questo giornale, noi focalizziamo su come disegnare i dati immagazzinati nel contesto di questi altri processi. Ci sono un numero di approcci proposti per l’architettura dei data warehouse nella letteratura (Inmon 1994, Ives 1995, Kimball 1994 McFadden 1996). Ognuna di queste metodologie ha una breve rassegna con un’analisi dei loro punti di forza e non.

Inmon’s (1994) Approach for Data Warehouse Design

Inmon (1994) propose quattro passi iterativi per disegnare un data warehouse (veda Figura 2). Il primo passo è progettare un modello dati sociale per capire come i dati possono essere integrati attraverso aree funzionali all’interno di un’organizzazione suddividendo i dati immagazzini in aree. Il modello dati è fatto per immagazzinare dati attinenti a prese di decisione, incluso dati storici, ed incluso dati dedotti ed aggregati. Il secondo passo è identificare aree soggette per la realizzazione. Questi sono basati su priorità determinate da una particolare organizzazione. Il terzo passo comporta il disegno di un database per l’area soggetta, pone particolare attenzione a includere appropriati livelli di granularità. Inmon raccomanda di usare il modello entità e relazioni. Il quarto passo è identificare sistemi di fonti dati richiesti e sviluppare processi di trasformazione per acquisire, pulire e formattare i dati.

Le forze dell’approccio di Inmon sono che il modello dati sociale offre la base per l’integrazione di dati all’interno dell’organizzazione e pianificazione di supporti per lo sviluppo iterativo di data warehouse. Le sue pecche sono la difficoltà e il costo nel disegnare il modello dati sociale, la difficoltà nel capire modelli di entità e relazioni usati in ambo i modelli, quello dati sociale e quello di dati immagazzinati per area soggetto, e l’appropriatezza dei dati del disegno di data warehouse per la realizzazione di database relazionali ma non per database multi-dimensionali.

Ives’ (1995) Approach to Data Warehouse Design

Ives (1995) propone un approccio di quattro passi per disegnare un sistema informativo che lui ritiene applicabile al disegno di un data warehouse (veda Figura 3). L’approccio è molto basato sull’ Information Engineering per lo sviluppo di sistemi di informazioni (Martin 1990). Il primo passo è determinare gli obiettivi, i fattori critici e di successo e gli indicatori chiave delle prestazioni. I processi chiave di business e le informazioni necessarie sono modellate per condurci ad un modello dati sociale. Il secondo passo comporta lo sviluppo di un architettura che definisce dati immagazzinati per aree, database di data warehouse, i componenti di tecnologia che sono richiesti, l’insieme di supporto organizzativo richiesto per implementare ed operare con data warehouse. Il terzo passo include la selezione di pacchetti software e attrezzi richiesti. Il quarto passo è il disegno particolareggiato e la costruzione del data warehouse. Ives nota che immagazzinare dati è un vincolato processo iterativo.

La forza dell’approccio di Ives sono l’uso di specifiche tecniche per determinare i requisiti d’informazione, l’uso di uno strutturato processo per sostenere l’integrazione dei data warehouse, l’opportuna selezione hardware e software, e l’uso di molteplici tecniche di rappresentazione per il data warehouse. Le sue pecche sono inerenti alla complessità. Altre includono la difficoltà nello sviluppare molti livelli di database all’interno del data warehouse in tempi e costi ragionevoli.

Kimball’s (1994) Approach to Data Warehouse Design

Kimball (1994) propose cinque passi iterativi per disegnare un data warehouse (vedi Figuri 4). Il suo approccio è particolarmente dedicato sul disegno di un solo data warehouse e sull’uso di modelli dimensionali in preferenza a modelli di entità e relazioni. Kimball analizza quei modelli dimensionali perché è più facile capire per i dirigenti d’azienda gli affari, è più efficiente quando si trattano consultazioni complesse, e il disegno di database fisico è più efficiente (Kimball 1994). Kimball riconosce che lo sviluppo di un data warehouse è iterativo, e che data warehouse separati possono essere integrati attraverso la ripartizione in tavole di dimensioni comuni.

Il primo passo è identificare la particolare area soggetto per essere perfezionato. Il secondo e terzo passo concernono modellatura dimensionale. Nel secondo passo le misure identificano cose di interesse nell’area soggetto e raggruppate in una tabella dei fatti. Per esempio, in un’area di soggetto di vendite le misure di interesse potrebbero includere l’ammontare di articoli venduto ed il dollaro come valuta di vendite. Il terzo passo comporta l’identificazione di dimensioni che sono i modi nei quali possono essere raggruppati i fatti. In un’area di soggetto di vendite, dimensioni attinenti potrebbero includere articolo, ubicazione e tempo periodo. La tabella dei fatti ha una chiave multi- part per collegarla ad ognuna delle tabelle di dimensione e tipicamente contiene un numero molto grande di fatti. In contrasto, tavole di dimensione contengono descrittive informazioni sulle dimensioni e gli altri attributi che possono essere usati per raggruppare i fatti. La tabella dei fatti e dimensioni associata proposta forma quello che è chiamato uno schema a stella a causa della sua forma. Il quarto passo comporta la costruzione di un database multidimensionale per perfezionare lo schema della stella. Il passo finale è identificare sistemi di fonti dati richiesti e sviluppare processi di trasformazione per acquisire, pulire e formattare i dati.

Le forze dell’approccio di Kimball includono l’uso di modelli dimensionali per rappresentare i dati immagazzinati che lo rendono facile da capire e conduce ad un disegno fisico efficiente. Un modello dimensionale che usa prontamente anche entrambi i sistemi di database relazionali può essere perfezionato o sistemi di database multidimensionali. Le sue pecche includono la mancanza di alcune tecniche per facilitare la pianificazione o l’integrazione di molti schemi della stella all’interno di un data warehouse e la difficoltà di progettare dall’estrema struttura denormalizzata in un modello dimensionale a dati in legacy system.

McFadden’s (1996) Approach to Data Warehouse Design

McFadden (1996) propone un approccio di cinque passi per disegnare un data warehouse (vedi Figura 5).
Il suo approccio è basato su una sintesi delle idee dalla letteratura ed è focalizzato sul disegno di un solo data warehouse. Il primo passo comporta un’analisi dei requisiti. Anche se le specifiche tecniche non sono prescritte, le note di McFadden identificano le entità dati specifiche ed i loro attributi, e si riferisce ai lettori Watson e Frolick (1993) per l’acquisizione dei requisiti.
Nel secondo passo viene disegnato un modello entità relazioni per data warehouse e poi convalidato dai dirigenti d’azienda. Il terzo passo comprende la determinazione del mapping da legacy system e fonti esterne di data warehouse. Il quarto passo comporta processi in sviluppo, la distribuzione e sincronizzazione di dati nel data warehouse. Nel passo finale, la consegna del sistema è sviluppata con particolare enfasi su un’interfaccia utente. McFadden fa notare che il processo di disegno è generalmente iterativo.

Le forze dell’approccio di McFadden puntano sulla partecipazione da parte dei dirigenti d’azienda nel determinare i requisiti ed anche l’importanza delle risorse dati, la loro pulizia e raccolta. Le sue pecche riguardano la mancanza di un processo per suddividere un grande progetto di data warehouse in molti stages integrati, ed la

difficoltà nel capire i modelli di entità e relazione usati nel disegno di data warehouse.

Non ci sceglie solo chi è vicino a noi.