Поделиться через


Управление сборками многомерной модели

Службы Microsoft SQL Server Analysis Services предоставляют значительное количество внутренних функций для использования с языками многомерных выражений и расширений интеллектуального анализа данных, предназначенных для выполнения любых задач, от стандартных статистических вычислений до обхода элементов в иерархии. Однако, как и с любым другим сложным и надежным продуктом, существует необходимость в дальнейшем расширении функциональности такого продукта.

Поэтому Analysis Services позволяет добавлять сборки в экземпляр Analysis Services или базу данных. Сборки позволяют создавать внешние пользовательские функции при помощи любого языка среды CLR, например Microsoft Visual Basic .NET или Microsoft Visual C#. Также можно использовать языки автоматизации COM, например Microsoft Visual Basic или Microsoft Visual C++.

Примечание по безопасностиПримечание по безопасности

Использование сборок COM может представлять угрозу безопасности. По этой причине, а также по ряду других сборки COM в службах Службы SQL Server 2008 Analysis Services (SSAS) являются устаревшими. Поддержка сборок COM в последующих версиях может быть прекращена.

Сборки позволяют расширять бизнес-функции многомерных выражений и расширений интеллектуального анализа данных. Требуемые функции формируются в виде библиотеки, например динамически подключаемой библиотеки (DLL), которая затем добавляется в качестве сборки к экземпляру служб Analysis Services или к базе данных служб Analysis Services. Общие методы в библиотеке затем открываются в виде пользовательских функций для многомерных выражений и выражений расширений интеллектуального анализа данных, их процедур, вычислений, действий и клиентских приложений.

Для дополнения программного обеспечения сервера может быть установлена сборка с новыми процедурами и функциями. Сборки могут использоваться для расширения или добавления определяемых пользователем функциональных возможностей, которые не предоставляются сервером. Сборки позволяют добавлять новые функции к многомерным выражениям (MDX), расширениям интеллектуального анализа данных (DMX) или хранимым процедурам. Сборки загружаются с того места, откуда запущено пользовательское приложение, и копия двоичного файла сборки сохраняется наряду с данными базы данных на сервере. После удаления сборки удаляется также копия сборки с сервера.

Сборки могут относиться к двум разным типам: COM и CLR. Сборки CLR представляют собой сборки, разработанные на языках программирования .NET Framework, таких как C#, Visual Basic .NET, основанных на C++. Сборки COM — это библиотеки COM, которые должны быть зарегистрированы на сервере.

Сборки могут быть добавлены к объектам Server или Database. Вызов сборок сервера может осуществляться любым пользователем, подключенным к серверу, или любым объектом на сервере. Сборки базы данных могут вызываться только объектами Database или пользователями, подключенными к базе данных.

Простой объект Assembly состоит из основной информации (имени и идентификатора), коллекции файлов и спецификаций безопасности.

Под коллекцией файлов подразумеваются загруженные файлы сборки и соответствующие им файлы отладки (с расширением PDB), если файлы отладки были загружены вместе с файлами сборки. Файлы сборки загружаются из того места, в котором эти файлы определены приложением, а копия этих файлов сохраняется на сервере наряду с данными. Копия файла сборки используется для загрузки сборки при каждом запуске службы.

Спецификации безопасности включают набор разрешений и информацию заимствования полномочий, используемую для эксплуатации сборки.

Вызов пользовательских функций

Вызов пользовательской функции в сборке осуществляется так же, как вызов внутренней функции, за исключением необходимости использовать полное имя объектов (со всеми квалификаторами). Например, пользовательская функция, возвращающая тип, ожидаемый многомерным выражением, включается в запрос многомерных выражений, как показано в следующем примере:

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

Пользовательские функции также могут вызываться при помощи ключевого слова CALL. Ключевое слово CALL необходимо использовать для пользовательских функций, возвращающих наборы записей или пустые значения, и нельзя использовать, если пользовательская функция зависит от объекта в контексте инструкции или скрипта многомерных выражений или расширений интеллектуального анализа данных, например текущего куба или модели интеллектуального анализа данных. Распространенным применением функции, вызываемой вне MDX- или DMX-запроса, является использование модели объектов AMO для выполнения административных функций. Например, если необходимо использовать функцию MyVoidProcedure(a, b, c) в инструкции многомерных выражений, то будет задействован следующий синтаксис:

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

Сборки упрощают разработку базы данных благодаря тому, что общий код создается один раз и сохраняется в одном месте. Разработчики клиентских приложений могут создавать библиотеки функций для служб Analysis Services и распространять их вместе со своими приложениями.

Сборки и пользовательские функции могут дублировать имена функций библиотеки функций служб Analysis Services или других сборок. При условии вызова пользовательской функции полностью достоверным именем службы Analysis Services будут использовать правильную процедуру. В целях безопасности, а также во избежание возможности вызова дублирующего имени в другой библиотеке классов службы Analysis Services требуют использования только полностью достоверных имен для хранимых процедур.

Чтобы вызвать пользовательскую функцию из конкретной сборки CLR, до самой пользовательской функции нужно указать имя сборки, полное имя класса и имя процедуры, как показано на следующем примере:

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

Для обеспечения обратной совместимости с предыдущими версиями служб Analysis Services также допустим следующий синтаксис:

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

