Gestione di assembly di modelli multidimensionali

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

Microsoft SQL Server SQL Server Analysis Services fornisce molte funzioni intrinseche da usare con i linguaggi MDX (Multidimensional Expressions) e Data Mining Extensions (DMX), progettati per eseguire tutte le operazioni dai calcoli statistici standard ai membri in una gerarchia. Come avviene per qualsiasi altro prodotto complesso e affidabile, tuttavia, si avverte sempre l'esigenza di estendere ulteriormente la funzionalità di questo servizio.

Pertanto, SQL Server Analysis Services consente di aggiungere assembly a un'istanza o a un database SQL Server Analysis Services. Gli assembly consentono di creare funzioni esterne definite dall'utente mediante qualsiasi linguaggio Common Language Runtime (CLR), ad esempio Microsoft Visual Basic .NET o Microsoft Visual C#. È inoltre possibile utilizzare linguaggi di automazione COM (Component Object Model), ad esempio Microsoft Visual Basic o Microsoft Visual C++.

Importante

Gli assembly COM potrebbero comportare un rischio per la sicurezza. A causa di questo rischio e altre considerazioni, gli assembly COM sono stati deprecati in SQL Server 2008 Analysis Services (SSAS). e potrebbero non essere supportati nelle versioni future.

Gli assembly consentono di estendere la funzionalità business dei linguaggi MDX e DMX. Si compilano le funzionalità desiderate in una libreria, ad esempio una libreria di collegamento dinamica (DLL) e si aggiunge la libreria come assembly a un'istanza di SQL Server Analysis Services o a un database SQL Server Analysis Services. I metodi pubblici della libreria vengono quindi esposti come funzioni definite dall'utente in espressioni MDX e DMX, procedure, calcoli, azioni e applicazioni client.

Un assembly con nuove procedure e funzioni può essere aggiunto al server. È possibile utilizzare gli assembly per migliorare o aggiungere funzionalità personalizzate non fornite dal server. Gli assembly consentono di aggiungere nuove funzioni in formato MDX (Multidimensional Expressions) e DMX (Data Mining Extensions) o stored procedure. Gli assembly vengono caricati dal percorso di esecuzione dell'applicazione personalizzata e una copia del file binario dell'assembly viene salvata nel server insieme ai dati del database. La rimozione di un assembly implica anche la rimozione dell'assembly copiato dal server.

Sono disponibili due tipi di assembly: COM e CLR. Gli assembly CLR sono sviluppati nei linguaggi di programmazione .NET Framework, ad esempio C#, Visual Basic .NET e C++ gestito. Gli assembly COM sono librerie COM che devono essere registrate nel server.

È possibile aggiungere gli assembly a oggetti Server o Database . Gli assembly del server possono essere chiamati da qualsiasi utente connesso al server o da un oggetto nel server. Gli assembly del database possono essere chiamati solo da oggetti Database o utenti connessi al database.

Un oggetto Assembly semplice è composto da informazioni di base (Nome e ID), dalla raccolta di file e dalle specifiche di sicurezza.

La raccolta di file fa riferimento ai file di assembly caricati e ai file di debug corrispondenti con estensione pdb, se i file di debug sono stati caricati con i file di assembly. I file di assembly vengono caricati dal percorso in cui sono stati definiti dall'applicazione e una copia viene salvata nel server insieme ai dati. La copia del file di assembly viene utilizzata per caricare l'assembly a ogni avvio del servizio.

Le specifiche di sicurezza includono il set di autorizzazioni e la rappresentazione utilizzata per l'esecuzione dell'assembly.

Chiamata di funzioni definite dall'utente

La chiamata in un assembly di una funzione definita dall'utente viene eseguita esattamente come la chiamata di una funzione intrinseca, tranne per il fatto che è necessario utilizzare un nome completo. Una funzione definita dall'utente che restituisce un tipo previsto dal linguaggio MDX, ad esempio, viene inclusa in una query MDX come illustrato nell'esempio seguente:

Select MyAssembly.MyClass.MyStoredProcedure(a, b, c) on 0 from Sales  

