Data Warehousing - Guida rapida

Il termine "Data Warehouse" è stato coniato per la prima volta da Bill Inmon nel 1990. Secondo Inmon, un data warehouse è una raccolta di dati orientata al soggetto, integrata, variante temporale e non volatile. Questi dati aiutano gli analisti a prendere decisioni informate in un'organizzazione.

Un database operativo è soggetto a frequenti modifiche su base giornaliera a causa delle transazioni che avvengono. Supponiamo che un dirigente aziendale desideri analizzare il feedback precedente su qualsiasi dato come un prodotto, un fornitore o qualsiasi dato del consumatore, quindi il dirigente non avrà dati disponibili da analizzare perché i dati precedenti sono stati aggiornati a causa delle transazioni.

Un data warehouse ci fornisce dati generalizzati e consolidati in una vista multidimensionale. Insieme a una visualizzazione dei dati generalizzata e consolidata, un data warehouse ci fornisce anche strumenti OLAP (Online Analytical Processing). Questi strumenti ci aiutano nell'analisi interattiva ed efficace dei dati in uno spazio multidimensionale. Questa analisi si traduce nella generalizzazione dei dati e nel data mining.

Le funzioni di data mining come associazione, clustering, classificazione e previsione possono essere integrate con le operazioni OLAP per migliorare l'estrazione interattiva della conoscenza a più livelli di astrazione. Ecco perché il data warehouse è ora diventato un'importante piattaforma per l'analisi dei dati e l'elaborazione analitica online.

Capire un data warehouse

• Un data warehouse è un database, tenuto separato dal database operativo dell'organizzazione.

• Non vengono eseguiti aggiornamenti frequenti in un data warehouse.

• Possiede dati storici consolidati, che aiutano l'organizzazione ad analizzare il proprio business.

• Un data warehouse aiuta i dirigenti a organizzare, comprendere e utilizzare i propri dati per prendere decisioni strategiche.

• I sistemi di data warehouse aiutano nell'integrazione della diversità dei sistemi applicativi.

• Un sistema di data warehouse aiuta nell'analisi dei dati storici consolidati.

Perché un data warehouse è separato dai database operativi

Un data warehouse è tenuto separato dai database operativi per i seguenti motivi:

• Un database operativo è costruito per compiti e carichi di lavoro ben noti come la ricerca di record particolari, l'indicizzazione, ecc. Nel contratto, le query del data warehouse sono spesso complesse e presentano una forma generale di dati.

• I database operativi supportano l'elaborazione simultanea di più transazioni. Il controllo della concorrenza e i meccanismi di ripristino sono necessari affinché i database operativi garantiscano la robustezza e la coerenza del database.

• Una query di database operativa consente di leggere e modificare le operazioni, mentre una query OLAP necessita solo read only accesso ai dati memorizzati.

• Un database operativo conserva i dati correnti. D'altra parte, un data warehouse conserva i dati storici.

Caratteristiche del data warehouse

Le caratteristiche principali di un data warehouse sono discusse di seguito:

• Subject Oriented- Un data warehouse è orientato al soggetto perché fornisce informazioni su un argomento piuttosto che sulle operazioni in corso dell'organizzazione. Questi soggetti possono essere prodotti, clienti, fornitori, vendite, ricavi, ecc. Un data warehouse non si concentra sulle operazioni in corso, ma piuttosto sulla modellazione e analisi dei dati per il processo decisionale.

• Integrated - Un data warehouse viene costruito integrando dati da fonti eterogenee come database relazionali, file flat, ecc. Questa integrazione migliora l'analisi efficace dei dati.

• Time Variant- I dati raccolti in un data warehouse sono identificati con un determinato periodo di tempo. I dati in un data warehouse forniscono informazioni dal punto di vista storico.

• Non-volatile- Non volatile significa che i dati precedenti non vengono cancellati quando vengono aggiunti nuovi dati. Un data warehouse viene tenuto separato dal database operativo e pertanto le frequenti modifiche nel database operativo non si riflettono nel data warehouse.

Note - Un data warehouse non richiede l'elaborazione delle transazioni, il ripristino e i controlli di concorrenza, poiché è archiviato fisicamente e separato dal database operativo.

Applicazioni di data warehouse

Come discusso in precedenza, un data warehouse aiuta i dirigenti aziendali a organizzare, analizzare e utilizzare i propri dati per il processo decisionale. Un data warehouse funge da unica parte di un sistema di feedback "a ciclo chiuso" per la gestione aziendale. I data warehouse sono ampiamente utilizzati nei seguenti campi:

• Servizi finanziari
• Servizi bancari
• Beni di consumo
• Settori di vendita al dettaglio
• Produzione controllata

Tipi di data warehouse

Elaborazione delle informazioni, elaborazione analitica e data mining sono i tre tipi di applicazioni di data warehouse discussi di seguito:

• Information Processing- Un data warehouse consente di elaborare i dati in esso archiviati. I dati possono essere elaborati mediante interrogazione, analisi statistica di base, reportistica utilizzando campi incrociati, tabelle, grafici o grafici.

• Analytical Processing- Un data warehouse supporta l'elaborazione analitica delle informazioni in esso memorizzate. I dati possono essere analizzati mediante operazioni OLAP di base, tra cui slice-and-dice, drill down, drill up e pivoting.

• Data Mining- Il data mining supporta la scoperta della conoscenza trovando schemi e associazioni nascosti, costruendo modelli analitici, eseguendo la classificazione e la previsione. Questi risultati di mining possono essere presentati utilizzando gli strumenti di visualizzazione.

Sr.No.	Data Warehouse (OLAP)	Database operativo (OLTP)
1	Implica l'elaborazione storica delle informazioni.	Coinvolge l'elaborazione quotidiana.
2	I sistemi OLAP sono utilizzati da knowledge worker quali dirigenti, manager e analisti.	I sistemi OLTP vengono utilizzati da impiegati, amministratori di database o professionisti del database.
3	Viene utilizzato per analizzare l'attività.	Viene utilizzato per gestire l'attività.
4	Si concentra sull'informazione fuori.	Si concentra sui dati in formato.
5	Si basa su Star Schema, Snowflake Schema e Fact Constellation Schema.	Si basa sul modello di relazione tra entità.
6	Si concentra sull'informazione fuori.	È orientato all'applicazione.
7	Contiene dati storici.	Contiene dati correnti.
8	Fornisce dati riepilogati e consolidati.	Fornisce dati primitivi e altamente dettagliati.
9	Fornisce una vista riepilogativa e multidimensionale dei dati.	Fornisce una vista relazionale dettagliata e piatta dei dati.
10	Il numero di utenti è in centinaia.	Il numero di utenti è in migliaia.
11	Il numero di record a cui si accede è in milioni.	Il numero di record a cui si accede è espresso in decine.
12	La dimensione del database va da 100 GB a 100 TB.	La dimensione del database va da 100 MB a 100 GB.
13	Questi sono altamente flessibili.	Fornisce prestazioni elevate.

Cos'è il data warehousing?

Il data warehousing è il processo di costruzione e utilizzo di un data warehouse. Un data warehouse viene costruito integrando dati da più fonti eterogenee che supportano report analitici, query strutturate e / o ad hoc e processi decisionali. Il data warehousing implica la pulizia dei dati, l'integrazione dei dati e il consolidamento dei dati.

Utilizzo delle informazioni del data warehouse

Esistono tecnologie di supporto decisionale che aiutano a utilizzare i dati disponibili in un data warehouse. Queste tecnologie aiutano i dirigenti a utilizzare il magazzino in modo rapido ed efficace. Possono raccogliere dati, analizzarli e prendere decisioni sulla base delle informazioni presenti nel magazzino. Le informazioni raccolte in un magazzino possono essere utilizzate in uno qualsiasi dei seguenti domini:

• Tuning Production Strategies - Le strategie di prodotto possono essere ottimizzate riposizionando i prodotti e gestendo i portafogli di prodotti confrontando le vendite trimestrali o annuali.

• Customer Analysis - L'analisi del cliente viene eseguita analizzando le preferenze di acquisto del cliente, i tempi di acquisto, i cicli di budget, ecc.

• Operations Analysis- Il data warehousing aiuta anche nella gestione delle relazioni con i clienti e nell'apportare correzioni ambientali. Le informazioni ci consentono anche di analizzare le operazioni aziendali.

Integrazione di database eterogenei

Per integrare database eterogenei, abbiamo due approcci:

• Approccio basato su query
• Approccio guidato dall'aggiornamento

Approccio basato su query

Questo è l'approccio tradizionale per integrare database eterogenei. Questo approccio è stato utilizzato per creare wrapper e integratori su più database eterogenei. Questi integratori sono noti anche come mediatori.

Processo di approccio basato su query

• Quando una query viene inviata a un lato client, un dizionario di metadati traduce la query in una forma appropriata per i singoli siti eterogenei coinvolti.

• Ora queste query vengono mappate e inviate al Query Processor locale.

• I risultati di siti eterogenei sono integrati in una serie di risposte globali.

Svantaggi

• L'approccio basato sulle query richiede processi di integrazione e filtraggio complessi.

• Questo approccio è molto inefficiente.

• È molto costoso per domande frequenti.

• Questo approccio è anche molto costoso per le query che richiedono aggregazioni.

Approccio guidato dall'aggiornamento

Questa è un'alternativa all'approccio tradizionale. I sistemi di data warehouse odierni seguono un approccio guidato dall'aggiornamento piuttosto che l'approccio tradizionale discusso in precedenza. Nell'approccio basato sull'aggiornamento, le informazioni provenienti da più fonti eterogenee vengono integrate in anticipo e vengono archiviate in un magazzino. Queste informazioni sono disponibili per query e analisi dirette.

Vantaggi

Questo approccio presenta i seguenti vantaggi:

• Questo approccio fornisce prestazioni elevate.

• I dati vengono copiati, elaborati, integrati, annotati, riepilogati e ristrutturati in anticipo in un archivio dati semantico.

• L'elaborazione delle query non richiede un'interfaccia per elaborare i dati nelle origini locali.

Funzioni degli strumenti e delle utilità del data warehouse

Di seguito sono riportate le funzioni degli strumenti e delle utilità del data warehouse:

• Data Extraction - Coinvolge la raccolta di dati da più fonti eterogenee.

• Data Cleaning - Coinvolge la ricerca e la correzione degli errori nei dati.

• Data Transformation - Coinvolge la conversione dei dati dal formato legacy al formato warehouse.

• Data Loading - Comprende l'ordinamento, il riepilogo, il consolidamento, il controllo dell'integrità e la creazione di indici e partizioni.

• Refreshing - Coinvolge l'aggiornamento dalle origini dati al magazzino.

Note - La pulizia e la trasformazione dei dati sono passaggi importanti per migliorare la qualità dei dati e i risultati del data mining.

In questo capitolo discuteremo alcuni dei termini più comunemente usati nel data warehousing.

Metadati

I metadati sono definiti semplicemente come dati sui dati. I dati utilizzati per rappresentare altri dati sono noti come metadati. Ad esempio, l'indice di un libro funge da metadati per i contenuti del libro. In altre parole, possiamo dire che i metadati sono i dati riassunti che ci portano ai dati dettagliati.

In termini di data warehouse, possiamo definire i metadati come segue:

• I metadati sono una road map per il data warehouse.

• I metadati nel data warehouse definiscono gli oggetti warehouse.

• I metadati fungono da directory. Questa directory aiuta il sistema di supporto decisionale a individuare i contenuti di un data warehouse.

Repository di metadati

Il repository di metadati è parte integrante di un sistema di data warehouse. Contiene i seguenti metadati:

• Business metadata - Contiene le informazioni sulla proprietà dei dati, la definizione aziendale e la modifica delle politiche.

• Operational metadata- Include la valuta dei dati e la derivazione dei dati. La valuta dei dati si riferisce ai dati attivi, archiviati o eliminati. Derivazione dei dati significa storia dei dati migrati e trasformazione applicata su di essi.

• Data for mapping from operational environment to data warehouse - I metadati includono i database di origine e il loro contenuto, l'estrazione dei dati, la partizione dei dati, la pulizia, le regole di trasformazione, l'aggiornamento dei dati e le regole di eliminazione.

• The algorithms for summarization - Include algoritmi dimensionali, dati sulla granularità, aggregazione, riepilogo, ecc.

Cubo dati

Un cubo di dati ci aiuta a rappresentare i dati in più dimensioni. È definito da dimensioni e fatti. Le dimensioni sono le entità rispetto alle quali un'impresa conserva i record.

Illustrazione di Data Cube

Si supponga che un'azienda desideri tenere traccia dei record delle vendite con l'aiuto del data warehouse delle vendite rispetto a tempo, articolo, filiale e ubicazione. Queste dimensioni consentono di tenere traccia delle vendite mensili e in quale filiale sono stati venduti gli articoli. C'è una tabella associata a ciascuna dimensione. Questa tabella è nota come tabella delle dimensioni. Ad esempio, la tabella delle dimensioni "articolo" può avere attributi come nome_articolo, tipo_elemento e marchio_articolo.

La tabella seguente rappresenta la visualizzazione 2-D dei dati di vendita per una società rispetto alle dimensioni di tempo, articolo e ubicazione.

Ma qui, in questa tabella 2-D, abbiamo record solo per quanto riguarda l'ora e l'elemento. Le vendite per New Delhi sono mostrate in base al tempo e alle dimensioni degli articoli in base al tipo di articoli venduti. Se desideriamo visualizzare i dati sulle vendite con un'altra dimensione, ad esempio la dimensione della posizione, la visualizzazione 3-D sarebbe utile. La visualizzazione 3-D dei dati di vendita rispetto a tempo, articolo e ubicazione è mostrata nella tabella seguente:

