Migrazione ad Analysis Services 2005
Articolo tecnico su SQL Server
Relativo a: SQL Server 2005
Riassunto: In questo articolo viene descritta la procedura per la migrazione ad Analysis Services in SQL Server 2005. Il modello dimensionale unificato (UDM, Unified Dimensional Model) offre agli sviluppatori di cubi nuove opportunità di progettazione. Il modello UDM ha unito i mondi del reporting relazionale e OLAP per offrire un forum unificato per entrambi gli ambienti di richiesta dei dati. La comprensione delle nuove opzioni di progettazione e il loro influsso sull'organizzazione consente di ottimizzare la migrazione. Migration Wizard (Migrazione guidata) è uno strumento rapido ed efficace per il trasferimento dei cubi esistenti in Analysis Services 2005. Questo articolo presenta la procedura guidata e consente di determinare se sia necessario utilizzarla. In alcuni casi, infatti, è preferibile optare per una nuova progettazione ed assicurarsi di sfruttare correttamente le nuove funzioni di Analysis Services 2005.
In questa pagina
Informazioni su Project REAL
Lo scopo di Project REAL è individuare le procedure consigliate per la creazione di applicazioni di business intelligence basate su Microsoft® SQL Server™ 2005, realizzando implementazioni di riferimento relative a scenari di clienti reali. Ciò significa che i dati dei clienti vengono acquisiti e utilizzati per risolvere gli stessi problemi che i clienti affrontano durante la distribuzione. Tali problemi riguardano:
| • | Progettazione degli schemi |
| • | Implementazione delle procedure ETL di estrazione, trasformazione e caricamento dei dati |
| • | Dimensionamento dei sistemi per la produzione |
| • | Gestione e manutenzione regolare dei sistemi |
Utilizzando scenari di distribuzione reali è possibile comprendere pienamente come utilizzare gli strumenti. Lo scopo è tentare di risolvere i numerosi problemi affrontati dalle grandi aziende durante la distribuzione in ambienti reali. In questo articolo viene illustrato il ruolo della migrazione in Project REAL. Project REAL utilizza i dati relativi a due clienti Microsoft per il settore della business intelligence. La Fase 1 del progetto è stata modellata su un importante rivenditore di elettronica che conserva i dati inerenti alle vendite e all'inventario in un data wharehouse Microsoft SQL Server 2000. SQL Server 2000 Data Transformation Services (DTS) viene utilizzato per gestire il flusso dei dati nel database relazionale e da quest'ultimo ai cubi di SQL Server 2000 Analysis Services per il reporting e l'esecuzione di query interattive. Il cliente conserva circa 200 GB di dati nell'archivio relazionale. Tutti i dati vengono successivamente elaborati nei cubi di Analysis Services. L'implementazione della Fase 1 si concentra principalmente sui problemi che un utente esistente di SQL Server 2000 potrebbe riscontrare durante la migrazione a SQL Server 2005. I risultati rappresentano in modo significativo la migrazione delle funzionalità esistenti integrata, se necessario, con l'utilizzo di alcune nuove funzioni. Per quanto concerne la migrazione ad Analysis Services il cubo di dati è stato trasferito ad Analysis Services 2005 principalmente mediante la procedura di migrazione guidata. Al termine della migrazione, ai cubi sono state aggiunte ulteriori funzioni.
La Fase 2 di Project REAL si basa su un insieme di dati più ampio proveniente da un altro cliente e utilizza una quantità di nuove funzioni di SQL Server 2005 superiore a quello della Fase 1. Ciò è dovuto al fatto che la Fase 2 è essenzialmente una nuova implementazione di una soluzione SQL Server 2005. Lo scopo della Fase 2 era mostrare numerose nuove funzioni di Analysis Services. Poiché si è determinato che nella Fase 2 era necessario progettare nuovamente i cubi, la migrazione guidata non è stata utilizzata. Ulteriori articoli su Project REAL verranno pubblicati in futuro.
Introduzione
Analysis Services 2005 offre un nuovo approccio a OLAP e consente di integrare completamente le esigenze relative al reporting OLAP e al reporting relazionale. Grazie ad Analysis Services 2005 è possibile diminuire il carico complessivo delle attività di amministrazione dei cubi e migliorare l'esperienza dell'utente finale. L'approccio alla progettazione del modello UDM rappresenta un elemento di continuità tra i mondi del reporting OLAP e del reporting relazionale. È stato modificato il modo con cui vengono strutturati i cubi.
Le nuove funzioni di Analysis Services 2005 consentono di impostare più correttamente i modelli di navigazione comuni, soddisfacendo e superando i requisiti del reporting relazionale e del reporting OLAP, gestire tipi di dati unici e diminuire l'overhead della memoria dovuto alle analisi.
In questo articolo viene analizzato il processo di migrazione e, grazie a esso, gli utenti potranno determinare il percorso di migrazione più adatto per la propria organizzazione. La migrazione può essere effettuata utilizzando gli strumenti di migrazione incorporati, oppure progettando nuovamente i cubi esistenti. In questo articolo vengono illustrate le modifiche nella progettazione di Analysis Services 2005 e l'impatto che queste modifiche eserciteranno sulla struttura dei cubi corrente.
In questo articolo vengono esaminati i passaggi principali della migrazione guidata. Inoltre, vengono proposte alcune domande la cui risposta permette di determinare se l'uso della procedura guidata sia la scelta più opportuna.
Grazie a questo articolo è possibile stabilire se sia necessario utilizzare la migrazione guidata come punto di partenza per la creazione dei cubi, oppure se sia preferibile progettare nuovamente questi ultimi.
Aspetti della progettazione dei cubi che influiscono sulla migrazione
I cubi di Analysis Services 2005 sono molto diversi da quelli delle versioni precedenti del prodotto. Se si effettua la migrazione per mezzo della procedura guidata, Analysis Services tenta di duplicare i cubi esistenti nel nuovo ambiente. Sebbene ciò consenta di passare rapidamente alla nuova piattaforma, non è possibile sfruttare tutte le nuove funzioni di progettazione di Analysis Services 2005.
Analysis Services 2005 introduce il modello dimensionale unificato (UDM, Unified Dimensional Model). Il ruolo del modello UDM è unire in modo completo i mondi del reporting OLAP e del reporting relazionale. Per tradizione, gli ambienti OLAP offrono percorsi di navigazione eccellenti per ottenere dati più o meno dettagliati. I dati sono memorizzati in livelli. Il reporting relazionale è ideale per la generazione di report nei quali un campo può essere posizionato in un punto qualsiasi.
OLAP presenta problemi quando gli utenti desiderano utilizzare campi che non possono essere inseriti nelle gerarchie definite dall'amministratore del cubo. Come è possibile includere nell'analisi i campi che non possono essere inseriti in una gerarchia naturale? Per risolvere questo problema, un'organizzazione potrebbe adottare due approcci diversi, ad esempio utilizzando sia uno strumento OLAP sia uno relazionale.
Il modello UDM risolve completamente il problema del reporting analitico e relazionale, poiché permette di trattare tutti i campi ritenuti necessari come attributi di prima classe. Il modello UDM garantisce una flessibilità prima non disponibile. Esso consiste di vari componenti ad alto livello che consentono una progettazione flessibile. Le funzioni offerte sono indicate di seguito.
| • | Gerarchie degli attributi e gerarchie definite dall'utente |
| • | Attributi correlati |
| • | Viste delle origini dati |
| • | Gruppi di misure |
| • | Prospettive |
Le sezioni seguenti mostrano come ogni funzione influisca sulla progettazione dei cubi in Analysis Services 2005 e permettono di determinare il percorso di migrazione più opportuno.
Gerarchie degli attributi
Analysis Services 2005 consente di creare attributi in base a qualsiasi campo si desideri includere nell'analisi. Questi attributi possono essere successivamente impiegati per l'analisi o il report relazionale. Inoltre, è possibile organizzare gli attributi in gerarchie per realizzare un percorso di navigazione. Dal punto di vista della navigazione, le gerarchie degli attributi e quelle definite dall'utente sostituiscono le dimensioni di Analysis Services 2000. Ne consegue che i cubi potranno presentare numerose gerarchie degli attributi. Infatti, i cubi complessi di grandi dimensioni potrebbero contenere centinaia di attributi. In Analysis Services 2000 spesso era preferibile utilizzare insiemi limitati di dimensioni. Ciò era dovuto a due motivi:
| • | Utilizzare la memoria in modo efficace. Tutte le dimensioni che per impostazione predefinita facevano riferimento all'archiviazione MOLAP e tutti i membri erano caricati nella memoria. Un numero limitato di dimensioni condivise ammesse consentiva un'elaborazione rapida e tempi di risposta rapidi alle query. |
| • | Aggiungere contesto per l'utente. Per gli utenti è difficile concettualizzare più di sei o otto dimensioni e mantenere il contesto durante l'utilizzo dei dati. Il modello UDM introduce una modifica sostanziale. Ogni campo che si desidera visualizzare nell'analisi può essere, e nella maggior parte dei casi è, aggiunto al cubo come attributo. In questo modo è possibile utilizzare più attributi e inserirli nelle gerarchie definite dall'utente. Queste ultime possono essere di tipo tradizionale oppure forte, in cui molti figli eseguono il rollup verso un singolo elemento padre. In alternativa, possono essere gerarchie di navigazione in cui gli attributi possono essere posizionati in percorsi differenti indipendentemente dalla cardinalità tra gli elementi padre e figlio. Questo metodo di progettazione offre i seguenti vantaggi: |
| • | Ogni campo può essere posizionato in qualsiasi punto del report o della vista dei dati. È possibile posizionare facilmente un singolo campo all'interno di righe e colonne, indipendentemente dagli altri campi della gerarchia. |
| • | I cubi rappresentano in modo più adeguato il data warehouse o l'archivio dei dati. In Analysis Services 2005, il cubo può contenere numerosi attributi, gerarchie definite dall'utente e misure (provenienti da tabelle dei fatti). Ciò fa sì che il cubo rappresenti in modo più realistico i dati di origine. |
| • | I cubi possono contenere dati provenienti da più tabelle delle dimensioni e dei fatti. I tipi di progetto che si possono ottenere sono virtualmente illimitati. |
| • | È possibile definire percorsi di navigazione per tutti i tipi di dati. Non vi è più alcuna limitazione al tipo di gerarchie che è possibile creare. |
| • | Le proprietà dei membri e le dimensioni virtuali non sono più necessarie per la creazione di report. Per aggiungere colonne ai report, gli amministratori dei cubi di Analysis Services 2000 erano spesso costretti ad aggiungere proprietà dei membri e, quindi, dimensioni virtuali. Ciò non è più necessario, poiché gli attributi costituiscono la base per le attività di analisi e reporting e, nella maggior parte dei casi, rappresentano una singola colonna. |
Attributi correlati
Analysis Services 2005 amplia il concetto tradizionale di proprietà dei membri, poiché queste ultime sono ora disponibili come relazioni tra attributi. Quando si esegue una query delle proprietà di un membro, non vengono visualizzate solo le proprietà tradizionali, bensì tutte le relazioni tra attributi. Le relazioni tra attributi vengono utilizzate dalla procedura di aggregazione guidata per determinare quali aggregazioni sia possibile effettuare. Per questo motivo, è necessario che le relazioni tra vari attributi siano organizzate in livelli. Ad esempio, una normale gerarchia riferita ai clienti può comprendere livelli quali Paese, Stato, Città e Cliente. Per trarre vantaggio dalle aggregazioni, è necessario che esista una relazione tra attributi tra Città e Stato. Anche la procedura guidata Formula utilizza le relazioni tra attributi per determinare il meccanismo più adatto per l'esecuzione dei calcoli.
Le proprietà dei membri erano spesso impiegate per agevolare il reporting in Analysis Services 2000. Per visualizzare una colonna non appartenente alla gerarchia, era possibile utilizzare una proprietà del membro per visualizzare il valore della colonna. La proprietà del membro poteva essere visualizzata come membro calcolato, dimensione virtuale o mediante uno strumento di terze parti che la esponeva senza necessità di modifiche. Con il modello UDM non è più necessario creare le proprietà dei membri per il reporting, poiché è possibile aggiungere tutte le colonne desiderate come attributi. Gli attributi possono quindi essere posizionati all'interno di righe e colonne per soddisfare qualsiasi necessità relativa all'analisi.
Nota: Analysis Services 2005 utilizza le relazioni tra attributi per determinare quali siano i calcoli necessari per eseguire il rollup nelle gerarchie definite dall'utente. In assenza delle relazioni tra attributi nelle gerarchie, le aggregazioni non vengono create. Nelle gerarchie forti, il livello padre degli elementi figli è una relazione tra attributi. Il processo di aggregazione per le gerarchie tra attributi dipende da questa relazione. |
Viste delle origini dati
Analysis Services 2005 offre un ulteriore livello di astrazione tra i cubi e le origini dati. La vista delle origini dati permette di separare logicamente un cubo dalle relative origini dati. È possibile combinare una o più origini dati in una vista per fornire una rappresentazione logica dei dati. La vista dell'origine dati può essere costituita da tabelle selezionate nell'ambito delle origini dati, oppure da una query denominata. La query denominata è un'istruzione SQL che consente di caricare i dati nel modo desiderato (non in modo diverso dalla vista relazionale, a eccezione del fatto che la query denominata è memorizzata nella DSV). Il cubo viene quindi creato a partire dalla vista dell'origine dati.
Le viste delle origini dati:
| • | Forniscono un livello di astrazione dalle origini dati. |
| • | Possono includere più origini dati. Tali origini possono essere costituite da più database residenti nello stesso server o in server diversi. |
| • | Forniscono query denominate che consentono di scrivere la query utilizzata da Analysis Services per caricare i dati. Questa caratteristica può essere utilizzata per filtrare, limitare oppure ottimizzare il caricamento dei dati dall'origine. |
| • | Possono essere utilizzate per rinominare i dati e fornire un livello di denominazione diverso dall'origine dati effettiva. |
| • | Permettono la rappresentazione di chiavi logiche per definire la relazione tra le tabelle dei fatti e quelle delle dimensioni. |
| • | Supportano i calcoli denominati. Ogni calcolo denominato contiene un'espressione, utilizzata per creare la definizione delle colonne. |
| • | Costituiscono la base per la creazione del cubo. |
Gruppi di misure
Uno dei principali aspetti da considerare in relazione ai cubi nuovi è il contesto nel quale l'utente visualizza i dati. È possibile creare un cubo a partire da più tabelle dei fatti. Ognuna di queste tabelle può presentare più misure e livelli di granularità differenti. Per questo motivo, al cubo corrisponderanno centinaia di attributi, oltre a misure provenienti da tabelle dei fatti diverse e con vari livelli di granularità.
Ad esempio, si consideri un cubo che presenta il gruppo di misure Vendite effettive dettagliato in termini di Prodotto, Negozio, Cliente, Giorno (chi ha comprato cosa, dove e quando?). Il cubo presenta anche il gruppo di misure Previsioni dettagliato in termini di Classe di prodotto, Negozio e Mese (cosa sarà venduto e dove nei mesi futuri?). Inoltre, è presente anche il gruppo di misure Inventario dettagliato in termini di Prodotto, Negozio e Settimana (quali prodotti sono stati disponibili, in quale negozio e quando?). Combinando questi tre gruppi di misure nello stesso cubo, è possibile ricavare informazioni sulle tendenze. Ad esempio, la mancata disponibilità di prodotti ha influito sulle vendite e come questa circostanza influisce sulle proiezioni future? Ciò è possibile perché tutti i fatti possono essere combinati nello stesso cubo. In Analysis Services 2000 era necessario creare due cubi e combinarli in un cubo virtuale. In Analysis Services 2005, invece, un solo cubo contiene più gruppi di misure (uno per ogni tabella dei fatti).
Sebbene questa caratteristica assicuri un'elevata flessibilità a coloro che creano i cubi, non sempre fornisce all'utente finale il contesto necessario. La maggior parte degli utenti finali non hanno dimestichezza con la progettazione di data warehouse o archivi di dati. È possibile creare gruppi di misure per separare misure diverse e fornire il contesto all'utente finale. Le misure con livelli di granularità simili possono essere raggruppate e trattate (dal punto di vista amministrativo) come una singola unità. Per impostazione predefinita, i gruppi di misure sono organizzati in base alla tabella dei fatti da cui vengono ricavati. Le misure provenienti da un'unica tabella dei fatti presentano un livello di granularità simile. Tutte le misure all'interno della stessa tabella dei fatti appartengono allo stesso gruppo di misure. I gruppi di misure presentano i seguenti vantaggi:
| • | Le misure possono provenire da più tabelle dei fatti. |
| • | Le misure possono essere raggruppate in base alla granularità. |
| • | È possibile includere più livelli di granularità in un solo cubo di base. |
| • | È possibile applicare criteri di protezione a determinati gruppi di misure. |
| • | È possibile esporre i gruppi di misure attraverso una o più prospettive e raggrupparli con dimensioni significative per l'utente finale. I gruppi di misure consentono di fornire il contesto per l'utente finale. |
Prospettive
In Analysis Services 2000 la definizione dei cubi prevedeva un numero inferiore di dimensioni e una quantità prefissata di misure provenienti da una sola tabella dei fatti. Per aggiungere misure di granularità differenti o visualizzare più dimensioni appartenenti a cubi diversi, era possibile combinare vari cubi di base in un cubo virtuale che avesse l'aspetto di un'entità molto più grande. Ciò consentiva di ottenere il risultato finale. Oltre a risolvere i problemi legati alla granularità, questo metodo diminuiva la quantità di memoria utilizzata in Analysis Services 2000.
Il modello UDM ha modificato la situazione. Adesso i cubi possono presentare centinaia di attributi, gerarchie definite dall'utente e più gruppi di misure (provenienti da tabelle dei fatti diverse). Per questo motivo, la progettazione dei cubi è molto flessibile. Il solo problema non risolto riguarda il contesto dell'utente. A un certo momento, è necessario restringere le viste dei dati affinché siano comprensibili per l'utente finale. Lo scopo della vista dei dati è consentire all'utente di soddisfare i requisiti imposti dai propri progetti.
Le prospettive forniscono il contesto all'utente finale. Una prospettiva è un insieme di attributi, gerarchie definite dall'utente, azioni e gruppi di misure che si desidera raggruppare in una raccolta logica. La prospettiva costituisce l'elemento fondamentale delle analisi e fornisce il contesto all'utente. In futuro sarà normale avere cubi di grandi dimensioni con centinaia di attributi e molte misure. Ciò consentirà di creare numerose prospettive grazie alle quali gli utenti potranno interagire con raccolte di dati pertinenti all'attività svolta. Il modello UDM è destinato agli amministratori dei cubi, mentre le prospettive sono per gli utenti finali. Non è possibile utilizzare le prospettive per implementare la protezione.
Suggerimento: le prospettive sono esposte agli strumenti front-end in un modo simile a quello con cui i cubi erano presentati in Analysis Services 2000. Se gli utenti sono abituati a considerare insiemi di cubi collegati ed esplorabili, è possibile creare una situazione simile implementando prospettive che includano le stesse dimensioni e misure contenute nei cubi di Analysis Services 2000. Ad esempio, potrebbe esistere un cubo fisico Vendite con varie prospettive basate sui diversi impieghi di questo dato nell'ambito dell'azienda, ad esempio la prospettiva Brand Manager, Responsabile del negozio o Responsabile regionale. Ogni prospettiva in effetti è esposta all'utente come un cubo (come nel cubo di base, più grande e complesso), ma le dimensioni, i calcoli, i gruppi di misure e altre entità sono state adeguate esattamente a un determinati uso aziendale. |
Riepilogo dei problemi di progettazione
In Analysis Services 2005 i cubi possono presentare vari attributi, gerarchie definite dall'utente e misure. Il modello UDM unisce il meglio del mondo OLAP e del mondo del reporting relazionale per offrire opportunità illimitate nella progettazione dei cubi. Il risultato finale di questa attività può essere molto più esaustivo rispetto alle richieste dell'utente. È possibile utilizzare i gruppi di misure e le prospettive per fornire il contesto agli utenti. Nella maggior parte dei casi, la prospettiva costituisce l'elemento fondamentale dell'esperienza degli utenti.
Strumenti di migrazione
Analysis Services 2005 offre strumenti che agevolano il processo di migrazione. Quando si installa Analysis Services 2005 in un computer che utilizza già Analysis Services 2000 e si sceglie l'installazione predefinita, si viene invitati ad eseguire la migrazione guidata durante l'installazione stessa. Se si sceglie di non eseguire la procedura guidata durante l'installazione, è possibile utilizzarla successivamente come strumento autonomo.
La migrazione guidata permette di trasferire i cubi di Analysis Services 2000 nella nuova versione, oppure di creare uno script XMLA (XML for Analysis) per effettuare la migrazione in un momento successivo. Le procedure guidate sono rapide ed efficaci. In seguito, è necessario determinare se il risultato finale soddisfa le proprie esigenze. In alcuni casi, la migrazione guidata è un eccellente punto di inizio mentre in altri è preferibile effettuare nuovamente la progettazione. Anche se si prevede di progettare nuovamente i cubi, è comunque opportuno utilizzare la migrazione guidata. Nella peggiore delle ipotesi, si tratta di un'esperienza utile e formativa che consente di appurare come la procedura guidata converta gli oggetti. Alla fine si può decidere di non accogliere le raccomandazioni fornite e di progettare nuovamente lo schema mediante le normali procedure guidate per la progettazione, ma è comunque utile rendersi conto di come la migrazione guidata effettui questa attività.
Analysis Services 2005 comprende due strumenti incorporati per la migrazione. Il primo è rappresentato dall'opzione di migrazione durante l'installazione di Analysis Services 2005.
Il secondo è la migrazione guidata avviata come processo autonomo come uno degli strumenti principali nel gruppo di programmi di SQL Server 2005.
Migrazione guidata
La migrazione guidata duplica nel modo migliore possibile i cubi presenti in Analysis Services 2000. Lo scopo della procedura guidata non è fornire un cubo di Analysis Services 2005 conforme al modello consigliato. Tenendo presente questa considerazione, è facile comprendere la motivazione delle scelte compiute dalla procedura. Al termine dell'operazione, è necessario determinare le operazioni aggiuntive necessarie per sfruttare al meglio tutte le funzioni di Analysis Services 2005.
La procedura guidata chiede di scegliere i database OLAP di cui si intende eseguire la migrazione. Una volta effettuata la selezione, è necessario decidere se si desidera trasferirli direttamente ad Analysis Services 2005 oppure generare uno script XMLA. Questo script può essere eseguito in un momento successivo da SQL Server Management Studio.
Per eseguire la migrazione guidata
1. | Nel gruppo di programmi SQL Server 2005, attivare Migration Wizard (Migrazione guidata). La migrazione guidata è uno degli strumenti di Analysis Services. La procedura guidata appare come mostrato nella figura 1.  Figura 1. La migrazione guidata di Analysis Services 2005 consente di effettuare la migrazione dei cubi di Analysis Services 2000 | |
2. | Scegliere Next (Avanti) per visualizzare la sezione Source and Destination Page (Pagina di origine e destinazione) della procedura guidata. | |
3. | Indicare l'origine e la destinazione dei dati, come mostrato nella figura 2. L'origine dei dati deve corrispondere all'istanza di Analysis Services 2000. La destinazione deve corrispondere alla nuova istanza di Analysis Services 2005. È possibile selezionare un file di script anziché una destinazione. Ciò fa sì che la procedura guidata generi uno script XMLA che può essere eseguito in un momento successivo per generare i cubi.  Figura 2. L'origine e la destinazione costituiscono l'elemento fondamentale della migrazione | |
4. | Dopo avere indicato l'origine e la destinazione, scegliere Next (Avanti). La procedura guidata legge i metadati dall'origine dati, quindi visualizza la schermata Select Databases to Migrate (Selezione database di cui eseguire la migrazione). | |
5. | Selezionare i database di cui si intende eseguire la migrazione. Per impostazione predefinita, il nome del database di destinazione viene generato automaticamente. La procedura guidata tenta di creare un database con lo stesso nome. Se esso risulta già esistente, la procedura guidata genera un nome aggiungendo un valore numerico incrementale (partendo da 1) al nome del database. Per indicare un nome, fare clic nella cella Destination Database (Database di destinazione) e inserire il nome desiderato come mostrato nella figura 3.  Figura 3. Analysis Services 2005 consente di modificare il nome del database di destinazione, utilizzando quello desiderato | |
6. | Una volta indicati i nomi dei database di cui si intende eseguire la migrazione e dei database di destinazione, scegliere Next (Avanti). | |
7. | Viene avviata la sezione Validating Objects (Convalida oggetti) della procedura guidata. L'esecuzione di questa fase richiede alcuni minuti (in base alla quantità di metadati nelle origini dati). A mano a mano che gli oggetti vengono convalidati, la procedura guidata visualizza messaggi di avviso e di errore relativi ai dati che potrebbero presentare problemi. È possibile esaminare dettagliatamente le modifiche apportate ai dati dalla procedura guidata. Ad esempio, se una dimensione viene rinominata, si riceve un messaggio di avviso che segnala questa circostanza. In una sezione successiva di questo articolo verranno descritti brevemente alcuni potenziali problemi che potrebbero verificarsi durante l'uso della migrazione guidata. È possibile utilizzare le funzioni View Log (Visualizza log) e Save Log (Salva log), rispettivamente, per visualizzare e filtrare le informazioni e salvarle in un file per analizzarle in seguito. Una volta esaminate le informazioni sugli oggetti, scegliere Next (Avanti). | |
8. | Viene visualizzata la schermata Migrating Database (Migrazione database). La procedura guidata sta eseguendo la migrazione ed è in corso la generazione dei metadati. Tuttavia, i dati non vengono trasferiti. Infatti, è necessario elaborare i nuovi cubi per popolarli con i dati. | |
9. | Una volta effettuata la migrazione dei database, scegliere Next (Avanti) per terminare la procedura guidata.
|
La procedura guidata non effettua la migrazione dei seguenti elementi:
| • | Partizioni remote |
| • | Cubi collegati |
| • | Opzioni drill-through |
Durante la migrazione, la procedura guidata compie alcune scelte per eseguire il mapping tra le vecchie e le nuove funzioni. È necessario tenere in considerazione quanto segue:
| • | Le proprietà dei membri sono migrate nelle relazioni tra attributi. Si osservi che il termine relazione tra attributi è utilizzato principalmente in Business Intelligence Development Studio. Se si esegue una query sull'API per determinare le proprietà dei membri, la query restituisce relazioni tra attributi. Oltre all'insieme esistente di proprietà dei membri, a ciascun livello della gerarchia è associata un'ulteriore relazione tra attributi relativa al livello dell'elemento padre. La relazione tra attributi è utilizzata dal motore di aggregazione per fornire le relazioni tra i punti dati. Queste relazioni sono necessarie per i calcoli del rollup. Non è consentito rimuovere questi attributi correlati. Se sono state aggiunte altre proprietà dei membri per soddisfare particolari esigenze di reporting, è possibile rimuovere gli attributi correlati al report poiché le colonne sono definite anche come dimensioni degli attributi. |
| • | Alcuni calcoli denominati possono essere creati automaticamente nella vista origine dati. Questi calcoli memorizzano l'espressione utilizzata per creare la colonna. Le colonne create in ogni tabella vengono denominate columnx (colonnax), partendo da column1 (colonna1). Ciò si verifica quando il nome o l'ID di un membro di un determinato livello è basato su un espressione di Analysis Services 2000. In Analysis Services 2000 le caselle delle proprietà relative al nome e all'ID del membro consentivano di utilizzare istruzioni di tipo SQL per gestire problemi quali la concatenazione. Esse ora sono memorizzate come espressioni. Ad esempio, la dimensione Customers (Clienti) del cubo Foodmart costituisce un esempio di questo comportamento. Durante la migrazione, nella tabella Customers (Clienti) si noterà che è presente una nuova colonna (nella vista origine dati e, inoltre, aggiunta come attributo), denominata Column1. Esaminando le proprietà, si osserva che l'origine corrisponde al risultato della concatenazione delle colonne First Name (Nome) e Last Name (Cognome). |
| • | Quasi tutte le colonne provenienti dalle tabelle delle origini dati vengono aggiunte come dimensioni degli attributi. Analysis Services esclude le colonne contenenti tipi di dati non ritenuti interessanti, tra i quali timestamp, uniqueidentifier e table. Tutte le colonne contenenti valori numerici, date e caratteri sono attributi aggiunti. |
| • | I cubi virtuali vengono migrati come cubi. I gruppi di misura non vengono aggiunti ai cubi. Essi vengono migrati come gruppi di misura collegati che puntano al cubo di base. Per ogni cubo di base referenziato dal cubo virtuale originale è presente un cubo di misure collegato che punta alla base. |
| • | Le dimensioni virtuali sono soggette alle stesse regole imposte alle dimensioni unite. Le dimensioni virtuali erano basate sulle proprietà dei membri e potevano contenere uno o più livelli. Se la dimensione presentava un solo livello, essa veniva unita alla dimensione sulla quale era basata. Se la dimensione virtuale presentava più livelli, essa veniva convertita in una dimensione reale. Ad esempio, nel database Foodmart vi sono tre dimensioni virtuali. Per illustrare questo concetto, verranno cercati gli elementi Position (Posizione), che presenta più livelli e Store Size in Sq Ft, che presenta un solo livello. Durante la migrazione, Position (Posizione) viene creato come nuova dimensione. Store Size in Sq ft viene unito nella dimensione del negozio. Square Feet viene aggiunto come attributo alla dimensione. |
| • | Per ogni azione si riceve un messaggio che segnala che essa verrà migrata come comando. Nell'interfaccia utente di Analysis Services 2005 si nota che si fa ancora riferimento a questi elementi come azioni. |
| • | Le viste delle origini dati vengono create automaticamente e danno origine a query denominate per rappresentare un insieme di colonne appartenenti a una tabella. La vista dell'origine dati che viene creata contiene tutte le tabelle dei fatti e delle dimensioni utilizzate nel database OLAP di Analysis Services 2000. |
| • | Viene effettuata la migrazione delle partizioni, sebbene gli script utilizzati per crearle automaticamente vengono migrati all'interno di script XMLA. Le partizioni impiegano un'associazione di query utilizzando la stessa istruzione SQL generata da Analysis Services 2000 per elaborare la partizione. |
| • | I ruoli vengono migrati insieme alla protezione dei cubi e delle dimensioni. Analysis Services 2005 consente di implementare più tipi di protezione. Qualora si desideri implementare una delle nuove opzioni per la protezione, è necessario farlo dopo la migrazione. |
| • | Le dimensioni di gerarchie multiple vengono migrate, ma non sempre viene loro assegnato il nome desiderato. Ad esempio, le dimensioni Time.Fiscal e Time.Calendar di Analysis Services 2000 verranno probabilmente migrate come Time e Time 1. Qualora la gerarchia denominata Time sia già presente, la procedura esegue la migrazione in Time TimeDim e TimeDim 1. Ciò può generare confusione. Sebbene il risultato ottenuto possa essere diverso da quello desiderato, rinominare le dimensioni è un'operazione molto semplice. |
Al termine della migrazione guidata, potrebbe essere necessario passare a Business Intelligence Development Studio per esaminare i risultati e apportare le modifiche eventualmente necessarie. Le attività da eseguire dopo la migrazione comprendono:
| • | Rinominare le dimensioni, affinché siano conformi alle convenzioni utilizzate in materia di nomi. |
| • | Determinare se tutte le gerarchie definite dall'utente si trovano nelle dimensioni corrette. In alcuni casi, la procedura di migrazione guidata crea più dimensioni di quelle necessarie. Potrebbe essere possibile consolidare alcune gerarchie definite dall'utente ed eliminare le dimensioni aggiuntive. Questa operazione consente di assicurarsi che i nomi delle dimensioni nuove non influiscano sulle query MDX esistenti e ne impediscano il funzionamento. |
| • | Assegnare il nome ai calcoli denominati. Columnx è il nome applicato a tutti i calcoli denominati aggiunti alla vista dell'origine dati. È consigliabile assegnare nomi pertinenti alla colonna. |
| • | Configurare le impostazioni drill-through come azioni drill-through. Il drill-through ora viene eseguito come un'azione ed è necessario configurarlo. |
Per rinominare una dimensione in Business Intelligence Development Studio, procedere come descritto di seguito.
Per visualizzare il nuovo cubo e rinominare una dimensione
1. | Nel gruppo di programmi SQL Server 2005, aprire Business Intelligence Development Studio. |
2. | All'avvio dello strumento, si accede alla pagina iniziale di Visual Studio. |
3. | Per aprire il cubo, scegliere Apri dal menu File. Scegliere Database di Analysis Services, come mostrato nella figura 4.  Figura 4. Da Business Intelligence Development Studio è possibile aprire un database di Analysis Services esistente |
1. | È possibile scegliere l'opzione Create a Database (Crea un database) oppure Open an Existing Database (Apri un database esistente). Scegliere Open an Existing Database (Apri un database esistente) e fornire le informazioni relative all'istanza e al database. |
2. | In Solution Explorer (Esplora soluzioni) vengono visualizzati il database e l'elenco dei cubi e delle dimensioni generati. |
3. | Per rinominare una dimensione, fare clic con il pulsante destro del mouse e scegliere Rename (Rinomina). Digitare il nuovo nome, come mostrato nella figura 5.  Figura 5. In Analysis Services 2005, rinominare gli oggetti è un'operazione semplice |
La migrazione guidata non implementa alcune funzioni, poiché a esse non trovano corrispondenza in Analysis Services 2000. Per accedere a queste funzioni è necessario servirsi delle schede e delle caselle relative alle proprietà contenute negli strumenti di amministrazione di Analysis Services. Tra le funzioni di alto livello non implementate vi sono:
| • | KPI (Key Performance Indicator) |
| • | Conversioni |
| • | Dimensioni molti a molti |
| • | Dimensioni basate su giochi di ruolo |
| • | Misure semiaddittive |
Migrazione in Project REAL
I database OLAP e i cubi utilizzati in Project REAL sono stati riprogettati. Come base per la progettazione dei cubi sono state utilizzate le procedure guidate di Analysis Services 2005. Come processo collaterale, la migrazione guidata è stata utilizzata su un insieme di dati campione forniti da Barnes and Noble Booksellers per confrontare i risultati ottenuti. Tutte le dimensioni condivise utilizzate per i dati e molte dimensioni condivise erano dimensioni virtuali. Una volta eseguita la migrazione guidata, sono state effettuate le seguenti osservazioni:
| • | Ogni dimensione virtuale era basata sulle proprietà dei membri proveniente da una tabella elementi. Durante la migrazione, ciascuna dimensione è stata unita (o rinominata) nella dimensione dell'elemento. Tutte le dimensioni virtuali sono state aggiunte alla dimensione dell'elemento come gerarchia definita dall'utente. Esse sono state rese visibili per impostazione predefinita ed è stato possibile effettuare gli stessi riferimenti presenti prima della migrazione. Ciò aumenta la possibilità che le query precedenti continuino a funzionare semplicemente utilizzando il nuovo provider. |
| • | È stata creata una singola origine dati partendo da quella utilizzata in Analysis Services 2000. La vista dell'origine dati rappresentava tutte le tabelle impiegate dall'origine dati esistente. |
| • | È stata effettuata la migrazione dell'unico cubo esistente in un cubo di Analysis Services 2005. Tutti i cubi di base sono stati migrati come gruppi di misure separati, rispettivamente per Store Sales (Vendite negozio), Store Inventory (Inventario negozio) e Distribution Center Inventory (Inventario del centro di distribuzione). |
| • | La migrazione di tutte le informazioni relative alla protezione, compresi ruoli e protezione dei dati, è stata effettuata correttamente. |
| • | A eccezione della dimensione Time, che è stata rinominata in Time.Fiscal e Time.Calendar (come descritto in precedenza nella sezione relativa alle gerarchie multiple), non si sono verificati conflitti tra i nomi delle dimensioni. Per questo motivo, in Analysis Services 2005 esse hanno mantenuto i nomi che avevano in Analysis Services 2000. |
| • | Nel complesso, il processo è risultato rapido e privo di problemi e ha creato correttamente in Analysis Services 2005 gli stessi cubi presenti in Analysis Services 2000. |
| • | Nei dati relativi all'inventario sono state utilizzate misure semiadditive per impostare LastNonEmptyChild per tutte le misure riferite alle quantità disponibili e a quelle ordinate. Poiché questa è una nuova funzionalità di Analysis Services 2005, sono stati rimossi i calcoli complessi utilizzati per i rollup semiadditivi. |
Scelta tra migrazione e riprogettazione
La migrazione guidata consente di esaminare in modo sufficientemente approfondito i dati nei cubi di Analysis Services 2005. Tuttavia, è opportuno notare che i cubi creati con la migrazione guidata costituiscono una replica di quelli presenti in Analysis Services 2000 e che essi potrebbero non corrispondere al risultato desiderato. Talvolta sarà sufficiente utilizzare la procedura guidata per effettuare la migrazione e, quindi, aggiungere le funzioni desiderate. In altri casi, sarà preferibile progettare nuovamente i cubi nella nuova architettura. Le domande seguenti consentono di determinare se la migrazione guidata sia un punto di partenza adeguato alle proprie esigenze o se non sia più opportuno effettuare una nuova progettazione.
| • | Sono presenti numerosi cubi piccoli che presentano dimensioni e misure limitate? Gli amministratori dei cubi in Analysis Services 2000 normalmente creavano molti cubi piccoli. Utilizzando la procedura guidata di Analysis Services 2005, viene effettuata la migrazione di ognuno di questi cubi in cubi singoli. Poiché Analysis Services 2005 non pone limitazioni relative a utilizzo della memoria, misure di tabelle dei fatti singole, conteggi distinti e proprietà dei membri, potrebbe essere preferibile non utilizzare numerosi cubi di piccole dimensioni. Infatti, i dati potrebbero essere più significativi se fossero contenuti in pochi cubi di grandi dimensioni in cui le prospettive forniscono il contesto per l'utente. Se si sono utilizzati molti cubi per fornire il contesto, potrebbe essere consigliabile riprogettare i cubi in Analysis Services 2005. |
| • | Sono state aggiunte numerose proprietà alle dimensioni per le attività di reporting? Ora è possibile aggiungere le colonne come dimensioni degli attributi per migliorare il layout dei report e agevolare la navigazione. Non è necessario che tutte le proprietà dei membri siano attributi correlati. Ciò potrebbe implicare un notevole carico di attività di pulitura manuale dopo la migrazione e, quindi, è preferibile riprogettare i cubi. |
| • | Le dimensioni private sono state utilizzate in molti cubi? Le dimensioni private vengono migrate come dimensioni. Se si sono utilizzate numerose dimensioni private e lo stesso tipo di dimensioni per cubi diversi, si noterà che il sistema duplica queste dimensioni in Analysis Services 2005. Ciò rende necessario eliminare i nomi delle dimensioni e modificare i cubi. In questo caso, probabilmente è preferibile effettuare nuovamente la progettazione. |
| • | Vi sono numerosi membri calcolati che non sono ammessi come misure? Le misure ora presentano ulteriori funzioni aggregate. L'elenco delle funzioni aggregate si è ampliato rispetto a quello originale, costituito da Sum (Somma), Count (Conteggio), Distinct Count (Conteggio distinto), Min e Max, per includere Average of Children (Media degli elementi figli), None (Nessuno), First Child (Primo elemento figlio), Last Child (Ultimo elemento figlio), First Non Empty Child (Primo elemento figlio non vuoto) e Last Non Empty Child (Ultimo elemento figlio non vuoto). Se sono stati creati membri calcolati che possono essere utilizzati come misure, potrebbe essere opportuno effettuare nuovamente la progettazione o, almeno, valutare il carico di attività richiesto per la pulizia dopo la migrazione. |
| • | Sono state apportate modifiche significative al processo ETL, oppure sono state create viste nel database relazionale per ottenere un'unica origine dati per il cubo? Qualora si desideri che i dati provengano in modo lineare da più origini, probabilmente è preferibile riprogettare i cubi e creare le query denominate nelle viste delle origini dati per caricare i dati stessi. |
| • | È stato necessario trovare soluzioni alternative ai conteggi distinti? In Analysis Services 2000 i conteggi distinti richiedevano particolare attenzione. Essi erano limitati a uno per cubo ed era consigliabile che il conteggio distinto si trovasse nel proprio cubo e fosse combinato con altre misure in un cubo virtuale. Questa limitazione non esiste più e le soluzioni alternative da attuare potrebbero non essere soddisfacenti. |
| • | Si utilizzano numerosi cubi e dimensioni virtuali? Essi verranno trasformati in dimensioni e cubi attuali. Nel caso delle dimensioni virtuali, questo non è probabilmente il risultato desiderato, poiché la colonna può essere creata facilmente come dimensione dell'attributo. Nel caso dei cubi virtuali, a causa della duplicazione dei dati sarà probabilmente necessario effettuare una pulizia del cubo virtuale e del cubo di base. Se la pulizia si prospetta impegnativa, probabilmente è preferibile progettare nuovamente il cubo. |
| • | Il progetto dei cubi è adeguato alla proprie esigenze, ma si desidera utilizzare le nuove funzioni di Analysis Services 2005? Se si è soddisfatti dei cubi esistenti e si ritiene che siano compatibili con i nuovi requisiti di progettazione di Analysis Services 2005, è opportuno utilizzare la migrazione guidata per portare i dati nella nuova versione. In seguito a questa operazione, è possibile aggiungere le nuove funzionalità desiderate. Per un elenco completo delle nuove funzioni, consultare la documentazione di prodotto. |
Conclusioni
Grazie al nuovo modello UDN (Unified Dimensional Model), il ponte che unisce il reporting relazionale al reporting OLAP è stato completato. Le nuove opzioni di progettazione disponibili in Analysis Services 2005 ampliano infinitamente le possibilità di utilizzare la progettazione e migliorano in modo significativo l'esperienza dell'utente finale riferita all'analisi e al reporting. La migrazione guidata costituisce uno strumento eccellente che consente agli utenti di iniziare a utilizzare l'applicazione. Grazie alla migrazione guidata è possibile eseguire facilmente il porting dei database OLAP nella nuova versione e iniziare a sfruttare le nuove funzioni. La migrazione guidata tenta di ricreare i cubi esistenti in Analysis Services 2005 e, al termine, si può eventualmente decidere che le modifiche alla progettazione sono talmente significative che si preferisce iniziare da zero anziché utilizzare la migrazione guidata. La decisione tra una nuova progettazione e la procedura automatica viene effettuata valutando ciò che è disponibile in un determinato momento e l'entità delle modifiche desiderate in Analysis Services 2005.
Per ulteriori informazioni, vedere
http://www.microsoft.com/sql/