È inoltre possibile chiamare le funzioni definite dall'utente mediante la parola chiave CALL. È necessario utilizzare la parola chiave CALL per le funzioni definite dall'utente che restituiscono recordset o valori void, mentre non è possibile utilizzare tale parola chiave se la funzione definita dall'utente dipende da un oggetto nel contesto dell'istruzione o dello script MDX o DMX, ad esempio il cubo o il modello di data mining corrente. In genere, una funzione chiamata al di fuori di una query MDX o DMX viene utilizzata per eseguire funzioni amministrative mediante il modello a oggetti AMO. Se ad esempio si desidera utilizzare la funzione MyVoidProcedure(a, b, c) in un'istruzione MDX, è necessario applicare la sintassi seguente:

Call MyAssembly.MyClass.MyVoidProcedure(a, b, c)  

Gli assembly semplificano lo sviluppo di database consentendo di scrivere una sola volta il codice comune e di archiviarlo in una singola posizione. Gli sviluppatori software client possono creare librerie di funzioni per SQL Server Analysis Services e distribuirle con le applicazioni.

Gli assembly e le funzioni definite dall'utente possono duplicare i nomi delle funzioni della libreria di funzioni SQL Server Analysis Services o di altri assembly. Se si chiama la funzione definita dall'utente usando il nome completo, SQL Server Analysis Services userà la procedura corretta. A scopo di sicurezza e per eliminare la possibilità di chiamare un nome duplicato in una libreria di classi diversa, SQL Server Analysis Services richiede che usi solo nomi completi per le stored procedure.

Per chiamare una funzione definita dall'utente da un assembly CLR specifico, è necessario che tale funzione sia preceduta dal nome dell'assembly, dal nome completo della classe e dal nome della procedura, come illustrato di seguito:

AssemblyName. FullClassName. ProcedureName(Argument1, Argument2, ...)

Per la compatibilità con le versioni precedenti di SQL Server Analysis Services, è accettabile anche la sintassi seguente:

NomeAssembly!NomeCompletoClasse!NomeProcedura(Argomento1, Argomento2, ...)

Se una libreria COM supporta più interfacce, è inoltre possibile utilizzare l'ID dell'interfaccia per risolvere il nome della procedura, come illustrato di seguito:

NomeAssembly!IDInterfaccia!NomeProcedura(Argomento1, Argomento2, ...)

Sicurezza

La sicurezza degli assembly è basata sul modello di sicurezza dall'accesso di codice di .NET Framework. .NET Framework supporta un meccanismo di sicurezza dall'accesso di codice che presume che il run-time possa ospitare codice completamente o parzialmente attendibile. In genere, la sicurezza delle risorse mediante sicurezza dall'accesso di codice di .NET Framework viene eseguita tramite wrapping delle risorse con codice gestito, che richiede l'autorizzazione corrispondente prima di consentire l'accesso alla risorsa. La richiesta di autorizzazione viene soddisfatta solo se tutti i chiamanti a livello di assembly nello stack di chiamate dispongono dell'autorizzazione corrispondente per la risorsa.

Per gli assembly, l'autorizzazione relativa all'esecuzione viene passata con la proprietà PermissionSet sull'oggetto Assembly . Le autorizzazioni ricevute dal codice gestito sono determinate dai criteri di sicurezza attivi. Esistono già tre livelli di criteri in un ambiente non SQL Server Analysis Services ospitato: enterprise, computer e utente. L'elenco effettivo delle autorizzazioni ricevute dal codice è determinato dall'intersezione delle autorizzazioni ottenute da questi tre livelli.

SQL Server Analysis Services fornisce un livello di criteri di sicurezza a livello di host a CLR durante l'hosting. Questo criterio è un livello di criterio aggiuntivo al di sotto dei tre livelli di criteri sempre effettivi. Questo criterio è impostato per ogni dominio applicazione creato da SQL Server Analysis Services.