La tabella 3-D sopra può essere rappresentata come cubo di dati 3-D come mostrato nella figura seguente -

Data Mart

I data mart contengono un sottoinsieme di dati a livello di organizzazione che è prezioso per gruppi specifici di persone in un'organizzazione. In altre parole, un data mart contiene solo i dati specifici di un particolare gruppo. Ad esempio, il data mart di marketing può contenere solo dati relativi ad articoli, clienti e vendite. I data mart sono limitati ai soggetti.

Punti da ricordare sui data mart

• I server basati su Windows o su Unix / Linux vengono utilizzati per implementare i data mart. Sono implementati su server a basso costo.

• Il ciclo di implementazione di un data mart viene misurato in brevi periodi di tempo, ovvero in settimane anziché in mesi o anni.

• Il ciclo di vita dei data mart può essere complesso a lungo termine, se la loro pianificazione e progettazione non riguarda l'intera organizzazione.

• I data mart sono di piccole dimensioni.

• I data mart sono personalizzati per reparto.

• L'origine di un data mart è un data warehouse strutturato a livello di reparto.

• I data mart sono flessibili.

La figura seguente mostra una rappresentazione grafica dei data mart.

Magazzino virtuale

La visualizzazione su un data warehouse operativo è nota come magazzino virtuale. È facile costruire un magazzino virtuale. La creazione di un magazzino virtuale richiede capacità in eccesso sui server di database operativi.

Un data warehouse non è mai statico; si evolve con l'espansione dell'attività. Man mano che l'azienda si evolve, i suoi requisiti continuano a cambiare e quindi un data warehouse deve essere progettato per far fronte a questi cambiamenti. Quindi un sistema di data warehouse deve essere flessibile.

Idealmente dovrebbe esserci un processo di consegna per fornire un data warehouse. Tuttavia, i progetti di data warehouse normalmente soffrono di vari problemi che rendono difficile completare attività e risultati nel modo rigoroso e ordinato richiesto dal metodo a cascata. La maggior parte delle volte, i requisiti non vengono compresi completamente. Le architetture, i progetti e i componenti di costruzione possono essere completati solo dopo aver raccolto e studiato tutti i requisiti.

metodo di consegna

Il metodo di consegna è una variante dell'approccio di sviluppo applicativo congiunto adottato per la consegna di un data warehouse. Abbiamo organizzato il processo di consegna del data warehouse per ridurre al minimo i rischi. L'approccio di cui discuteremo qui non riduce i tempi di consegna complessivi, ma garantisce che i vantaggi aziendali vengano forniti in modo incrementale durante il processo di sviluppo.

Note - Il processo di consegna è suddiviso in fasi per ridurre il progetto e il rischio di consegna.

Il diagramma seguente spiega le fasi del processo di consegna:

Strategia IT

I data warehouse sono investimenti strategici che richiedono un processo aziendale per generare benefici. La strategia IT è necessaria per ottenere e trattenere i finanziamenti per il progetto.

Caso aziendale

L'obiettivo del business case è stimare i vantaggi aziendali che dovrebbero derivare dall'utilizzo di un data warehouse. Questi benefici potrebbero non essere quantificabili, ma i benefici previsti devono essere chiaramente indicati. Se un data warehouse non ha un business case chiaro, l'azienda tende a soffrire di problemi di credibilità a un certo punto durante il processo di consegna. Pertanto, nei progetti di data warehouse, dobbiamo comprendere il business case dell'investimento.

Istruzione e prototipazione

Le organizzazioni sperimentano il concetto di analisi dei dati e si informano sul valore di avere un data warehouse prima di accontentarsi di una soluzione. Questo viene risolto dalla prototipazione. Aiuta a comprendere la fattibilità e i vantaggi di un data warehouse. L'attività di prototipazione su piccola scala può promuovere il processo educativo purché:

• Il prototipo si rivolge a un obiettivo tecnico definito.

• Il prototipo può essere gettato via dopo che è stato mostrato il concetto di fattibilità.

• L'attività si rivolge a un piccolo sottoinsieme di eventuali contenuti di dati del data warehouse.

• La tempistica dell'attività non è critica.

I seguenti punti devono essere tenuti presenti per produrre una versione anticipata e fornire vantaggi aziendali.

• Identifica l'architettura che è in grado di evolversi.

• Concentrarsi sui requisiti aziendali e sulle fasi del progetto tecnico.

• Limita l'ambito della prima fase di compilazione al minimo che offra vantaggi aziendali.

• Comprendere i requisiti a breve e medio termine del data warehouse.

Requisiti aziendali

Per fornire risultati di qualità, dobbiamo assicurarci che i requisiti generali siano compresi. Se comprendiamo i requisiti aziendali sia a breve che a medio termine, possiamo progettare una soluzione per soddisfare i requisiti a breve termine. La soluzione a breve termine può quindi essere trasformata in una soluzione completa.

In questa fase vengono determinati i seguenti aspetti:

• La regola aziendale da applicare ai dati.

• Il modello logico per le informazioni all'interno del data warehouse.

• I profili di query per il requisito immediato.

• I sistemi di origine che forniscono questi dati.

Progetto tecnico

Questa fase deve fornire un'architettura globale che soddisfi i requisiti a lungo termine. Questa fase fornisce anche i componenti che devono essere implementati a breve termine per trarre qualsiasi vantaggio aziendale. Il progetto deve identificare i seguenti.

• L'architettura complessiva del sistema.
• La politica di conservazione dei dati.
• La strategia di backup e ripristino.
• L'architettura del server e del data mart.
• Il piano di capacità per hardware e infrastruttura.
• I componenti della progettazione di database.

Creazione della versione

In questa fase, viene prodotto il primo deliverable di produzione. Questo deliverable di produzione è il componente più piccolo di un data warehouse. Questo componente più piccolo aggiunge vantaggi per l'azienda.

Caricamento della cronologia

Questa è la fase in cui il resto della cronologia richiesta viene caricata nel data warehouse. In questa fase, non aggiungiamo nuove entità, ma verrebbero probabilmente create tabelle fisiche aggiuntive per memorizzare maggiori volumi di dati.

Facciamo un esempio. Supponiamo che la fase della versione build abbia fornito un data warehouse per l'analisi delle vendite al dettaglio con 2 mesi di cronologia. Queste informazioni consentiranno all'utente di analizzare solo le tendenze recenti e affrontare i problemi a breve termine. L'utente in questo caso non può identificare le tendenze annuali e stagionali. Per aiutarlo a farlo, la cronologia delle vendite degli ultimi 2 anni potrebbe essere caricata dall'archivio. Ora i dati da 40 GB vengono estesi a 400 GB.

Note - Le procedure di backup e ripristino possono diventare complesse, pertanto si consiglia di eseguire questa attività in una fase separata.

Query ad hoc

In questa fase, configuriamo uno strumento di query ad hoc che viene utilizzato per gestire un data warehouse. Questi strumenti possono generare la query del database.

Note - Si consiglia di non utilizzare questi strumenti di accesso quando il database viene modificato in modo sostanziale.

Automazione

In questa fase i processi di gestione operativa sono completamente automatizzati. Questi includerebbero:

• Trasformare i dati in una forma adatta all'analisi.

• Monitoraggio dei profili di query e determinazione delle aggregazioni appropriate per mantenere le prestazioni del sistema.

• Estrazione e caricamento dei dati da diversi sistemi di origine.

• Generazione di aggregazioni da definizioni predefinite all'interno del data warehouse.

• Backup, ripristino e archiviazione dei dati.

Estensione dell'ambito

In questa fase, il data warehouse viene esteso per soddisfare una nuova serie di requisiti aziendali. L'ambito può essere esteso in due modi:

• Caricando dati aggiuntivi nel data warehouse.

• Introducendo nuovi data mart utilizzando le informazioni esistenti.

Note - Questa fase dovrebbe essere eseguita separatamente, poiché comporta notevoli sforzi e complessità.

Requisiti Evoluzione

Dal punto di vista del processo di consegna, i requisiti sono sempre mutevoli. Non sono statici. Il processo di consegna deve supportare questo e consentire che queste modifiche si riflettano all'interno del sistema.

Questo problema viene risolto progettando il data warehouse in base all'uso dei dati all'interno dei processi aziendali, in contrasto con i requisiti dei dati delle query esistenti.

L'architettura è progettata per cambiare e crescere per soddisfare le esigenze aziendali, il processo opera come un processo di sviluppo di pseudo-applicazioni, in cui i nuovi requisiti vengono continuamente inseriti nelle attività di sviluppo e vengono prodotti i deliverable parziali. Questi risultati parziali vengono restituiti agli utenti e quindi rielaborati garantendo che il sistema complessivo venga continuamente aggiornato per soddisfare le esigenze aziendali.

Abbiamo un numero fisso di operazioni da applicare sui database operativi e abbiamo tecniche ben definite come use normalized data, keep table small, ecc. Queste tecniche sono adatte per fornire una soluzione. Ma in caso di sistemi di supporto decisionale, non sappiamo quale query e operazione debbano essere eseguite in futuro. Pertanto le tecniche applicate sui database operativi non sono adatte per i data warehouse.

In questo capitolo, discuteremo come costruire soluzioni di data warehousing sulle migliori tecnologie a sistema aperto come Unix e database relazionali.

Flusso di processo in Data Warehouse

Esistono quattro processi principali che contribuiscono a un data warehouse:

• Estrai e carica i dati.
• Pulizia e trasformazione dei dati.
• Backup e archiviazione dei dati.
• Gestire le query e indirizzarle alle origini dati appropriate.

Estrazione e caricamento del processo

L'estrazione dei dati prende i dati dai sistemi di origine. Il caricamento dei dati prende i dati estratti e li carica nel data warehouse.

Note - Prima di caricare i dati nel data warehouse, è necessario ricostruire le informazioni estratte dalle fonti esterne.

Controllo del processo

Il controllo del processo implica la determinazione del momento in cui avviare l'estrazione dei dati e il controllo della coerenza dei dati. Il processo di controllo garantisce che gli strumenti, i moduli logici ei programmi vengano eseguiti nella sequenza corretta e al momento giusto.

Quando avviare l'estrazione

I dati devono essere in uno stato coerente quando vengono estratti, ovvero il data warehouse deve rappresentare una versione unica e coerente delle informazioni per l'utente.

Ad esempio, in un data warehouse di profilazione dei clienti nel settore delle telecomunicazioni, è illogico unire l'elenco dei clienti alle 20:00 di mercoledì da un database clienti con gli eventi di abbonamento clienti fino alle 20:00 di martedì. Ciò significherebbe che stiamo trovando i clienti per i quali non ci sono abbonamenti associati.

Caricamento dei dati

Dopo aver estratto i dati, vengono caricati in un archivio dati temporaneo dove vengono puliti e resi coerenti.

Note - I controlli di coerenza vengono eseguiti solo quando tutte le origini dati sono state caricate nell'archivio dati temporaneo.

Processo pulito e di trasformazione

Una volta estratti i dati e caricati nell'archivio dati temporaneo, è il momento di eseguire la pulizia e la trasformazione. Ecco l'elenco dei passaggi coinvolti nella pulizia e nella trasformazione:

• Pulisci e trasforma i dati caricati in una struttura
• Partizionare i dati
• Aggregation

Pulisci e trasforma i dati caricati in una struttura

La pulizia e la trasformazione dei dati caricati aiuta ad accelerare le query. Può essere fatto rendendo i dati coerenti:

• dentro di sé.
• con altri dati all'interno della stessa origine dati.
• con i dati in altri sistemi di origine.
• con i dati esistenti presenti nel magazzino.

La trasformazione implica la conversione dei dati di origine in una struttura. La strutturazione dei dati aumenta le prestazioni delle query e riduce i costi operativi. I dati contenuti in un data warehouse devono essere trasformati per supportare i requisiti di prestazioni e controllare i costi operativi correnti.

Partizionare i dati

Ottimizzerà le prestazioni hardware e semplificherà la gestione del data warehouse. Qui partizioniamo ogni tabella dei fatti in più partizioni separate.

Aggregazione

L'aggregazione è necessaria per velocizzare le query comuni. L'aggregazione si basa sul fatto che le query più comuni analizzeranno un sottoinsieme o un'aggregazione dei dati dettagliati.

Backup e archiviazione dei dati

Per ripristinare i dati in caso di perdita di dati, guasto del software o guasto dell'hardware, è necessario mantenere backup regolari. L'archiviazione comporta la rimozione dei vecchi dati dal sistema in un formato che consente di ripristinarli rapidamente quando necessario.

Ad esempio, in un data warehouse di analisi delle vendite al dettaglio, potrebbe essere necessario conservare i dati per 3 anni con i dati degli ultimi 6 mesi mantenuti online. In tale scenario, spesso è necessario essere in grado di effettuare confronti mese per mese per quest'anno e l'anno scorso. In questo caso, è necessario ripristinare alcuni dati dall'archivio.

Processo di gestione delle query

Questo processo esegue le seguenti funzioni:

• gestisce le query.

• aiuta ad accelerare i tempi di esecuzione dei queris.

• indirizza le query alle origini dati più efficaci.

• assicura che tutte le sorgenti di sistema siano utilizzate nel modo più efficace.

• monitora i profili di query effettivi.

Le informazioni generate in questo processo vengono utilizzate dal processo di gestione del magazzino per determinare quali aggregazioni generare. Questo processo in genere non funziona durante il carico regolare di informazioni nel data warehouse.

In questo capitolo, discuteremo il framework di analisi aziendale per la progettazione e l'architettura di un data warehouse.

Framework di analisi aziendale

