Administración de ensamblados de modelos multidimensionales

Microsoft SQL Server Analysis Services proporciona una gran cantidad de funciones intrínsecas para su uso con los lenguajes de expresiones multidimensionales (MDX) y Extensiones de minería de datos (DMX), diseñados para llevar a cabo todo, desde cálculos estadísticos estándar hasta el recorrido de miembros en una jerarquía. Pero, al igual que con cualquier otro producto complejo y robusto, siempre es necesario ampliar aún más la funcionalidad de este producto.

Por lo tanto, Analysis Services le permite agregar ensamblados a una instancia o base de datos de Analysis Services. Los ensamblados permiten crear funciones externas definidas por el usuario mediante cualquier lenguaje de Common Language Runtime (CLR), como Microsoft Visual Basic .NET o Microsoft Visual C#. También puede usar lenguajes de automatización del modelo de objetos componentes (COM), como Microsoft Visual Basic o Microsoft Visual C++.

Los ensamblados permiten ampliar la funcionalidad empresarial de MDX y DMX. Cree la funcionalidad que desee en una biblioteca, como una biblioteca de vínculos dinámicos (DLL) y agregue la biblioteca como un ensamblado a una instancia de Analysis Services o a una base de datos de Analysis Services. A continuación, los métodos públicos de la biblioteca se exponen como funciones definidas por el usuario en expresiones MDX y DMX, procedimientos, cálculos, acciones y aplicaciones cliente.

Se puede agregar un ensamblado con nuevos procedimientos y funciones al servidor. Puede usar ensamblados para mejorar o agregar funcionalidad personalizada que el servidor no proporciona. Mediante el uso de ensamblados, puede agregar nuevas funciones a expresiones multidimensionales (MDX), extensiones de minería de datos (DMX) o procedimientos almacenados. Los ensamblados se cargan desde la ubicación donde se ejecuta la aplicación personalizada y se guarda una copia del archivo binario de ensamblado junto con los datos de la base de datos del servidor. Cuando se quita un ensamblado, el ensamblado copiado también se quita del servidor.

Los ensamblados pueden ser de dos tipos diferentes: COM y CLR. Los ensamblados CLR son ensamblados desarrollados en lenguajes de programación de .NET Framework como C#, Visual Basic .NET, C++administrado. Los ensamblados COM son bibliotecas COM que se deben registrar en el servidor

Los ensamblados se pueden agregar a objetos Server o Database. Los ensamblados del servidor pueden ser llamados por cualquier usuario conectado al servidor o por cualquier objeto en el servidor. Los ensamblados de base de datos solo pueden ser llamados por objetos Database o usuarios conectados a la base de datos.

Un objeto simple Assembly se compone de información básica (nombre e identificador), colección de archivos y especificaciones de seguridad.

La colección de archivos hace referencia a los archivos de ensamblado cargados y sus archivos de depuración (.pdb) correspondientes, si los archivos de depuración se cargaron con los archivos de ensamblado. Los archivos de ensamblado se cargan desde la ubicación en la que la aplicación definió los archivos y se guarda una copia en el servidor junto con los datos. La copia del archivo de ensamblado se usa para cargar el ensamblado cada vez que se inicia el servicio.

Las especificaciones de seguridad incluyen el conjunto de permisos y la suplantación que se usa para ejecutar el ensamblado.

Llamar a funciones User-Defined

Llamar a una función definida por el usuario en un ensamblado se realiza igual que llamar a una función intrínseca, excepto que debe usar un nombre completo. Por ejemplo, una función definida por el usuario que devuelve un tipo esperado por MDX se incluye en una consulta MDX, como se muestra en el ejemplo siguiente:

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

También se puede llamar a las funciones definidas por el usuario mediante la palabra clave CALL. Debe usar la palabra clave CALL para funciones definidas por el usuario que devuelven conjuntos de registros o valores vacíos, y no puede usar la palabra clave CALL si la función definida por el usuario depende de un objeto en el contexto de la instrucción MDX o DMX o del script, como el cubo actual o el modelo de minería de datos. Un uso común de una función denominada fuera de una consulta MDX o DMX es usar el modelo de objetos de AMO para realizar funciones administrativas. Si, por ejemplo, quería usar la función MyVoidProcedure(a, b, c) en una instrucción MDX, se emplearía la sintaxis siguiente:

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

Los ensamblados simplifican el desarrollo de bases de datos al permitir que el código común se desarrolle una vez y se almacene en una sola ubicación. Los desarrolladores de software cliente pueden crear bibliotecas de funciones para Analysis Services y distribuirlas con sus aplicaciones.

Los ensamblados y las funciones definidas por el usuario pueden duplicar los nombres de función de la biblioteca de funciones de Analysis Services o de otros ensamblados. Siempre que llame a la función definida por el usuario mediante su nombre completo, Analysis Services usará el procedimiento correcto. Para fines de seguridad y para eliminar la posibilidad de llamar a un nombre duplicado en una biblioteca de clases diferente, Analysis Services requiere que use solo nombres completos para procedimientos almacenados.

