Origini dati e associazioni (SSAS - multidimensionale)

È possibile associare cubi, dimensioni e altri oggetti di Analysis Services a un'origine dati. Un'origine dati può essere rappresentata da uno dei seguenti oggetti:

• Un'origine dati relazionale.

• Una pipeline di Analysis Services che restituisce un set di righe o un set di righe a 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 ulteriori 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. Le associazioni per un cubo o altri oggetti Analysis Services sono pertanto espresse sotto forma di associazioni alla vista origine dati. Tali associazioni possono includere associazioni a oggetti logici, quali viste, colonne calcolate e relazioni che non esistono fisicamente nell'origine dati. In Analysis Services viene aggiunta una colonna calcolata che incapsula l'espressione nella vista origine dati, quindi la misura OLAP corrispondente viene associata a tale colonna nella vista origine dati. Per ulteriori informazioni su DSVs, vedere Viste origine dati in modelli multidimensionali.

Ciascun oggetto Analysis Services viene associato all'origine dati in modo specifico. 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 utilizzati nelle associazioni devono corrispondere ai tipi di dati supportati da Analysis Services. In Analysis Services sono definiti i tipi di dati seguenti:

Tutti 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 (SSDT) di solito imposta il tipo di dati nell'associazione a quello che corrisponde meglio al tipo di origine nell'origine dati. Ad esempio, per i tipi di dati SQL Date, DateTime, SmallDateTime, DateTime2, DateTimeOffset viene eseguito il mapping a SSAS Date e il tipo SQL Time 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. Se sono presenti più set di relazioni nella stessa tabella, potrebbe essere necessario introdurre una query denominata nella vista origine dati da utilizzare come tabella di '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.

• Ciascun gruppo di misure è associato a una colonna della tabella, ad esempio Measure.ValueColumn.Source.

• Ciascuna 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 utilizza 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 gli GranularityAttributes non esistano come colonne nella tabella dei fatti. Di seguito vengono riportati i casi in cui gli 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:

• Ciascuna 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.

• Ciascuna colonna di tabella nidificata è associata a 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 DataSource o DataSourceView è specificato, 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 ciascuna proprietà Binding. Ciascuna 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 assume il formato flat tipico dell'elemento Object nei comandi Process, a meno che non siano presenti tag <Object></Object>.

Ciascun oggetto per il quale è specificata l'associazione è identificato da un elemento XML con l'ID <object> del formato, ad esempio DimensionID. Una volta identificato l'oggetto con il formato <object>, è possibile identificare l'elemento per il quale è stata specificata l'associazione, 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 di KeyColumns 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, le Translations sono identificate a livello semantico in base alla lingua. È pertanto necessario che le Translations in Binding includano l'identificatore di lingua.

All'interno di Binding è consentito un elemento aggiuntivo che non esiste direttamente nell'istruzione DDL denominato ParentColumnID, il quale è utilizzato 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.