Origini dati e collegamenti (SSAS Multidimensionale)

2017-03-06

I cubi, le dimensioni e altri oggetti di Analysis Services possono essere associati a un'origine dati. Un'origine dati può essere uno degli oggetti seguenti:

Una origine dati relazionale.
Un flusso di servizi di analisi che produce un insieme di righe (o insiemi di righe suddivisi in capitoli).

I mezzi per esprimere l'origine dati variano in base al tipo di origine dati. Ad esempio, un'origine dati relazionale è distinta dalla stringa di connessione. Per altre informazioni sulle origini dati, vedere Origini dati nei modelli multidimensionali.

Indipendentemente dall'origine dati usata, la vista origine dati (DSV) contiene i metadati per l'origine dati. Di conseguenza, le associazioni per un cubo o altri oggetti di Analysis Services vengono espresse come associazioni alla vista del modello dei dati. Queste associazioni possono includere associazioni a oggetti logici, ad esempio viste, colonne calcolate e relazioni che non esistono fisicamente nell'origine dati. Analysis Services aggiunge una colonna calcolata che incapsula l'espressione alla vista origine dati e quindi associa la misura OLAP corrispondente a tale colonna nella vista origine dati. Per altre informazioni sui DSV, vedere Viste origine dati nei modelli multidimensionali.

Ogni oggetto Analysis Services viene associato all'origine dati in modo autonomo. Inoltre, i collegamenti dati per questi oggetti e la definizione dell'origine dati possono essere forniti in linea con la definizione dell'oggetto collegato ai dati (ad esempio, la dimensione), oppure fuori linea come set separato di definizioni.

Tipi di dati di Analysis Services

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

Tipo di dati di Analysis Services	Descrizione
BigInt	Intero con segno a 64 bit. Questo tipo di dati viene mappato al tipo di dati Int64 all'interno di Microsoft .NET Framework e al tipo di dati DBTYPE_I8 all'interno di OLE DB.
Bool	Valore booleano. Questo tipo di dati viene mappato al tipo di dati booleano all'interno di .NET Framework e al tipo di dati DBTYPE_BOOL all'interno di OLE DB.
Valuta	Valore di valuta compreso tra -263 (o -922.337.203.685.477.5808) e 263-1 (o +922.337.203.685.477.5807) con accuratezza fino a diecimilasimi di unità valuta. Questo tipo di dati viene mappato al tipo di dati Decimal nel .NET Framework e al tipo di dati DBTYPE_CY nell'OLE DB.
Dati	Dati di data, archiviati come numero a virgola mobile e precisione doppia. L'intera parte è il numero di giorni dal 30 dicembre 1899, mentre la parte frazionaria è una frazione di un giorno. Questo tipo di dati viene mappato al tipo di dati DateTime all'interno di .NET Framework e al tipo di dati DBTYPE_DATE all'interno di OLE DB.
Doppio	Numero a virgola mobile a doppia precisione compreso nell'intervallo tra -1,79E +308 e 1,79E +308. Questo tipo di dati viene mappato al tipo di dati Double all'interno di .NET Framework e al tipo di dati DBTYPE_R8 all'interno di OLE DB.
Numero intero	Intero con segno a 32 bit. Questo tipo di dati viene mappato al tipo di dati Int32 all'interno di .NET Framework e al tipo di dati DBTYPE_I4 all'interno di OLE DB.
Singolo	Numero a virgola mobile a singola precisione nell'intervallo tra -3,40E +38 e 3,40E +38. Questo tipo di dati viene mappato al tipo di dati Single all'interno di .NET Framework e al tipo di dati DBTYPE_R4 all'interno di OLE DB.
SmallInt	Intero con segno a 16 bit. Questo tipo di dati viene mappato al tipo di dati Int16 all'interno di .NET Framework e al tipo di dati DBTYPE_I2 all'interno di OLE DB.
TinyInt	Intero con segno a 8 bit. Questo tipo di dati viene mappato al tipo di dati SByte all'interno di .NET Framework e al tipo di dati DBTYPE_I1 all'interno di OLE DB. Nota: se un'origine dati contiene campi con tipo di dati tinyint e la proprietà AutoIncrement è impostata su True, verranno convertiti in numeri interi nella vista origine dati.
UnsignedBigInt	Intero senza segno a 64 bit. Questo tipo di dati viene mappato al tipo di dati UInt64 all'interno di .NET Framework e al tipo di dati DBTYPE_UI8 all'interno di OLE DB.
Intero senza segno	Intero senza segno a 32 bit. Questo tipo di dati viene mappato al tipo di dati UInt32 all'interno di .NET Framework e al tipo di dati DBTYPE_UI4 all'interno di OLE DB.
UnsignedSmallInt	Intero senza segno a 16 bit. Questo tipo di dati viene mappato al tipo di dati UInt16 all'interno di .NET Framework e al tipo di dati DBTYPE_UI2 all'interno di OLE DB.
WChar	Flusso con terminazione Null di caratteri Unicode. Questo tipo di dati corrisponde al tipo di dati String all'interno di .NET Framework e al tipo di dati DBTYPE_WSTR in OLE DB.

