Gerenciamento de assemblies de modelo multidimensional

O Microsoft SQL Server Analysis Services fornece muitas funções intrínsecas para uso com as linguagens MDX (Expressões Multidimensionais) e DMX (Extensões de Mineração de Dados), para realizar desde cálculos estatísticos padrão até percorrer membros de uma hierarquia. Mas, como acontece com qualquer outro produto complexo e robusto, sempre há a necessidade de estender ainda mais a funcionalidade de um produto desse tipo.

Portanto, o Analysis Services permite adicionar assemblies a uma instância ou banco de dados do Analysis Services. Os assemblies permitem criar funções externas definidas pelo usuário usando qualquer linguagem CLR (Common Language Runtime), como o Microsoft Visual Basic .NET ou o Microsoft Visual C#. Você também pode usar linguagens de Automação do COM (Component Object Model), como o Microsoft Visual Basic ou o Microsoft Visual C++.

Os assemblies permitem estender as funcionalidades empresariais do MDX e do DMX. Você cria a funcionalidade desejada em uma biblioteca, como uma DLL (biblioteca de link dinâmico) e adiciona a biblioteca como um assembly a uma instância do Analysis Services ou a um banco de dados do Analysis Services. Os métodos públicos na biblioteca são expostos como funções definidas pelo usuário para expressões MDX e DMX, procedimentos, cálculos, ações e aplicativos cliente.

Um assembly com novos procedimentos e funções pode ser adicionado ao servidor. Você pode usar assemblies para aprimorar ou adicionar funcionalidades personalizadas que não são fornecidas pelo servidor. Usando assemblies, você pode adicionar novas funções a MDX (Expressões Multidimensionais), DMX (Extensões de Mineração de Dados) ou procedimentos armazenados. Os assemblies são carregados do local em que o aplicativo personalizado é executado e uma cópia do arquivo binário do assembly é salva junto com os dados do banco de dados no servidor. Quando um assembly é removido, o assembly copiado também é removido do servidor.

Os assemblies podem ser de dois tipos diferentes: COM e CLR. Os assemblies CLR são desenvolvidos em linguagens de programação do .NET Framework, como C#, Visual Basic .NET e C++ gerenciado. Assemblies COM são bibliotecas COM que devem ser registradas no servidor

Assemblies podem ser adicionados a objetos Server ou Database. Os assemblies de servidor podem ser chamados por qualquer usuário conectado ao servidor ou qualquer objeto no servidor. Os assemblies de banco de dados só podem ser chamados por Database objetos ou usuários conectados ao banco de dados.

Um objeto simples Assembly é composto de informações básicas (Nome e ID), coleção de arquivos e especificações de segurança.

A coleção de arquivos refere-se aos arquivos de assembly carregados e seus correspondentes arquivos de depuração (.pdb), se estes foram carregados juntamente com os arquivos de assembly. Os arquivos de assembly são carregados do local para o qual o aplicativo definiu os arquivos e uma cópia é salva no servidor junto com os dados. A cópia do arquivo de assemblagem é usada para carregar a assemblagem sempre que o serviço é iniciado.

As especificações de segurança incluem o conjunto de permissões e a impersonação usada para executar o assembly.

Chamando funções da User-Defined

Chamar uma função definida pelo usuário em um assembly é igual a chamar uma função intrínseca, exceto que você deve usar um nome completamente qualificado. Por exemplo, uma função definida pelo usuário que retorna um tipo esperado pelo MDX está incluída em uma consulta MDX, conforme mostrado no exemplo a seguir:

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

As funções definidas pelo usuário também podem ser chamadas usando a palavra-chave CALL. Você deve usar a palavra-chave CALL para funções definidas pelo usuário que retornam conjuntos de registros ou valores nulos e não poderá usar a palavra-chave CALL se a função definida pelo usuário depender de um objeto no contexto da instrução ou script MDX ou DMX, como o cubo atual ou o modelo de mineração de dados. Um uso comum para uma função chamada fora de uma consulta MDX ou DMX é usar o modelo de objeto AMO para executar funções administrativas. Se, por exemplo, você quisesse usar a função MyVoidProcedure(a, b, c) em uma instrução MDX, a seguinte sintaxe seria empregada:

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

Os assemblies simplificam o desenvolvimento de banco de dados, permitindo que o código comum seja desenvolvido uma vez e armazenado em um único local. Os desenvolvedores de software cliente podem criar bibliotecas de funções para o Analysis Services e distribuí-las com seus aplicativos.

Assemblies e funções definidas pelo usuário podem duplicar os nomes de função da biblioteca de funções do Analysis Services ou de outros assemblies. Desde que você chame a função definida pelo usuário usando seu nome totalmente qualificado, o Analysis Services usará o procedimento correto. Para fins de segurança e para eliminar a chance de chamar um nome duplicado em uma biblioteca de classes diferente, o Analysis Services exige que você use apenas nomes totalmente qualificados para procedimentos armazenados.

