Video: Ottimizzazione dei processi aziendali, il ruolo di Explora Process 2025
Intorno al 1995, i fornitori iniziarono a posizionare il loro software come strumenti di data warehousing virtuali. La premessa fondamentale era che a volte non ha senso copiare e manipolare un gruppo di dati, nel caso qualcuno ne avesse bisogno. Perché non accedere ai dati direttamente dalla sorgente in base alle necessità?
Purtroppo, l'accesso ai dati su una rete alla fonte si è dimostrato il meno impegnativo dei problemi nel tentativo di fornire un tipo di data warehouse sul posto. Le stesse sfide affrontate in qualsiasi ambiente di data warehousing (come occuparsi della qualità dei dati, decidere quali tipi di trasformazioni devono verificarsi e scegliere come gestire tali trasformazioni quando fonti diverse sono incoerenti) sono ancora presenti.
Solo perché è possibile accedere ai dati all'origine (in quasi tutti i database o la struttura dei file) non significa che i dati forniscano la necessaria business intelligence quando è nelle tue mani.
Per risolvere questi problemi relativi alla qualità dei dati, molti architetti di dati hanno iniziato a realizzare una costruzione di data mart bottom-up per sviluppare un data warehouse basato su componenti. Anziché disporre di un singolo database nel quale vengono inseriti tutti i dati (creazione del data warehouse), una serie di componenti gestisce ciascuno un determinato insieme di funzioni (come la risposta a domande aziendali specifiche) o determinati argomenti. Insieme, questi data mart (o componenti) comprendono un ambiente di data warehousing.
Questa architettura di dati di accesso dinamico basata su componenti è la base per il data warehousing virtuale e, in particolare, quali server Enterprise Information Integration (EII) offrono al mercato.
Questa figura mostra un ambiente in cui i singoli componenti vengono creati all'interno dell'ambiente di data warehousing in modo bottom-up. Invece di combinare i componenti in un unico grande database (e copiare di nuovo tutti i dati), EII crea un ambiente di data warehousing in cui gli utenti possono accedere ai contenuti di ogni componente da uno strumento di business intelligence come se fossero tutti archiviati, anche se non lo sono.
Pensa a come usi un browser Web sul desktop. Fai clic su un link o digita un URL specifico e l'ambiente, lavorando dietro le quinte, ti porta nel posto giusto per il contenuto che hai richiesto. Ora, immagina che Internet funzioni molto più velocemente.
Quando vai su vari siti, non stai consultando gli annunci per l'ultima trazione integrale che hai desiderato, i risultati sportivi, i cartoni di Dilbert o qualsiasi altra cosa tu faccia su Internet.Stai recuperando pezzi di dati che vengono poi combinati e inviati al tuo browser. Questo è il data warehousing virtuale - è proprio come Internet!
Non è una buona idea creare un ambiente di data warehousing virtuale per accedere direttamente ai dati di origine, nel suo formato nativo. La tua sfida non è capire come unire i database multipiattaforma (ad esempio, combinando i dati IMS con i dati DB2) e gestire questi tipi di trasformazione a livello di sistema, significa garantire che la qualità dei dati sia elevata e non richieda l'utente per pulire manualmente i dati.
Ogni applicazione deve quindi essere abilitata al magazzino e contenere un editore di dati responsabile di tutti i servizi middleware (come l'estrazione e la garanzia della qualità), come specificato nelle regole aziendali dell'ambiente.
L'editore di dati potrebbe in teoria funzionare quasi in modalità tempo reale, come dovrebbe fare in un archivio dati operativo, o potrebbe funzionare in modalità periodica (orientata ai batch) se non sono richiesti aggiornamenti istantanei. In questa situazione, l'editore di dati è un prodotto mini-middleware incorporato nell'applicazione (o un servizio accessibile dall'applicazione).
Quando si pensa al data warehousing virtuale, sostituire la domanda "Posso accedere ai dati? "Con la domanda" Posso ottenere dati utilizzabili? "L'editore di dati svolge un ruolo importante e non dovrebbe essere trascurato.
Inoltre non puoi trascurare l'architettura dei dati. Solo perché stai sviluppando i componenti in modo bottom-up e il loro accesso è in atto, piuttosto che essere copiati in un database di data warehouse più grande, non significa che puoi trascurare questa funzione.
Supponiamo che un componente memorizzi gli ID cliente come numeri a cinque cifre dopo la trasformazione e contenga solo i clienti che hanno effettuato acquisti negli ultimi sei mesi. E un altro componente, che contiene tutti i clienti che hanno acquistato i prodotti della tua azienda, utilizza identificatori alfanumerici di sette caratteri. In questa situazione, potresti avere lo stesso tipo di problemi di mancata corrispondenza dei dati che avresti se accedessi ai dati direttamente dai sorgenti.
Sebbene EII consenta differenze tra i contenuti dei componenti, è necessario comprendere e gestire le differenze in modo da non ostacolare la missione di business intelligence.