I criteri SQL Server Analysis Services a livello di host sono una combinazione di criteri fissi SQL Server Analysis Services per gli assembly di sistema e i criteri specificati dall'utente per gli assembly utente. Il componente specificato dall'utente del criterio host SQL Server Analysis Services si basa sul proprietario dell'assembly specificando uno dei tre bucket di autorizzazione per ogni assembly:

Impostazione dell'autorizzazione	Descrizione
Safe	Garantisce l'autorizzazione per calcoli interni. Questo bucket non assegna autorizzazioni per l'accesso alle risorse protette di .NET Framework. Rappresenta il bucket di autorizzazione predefinito per un assembly se non ne è stato specificato uno con la proprietà PermissionSet .
ExternalAccess	Assicura lo stesso accesso dell'impostazione Safe , con la possibilità aggiuntiva di accedere a risorse di sistema esterne. Sebbene sia possibile proteggere questo scenario, tale bucket di autorizzazione non offre garanzie di sicurezza ma di affidabilità.
Pericoloso	Non prevede alcuna restrizione. Per il codice gestito eseguito con questo set di autorizzazioni non è possibile offrire garanzie di sicurezza o di affidabilità. A questo livello di attendibilità viene concessa infatti qualsiasi autorizzazione, anche un'autorizzazione personalizzata inclusa dall'amministratore.

Quando CLR è ospitato da SQL Server Analysis Services, il controllo delle autorizzazioni basate su stack si arresta al limite con il codice nativo SQL Server Analysis Services. Qualsiasi codice gestito negli assembly SQL Server Analysis Services rientra sempre in una delle tre categorie di autorizzazioni elencate in precedenza.

Le routine di assembly COM o non gestiti non supportano il modello di sicurezza CLR.

Rappresentazione

Ogni volta che il codice gestito accede a qualsiasi risorsa all'esterno di SQL Server Analysis Services, SQL Server Analysis Services segue le regole associate all'impostazione della proprietà ImpersonationMode dell'assembly per assicurarsi che l'accesso si verifichi in un contesto di sicurezza di Windows appropriato. Poiché gli assembly che usano l'impostazione Di autorizzazione sicura non possono accedere alle risorse all'esterno di SQL Server Analysis Services, queste regole sono applicabili solo per gli assembly usando le impostazioni di autorizzazione ExternalAccess e Unsafe.

• Se il contesto di esecuzione corrente corrisponde all'account di accesso autenticato di Windows ed è lo stesso del contesto del chiamante originale, ovvero non esiste EXECUTE AS al centro, SQL Server Analysis Services rappresenta l'account di accesso autenticato di Windows prima di accedere alla risorsa.

• Se esiste un EXECUTE AS intermedio che ha modificato il contesto rispetto a quello del chiamante originale, il tentativo di accesso alla risorsa esterna non riuscirà.

È possibile impostare la proprietà ImpersonationMode su ImpersonateCurrentUser o su ImpersonateAnonymous. L'impostazione predefinita ImpersonateCurrentUseresegue un assembly con l'account di accesso di rete dell'utente corrente. Se viene usata l'impostazione ImpersonateAnonymous , il contesto di esecuzione corrisponde all'account utente di accesso di Windows IUSER_servername nel server. Questo rappresenta l'account Internet Guest, che dispone di privilegi limitati sul server. Un assembly eseguito in questo contesto può accedere solo a risorse limitate nel server locale.

Domini applicazione

SQL Server Analysis Services non espone direttamente i domini dell'applicazione. Per mezzo del set degli assembly in esecuzione nello stesso dominio dell'applicazione, tali domini possono individuarsi a vicenda in fase di esecuzione usando lo spazio dei nomi System.Reflection di .NET Framework o in altro modo, nonché eseguire chiamate all'interno con associazione tardiva. Tali chiamate saranno soggette ai controlli delle autorizzazioni usati da SQL Server Analysis Services sicurezza basata sull'autorizzazione.

La ricerca degli assembly nello stesso dominio dell'applicazione non è affidabile, poiché il confine e gli assembly di ogni dominio dell'applicazione vengono definiti dall'implementazione.

Vedere anche

Impostazione della sicurezza per stored procedure
Definizione di stored procedure