Para chamar uma função definida pelo usuário de um assembly CLR específico, a função definida pelo usuário é precedida pelo nome do assembly, pelo nome da classe completa e pelo nome do procedimento, conforme demonstrado aqui:

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

Para compatibilidade com versões anteriores do Analysis Services, a seguinte sintaxe também é aceitável:

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

Se uma biblioteca COM der suporte a várias interfaces, a ID da interface também poderá ser usada para resolver o nome do procedimento, conforme demonstrado aqui:

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

Segurança

A segurança para assemblies baseia-se no modelo de segurança do .NET Framework, que é um modelo de segurança de acesso a código. O .NET Framework dá suporte a um mecanismo de segurança de acesso a código que pressupõe que o runtime possa hospedar código totalmente confiável e parcialmente confiável. Os recursos protegidos pela segurança de acesso ao código do .NET Framework normalmente são encapsulados pelo código gerenciado que exige a permissão correspondente antes de habilitar o acesso ao recurso. A demanda para a permissão é satisfatória apenas quando todos os chamadores (no nível de assembly) na pilha de chamadas tiverem a permissão do recurso correspondente.

Para assemblies, a permissão para execução é passada com a PermissionSet propriedade no Assembly objeto. As permissões recebidas pelo código gerenciado são determinadas pela política de segurança em vigor. Já existem três níveis de política em vigor em um ambiente não hospedado do Analysis Services: empresa, computador e usuário. A lista efetiva de permissões recebidas pelo código é determinada pela interseção das permissões obtidas por esses três níveis.

O Analysis Services fornece um nível de política de segurança no nível do host para o CLR durante a hospedagem; essa política é um nível de política adicional abaixo dos três níveis de política que estão sempre em vigor. Essa política é definida para cada domínio de aplicativo criado pelo Analysis Services.

A política de nível de host do Analysis Services é uma combinação de política fixa do Analysis Services para assemblies de sistema e política especificada pelo usuário para assemblies de usuário. A parte especificada pelo usuário da política de host do Analysis Services baseia-se no proprietário do assembly especificando um dos três buckets de permissão para cada assembly:

Quando o CLR é hospedado pelo Analysis Services, a verificação de permissão baseada em stack-walk é interrompida no limite com o código nativo do Analysis Services. Qualquer código gerenciado em assemblies do Analysis Services sempre se enquadra em uma das três categorias de permissão listadas anteriormente.

As rotinas de assembly COM (ou não gerenciadas) não dão suporte ao modelo de segurança CLR.

Representação

Sempre que o código gerenciado acessa qualquer recurso fora do Analysis Services, o Analysis Services segue as regras associadas à configuração de propriedade do assembly ImpersonationMode para garantir que o acesso ocorra em um contexto de segurança do Windows apropriado. Como os assemblies que usam a configuração de permissão Safe não podem acessar recursos fora do Analysis Services, essas regras são aplicáveis somente para assemblies que usam as configurações de permissão ExternalAccess e Unsafe.

• Se o contexto de execução atual corresponder ao logon autenticado do Windows e for o mesmo que o contexto do chamador original (ou seja, não há EXECUTE AS no meio), o Analysis Services representará o logon autenticado do Windows antes de acessar o recurso.

• Se houver um EXECUTE AS intermediário que alterou o contexto do chamador original, a tentativa de acessar o recurso externo falhará.

A ImpersonationMode propriedade pode ser definida como ImpersonateCurrentUser ou ImpersonateAnonymous. A configuração padrão ImpersonateCurrentUser executa um assembly na conta de logon de rede do usuário atual. Se a ImpersonateAnonymous configuração for usada, o contexto de execução corresponderá à conta de usuário de logon do Windows IUSER_servername no servidor. Essa é a conta de convidado da Internet, que tem privilégios limitados no servidor. Um assembly em execução nesse contexto só pode acessar recursos limitados no servidor local.

Domínios de aplicativo

O Analysis Services não expõe domínios de aplicativo diretamente. Devido a um conjunto de assemblies em execução no mesmo domínio de aplicativo, os domínios de aplicativo podem descobrir uns aos outros no momento da execução usando o System.Reflection namespace no .NET Framework ou de alguma outra maneira e podem chamá-los de maneira tardia. Essas chamadas estarão sujeitas às verificações de permissão usadas pela segurança baseada em autorização do Analysis Services.

Você não deve contar com a localização de assemblies no mesmo domínio do aplicativo, pois o limite de domínio do aplicativo e os assemblies que entram em cada domínio são definidos pela implementação.

Consulte Também

Configurando a segurança para procedimentos armazenados
Definindo procedimentos armazenados