L'analista aziendale ottiene le informazioni dai data warehouse per misurare le prestazioni e apportare modifiche critiche al fine di conquistare altri imprenditori sul mercato. Avere un data warehouse offre i seguenti vantaggi:

• Poiché un data warehouse può raccogliere informazioni in modo rapido ed efficiente, può migliorare la produttività aziendale.

• Un data warehouse ci fornisce una visione coerente dei clienti e degli articoli, quindi ci aiuta a gestire le relazioni con i clienti.

• Un data warehouse aiuta anche a ridurre i costi monitorando le tendenze, i modelli su un lungo periodo in modo coerente e affidabile.

Per progettare un data warehouse efficace ed efficiente, è necessario comprendere e analizzare le esigenze aziendali e costruire un file business analysis framework. Ogni persona ha punti di vista diversi riguardo alla progettazione di un data warehouse. Queste visualizzazioni sono le seguenti:

• The top-down view - Questa visualizzazione consente la selezione delle informazioni rilevanti necessarie per un data warehouse.

• The data source view - Questa visualizzazione presenta le informazioni acquisite, archiviate e gestite dal sistema operativo.

• The data warehouse view- Questa visualizzazione include le tabelle dei fatti e le tabelle delle dimensioni. Rappresenta le informazioni archiviate all'interno del data warehouse.

• The business query view - È la visione dei dati dal punto di vista dell'utente finale.

Architettura del data warehouse a tre livelli

Generalmente un data warehouse adotta un'architettura a tre livelli. Di seguito sono riportati i tre livelli dell'architettura del data warehouse.

• Bottom Tier- Il livello inferiore dell'architettura è il server del database del data warehouse. È il sistema di database relazionale. Usiamo gli strumenti e le utilità di back-end per inserire i dati nel livello inferiore. Questi strumenti e utilità di back-end eseguono le funzioni di estrazione, pulizia, caricamento e aggiornamento.

• Middle Tier - Nel livello intermedio, abbiamo il server OLAP che può essere implementato in uno dei seguenti modi.

  • Da Relational OLAP (ROLAP), che è un sistema di gestione di database relazionali esteso. Il ROLAP mappa le operazioni sui dati multidimensionali alle operazioni relazionali standard.

  • Dal modello Multidimensional OLAP (MOLAP), che implementa direttamente i dati e le operazioni multidimensionali.

• Top-Tier- Questo livello è il livello del client front-end. Questo livello contiene gli strumenti di query e gli strumenti di reporting, gli strumenti di analisi e gli strumenti di data mining.

Il diagramma seguente illustra l'architettura a tre livelli del data warehouse:

Modelli di data warehouse

Dal punto di vista dell'architettura del data warehouse, abbiamo i seguenti modelli di data warehouse:

• Magazzino virtuale
• Data mart
• Magazzino aziendale

Magazzino virtuale

La visualizzazione su un data warehouse operativo è nota come magazzino virtuale. È facile costruire un magazzino virtuale. La creazione di un magazzino virtuale richiede capacità in eccesso sui server di database operativi.

Data Mart

Il data mart contiene un sottoinsieme di dati a livello di organizzazione. Questo sottoinsieme di dati è prezioso per gruppi specifici di un'organizzazione.

In altre parole, possiamo affermare che i data mart contengono dati specifici per un particolare gruppo. Ad esempio, il data mart di marketing può contenere dati relativi ad articoli, clienti e vendite. I data mart sono limitati ai soggetti.

Punti da ricordare sui data mart -

• Per implementare i data mart vengono utilizzati server basati su finestre o su Unix / Linux. Sono implementati su server a basso costo.

• I cicli di data mart di implementazione vengono misurati in brevi periodi di tempo, ovvero in settimane anziché in mesi o anni.

• Il ciclo di vita di un data mart può essere complesso nel lungo periodo, se la sua pianificazione e progettazione non sono a livello di organizzazione.

• I data mart sono di piccole dimensioni.

• I data mart sono personalizzati per reparto.

• L'origine di un data mart è un data warehouse strutturato a livello di reparto.

• I data mart sono flessibili.

Magazzino aziendale

• Un magazzino aziendale raccoglie tutte le informazioni e gli argomenti che coprono un'intera organizzazione

• Ci fornisce l'integrazione dei dati a livello aziendale.

• I dati sono integrati da sistemi operativi e fornitori di informazioni esterni.

• Queste informazioni possono variare da pochi gigabyte a centinaia di gigabyte, terabyte o oltre.

Load Manager

Questo componente esegue le operazioni richieste per estrarre e caricare il processo.

La dimensione e la complessità del gestore del carico varia tra le soluzioni specifiche da un data warehouse all'altro.

Architettura Load Manager

Il load manager svolge le seguenti funzioni:

• Estrai i dati dal sistema di origine.

• Carica veloce i dati estratti nell'archivio dati temporaneo.

• Eseguire semplici trasformazioni in una struttura simile a quella nel data warehouse.

Estrai dati dall'origine

I dati vengono estratti dai database operativi o dai fornitori di informazioni esterni. I gateway sono i programmi applicativi utilizzati per estrarre i dati. È supportato dal DBMS sottostante e consente al programma client di generare SQL da eseguire su un server. Open Database Connection (ODBC), Java Database Connection (JDBC), sono esempi di gateway.

Caricamento veloce

• Per ridurre al minimo la finestra di carico totale, i dati devono essere caricati nel magazzino nel più breve tempo possibile.

• Le trasformazioni influiscono sulla velocità di elaborazione dei dati.

• È più efficace caricare i dati nel database relazionale prima di applicare trasformazioni e controlli.

• La tecnologia gateway si dimostra inadatta, poiché tendono a non essere performanti quando sono coinvolti grandi volumi di dati.

Trasformazioni semplici

Durante il caricamento potrebbe essere necessario eseguire semplici trasformazioni. Dopo che questo è stato completato, siamo in grado di eseguire i controlli complessi. Supponiamo che stiamo caricando la transazione di vendita EPOS di cui abbiamo bisogno per eseguire i seguenti controlli:

• Elimina tutte le colonne che non sono necessarie all'interno del magazzino.
• Converti tutti i valori nei tipi di dati richiesti.

Responsabile del magazzino

Un responsabile del magazzino è responsabile del processo di gestione del magazzino. È costituito da software di sistema di terze parti, programmi C e script della shell.

Le dimensioni e la complessità dei responsabili del magazzino variano a seconda delle soluzioni specifiche.

Architettura del responsabile del magazzino

Un responsabile del magazzino include quanto segue:

• Il processo di controllo
• Stored procedure o C con SQL
• Strumento di backup / ripristino
• Script SQL

Operazioni eseguite da Warehouse Manager

• Un responsabile del magazzino analizza i dati per eseguire controlli di coerenza e integrità referenziale.

• Crea indici, viste aziendali, viste delle partizioni rispetto ai dati di base.

• Genera nuove aggregazioni e aggiorna le aggregazioni esistenti. Genera normalizzazioni.

• Trasforma e unisce i dati di origine nel data warehouse pubblicato.

• Eseguire il backup dei dati nel data warehouse.

• Archivia i dati che hanno raggiunto la fine della loro vita catturata.

Note - Un responsabile del magazzino analizza anche i profili delle query per determinare l'indice e le aggregazioni sono appropriate.

Query Manager

• Il gestore delle query è responsabile di indirizzare le query alle tabelle appropriate.

• Indirizzando le query alle tabelle appropriate, è possibile aumentare la velocità di query e la generazione di risposte.

• Il gestore delle query è responsabile della pianificazione dell'esecuzione delle query poste dall'utente.

Architettura di Query Manager

Lo screenshot seguente mostra l'architettura di un gestore di query. Include quanto segue:

• Reindirizzamento delle query tramite lo strumento C o RDBMS
• Procedura di archiviazione
• Strumento di gestione delle query
• Pianificazione delle query tramite lo strumento C o RDBMS
• Pianificazione delle query tramite software di terze parti

Informazioni dettagliate

Le informazioni dettagliate non vengono conservate online, ma vengono aggregate al livello di dettaglio successivo e quindi archiviate su nastro. La parte delle informazioni dettagliate del data warehouse conserva le informazioni dettagliate nello schema starflake. Le informazioni dettagliate vengono caricate nel data warehouse per integrare i dati aggregati.

Il diagramma seguente mostra un'impressione visiva di dove sono memorizzate le informazioni dettagliate e come vengono utilizzate.

Note - Se le informazioni dettagliate vengono conservate offline per ridurre al minimo lo spazio di archiviazione su disco, dobbiamo assicurarci che i dati siano stati estratti, puliti e trasformati nello schema Starflake prima di essere archiviati.

Informazioni di riepilogo

Le informazioni di riepilogo sono una parte del data warehouse che archivia le aggregazioni predefinite. Queste aggregazioni vengono generate dal responsabile del magazzino. Le informazioni di riepilogo devono essere trattate come transitorie. Cambia in movimento per rispondere ai mutevoli profili di query.

I punti da notare sulle informazioni di riepilogo sono i seguenti:

• Le informazioni di riepilogo velocizzano le prestazioni delle query comuni.

• Aumenta il costo operativo.

• Deve essere aggiornato ogni volta che vengono caricati nuovi dati nel data warehouse.

• Potrebbe non essere stato eseguito il backup, poiché può essere generato fresco dalle informazioni dettagliate.

Online Analytical Processing Server (OLAP) si basa sul modello di dati multidimensionali. Consente a manager e analisti di ottenere una visione delle informazioni attraverso un accesso rapido, coerente e interattivo alle informazioni. Questo capitolo tratta i tipi di OLAP, le operazioni su OLAP, la differenza tra OLAP e database statistici e OLTP.

Tipi di server OLAP

Abbiamo quattro tipi di server OLAP:

• OLAP relazionale (ROLAP)
• OLAP multidimensionale (MOLAP)
• OLAP ibrido (HOLAP)
• Server SQL specializzati

OLAP relazionale

I server ROLAP vengono inseriti tra il server relazionale back-end e gli strumenti front-end del client. Per archiviare e gestire i dati del magazzino, ROLAP utilizza DBMS relazionali o relazionali estesi.

ROLAP include quanto segue:

• Implementazione della logica di navigazione di aggregazione.
• Ottimizzazione per ogni back-end DBMS.
• Strumenti e servizi aggiuntivi.

OLAP multidimensionale

MOLAP utilizza motori di archiviazione multidimensionale basati su array per visualizzazioni multidimensionali dei dati. Con archivi di dati multidimensionali, l'utilizzo dello spazio di archiviazione potrebbe essere basso se il set di dati è scarso. Pertanto, molti server MOLAP utilizzano due livelli di rappresentazione dell'archiviazione dei dati per gestire set di dati densi e sparsi.

OLAP ibrido

OLAP ibrido è una combinazione di ROLAP e MOLAP. Offre una maggiore scalabilità di ROLAP e un calcolo più veloce di MOLAP. I server HOLAP consentono di memorizzare grandi volumi di dati di informazioni dettagliate. Le aggregazioni vengono archiviate separatamente nel negozio MOLAP.

Server SQL specializzati

I server SQL specializzati forniscono un linguaggio di query avanzato e supporto per l'elaborazione delle query per le query SQL su schemi a stella e fiocco di neve in un ambiente di sola lettura.

Operazioni OLAP

Poiché i server OLAP si basano su una visualizzazione multidimensionale dei dati, discuteremo delle operazioni OLAP nei dati multidimensionali.

Ecco l'elenco delle operazioni OLAP:

• Roll-up
• Drill-down
• Fare a pezzi
• Pivot (ruota)

Roll-up

Il roll-up esegue l'aggregazione su un cubo di dati in uno dei seguenti modi:

• Scalando una gerarchia di concetti per una dimensione
• Per riduzione dimensionale

Il diagramma seguente illustra come funziona il roll-up.

• Il roll-up viene eseguito risalendo una gerarchia di concetti per la posizione della dimensione.

• Inizialmente la gerarchia del concetto era "strada <città <provincia <paese".

• Al momento dell'aggiornamento, i dati vengono aggregati ascendendo la gerarchia della posizione dal livello di città al livello di paese.

• I dati sono raggruppati in città anziché in paesi.

• Quando viene eseguito il roll-up, una o più dimensioni dal cubo di dati vengono rimosse.

Scavare a fondo

Il drill-down è l'operazione inversa del roll-up. Viene eseguito in uno dei seguenti modi:

• Riducendo una gerarchia di concetti per una dimensione
• Introducendo una nuova dimensione.

Il diagramma seguente illustra come funziona il drill-down:

• Il drill-down viene eseguito abbassando una gerarchia di concetti per la dimensione tempo.

• Inizialmente la gerarchia del concetto era "giorno <mese <trimestre <anno".

• Durante il drill down, la dimensione temporale viene discendente dal livello del trimestre al livello del mese.

• Quando viene eseguito il drill-down, vengono aggiunte una o più dimensioni dal cubo di dati.

• Naviga i dati da dati meno dettagliati a dati altamente dettagliati.

Fetta

L'operazione slice seleziona una dimensione particolare da un dato cubo e fornisce un nuovo sottocubo. Considera il seguente diagramma che mostra come funziona lo slice.

• Qui Slice viene eseguito per la dimensione "time" utilizzando il criterio time = "Q1".

• Formerà un nuovo sottocubo selezionando una o più dimensioni.

Dado

Dice seleziona due o più dimensioni da un dato cubo e fornisce un nuovo sottocubo. Considera il seguente diagramma che mostra il funzionamento dei dadi.

L'operazione dei dadi sul cubo basata sui seguenti criteri di selezione coinvolge tre dimensioni.

• (location = "Toronto" o "Vancouver")
• (ora = "Q1" o "Q2")
• (item = "Mobile" o "Modem")

Perno

L'operazione di rotazione è anche nota come rotazione. Ruota gli assi dei dati in vista per fornire una presentazione alternativa dei dati. Considera il diagramma seguente che mostra l'operazione pivot.

OLAP vs OLTP

Sr.No.	Data Warehouse (OLAP)	Database operativo (OLTP)
1	Coinvolge l'elaborazione storica delle informazioni.	Coinvolge l'elaborazione quotidiana.
2	I sistemi OLAP vengono utilizzati da knowledge worker quali dirigenti, manager e analisti.	I sistemi OLTP vengono utilizzati da impiegati, amministratori di database o professionisti del database.
3	Utile per analizzare il business.	Utile nella gestione dell'attività.
4	Si concentra sull'informazione fuori.	Si concentra sui dati in formato.
5	Basato su Star Schema, Snowflake, Schema e Fact Constellation Schema.	Basato sul modello di relazione tra entità.
6	Contiene dati storici.	Contiene i dati correnti.
7	Fornisce dati riepilogati e consolidati.	Fornisce dati primitivi e altamente dettagliati.
8	Fornisce una vista riepilogativa e multidimensionale dei dati.	Fornisce una vista relazionale dettagliata e semplice dei dati.
9	Il numero o gli utenti sono in centinaia.	Il numero di utenti è in migliaia.
10	Il numero di record a cui si accede è in milioni.	Il numero di record a cui si accede è espresso in decine.
11	La dimensione del database va da 100 GB a 1 TB	La dimensione del database va da 100 MB a 1 GB.
12	Altamente flessibile.	Fornisce prestazioni elevate.

I server OLAP relazionali si trovano tra il server relazionale back-end e gli strumenti front-end del client. Per archiviare e gestire i dati del magazzino, l'OLAP relazionale utilizza DBMS relazionali o relazionali estesi.

ROLAP include quanto segue:

• Implementazione della logica di navigazione di aggregazione
• Ottimizzazione per ogni back-end DBMS
• Strumenti e servizi aggiuntivi

Punti da ricordare

• I server ROLAP sono altamente scalabili.

• Gli strumenti ROLAP analizzano grandi volumi di dati su più dimensioni.

• Gli strumenti ROLAP archiviano e analizzano dati altamente volatili e modificabili.

Architettura OLAP relazionale

ROLAP include i seguenti componenti:

• Server di database
• Server ROLAP
• Strumento front-end.

Vantaggi

• I server ROLAP possono essere facilmente utilizzati con RDBMS esistenti.
• I dati possono essere archiviati in modo efficiente, poiché non è possibile memorizzare zero fatti.
• Gli strumenti ROLAP non utilizzano cubi di dati precalcolati.
• Il server DSS di micro-strategia adotta l'approccio ROLAP.

Svantaggi

• Scarse prestazioni delle query.

• Alcune limitazioni di scalabilità a seconda dell'architettura tecnologica utilizzata.

Multidimensional OLAP (MOLAP) utilizza motori di archiviazione multidimensionale basati su array per visualizzazioni multidimensionali dei dati. Con archivi di dati multidimensionali, l'utilizzo dello spazio di archiviazione potrebbe essere basso se il set di dati è scarso. Pertanto, molti server MOLAP utilizzano due livelli di rappresentazione dell'archiviazione dei dati per gestire set di dati densi e sparsi.

Punti da ricordare -

• Gli strumenti MOLAP elaborano le informazioni con tempi di risposta costanti indipendentemente dal livello di riepilogo o di calcolo selezionato.

• Gli strumenti MOLAP devono evitare molte delle complessità della creazione di un database relazionale per archiviare i dati per l'analisi.

• Gli strumenti MOLAP richiedono prestazioni più veloci possibili.

• Il server MOLAP adotta due livelli di rappresentazione dello storage per gestire set di dati densi e sparsi.

• I sottocubi più densi vengono identificati e memorizzati come struttura di matrice.

• I sottocubi sparsi utilizzano la tecnologia di compressione.

Architettura MOLAP

MOLAP include i seguenti componenti:

• Server di database.
• Server MOLAP.
• Strumento front-end.

Vantaggi

• MOLAP consente l'indicizzazione più rapida dei dati riepilogati precalcolati.
• Aiuta gli utenti connessi a una rete che hanno bisogno di analizzare dati più grandi e meno definiti.
• Più facile da usare, quindi MOLAP è adatto ad utenti inesperti.

Svantaggi

• I MOLAP non sono in grado di contenere dati dettagliati.
• L'utilizzo della memoria potrebbe essere basso se il set di dati è scarso.

MOLAP vs ROLAP

Sr.No.	MOLAP	ROLAP
1	Il recupero delle informazioni è veloce.	Il recupero delle informazioni è relativamente lento.
2	Utilizza array sparsi per memorizzare set di dati.	Utilizza la tabella relazionale.
3	MOLAP è più adatto per utenti inesperti, poiché è molto facile da usare.	ROLAP è più adatto per utenti esperti.
4	Mantiene un database separato per i cubi di dati.	Potrebbe non richiedere spazio diverso da quello disponibile nel data warehouse.
5	La struttura DBMS è debole.	La struttura DBMS è forte.

Lo schema è una descrizione logica dell'intero database. Include il nome e la descrizione dei record di tutti i tipi di record, inclusi tutti gli elementi di dati e gli aggregati associati. Proprio come un database, anche un data warehouse richiede di mantenere uno schema. Un database utilizza il modello relazionale, mentre un data warehouse utilizza lo schema Star, Snowflake e Fact Constellation. In questo capitolo discuteremo gli schemi utilizzati in un data warehouse.

Schema a stella

• Ogni dimensione in uno schema a stella è rappresentata con una sola tabella a una dimensione.

• Questa tabella delle dimensioni contiene la serie di attributi.

• Il diagramma seguente mostra i dati di vendita di un'azienda rispetto alle quattro dimensioni, ovvero tempo, articolo, filiale e ubicazione.

• C'è una tabella dei fatti al centro. Contiene le chiavi di ciascuna delle quattro dimensioni.

• La tabella dei fatti contiene anche gli attributi, vale a dire dollari venduti e unità vendute.

Note- Ogni dimensione ha solo una tabella delle dimensioni e ogni tabella contiene una serie di attributi. Ad esempio, la tabella delle dimensioni della posizione contiene il set di attributi {location_key, street, city, province_or_state, country}. Questo vincolo può causare la ridondanza dei dati. Ad esempio, "Vancouver" e "Victoria" entrambe le città si trovano nella provincia canadese della British Columbia. Le voci per tali città possono causare la ridondanza dei dati lungo gli attributi province_or_state e country.

Schema del fiocco di neve

• Alcune tabelle delle dimensioni nello schema Snowflake sono normalizzate.

• La normalizzazione suddivide i dati in tabelle aggiuntive.

• A differenza dello schema Star, la tabella delle dimensioni in uno schema a fiocco di neve viene normalizzata. Ad esempio, la tabella delle dimensioni dell'articolo nello schema a stella viene normalizzata e suddivisa in due tabelle delle dimensioni, ovvero la tabella degli articoli e dei fornitori.

• Ora la tabella delle dimensioni dell'articolo contiene gli attributi chiave_articolo, nome_articolo, tipo, marca e chiave-fornitore.

• La chiave del fornitore è collegata alla tabella delle dimensioni del fornitore. La tabella delle dimensioni del fornitore contiene gli attributi fornitore_key e fornitore_type.

Note - A causa della normalizzazione nello schema Snowflake, la ridondanza viene ridotta e quindi diventa facile da mantenere e risparmiare spazio di archiviazione.

Schema delle costellazioni dei fatti

• Una costellazione dei fatti ha più tabelle dei fatti. È anche noto come schema galassia.

• Il diagramma seguente mostra due tabelle dei fatti, ovvero vendite e spedizione.

• La tabella dei fatti sulle vendite è uguale a quella nello schema a stella.

• La tabella dei fatti di spedizione ha le cinque dimensioni, ovvero item_key, time_key, shipper_key, from_location, to_location.

• La tabella dei dati di spedizione contiene anche due misure, vale a dire dollari venduti e unità vendute.

• È anche possibile condividere tabelle delle dimensioni tra tabelle dei fatti. Ad esempio, le tabelle delle dimensioni di ora, articolo e posizione vengono condivise tra la tabella dei fatti di vendita e di spedizione.

Definizione dello schema

Lo schema multidimensionale viene definito utilizzando DMQL (Data Mining Query Language). Le due primitive, definizione del cubo e definizione della dimensione, possono essere utilizzate per definire i data warehouse e i data mart.

Sintassi per la definizione del cubo

define cube < cube_name > [ < dimension-list > }: < measure_list >

Sintassi per la definizione della dimensione

define dimension < dimension_name > as ( < attribute_or_dimension_list > )

Definizione dello schema a stella

Lo schema a stella che abbiamo discusso può essere definito utilizzando DMQL (Data Mining Query Language) come segue:

define cube sales star [time, item, branch, location]:   
    	   
dollars sold = sum(sales in dollars), units sold = count(*)    	  

define dimension time as (time key, day, day of week, month, quarter, year)
define dimension item as (item key, item name, brand, type, supplier type)        	
define dimension branch as (branch key, branch name, branch type)              	
define dimension location as (location key, street, city, province or state, country)

Definizione dello schema del fiocco di neve

Lo schema Snowflake può essere definito utilizzando DMQL come segue:

define cube sales snowflake [time, item, branch, location]:

dollars sold = sum(sales in dollars), units sold = count(*)

define dimension time as (time key, day, day of week, month, quarter, year)
define dimension item as (item key, item name, brand, type, supplier (supplier key, supplier type))
define dimension branch as (branch key, branch name, branch type)
define dimension location as (location key, street, city (city key, city, province or state, country))

Definizione dello schema delle costellazioni dei fatti

Lo schema della costellazione dei fatti può essere definito utilizzando DMQL come segue:

define cube sales [time, item, branch, location]:

dollars sold = sum(sales in dollars), units sold = count(*)

define dimension time as (time key, day, day of week, month, quarter, year)
define dimension item as (item key, item name, brand, type, supplier type)
define dimension branch as (branch key, branch name, branch type)
define dimension location as (location key, street, city, province or state,country)
define cube shipping [time, item, shipper, from location, to location]:

dollars cost = sum(cost in dollars), units shipped = count(*)

define dimension time as time in cube sales
define dimension item as item in cube sales
define dimension shipper as (shipper key, shipper name, location as location in cube sales, shipper type)
define dimension from location as location in cube sales
define dimension to location as location in cube sales

Il partizionamento viene eseguito per migliorare le prestazioni e facilitare la facile gestione dei dati. Il partizionamento aiuta anche a bilanciare i vari requisiti del sistema. Ottimizza le prestazioni hardware e semplifica la gestione del data warehouse partizionando ogni tabella dei fatti in più partizioni separate. In questo capitolo, discuteremo diverse strategie di partizionamento.

Perché è necessario partizionare?

Il partizionamento è importante per i seguenti motivi:

• Per una facile gestione,
• Per assistere il backup / ripristino,
• Per migliorare le prestazioni.

Per una facile gestione

La tabella dei fatti in un data warehouse può aumentare fino a centinaia di gigabyte. Questa tabella dei fatti di dimensioni enormi è molto difficile da gestire come singola entità. Quindi necessita di partizionamento.

Per assistere il backup / ripristino

Se non partizioniamo la tabella dei fatti, dobbiamo caricare l'intera tabella dei fatti con tutti i dati. Il partizionamento ci consente di caricare solo la quantità di dati necessaria su base regolare. Riduce il tempo di caricamento e migliora anche le prestazioni del sistema.

Note- Per ridurre le dimensioni del backup, tutte le partizioni diverse dalla partizione corrente possono essere contrassegnate come di sola lettura. Possiamo quindi mettere queste partizioni in uno stato in cui non possono essere modificate. Quindi possono essere sottoposti a backup. Significa che deve essere eseguito il backup solo della partizione corrente.

Per migliorare le prestazioni

Partizionando la tabella dei fatti in set di dati, le procedure di query possono essere migliorate. Le prestazioni della query sono migliorate perché ora la query analizza solo le partizioni rilevanti. Non è necessario scansionare tutti i dati.

Partizionamento orizzontale

Esistono vari modi in cui una tabella dei fatti può essere partizionata. Nel partizionamento orizzontale, dobbiamo tenere presenti i requisiti per la gestibilità del data warehouse.

Partizionamento in base al tempo in segmenti uguali

In questa strategia di partizionamento, la tabella dei fatti viene partizionata sulla base del periodo di tempo. Qui ogni periodo di tempo rappresenta un periodo di conservazione significativo all'interno dell'azienda. Ad esempio, se l'utente richiedemonth to date dataquindi è opportuno suddividere i dati in segmenti mensili. Possiamo riutilizzare le tabelle partizionate rimuovendo i dati al loro interno.

Partizione in base al tempo in segmenti di dimensioni diverse

Questo tipo di partizione viene eseguita laddove si accede ai dati obsoleti di rado. È implementato come un insieme di piccole partizioni per dati relativamente attuali, partizioni più grandi per dati inattivi.

Punti da notare

• Le informazioni dettagliate rimangono disponibili online.

• Il numero di tabelle fisiche viene mantenuto relativamente piccolo, il che riduce i costi operativi.

• Questa tecnica è adatta dove è richiesto un mix di dati che immergono la storia recente e il data mining attraverso l'intera storia.

• Questa tecnica non è utile quando il profilo di partizionamento cambia regolarmente, perché il ripartizionamento aumenterà il costo operativo del data warehouse.

Partizione su una dimensione diversa

La tabella dei fatti può anche essere partizionata sulla base di dimensioni diverse dal tempo come gruppo di prodotti, regione, fornitore o qualsiasi altra dimensione. Facciamo un esempio.

Supponiamo che una funzione di mercato sia stata strutturata in dipartimenti regionali distinti come in a state by statebase. Se ogni regione desidera eseguire query sulle informazioni acquisite all'interno della propria regione, sarebbe più efficace suddividere la tabella dei fatti in partizioni regionali. Ciò farà accelerare le query perché non richiede la scansione di informazioni non pertinenti.

Punti da notare

• La query non deve eseguire la scansione di dati irrilevanti che accelera il processo di query.

• Questa tecnica non è appropriata quando è improbabile che le dimensioni cambino in futuro. Quindi, vale la pena determinare che la dimensione non cambia in futuro.

• Se la dimensione cambia, l'intera tabella dei fatti dovrebbe essere ripartizionata.

Note - Si consiglia di eseguire la partizione solo sulla base della dimensione temporale, a meno che non si sia certi che il raggruppamento di dimensioni suggerito non cambierà durante la vita del data warehouse.

Partizione per dimensione della tabella

Quando non ci sono basi chiare per partizionare la tabella dei fatti su qualsiasi dimensione, allora dovremmo partition the fact table on the basis of their size.Possiamo impostare la dimensione predeterminata come punto critico. Quando la tabella supera la dimensione predeterminata, viene creata una nuova partizione di tabella.

Punti da notare

• Questo partizionamento è complesso da gestire.

• Richiede metadati per identificare quali dati sono archiviati in ciascuna partizione.

Dimensioni di partizionamento

Se una dimensione contiene un numero elevato di voci, è necessario partizionare le dimensioni. Qui dobbiamo controllare la dimensione di una dimensione.

Considera un design di grandi dimensioni che cambia nel tempo. Se dobbiamo memorizzare tutte le variazioni per applicare i confronti, quella dimensione potrebbe essere molto grande. Ciò influirebbe sicuramente sul tempo di risposta.

Partizioni Round Robin

Nella tecnica round robin, quando è necessaria una nuova partizione, viene archiviata quella vecchia. Utilizza i metadati per consentire allo strumento di accesso utente di fare riferimento alla partizione di tabella corretta.

Questa tecnica semplifica l'automazione delle funzionalità di gestione delle tabelle all'interno del data warehouse.

Partizione verticale

Partizionamento verticale, divide i dati verticalmente. Le immagini seguenti mostrano come viene eseguito il partizionamento verticale.

Il partizionamento verticale può essere eseguito nei due modi seguenti:

• Normalization
• Divisione di righe

Normalizzazione

La normalizzazione è il metodo relazionale standard di organizzazione del database. In questo metodo, le righe vengono compresse in una singola riga, quindi riduce lo spazio. Dai un'occhiata alle seguenti tabelle che mostrano come viene eseguita la normalizzazione.

Tabella prima della normalizzazione

Codice prodotto	Qtà	Valore	data_vendite	Store_id	Nome del negozio	Posizione	Regione
30	5	3.67	3 agosto 13	16	soleggiato	Bangalore	S
35	4	5.33	3-set-13	16	soleggiato	Bangalore	S
40	5	2.50	3-set-13	64	san	Mumbai	W
45	7	5.66	3-set-13	16	soleggiato	Bangalore	S

Tabella dopo la normalizzazione

Store_id	Nome del negozio	Posizione	Regione
16	soleggiato	Bangalore	W
64	san	Mumbai	S

Codice prodotto	Quantità	Valore	data_vendite	Store_id
30	5	3.67	3 agosto 13	16
35	4	5.33	3-set-13	16
40	5	2.50	3-set-13	64
45	7	5.66	3-set-13	16

Divisione di righe

La suddivisione delle righe tende a lasciare una mappa uno a uno tra le partizioni. Il motivo della suddivisione delle righe è accelerare l'accesso a un tavolo di grandi dimensioni riducendone le dimensioni.

Note - Durante l'utilizzo del partizionamento verticale, assicurarsi che non sia necessario eseguire un'operazione di join principale tra due partizioni.

Identifica la chiave per la partizione

È molto importante scegliere la giusta chiave di partizione. La scelta di una chiave di partizione sbagliata porterà a riorganizzare la tabella dei fatti. Facciamo un esempio. Supponiamo di voler partizionare la seguente tabella.

Account_Txn_Table
transaction_id
account_id
transaction_type
value
transaction_date
region
branch_name

Possiamo scegliere di partizionare su qualsiasi chiave. Le due possibili chiavi potrebbero essere

• region
• transaction_date

Supponiamo che l'attività sia organizzata in 30 regioni geografiche e ogni regione abbia un numero diverso di filiali. Questo ci darà 30 partizioni, il che è ragionevole. Questo partizionamento è abbastanza buono perché la nostra acquisizione dei requisiti ha dimostrato che la stragrande maggioranza delle query è limitata alla regione aziendale dell'utente.

Se partizioniamo per transaction_date invece che per regione, l'ultima transazione di ogni regione sarà in una partizione. Ora l'utente che desidera esaminare i dati all'interno della propria regione deve eseguire query su più partizioni.

Quindi vale la pena determinare la giusta chiave di partizionamento.

Cosa sono i metadati?

I metadati sono definiti semplicemente come dati sui dati. I dati utilizzati per rappresentare altri dati sono noti come metadati. Ad esempio, l'indice di un libro funge da metadati per i contenuti del libro. In altre parole, possiamo dire che i metadati sono i dati riassunti che ci portano a dati dettagliati. In termini di data warehouse, possiamo definire i metadati come segue.

• I metadati sono la road map per un data warehouse.

• I metadati in un data warehouse definiscono gli oggetti warehouse.

• I metadati fungono da directory. Questa directory aiuta il sistema di supporto decisionale a individuare i contenuti di un data warehouse.

Note- In un data warehouse, creiamo metadati per i nomi dei dati e le definizioni di un dato data warehouse. Insieme a questi metadati, vengono creati anche metadati aggiuntivi per la marcatura temporale dei dati estratti, l'origine dei dati estratti.

Categorie di metadati

I metadati possono essere suddivisi in tre categorie:

• Business Metadata - Contiene le informazioni sulla proprietà dei dati, la definizione aziendale e le politiche di modifica.

• Technical Metadata- Include nomi di sistema del database, nomi e dimensioni di tabelle e colonne, tipi di dati e valori consentiti. I metadati tecnici includono anche informazioni strutturali come attributi e indici di chiavi primarie ed esterne.

• Operational Metadata- Include la valuta dei dati e la derivazione dei dati. Per valuta dei dati si intende se i dati sono attivi, archiviati o eliminati. Derivazione dei dati significa la storia dei dati migrati e la trasformazione applicata su di essi.

Ruolo dei metadati

I metadati hanno un ruolo molto importante in un data warehouse. Il ruolo dei metadati in un magazzino è diverso dai dati del magazzino, ma gioca un ruolo importante. Di seguito vengono spiegati i vari ruoli dei metadati.

• I metadati fungono da directory.

• Questa directory aiuta il sistema di supporto decisionale a individuare i contenuti del data warehouse.

• I metadati aiutano nel sistema di supporto decisionale per la mappatura dei dati quando i dati vengono trasformati dall'ambiente operativo all'ambiente del data warehouse.

• I metadati aiutano a riepilogare tra dati dettagliati correnti e dati altamente riepilogati.

• I metadati aiutano anche a riepilogare tra dati leggermente dettagliati e dati altamente riepilogati.

• I metadati vengono utilizzati per gli strumenti di query.

• I metadati vengono utilizzati negli strumenti di estrazione e pulizia.

• I metadati vengono utilizzati negli strumenti di reporting.

• I metadati vengono utilizzati negli strumenti di trasformazione.

• I metadati giocano un ruolo importante nel caricamento delle funzioni.

Il diagramma seguente mostra i ruoli dei metadati.

Repository di metadati

Il repository di metadati è parte integrante di un sistema di data warehouse. Ha i seguenti metadati:

• Definition of data warehouse- Include la descrizione della struttura del data warehouse. La descrizione è definita da schema, vista, gerarchie, definizioni di dati derivati ​​e posizioni e contenuti del data mart.

• Business metadata - Contiene le informazioni sulla proprietà dei dati, la definizione aziendale e la modifica delle politiche.

• Operational Metadata- Include la valuta dei dati e la derivazione dei dati. Per valuta dei dati si intende se i dati sono attivi, archiviati o eliminati. Derivazione dei dati significa la storia dei dati migrati e la trasformazione applicata su di essi.

• Data for mapping from operational environment to data warehouse - Include i database di origine e il loro contenuto, l'estrazione dei dati, la pulizia della partizione dei dati, le regole di trasformazione, l'aggiornamento dei dati e le regole di eliminazione.

• Algorithms for summarization - Include algoritmi dimensionali, dati sulla granularità, aggregazione, riepilogo, ecc.

Sfide per la gestione dei metadati

L'importanza dei metadati non può essere sopravvalutata. I metadati aiutano a migliorare l'accuratezza dei report, convalidano la trasformazione dei dati e garantiscono l'accuratezza dei calcoli. I metadati impongono inoltre la definizione dei termini commerciali agli utenti finali aziendali. Con tutti questi usi dei metadati, ha anche le sue sfide. Alcune delle sfide sono discusse di seguito.

• I metadati in una grande organizzazione sono sparsi in tutta l'organizzazione. Questi metadati vengono distribuiti in fogli di calcolo, database e applicazioni.

• I metadati potrebbero essere presenti in file di testo o file multimediali. Per utilizzare questi dati per soluzioni di gestione delle informazioni, è necessario che siano definiti correttamente.

• Non esistono standard accettati a livello di settore. I fornitori di soluzioni per la gestione dei dati hanno un focus ristretto.

• Non esistono metodi facili e accettati per il passaggio dei metadati.

Perché abbiamo bisogno di un data mart?

Di seguito sono elencati i motivi per creare un data mart:

• Per partizionare i dati per imporre access control strategies.

• Per velocizzare le query riducendo il volume di dati da scansionare.

• Per segmentare i dati in diverse piattaforme hardware.

• Per strutturare i dati in una forma adatta per uno strumento di accesso utente.

Note- Non eseguire il data mart per nessun altro motivo poiché il costo operativo del data marting potrebbe essere molto elevato. Prima del data marting, assicurati che la strategia di data marting sia appropriata per la tua particolare soluzione.

Data marting conveniente

Seguire i passaggi indicati di seguito per rendere il data marting conveniente -

• Identificare le divisioni funzionali
• Identificare i requisiti dello strumento di accesso utente
• Identifica i problemi di controllo degli accessi

Identificare le divisioni funzionali

In questa fase, determiniamo se l'organizzazione ha suddivisioni funzionali naturali. Cerchiamo divisioni dipartimentali e determiniamo se il modo in cui i reparti utilizzano le informazioni tende a essere isolato dal resto dell'organizzazione. Facciamo un esempio.

Considera un'organizzazione di vendita al dettaglio, in cui ogni commerciante è responsabile dell'ottimizzazione delle vendite di un gruppo di prodotti. Per questo, le seguenti sono le informazioni preziose:

• transazione di vendita su base giornaliera
• previsioni di vendita su base settimanale
• posizione azionaria su base giornaliera
• movimenti delle scorte su base giornaliera

Poiché il commerciante non è interessato ai prodotti con cui non ha a che fare, il data marting è un sottoinsieme dei dati che trattano il gruppo di prodotti di interesse. Il diagramma seguente mostra il data marting per diversi utenti.

Di seguito sono riportati i problemi da prendere in considerazione durante la determinazione della divisione funzionale:

• La struttura del dipartimento può cambiare.

• I prodotti potrebbero passare da un reparto all'altro.

• Il commerciante potrebbe interrogare l'andamento delle vendite di altri prodotti per analizzare cosa sta succedendo alle vendite.

Note - Dobbiamo determinare i vantaggi aziendali e la fattibilità tecnica dell'utilizzo di un data mart.

Identificare i requisiti dello strumento di accesso utente

Abbiamo bisogno di data mart per supportare user access toolsche richiedono strutture dati interne. I dati in tali strutture sono fuori dal controllo del data warehouse ma devono essere popolati e aggiornati regolarmente.

Ci sono alcuni strumenti che popolano direttamente dal sistema di origine ma altri no. Pertanto, per il futuro è necessario identificare ulteriori requisiti al di fuori dell'ambito dello strumento.

Note - Al fine di garantire la coerenza dei dati in tutti gli strumenti di accesso, i dati non devono essere popolati direttamente dal data warehouse, ma ogni strumento deve avere il proprio data mart.

Identifica i problemi di controllo degli accessi

Dovrebbero esserci regole sulla privacy per garantire che i dati siano accessibili solo da utenti autorizzati. Ad esempio, un data warehouse per un istituto di credito al dettaglio garantisce che tutti i conti appartengano alla stessa persona giuridica. Le leggi sulla privacy possono costringerti a impedire totalmente l'accesso a informazioni che non sono di proprietà della banca specifica.

I data mart ci consentono di costruire un muro completo separando fisicamente i segmenti di dati all'interno del data warehouse. Per evitare possibili problemi di privacy, i dati dettagliati possono essere rimossi dal data warehouse. Possiamo creare data mart per ogni persona giuridica e caricarli tramite data warehouse, con dati dettagliati sull'account.

Progettazione di data mart

