Gerenciamento de assemblies de modelo multidimensional

Aplica-se a: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

O Microsoft SQL Server SQL Server Analysis Services fornece muitas funções intrínsecas para uso com as linguagens MDX (Multidimensional Expressions) e DMX (Data Mining Extensions), projetadas para realizar tudo, desde cálculos estatísticos padrão até a passagem de membros em uma hierarquia. Mas, como em qualquer outro produto complexo, há sempre a necessidade de estender a funcionalidade para o produto.

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

Importante

Os assemblies COM podem representar um risco à segurança. Devido a esse risco e outras considerações, os assemblies COM foram preteridos no SSAS (SQL Server 2008 Analysis Services). Talvez não haja suporte para assemblies COM em versões futuras.

Os assemblies permitem estender a funcionalidade empresarial de MDX e DMX. Você cria a funcionalidade desejada em uma biblioteca, como uma DLL (biblioteca de vínculo dinâmico) e adiciona a biblioteca como um assembly a uma instância do SQL Server Analysis Services ou a um banco de dados SQL Server Analysis Services. Em seguida, 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. É possível usar assemblies para aprimorar ou adicionar funcionalidade personalizada que não foi fornecida pelo servidor. Usando os assemblies, você pode adicionar novas funções para o MDX, extensões DMX ou procedimentos armazenados. Os assemblies são carregados do local onde o aplicativo personalizado é executado e uma cópia do arquivo binário do assembly é salva 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 .NET Framework, como C#, Visual Basic .NET, C++ gerenciado. Os 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 objetos Database ou usuários conectados ao banco de dados.

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

A coleção de arquivo refere-se aos arquivos assembly carregados e seus arquivos de depuração correspondentes (.pdb), caso os arquivos de depuração tenham sido carregados com os arquivos assembly. Os arquivos assembly são carregados do local em que o aplicativo definiu os arquivos e uma cópia é gravada no servidor com os dados. A cópia do arquivo assembly é usada para carregar o assembly sempre que o serviço é iniciado.

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

Chamando funções definidas pelo usuário

A chamada de uma função definida pelo usuário em um assembly é executada como a chamada de uma função intrínseca, exceto pelo fato de que você deve usar um nome totalmente qualificado. Por exemplo, uma função definida pelo usuário que retorna um tipo esperado pelo MDX é 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 retornem conjuntos de registros ou valores nulos e não será possível 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 de 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ê quiser usar a função MyVoidProcedure(a, b, c) em uma instrução MDX, a seguinte sintaxe será aplicada:

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

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

Assemblies e funções definidas pelo usuário podem duplicar os nomes de função do SQL Server Analysis Services biblioteca de funções ou de outros assemblies. Contanto que você chame a função definida pelo usuário usando seu nome totalmente qualificado, SQL Server 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, SQL Server Analysis Services requer 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 é precedida pelo nome do assembly, o nome completo da classe e o nome do procedimento, conforme demonstrado aqui:

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

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

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

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

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

Segurança

A segurança dos assemblies baseia-se no modelo de segurança .NET Framework, que é um modelo de segurança de acesso por código. O .NET Framework oferece suporte a um mecanismo de segurança de acesso por código assumindo que o runtime pode hospedar tanto o código totalmente confiável quanto o parcialmente confiável. Os recursos protegidos pela segurança de código de acesso .NET Framework geralmente são envolvidos pelo código gerenciado que demanda a permissão correspondente antes de permitir 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 os assemblies, a permissão de execução é passada com a propriedade PermissionSet no objeto Assembly . As permissões que o código gerenciado recebe 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 hospedado não SQL Server Analysis Services: empresa, computador e usuário. A lista efetiva de permissões que o código recebe é determinada pela interseção das permissões obtidas por esses três níveis.

SQL Server 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 por SQL Server Analysis Services.

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

Configuração de permissões	Descrição
Safe	Fornece a permissão de computação interna. Esse recipiente de permissão não atribui permissões para acessar qualquer um dos recursos protegidos em .NET Framework. Este será o recipiente de permissão padrão de um assembly se não houver outro especificado com a propriedade PermissionSet .
ExternalAccess	Fornece o mesmo acesso que a configuração Safe , com a habilidade adicional de acessar recursos externos do sistema. Esse recipiente de permissão não oferece garantias de segurança (embora seja possível para proteger esse cenário), mas oferece garantias de confiabilidade.
Inseguro	Não fornece restrições. Nenhuma garantia de segurança ou confiabilidade pode ser criada para o código gerenciado executado sob essa permissão definida. Qualquer permissão, mesmo uma permissão personalizada incluída pelo administrador, é concedida ao código executado nesse nível de confiança.

Quando o CLR é hospedado por SQL Server Analysis Services, a permissão baseada em stack walk marcar para no limite com código de SQL Server Analysis Services nativo. Qualquer código gerenciado em assemblies SQL Server 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 oferecem suporte ao modelo de segurança CLR.

Representação

Sempre que o código gerenciado acessa qualquer recurso fora SQL Server Analysis Services, SQL Server Analysis Services segue as regras associadas à configuração da propriedade ImpersonationMode do assembly para garantir que o acesso ocorra em um contexto de segurança apropriado do Windows. Como os assemblies que usam a configuração De permissão segura não podem acessar recursos fora SQL Server 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 houver EXECUTE AS no meio), SQL Server Analysis Services representará o logon autenticado do Windows antes de acessar o recurso.

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

A propriedade ImpersonationMode 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 configuração ImpersonateAnonymous for usada, o contexto de execução será correspondente à conta de usuário de logon do Windows IUSER_nomedoservidor no servidor. Esta é a conta-convidado da Internet que limitou os privilégios no servidor. Um assembly executado nesse contexto só pode acessar recursos limitados no servidor local.

Domínios do aplicativo

SQL Server Analysis Services não expõe domínios de aplicativo diretamente. Devido a um conjunto de assemblies executado no mesmo domínio de aplicativo, os domínios de aplicativo podem descobrir um ao outro no momento de execução usando o namespace System.Reflection no .NET Framework, ou de alguma outra maneira, e podem chamá-los no modo associado mais recente. Essas chamadas estarão sujeitas às verificações de permissão usadas pelo SQL Server Analysis Services segurança baseada em autorização.

Você não deve confiar na localização dos assemblies no mesmo domínio do aplicativo, pois o limite do domínio de aplicativo e dos assemblies que vão para cada domínio são definidos pela implementação.

Consulte Também

Definindo a segurança para procedimentos armazenados
Definindo procedimentos armazenados