Gestione degli 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 numerose funzioni intrinseche da usare con i linguaggi MDX (Multidimensional Expressions) e DMX (Data Mining Extensions), progettati per eseguire tutte le operazioni, dai calcoli statistici standard all'attraversamento dei membri in una gerarchia. Ma, come per qualsiasi altro prodotto complesso e robusto, c'è sempre la necessità di estendere ulteriormente la funzionalità di tale prodotto.

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

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

È possibile aggiungere un assembly con nuove procedure e funzioni al server. È possibile usare gli assembly per migliorare o aggiungere funzionalità personalizzate non fornite dal server. Usando gli assembly, è possibile aggiungere nuove funzioni a MDX (Multidimensional Expressions), Data Mining Extensions (DMX) o stored procedure. Gli assembly vengono caricati dal percorso in cui viene eseguita l'applicazione personalizzata e una copia del file binario dell'assembly viene salvata insieme ai dati del database nel server. Quando un assembly viene rimosso, l'assembly copiato viene rimosso anche dal server.

Gli assembly possono essere di due tipi diversi: COM e CLR. Gli assembly CLR sono assembly sviluppati in linguaggi di programmazione .NET Framework come C#, Visual Basic .NET, C++ gestito. Gli assembly COM sono librerie COM che devono essere registrate nel server

Gli assembly possono essere aggiunti a oggetti Server o Database. Gli assembly del server possono essere chiamati da qualsiasi utente connesso al server o a qualsiasi oggetto nel server. Gli assembly di database possono essere chiamati solo da Database oggetti o utenti connessi al database.

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

La raccolta di file fa riferimento ai file di assembly caricati e ai relativi file di debug (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 l'applicazione ha definito i file e una copia viene salvata nel server insieme ai dati. La copia del file di assembly viene usata per caricare l'assembly ogni volta che viene avviato il servizio.

Le specifiche di sicurezza includono il set di autorizzazioni e l'impersonificazione usata per eseguire l'assembly.

Chiamata di funzioni definite dall'utente

La chiamata di una funzione definita dall'utente in un assembly viene eseguita esattamente come la chiamata di una funzione intrinseca, ad eccezione del fatto che è necessario usare un nome completo. Ad esempio, una funzione definita dall'utente che restituisce un tipo previsto da MDX è inclusa in una query MDX, come illustrato nell'esempio seguente:

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

Le funzioni definite dall'utente possono essere chiamate anche usando la parola chiave CALL. È necessario utilizzare la parola chiave CALL per le funzioni definite dall'utente che restituiscono recordset o valori void e non è possibile utilizzare la parola chiave CALL se la funzione definita dall'utente dipende da un oggetto nel contesto dell'istruzione MDX o DMX o dello script, ad esempio il cubo corrente o il modello di data mining. Un uso comune per una funzione chiamata all'esterno di una query MDX o DMX consiste nell'usare il modello a oggetti AMO per eseguire funzioni amministrative. Se, ad esempio, si vuole usare la funzione MyVoidProcedure(a, b, c) in un'istruzione MDX, verrà usata la sintassi seguente:

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

Gli assembly semplificano lo sviluppo di database abilitando lo sviluppo di codice comune una sola volta e archiviati in un'unica posizione. Gli sviluppatori di 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 di funzione della libreria di funzioni di 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. Per motivi di sicurezza ed eliminare la possibilità di chiamare un nome duplicato in una libreria di classi diversa, SQL Server Analysis Services richiede l'uso solo di nomi completi per le stored procedure.

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

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

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

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

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

AssemblyName! InterfaceID! ProcedureName(Argument1, Argument2, ...)

Security

La sicurezza degli assembly è basata sul modello di sicurezza .NET Framework, ovvero un modello di sicurezza con accesso al codice. .NET Framework supporta un meccanismo di sicurezza con accesso al codice che presuppone che il runtime possa ospitare codice completamente attendibile e parzialmente attendibile. Le risorse protette dalla sicurezza dell'accesso al codice .NET Framework vengono in genere incluse in codice gestito che richiedono l'autorizzazione corrispondente prima di abilitare 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 di risorsa corrispondente.

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

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

I criteri a livello di host di SQL Server Analysis Services sono una combinazione di criteri fissi di SQL Server Analysis Services per gli assembly di sistema e i criteri specificati dall'utente per gli assembly utente. La parte specificata dall'utente dei criteri host di SQL Server Analysis Services è basata sul proprietario dell'assembly che specifica uno dei tre bucket di autorizzazione per ogni assembly:

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

Le routine di assembly COM (o non gestite) non supportano il modello di sicurezza CLR.

Impersonificazione

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 Autorizzazione sicura non possono accedere alle risorse esterne a SQL Server Analysis Services, queste regole sono applicabili solo per gli assembly che usano le impostazioni di autorizzazione ExternalAccess e Unsafe .

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

• Se è presente un'istruzione EXECUTE AS intermedia che ha modificato il contesto rispetto a quello del chiamante originale, il tentativo di accesso alla risorsa esterna avrà esito negativo.

La proprietà ImpersonationMode può essere impostata su ImpersonateCurrentUser o ImpersonateAnonymous. Come impostazione predefinita, ImpersonateCurrentUser esegue un assembly con l'account di accesso di rete dell'utente corrente. Se viene utilizzata l'impostazione ImpersonateAnonymous , il contesto di esecuzione corrisponde all'account utente di accesso di Windows IUSER_servername nel server. Si tratta dell'account guest Internet, che dispone di privilegi limitati sul server. Un assembly in esecuzione in questo contesto può accedere solo a risorse limitate nel server locale.

Domini di applicazione

SQL Server Analysis Services non espone direttamente i domini applicazione. A causa di un set di assembly in esecuzione nello stesso dominio applicativo, i domini applicativi possono individuarsi reciprocamente in fase di esecuzione usando lo spazio dei nomi System.Reflection in .NET Framework o in altro modo, e possono chiamarli in modalità a legame tardivo. Tali chiamate saranno soggette ai controlli delle autorizzazioni usati dalla sicurezza basata sull'autorizzazione di SQL Server Analysis Services.

Non è consigliabile fare affidamento sulla ricerca di assembly nello stesso dominio applicazione, perché il limite del dominio applicazione e gli assembly che accedono a ogni dominio sono definiti dall'implementazione.

Vedere anche

Impostazione della sicurezza per le stored procedure
Definizione delle procedure memorizzate