Origini dati e associazioni (SSAS - multidimensionale)

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

I cubi, le dimensioni e altri oggetti SQL Server Analysis Services possono essere associati a un'origine dati. Un'origine dati può essere rappresentata da uno dei seguenti oggetti:

• Un'origine dati relazionale.

• Pipeline SQL Server Analysis Services che restituisce un set di righe (o set di righe con capitoli).

La modalità di espressione dell'origine dati varia in base al tipo di origine dati. Un'origine dati relazionale si distingue ad esempio per la stringa di connessione. Per altre informazioni sulle origini dati, vedere Origini dati nei modelli multidimensionali.

Indipendentemente dall'origine dati utilizzata, la vista origine dati contiene i metadati per l'origine dati. Pertanto, le associazioni per un cubo o altri oggetti SQL Server Analysis Services vengono espresse come associazioni alla DSV. Queste associazioni possono includere associazioni a oggetti logici, ad esempio viste, colonne calcolate e relazioni che non esistono fisicamente nell'origine dati. SQL Server Analysis Services aggiunge una colonna calcolata che incapsula l'espressione alla DSV e quindi associa la misura OLAP corrispondente a quella colonna nella DSV. Per altre informazioni sulle viste origine dati, vedere Viste origine dati in modelli multidimensionali.

Ogni oggetto SQL Server Analysis Services associa all'origine dati in modo personalizzato. Inoltre, le associazioni dati per tali oggetti e la definizione dell'origine dati possono essere fornite inline con la definizione dell'oggetto associato a dati, ad esempio la dimensione, oppure out-of-line come un set di definizioni distinto.

Tipi di dati di Analysis Services

I tipi di dati usati nelle associazioni devono corrispondere ai tipi di dati supportati da SQL Server Analysis Services. I tipi di dati seguenti sono definiti in SQL Server Analysis Services:

Tutti i dati ricevuti dall'origine dati vengono convertiti nel tipo SSAS specificato nell'associazione (in genere durante l'elaborazione). Viene generato un errore se non è possibile eseguire la conversione (ad esempio da String a Int). SQL Server Data Tools in genere imposta il tipo di dati nell'associazione a quello che corrisponde al tipo di origine nell'origine dati. Ad esempio, i tipi SQL Date, DateTime, SmallDateTime, DateTime2, DateTimeOffset vengono mappati a Data SSAS e il tipo SQL viene mappato a String.

Associazioni per dimensioni

Ciascun attributo di una dimensione è associato a una colonna in una vista origine dati. Tutti gli attributi di una dimensione devono provenire da una singola origine dati. È tuttavia possibile associare gli attributi a colonne di diverse tabelle. Le relazioni tra le tabelle sono definite nella vista origine dati. Nel caso in cui esistano più di un set di relazioni nella stessa tabella, potrebbe essere necessario introdurre una query denominata nella DSV per agire come tabella 'alias'. Le espressioni e i filtri sono definiti nella tabella origine dati mediante calcoli denominati e query denominate.

Associazioni per gruppi di misure, misure e partizioni

Ciascun gruppo di misure dispone delle seguenti associazioni predefinite:

• Il gruppo di misure è associato a una tabella in una vista origine dati, ad esempio MeasureGroup.Source.

• Ogni misura è associata a una colonna della tabella, ad esempio Measure.ValueColumn.Source.

• Ogni dimensione del gruppo di misure dispone di un set di attributi di granularità che definiscono la granularità del gruppo di misure. Ciascuno di tali attributi deve essere associato alla colonna o alle colonne della tabella dei fatti contenente la chiave dell'attributo. Per ulteriori informazioni sugli attributi di granularità, vedere "Attributi di granularità dei gruppi di misure" più avanti in questo argomento.

È possibile eseguire l'override di queste associazioni predefinite in modo selettivo per partizione. Ogni partizione può specificare un'origine dati, un nome di tabella o di query o un'espressione di filtro differente. La strategia di partizionamento più comune consiste nell'eseguire l'override della tabella per partizione, utilizzando la stessa origine dati. È anche possibile applicare un filtro diverso per partizione o modificare l'origine dati.

È necessario definire l'origine dati predefinita nella tabella origine dati, fornendo le informazioni sullo schema e includendo i dettagli delle relazioni. Sebbene le tabelle e le query aggiuntive specificate a livello di partizione non debbano essere elencate nella vista origine dati, devono avere lo stesso schema della tabella predefinita definita per il gruppo di misure o contenere almeno tutte le colonne utilizzate dalle misure o dagli attributi di granularità. Non è possibile eseguire l'override a livello di partizione delle associazioni dettagliate per misura e attributo di granularità. Si presuppone inoltre che si tratti delle stesse colonne definite per il gruppo di misure. Pertanto, se la partizione usa un'origine dati con uno schema diverso, la query TableDefinition definita per la partizione deve restituire lo stesso schema utilizzato dal gruppo di misure.

Attributi di granularità dei gruppi di misure

Se la granularità di un gruppo di misure corrisponde alla granularità nota nel database ed esiste una relazione diretta tra la tabella dei fatti e la tabella delle dimensioni, l'attributo di granularità deve essere associato solo alla colonna chiave esterna appropriata o alle colonne nella tabella dei fatti. Si considerino ad esempio la tabella dei fatti e la tabella delle dimensioni seguenti:

Sales(RequestedDate, OrderedProductID, ReplacementProductID, Qty)

Product(ProductID, ProductName,Category)

``

Relation: Sales.OrderedProductID -> Product.ProductID

Relation: Sales.ReplacementProductID -> Product.ProductID

``

Se si esegue l'analisi in base al prodotto ordinato, l'attributo di granularità Product viene associato a Sales.OrderedProductID per il ruolo di dimensione Ordered Product on Sales.

In alcuni casi è tuttavia possibile che i GranularityAttributes non esistano come colonne nella tabella dei fatti. Di seguito vengono riportati i casi in cui i GranularityAttributes potrebbero non esistere come colonne:

• La granularità OLAP è più grossolana della granularità nell'origine.

• Una tabella intermedia si interpone tra la tabella dei fatti e la tabella delle dimensioni.

• La chiave della dimensione non corrisponde alla chiave primaria nella tabella delle dimensioni.

In tali casi, è necessario definire la vista origine dati in modo che siano presenti attributi di granularità nella tabella dei fatti. È ad esempio possibile introdurre una query denominata o una colonna calcolata.

In caso di granularità per categoria, nelle stesse tabelle di esempio indicate in precedenza è ad esempio possibile introdurre una vista delle vendite:

SalesWithCategory(RequestedDate, OrderedProductID, ReplacementProductID, Qty, OrderedProductCategory)

SELECT Sales.*, Product.Category AS OrderedProductCategory

FROM Sales INNER JOIN Product

ON Sales.OrderedProductID = Product.ProductID

``

In questo caso, la categoria dell'attributo di granularità è associata a SalesWithCategory.OrderedProductCategory.

Esecuzione della migrazione da DSO (Decision Support Objects)

DSO (Decision Support Objects) 8.0 consente di riassociare le PartitionMeasures . La strategia di migrazione in questi casi consiste pertanto nella costruzione della query appropriata.

In modo analogo, non è possibile riassociare gli attributi della dimensione all'interno di una partizione, sebbene DSO 8.0 supporti anche la riassociazione. In questi casi, la strategia di migrazione consiste nel definire le query denominate necessarie nella vista origine dati, in modo tale che nella vista origine dati della partizione esistano le stesse tabelle e colonne utilizzate per la dimensione. Potrebbe in tali casi essere necessario utilizzare la migrazione semplice, che prevede il mapping della clausola From/Join/Filter a una sola query denominata anziché a un set strutturato di tabelle correlate. Sebbene DSO 8.0 consenta la riassociazione delle dimensioni della partizione anche se la partizione utilizza la stessa origine dati, è possibile che la migrazione richieda più viste origine dati per la stessa origine dati.

In DSO 8.0 le associazioni corrispondenti possono essere espresse in due diversi modi, a seconda se vengono utilizzati schemi ottimizzati: associazione alla chiave primaria nella tabella delle dimensioni o alla chiave esterna nella tabella dei fatti. In ASSL non è possibile distinguere questi due modi.

Lo stesso approccio relativo alle associazioni è valido anche per una partizione che utilizza un'origine dati non contenente tabelle delle dimensioni, poiché viene effettuata l'associazione alla colonna chiave esterna nella tabella dei fatti, anziché alla colonna chiave primaria nella tabella delle dimensioni.

Associazioni per modelli di data mining

Un modello di data mining può essere relazionale oppure OLAP. Le associazioni dati per un modello di data mining relazionale sono molto diverse da quelle per un modello di data mining OLAP.

Associazioni per un modello di data mining relazionale

Un modello di data mining relazionale si basa sulle relazioni definite nella vista origine dati per risolvere qualsiasi ambiguità relativa alle associazioni tra colonne e origini dati. In un modello di data mining relazionale, le associazioni dati sono basate sulle seguenti regole:

• Ciascuna colonna di tabella non nidificata è associata a una colonna nella tabella del case o a una tabella correlata alla tabella del case, in base a una relazione molti-a-uno o uno-a-uno. Le relazioni tra le tabelle sono definite nella vista origine dati.

• Ciascuna colonna di tabella nidificata è associata a una tabella di origine. Le colonne di proprietà della colonna di tabella nidificata vengono pertanto associate alle colonne della tabella di origine o di una tabella correlata alla tabella di origine. Anche in questo caso, l'associazione si basa su una relazione molti-a-uno o uno-a-uno. Le associazioni per il modello di data mining non forniscono il percorso di join della tabella nidificata. Tali informazioni vengono invece fornite dalle relazioni definite nella vista origine dati.

Associazioni per un modello di data mining OLAP

I modelli di data mining OLAP non dispongono di un elemento equivalente a una vista origine dati. È pertanto necessario che le associazioni dati consentano la risoluzione di ambiguità tra colonne e origini dati. È ad esempio possibile che un modello di data mining sia basato sul cubo Sales e che le colonne siano basate su Qty, Amount e Product Name. In alternativa, è possibile che un modello di data mining sia basato su Product e che le colonne siano basate su Product Name, Product Color e su una tabella nidificata con Sales Qty.

In un modello di data mining OLAP, le associazioni dati sono basate sulle seguenti regole:

• Ogni colonna di tabella non nidificata è associata a una misura in un cubo, a un attributo in una dimensione del cubo (specificando CubeDimension per risolvere l'ambiguità nel caso dei ruoli di dimensione) o a un attributo in una dimensione.

• Ogni colonna di tabella nidificata è associata a una CubeDimension. Definisce pertanto la modalità di navigazione da una dimensione a un cubo correlato o, nel caso meno comune di tabelle nidificate, da un cubo a una delle relative dimensioni.

associazioni out-of-line

Le associazioni out-of-line consentono di modificare temporaneamente le associazioni dati esistenti per la durata di un comando. Le associazioni out-of-line si riferiscono ad associazioni incluse in un comando e non sono persistenti. Tali associazioni si applicano solo durante l'esecuzione del comando specifico. Le associazioni inline sono invece contenute in una definizione di oggetto ASSL e risultano persistenti con la definizione di oggetto nei metadati del server.

ASSL consente di specificare le associazioni out-of-line in un comando Process , se non è in un batch, o in un comando Batch . Se le associazioni out-of-line sono specificate nel comando Batch , tutte le associazioni specificate nel comando Batch creano un nuovo contesto di associazione in cui vengono eseguiti tutti i comandi Process del batch. Il nuovo contesto di associazione include oggetti elaborati indirettamente a causa del comando Process .

Quando vengono specificate in un comando, le associazioni out-of-line eseguono l'override delle associazioni inline contenute nell'istruzione DDL persistente per gli oggetti specificati. Tali oggetti elaborati possono includere l'oggetto denominato direttamente nel comando Process o altri oggetti la cui elaborazione viene inizializzata automaticamente come parte dell'elaborazione.

Le associazioni out-of-line vengono specificate includendo l'oggetto raccolta Bindings facoltativo nel comando di elaborazione. La raccolta Bindings facoltativa contiene i seguenti elementi.

Tutti gli elementi che fanno riferimento alle associazioni out-of-line sono facoltativi. Per qualsiasi elemento non specificato, ASSL utilizza la specifica contenuta nell'istruzione DDL dell'oggetto persistente. La specifica di DataSource o DataSourceView nel comando Process è facoltativa. Se si specifica DataSource o DataSourceView , la relativa istanza non viene creata. Gli oggetti non risultano inoltre persistenti una volta completato il comando Process .

Definizione del tipo di associazione out-of-line

Nella raccolta Bindings out-of-line, ASSL supporta una raccolta di associazioni per più oggetti, una per ogni proprietà Binding. Ogni proprietà Binding ha un riferimento all'oggetto esteso, che è simile al riferimento all'oggetto, ma può riferirsi anche a oggetti minori, ad esempio attributi della dimensione e attributi del gruppo di misure. Questo oggetto accetta la forma flat dell'elemento Object nei comandi Process, ad eccezione del fatto che i < tag Object></Object> non sono presenti.

Ogni oggetto per il quale viene specificato l'associazione viene identificato da un elemento XML dell'ID oggetto>form<, ad esempio DimensionID. Dopo aver identificato l'oggetto come possibile con l'ID dell'oggetto>form<, identificare l'elemento per il quale viene specificata l'associazione, che è in genere Source. Una situazione comune da tenere in considerazione è quella in cui Source è una proprietà in DataItem, come nel caso delle associazioni di colonna in un attributo. In questo caso, non specificare il tag DataItem . Specificare solo la proprietà Source , come se si trovasse direttamente nella colonna da associare.

L'identificazione diKeyColumns viene effettuata in base all'ordinamento nella raccolta KeyColumns . Non è possibile ad esempio specificare solo la prima e la terza colonna chiave di un attributo, perché non è possibile indicare di ignorare la seconda colonna chiave. Tutte le colonne chiave devono essere presenti nell'associazione out-of-line per un attributo della dimensione.

Sebbene non dispongano di un ID, letraduzionisono identificate a livello semantico in base alla lingua. È pertanto necessario che le traduzioni in una proprietà Binding includano l'identificatore di lingua.

All'interno di Binding è consentito un elemento aggiuntivo che non esiste direttamente nell'istruzione DDL denominato ParentColumnIDe che viene usato per le tabelle nidificate per il data mining. In questo caso, è necessario identificare la colonna padre nella tabella nidificata per la quale è fornita l'associazione.