Panoramica dell'architettura logica (Analysis Services - Dati multidimensionali)

Si applica a: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

Analysis Services viene eseguito in una modalità di distribuzione server che determina l'architettura di memoria e l'ambiente di runtime utilizzati dai diversi tipi di modelli di Analysis Services. La modalità server viene determinata durante l'installazione. La modalità di data mining e multidimensionale supporta il data mining OLAP e tradizionale. La modalità tabulare supporta i modelli tabulari . La modalità integrata di SharePoint fa riferimento a un'istanza di Analysis Services installata come Power Pivot per SharePoint, utilizzata per il caricamento e l'esecuzione di query su modelli di dati Excel o PowerPivot all'interno di una cartella di lavoro.

In questo argomento viene illustrata l'architettura di base di Analysis Services quando viene utilizzato nella modalità multidimensionale e di data mining. Per altre informazioni su altre modalità, vedere Modellazione tabularee confronto di soluzioni tabulari e multidimensionali.

Architettura di base

Un'istanza di SQL Server Analysis Services può contenere più database e un database può avere oggetti OLAP e oggetti di data mining contemporaneamente. Le applicazioni si connettono a un'istanza specificata di SQL Server Analysis Services e a un database specificato. Un computer server può ospitare più istanze di SQL Server Analysis Services. Le istanze di SQL Server Analysis Services sono denominate "<ServerName\<InstanceName>>". La figura seguente mostra tutte le relazioni menzionate tra oggetti SQL Server Analysis Services.

Le classi di base rappresentano il set di oggetti minimo richiesto per la compilazione di un cubo. Tale set di oggetti minimo è costituito da una dimensione, un gruppo di misure e una partizione. L'utilizzo di un'aggregazione è facoltativo.

Le dimensioni vengono compilate da attributi e gerarchie. Queste ultime sono formate da un set ordinato di attributi, dove ogni attributo del set corrisponde a un livello nella gerarchia.

I cubi sono compilati da dimensioni e gruppi di misure. Le dimensioni nella raccolta di dimensioni di un cubo appartengono alla raccolta di dimensioni del database. I gruppi di misure sono raccolte di misure che hanno la stessa vista origine dati e lo stesso subset di dimensioni del cubo. Un gruppo di misure dispone di una o più partizioni per la gestione dei dati fisici. Un gruppo di misure può avere una progettazione delle aggregazioni predefinita, la quale può essere utilizzata da tutte le partizioni nel gruppo di misure. Ogni partizione può inoltre disporre di una progettazione delle aggregazioni specifica.

Oggetti Server
Ogni istanza di SQL Server Analysis Services viene vista come un oggetto server diverso in AMO. Ogni istanza diversa è connessa a un Server oggetto da una connessione diversa. In ogni oggetto server sono contenuti una o più origini dati, viste origine dati e oggetti di database, nonché assembly e ruoli di sicurezza.

Oggetti Dimension
Ogni oggetto di database contiene più oggetti dimensione, ciascuno dei quali contiene uno o più attributi organizzati in gerarchie.

Oggetti cubo
Ogni oggetto di database contiene uno o più oggetti cubo. Un cubo è definito dalle relative misure e dimensioni. Le misure e le dimensioni di un cubo derivano dalle tabelle e dalle viste della vista origine dati su cui il cubo si basa o che viene generata dalle definizioni delle misure e delle dimensioni.

Ereditarietà degli oggetti

Il modello a oggetti ASSL contiene molti gruppi di elementi ripetuti. Ad esempio, il gruppo di elementi "Dimensioni contengono gerarchie", definisce la gerarchia delle dimensioni di un elemento. Sia i cubi che i MeasureGroup contengono il gruppo di elementi "Dimensioni contengono gerarchie".

Se non viene sottoposto a override in modo esplicito, un elemento eredita i dettagli di tali gruppi di elementi ripetuti dal livello più elevato. Ad esempio, le traduzioni per un CubeDimension sono uguali a quella dell'elemento Translations per il relativo elemento predecessore, Cube.

Per eseguire in modo esplicito l'override delle proprietà ereditate da un oggetto di livello superiore, non è necessario che un oggetto ripeta in modo esplicito l'intera struttura e le proprietà dell'oggetto di livello superiore. Un oggetto deve dichiarare in modo esplicito solo le proprietà di cui desidera eseguire l'override. Ad esempio, un CubeDimension può elencare solo le gerarchie che devono essere disabilitate nel cubo o per cui la visibilità deve essere modificata o per cui alcuni dettagli di livello non sono stati forniti a livello di dimensione .

Alcune proprietà specificate per un oggetto forniscono i valori predefiniti per la stessa proprietà in un oggetto figlio o discendente. Ad esempio, Cube.StorageMode fornisce il valore predefinito per Partition.StorageMode. Per i valori predefiniti ereditati, in ASSL vengono applicate le regole per i valori predefiniti ereditati:

• Quando la proprietà per l'oggetto figlio è Null in XML, il valore ereditato viene utilizzato per impostazione predefinita. Se tuttavia si esegue una query relativa al valore nel server, viene restituito il valore Null dell'elemento XML.

• Non è possibile determinare a livello di programmazione se la proprietà di un oggetto figlio è stata impostata direttamente su tale oggetto oppure se è stata ereditata.

Esempio

Il cubo Imports contiene due misure, Packages e Last, e tre dimensioni correlate, Route, Source e Time.

