Выражение 1

select {[Measures].[Сумма]} on 0,

non empty {[Дата].[Месяц].[Месяц].members} on 1

from [PF].

Предположим, что нам требуется в этом отчете упорядочить месяцы по возрастанию плановых показателей. Вообще говоря, результат исполнения выражения 1 можно воспринимать по-разному. С одной стороны — это отчет, с другой — его можно считать многомерным пространством, являющимся подпространством исходного куба. Результат выражения 1 — подкуб куба [PF].

Вы видите, количество атрибутов, спроецированных на оси отчета, меньше общего числа атрибутов в исходном кубе. Для недостающих атрибутов Microsoft Analysis создает специальную ось — Slicer Axis (наиболее точный перевод — ось среза). Она содержит по одному элементу каждой из осей, не представленных в отчете. Такие элементы называются Default member (элементы по умолчанию).

Элементы по умолчанию выбираются для каждого измерения на этапе проектирования многомерной модели. Для агрегируемых атрибутов (в иерархии присутствует элемент [All]) в качестве такого элемента обычно назначается [All]. В частности, элемент [All] выбирается элементом по умолчанию для измерения [План_Факт], которого нет в выражении 1. Поэтому в показателе «Сумма» стоит результат ([План]+[Факт]).

Когда требуется детализировать срез данных, добавленных в подкуб, используют предложение WHERE. Если мы хотим оставить в подкубе только плановые значения, в предложении WHERE нужно указать соответствующий элемент измерения [План_Факт] (рис. 3).

Рис. 3. Задание глобального контекста

Из рис. 3 видно, что теперь в операторе Select используется уточненная координата по измерению [План_Факт], в нем элемент [All] заменили на элемент [План]. Поэтому об операторе Select говорят, что он выполняется в контексте предложения WHERE.

Важно отметить, что добавленное в запрос ограничение WHERE будет действовать для любого пользователя, подключенного к аналитическому серверу, в рамках каждой его открытой сессии. Поэтому про инструкцию WHERE еще говорят, что она определяет глобальный контекст куба (Global scope).

После того как мы сузили исходное пространство и оставили в нем только плановые значения, мы можем попытаться отсортировать набор {[Дата].[Месяц].members }, который откладывается на оси Y отчета, по возрастанию меры «Сумма».

Как видно из рис. 4, в созданном отчете месяцы упорядочены по возрастанию плановых показателей. Это ожидаемый результат: в подкубе нет ничего, кроме плановых значений. Поэтому вполне естественно, что сортировка набора по мере «Сумма» автоматически ранжирует периоды и по возрастанию плана. Но вот можно ли признать полученный результат удачным? Скорее всего, нет. У нас не получится использовать упорядоченный набор из дат для отображения фактических результатов продаж — ведь информации о факте нет в созданном срезе данных.

Рис. 4. Сортировка календарных периодов по мере «Сумма»

Из сказанного следует, что глобальный контекст не подходит для задания ограничений при выполнении сортировок наборов в отчете.

По аналогичным причинам для этих целей не подходит и контекст сессии. Напомним читателям, что в рамках открытой сессии также можно определить новое подпространство куба посредством оператора Create SubCube (рис. 5).

Рис. 5. Задание контекста сессии

Инструкция Create SubCube переопределяет пространство заданного куба на вложенный куб. Фактически она изменяет видимое пространство куба для всех последующих операций в рамках одной сессии. Поэтому о команде Create SubCube говорят, что она определяет контекст сессии (Session scope). Рис. 5 демонстрирует, как она работает на практике. Операция Create SubCube определяет срез данных, как и команда WHERE (в нашем примере мы опять оставили в подпространстве только плановые значения). После чего всем последующим операторам исходный куб представляется уже в новом, усеченном виде.

В частности, оператор Select в выражении 2 выполнится в контексте подкуба и, как показывает рис. 5, выдает тот же результат, что и команда, запущенная в глобальном контексте.

Поиск по сайту: