fbpx

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