I valori alfanumerici più piccoli disposti intorno al cubo rappresentano i membri delle dimensioni. Ad esempio, ground, Africa e 1st quarter sono rispettivamente membri delle dimensioni Route, Source e Time.

Misure

I valori all'interno delle celle del cubo rappresentano le due misure Packages e Last. La misura Pacchetti rappresenta il numero di pacchetti importati e la funzione Sum viene usata per aggregare i fatti. La misura Last rappresenta la data di ricezione e la funzione Max viene usata per aggregare i fatti.

Dimensioni

La dimensione Route rappresenta il mezzo di trasporto mediante il quale i beni importati giungono a destinazione. I membri di questa dimensione includono ground, nonground, air, sea, road e rail. La dimensione Source rappresenta le località in cui vengono prodotti i beni importati, ad esempio Africa o Asia. La dimensione Time rappresenta i trimestri e i semestri di un singolo anno.

Aggregazioni

Gli utenti aziendali di un cubo possono determinare il valore di qualsiasi misura per ogni membro di ogni dimensione, indipendentemente dal livello del membro all'interno della dimensione, perché SQL Server Analysis Services aggrega i valori a livelli superiori in base alle esigenze. Ad esempio, i valori delle misure nella figura precedente possono essere aggregati in base a una gerarchia di calendario standard usando la gerarchia tempo calendario nella dimensione Time come illustrato nel diagramma seguente.

Oltre che in base a un'unica dimensione, le misure possono essere aggregate utilizzando combinazioni di membri di dimensioni diverse. Ciò consente agli utenti aziendali di valutare le misure di più dimensioni contemporaneamente. Se, ad esempio, un utente aziendale desidera analizzare ogni trimestre le importazioni giunte per via aerea dagli emisferi orientale e occidentale, potrà eseguire una query sul cubo per recuperare il set di dati seguente.

Pacchetti | Intervallo di tempo | Tutte le origini | Emisfero orientale | Emisfero occidentale | | ---------- | ----------- | ------------------ | ------------------ |
|All Time|25110|6547|18563|
|1° metà|11173|2977|8196|
|1° trimestre|5108|1452|3656|
|2° trimestre|6065|1525|4540|Jun-28-99|Jun-20-99|Jun-28-99|
|2nd Half|13937|3570|10367|29-99 dicembre|Dec-22-99|29-99 dicembre|
|3° trimestre|6119|1444|4675|Sep-30-99|Sep-18-99|Sep-30-99|
|4° trimestre|7818|2126|5692|29-99 dicembre|Dec-22-99|29-99 dicembre|

Ultimo | Intervallo di tempo | Tutte le origini | Emisfero orientale | Emisfero occidentale | | ---------- | ----------- | ------------------ | ------------------ | |Tutto il tempo |29-99 dicembre|Dec-22-99|29-99 dicembre|
|1° metà|Jun-28-99|Jun-20-99|Jun-28-99|
|1° trimestre|Mar-30-99|Mar-19-99|Mar-30-99|
|2° trimestre|Jun-28-99|Jun-20-99|Jun-28-99|
|2° metà|29-99 dicembre|Dec-22-99|29-99 dicembre|
|3° trimestre|Sep-30-99|Sep-18-99|Sep-30-99|
|4° trimestre|29-99 dicembre|Dec-22-99|29-99 dicembre|

Dopo avere definito un cubo, è possibile creare nuove aggregazioni o modificare quelle esistenti in modo da impostare le opzioni per determinare, ad esempio, se le aggregazioni devono essere precalcolate durante la fase di elaborazione o calcolate durante l'esecuzione della query. Argomento correlato:Aggregazioni e progettazione aggregazioni.

Mapping di misure, attributi e gerarchie

Le misure, gli attributi e le gerarchie del cubo di esempio derivano dalle colonne seguenti nelle tabelle dei fatti e delle dimensioni del cubo.

I dati di una singola cella del cubo in genere derivano da più righe della tabella dei fatti. Ad esempio, la cella del cubo all'intersezione del membro air, il membro Africa e il membro del 1° trimestre contiene un valore derivato dall'aggregazione delle righe seguenti nella tabella dei fatti ImportFactTable .

Nella tabella precedente ogni riga ha gli stessi valori per le colonne RouteKey, SourceKey e TimeKey , che indicano che queste righe contribuiscono alla stessa cella del cubo.

Nell'esempio illustrato di seguito viene rappresentato un cubo molto semplice, in quanto contiene un solo gruppo di misure, e tutte le tabelle delle dimensioni vengono unite in join alla tabella dei fatti in uno schema star. Un altro schema comune è quello snowflake, in cui una o più tabelle delle dimensioni sono unite in join a un'altra tabella delle dimensioni, anziché direttamente alla tabella dei fatti. Argomento correlato:Dimensioni (Analysis Services - Dati multidimensionali).

Nell'esempio illustrato di seguito viene utilizzata una sola tabella dei fatti. Quando un cubo utilizza più tabelle dei fatti, le misure di ogni tabella dei fatti vengono organizzate in gruppi di misure, ognuno dei quali è correlato a un set di dimensioni specifico mediante le relazioni tra dimensioni definite. Queste relazioni vengono definite specificando le tabelle della vista origine dati coinvolte e il livello di granularità della relazione. Argomento correlato:Relazioni tra dimensioni.

Vedere anche

Database di modelli multidimensionali