Assembly (Analysis Services)
Microsoft SQL Server 2005 Analysis Services (SSAS) offre una vasta gamma di funzioni intrinseche da utilizzare con i linguaggi MDX (Multidimensional Expressions) e DMX (Data Mining Extensions), progettate per eseguire qualsiasi tipo di operazione, dai calcoli statistici standard all'attraversamento dei membri di 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.
Analysis Services consente pertanto di aggiungere assembly a un database o a un'istanza di 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++.
Gli assembly consentono di estendere la funzionalità business dei linguaggi MDX e DMX. È necessario creare la funzionalità desiderata in una libreria, ad esempio in una libreria a collegamento dinamico (DLL), e aggiungerla come assembly a un'istanza di Analysis Services o a un database di 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.
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 set di record 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 di 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 di software client possono creare librerie di funzioni per Analysis Services e distribuirle con le applicazioni stesse.
Gli assembly e le funzioni definite dall'utente possono duplicare i nomi delle funzioni della libreria di Analysis Services o di altri assembly. Analysis Services utilizzerà la procedura corretta a condizione che la funzione definita dall'utente venga chiamata utilizzando il relativo nome completo. Al fine di garantire la protezione ed evitare che venga chiamato un nome duplicato in una diversa libreria di classi, Analysis Services richiede l'utilizzo esclusivamente di 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 assicurare la compatibilità con le versioni precedenti di Analysis Services, è possibile utilizzare anche la sintassi seguente:
AssemblyName!FullClassName!ProcedureName(Argument1, Argument2, ...)
Se una libreria COM supporta più interfacce, è inoltre possibile utilizzare l'ID dell'interfaccia per risolvere il nome della procedura, come illustrato di seguito:
AssemblyName!InterfaceID!ProcedureName(Argument1, Argument2, ...)
Protezione
La protezione degli assembly è basata sul modello di protezione dall'accesso di codice di .NET Framework. .NET Framework supporta un meccanismo di protezione dall'accesso di codice che presume che il run-time possa ospitare codice completamente o parzialmente attendibile. In genere, la protezione delle risorse mediante protezione 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 dal criterio di protezione attivo. In un ambiente diverso da Analysis Services esistono già tre livelli di criteri attivi: organizzazione, computer e utente. L'elenco effettivo delle autorizzazioni ricevute dal codice è determinato dall'intersezione delle autorizzazioni ottenute da questi tre livelli.
Analysis Services offre criteri di protezione a livello host per CLR, quando ospita tale ambiente. Questo livello di criteri aggiuntivo è sottostante ai tre livelli sempre attivi e viene impostato per ogni dominio applicazione creato da Analysis Services.
Il criterio a livello host di Analysis Services è una combinazione dei criteri fissi di Analysis Services per gli assembly di sistema e dei criteri specificati dall'utente per gli assembly utente. La parte del criterio host di Analysis Services definita dall'utente è basata su uno dei tre bucket di autorizzazione specificati per ogni assembly dal relativo proprietario:
| 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 protezione ma di affidabilità. |
Unsafe |
Non prevede alcuna restrizione. Per il codice gestito eseguito con questo set di autorizzazioni non è possibile offrire garanzie di protezione o di affidabilità. A questo livello di attendibilità viene concessa infatti qualsiasi autorizzazione, anche un'autorizzazione personalizzata inclusa dall'amministratore. |
Quando CLR è ospitato in un ambiente Analysis Services, il controllo delle autorizzazioni basato sul percorso stack viene interrotto al confine con il codice Analysis Services nativo. Qualsiasi codice gestito negli assembly di Analysis Services rientra sempre in una delle tre categorie di autorizzazione elencate in precedenza.
Le routine di assembly COM o non gestiti non supportano il modello di protezione CLR.
Rappresentazione
Ogni volta che il codice gestito accede a una risorsa esterna a Analysis Services, Analysis Services segue le regole associate all'impostazione della proprietà ImpersonationMode dell'assembly per assicurare che l'accesso venga eseguito nel contesto di protezione di Windows appropriato. Poiché gli assembly che utilizzano l'impostazione di autorizzazione Safe non possono accedere alle risorse esterne a Analysis Services, tali regole sono applicabili solo agli assembly che utilizzano le impostazioni di autorizzazione ExternalAccess e Unsafe.
- Se il contesto di esecuzione corrente corrisponde all'account di accesso con autenticazione di Windows ed è identico al contesto del chiamante originale, ovvero non è incluso EXECUTE AS, Analysis Services rappresenterà l'account di accesso con autenticazione 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 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. 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 delle applicazioni
Analysis Services non espone direttamente i domini delle applicazioni. Per mezzo dell'insieme degli assembly in esecuzione nello stesso dominio dell'applicazione, tali domini possono individuarsi a vicenda in fase di esecuzione utilizzando 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 utilizzati dalla protezione di Analysis Services.
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
Concetti
Impostazione della protezione per stored procedure (Analysis Services)
Utilizzo di stored procedure (Analysis Services)