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

Статья
06/13/2017

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

Таким образом, службы 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_имясервера на сервере. Это учетная запись гостя из сети Интернет, которой предоставлены ограниченные права на сервере. Сборка, запущенная в таком контексте, может получить доступ только к ограниченным ресурсам на локальном сервере.

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

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

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

См. также:

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

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