I data mart dovrebbero essere progettati come una versione più piccola dello schema starflake all'interno del data warehouse e dovrebbero corrispondere alla progettazione del database del data warehouse. Aiuta a mantenere il controllo sulle istanze del database.

I riepiloghi vengono sottoposti a data mart nello stesso modo in cui sarebbero stati progettati all'interno del data warehouse. Le tabelle di riepilogo aiutano a utilizzare tutti i dati di dimensione nello schema starflake.

Costo del data marting

Le misure dei costi per il data marting sono le seguenti:

• Costo hardware e software
• Accesso alla rete
• Vincoli della finestra temporale

Costo hardware e software

Sebbene i data mart vengano creati sullo stesso hardware, richiedono hardware e software aggiuntivi. Per gestire le query degli utenti, richiede potenza di elaborazione e spazio su disco aggiuntivi. Se i dati dettagliati e il data mart esistono all'interno del data warehouse, dovremmo sostenere costi aggiuntivi per archiviare e gestire i dati replicati.

Note - Il data marting è più costoso delle aggregazioni, quindi dovrebbe essere utilizzato come strategia aggiuntiva e non come strategia alternativa.

Accesso alla rete

Un data mart potrebbe trovarsi in una posizione diversa dal data warehouse, quindi dobbiamo assicurarci che la LAN o WAN abbia la capacità di gestire i volumi di dati trasferiti all'interno del data mart load process.

Vincoli della finestra temporale

La misura in cui un processo di caricamento del data mart occuperà la finestra di tempo disponibile dipende dalla complessità delle trasformazioni e dai volumi di dati spediti. La determinazione del numero di data mart possibili dipende da:

• Capacità di rete.
• Finestra temporale disponibile
• Volume di dati trasferiti
• Meccanismi utilizzati per inserire dati in un data mart

La gestione del sistema è obbligatoria per la corretta implementazione di un data warehouse. I gestori di sistema più importanti sono:

• Gestore della configurazione del sistema
• Gestore della pianificazione del sistema
• Gestore degli eventi di sistema
• Gestore database di sistema
• Gestore ripristino backup di sistema

System Configuration Manager

• Il gestore della configurazione del sistema è responsabile della gestione dell'installazione e della configurazione del data warehouse.

• La struttura del Configuration Manager varia da un sistema operativo all'altro.

• Nella struttura di configurazione Unix, il gestore varia da fornitore a fornitore.

• I gestori di configurazione hanno un'unica interfaccia utente.

• L'interfaccia del Configuration Manager ci permette di controllare tutti gli aspetti del sistema.

Note - Lo strumento di configurazione più importante è il gestore I / O.

System Scheduling Manager

System Scheduling Manager è responsabile della corretta implementazione del data warehouse. Il suo scopo è pianificare query ad hoc. Ogni sistema operativo ha il proprio scheduler con una qualche forma di meccanismo di controllo batch. L'elenco delle funzionalità che un gestore della pianificazione del sistema deve avere è il seguente:

• Lavora oltre i confini di cluster o MPP
• Gestisci le differenze di orario internazionali
• Gestire il fallimento del lavoro
• Gestisci più query
• Supportare le priorità del lavoro
• Riavviare o rimettere in coda i lavori non riusciti
• Avvisare l'utente o un processo quando il lavoro è stato completato
• Mantieni le pianificazioni dei lavori durante le interruzioni del sistema
• Re-accodare i lavori ad altre code
• Supporta l'arresto e l'avvio delle code
• Log lavori in coda
• Gestisci l'elaborazione tra le code

Note - L'elenco sopra può essere utilizzato come parametri di valutazione per la valutazione di un buon scheduler.

Alcuni lavori importanti che uno scheduler deve essere in grado di gestire sono i seguenti:

• Pianificazione delle query giornaliera e ad hoc
• Esecuzione dei requisiti di report periodici
• Caricamento dei dati
• Elaborazione dati
• Creazione dell'indice
• Backup
• Creazione di aggregazioni
• Trasformazione dei dati

Note - Se il data warehouse è in esecuzione su un'architettura cluster o MPP, il gestore della pianificazione del sistema deve essere in grado di funzionare sull'architettura.

System Event Manager

L'event manager è una specie di software. Il gestore eventi gestisce gli eventi definiti nel sistema di data warehouse. Non possiamo gestire manualmente il data warehouse perché la struttura del data warehouse è molto complessa. Abbiamo quindi bisogno di uno strumento che gestisca automaticamente tutti gli eventi senza alcun intervento dell'utente.

Note- L'Event manager monitora gli eventi che si verificano e li gestisce. Il gestore degli eventi tiene traccia anche della miriade di cose che possono andare storte in questo complesso sistema di data warehouse.

Eventi

Gli eventi sono le azioni che vengono generate dall'utente o dal sistema stesso. Si può notare che l'evento è un evento misurabile, osservabile, di un'azione definita.

Di seguito è riportato un elenco di eventi comuni che devono essere monitorati.

• Errore hardware
• Spazio esaurito su alcuni dischi delle chiavi
• Un processo che sta morendo
• Un processo che restituisce un errore
• Utilizzo della CPU che supera una soglia 805
• Contesa interna sui punti di serializzazione del database
• Rapporti di riscontro della cache del buffer in eccesso o errore al di sotto della soglia
• Un tavolo che arriva al massimo delle sue dimensioni
• Eccessivo scambio di memoria
• Un tavolo che non si allunga per mancanza di spazio
• Il disco presenta colli di bottiglia di I / O
• Utilizzo di aree temporanee o di smistamento che raggiungono determinate soglie
• Qualsiasi altro utilizzo della memoria condivisa del database

La cosa più importante degli eventi è che dovrebbero essere in grado di eseguirsi da soli. I pacchetti di eventi definiscono le procedure per gli eventi predefiniti. Il codice associato a ogni evento è noto come gestore eventi. Questo codice viene eseguito ogni volta che si verifica un evento.

Gestore di sistema e database

Il gestore del sistema e del database possono essere due parti separate del software, ma svolgono lo stesso lavoro. L'obiettivo di questi strumenti è automatizzare determinati processi e semplificare l'esecuzione di altri. I criteri per la scelta di un sistema e del database manager sono i seguenti:

• aumentare la quota dell'utente.
• assegnare e de-assegnare ruoli agli utenti
• assegnare e de-assegnare i profili agli utenti
• eseguire la gestione dello spazio del database
• monitorare e creare report sull'utilizzo dello spazio
• riordinare lo spazio frammentato e inutilizzato
• aggiungere ed espandere lo spazio
• aggiungere e rimuovere utenti
• gestire la password utente
• gestire tabelle di riepilogo o temporanee
• assegnare o assegnare spazio temporaneo ae dall'utente
• recuperare lo spazio da tabelle temporanee vecchie o obsolete
• gestire gli errori e i log di traccia
• per sfogliare i file di registro e traccia
• reindirizzare l'errore o rintracciare le informazioni
• attivare e disattivare la registrazione degli errori e delle tracce
• eseguire la gestione dello spazio di sistema
• monitorare e creare report sull'utilizzo dello spazio
• ripulire le directory di file vecchie e inutilizzate
• aggiungere o espandere lo spazio.

System Backup Recovery Manager

Lo strumento di backup e ripristino semplifica il backup dei dati da parte del personale operativo e di gestione. Notare che il gestore di backup del sistema deve essere integrato con il software di gestione della pianificazione utilizzato. Le caratteristiche importanti necessarie per la gestione dei backup sono le seguenti:

• Scheduling
• Monitoraggio dei dati di backup
• Consapevolezza del database

I backup vengono eseguiti solo per proteggersi dalla perdita di dati. Di seguito sono riportati i punti importanti da ricordare:

• Il software di backup manterrà una qualche forma di database di dove e quando è stato eseguito il backup del pezzo di dati.

• Il gestore ripristino backup deve disporre di un buon front-end per quel database.

• Il software di ripristino del backup dovrebbe essere a conoscenza del database.

• Essendo a conoscenza del database, il software può quindi essere indirizzato in termini di database e non eseguirà backup che non sarebbero fattibili.

I responsabili dei processi sono responsabili del mantenimento del flusso di dati sia in entrata che in uscita dal data warehouse. Esistono tre diversi tipi di process manager:

• Load manager
• Responsabile del magazzino
• Gestore delle query

Gestore del carico del data warehouse

Load manager esegue le operazioni richieste per estrarre e caricare i dati nel database. Le dimensioni e la complessità di un gestore del carico variano tra soluzioni specifiche da un data warehouse a un altro.

Architettura Load Manager

Il gestore del carico esegue le seguenti funzioni:

• Estrai i dati dal sistema di origine.

• Carica rapidamente i dati estratti nell'archivio dati temporaneo.

• Eseguire semplici trasformazioni in una struttura simile a quella nel data warehouse.

Estrai dati dall'origine

I dati vengono estratti dai database operativi o dai fornitori di informazioni esterni. I gateway sono i programmi applicativi utilizzati per estrarre i dati. È supportato dal DBMS sottostante e consente al programma client di generare SQL da eseguire su un server. Open Database Connection (ODBC) e Java Database Connection (JDBC) sono esempi di gateway.

Caricamento veloce

• Per ridurre al minimo la finestra di carico totale, i dati devono essere caricati nel magazzino nel più breve tempo possibile.

• Le trasformazioni influiscono sulla velocità di elaborazione dei dati.

• È più efficace caricare i dati in un database relazionale prima di applicare trasformazioni e controlli.

• La tecnologia gateway non è adatta, poiché sono inefficienti quando sono coinvolti grandi volumi di dati.

Trasformazioni semplici

Durante il caricamento, potrebbe essere necessario eseguire semplici trasformazioni. Dopo aver completato semplici trasformazioni, possiamo eseguire controlli complessi. Supponiamo di caricare la transazione di vendita EPOS, dobbiamo eseguire i seguenti controlli:

• Elimina tutte le colonne che non sono necessarie all'interno del magazzino.
• Converti tutti i valori nei tipi di dati richiesti.

Responsabile del magazzino

Il responsabile del magazzino è responsabile del processo di gestione del magazzino. Consiste in un software di sistema di terze parti, programmi C e script della shell. Le dimensioni e la complessità di un responsabile del magazzino variano tra le soluzioni specifiche.

Architettura del responsabile del magazzino

Un responsabile del magazzino include quanto segue:

• Il processo di controllo
• Stored procedure o C con SQL
• Strumento di backup / ripristino
• Script SQL

Funzioni di Warehouse Manager

Un responsabile del magazzino svolge le seguenti funzioni:

• Analizza i dati per eseguire controlli di coerenza e integrità referenziale.

• Crea indici, viste aziendali, viste delle partizioni rispetto ai dati di base.

• Genera nuove aggregazioni e aggiorna le aggregazioni esistenti.

• Genera normalizzazioni.

• Trasforma e unisce i dati di origine dell'archivio temporaneo nel data warehouse pubblicato.

• Esegue il backup dei dati nel data warehouse.

• Archivia i dati che hanno raggiunto la fine della loro vita catturata.

Note - Un responsabile del magazzino analizza i profili delle query per determinare se l'indice e le aggregazioni sono appropriati.

Query Manager

Il gestore delle query è responsabile di indirizzare le query alle tabelle adatte. Indirizzando le query alle tabelle appropriate, accelera la richiesta di query e il processo di risposta. Inoltre, il gestore delle query è responsabile della pianificazione dell'esecuzione delle query inviate dall'utente.

Architettura di Query Manager

Un Query Manager include i seguenti componenti:

• Reindirizzamento delle query tramite lo strumento C o RDBMS
• Procedura di archiviazione
• Strumento di gestione delle query
• Pianificazione delle query tramite lo strumento C o RDBMS
• Pianificazione delle query tramite software di terze parti

Funzioni di Query Manager

• Presenta i dati all'utente in una forma che comprende.

• Pianifica l'esecuzione delle query inviate dall'utente finale.

• Memorizza i profili delle query per consentire al responsabile del magazzino di determinare quali indici e aggregazioni sono appropriati.

L'obiettivo di un data warehouse è di rendere facilmente accessibili grandi quantità di dati agli utenti, consentendo così agli utenti di estrarre informazioni sull'azienda nel suo complesso. Ma sappiamo che potrebbero essere applicate alcune restrizioni di sicurezza sui dati che possono essere un ostacolo per l'accesso alle informazioni. Se l'analista ha una visione limitata dei dati, è impossibile acquisire un quadro completo delle tendenze all'interno dell'azienda.

I dati di ogni analista possono essere riepilogati e trasmessi alla direzione dove è possibile aggregare i diversi riepiloghi. Poiché le aggregazioni dei riepiloghi non possono essere uguali a quelle dell'aggregazione nel suo insieme, è possibile perdere alcune tendenze delle informazioni nei dati a meno che qualcuno non stia analizzando i dati nel loro insieme.

Requisiti di sicurezza

L'aggiunta di funzionalità di sicurezza influisce sulle prestazioni del data warehouse, pertanto è importante determinare i requisiti di sicurezza il prima possibile. È difficile aggiungere funzionalità di sicurezza dopo che il data warehouse è stato attivato.

Durante la fase di progettazione del data warehouse, dobbiamo tenere presente quali origini dati possono essere aggiunte in seguito e quale sarebbe l'impatto dell'aggiunta di tali origini dati. Dovremmo considerare le seguenti possibilità durante la fase di progettazione.

• Se le nuove origini dati richiederanno l'implementazione di nuove restrizioni di sicurezza e / o di controllo?

• Se i nuovi utenti aggiunti che hanno accesso limitato ai dati che sono già generalmente disponibili?

Questa situazione si verifica quando i futuri utenti e le fonti di dati non sono ben noti. In una situazione del genere, dobbiamo utilizzare la conoscenza del business e l'obiettivo del data warehouse per conoscere i requisiti probabili.

