Унифицированная многомерная модель

При получении данных непосредственно из источника данных, например из базы данных планирования ресурсов предприятия (ERP), возникают различные проблемы.

• Часто содержимое таких источников данных сложно для понимания, так как эти данные разрабатывались для систем и разработчиков, а не для конечных пользователей.
• Интересующие пользователей данные, как правило, распределены по нескольким гетерогенным источникам данных. Даже если приходится работать только с различными реляционными базами данных, пользователь должен знать особенности каждой базы данных (например диалект используемого языка SQL). Хуже того, эти источники данных могут быть совершенно разных типов, включая не только реляционные базы данных, но также файлы и веб-службы.
• Тогда как многие источники данных ориентированы на поддержание большого объема детализации на уровне транзакций, для поддержания бизнес-решений часто необходимо использовать запросы, включающие сводку и статистические данные. При возрастании объемов данных время, необходимое для извлечения сводных значений для интерактивного анализа конечными пользователями, становится слишком большим.
• Бизнес-правила, как правило, не инкапсулированы в источниках данных. Пользователи должны выполнять собственную интерпретацию данных.

Роль унифицированной многомерной модели заключается в создании моста между пользователем и источниками данных. Модель UDM конструируется на одном или нескольких источниках данных. Пользователь запрашивает модель UDM при помощи различных клиентских средств, например Microsoft Excel.

Конечному пользователю это дает определенные преимущества, даже если модель UDM конструируется только как тонкий слой над источником данных: проще и легче можно понять модель данных; обеспечивается изоляция от гетерогенных серверных источников данных; повышается производительность при обработке запросов обобщенного типа. В некоторых сценариях простая модель UDM может конструироваться автоматически. Дополнительные вложения в создание унифицированной многомерной модели могут обеспечить дополнительные преимущества, вытекающие из богатства метаданных, которые может предоставить эта модель.

Преимущества использования унифицированной многомерной модели:

• значительно обогащает пользовательскую модель;
• обеспечивает высокую производительность запросов, поддерживая интерактивный анализ даже на очень больших объемах данных;
• использует в модели бизнес-правила для поддержки более богатого анализа;
• поддерживает «закрытие цикла»: пользователям позволяется действовать с данными, которые они видят.

Основная пользовательская модель

Рассмотрим пример, в котором конечному пользователю требуется сравнить продажи с квотами в различных временных интервалах.

Данные о продажах хранятся в главной базе данных «Sales and Inventory», в которой также содержится много других таблиц. Даже после идентификации соответствующих таблиц пользователь может обнаружить, что данные для одной сущности, например «Продукт», распределены по многим таблицам. Так как ссылочная целостность задается логикой приложения, между этими таблицами не определено никаких связей. Sales Quotas хранятся в базе данных другого приложения. Ни одна из баз данных не содержит бизнес-правил, например проверки, что для сравнения квот с фактическими продажами должна использоваться дата отправки заказа, а не другие даты, связанные с заказом (дата размещения заказа, дата оплаты счета, запланированная дата и т.п.).

Непосредственный доступ к источникам данных

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

К этому времени пользователем сделано очень много. Выполнены следующие действия.

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

Теперь пользователю нужно определить, какие следует использовать соединения («внешние» или «внутренние»),а также как выполнять группирование для обеспечения необходимых агрегатов.

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