Para llamar a una función definida por el usuario desde un ensamblado CLR específico, la función definida por el usuario va precedida por el nombre del ensamblado, el nombre de clase completo y el nombre del procedimiento, como se muestra aquí:

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

Para la compatibilidad con versiones anteriores de Analysis Services, también se admite la sintaxis siguiente:

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

Si una biblioteca COM admite varias interfaces, también se puede usar el identificador de interfaz para resolver el nombre del procedimiento, como se muestra aquí:

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

Seguridad

La seguridad de los ensamblados se basa en el modelo de seguridad de .NET Framework, que es un modelo de seguridad de acceso a código. .NET Framework admite un mecanismo de seguridad de acceso a código que supone que el entorno de ejecución puede hospedar código de plena confianza y de confianza parcial. Normalmente, los recursos protegidos por la seguridad de acceso al código de .NET Framework se encapsulan mediante código administrado que exige el permiso correspondiente antes de habilitar el acceso al recurso. La solicitud de permiso solo se satisface si todos los que llaman (en el nivel de ensamblado) de la pila de llamadas tienen el permiso correspondiente para el recurso.

Para los ensamblajes, el permiso para la ejecución se transmite con la propiedad PermissionSet del objeto Assembly. Los permisos que recibe el código administrado están determinados por la directiva de seguridad en vigor. Ya hay tres niveles de directiva en vigor en un entorno hospedado que no es de Analysis Services: empresa, equipo y usuario. La lista efectiva de permisos que recibe el código viene determinada por la intersección de los permisos obtenidos por estos tres niveles.

Analysis Services proporciona un nivel de directiva de seguridad de nivel de host al CLR mientras lo hospeda; esta directiva es un nivel de directiva adicional por debajo de los tres niveles de directiva que siempre están en vigor. Esta directiva se establece para cada dominio de aplicación creado por Analysis Services.

La directiva de nivel de host de Analysis Services es una combinación de directivas fijas de Analysis Services para ensamblados del sistema y directiva especificada por el usuario para ensamblados de usuario. La parte especificada por el usuario de la directiva de host de Analysis Services se basa en que el propietario del ensamblado especifica una de las tres categorías de permisos para cada ensamblado.

Cuando CLR se hospeda en Analysis Services, la comprobación de permisos realizada a través de la pila se detiene en el límite con código nativo de Analysis Services. Cualquier código administrado en los ensamblados de Analysis Services siempre entra en una de las tres categorías de permisos enumeradas anteriormente.

Las rutinas de ensamblado COM (o no administradas) no admiten el modelo de seguridad CLR.

Suplantación

Cada vez que el código administrado accede a cualquier recurso fuera de Analysis Services, Analysis Services sigue las reglas asociadas a la ImpersonationMode configuración de propiedad del ensamblado para asegurarse de que el acceso se produce en un contexto de seguridad de Windows adecuado. Dado que los ensamblados que usan la Safe configuración de permisos no pueden tener acceso a recursos fuera de Analysis Services, estas reglas solo se aplican a los ensamblados que usan la ExternalAccess configuración de permisos y Unsafe .

• Si el contexto de ejecución actual corresponde al inicio de sesión autenticado de Windows y es el mismo que el contexto del autor de la llamada original (es decir, no hay EXECUTE AS en el medio), Analysis Services suplantará el inicio de sesión autenticado de Windows antes de acceder al recurso.

• Si hay un EXECUTE AS intermedio que cambió el contexto del autor de la llamada original, el intento de acceder al recurso externo fallará.

La ImpersonationMode propiedad se puede establecer en ImpersonateCurrentUser o ImpersonateAnonymous. La configuración predeterminada, ImpersonateCurrentUser, ejecuta un ensamblado en la cuenta de inicio de sesión de red del usuario actual. Si se usa la ImpersonateAnonymous configuración, el contexto de ejecución corresponde a la cuenta de usuario de inicio de sesión de Windows IUSER_servername en el servidor. Esta es la cuenta de invitado de Internet, que tiene privilegios limitados en el servidor. Un ensamblado que se ejecuta en este contexto solo puede acceder a recursos limitados en el servidor local.

Dominios de aplicación

Analysis Services no expone directamente los dominios de aplicación. Debido a un conjunto de ensamblados que se ejecutan en el mismo dominio de aplicación, los dominios de aplicación pueden detectarse entre sí en tiempo de ejecución utilizando el System.Reflection espacio de nombres en .NET Framework o de alguna otra manera, y pueden llamar a ellos de forma tardía. Estas llamadas estarán sujetas a las comprobaciones de permisos usadas por la seguridad basada en autorización de Analysis Services.

No debe confiar en la búsqueda de ensamblados en el mismo dominio de aplicación, ya que la implementación define el límite del dominio de aplicación y los ensamblados que van a cada dominio.

Véase también

Establecer la seguridad de los procedimientos almacenados
Definición de procedimientos almacenados