Если библиотека COM поддерживает несколько интерфейсов, то ID интерфейса также можно использовать для определения имени процедуры, как демонстрируется в следующем примере:

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

Безопасность

Безопасность сборок основана на модели безопасности платформы .NET Framework, представляющей собой модель безопасности на базе кодового доступа. Платформа .NET Framework поддерживает механизм обеспечения безопасности на базе кодового доступа, который основывается на предположении, что в рабочем цикле может размещаться как полностью, так и частично достоверный код. Ресурсы, чья безопасность обеспечивается системой безопасности платформы .NET Framework на базе кодового доступа, обычно окружены управляемым кодом, который предоставляет доступ к ресурсу только после указания соответствующего разрешения. Требование разрешения удовлетворяется только в том случае, если все вызывающие элементы (на уровне сборки) в стеке вызовов обладают соответствующими ресурсными разрешениями.

Для сборок разрешение на выполнение передается со свойством PermissionSet в объекте Assembly. Разрешения, получаемые управляемым кодом, обусловлены действующей политикой безопасности. В среде, не размещаемой в службах Analysis Services, уже есть три уровня действующей политики: предприятие, компьютер и пользователь. Действительный список разрешений, получаемых кодом, определяется на основании пересечения разрешений, полученных указанными тремя уровнями.

Службы Analysis Services предоставляют размещенной в себе среде CLR уровень политики безопасности на уровне сервера; данная политика представляет собой дополнительный уровень политики, расположенный ниже трех уже действующих уровней политики. Данная политика задается для каждого домена приложений, создаваемого службами Analysis Services.

Политика на уровне сервера служб Analysis Services является сочетанием фиксированной политики служб Analysis Services для системных сборок и пользовательской политики для пользовательских сборок. В основе пользовательской части политики сервера служб Analysis Services лежит указание владельцем сборки одного из трех сегментов разрешений для каждой сборки:

Установка разрешения

Описание

Safe

Обеспечивает разрешение внутреннего вычисления. Данный сегмент разрешений не предоставляет разрешений для доступа к любым из защищаемых ресурсов платформы .NET Framework. Для сборки этот сегмент разрешений является сегментом по умолчанию, если в свойстве PermissionSet не указывается иное.

ExternalAccess

Предоставляет такой же доступ, как и параметр Safe, с дополнительной возможностью доступа к внутренним системным ресурсам. Данный сегмент разрешений не предлагает гарантий безопасности (хотя возможность обезопасить данный сценарий существует), однако он предоставляет гарантии надежности.

Unsafe

Не предоставляет каких-либо ограничений. Для управляемого кода, запущенного под данным набором разрешений, нельзя создать гарантии безопасности или надежности. Коду, запущенному на данном уровне доверия, предоставляется любое, даже пользовательское разрешение, включенное администратором.

При размещении среды CLR в службах Analysis Services разрешение, основанное на обходе стека, проверяет остановки на границе с собственным кодом служб Analysis Services. Любой управляемый код в сборках служб Analysis Services всегда попадает в одну из трех категорий разрешений, упомянутых выше.

COM-подпрограммы сборки (или неуправляемые) не поддерживают модель безопасности среды CLR.

Олицетворение

При доступе управляемого кода к любому ресурсу, расположенному за пределами служб Analysis Services, службы Analysis Services следуют правилам, связанным со свойством ImpersonationMode сборки для обеспечения доступа в рамках соответствующего контекста безопасности Windows. Поскольку сборки, использующие параметр разрешения Safe, не могут получить доступ к ресурсам за пределами служб Analysis Services, данные правила применяются только в отношении сборок, использующих параметры разрешения ExternalAccess и Unsafe.

  • Если текущий контекст исполнения соответствует имени входа, прошедшему проверку подлинности Windows, и идентичен контексту вызывающего элемента (то есть в середине нет инструкции EXECUTE AS), тогда службы Analysis Services будут олицетворять имя входа, прошедшее проверку подлинности Windows, прежде чем получить доступ к ресурсу.

  • В случае отсутствия промежуточной инструкции EXECUTE AS, изменившей контекст исходного вызывающего элемента, попытка получить доступ к внутреннему ресурсу закончится ошибкой.

Свойство ImpersonationMode может принимать значение ImpersonateCurrentUser или ImpersonateAnonymous. Параметр по умолчанию, ImpersonateCurrentUser, запускает сборку под текущей сетевой учетной записью входа пользователя. При использовании параметра ImpersonateAnonymous контекст исполнения соответствует учетной записи входа пользователя Windows IUSER_servername на сервере. Это учетная запись гостя из сети Интернет, которой предоставлены ограниченные права на сервере. Сборка, запущенная в таком контексте, может получить доступ только к ограниченным ресурсам на локальном сервере.

Домены приложений

Службы Analysis Services не открывают домены приложений напрямую. На основании набора сборок, запущенных в одном и том же домене приложений, домены приложений способны обнаруживать друг друга во время выполнения, используя пространство имен служб System.Reflection на платформе .NET Framework или иными способами, а также способны вызывать их с использованием режима позднего связывания. Такие вызовы подвергаются проверкам разрешений, используемым основанной на авторизации системой безопасности служб Analysis Services.

Не следует искать сборки в том же домене приложений, поскольку граница домена приложений и сборки, входящие в каждый домен, определяются реализацией.

См. также

Основные понятия

Настройка безопасности хранимых процедур

Определение хранимых процедур