Tutti i dati ricevuti dall'origine dati vengono convertiti nel tipo SSAS specificato nell'associazione (in genere durante l'elaborazione). Se non è possibile eseguire la conversione, ad esempio String to Int, viene generato un errore. Gli strumenti SQL Server Data Tools (SSDT) solitamente impostano il tipo di dati nell'associazione in modo che corrisponda al meglio al tipo di origine presente nella fonte dati. Ad esempio, i tipi SQL Date, DateTime, SmallDateTime, DateTime2, DateTimeOffset vengono mappati al tipo SSAS Date, mentre il tipo SQL Time viene mappato a String.

Collegamenti per le dimensioni

Ogni attributo di una dimensione è associato a una colonna in una vista origine dati (DSV). Tutti gli attributi di una dimensione devono provenire da una singola origine dati. Tuttavia, gli attributi possono essere associati a colonne in tabelle diverse. Le relazioni tra le tabelle sono definite nel DSV. Nel caso in cui esistano più set di relazioni nella stessa tabella, potrebbe essere necessario introdurre una query denominata nella vista origine dati per fungere da tabella "alias". Le espressioni e i filtri vengono definiti nella DSV (vista origine dati) utilizzando calcoli denominati e query denominate.

Associazioni per Gruppi di Misurazione, Misure e Partizioni

Ogni gruppo di misure ha le associazioni predefinite seguenti:

Il gruppo di misure è associato a una tabella in un DSV, ad esempio MeasureGroup.Source.
Ogni misura è associata a una colonna della tabella , ad esempio Measure.ValueColumn.Source.
Ogni dimensione del gruppo di misure ha un set di attributi di granularità che definiscono la granularità del gruppo di misure. Ognuno di questi attributi deve essere associato alla colonna o alle colonne della tabella dei fatti che contengono la chiave dell'attributo. Per ulteriori informazioni sugli attributi di granularità, consultare gli attributi di granularità del gruppo di misure più avanti nel presente argomento.

Queste associazioni predefinite possono essere sottoposte a override selettiva per ogni partizione. Ogni partizione può specificare un'origine dati diversa, un nome di tabella o di query o un'espressione di filtro. La strategia di partizionamento più comune consiste nell'eseguire l'override della tabella per partizione usando la stessa origine dati. Le alternative includono l'applicazione di un filtro diverso per partizione o la modifica dell'origine dati.

L'origine dati predefinita deve essere definita nella DSV, fornendo in questo modo le informazioni sullo schema, inclusi i dettagli delle relazioni. Le tabelle o le query aggiuntive specificate a livello di partizione non devono essere elencate nel DSV, ma devono avere lo stesso schema della tabella predefinita definita per il gruppo di misure, o almeno devono contenere tutte le colonne usate dalle misure o dagli attributi di granularità. Le associazioni dettagliate per ogni attributo di misura e granularità non possono essere sottoposte a override a livello di partizione e si presuppone che siano le stesse colonne definite per il gruppo di misure. Pertanto, se la partizione usa un'origine dati che ha effettivamente uno schema diverso, la TableDefinition query definita per la partizione deve restituire lo stesso schema dello schema usato dal gruppo di misure.

Attributi di granularità del gruppo di misura

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

Sales(RequestedDate, OrderedProductID, ReplacementProductID, Qty)

Product(ProductID, ProductName,Category)

Relation: Sales.OrderedProductID -> Product.ProductID

Relation: Sales.ReplacementProductID -> Product.ProductID

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

Tuttavia, potrebbero verificarsi momenti in cui l'oggetto GranularityAttributes potrebbe non esistere come colonne nella tabella dei fatti. Ad esempio, potrebbe GranularityAttributes non esistere come colonne nelle circostanze seguenti:

La granularità OLAP è più grossolana rispetto alla 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 tutti questi casi, il DSV deve essere definito in modo che gli attributi di granularità esistano nella tabella dei fatti. Ad esempio, è possibile introdurre una query denominata o una colonna calcolata.

Ad esempio, nelle stesse tabelle di esempio descritte in precedenza, se la granularità era in base a Category, è possibile introdurre una visualizzazione 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 GranularityAttribute è associata a SalesWithCategory.OrderedProductCategory.

Migrazione da oggetti di supporto decisionale

Gli oggetti DSO (Decision Support Objects) 8.0 consentono di PartitionMeasures rimbalzare. Pertanto, la strategia di migrazione in questi casi consiste nel costruire la query appropriata.

Analogamente, non è possibile riassociare gli attributi della dimensione all'interno di una partizione, anche se DSO 8.0 consente anche questa riassociazione. La strategia di migrazione in questi casi consiste nel definire le query denominate necessarie nel DSV, affinché le stesse tabelle e colonne esistano nel DSV per la partizione come quelle utilizzate per la dimensione. Questi casi possono richiedere l'adozione della migrazione semplice, in cui la clausola From/Join/Filter viene mappata a una singola query denominata anziché a un set strutturato di tabelle correlate. DSO 8.0 consente il rimbalzo di PartitionDimensions anche quando la partizione usa la stessa origine dati, la migrazione potrebbe richiedere anche più DSV per la stessa origine dati.

In DSO 8.0, le associazioni corrispondenti possono essere espresse in due modi diversi, a seconda che vengano utilizzati schemi ottimizzati, tramite l'associazione alla chiave primaria nella tabella delle dimensioni o alla chiave esterna nella tabella dei fatti. In ASSL le due forme diverse non sono distinte.

Lo stesso approccio alle associazioni si applica anche per una partizione che utilizza un'origine dati che non contiene le tabelle delle dimensioni, perché l'associazione viene effettuata alla colonna chiave esterna nella tabella dei fatti, non alla colonna chiave primaria nella tabella delle dimensioni.

Collegamenti per i modelli di mining

Un modello di data mining è relazionale o OLAP. I data binding per un modello di data mining relazionale sono notevolmente diversi rispetto alle associazioni per un modello di data mining OLAP.

Vincoli per un modello di mining relazionale

Un modello di data mining relazionale si basa sulle relazioni definite nella vista origine dati (DSV) per risolvere qualsiasi ambiguità riguardante le colonne collegate alle fonti di dati. In un modello di data mining relazionale, i data binding seguono queste regole:

Ogni colonna di tabella non nidificata è associata a una colonna nella tabella del caso o in una tabella correlata alla tabella del caso (secondo una relazione molti a uno o uno a uno). DSV definisce le relazioni tra le tabelle.
Ogni colonna della tabella nidificata è associata a una tabella di origine. Le colonne appartenenti alla colonna della tabella annidata vengono quindi associate a colonne nella tabella sorgente o in una tabella correlata alla tabella sorgente. Anche in questo caso, l'associazione segue una relazione molti-a-uno o uno-a-uno. Le associazioni di modelli di data mining non forniscono il percorso di join alla tabella nidificata. Invece, le relazioni definite nella DSV forniscono queste informazioni.

Collegamenti per un modello di mining OLAP

I modelli di data mining OLAP non hanno l'equivalente di una vista di origine dati. Pertanto, i collegamenti dati devono fornire qualsiasi disambiguazione tra colonne e origini dati. Ad esempio, un modello di data mining può essere basato sul cubo Sales e le colonne possono essere basate su Qty, Amount e Product Name. In alternativa, un modello di data mining può essere basato su Prodotto e le colonne possono essere basate su Nome del Prodotto, Colore del Prodotto e una tabella annidata con Quantità di Vendite.

In un modello di data mining OLAP, i data binding seguono queste regole:

Ogni colonna di tabella non nidificata è associata a una misura su un cubo, a un attributo nella dimensione del cubo (specificando per CubeDimension disambiguare nel caso dei ruoli di dimensione) o a un attributo nella dimensione.
Ogni colonna della tabella nidificata è associata a un oggetto CubeDimension. Ciò significa che definisce come passare da una dimensione a un cubo correlato o, nel caso meno comune delle tabelle nidificate, da un cubo a una delle relative dimensioni.

Associazioni fuori linea

Le associazioni out-of-line consentono di modificare temporaneamente le associazioni di dati esistenti per la durata di un comando. Le associazioni out-of-line fanno riferimento alle associazioni incluse in un comando e non sono persistenti. Le associazioni out-of-line si applicano solo durante l'esecuzione di quel particolare comando. Al contrario, le associazioni inline sono contenute nella definizione dell'oggetto ASSL e vengono mantenute con la definizione dell'oggetto all'interno dei metadati del server.

ASSL consente di specificare associazioni out-of-line su un comando Process, se non è in un batch, oppure su un comando Batch. Se le associazioni out-of-line vengono 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. Questo nuovo contesto di associazione include oggetti elaborati indirettamente a causa del Process comando .

Quando si specificano associazioni out-of-line in un comando, eseguono l'override delle associazioni inline contenute nel DDL persistente per gli oggetti specificati. Questi oggetti elaborati possono includere l'oggetto denominato direttamente nel Process comando oppure possono includere altri oggetti la cui elaborazione viene avviata automaticamente come parte dell'elaborazione.

Le associazioni fuori linea vengono specificate includendo l'oggetto raccolta opzionale Bindings nel comando di elaborazione. La raccolta facoltativa Bindings contiene gli elementi seguenti.

Proprietà	Cardinalità	TIPO	Descrizione
`Binding`	0-n	`Binding`	Fornisce una raccolta di nuove connessioni.
`DataSource`	0-1	`DataSource`	Sostituisce `DataSource` proveniente dal server che sarebbe stato utilizzato.
`DataSourceView`	0-1	`DataSourceView`	Sostituisce il `DataSourceView` con server che sarebbe stato utilizzato.

Tutti gli elementi correlati alle associazioni out-of-line sono facoltativi. Per gli elementi non specificati, ASSL usa la specifica contenuta nel DDL dell'oggetto persistente. La specifica di DataSource o DataSourceView nel Process comando è facoltativa. Se DataSource o DataSourceView vengono specificati, non vengono instanziati e non persistono dopo il comando Process.

Definizione del tipo di associazione out-of-line

All'interno della raccolta out-of-lineBindings, ASSL consente una raccolta di associazioni per più oggetti, ognuno di essi ciascuno un Binding. Ognuno Binding ha un riferimento a un oggetto esteso, simile al riferimento all'oggetto, ma può anche fare riferimento a oggetti secondari , ad esempio attributi della dimensione e attributi del gruppo di misure. Questo oggetto assume la forma piatta tipica dell'elemento Object nei Process comandi, ad eccezione del fatto che i < tag Object></Object> non sono presenti.

Ogni oggetto per il quale viene specificata l'associazione è identificato da un elemento XML della forma <oggetto>ID (ad esempio, DimensionID). Dopo aver identificato l'oggetto nel modo più specifico possibile utilizzando il modulo ID <oggetto>, si procede a identificare l'elemento per il quale viene specificata l'associazione, che è generalmente Source. Un caso comune da notare è che in cui Source è una proprietà in DataItem, che è il caso per le associazioni di colonna in un attributo. In questo caso, non si specifica il DataItem tag, ma si specifica semplicemente la Source proprietà , come se fosse direttamente sulla colonna da associare.

KeyColumns vengono identificati dall'ordine all'interno della raccolta KeyColumns. Non è possibile specificare, ad esempio, solo la prima e la terza colonna chiave di un attributo, perché non è possibile indicare che la seconda colonna chiave deve essere ignorata. Tutte le colonne chiave devono essere presenti nell'associazione out-of-line per un attributo della dimensione.

Translations, anche se non hanno ID, sono identificati semanticamente dal linguaggio. Pertanto, è necessario che il Translations all'interno di un Binding includa il relativo identificatore di lingua.

Un elemento aggiuntivo consentito all'interno di un Binding che non è presente direttamente nel DDL è ParentColumnID, utilizzato per le tabelle nidificate nel data mining. In questo caso, è necessario identificare la colonna padre nella tabella nidificata per cui si fornisce il legame.

Condividi tramite