Le seguenti attività sono influenzate dalle misure di sicurezza:

• Accesso utente
• Caricamento dei dati
• Spostamento dei dati
• Generazione di query

Accesso utente

Dobbiamo prima classificare i dati e poi classificare gli utenti sulla base dei dati a cui possono accedere. In altre parole, gli utenti vengono classificati in base ai dati a cui possono accedere.

Data Classification

I seguenti due approcci possono essere utilizzati per classificare i dati:

• I dati possono essere classificati in base alla loro sensibilità. I dati altamente sensibili sono classificati come altamente limitati e i dati meno sensibili sono classificati come meno restrittivi.

• I dati possono anche essere classificati in base alla funzione lavorativa. Questa restrizione consente solo a utenti specifici di visualizzare dati particolari. Qui limitiamo gli utenti a visualizzare solo quella parte dei dati a cui sono interessati e di cui sono responsabili.

Ci sono alcuni problemi nel secondo approccio. Per capire, facciamo un esempio. Supponiamo che tu stia costruendo il data warehouse per una banca. Considera che i dati archiviati nel data warehouse sono i dati delle transazioni per tutti gli account. La domanda qui è: chi può vedere i dati della transazione. La soluzione sta nel classificare i dati in base alla funzione.

User classification

I seguenti approcci possono essere utilizzati per classificare gli utenti:

• Gli utenti possono essere classificati in base alla gerarchia degli utenti in un'organizzazione, ovvero gli utenti possono essere classificati per reparti, sezioni, gruppi e così via.

• Gli utenti possono anche essere classificati in base al loro ruolo, con le persone raggruppate nei reparti in base al loro ruolo.

Classification on basis of Department

Facciamo un esempio di un data warehouse in cui gli utenti provengono dal reparto vendite e marketing. Possiamo avere la sicurezza dalla vista aziendale dall'alto verso il basso, con accesso centrato sui diversi reparti. Ma potrebbero esserci alcune restrizioni per gli utenti a diversi livelli. Questa struttura è mostrata nel diagramma seguente.

Ma se ogni reparto accede a dati diversi, dovremmo progettare l'accesso di sicurezza per ogni reparto separatamente. Ciò può essere ottenuto dai data mart dipartimentali. Poiché questi data mart sono separati dal data warehouse, possiamo applicare restrizioni di sicurezza separate su ogni data mart. Questo approccio è mostrato nella figura seguente.

Classification Based on Role

Se i dati sono generalmente disponibili a tutti i reparti, è utile seguire la gerarchia di accesso dei ruoli. In altre parole, se i dati sono generalmente accessibili da tutti i reparti, applicare le restrizioni di sicurezza in base al ruolo dell'utente. La gerarchia di accesso al ruolo è mostrata nella figura seguente.

Requisiti di audit

L'auditing è un sottoinsieme della sicurezza, un'attività costosa. L'auditing può causare pesanti sovraccarichi al sistema. Per completare un audit in tempo, abbiamo bisogno di più hardware e, pertanto, si consiglia, ove possibile, di disattivare l'audit. I requisiti di audit possono essere classificati come segue:

• Connections
• Disconnections
• Accesso ai dati
• Modifica dei dati

Note- Per ciascuna delle suddette categorie, è necessario verificare il successo, il fallimento o entrambi. Dal punto di vista dei motivi di sicurezza, l'audit dei guasti è molto importante. La verifica dei guasti è importante perché possono evidenziare accessi non autorizzati o fraudolenti.

Requisiti di rete

La sicurezza della rete è importante quanto gli altri titoli. Non possiamo ignorare i requisiti di sicurezza della rete. Dobbiamo considerare i seguenti problemi:

• È necessario crittografare i dati prima di trasferirli al data warehouse?

• Ci sono restrizioni su quali percorsi di rete possono prendere i dati?

Queste restrizioni devono essere considerate attentamente. Di seguito sono riportati i punti da ricordare:

• Il processo di crittografia e decrittografia aumenterà i costi generali. Richiederebbe più potenza di elaborazione e tempo di elaborazione.

• Il costo della crittografia può essere elevato se il sistema è già un sistema caricato poiché la crittografia è a carico del sistema di origine.

Spostamento dei dati

Esistono potenziali implicazioni per la sicurezza durante lo spostamento dei dati. Supponiamo di dover trasferire alcuni dati limitati come file flat da caricare. Quando i dati vengono caricati nel data warehouse, vengono sollevate le seguenti domande:

• Dove viene archiviato il file flat?
• Chi ha accesso a quello spazio su disco?

Se parliamo del backup di questi file flat, vengono sollevate le seguenti domande:

• Esegui il backup delle versioni crittografate o decrittografate?
• È necessario eseguire questi backup su nastri speciali archiviati separatamente?
• Chi ha accesso a questi nastri?

È necessario considerare anche alcune altre forme di spostamento dei dati come i set di risultati delle query. Le domande sollevate durante la creazione della tabella temporanea sono le seguenti:

• Dove si terrà quel tavolo temporaneo?
• Come si rende visibile questo tavolo?

Dobbiamo evitare la violazione accidentale delle restrizioni di sicurezza. Se un utente con accesso ai dati limitati può generare tabelle temporanee accessibili, i dati possono essere visibili agli utenti non autorizzati. Possiamo superare questo problema disponendo di un'area temporanea separata per gli utenti con accesso a dati limitati.

Documentazione

I requisiti di controllo e sicurezza devono essere adeguatamente documentati. Questo sarà considerato come una parte della giustificazione. Questo documento può contenere tutte le informazioni raccolte da:

• Classificazione dei dati
• Classificazione degli utenti
• Requisiti di rete
• Requisiti per lo spostamento e l'archiviazione dei dati
• Tutte le azioni verificabili

Impatto della sicurezza sul design

La sicurezza influisce sul codice dell'applicazione e sui tempi di sviluppo. La sicurezza influisce sulla seguente area:

• Sviluppo di applicazioni
• Progettazione di database
• Testing

Sviluppo di applicazioni

La sicurezza influisce sullo sviluppo generale dell'applicazione e influisce anche sulla progettazione dei componenti importanti del data warehouse, come il gestore del carico, il gestore del magazzino e il gestore delle query. Il gestore del carico potrebbe richiedere il controllo del codice per filtrare i record e posizionarli in posizioni diverse. Potrebbero essere necessarie ulteriori regole di trasformazione per nascondere determinati dati. Inoltre potrebbero essere necessari metadati aggiuntivi per gestire eventuali oggetti aggiuntivi.

Per creare e mantenere viste aggiuntive, il responsabile del magazzino potrebbe richiedere codici aggiuntivi per rafforzare la sicurezza. Potrebbe essere necessario codificare ulteriori controlli nel data warehouse per evitare che venga indotto a spostare i dati in una posizione in cui non dovrebbero essere disponibili. Il gestore query richiede le modifiche per gestire eventuali limitazioni di accesso. Il gestore delle query dovrà essere a conoscenza di tutte le visualizzazioni e aggregazioni aggiuntive.

Progettazione di database

Anche il layout del database viene influenzato perché quando vengono implementate le misure di sicurezza, si verifica un aumento del numero di visualizzazioni e tabelle. L'aggiunta di sicurezza aumenta le dimensioni del database e quindi aumenta la complessità della progettazione e della gestione del database. Aggiungerà inoltre complessità alla gestione del backup e al piano di ripristino.

Test

Il test del data warehouse è un processo lungo e complesso. L'aggiunta di sicurezza al data warehouse influisce anche sulla complessità del tempo di test. Influisce sul test nei due modi seguenti:

• Aumenterà il tempo necessario per l'integrazione e il test del sistema.

• Sono presenti funzionalità aggiuntive da testare che aumenteranno le dimensioni della suite di test.

Un data warehouse è un sistema complesso e contiene un enorme volume di dati. Pertanto è importante eseguire il backup di tutti i dati in modo che siano disponibili per il ripristino in futuro secondo i requisiti. In questo capitolo, discuteremo i problemi nella progettazione della strategia di backup.

Terminologie di backup

Prima di procedere oltre, è necessario conoscere alcune delle terminologie di backup discusse di seguito.

• Complete backup- Esegue il backup dell'intero database contemporaneamente. Questo backup include tutti i file di database, i file di controllo e i file journal.

• Partial backup- Come suggerisce il nome, non crea un backup completo del database. Il backup parziale è molto utile nei database di grandi dimensioni perché consente una strategia in base alla quale viene eseguito il backup di varie parti del database in modo round robin su base giornaliera, in modo che il backup dell'intero database venga eseguito efficacemente una volta alla settimana.

• Cold backup- Il backup a freddo viene eseguito mentre il database è completamente chiuso. Nell'ambiente multiistanza, tutte le istanze dovrebbero essere chiuse.

• Hot backup- Il backup a caldo viene eseguito quando il motore del database è attivo e in esecuzione. I requisiti del backup a caldo variano da RDBMS a RDBMS.

• Online backup - È abbastanza simile al backup a caldo.

Backup hardware

È importante decidere quale hardware utilizzare per il backup. La velocità di elaborazione del backup e del ripristino dipende dall'hardware utilizzato, dalla modalità di connessione dell'hardware, dalla larghezza di banda della rete, dal software di backup e dalla velocità del sistema I / O del server. Qui discuteremo alcune delle scelte hardware disponibili e i loro pro e contro. Queste scelte sono le seguenti:

• Tecnologia a nastro
• Backup del disco

Tecnologia a nastro

La scelta del nastro può essere classificata come segue:

• Supporti su nastro
• Unità a nastro autonome
• Impilatori di nastri
• Silos di nastri

Tape Media

Esistono diverse varietà di supporti a nastro. Alcuni standard dei supporti a nastro sono elencati nella tabella seguente:

Supporto a nastro	Capacità	Velocità di I / O
DLT	40 GB	3 MB / s
3490e	1,6 GB	3 MB / s
8 mm	14 GB	1 MB / s

Altri fattori che devono essere considerati sono i seguenti:

• Affidabilità del supporto nastro
• Costo del supporto nastro per unità
• Scalability
• Costo degli aggiornamenti al sistema a nastro
• Costo del supporto nastro per unità
• Periodo di validità del supporto nastro

Standalone Tape Drives

Le unità a nastro possono essere collegate nei seguenti modi:

• Direttamente al server
• Come dispositivi disponibili in rete
• In remoto su un'altra macchina

Potrebbero verificarsi problemi nel collegamento delle unità nastro a un data warehouse.

• Considera che il server è una macchina MPP a 48 nodi. Non conosciamo il nodo per connettere le unità a nastro e non sappiamo come distribuirle sui nodi del server per ottenere le prestazioni ottimali con la minima interruzione del server e la minima latenza I / O interna.

• Il collegamento dell'unità a nastro come dispositivo disponibile in rete richiede che la rete sia all'altezza delle enormi velocità di trasferimento dei dati. Assicurati che sia disponibile una larghezza di banda sufficiente per tutto il tempo richiesto.

• Anche il collegamento delle unità a nastro in remoto richiede una larghezza di banda elevata.

Impilatori di nastri

Il metodo per caricare più nastri in una singola unità nastro è noto come impilatori di nastri. Lo stacker smonta il nastro corrente quando ha finito con esso e carica il nastro successivo, quindi è disponibile un solo nastro alla volta a cui accedere. Il prezzo e le funzionalità possono variare, ma l'abilità comune è che possono eseguire backup automatici.

Silos a nastro

I silos di nastri forniscono grandi capacità di magazzino. I silos di nastri possono archiviare e gestire migliaia di nastri. Possono integrare più unità nastro. Hanno il software e l'hardware per etichettare e archiviare i nastri che archiviano. È molto comune che il silo sia connesso in remoto tramite una rete o un collegamento dedicato. Dovremmo assicurarci che la larghezza di banda della connessione sia all'altezza del lavoro.

Backup del disco

I metodi di backup del disco sono:

• Backup da disco a disco
• Specchio che si rompe

Questi metodi vengono utilizzati nel sistema OLTP. Questi metodi riducono al minimo il tempo di inattività del database e massimizzano la disponibilità.

Disk-to-Disk Backups

Qui il backup viene eseguito sul disco piuttosto che sul nastro. I backup da disco a disco vengono eseguiti per i seguenti motivi:

• Velocità dei backup iniziali
• Velocità di ripristino

Il backup dei dati da disco a disco è molto più veloce che su nastro. Tuttavia è il passaggio intermedio del backup. Successivamente viene eseguito il backup dei dati sul nastro. L'altro vantaggio dei backup da disco a disco è che fornisce una copia in linea dell'ultimo backup.

Mirror Breaking

L'idea è di avere dischi con mirroring per la resilienza durante la giornata lavorativa. Quando è richiesto il backup, uno dei set di mirror può essere suddiviso. Questa tecnica è una variante dei backup da disco a disco.

Note - Potrebbe essere necessario chiudere il database per garantire la coerenza del backup.

Jukebox ottici

I jukebox ottici consentono di memorizzare i dati vicino alla linea. Questa tecnica consente di gestire un gran numero di dischi ottici allo stesso modo di un impilatore di nastri o di un silo di nastri. Lo svantaggio di questa tecnica è che ha una velocità di scrittura ridotta rispetto ai dischi. Ma il supporto ottico offre lunga durata e affidabilità che li rende una buona scelta di supporto per l'archiviazione.

Backup software

Sono disponibili strumenti software che aiutano nel processo di backup. Questi strumenti software vengono forniti come pacchetto. Questi strumenti non solo eseguono il backup, ma possono gestire e controllare efficacemente le strategie di backup. Ci sono molti pacchetti software disponibili sul mercato. Alcuni di loro sono elencati nella tabella seguente:

Nome del pacchetto	Venditore
Networker	Legato
ADSM	IBM
Epoca	Epoch Systems
Omniback II	HP
Alessandria	Sequent

Criteri per la scelta dei pacchetti software

I criteri per la scelta del miglior pacchetto software sono elencati di seguito:

• Quanto è scalabile il prodotto quando vengono aggiunte le unità a nastro?
• Il pacchetto ha un'opzione client-server o deve essere eseguito sul server del database stesso?
• Funzionerà in ambienti cluster e MPP?
• Quale grado di parallelismo è richiesto?
• Quali piattaforme sono supportate dal pacchetto?
• Il pacchetto supporta un facile accesso alle informazioni sui contenuti del nastro?
• Il database dei pacchetti è a conoscenza?
• Quali unità a nastro e supporti a nastro sono supportati dal pacchetto?

Un data warehouse continua a evolversi ed è imprevedibile quale query l'utente pubblicherà in futuro. Pertanto diventa più difficile mettere a punto un sistema di data warehouse. In questo capitolo, discuteremo come ottimizzare i diversi aspetti di un data warehouse come prestazioni, caricamento dei dati, query, ecc.

Difficoltà nell'ottimizzazione del data warehouse

La messa a punto di un data warehouse è una procedura difficile per i seguenti motivi:

• Il data warehouse è dinamico; non rimane mai costante.

• È molto difficile prevedere quale query l'utente pubblicherà in futuro.

• I requisiti aziendali cambiano con il tempo.

• Gli utenti ei loro profili continuano a cambiare.

• L'utente può passare da un gruppo all'altro.

• Anche il carico dei dati sul magazzino cambia nel tempo.

Note - È molto importante avere una conoscenza completa del data warehouse.

Valutazione delle prestazioni

Ecco un elenco di misure oggettive della performance:

• Tempo medio di risposta alle query
• Velocità di scansione
• Tempo utilizzato per query giornaliera
• Utilizzo della memoria per processo
• Velocità di trasmissione I / O

Di seguito sono riportati i punti da ricordare.

• È necessario specificare le misure nell'accordo sul livello di servizio (SLA).

• È inutile cercare di regolare i tempi di risposta, se sono già migliori di quelli richiesti.

• È essenziale avere aspettative realistiche durante la valutazione delle prestazioni.

• È anche essenziale che gli utenti abbiano aspettative realizzabili.

• Per nascondere la complessità del sistema all'utente, è necessario utilizzare aggregazioni e visualizzazioni.

• È anche possibile che l'utente possa scrivere una query per la quale non eri sintonizzato.

Ottimizzazione del caricamento dei dati

Il caricamento dei dati è una parte fondamentale dell'elaborazione notturna. Nient'altro può essere eseguito fino al completamento del caricamento dei dati. Questo è il punto di ingresso nel sistema.

Note- Se si verifica un ritardo nel trasferimento dei dati o nell'arrivo dei dati, l'intero sistema ne risente gravemente. Pertanto è molto importante regolare prima il caricamento dei dati.

Esistono vari approcci per l'ottimizzazione del caricamento dei dati discussi di seguito:

• L'approccio molto comune consiste nell'inserire i dati utilizzando il SQL Layer. In questo approccio, devono essere eseguiti normali controlli e vincoli. Quando i dati vengono inseriti nella tabella, il codice verrà eseguito per verificare lo spazio sufficiente per inserire i dati. Se non è disponibile spazio sufficiente, potrebbe essere necessario allocare più spazio a queste tabelle. Questi controlli richiedono tempo per essere eseguiti e sono costosi per la CPU.

• Il secondo approccio consiste nell'aggirare tutti questi controlli e vincoli e inserire i dati direttamente nei blocchi preformattati. Questi blocchi vengono successivamente scritti nel database. È più veloce del primo approccio, ma può funzionare solo con interi blocchi di dati. Questo può portare a uno spreco di spazio.

• Il terzo approccio è che durante il caricamento dei dati nella tabella che già contiene la tabella, possiamo mantenere gli indici.

• Il quarto approccio dice che per caricare i dati in tabelle che già contengono dati, drop the indexes & recreate themquando il caricamento dei dati è completo. La scelta tra il terzo e il quarto approccio dipende dalla quantità di dati già caricati e dal numero di indici da ricostruire.

Controlli di integrità

Il controllo dell'integrità influisce notevolmente sulle prestazioni del carico. Di seguito sono riportati i punti da ricordare:

• I controlli di integrità devono essere limitati perché richiedono un'elevata potenza di elaborazione.

• I controlli di integrità dovrebbero essere applicati al sistema di origine per evitare il degrado delle prestazioni del carico di dati.

Query di ottimizzazione

Abbiamo due tipi di query nel data warehouse:

• Query fisse
• Query ad hoc

Query fisse

Le query fisse sono ben definite. Di seguito sono riportati gli esempi di query fisse:

• rapporti regolari
• Query predefinite
• Aggregazioni comuni

L'ottimizzazione delle query fisse in un data warehouse è la stessa di un sistema di database relazionale. L'unica differenza è che la quantità di dati da interrogare potrebbe essere diversa. È utile memorizzare il piano di esecuzione di maggior successo durante il test delle query fisse. La memorizzazione di questi piani di esecuzione ci consentirà di individuare la modifica delle dimensioni dei dati e l'inclinazione dei dati, poiché causerà la modifica del piano di esecuzione.

Note - Non possiamo fare di più sulla tabella dei fatti, ma mentre ci occupiamo delle tabelle delle dimensioni o delle aggregazioni, è possibile utilizzare la solita raccolta di modifiche SQL, meccanismi di archiviazione e metodi di accesso per ottimizzare queste query.

Query ad hoc

Per comprendere le query ad hoc, è importante conoscere gli utenti ad hoc del data warehouse. Per ogni utente o gruppo di utenti, è necessario conoscere quanto segue:

• Il numero di utenti nel gruppo
• Se utilizzano query ad hoc a intervalli di tempo regolari
• Indica se utilizzano frequentemente query ad hoc
• Se utilizzano occasionalmente query ad hoc a intervalli sconosciuti.
• La dimensione massima della query che tendono a eseguire
• La dimensione media della query che tendono a eseguire
• Se richiedono l'accesso drill-down ai dati di base
• Il tempo di accesso trascorso al giorno
• L'ora di punta dell'utilizzo quotidiano
• Il numero di query eseguite per ora di punta

Points to Note

• È importante tenere traccia dei profili dell'utente e identificare le query eseguite regolarmente.

• È anche importante che la messa a punto eseguita non influisca sulle prestazioni.

• Identifica query simili e ad hoc che vengono eseguite di frequente.

• Se queste query vengono identificate, il database cambierà e sarà possibile aggiungere nuovi indici per tali query.

• Se queste query vengono identificate, è possibile creare nuove aggregazioni specificamente per quelle query che risulterebbero nella loro esecuzione efficiente.

I test sono molto importanti per i sistemi di data warehouse per farli funzionare correttamente ed efficientemente. Esistono tre livelli di base di test eseguiti su un data warehouse:

• Test unitario
• Test d'integrazione
• Test di sistema

Test unitario

• In unit test, ogni componente viene testato separatamente.

• Ogni modulo, cioè procedura, programma, script SQL, shell Unix viene testato.

• Questo test viene eseguito dallo sviluppatore.

Test d'integrazione

• Nel test di integrazione, i vari moduli dell'applicazione vengono riuniti e quindi testati rispetto al numero di input.

• Viene eseguito per verificare se i vari componenti funzionano correttamente dopo l'integrazione.

Test di sistema

• Durante il test del sistema, l'intera applicazione del data warehouse viene testata insieme.

• Lo scopo del test del sistema è verificare se l'intero sistema funziona correttamente insieme o meno.

• Il test del sistema viene eseguito dal team di test.

• Poiché le dimensioni dell'intero data warehouse sono molto grandi, di solito è possibile eseguire test di sistema minimi prima che il piano di test possa essere attuato.

Programma dei test

Prima di tutto, il programma di test viene creato nel processo di sviluppo del piano di test. In questa pianificazione, prevediamo il tempo stimato necessario per il test dell'intero sistema di data warehouse.

Sono disponibili diverse metodologie per creare una pianificazione dei test, ma nessuna è perfetta perché il data warehouse è molto complesso e di grandi dimensioni. Anche il sistema di data warehouse si sta evolvendo in natura. Si possono affrontare i seguenti problemi durante la creazione di un programma di test:

• Un problema semplice può avere una query di grandi dimensioni che può richiedere un giorno o più per essere completata, ovvero la query non viene completata in una scala temporale desiderata.

• Potrebbero verificarsi errori hardware come la perdita di un disco o errori umani come l'eliminazione accidentale di una tabella o la sovrascrittura di una tabella di grandi dimensioni.

Note - A causa delle difficoltà sopra menzionate, si consiglia di raddoppiare sempre il tempo che normalmente si concede per il test.

Test del ripristino del backup

Il test della strategia di ripristino del backup è estremamente importante. Ecco l'elenco degli scenari per i quali è necessario questo test:

• Errore multimediale
• Perdita o danneggiamento dello spazio tabella o del file di dati
• Perdita o danneggiamento del file di registro di ripristino
• Perdita o danneggiamento del file di controllo
• Errore istanza
• Perdita o danneggiamento del file di archivio
• Perdita o danneggiamento del tavolo
• Errore durante l'errore dei dati

Test dell'ambiente operativo

Ci sono una serie di aspetti che devono essere testati. Questi aspetti sono elencati di seguito.

• Security- Per i test di sicurezza è necessario un documento di sicurezza separato. Questo documento contiene un elenco di operazioni non consentite e test di progettazione per ciascuna.

• Scheduler- Il software di pianificazione è necessario per controllare le operazioni quotidiane di un data warehouse. Deve essere testato durante il test del sistema. Il software di pianificazione richiede un'interfaccia con il data warehouse, che richiederà allo scheduler di controllare l'elaborazione notturna e la gestione delle aggregazioni.

• Disk Configuration.- Anche la configurazione del disco deve essere testata per identificare i colli di bottiglia di I / O. Il test deve essere eseguito più volte con impostazioni diverse.

• Management Tools.- È necessario testare tutti gli strumenti di gestione durante il test del sistema. Ecco l'elenco degli strumenti che devono essere testati.

  • Manager di eventi
  • Gestore di sistema
  • Gestore di database
  • Gestore della configurazione
  • Gestione ripristino backup

Testare il database

Il database viene testato nei tre modi seguenti:

• Testing the database manager and monitoring tools - Per testare il database manager e gli strumenti di monitoraggio, è necessario utilizzarli nella creazione, esecuzione e gestione del database di test.

• Testing database features - Ecco l'elenco delle funzionalità che dobbiamo testare -

  • Query in parallelo

  • Crea indice in parallelo

  • Caricamento dei dati in parallelo

• Testing database performance- L'esecuzione delle query gioca un ruolo molto importante nelle misure delle prestazioni del data warehouse. Esistono serie di query fisse che devono essere eseguite regolarmente e dovrebbero essere testate. Per testare le query ad hoc, è necessario esaminare il documento sui requisiti dell'utente e comprendere completamente l'attività. Prenditi del tempo per testare le query più scomode che è probabile che l'azienda chieda rispetto a diverse strategie di indice e aggregazione.

Test dell'applicazione

• Tutti i gestori dovrebbero essere integrati correttamente e lavorare in modo da garantire che il carico, l'indice, l'aggregazione e le query end-to-end funzionino secondo le aspettative.

• Ogni funzione di ogni manager dovrebbe funzionare correttamente

• È inoltre necessario testare l'applicazione per un periodo di tempo.

• Dovrebbero essere testate anche le attività di fine settimana e di fine mese.

Logistica del test

Lo scopo del test di sistema è testare tutte le seguenti aree:

• Software di pianificazione
• Procedure operative quotidiane
• Strategia di ripristino del backup
• Strumenti di gestione e pianificazione
• Elaborazione notturna
• Prestazioni delle query

Note- Il punto più importante è testare la scalabilità. In caso contrario, ci lasceremo un progetto di sistema che non funziona quando il sistema cresce.

Di seguito sono riportati gli aspetti futuri del data warehousing.

• Come abbiamo visto che la dimensione del database aperto è cresciuta di circa il doppio della sua grandezza negli ultimi anni, mostra il valore significativo che contiene.

• Man mano che le dimensioni dei database crescono, le stime di ciò che costituisce un database molto grande continuano a crescere.

• L'hardware e il software oggi disponibili non consentono di mantenere una grande quantità di dati online. Ad esempio, un record di una chiamata Telco richiede 10 TB di dati da mantenere online, che è solo una dimensione del record di un mese. Se è necessario tenere un registro delle vendite, del cliente del marketing, dei dipendenti, ecc., La dimensione sarà superiore a 100 TB.

• Il record contiene informazioni testuali e alcuni dati multimediali. I dati multimediali non possono essere facilmente manipolati come dati di testo. La ricerca dei dati multimediali non è un compito facile, mentre le informazioni testuali possono essere recuperate dal software relazionale oggi disponibile.

• A parte la pianificazione delle dimensioni, è complesso costruire ed eseguire sistemi di data warehouse di dimensioni sempre maggiori. Con l'aumentare del numero di utenti, aumenta anche la dimensione del data warehouse. Questi utenti richiederanno anche di accedere al sistema.

• Con la crescita di Internet, è necessario che gli utenti accedano ai dati online.

Quindi la forma futura del data warehouse sarà molto diversa da quella che viene creata oggi.