Da: Arshad Ali | Aggiornamento: 2013-06-24 | Commenti (9) e Relativi a: > Analisi dei Servizi di Sviluppo
Problema
Nel mio ultimo paio di consigli, ho parlato dell’importanza di una soluzione di Business Intelligence, perché sta diventando priorità forexecutives, ciò che un tipico sistema di Business Intelligence architettura sembra, etc. In questo suggerimento, parlerò in dettaglio di come un data warehouse è diverso dall’archivio dati operativo e dalle diverse metodologie di progettazione per un data warehouse.
Soluzione
Questo suggerimento riguarderà i Data Warehouse (DW, a volte chiamato anche Enterprise Data Warehouse o EDW), in che modo si differenzia da Operational Data Store (ODS) e diverse metodologie di progettazione del Data Warehouse.
Magazzino dati aziendale (EDW o DW) Vs. Operational Data Store (ODS)
Lo scopo del Data Warehouse nell’architettura complessiva della Business Intelligence è quello di integrare i dati aziendali provenienti da diverse fonti di dati eterogenee al fine di facilitare il reporting di analisi storica e di tendenza. Agisce come un repository centrale e contiene la “versione singola della verità” per l’organizzazione che è stata accuratamente costruita dai dati memorizzati in database operativi interni ed esterni disparati\sistemi. Per prestazioni migliori, per lo più i dati nel data warehouse saranno in forma de-normalizzata che può essere classificata in schemi a stella o a fiocco di neve (maggiori informazioni su questo nel prossimo suggerimento).
Lo scopo di Operation Data Store (ODS) è quello di integrare i dati aziendali provenienti da diverse fonti di dati eterogenee al fine di facilitare il reporting operativo in tempo reale o quasi in tempo reale. Spesso i dati in ODS saranno strutturati in modo simile ai sistemi di origine, anche se durante l’integrazione può comportare la pulizia dei dati, la de-duplicazione e può applicare regole aziendali per garantire l’integrità dei dati. Un ODS è destinato principalmente a integrare i dati abbastanza frequentemente al livello granulare più basso per la segnalazione operativa in uno scenario di integrazione dei dati quasi in tempo reale. Normalmente, un ODS non sarà ottimizzato per l’analisi storica e di tendenza su un enorme insieme di dati.
Riassumiamo le differenze tra un ODS e DW:
- ODS si intende per attività di reporting operativo e supporta la corrente o ” near real time reporting requisiti whereasa DW è pensato per storica e l’analisi delle tendenze di reporting su un grande volume di dati
- ODS è destinato a basso granulare query, mentre un DW è utilizzato per il complesso query di riepilogo o sui dati aggregati
- ODS fornisce informazioni operative, decisioni tattiche attuale, o in prossimità di dati in tempo reale acquisizione whereasa DW fornisce un feedback per le decisioni strategiche che conduce al complessivo sistema di miglioramenti
- In un ODS l’ la frequenza di caricamento dei dati, potrebbe essere oraria o giornaliera, mentre in un DWthe frequenza di carichi di dati può essere giornaliero, settimanale, mensile o trimestrale
Metodologie di Progettazione di Data Warehouse
Ci sono due diverse metodologie di solito seguita durante la progettazione di una soluzione di Data Warehouse e basato sulle esigenze del vostro progetto che si può scegliere quale si adatta il vostro scenario. Queste metodologie sono il risultato della ricerca di BillInmon e Ralph Kimball.
Bill Inmon – Top-down dei Dati di Magazzino Approccio di Progettazione
Bill Inmon è a volte indicato anche come il “padre di data warehousing”; la sua metodologia di progettazione basata ona approccio top-down e definisce il data warehouse in questi termini
- Subject oriented – I dati in un data warehouse è classificato sulla base della disciplina e, quindi, non è “soggetto oriented”.
- Integrato-I dati vengono integrati da diverse fonti di dati disparate e quindi convenzioni di denominazione universali, misurazioni, classificazioni e così via utilizzate nel data warehouse. Il data warehouse fornisce una visione consolidata aziendale dei dati e quindi è designato come una soluzione integrata.
- Non volatile – Una volta che i dati sono integrati\caricati nel data warehouse, possono essere letti solo. Gli utenti non possono apportare modifiche ai dati e thispractice rende i dati non volatili.
- Variante temporale – Infine i dati vengono memorizzati per lunghi periodi di tempo quantificati in anni e hanno una data e un timestamp e quindi sono descritti come”variante temporale”.
Bill Inmon ha visto la necessità di integrare i dati provenienti da diversi sistemi OLTP in un repository centralizzato (chiamato data warehouse) con un cosiddetto approccio top-down. Bill Inmon prevede un data warehouse al centro della” Corporate Information Factory ” (CIF), che fornisce un framework logico per la fornitura di business intelligence (BI), business analytics e funzionalità di gestione aziendale.
Questo design dall’alto verso il basso fornisce una visione dimensionale altamente coerente dei dati tra i data mart poiché tutti i data mart vengono caricati dal repository centralizzato (Data Warehouse).Il design top-down ha anche dimostrato di essere flessibile per supportare i cambiamenti aziendali in quanto guarda l’organizzazione nel suo complesso, non ad ogni funzione o processo aziendale dell’organizzazione. Generare un nuovo data mart dimensionale rispetto ai dati memorizzati inil data warehouse è un’attività relativamente semplice. Sebbene ci siano alcune sfide per l’approccio top-down, ad esempio rappresenta un progetto molto ampio con un ambito molto ampio e quindi il costo iniziale per l’implementazione di un data warehouse utilizzando la metodologia top-down è significativo.Inoltre, la durata del tempo dall’inizio del progetto al punto che gli utenti finali iniziano a sperimentare i vantaggi iniziali della soluzione può essere sostanziale. Inoltre, la metodologia top-down può essere inflessibile e non risponde alle mutevoli esigenze dei processi dipartimentali o aziendali (una preoccupazione per l’ambiente in continua evoluzione dinamica) durante la fase di implementazione.
Ralph Kimball – Bottom-up Data Warehouse Design Approach
Ralph Kimball è un famoso autore sul tema del data warehousing. La sua metodologia di progettazione è chiamata modellazione dimensionalethe metodologia Kimball. Questa metodologia si concentra su un approccio bottom-up, sottolineando il valore del data warehouse per gli utenti il più rapidamente possibile. Nella sua visione, un data warehouse è la copia dei dati transazionali specificamente strutturati per l’interrogazione analitica e il reporting al fine di supportare il sistema di supporto decisionale. Secondo la sua metodologia, i data mart vengono creati per fornire funzionalità di reporting e analisi per processi specifici di business\funzionali e in seguito questi data mart possono essere combinati insieme per creare un data warehouse aziendale completo. L’approccio bottom-up si concentra su ogni processo di business a un certo punto di timeso il ritorno sull’investimento potrebbe essere veloce come primo data mart viene creato. Sebbene se non pianificato con cura, potrebbe mancare il quadro generale del data warehouse aziendale perdendo alcune dimensioni o creando dimensioni ridondanti,ecc. quando si è troppo concentrati su un processo di business individuale.
L’approccio bottom-up di Ralph Kimball propone di creare una matrice aziendale che dovrebbe contenere tutti gli elementi comuni (che vengono utilizzati dai data mart come conformed\shared dimension, measures, ecc.) definito per l’impresa nel suo complesso. Con questo, l’utente può progettare e sviluppare soluzioni che supportano l’analisi attraverso i processi aziendali per il cross selling. Puoi saperne di più sula matrice qui.
Per una persona che vuole fare carriera nel Data Warehouse e nel dominio di Business Intelligence, consiglierei di studiare i libri di Bill Inmon (Building the Data Warehouse e DW 2.0: L’architettura per la prossima generazione di Data Warehousing) e il libro di Ralph Kimball (The Microsoft Data Warehouse Toolkit).
Prossimi passi
- ReviewMicrosoft SQL Server Business Intelligence – Cosa, perché e come – Parte 1.
- ReviewMicrosoft SQL Server Business Intelligence System Architecture-Parte 2.
- di sql Server Business Intelligence consigli su MSSQLTips.com.
Ultimo Aggiornamento: 2013-06-24
Circa l’autore
Arshad Ali è un SQL e BI Developer concentrandosi su progetti di Data Warehousing per Microsoft.Visualizza tutti i miei suggerimenti
- Altri suggerimenti di Business Intelligence…