SELECT Quotas.QuotaAmount, Quotas.EmployeeId, …
FROM OPENROWSET('SQLOLEDB','seattle1';
'Sales';'MyPass',
   'SELECT * FROM Forecasts.dbo.SalesQuota’ ) As Quotas

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

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

Доступ к источникам данных при помощи модели UDM

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

Интерфейс конструирования, показанный в этом примере, имеется в средствах разработки, предоставляемых Microsoft SQL Server 2005. Однако может использоваться любой интерфейс, поддерживающий модель UDM, в том числе клиентские средства, такие как Office Excel, веб-компоненты Office (OWC) или одно из многих средств составления отчетов и анализа данных.

Содержимое унифицированной многомерной модели представлено в виде дерева в левой части. В этом примере следует отметить следующее.

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

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

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

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

Эта модель определяет простое форматирование по умолчанию: например, использование символов валюты. Можно задать более подробное форматирование, включая условное форматирование, например отображение значений красным цветом, если они ниже определенного порога.

Одна модель поддерживает различные запросы. Например, результаты можно классифицировать по сотрудникам, перетащив атрибут из измерения «Сотрудник».

Расширение базовой модели

В предыдущих примерах демонстрировалось, как даже простая модель UDM может значительно упростить исследование данных. Однако при предоставлении пользователям доступа к данным необходимо учитывать и другие проблемы. Например:

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

В данном разделе рассматриваются некоторые из этих вопросов, и показывается, как модель UDM поддерживает расширение базовой модели для возможности дополнительного исследования данных.

Иерархии

Хотя объединение всех атрибутов сущности в измерение значительно упрощает модель для пользователей, между атрибутами имеются дополнительные связи, которые невозможно выразить простым списком. В предыдущем случае уровни Category, SubCategory и SKU определяют одну из иерархий возможной организации продукции. Модель UDM позволяет определять такие иерархии, т.к. пользователям часто нужно выполнить анализ, основанный на таких иерархиях. Например, после просмотра итоговых данных на уровне Category пользователь может детализировать просмотр на уровне SubCategory, а затем на самом низком уровне — SKU. Каждая иерархия представляет собой последовательность атрибутов, которую можно использовать в запросах для упрощения таких сценариях перехода на уровень выше или ниже.

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

Модель UDM ведет обработку подробностей процесса переходов между уровнями иерархии. Модель UDM обрабатывает такие подробности, как тот факт, что «Квоты» на уровне SubCategory не доступны, а имеются только на уровне Category.

Специальный вид иерархии, иерархия типа «родители-потомки», содержит элементы со сложными связями. На следующем рисунке измерение «Сотрудник» имеет иерархию «Сотрудники согласно структуре организации». Использование этой иерархии облегчает переходы по связи родитель-потомок и анализ свернутых значений на каждом уровне организации. Например, квота продаж для вице-президента отдела продаж Чарльза Маршалла (Charles Marshall) включает сумму квот всех его сотрудников плюс любые квоты, связанные непосредственно с ним.

Классификация

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

• Измерения, атрибуты и другие объекты могут быть помещены в семантически осмысленные категории, что дает возможность использовать объект клиентским средством более интеллектуальным образом. Например, атрибут может быть помечен, как URL-адрес. Отчет, содержащий этот атрибут, может далее включать переходы на основании значений URL-адреса. Другой атрибут может быть отмечен, как адрес электронной почты. В этом случае клиент, выполняющий отчет, может автоматически открывать новое сообщение электронной почты в ответ на некоторое действие пользователя.
• Меры, иерархии и другие объекты могут группироваться в папки, имеющие смысл для пользователя. Такое группирование позволяет средству составления отчетов отображать большое количество атрибутов в более осмысленном виде. Например, может быть группа атрибутов с названием «Демография клиентов».

Время

Данные о времени, как правило, записываются в базовые источники данных с помощью типов данных DataTime или Date. Хотя пользователи с опытом использования SQL или XPath могут выделить сведения о дате, необходимые для подведения итоговых данных по годам, даже для них может оказаться затруднительным составить запрос на основе других временных показателей, например «Показать продажи по дням недели» или «Разбить по финансовым годам, начиная с 1 июля».

Но в модели UDM имеются встроенные данные о времени, включая различные календари:

• обычный;
• финансовый;
• отчетный («445» и т.д.);
• производственный (13 периодов);
• ISO8601.

Следовательно, эта модель может включать измерение времени, предоставляющее набор атрибутов, определяющих подробные сведения каждого дня. На следующем рисунке показаны результаты просмотра объема продаж и квот за 2001 финансовый год. Чтобы получить их, пользователь просто перетаскивает соответствующий элемент из дерева в область фильтра. Модель UDM знает, как перевести это действие пользователя в диапазон дат. Кроме того, она понимает бизнес-правило, согласно которому в запрос должны включаться заказы, по которым в эти даты выполнены поставки, а не сроки исполнения заказов или заказы, поступившие в эти дни. Корректное соединение выполняется неявно моделью UDM.

Кроме того, модель UDM обеспечивает специальную поддержку ответов на обычные вопросы, связанные со временем, включая сравнение по периодам, например «сравнить показатели за месяц с показателями за тот же месяц прошлого года».

Переводы

В предыдущих примерах содержимое модели и данные отображались на одном и том же языке. Однако пользователям в разных странах часто необходимо просматривать метаданные на своем языке.

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

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

Перспективы

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

Модель UDM предоставляет подобные представления, называемые перспективами. В модели UDM может содержаться большое количество перспектив, каждая из которых представляет определенное подмножество модели (меры, измерения, атрибуты и т. д.), соответствующее отдельной группе пользователей. Каждую перспективу можно связать с пользовательскими ролями безопасности, определяющими пользователей, которым разрешен просмотр этой перспективы.

Например, перспективу «Запасы Сиэтла» можно определить как перспективу, которая включает только меры из группы мер «Запасы», скрывает иерархию «Хранилища по местоположению» и по умолчанию задает город Сиэтл.

Семантика атрибута

Модель UDM предоставляет дополнительную семантику для атрибутов. Эта семантика направлена на облегчение восприятия данных. Далее представлены некоторые примеры семантики, которая может быть применима к атрибутам.

• Имена в сравнении с ключами. При просмотре реляционной базы данных не очевидно, что столбец EmployeeID представляет собой не имеющий смысла уникальный, созданный системой ключ. Модель UDM позволяет всем атрибутам таблицы Employee иметь ключ (уникальный идентификатор EmployeeID) и имя (например, объединение имени и фамилии — FirstName и LastName). При этом запрос, например «показать сотрудников», корректно выделяет сотрудников с одинаковым именем по их уникальным идентификаторам и выводит пользователю осмысленные имена.
• Порядок. Значения атрибутов часто должны отображаться в некотором фиксированном порядке, не являющемся алфавитным или числовым порядком. Для удовлетворения этого требования модель UDM позволяет определить порядок по умолчанию. Например.
  • Дни недели отображаются как «Воскресенье», «Понедельник», «Вторник» и т. д.
  • Приоритеты отображаются в порядке «Высокий», «Средний» и «Низкий».
• Дискретизация. Для числовых атрибутов иногда полезно отображать каждое отдельное значение атрибута. Например, просмотр продаж со всеми различными ценами на продукцию (9,97, 10,05, 10,10 рублей и т.д.) имеет гораздо меньший смысл, чем просмотр продаж для диапазона цен ( <10, 10 — 15…). Модель UDM позволяет разделить атрибуты на такие диапазоны при помощи различных критериев.

Ключевые индикаторы производительности

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

Для каждой метрики производительности ключевой индикатор производительности в модели UDM определяет до четырех выражений.

• Действительное значение
• Целевое значение
• Состояние: нормализованное значение в диапазоне от -1 до 1, представляющее отношение действительного и целевого значений (-1 — «очень плохо», 1 — «очень хорошо»).
• Тенденция: нормализованное значение в диапазоне от -1 до 1, представляющее тенденцию во времени (-1 — «становится гораздо хуже», 1 — «становится гораздо лучше»).

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

Производительность

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

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

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

Аналитика

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

Основные функции аналитики

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

Метод статистической обработки можно определить с помощью различных схем.

• Можно использовать простые статистические функции, такие как Sum, Count, Distinct Count, Max или Min.
• Статистическая обработка может быть определена как полуаддитивная. Это означает, что простая функция, например Sum, может использоваться для всех измерений, за исключением измерения «Время», для которого используется «Последний период». Например, хотя «Уровень запасов» может суммироваться от «Продукта» до «Категории продукта», уровень запасов за месяц не является суммой уровня запасов за каждый день месяца. Уровень запасов за месяц является уровнем запасов на последний день месяца.
• Статистическое вычисление может основываться на типе счета, например «Доходы» относительно «Расходы».
• Статистическое вычисление можно настроить в соответствии с особыми требованиями.

Модель UDM также может включать вычисляемые элементы. Такие элементы не связаны напрямую с источником данных, а являются их производными. Например, можно определить вычисляемый элемент «Разность» для вычисления разности между «Продажами» и «Квотой».

Аналогично: модель UDM может определять наборы сущностей, интересующих пользователя: например десять клиентов с наибольшим объемом продаж или наиболее важные виды продукции. Такие наборы можно использовать для ограничения запросов к отдельным наборам сущностей.

Дополнительный анализ

Иногда для пользователей необходимы гораздо более сложные вычисления, чем в представленном ранее примере «Дисперсия». Ниже приведены некоторые примеры сложных вычислений.

• Отображение изменения среднего значения за каждый период времени.
• Сравнение роста в годовом исчислении за этот период и за тот же период прошлого года.
• Преобразование показателей продаж в исходную валюту с помощью среднего за день курс обмена на момент продажи, если продажи отображаются в основной валюте.
• Расчет планируемых продаж по категориям на следующий год, с учетом планируемого увеличения продаж на 10 % по сравнению с текущим годом, и последующее размещение бюджета по каждому продукту на основе относительных средних продаж за последние три года.

Модель UDM является удобной для определения таких расчетов. Она подобна многомерной электронной таблице, в которой значение в ячейке может рассчитываться на основании значений в других ячейках. Но даже такое сравнение неадекватно описывает возможности вычислений в унифицированной многомерной модели. В частности, значение в ячейке можно рассчитывать не только по значению в другой ячейке, но и по значению в этой ячейке, которое должно быть. Следовательно, могут поддерживаться системы уравнений. Например, прибыль рассчитывается, как доход минус расход, а включенные в расходы премии рассчитываются по прибыли.

Кроме того, для поддержки мощного языка многомерных выражений, специально разработанного для таких вычислений, модель UDM поддерживает интеграцию с Microsoft .NET. Эта интеграция позволяет писать хранимые процедуры и функции на любом, совместимом с .NET, языке, например на C#.NET или Visual Basic .NET. Затем эта хранимая процедура или функция может быть вызвана из многомерных выражений и использована в вычислениях.

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

Интеграция с интеллектуальным анализом данных

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

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

Обеспечение возможности производить действия над данными

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

• «Какие конкретно продажи привели к такому значению?»
• «Квота слишком мала, и ее необходимо увеличить.»
• «Это странно. Нужно добавить к этому значению комментарий.»
• «Что делается для продвижения товаров на нашем веб-узле?»

Простого представления пользователям данных в понятной форме не достаточно. Необходимо также предоставить пользователям возможность выполнения действий.

В унифицированной многомерной модели это поддерживается двумя способами:

• разрешение записи изменений в данные;
• разрешение действий, связанных с данными.

Обратная запись

Унифицированная многомерная модель не ограничена статусом «только для чтения». Данные в модели можно обновлять. Обновления для мер могут храниться отдельно от исходных значений в виде приращений.

Кроме того, можно обновлять результаты суммирования. Рассмотрим, например, сценарий «Составление бюджета». Запланированный объем может быть известен на более подробном уровне (например, по группам и счетам), но изначально известны значения только на более общем уровне (по отделам и типам счетов).

Действия

Унифицированная многомерная модель поддерживает действия в виде ссылок между данными и действиями на основе данных. Основные виды действий:

• URL-адрес. Переход к заданному URL-адресу. Этот тип действий поддерживает направление пользователя на некоторый URL-адрес для получения дополнительных данных, а также направление пользователя к некоторому веб-приложению, позволяющему выполнить новую задачу. Например:
  • для получения сведений о продукте можно перейти на веб-узел компании с описанием этого продукта;
  • для получения сведений о продукте и оптовых складах можно перейти к веб-приложению управления запасами, передать в качестве параметров данные о продукте и оптовых складах и увеличить уровень резервных запасов.
• Отчет. Выполнение отчетов. Например, для данного продукта можно выполнить параметризованный отчет с описанием продукта и текущего состояния заказов.
• Детализация. Детализация до минимально возможного уровня. Например, пользователь, проверяющий общие продажи по продуктам и потребителям, может просмотреть все транзакции продаж.

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

Хотя действия определяются в составе унифицированной многомерной модели, именно клиентское приложение ответственно за извлечение данных о применимых действиях и предложение их пользователям, а также за дальнейший вызов действия.

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

Доступ к унифицированной многомерной модели можно контролировать. Ключевые свойства безопасности перечислены ниже.

• Унифицированная многомерная модель обеспечивает ролевую безопасность. Можно определить роли, разрешения, предоставленные этим ролям, и пользователей, входящих в состав каждой роли. Фактические разрешения пользователя представляют собой разрешение роли, к которой он относится. Разрешения для роли также могут включать строгие запреты, удаляющие права независимо от других ролей, к которым может относиться пользователь.
• Административные разрешения (например, на изменение унифицированной многомерной модели) могут предоставляться независимо от разрешений на доступ к данным. Кроме того, могут быть предоставлены отдельные разрешения на считывание метаданных объекта, а также на доступ для чтения/записи данных.
• Данные могут быть защищены с уровнями гранулярности вплоть до отдельных ячеек. Например, пользователям можно ограничить возможность просматривать продажи продукта «Устройство» клиенту «ACME». Защита может быть также условной: например, роли можно разрешить просмотр общей заработной платы отдела, только если в этом отделе более пяти сотрудников.
• Разрешения могут определять, следует ли использовать визуальное представление общего значения, когда это значение отображается только для членов более низкого уровня с соответствующими разрешениями. Доступ к ячейке может быть также производным. Это означает, что ячейки, формируемые из других ячеек, видны, если только все другие ячейки также видны. Например, если прибыль формируется на основании доходов и затрат, пользователи могут видеть прибыль только для продуктов, на которые они имеют разрешение на просмотр и доходов, и затрат.

См. также

Другие ресурсы

Основные понятия служб Analysis Services

Справка и поддержка

Получение помощи по SQL Server 2005