Data Warehousing e Infrastructure Challenge - dummies

La natura di un data warehouse (che è composto principalmente, o esclusivamente, di dati che provengono da altrove, altre applicazioni database, e viene convertito in un asset di dati) significa che non può essere considerato un'entità indipendente all'interno della propria organizzazione.

La crescita fenomenale del calcolo distribuito (Internet e Intranet, nonché dati interni ed esterni di data warehousing) ha portato a un cambiamento fondamentale nel modo in cui le applicazioni sono costruite.A vecchi tempi di mainframe e minicomputer, un singolo sistema fisico in gran parte conteneva l'infrastruttura (sistemi operativi, database e file system e comunicazioni e gestori delle transazioni).

< ! --1 ->

Con il calcolo distribuito ora il modello dominante (anche i mainframe ei minicomputer fanno solitamente parte di un ambiente distribuito più grande), l'infrastruttura è distribuita su molti diversi p informazioni su tutta la tua azienda e possibilmente al di fuori della tua azienda.

Quando sviluppi un'applicazione o un sistema, sia di data warehousing che di un'applicazione di elaborazione delle transazioni più tradizionale, hai dipendenze significative su parti dell'ambiente generale su cui non hai controllo diretto. Ecco alcuni esempi specifici per il data warehousing:

• Si progetta un data warehouse che, in base ai requisiti di business e alle politiche di disponibilità dei dati delle applicazioni, deve avere circa 25 gigabyte di dati nuovi e aggiornati estratti da varie sorgenti ogni sera e inviati in rete al piattaforma hardware su cui è in esecuzione il data warehouse.

  L'infrastruttura di rete aziendale è ancora sottodimensionata. Dopo un'ulteriore analisi, la rete non può avvicinarsi a supportare il throughput necessario per spostare i dati nel proprio magazzino nella finestra temporale disponibile.

• Durante la fase di validità del progetto di data warehousing, si determina che una strategia push per aggiornare il data warehouse è il modello più appropriato da seguire. Per implementare una strategia push, tuttavia, è necessario modificare ciascuna applicazione di origine per includere il codice che rileva quando tale applicazione deve inviare (inviare) i dati nel data warehouse.

  Le applicazioni legacy che forniscono dati al magazzino sono, sfortunatamente, così difficili da comprendere che una politica di non apportare modifiche a meno che non sia assolutamente necessario è valida per ciascuna applicazione.

• Si decide di perseguire una soluzione relazionale OLAP (o ROLAP) ed eseguire una serie di benchmark su tre prodotti DBMS relazionali (RDBMS) per vedere quale meglio supporta l'elaborazione di informazioni e supporto decisionale (piuttosto che l'elaborazione delle transazioni).

  Il prodotto che ha ottenuto risultati peggiori nei benchmark è, sfortunatamente, anche il tuo standard aziendale e qualsiasi database relazionale installato in qualsiasi punto della tua azienda deve essere di questa varietà, indipendentemente da come prevedi di usarlo.

Pensa concettualmente (senza preoccuparti dei dettagli di implementazione) nelle prime fasi di un progetto di data warehousing, o qualsiasi altro sforzo di sviluppo di applicazioni - non è solo accettabile, è anche una buona pratica di sviluppo dei sistemi.

Ad un certo punto, tuttavia, è necessario considerare hardware, software, costi, budget e altri tipi di vincoli reali. Prima di iniziare la costruzione, assicurati di prendere in considerazione tutto ciò che può influire sui tuoi progetti e piani per il tuo data warehouse.

Questo progetto è molto simile alla costruzione di una casa. Segui un processo in base al quale determini le tue esigenze e poi l'architetto redige i progetti. I progetti evidenziano i materiali necessari per supportare le vostre esigenze - assicurando che il prodotto finito soddisfi la visione stabilita all'inizio.