Лекции ММПР

Полубояров В.В.
Использование MS SQL Server Analysis Services 2008 для построения

хранилищ данных
Лекции
1. Введение в основы OLAP
1.1. Хранилища данных
1.1.1. Понятие и архитектура системы поддержки принятия решений

К настоящему времени во многих организациях накоплены значительные объемы данных, на основе
которых имеется возможность решения разнообразных аналитических и управленческих задач. Проблемы
хранения и обработки аналитической информации становятся все более актуальными и привлекают
внимание специалистов и фирм, работающих в области информационных технологий, что привело к
формированию полноценного рынка технологий бизнес-анализа.
В идеале работа аналитиков и руководителей различных уровней должна быть организована так, чтобы
они могли иметь доступ ко всей интересующей их информации и пользоваться удобными и простыми
средствами представления и работы с этой информацией. Именно на достижение этих целей и
направлены информационные технологии, объединяющиеся под общим названием хранилищ данных и
бизнес-анализа.
В соответствии с определением Gartner, бизнес-анализ (BI, Business Intelligence) – это категория

приложений и технологий для сбора, хранения, анализа и публикации данных, позволяющая
корпоративным пользователям принимать лучшие решения. В русскоязычной терминологии подобные
системы называются также системами поддержки принятия решений (СППР).
Подсистема
информационно-
поискового
анализа
(СУБД,SQL)
Подсистема хранения оперативного
Подсистема ввода
информации (СУБД и/или анализа (OLAP)
(СУБД – OLTP)
ХД)
Оператор Подсистема Аналитик

интеллектуально
го анализа (Data
Mining)
Подсистема анализа
Рисунок 1. Архитектура СППР

1
Сбор и хранение информации, а также решение задач информационно-поискового запроса эффективно
реализуются средствами систем управления базами данных (СУБД). В OLTP (Online Analytical Processing)-
подсистемах реализуется транзакционная обработка данных. Непосредственно OLTP-системы не подходят
для полноценного анализа информации в силу противоречивости требований, предъявляемых к OLTP-
системам и СППР.
Для предоставления необходимой для принятия решений информации обычно приходится собирать
данные из нескольких транзакционных баз данных различной структуры и содержания. Основная
проблема при этом состоит в несогласованности и противоречивости этих баз-источников, отсутствии
единого логического взгляда на корпоративные данные.
Поэтому для объединения в одной системе OLTP и СППР для реализации подсистемы хранения
используются концепция хранилищ данных (ХД). В основе концепции ХД лежит идея разделения данных,
используемых для оперативной обработки и для решения задач анализа, что позволяет оптимизировать
структуры хранения. ХД позволяет интегрировать ранее разъединенные детализированные данные,
содержащиеся в исторических архивах, накапливаемых в традиционных OLTP-системах, поступающих из
внешних источников, в единую базу данных, осуществляя их предварительное согласование и, возможно,
агрегацию.
Подсистема анализа может быть построена на основе:
1. подсистемы информационно-поискового анализа на базе реляционных СУБД и статических

запросов с использованием языка SQL;
2. подсистемы оперативного анализа. Для реализации таких подсистем применяется технология

оперативной аналитической обработки данных OLAP, использующая концепцию многомерного
представления данных;
3. подсистемы интеллектуального анализа, реализующие методы и алгоритмы Data Mining.
1.1.2. Понятие хранилища данных

Технология ХД предназначена для хранения и анализа больших объемов данных с целью дальнейшего
обнаружения в них скрытых закономерностей и, наряду с технологией Data Mining, входит в понятие
«предсказательная аналитика». Data Mining, в свою очередь, изучает процесс нахождения новых,
действительных и потенциально полезных знаний в базах данных.
ХД – предметно-ориентированный, интегрированный, редко меняющийся, поддерживающий хронологию

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

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

(OLTP) источник данных
Оператор Аналитические
запросы
Подсистема ввода Оперативный Хранилище Подсистема

(OLTP) источник данных данных анализа
Оператор Аналитик
Данные

Оператор Подсистема
хранения информации
Внешний источник
данных
Рисунок 2. Структура СППР с физическим ХД
Избыточность информации можно свести к нулю, используя виртуальное ХД. В такой системе данные из
OLTP-системы не копируются в единое хранилище. Они извлекаются, преобразуются и интегрируются
непосредственно при выполнении аналитических запросов в режиме реального времени. Фактически
такие запросы напрямую передаются к OLTP-системе.
Достоинства виртуального ХД:
 минимизация объема хранимых данных;
 работа с текущими, актуальными данными.
Недостатки виртуального ХД:
 более высокое, по сравнению с физическим ХД время обработки запросов;
 необходимость постоянной доступности всех OLTP-источников;
 снижение быстродействия OLTP-систем;
 OLTP-системы не ориентированы на хранение данных за длительный период времени, по мере

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

Основная проблематика при создании ХД заключается в следующем:
3
1. интеграция разнородных данных. Данные в ХД поступают из разнородных OLTP-систем, которые
физически могу быть расположены на различных узлах сети. При проектировании и разработке ХД
необходимо решать задачу интеграции различных программных платформ хранения;
2. эффективное хранение и обработка больших объемов данных. Построение ХД предполагает

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

необходимы метаданные, описывающие структуру хранящихся в ХД данных, а также инструменты их
визуализации;
4. обеспечение информационной безопасности ХД. Сводная информация о деятельности компании,

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

Сокращение затрат на проектирование и разработку ХД может быть достигнуто путем создания витрин
данных (ВД). ВД – это упрощенный вариант ХД, содержащий только тематически объединенные данные
(Рисунок 3).
Аналитические
запросы
Витрина данных Подсистема
Данные
анализа
Оператор
Аналитик

Оператор запросы
Витрина данных
анализа
Данные
(OLTP) источник данных Аналитик
данных
Рисунок 3. Структура СППР с самостоятельными ВД
ВД содержит данные, ориентированные на конкретного пользователя, существенно меньше по объему, и

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

ситуация, когда источником информации для пополнения ВД служат непосредственно OLTP-системы.
Такие ВД, получившие название независимых, как правило, рассматриваются как временное решение,
позволяющее достаточно быстро и с небольшими затратами решить наиболее важные задачи, оценить
преимущества нового подхода, сформулировать некоторые рекомендации для более масштабного проекта
разработки общего ХД.
Возможно также совмещение ХД и ВД в рамках одной СППР. ХД в этом случае представляет собой единый
источник данных для всей предметной области, а ВД являются подмножествами данных из хранилища,
организованными для представления информации по тематическим разделам данной области. В том
случае, если пользователю, для которого создавалась ВД, содержащихся в ней данных недостаточно, то он
может обратиться к ХД (Рисунок 4).
запросы
Витрина данных Подсистема
Данные
анализа
Оператор
Аналитик
Подсистема ввода Оперативный Хранилище

(OLTP) источник данных данных
Оператор запросы
Витрина данных
анализа
Данные
(OLTP) источник данных Аналитик
данных
Рисунок 4. Структура СППР с ХД и ВД
Достоинствами такого решения являются простота создания и наполнения ВД, поскольку наполнение
происходит из единого стандартизированного источника очищенных данных – из ХД, простота расширения
за счет добавления новых ВД, а также снижение нагрузки на основное ХД.
Недостатки заключаются в избыточности, так как данные хранятся и в ХД, и в ВД, а также дополнительные
затраты на разработку СППР с ХД и ВД.
1.2. Понятие и модель данных OLAP
1.2.1. Понятие OLAP

OLAP (Online Analytical Processing) – технология оперативной аналитической обработки данных,
использующая методы и средства для сбора, хранения и анализа многомерных данных в целях поддержки
процессов принятия решений.
Основное назначение OLAP-систем – поддержка аналитической деятельности, произвольных запросов

пользователей – аналитиков. Цель OLAP-анализа – проверка возникающих гипотез.
5
1.2.2. Категории данных в ХД
Все данные в ХД делятся на три категории (Рисунок 5):
обобщения
Поток
Обратный Агрегирован-
поток ные данные
Оператор Аналитические
запросы
Подсистема ввода Оперативный Входной Детальные Выходной Подсистема

поток данные поток анализа
метаданных
Аналитик
Архивный
Оператор
поток
Поток
Данные
Подсистема ввода Оперативный Репозиторий Архивные

(OLTP) источник данных метаданных данные
Хранилище данных
данных
Рисунок 5. Архитектура ХД
1. детальные данные – данные, переносимые непосредственно из OLTP-подсистем. Соответствуют

элементарным событиям, фиксируемым в OLTP-системах. Подразделяются на:
 измерения – наборы данных, необходимые для описания событий (товар, продавец,

покупатель, магазин, … );
 факты – данные, отражающие сущность события (количество проданного товара, сумма

продаж, …);
2. агрегированные (обобщенные) данные – данные, получаемые на основании детальных путем

суммирования по определенным измерениям;
3. метаданные – данные о данных, содержащихся в ХД. Могут описывать:
 объекты предметной области, информация о которых содержится в ХД;
 категории пользователей, использующих данные в ХД;
 места и способы хранения данных;
 действия, выполняемые над данными;
 время выполнения различных действий над данными;
 причины выполнения различных действий над данными.
1.2.3. Информационные потоки в ХД

Данные в ХД образуют следующие информационные потоки (Рисунок 5):
6
 входной поток – образуется данными, копируемыми из OLTP-систем в ХД; данные при этом часто
очищаются и обогащаются путем добавления новых атрибутов;
 поток обобщения – образуется агрегированием детальных данных и их сохранением в ХД;
 архивный поток – образуется перемещением детальных данных, количество обращений к которым

снизилось;
 поток метаданных – образуется потоком информации о данных в репозиторий данных;
 выходной поток – образуется данными, извлекаемыми пользователями;
 обратный поток – образуется очищенными данными, записываемыми обратно в OLTP-системы.
1.3. Структура OLAP-куба

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

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

представления данных в виде многомерной модели – гиперкуба (Рисунок 6), или OLAP-куба.
Измерение
Измерение
Мера
Измерение
Рисунок 6. Гиперкуб
Оси куба представляют собой измерения, по которым откладывают параметры, относящиеся к

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

регионам. В этом случае куб становится трехмерным;
2. усложнение содержимого ячейки - например, нас может интересовать не только уровень продаж,
но и чистая прибыль или остаток на складе. В этом случае в ячейке будет несколько значений;
3. введение иерархии в пределах одного измерения - общее понятие «время» связано с иерархией
значений: год состоит из кварталов, квартал из месяцев и т.д.
1.4. Иерархия измерений OLAP-кубов

Каждое из измерений OLAP-куба может быть представлено в виде иерархической структуры. Например,
измерение «Регион» может иметь следующие уровни иерархии: «страна – федеральный округ – область –
город – район».
Некоторые измерения могут иметь несколько уровней иерархического представления, например

измерение «время» - представление «год – квартал – месяц - день» и представление «год – неделя –
день».
Точно так же в рамках измерения «География» можно ввести уровни «Страна», «Регион», «Область» и
«Город».
1.5. Операции, выполняемые над гиперкубом

Над гиперкубом могут выполняться следующие операции:
1. Срез (Рисунок 7) – формируется подмножество многомерного массива данных, соответствующее

единственному значению одного или нескольких элементов измерений, не входящих в это
подмножество.
Рисунок 7. Срез
8
2. Вращение (Рисунок 8) – изменение расположения измерений, представленных в отчете или на
отображаемой странице. Например, операция вращения может заключаться в перестановке
местами строк и столбцов таблицы. Кроме того, вращением куба данных является перемещение
внетабличных измерений на место измерений, представленных на отображаемой странице, и
наоборот.
Измерение 2
Рисунок 8. Вращение
Консолидация (Рисунок 9) и детализация (Рисунок 10) – операции, которые определяют переход вверх по
направлению от детального представления данных к агрегированному и наоборот, соответственно.
Направление детализации (обобщения) может быть задано как по иерархии отдельных измерений, так и
согласно прочим отношениям, установленным в рамках измерений или между измерениями.
Рисунок 9. Консолидация
9
Рисунок 10. Детализация
Например, если при анализе данных о продажах в Северной Америке выполнить операцию детализации
для измерения «Регион», то будут отображены такие элементы, как «Канада», «Восточные штаты США» и
«Западные штаты США». В результате дальнейшей детализации элемента «Канада» будут отображены
элементы «Торонто», «Ванкувер» и т.д.
1.6. Таблица фактов

Таблица фактов — является основной таблицей хранилища данных. Как правило, она содержит сведения
об объектах или событиях, совокупность которых будет в дальнейшем анализироваться. Обычно говорят о
четырех наиболее часто встречающихся типах фактов. К ним относятся:
1. факты, связанные с транзакциями (Transaction facts). Они основаны на отдельных событиях

(типичными примерами которых являются телефонный звонок или снятие денег со счета с
помощью банкомата);
2. факты, связанные с «моментальными снимками» (Snapshot facts). Основаны на состоянии объекта

(например, банковского счета) в определенные моменты времени, например на конец дня или
месяца. Типичными примерами таких фактов являются объем продаж за день или дневная
выручка;
3. факты, связанные с элементами документа (Line-item facts). Основаны на том или ином документе
(например, счете за товар или услуги) и содержат подробную информацию об элементах этого
документа (например, количестве, цене, проценте скидки);
4. факты, связанные с событиями или состоянием объекта (Event or state facts). Представляют
возникновение события без подробностей о нем (например, просто факт продажи или факт
отсутствия таковой без иных подробностей).
Таблица фактов, как правило, содержит уникальный составной ключ, объединяющий первичные ключи
таблиц измерений. Чаще всего это целочисленные значения либо значения типа «дата/время» — ведь
таблица фактов может содержать сотни тысяч или даже миллионы записей, и хранить в ней
повторяющиеся текстовые описания, как правило, невыгодно — лучше поместить их в меньшие по объему
таблицы измерений. При этом как ключевые, так и некоторые неключевые поля должны соответствовать
будущим измерениям OLAP-куба. Помимо этого таблица фактов содержит одно или несколько числовых
полей, на основании которых в дальнейшем будут получены агрегатные данные.
10
Для многомерного анализа пригодны таблицы фактов, содержащие как можно более подробные данные
(то есть соответствующие членам нижних уровней иерархии соответствующих измерений). В данном
случае предпочтительнее взять за основу факты продажи товаров отдельным заказчикам, а не суммы
продаж для разных стран — последние все равно будут вычислены OLAP-средством.
В таблице фактов нет никаких сведений о том, как группировать записи при вычислении агрегатных
данных. Например, в ней есть идентификаторы продуктов или клиентов, но отсутствует информация о том,
к какой категории относится данный продукт или в каком городе находится данный клиент. Эти сведения, в
дальнейшем используемые для построения иерархий в измерениях куба, содержатся в таблицах
измерений.
Пример фрагмента схемы данных хранилища данных AdventureWorks приведен на Рисунок 11.
Рисунок 11. Фрагмент схемы данных хранилища данных AdventureWorks
В приведенной схеме данных таблица FactInternetSales является таблицей фактов и содержит сведения о
продажах через Интернет в разрезе товаров, дат, валют, рекламы, клиентов и территории. Перечень
столбцов таблицы и их типов данных приведен на Рисунок 12.
11
Рисунок 12. Столбцы таблицы FactInternetSales и их типы данных
1.7. Таблицы измерений

Таблицы измерений содержат неизменяемые либо редко изменяемые данные. В подавляющем
большинстве случаев эти данные представляют собой по одной записи для каждого члена нижнего уровня
иерархии в измерении. Таблицы измерений также содержат как минимум одно описательное поле
(обычно с именем члена измерения) и, как правило, целочисленное ключевое поле (обычно это
суррогатный ключ) для однозначной идентификации члена измерения. Если будущее измерение,
основанное на данной таблице измерений, содержит иерархию, то таблица измерений также может
содержать поля, указывающие на «родителя» данного члена в этой иерархии. Нередко (но не всегда)
таблица измерений может содержать и поля, указывающие на «прародителей», и иных «предков» в
данной иерархии (это обычно характерно для сбалансированных иерархий), а также дополнительные
атрибуты членов измерений, содержавшиеся в исходной оперативной базе данных (например, адреса и
телефоны клиентов).
Каждая таблица измерений должна находиться в отношении «один ко многим» с таблицей фактов.
Отметим, что скорость роста таблиц измерений должна быть незначительной по сравнению со скоростью
роста таблицы фактов; например, добавление новой записи в таблицу измерений, характеризующую
товары, производится только при появлении нового товара, не продававшегося ранее.
12
Так, в приведенном выше примере одной из таблиц измерений является таблица DimCustomer,
содержащая редко изменяемые сведения о клиентах. Состав ее столбцов и их типы данных приведены на
Рисунок 13.
Рисунок 13. Состав столбцов таблицы измерений DimCusromer и их типы данных
1.8. Архитектура OLAP-систем

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

ХД. Эти стандарты опираются на современные исследования и общемировую практику создания хранилищ
данных и аналитических систем.
В общем виде архитектура корпоративной OLAP-системы описывается схемой с тремя выделенными

слоями (Рисунок 14):
13
Произвольные Многомерный
Отчеты Data Mining
запросы анализ
Доступ: «клиент-сервер» или web-интерфейс Анализ данных
Витрина Витрина
данных данных
Хранение
данных
Хранилище
данных
Извлечение,
Извлечение, преобразование и загрузка преобразование
и загрузка
данных
Источники
данных
Рисунок 14. Архитектура корпоративной OLAP-системы
 извлечение, преобразование и загрузка данных;
 хранение данных;
 анализ данных.
14
Данные поступают из различных внутренних OLTP-систем, от подчиненных структур, от внешних
организаций в соответствии с установленным регламентом, формами и макетами отчетности. Вся эта
информация проверяется, согласуется, преобразуется и помещается в хранилище и витрины данных. После
этого пользователи с помощью специализированных инструментальных средств получают необходимую
им информацию для построения различных табличных и графических представлений, прогнозирования,
моделирования и выполнения других аналитических задач.
1.8.1. Слой извлечения, преобразования и загрузки данных

С организационной точки зрения, данный слой включает подразделения и структуры организации всех
уровней, поддерживающие базы данных оперативного доступа. Он представляет собой низовой уровень
генерации информации, уровень внутренних и внешних информационных источников, вырабатывающих
“сырую” информацию. Эта информация является рабочей для повседневной деятельности различных
подразделений, которые ее вырабатывают и используют.
С системно-технической точки зрения данный слой представлен ЛВС всех подразделений всех уровней, к
которым подключены специализированные технические комплексы, хранящие информацию, чаще всего
реализованные в виде реляционных СУБД.
Из источников данных информация перемещается на основе некоторого регламента в централизованное

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

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

позволяющими:
1. извлекать данные из различных баз данных, текстовых файлов;
2. выполнять различные типы согласования и очистки данных;
3. преобразовывать данные при перемещении их от источников к хранилищу;
4. загружать согласованные и «очищенные» данные в структуры хранилища.

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

задачи. Цель ХД – обеспечить целостность и поддерживать хронологию всевозможных корпоративных
данных, и с этой точки зрения оно нейтрально по отношению к приложениям. В связи с этим в
большинстве случаев для выполнения определенного комплекса функционально замкнутых аналитических
задач рационально создавать витрины данных, в основе которых может быть как многомерная, так и
реляционная модель данных. По существу витрина представляет собой относительно небольшое, но что
самое важное, функционально-ориентированное ХД, в котором информация хранится специальным
образом, оптимизированным с точки зрения решения конкретных аналитических задач некоторого
подразделения или группы аналитиков.
ХД чаще всего реализуется в виде реляционной БД, работающей под управлением достаточно мощной
реляционной СУБД. Такая СУБД должна поддерживать эффективную работу с терабайтными объемами
информации, иметь развитые средства ограничения доступа, обеспечивать повышенный уровень
надежности и безопасности, соответствовать необходимым требованиям по восстановлению и архивации.
1.8.3. Слой анализа данных

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

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

использованием какой-то одной технологи. В настоящее время принято различать следующие основные
вида аналитической деятельности:
1. стандартная отчетность;
2. нерегламентированные запросы;
3. многомерный анализ (OLAP);
4. извлечение знаний (data mining).
Каждая из этих технологий имеет свои особенности, определенный набор типовых задач и должна
поддерживаться специализированной инструментальной средой.
1.9. Клиентские OLAP-средства

Клиентские OLAP-средства представляют собой приложения, осуществляющие вычисление агрегатных
данных (сумм, средних величин, максимальных или минимальных значений) и их отображение, при этом
сами агрегатные данные содержатся в кэше внутри адресного пространства такого OLAP-средства.
16
Если исходные данные содержатся в настольной СУБД, вычисление агрегатных данных производится
самим OLAP-средством. Если же источник исходных данных — серверная СУБД, многие из клиентских
OLAP-средств посылают на сервер SQL-запросы, содержащие оператор GROUP BY, и в результате получают
агрегатные данные, вычисленные на сервере.
Как правило, OLAP-функциональность реализована в средствах статистической обработки данных (из

продуктов этого класса на российском рынке широко распространены продукты компаний StatSoft и SPSS)
и в некоторых электронных таблицах. В частности, средствами многомерного анализа обладает Microsoft
Excel. С помощью этого продукта можно создать и сохранить в виде файла небольшой локальный
многомерный OLAP-куб и отобразить его двух- или трехмерные сечения.
Надстройки к пакету приложений Microsoft Office для извлечения и обработки данных представляют собой
ряд функций, обеспечивающих доступ к возможностям извлечения и обработки данных из приложений
Microsoft Office, и тем самым позволяющих осуществлять прогностический анализ на локальном
компьютере. Благодаря тому, что встроенные в службы платформы Microsoft SQL Server алгоритмы
извлечения и обработки данных доступны из среды приложений Microsoft Office, бизнес-пользователи
могут легко извлекать ценную информацию из сложных наборов данных всего несколькими щелчками
мыши. Надстройки к пакету приложений Office для извлечения и обработки данных дают конечным
пользователям возможность выполнять анализ непосредственно в приложениях Microsoft Excel и Microsoft
Visio.
В состав Microsoft Office 2007 входят три отдельных OLAP-компонента:
1. клиент извлечения и обработки данных для Excel позволяет создавать проекты извлечения и
обработки данных на базе служб SSAS и управлять ими из Excel 2007;
2. средства анализа таблиц для приложения Excel позволяют использовать встроенные в службы SSAS
функции извлечения и обработки информации для анализа данных, хранящихся в таблицах Excel;
3. шаблоны извлечения и обработки данных для приложения Visio позволяют визуализировать

деревья решений, деревья регрессии, кластерные диаграммы и сети зависимостей на диаграммах
Visio.
На Рисунок 15 изображена сводная таблица Excel, используемая для доступа клиентов к данным служб
аналитики.
17
Рисунок 15. Сводная таблица Excel 2007
С помощью приложения Microsoft Office Visio можно аннотировать, дополнять и отображать графические
представления результатов извлечения и обработки данных. Платформа SQL Server 2008 в сочетании с
приложением Visio 2007 позволяет:
1. визуализировать деревья решений, деревья регрессии, кластерные диаграммы и сети

зависимостей;
2. сохранять модели извлечения и обработки данных в виде документов Visio, внедренных в другие
документы приложений Office или сохраненных в виде веб-страниц.
Клиентские OLAP-средства применяются, как правило, при малом числе измерений (обычно
рекомендуется не более шести) и небольшом разнообразии значений этих параметров, — ведь
полученные агрегатные данные должны умещаться в адресном пространстве подобного средства, а их
количество растет экспоненциально при увеличении числа измерений. Поэтому даже самые примитивные
клиентские OLAP-средства, как правило, позволяют произвести предварительный подсчет объема
требуемой оперативной памяти для создания в ней многомерного куба.
1.10. Серверные OLAP-средства

Преимущества применения серверных OLAP-средств по сравнению с клиентскими OLAP-средствами
сходны с преимуществами применения серверных СУБД по сравнению с настольными: в случае
применения серверных средств вычисление и хранение агрегатных данных происходят на сервере, а
клиентское приложение получает лишь результаты запросов к ним, что позволяет в общем случае снизить
сетевой трафик, время выполнения запросов и требования к ресурсам, потребляемым клиентским
приложением. Отметим, что средства анализа и обработки данных масштаба предприятия, как правило,
18
базируются именно на серверных OLAP-средствах, например, таких как Oracle Database Server и Microsoft
SQL Server.
Некоторые клиентские OLAP-средства (в частности, Microsoft Excel) позволяют обращаться к серверным

OLAP-хранилищам, выступая в этом случае в роли клиентских приложений, выполняющих подобные
запросы. Помимо этого имеется немало продуктов, представляющих собой клиентские приложения к
OLAP-средствам различных производителей.
1.10.1. Oracle Business Intellegence

У компании Oracle существует несколько линеек продуктов класса Business Intelligence. Основная и самая
большая называется Oracle Business Intelligence Enterprise Edition PLUS.
Oracle Business Intelligence (BI) – это самый обширный комплекс технологий и приложений для обеспечения
представления внутренней организации бизнеса, включающий ведущие BI-приложения, технологические
BI-платформы и хранилища данных.
В BI-платформы Orecle основе лежит аналитический сервер Oracle BI Server EE.
Этот сервер хранит:
1. описание различных источников данных. В качестве источников данных могут быть практически
любые СУБД, как реляционные (Oracle, Microsoft SQL Server, Microsoft Analysis Services, IBM DB2), так
и многомерные (MS AS, Hyperion Essbase или SAP BW), а также ODBC источники, текстовые файлы и
т.д.
2. в репозитории хранится бизнес-модель данных, построенная над физическими источниками

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

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

вычисляет, какие данные нужны, в каком физическом источнике они находятся и делает запрос к
соответствующему источнику или источникам (один запрос может возвращать данные из нескольких
разных источников одновременно), после чего, сервер собирает, при необходимости агрегирует или
производит дополнительные вычисления и возвращает результат.
С другой стороны, BI Server сам виден в сети как ODBC источник и позволяет делать к себе запросы с
помощью любого инструмента или программы, работающей с ODBC. При этом этот сервер остается
виртуальным, так как данные на нем не хранятся, а собираются в момент запроса. Аналитический сервер
позволяет использовать хранилище как источник данных, одновременно с OLTP системами.
Инструментальные средства корпорации Oracle обеспечивают полное интегрированное решение для

создания ХД и эффективного использования накопленной в нем информации.
19
Общий перечень продуктов Oracle, необходимых для реализации технологии хранилищ данных и
аналитических приложений, приводится в Таблица 1 соответствии с выделенными ранее уровнями
(Рисунок 14).
Таблица 1. Продукты Oracle для OLAP и бизнес-анализа
Тип средств Продукт Комментарий
Извлечение, Oracle Warehouse Builder Поддержка процессов извлечения,

преобразование и преобразования и загрузки в хранилище
ETL-средства Oracle
загрузка
Database
Oracle WorkFlow
Хранение данных Oracle Database СУБД для ХД и реляционных ВД
Oracle OLAP Option Опция СУБД для многомерных ВД
Анализ данных Reporting and Publishing, Регламентированная отчетность

Reporting Workbench
Oracle BI Suite
Enterprise Edition Answers Инструмент выполнения произвольных
запросов и анализа с web-интерфейсом. При
этом пользователи работают с логическим
представлением информации из различных
источников данных.
Interactive Dashboard Интерактивные информационные панели с

широкими функциональными возможностями,
построенные в Web-архитектуре и
отображающие персонализированную
информацию
Delivers Уведомления в реальном времени, с помощью

которых возможно распространять по
различным каналам уведомляющие сообщения
при возникновения того или иного события
Office Plug-In Интеграция с MS Office
Disconnected Analysis Анализ данных в автономном режиме
Business Intelligence Server Сервер бизнес-анализа, интегрирующий

данные из множества реляционных,
неструктурированных, OLAP и готовых
приложений-источников
В качестве среды хранения информации в реляционных ХД и ВД используется сервер Oracle Database.

Центральным инструментальным средством создания хранилищ и витрин является Oracle Warehouse
Builder, построенный на базе современной архитектуры Common Warehouse Metadata. Он предназначен
для описания структуры ХД и ВД, проектирования и создания процедур извлечения, согласования и
загрузки данных, а также генерации метаданных для средств доступа, например таких, как Discoverer.
20
Проектировать хранилище можно и с помощью стандартного инструмента Oracle Designer, а затем
автоматически перенести описание проекта в репозиторий метаданных Oracle Warehouse Builder.
1.10.2. Microsoft SQL Server Analysis Services

Другой значимой OLAP-технологией является BI-решение от компании Microsoft, построенное на
платформе SQL Server и включающее компоненты Analysis Services и Integration Services. Это решение
будет подробно рассмотрено во второй главе.
1.11. Технические аспекты многомерного хранения данных

OLAP-серверы скрывают от конечного пользователя способ реализации многомерной модели. Они
формируют гиперкуб, с которым пользователи посредством OLAP-клиента выполняют необходимые
манипуляции, анализируя данные. Однако способ реализации важен, поскольку от него зависят
производительность решения и требуемые ресурсы.
Существует три основных способа реализации многомерной модели – MOLAP, ROLAP, HOLAP.
1.11.1. MOLAP
MOLAP (Multidimensional OLAP) – для реализации многомерной модели используются многомерные БД.
При этом данные хранятся в виде упорядоченных многомерных массивов. Такие массивы подразделяются
на гиперкубы, в которых все хранимые в БД ячейки имеют одинаковую мерность, и поликубы, в которых
каждая ячейка хранится с собственным набором измерений. Физически данные хранятся в «плоских»
файлах, при этом куб представляется в виде одной плоской таблицы, в которую построчно вписываются все
комбинации элементов всех измерений с соответствующими им значениями мер (Рисунок 16).
Измерения Меры
Магазин Время Поставщик Товар Единицы Стоимость

товара товара
№1 01.01.09 Иванов Картофель 100 20
№1 01.01.09. Иванов Морковь 50 25
№1 01.02.09 Иванов Картофель 150 20
№2 01.02.09 Петров Морковь 200 25
Рисунок 16. Куб в MOLAP-системе
Преимущества использования многомерных БД в OLAP-системах:
 поиск и выборка данных осуществляется значительно быстрее, чем при многомерном

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

разнообразных встроенных функций, тогда как объективно существующие ограничения языка SQL
21
делают выполнение этих задач на основе реляционных БД достаточно сложным, а иногда и
невозможным.
Недостатки MOLAP:
 за счет денормализации и предварительно выполненной агрегации объем данных в многомерной

БД, как правило, соответствует (по оценке Кодда) в 2,5... 100 раз меньшему объему исходных
детализированных данных;
 в подавляющем большинстве случаев информационный гиперкуб является сильно разреженным, а

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

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

при которых их использование является эффективным:
 объем исходных данных для анализа не слишком велик (не более нескольких гигабайт), т. е.
уровень агрегации данных достаточно высок;
 набор информационных измерений стабилен;
 время ответа системы на нерегламентированные запросы является наиболее критичным

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

вычислений над ячейками гиперкуба, в том числе возможность написания пользовательских
функций.
1.11.2. ROLAP
ROLAP (Relational OLAP) – для реализации многомерной модели используются реляционные БД.
В настоящее время распространены две основные схемы реализации многомерного представления

данных с помощью реляционных таблиц: схема "звезда" (Рисунок 17) и схема "снежинка" (Рисунок 18).
Если каждое измерение содержится в одной таблице, такая схема хранилища данных носит название
«звезда» (star schema). Если же хотя бы одно измерение содержится в нескольких связанных таблицах,
такая схема хранилища данных носит название «снежинка» (snowflake schema). Дополнительные таблицы
измерений в такой схеме, обычно соответствующие верхним уровням иерархии измерения и находящиеся
в соотношении «один ко многим» в главной таблице измерений, соответствующей нижнему уровню
иерархии, иногда называют консольными таблицами (outrigger table).
22
Сотрудник
PK ID_Сотрудника
Имя_Сотрудника
Продажи Клиент
PK,FK1 ID_Продукта PK ID_Клиента

PK,FK2 ID_Сотрудника
Продукт PK,FK3 ID_Клиента Название_компании
PK,FK5 ID_Поставщика Контактное_лицо
PK ID_Продукта Адрес
PK,FK4 ID_Время
Город
Название_Продукта Регион
Цена Количество
Сумма Телефон
Скидка
Время
PK ID_Время
Время
День_недели
Поставщик
Месяц
Год PK ID_Поставщика
Квартал
Название_Поставщика
Рисунок 17. Пример схемы данных "звезда"
23
Сотрудник1
PK ID_Сотрудника
Категория
PK ID_Категории Имя_Сотрудника
Название_Категории
Продажи1 Клиент1
PK,FK1 ID_Продукта PK ID_Клиента
PK,FK1 ID_Категории
Продукт1 PK,FK2 ID_Сотрудника Название_компании
PK ID_Продукта PK,FK3 ID_Клиента Контактное_лицо
PK,FK1 ID_Категории PK,FK5 ID_Поставщика Адрес
PK,FK4 ID_Время Город
Название_Продукта Регион
Цена Количество Телефон
Сумма
Скидка
Время1
PK ID_Время
Время
День_недели
Поставщик1
Месяц
Год PK ID_Поставщика
Квартал
Название_Поставщика
Рисунок 18. Пример схемы данных "снежинка"
В сложных задачах с иерархическими измерениями целесообразно использование схемы "снежинка". В

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

измерений, но и тем обстоятельством, что в общем случае факты имеют разные множества измерений.
При абстрагировании от отдельных измерений пользователь должен получать проекцию максимально
полного гиперкуба, причем не всегда значения показателей в ней должны являться результатом
элементарного суммирования. Таким образом, при большом числе независимых измерений необходимо
поддерживать множество таблиц фактов, соответствующих каждому возможному сочетанию выбранных в
запросе измерений, что также приводит к неэкономному использованию внешней памяти, увеличению
времени загрузки данных в БД со схемой "звезда" из внешних источников и сложностям
администрирования.
Использование реляционных БД в OLAP-системах имеет следующие достоинства:
 в большинстве случаев корпоративные ХД реализуются средствами реляционных СУБД, и

инструменты ROLAP позволяют производить анализ непосредственно над ними. При этом размер
хранилища не является таким критичным параметром, как в случае MOLAP;
24
 в случае переменной размерности задачи, когда изменения в структуру измерений приходится
вносить достаточно часто, ROLAP-системы с динамическим представлением размерности являются
оптимальным решением, т. к. в них такие модификации не требуют физической реорганизации БД;
 реляционные СУБД обеспечивают значительно более высокий уровень защиты данных и хорошие
возможности разграничения прав доступа.
Главный недостаток ROLAP по сравнению с многомерными СУБД — меньшая производительность. Для

обеспечения производительности, сравнимой с MOLAP, реляционные системы требуют тщательной
проработки схемы базы данных и настройки индексов. Только при использовании схем типа "звезда"
производительность хорошо настроенных реляционных систем может быть приближена к
производительности систем на основе многомерных баз данных.
1.11.3. HOLAP
HOLAP (Hybrid OLAP) - для реализации многомерной модели используются и многомерные, и реляционные
БД. HOLAP-серверы используют гибридную архитектуру, которая объединяет технологии ROLAP и MOLAP. В
отличие от MOLAP, которая работает лучше, когда данные более-менее плотные, серверы ROLAP
показывают лучшие параметры в тех случаях, когда данные довольно разрежены. Серверы HOLAP
применяют подход ROLAP для разреженных областей многомерного пространства и подход MOLAP — для
плотных областей. Серверы HOLAP разделяют запрос на несколько подзапросов, направляют их к
соответствующим фрагментам данных, комбинируют результаты, а затем предоставляют результат
пользователю.
2. Общие сведения о многомерном анализе данных при помощи службы

SQL Server 2008 Analysis Services
2.1. Возможности службы SSAS

Microsoft SQL Server Analysis Services (SSAS) является базовой платформой для развития систем бизнес-
анализа (Business Intelligence). SSAS 2008 обеспечивают высокую производительность работы приложений
и масштабируемость на уровне миллионов записей и тысяч пользователей.
2.1.1. Компоненты BI-решения Microsoft

BI-решение компании Microsoft основывается на масштабируемой платформе, предназначенной для
интеграции данных, построения хранилищ данных, анализа накопленных данных и построения отчетов.
Ядром BI-решения Microsoft является платформа SQL Server. Входящие в нее компоненты, специфические
для BI-решения, приведены в Таблица 2.
Таблица 2. Компоненты BI-решения Microsoft
Компонент Описание
SQL Server Database Engine Масштабируемая, высокопроизводительная

СУБД, способная хранить большие объемы
данных, образующиеся в результате
консолидации данных в единое хранилище для
25
анализа и построения отчетов.
SQL Server Integration Services Платформа для выполнения операций

извлечения, преобразования и загрузки,
которая обеспечивает заполнение ХД и его
синхронизацию с данными из различных
источников, которые используются бизнес-
приложениями организации.
SQL Server Analysis Services Обеспечивает возможность построения OLAP-

решений, включая возможность расчета
ключевых индикаторов производительности
(KPI). Применяется также для построения data-
mining-решений, которые используют
специализированные алгоритмы для
выявления трендов и зависимостей в бизнес-
данных.
SQL Server Reporting Services Инструментарий построения отчетов,

предназначенный для создания, публикации и
распространения детализированных бизнес-
отчетов, как для внутренних, так и для внешних
целей.
2.1.2. UDM
SSAS построены на основе Унифицированной Многомерной Модели (Unified Dimensional Model, UDM),
появившейся в версии 2005, которая позволяет различным типам клиентских приложений получать доступ
к данным как из реляционных, так и из многомерных баз данных без использования отдельных моделей
для каждого типа баз данных.
Основой UDM является архитектура измерений на основе атрибутов. Архитектура измерений на основе
атрибутов дает возможность группировать свойства (атрибуты), определяющие функционирование
бизнеса, в одно измерение и отделить эти свойства от правил навигации по измерению — иерархий.
UDM предоставляет возможность использовать множество источников данных (data sources) для создания
многомерной модели.
Модель UDM может быть использована для создания единого представления реляционных и
многомерных данных, включающих бизнес-объекты, бизнес-аналитику, вычисления и метрики.
Модель UDM создает промежуточный логический уровень между физической реляционной базой данных,
используемой в качестве источника данных, и фирменными структурами куба и измерений,
используемыми для обработки пользовательских запросов. Таким образом, модель UDM можно
представить себе как ядро системы OLAP. Одним из ключевых преимуществ модели UDM является
возможность сочетать гибкость и функциональное богатство традиционной реляционной модели
генерации отчетов с мощными аналитическими средствами и превосходной производительностью
классической модели системы OLAP. В эту модель включен широкий спектр функций бизнес-аналитики,
позволяющих эффективнее осуществлять реляционный и OLAP-анализ, и дающих организациям
26
возможность расширять свои решения с использованием механизма ключевых показателей эффективности
KPI, а также сложных функций прогностического анализа.
2.1.3. Масштабируемость и производительность

За счет высокой масштабируемости службы SSAS позволяют работать с терабайтными базами данных, и с
тысячами пользователей.
Чтобы обеспечить работу большого количества пользователей, избежать конфликтов при пользовании
ресурсами и снизить затраты, имеется возможность горизонтального масштабирования служб SSAS.
Горизонтальное масштабирование заключается в наращивании вычислительных мощностей и емкости
хранилищ данных с целью хранения и синхронизации нескольких версий данных, но в то же время службы
SSAS позволяют организовать общий доступ для чтения информации из одной базы данных служб с
нескольких серверов, устраняя необходимость в избыточных ресурсах.
Кубы служб SSAS — это многомерные структуры, обеспечивающие высокоскоростной доступ к большим
объемам предварительно объединенных данных, и позволяющие конечным пользователям получать
интересующие их бизнес-данные в реальном времени. В службах SSAS хранятся бизнес-данные в формате
MOLAP, предоставляющем возможность высокой степени оптимизации и сжатия . Присущая этому
формату гибкость дает также возможность частично или полностью хранить данные в реляционной базе
данных в режиме реляционного OLAP (ROLAP) или в смешанном режиме, называемом гибридным OLAP
(HOLAP). Режим MOLAP обеспечивает значительно более высокую производительность, чем режимы
ROLAP и HOLAP.
2.1.4. Представление источника данных

SSAS предоставляет уровень абстракции над реляционным источником данных — представление
источника данных. Представление источника данных позволяет определять таблицы из реляционной базы
для использования в многомерной модели. Кроме того, объект представления источника данных
позволяет создавать вычисляемые столбцы и представления над реляционными таблицами.
2.1.5. Интеграция с Microsoft Office System 2007

BI-платформа Microsoft предоставляет возможности интеграции с продуктами семейства Microsoft Office
System 2007, в частности:
 Microsoft Office Excel 2007 дает возможность просматривать данные, хранящиеся в OLAP-кубах SSAS
путем построения динамических представлений Microsoft PivotTable, что не требует установки
дополнительного программного обеспечения;
 Microsoft Office Word 2007, как и Microsoft Office Excel 2007, позволяют просматривать отчеты,
генерируемые при помощи Reporting Services;
 Microsoft Office Visio 2007 позволяет визуализировать деревья решений, деревья зависимостей,
кластерные диаграммы и другие модели технологии data mining;
 Microsoft Office SharePoint Server позволяет создать единый пользовательский интерфейс для
просмотра и управления отчетами, генерируемыми при помощи Reporting Services.
27
2.1.6. Локализация решения посредством использования переводов
Часто возникает необходимость разработки многоязыковых решений. Как правило, сами данные едины
для всего мира, но метаданные — куб, меры, наименования и уровни измерений, ключевые показатели
эффективности (KPI) будут своими для каждого используемого языка. Переводы позволяют задавать
различные значения метаданных для разных языков и приспосабливать решения для работы в
международном контексте. Финансовую информацию также необходимо локализировать для
представления результатов в надлежащей валюте. Предусмотренные в службах SSAS возможности
перевода и автоматического конвертирования валют позволяют отображать локализованные данные
анализа на родном языке пользователей.
2.2. Инструменты управления службой SSAS

SQL Server 2008 представляет следующий набор инструментов для разработки приложений и управления
серверами:
2.2.1. BI Dev Studio

SQL Server Business Intelligence Development Studio (BI Dev Studio) – инструмент, предназначенный для
разработки полноценных систем бизнес-анализа на основе Analysis Services, Reporting Services и Integration
Services (Рисунок 19).
Рисунок 19. BI Dev Studio
BI Dev Studio интегрируется в оболочку Visual Studio, что позволяет создавать дополнительные типы
проектов для SSAS (Рисунок 20);
28
Рисунок 20. Типы проектов для Analysis Services
При помощи среды BI Dev Studio можно создавать проекты служб SSAS, содержащие определения
объектов (кубов, измерений и т.д.) служб SSAS, которые хранятся в XML-файлах, содержащих элементы
языка сценариев служб SSAS (ASSL). Эти проекты содержатся в решениях, где также содержатся проекты из
других компонентов SQL Server, включая службы SQL Server Integration Services и SQL Server Reporting
Services.
В среде BI DevStudio можно разрабатывать проекты служб SSAS как часть решения, которое не зависит от
какого-либо конкретного экземпляра служб SSAS. Во время разработки объекты могут быть развернуты на
экземпляре на тестовом сервере с целью проверки, после чего этот же проект служб SSAS может быть
использован для развертывания объектов в экземплярах на одном или нескольких промежуточных или
рабочих серверах.
Средой BI DevStudio можно также воспользоваться, чтобы напрямую подсоединиться к существующему

экземпляру служб SSAS для создания и изменения объектов служб SSAS, без работы с проектом и без
хранения определений объекта в XML-файлах.
В BI Dev Studio входит средство оповещения Best Practice Design Alerts , автоматически информирующее о
возможных недочетах в проекте на ранних стадиях процесса разработки, и сокращающее потери времени,
вызванные проектными ошибками, что существенно ускоряет разработку.
2.2.2. SSMS
SQL Server Management Studio (SSMS) – инструмент, предназначенный для администраторов баз данных,
позволяющий управлять многомерными объектами, созданными разработчиками баз данных (Рисунок 21).
SSMS позволяет администрировать Analysis Services, SQL Server, Reporting Services и Integration Services в
единой консоли, которая объединяет функциональность управления, редактирования запросов и
настройки производительности.
29
Рисунок 21. SSMS
При помощи среды SQL Server Management Studio можно управлять объектами служб Analysis Services
(выполнять резервное копирование, обработку и т. д.), а также создавать новые объекты непосредственно
в существующем экземпляре служб Analysis Services с помощью сценариев XML для аналитики. Среда SQL
Server Management Studio представляет проект сценариев сервера анализа данных, в котором можно
разрабатывать и сохранять сценарии, написанные на языках многомерных выражений, расширений
интеллектуального анализа данных и XML для аналитики (XMLA). Обычно проекты сценариев сервера
анализа данных используются для выполнения задач по управлению или для повторного создания
объектов, например: баз данных или кубов, в экземплярах служб Analysis Services.
30
3. Планирование и архитектура SSAS
3.1. Логическая архитектура

Службы Microsoft SQL Server Analysis Services используют как серверные, так и клиентские компоненты для
предоставления приложениям бизнес-аналитики функций оперативной аналитической обработки (OLAP) и
интеллектуального анализа данных.
Серверный компонент служб SSAS реализован в виде службы Microsoft Windows. Службы SQL Server
Analysis Services поддерживают работу нескольких экземпляров на одном компьютере, при этом каждый
экземпляр служб SSAS реализован как отдельный экземпляр службы Windows.
Клиенты обмениваются данными со службами SSAS с помощью общедоступного стандарта XML для
аналитики (XMLA), который представляет собой протокол на базе SOAP для выполнения команд и
получения ответов и предоставляется в виде веб-службы. Поэтому каждый экземпляр SSAS является Web-
сервисом.
Клиентские модели объектов также предоставляются через XML для аналитики, и доступ к ним
производится через управляемый поставщик, например ADOMD.NET, или через собственный поставщик
OLE DB.
Также службы SSAS поддерживают ядро локального куба, которое позволяет приложениям на
отключенных клиентах просматривать локально хранимые многомерные данные.
Экземпляр служб SSAS может содержать несколько баз данных, а в базе данных могут одновременно
присутствовать объекты OLAP и объекты интеллектуального анализа данных. Приложения подключаются к
указанному экземпляру служб SSAS и к указанной базе данных. На серверном компьютере может
эксплуатироваться несколько экземпляров служб SSAS. Экземпляры служб SSAS именуются как
«<ИмяСервера>\<ИмяЭкземпляра>». На Рисунок 7 показаны все упомянутые связи между объектами служб
SSAS.
31
Рисунок 22. Связи между объектами служб SSAS
Основные классы представляют собой минимальный набор объектов, требуемый для формирования куба.
Этот минимальный набор объектов включает измерение, группу мер и секцию. Определение
статистической обработки является необязательным.
Измерение описывает элемент данных, по которому производится анализ. Например, распространенным

элементом анализа является время. Измерения создаются на основе атрибутов и иерархий.
Атрибут – это полная коллекция элементов одного типа. Например, все дни недели будут атрибутом
измерения «Время».
Иерархии формируются с использованием упорядоченного набора атрибутов, такого, что каждый атрибут
соответствует одному из уровней в иерархии.
Кубы создаются на основе измерений и групп мер. Начиная с Analysis Services 2005, поддерживается
множество фактов в одном кубе. Меры из таблицы фактов группируются в группу мер. Куб может иметь
несколько групп мер.
Измерения в коллекции измерений куба принадлежат к коллекции измерений базы данных.
Группы мер — это коллекции мер, которые имеют одно и то же представление источника данных и одно и
то же подмножество измерений в кубе. Группа мер имеет одну или несколько секций, предназначенных
для управления физическими данными. Группа мер может иметь применяемую по умолчанию
статистическую схему.
Статистическая схема по умолчанию может использоваться во всех секциях в группе мер; кроме того,
каждая секция может иметь собственную статистическую схему.
Каждый экземпляр служб SSAS рассматривается как отдельный объект сервера. Каждый отдельный
экземпляр подключается к объекту Server с помощью отдельного соединения. Каждый объект сервера
32
содержит один или несколько источников данных, представление источника данных и объекты базы
данных, а также сборки и роли безопасности.
Каждый объект базы данных содержит несколько объектов измерения. Каждый объект измерения
содержит один или несколько атрибутов, которые организованы в виде иерархий.
Каждый объект базы данных содержит один или несколько объектов куба. Куб задается его мерами и
измерениями. Меры и измерения куба выводятся из таблиц и представлений в представлении источника
данных, на котором основан куб или который создан из определений мер и измерений.
Пример
Куб «Импорт» (Рисунок 23) содержит две меры («Пакеты» и «Последняя дата») и три связанных измерения
(«Маршрут», «Источник» и «Время»).
Рисунок 23. Куб "Импорт"
По осям куба отложены элементы измерений. Примеры элементов — «Наземный» (элемент измерения
«Маршрут»), «Африка» (элемент измерения «Источник») и «1-й квартал» (элемент измерения «Время»).
Значение в ячейках куба представляют две меры — «Пакеты» и «Последняя дата». Мера «Пакеты»
представляет число импортированных посылок; для статистической обработки фактов используется
функция Sum. Мера «Последняя дата» представляет собой дату получения; для статистической обработки
используется функция Max.
Измерение «Маршрут» представляет пути, которыми импортируемый товар достигает своего назначения.
В число элементов этого измерения входят «наземный», «не наземный», «воздушный», «морской»,
«дорожный» и «железнодорожный». Измерение «Источник» представляет место производства
импортируемого товара, например Азию или Африку. Измерение «Время» представляет кварталы и
полугодия.
33
Пользователи куба могут определять значения его мер для каждого элемента в каждом измерении
независимо от уровня элемента в измерении, поскольку службы SSAS вычисляют значения верхних
уровней по мере необходимости.
Например, значения меры на Рисунок 23 могут быть вычислены в соответствии с обычной календарной
иерархией с использованием иерархии «Календарное время» в измерении «Время», как показано на
Рисунок 24.
Рисунок 24. Значения мер в соответствии с иерархией "Календарное время"
Меры, атрибуты и иерархии в примере куба выводятся из следующих столбцов таблиц фактов и измерений
куба (Таблица 3).
Таблица 3. Соответствие элементов куба таблицам фактов и измерений
Мера или Элементы Исходная таблица Исходный Образец

атрибут столбец значения
(уровень) столбца
Мера «Посылки» Неприменимо ImportsFactTable Посылки 12
Мера «Последняя Неприменимо ImportsFactTable Последняя дата 03-май-99

дата»
Уровень категории не наземный, наземный RouteDimensionTable Route_Category Не наземный

«Маршрут» в
измерении
«Маршрут»
Атрибут «Маршрут» воздушный, морской, RouteDimensionTable Маршрут Морской

в измерении дорожный, железнодорожный
«Маршрут»
Атрибут Восточное полушарие, SourceDimensionTable Полушарие Восточное

«Полушарие» в западное полушарие полушарие
измерении
«Источник»
34
Атрибут Африка, Азия, Австралия, SourceDimensionTable Континент Европа
«Континент» в Европа, Северная Америка,
измерении Южная Америка
«Источник»
Атрибут Первое полугодие, второе TimeDimensionTable Полугодие Второе

«Полугодие» в полугодие полугодие
измерении «Время»
Атрибут «Квартал» в Первый квартал, второй TimeDimensionTable Квартал Третий квартал

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

С точки зрения физической архитектуры службы SSAS состоят из серверного и клиентского компонентов.
1. Серверный компонент служб SSAS реализован в виде службы Microsoft Windows. Службы SSAS
поддерживают работу нескольких экземпляров на одном компьютере, при этом каждый экземпляр
служб SSAS реализован как отдельный экземпляр службы Windows.
2. Клиенты обмениваются данными со службами SSAS с помощью общедоступного стандарта XML для
аналитики (XMLA), который представляет собой протокол на базе SOAP для выполнения команд и
получения ответов и предоставляется в виде веб-службы. Клиентские модели объектов также
предоставляются через XML для аналитики, и доступ к ним производится через управляемый
поставщик, например ADOMD.NET, или через собственный поставщик OLE DB.
Команды запросов могут быть выражены на следующих языках:
1. Расширения интеллектуального анализа данных (DMX) — стандартный язык запросов,

ориентированный на интеллектуальный анализ данных.
2. Язык сценариев служб Analysis Services (ASSL) также может использоваться для управления
объектами базы данных служб SSAS.
Экземпляр служб SSAS запускается, как изолированная служба, взаимодействие с этой службой происходит
через XMLA с использованием протокола HTTP или TCP. Объекты AMO — это прослойка между
приложением пользователя и экземпляром служб SSAS. Они предоставляют доступ к административным
объектам служб SSAS. Объект AMO — это библиотека класса, которая принимает команды от клиентского
приложения и преобразует их в XMLA-сообщения для экземпляра служб SSAS. Объекты AMO представляют
объекты экземпляра служб SSAS, как классы для приложения конечного пользователя, с элементами-
методами, запускающими команды и элементами-свойствами, хранящими данные объектов служб SSAS.
На Рисунок 25 отображена архитектура компонентов служб SSAS, включая все главные элементы,
запущенные на экземпляре служб SSAS, и все пользовательские компоненты, взаимодействующие с этим
35
экземпляром. Как показано на рисунке, единственным путем доступа к экземпляру является
прослушиватель XML для аналитики или использование протокола HTTP или TCP.
Рисунок 25. Архитектура компонентов служб SSAS
3.3. Архитектура программирования SSAS

Прикладная модель определяет формат данных, и котором они передаются аналитическим приложениям.
Основным пользователем прикладной модели данных является клиентское приложение, которое
представляет модель пользователю. Прикладная модель создается с помощью Языка Многомерных
Выражений (Multidimensional Expressions, MDX), который служит как для представления запросов к
36
многомерной базе данных, так и для описания модели формирования данных внутри нее при помощи
MDX-сценариев (MDX Scripts).
3.3.1. Объекты AMO

Объекты AMO являются полной коллекцией классов управления для служб SSAS, доступных для
использования программным способом в управляемой среде, через пространство имен
Microsoft.AnalysisServices. Эти классы включены в файл AnalysisServices.dll, который обычно находится в
каталоге установки SQL Server, то есть в папке \100\SDK\Assemblies\. Для работы с классами AMO следует
указать в проекте Visual Studio ссылку на эту сборку.
Объекты AMO позволяют создавать, изменять и удалять такие объекты, как кубы, измерения, структуры
интеллектуального анализа, а также базы данных служб SSAS. Приложение, работающее на
платформе .NET Framework, может выполнять действия со всеми этими объектами. Кроме этого,
существует также возможность обновления и обработки данных, хранящихся в базах данных служб SSAS.
Объекты AMO не позволяют выполнять запросы к данным. Для запроса данных предназначены объекты,
описанные в разделе ADOMD.NET.
Библиотека классов AMO содержит иерархию классов, где для использования в коде сначала создаются
экземпляры одних классов, а затем других. Существуют также дополнительные классы, экземпляры
которых могут быть в любой момент созданы в коде, однако сначала, вероятно, потребуется создать
экземпляры одного или нескольких классов иерархии.
На Рисунок 26 приведена иерархия классов AMO высокого уровня, содержащая основные классы.
37
Рисунок 26. Иерархия классов AMO высокого уровня
Объекты AMO особенно полезны для автоматизации часто выполняемых задач (например, для создания
новых секций в группе мер при появлении новых данных в таблице фактов или для повторного обучения
модели интеллектуального анализа при появлении новых данных). Обычно эти задачи, которые создают
новые объекты, выполняются ежемесячно, еженедельно или ежеквартально, а приложение может легко
именовать эти новые объекты на основе новых данных.
Администраторы служб SSAS могут использовать объекты AMO, чтобы автоматизировать обработку баз
данных служб SSAS. Проектирование и развертывание баз данных служб SSAS следует производить в среде
BI Dev Studio.
Разработчикам объекты AMO дают возможность создавать интерфейсы администрирования для

определенных наборов пользователей. Эти интерфейсы позволяют ограничивать доступ к объектам служб
38
SSAS и разрешать пользователям выполнять только определенные задачи. На основе объектов AMO
можно, например, создать приложение для создания резервных копий, которое позволит пользователям
видеть все объекты баз данных, выбрать любую из баз данных и создать ее резервную копию на любом
устройстве из указанного набора.
Разработчики могут также внедрять в приложения логику служб SSAS. Это возможно благодаря созданию
кубов, измерений, структур и моделей интеллектуального анализа на основе пользовательского ввода и
других факторов.
Проектирование, развертывание и обслуживание большинства наиболее часто выполняемых задач лучше

всего выполняется при помощи приложений на основе служб Integration Services, написанных на любом
языке. А для тех повторяющихся задач, автоматизировать которые при помощи служб Integration Services
невозможно, можно использовать объекты AMO. Объекты AMO также полезны при разработке
специализированных приложений для бизнес-аналитики на основе служб SSAS.
3.3.2. Язык ASSL

Клиентские приложения служб SSAS, в том числе SQL Server Management Studio и BI Dev Studio,
поддерживают связь со службами SSAS с помощью сообщений SOAP. Язык сценариев служб Analysis
Services (язык ASSL), который является разновидностью XML, используемой для этих сообщений, состоит из
двух частей:
1. языка описания данных DDL, или язык определения объектов, который определяет и описывает
экземпляр служб SSAS, а также базы данных и объекты баз данных, находящихся в этом
экземпляре;
2. командного языка, который отправляет команды-действия, например Create, Alter или Process,
экземпляру служб SSAS.
В службах SSAS язык определения данных (Data Definition Language, DDL) языка ASSL определяет структуру
объектов служб SSAS (например, кубов, измерений и моделей интеллектуального анализа данных), а также
привязку объектов служб SSAS к источникам данных. DDL также сохраняет определение объектов служб
SSAS. Приложения служб SSAS используют DDL для создания, изменения, развертывания и описания
объектов SSAS.
Разработчик проектирует набор кубов при помощи средств проектирования среды BI DevStudio и сохраняет
это определение как часть проекта. Разработчик не ограничен использованием только средств
проектирования, он также может открывать непосредственно файлы определений кубов для изменения
XML.
Администратор БД использует среду SQL Server Management Studio для непосредственного

редактирования XML в качестве средства создания и изменения объектов служб SSAS так же, как он
использует SQL Server DDL, чтобы создавать и изменять объекты Microsoft SQL Server.
3.3.3. Поставщик данных ADOMD.NET

Как и в случае с поставщиками данных платформы Microsoft .NET Framework, такими как ADO.NET,
ADOMD.NET выступает в качестве моста между приложением и источником данных. Однако ADOMD.NET
отличается от остальных поставщиком данных платформы .NET Framework тем, что он работает с
аналитическими данными. Чтобы работать с аналитическими данными, компонент ADOMD.NET обладает
39
функциями, которые значительно отличаются от функций других поставщиков данных платформы .NET
Framework. ADOMD.NET позволяет получать не только данные, но и метаданные, а также изменять
структуру источника аналитических данных.
Получив метаданных при помощи наборов строк схемы или модели объекта, приложения могут узнать
больше о тех данных, которые можно извлечь из источника данных. Получить можно такие сведения, как
типы доступных ключевых индикаторов производительности, измерения в кубе и параметры, которые
требуются модели интеллектуального анализа данных. Наибольшее значение метаданные имеют для
динамических приложений, которым для определения типа, глубины и области действия получаемых
данных требуется ввод пользователя. Среди таких приложений Query Analyzer, Microsoft Excel и другие
средства запросов. Метаданные менее значимы для статических приложений, выполняющих набор
стандартных действий.
Получение данных — это фактическое извлечение сведений, хранящихся в источнике данных. Получение
данных является основной функцией «статических» приложений, которым известна структура источника
данных. Получение данных также является конечным результатом «динамических» приложений. Значение
ключевого индикатора производительности в данное время суток, число велосипедов, проданных за
последний час по каждому магазину и факторы, влияющие на среднегодовую производительность
сотрудников — все это примеры данных, которые можно получить. Получение данных важно для любого
выполняющего запросы приложения.
Компонент ADOMD.NET также можно использовать, чтобы фактически изменять структуру хранилища
аналитических данных. И хотя обычно это делается с помощью модели объектов AMO, компонент
ADOMD.NET можно использовать для отправки команд на ASSL, чтобы создавать, изменять или удалять
объекты на сервере.
40
4. Разработка многомерных баз данных с использованием SSAS
4.1. Проектирование и реализация многомерных баз данных
4.1.1. Решения, проекты и элементы

И среда BI Dev Studio, и среда SQL Server Management Studio предоставляют проекты, которые, в свою
очередь, организованы в решения. Решение может содержать несколько проектов, а проект обычно
содержит несколько элементов. При создании проекта автоматически создается новое решение, а в
существующее решение при необходимости можно добавлять проекты. Объекты, которые содержатся в
проекте, зависят от его типа. Элементы в каждом контейнере проекта хранятся в виде файлов,
расположенных в папках проекта в файловой системе.
4.1.2. Типы проектов бизнес-аналитики

В Таблица 4 приведены типы проектов бизнес-аналитики, которые могут быть созданы в среде BI Dev
Studio.
Таблица 4. Типы проектов бизнес-аналитики в среде BI Dev Studio
Проект Описание
Проект служб Analysis Содержит определения объектов для одиночной базы данных служб SSAS.
Services
Импорт базы данных Предоставляет мастер, который можно использовать для создания нового
служб Analysis Services проекта служб SSAS путем импортирования определений объектов из
2008 существующей базы данных служб SSAS.
Проект служб Integration Содержит определения объектов для набора пакетов служб Integration Services.
Services
Мастер проектов Предоставляет мастер, который помогает выполнить процесс создания проекта
отчетов отчета с помощью служб Reporting Services.
Проект модели отчета Содержит определения объектов для модели отчета служб Reporting Services.
Проект сервера отчетов Содержит определения объектов для одного или нескольких отчетов служб
Reporting Services.
Среда SSMS также содержит несколько типов проектов, предназначенных для различных типов запросов
или сценариев (Таблица 5).
Таблица 5. Типы проектов бизнес-аналитики в SSMS
Проект Описание
Сценарии служб Содержит сценарии расширений интеллектуального анализа данных, многомерных

Analysis Services выражений и XML для аналитики для служб SSAS, а также соединения с экземплярами
служб SSAS, в которых эти сценарии могут выполняться.
41
Сценарии SQL Содержит сценарии SQL для SQL Server Compact, а также соединения с экземплярами
Server Compact SQL Server Compact, в которых могут выполняться эти сценарии.
Сценарии SQL Содержит сценарии Transact-SQL и XQuery для экземпляра компонента SQL Server
Server Database Engine, а также соединения с экземплярами компонента SQL Server Database
Engine, в которых эти сценарии могут выполняться.
4.1.3. Выбор между SSMS и BI Dev Studio

Среда SSMS разработана для администрирования и настройки существующих объектов в компонентах SQL
Server Database Engine, Analysis Services, Integration Services и Reporting Services. Среда BI Dev Studio
предназначена для разработки решений в области бизнес-аналитики, которые включают функции служб
Analysis Services, Integration Services и Reporting Services.
Основные различия между SSMS и BI Dev Studio заключаются в следующем:
 среда SSMS предоставляет интегрированную среду для соединения с экземплярами служб SSAS,
SQL Server и Reporting Services, чтобы настраивать объекты, а также проводить администрирование
объектов и управлять ими в пределах экземпляра служб SSAS. С использованием этих сценариев
можно также использовать среду SSMS для создания или изменения объектов служб SSAS, но среда
SSMS не предоставляет графический интерфейс для конструирования и определения объектов;
 среда BI Dev Studio предоставляет интегрированную среду разработки для разработки решений
бизнес-аналитики. Среду BI Dev Studio можно использовать в проектном режиме, использующем
определения на основе XML объектов служб SSAS, Integration Services и Reporting Services,
содержащихся в проектах и решениях. Использование среды BI Dev Studio в проектном режиме
означает, что изменения объектов служб SSAS в среде BI Dev Studio применяются к определениям
объектов на основе XML, но не применяются непосредственно к объекту в экземпляре служб SSAS
до тех пор, пока решение не будет развернуто. Среду BI Dev Studio можно также использовать в
оперативном режиме, т. е. напрямую подключаться к экземпляру служб SSAS и работать с
объектами существующей базы данных.
4.1.4. Создание проекта служб Analysis Services в среде BI Dev Studio

Создание проекта служб SSAS в среде BI Dev Studio выполняется либо с помощью шаблона проекта служб
SSAS, либо с помощью мастера импорта базы данных служб Analysis Services 9.0 считывается содержимое
базы данных служб SSAS, и на его основе создается проект служб SSAS.
Если в настоящий момент в среде BI Dev Studio не загружено ни одно решение, при создании нового
проекта служб SSAS будет автоматически создано новое решение. В противном случае новый проект служб
SSAS может быть добавлен к существующему решению или создан в новом решении.
Для создания проекта служб SSAS в среде BI Dev Studio необходимо выполнить следующие шаги:
1. создание проекта служб SSAS выполняется путем выбора шаблона проекта служб SSAS или с
помощью мастера импорта базы данных служб Analysis Services 9.0 в группе шаблонов бизнес-
аналитики диалогового окна «Добавление нового проекта», а также задания имени и размещения
для нового проекта (Рисунок 27).
42
Рисунок 27. Создание проекта служб SSAS
2. если определить проект служб SSAS, основанный на шаблоне проекта служб SSAS, проект шаблона
будет открыт в среде BI Dev Studio, в которой можно определить источники данных, представления
источников данных, кубов, измерений, ролей и других объектов служб SSAS. Можно
сконструировать эти объекты, основанные на существующих источниках данных, или сформировать
специальную реляционную структуру базы данных, основанную на кубе и конструкторе измерений.
Также можно сконструировать куб и объекты измерения, основанные на кубе и шаблонах
измерений (Рисунок 28);
Рисунок 28. Обозреватель решений проекта Analysis Services в BI Dev Studio
3. если вновь определенный проект служб SSAS был основан на существующей базе данных служб
SSAS, метаданные для этой базы данных будут открыты в проекте служб SSAS в среде BI Dev Studio,
в которой можно изменить метаданные существующей базы данных. Однако до тех пор, пока
изменения не будут развернуты, они не повлияют на существующие базы данных служб SSAS;
4. Создаются другие проекты, требуемые для решения бизнес-аналитики.
43
5. Добавляются дополнительные файлы, например текстовые файлы, содержащие примечания к
проекту, в папку «Разное» проекта служб SSAS в окне обозревателя решений (Рисунок 29).
Рисунок 29. Добавление дополнительных файлов в папку "Разное" обозревателя решений
6. определяются свойства развертывания проекта, чтобы задать сервер, на котором будут развернуты
метаданные проекта как обработанные объекты, и указать другие свойства развертывания (Рисунок
30).
Рисунок 30. Определение свойств развертывания проекта
7. Собирается (Рисунок 31) и развертывается (Рисунок 32) решение в экземпляре служб SSAS для
тестирования. При сборке решения проверяются определения и зависимости объектов,
включенные в проект, и формируется сценарий развертывания. При развертывании решения
используется ядро развертывания служб SSAS для отправки подсистемы развертывания в
указанный экземпляр.
44
Рисунок 31. Построение решения Рисунок 32. Развертывание решения
8. просмотр и тестирование развернутого проекта;
9. при необходимости изменяются определения объектов, и повторяется сборка и развертывание.
4.1.5. Папки проекта служб Analysis Services

Проект служб SSAS содержит набор папок, которые используются для организации элементов, включенных
в проект (Таблица 6).
Таблица 6. Папки проекта служб SSAS
Папка Описание
Источники данных Содержит источники данных для проекта служб SSAS. Эти объекты создаются в
мастере источников данных и редактируются в конструкторе источников
данных.
Представления Содержит представления источников данных для проекта служб SSAS. Эти
источников данных объекты создаются в мастере представлений источников данных и
редактируются в конструкторе представлений источников данных.
Кубы Содержит кубы для проекта служб SSAS. Эти объекты создаются в мастере
кубов и редактируются в конструкторе кубов.
Измерения Содержит измерения для проекта служб SSAS. Эти объекты создаются в
мастере измерений или мастере кубов и редактируются в конструкторе
измерений.
Структуры Содержит структуры интеллектуального анализа данных для проекта служб

интеллектуального SSAS. Эти объекты создаются в мастере моделей интеллектуального анализа
45
анализа данных данных и редактируются в конструкторе моделей интеллектуального анализа
данных.
Роли Содержит роли базы данных для проекта служб SSAS. Создание и управление
ролями осуществляется в конструкторе ролей.
Сборки Содержит ссылки на библиотеки COM и сборки платформы Microsoft .NET

Framework для проекта служб SSAS. Ссылки создаются при помощи
диалогового окна Добавление ссылки.
Прочее Содержит все типы файлов, за исключением типов файлов служб SSAS.
4.1.6. Типы файлов проекта Analysis Services

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

SSAS (DWPROJ) сборки, определенные и включенные в проект служб SSAS.
Пользовательские настройки Содержит данные о конфигурации проекта служб SSAS для

проекта служб SSAS конкретного пользователя.
(DWPROJ.USER)
Файл источника данных (DS) Содержит элементы языка сценариев служб SSAS (ASSL),
определяющие метаданные для источника данных.
Файл представления источника Содержит элементы ASSL, определяющие метаданные для

данных (DSV) представления источника данных.
Файл куба (CUBE) Содержит элементы ASSL, определяющие метаданные для куба,
включая группы мер, меры и измерения куба.
Файл секций (PARTITIONS) Содержит элементы ASSL, определяющие метаданные для секций
указанного куба.
Файл измерения (DIM) Содержит элементы ASSL, определяющие метаданные для измерения
базы данных.
Файл структуры Содержит элементы ASSL, определяющие метаданные для структуры

интеллектуального анализа интеллектуального анализа данных и связанных с ней моделей
данных (DMM) интеллектуального анализа данных.
Файл базы данных (DATABASE) Содержит элементы ASSL, определяющие метаданные для базы
данных, включая типы учетных записей, переводы и разрешения базы
данных.
46
Файл роли базы данных (ROLE) Содержит элементы ASSL, определяющие метаданные для роли базы
данных, включая членов роли.
4.2. Запросы к многомерным базам данных

Многомерные выражения применяются для запросов многомерных данных или для работы с кубами.
4.2.1. Ключевые понятия многомерных выражений

Рассмотрим специфические для служб SSAS понятия и термины, связанные с многомерным
моделированием.
Измерение базы данных — это коллекция атрибутов измерения, связанных с ключевым атрибутом,
который, в свою очередь, связан с фактами в измерении мер.
Атрибут измерения привязан к одному или более столбцам в таблице измерения и состоит из элементов.
Атрибут измерения может содержать имена заказчиков, названия месяцев, названия продуктов.
Элемент — это значение атрибута измерения, в том числе измерения мер. Иерархия может содержать
конечные элементы, родительские элементы, элементы данных и элемент «(Все)».
Мера — это значение из таблицы фактов (синонимом меры является термин факт). Значение в измерении
мер часто называют общим термином элемент. Мерами обычно являются числовые значения, но могут
быть и строковые.
Измерение мер — это измерение, содержащее все меры куба. Измерение мер является измерением
специального типа, в котором элементы обычно статистически вычислены (обычно по сумме или
количеству) на основе текущего элемента каждого атрибута измерения, для которого существует данная
мера.
Группа мер — это коллекция связанных мер в кубе служб SSAS (обычно меры из одной таблицы фактов). В
службах SSAS куб может содержать несколько групп мер.
Элемент «(Все)» — это вычисленное значение всех элементов в иерархии атрибута или определенной
пользователем иерархии.
Вычисляемый элемент — это элемент измерения, который определяется и вычисляется во время

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

значение его дочерних элементов.
Конечный элемент — это элемент иерархии, у которого нет дочерних элементов.
Дочерний элемент — это элемент иерархии ниже верхнего уровня.

47
Ключевой атрибут измерения базы данных — это атрибут, с которым связаны все неключевые атрибуты
измерения (напрямую или косвенно). Ключевой атрибут часто является атрибутом гранулярности.
Атрибут гранулярности - атрибут измерения куба, связывающий измерение с фактами в группе мер в
измерении мер. Если атрибут гранулярности и ключевой атрибут — это разные атрибуты, то неключевые
атрибуты должны быть напрямую или косвенно связаны с атрибутом гранулярности. Внутри куба атрибут
гранулярности определяет гранулярность измерения.
Измерение куба — это экземпляр измерения базы данных в кубе.
Иерархия атрибута — это иерархия элементов атрибута, содержащая следующие уровни.
1. конечный уровень, содержащий все отдельные элементы атрибута, и все элементы конечного уровня
(конечные элементы);
2. промежуточные уровни, если иерархия атрибута является иерархией типа «родители-потомки»;
3. необязательный уровень «(Все)», содержащий статистическое значение конечных элементов иерархии

атрибута, элемент этого уровня называют элементом «(Все)».
Сбалансированная иерархия — это иерархия, в которой между верхним и любым из конечных элементов
расположено одинаковое количество уровней.
Несбалансированная иерархия (неровная) — это иерархия, в которой между верхним и конечным

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

атрибута, содержащие статистическое значение для родительского элемента, в том числе элементы
данных;
2. промежуточные уровни, содержащие родительские элементы;
3. необязательный уровень «(Все)», содержащий статистическое значение конечных элементов иерархии

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

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

куба.
4.2.2. Кортежи
Кортеж уникальным образом определяет ячейку на основе сочетания элементов атрибута, состоящих из
атрибутов каждой иерархии атрибута куба. При определении кортежа в запросе многомерных выражений
или в многомерном выражении не обязательно явно включать элемент атрибута из каждой иерархии
атрибута. Если элемент из иерархии атрибута не включен явно в запрос или выражение, в кортеж неявным
образом включается элемент по умолчанию данной иерархии атрибута. Если в кубе явно не указано
обратное, элементом по умолчанию любой иерархии атрибута считается элемент «(Все)», если он
существует. Если такой элемент отсутствует в иерархии атрибута, элементом по умолчанию считается
элемент верхнего уровня иерархии. Мерой по умолчанию является первая мера указанного куба, если
только мера по умолчанию не определена явно.
Например, следующий кортеж определяет одну ячейку в базе данных Adventure Works, явно определяя
только один элемент в измерении Measures.
(Measures.[Reseller Sales Amount])
В примере уникально определена ячейка, состоящая из элемента Reseller Sales Amount из измерения
Measures и элемента по умолчанию из каждой иерархии атрибута в кубе. Элементом по умолчанию для
каждой иерархии атрибута, кроме Destination Currency, является элемент «(Все)». Элементом по
умолчанию для иерархии Destination Currency является элемент US Dollar (он определен в сценарии
многомерных выражений в кубе Adventure Works).
Следующий запрос возвращает значение ячейки, на которую ссылается кортеж, указанный в предыдущем
примере:
SELECT
Measures.[Reseller Sales Amount] ON COLUMNS
FROM [Adventure Works]
Размерностью кортежа называют последовательность или порядок его элементов. Поскольку неявные
элементы всегда расположены в одном и том же порядке, размерность практически всегда зависит от
элементов кортежа, определенных явно. Порядок элементов кортежа важен при определении набора
кортежей. В следующем примере кортеж содержит два элемента по оси столбцов:
SELECT
([Measures].[Reseller Sales Amount],[Date].[Calendar Year].[CY 2004]) ON COLUMNS
49
Кортеж в запросе возвращает ячейку куба на пересечении меры Reseller Sales Amount измерения Measures
и элемента CY 2004 иерархии атрибута Calendar Year в измерении Date.
4.2.3. Наборы
Набором называют упорядоченное множество кортежей одинаковой размерности. Для обозначения
набора кортежей используются фигурные скобки {}. Пример набора:
SELECT
([Measures].[Reseller Sales Amount],
[Date].[Calendar Year].[CY 2003]),
([Measures].[Reseller Sales Amount],
[Date].[Calendar Year].[CY 2004])
} ON COLUMNS
В примере все кортежи набора имеют одинаковую размерность, поскольку первый элемент каждого
кортежа принадлежит измерению Measures, а второй элемент — иерархии атрибута Calendar Year.
Можно создать набор с псевдонимом, называемый именованным набором. Применение именованных

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

В языке многомерных выражений можно обращаться с запросом к таким многомерным объектам, как
кубы, и возвращать многомерные наборы ячеек, содержащие данные куба.
Базовый запрос многомерных выражений — это инструкция SELECT, наиболее частый запрос в
многомерных выражениях. Чтобы получить основательные знания о применении многомерных
выражений для запроса многомерных данных, необходимо понять, как в инструкции многомерных
выражений SELECT определяется результирующий набор, синтаксис инструкции SELECT и как с ее помощью
создавать простые запросы.
В многомерном выражении инструкция SELECT указывает результирующий набор, содержащий

подмножество многомерных данных, возвращаемое из куба. Чтобы указать результирующий набор,
запрос многомерных выражений должен содержать следующие данные:
 число осей или наборов иерархий. В многомерном запросе можно указать до 128 осей;
 элементы каждого измерения, включаемые в каждую ось многомерного запроса;
50
 имя куба, задающего контекст многомерного запроса;
 элементы оси среза, по которой отсекаются данные для элементов из осей запроса.
Для указания осей запроса куба, задающего контекст запроса, и осей среза в инструкции многомерных
выражений SELECT используются следующие предложения:
 предложение SELECT, определяющее оси запроса в инструкции многомерных выражений SELECT;
 предложение FROM, определяющее источник многомерных данных для их извлечения в

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

в качестве оси среза для выделения данных, относящихся к конкретному измерению или элементу.
Синтаксис базовой инструкции SELECT с использованием предложений SELECT, FROM и WHERE:
[ WITH <SELECT WITH clause> [ , <SELECT WITH clause> ... ] ]
SELECT [ * | ( <SELECT query axis clause>
[ , <SELECT query axis clause> ... ] ) ]
FROM <SELECT subcube clause>
[ <SELECT slicer axis clause> ]
[ <SELECT cell property list clause> ]
Далее приведен базовый запрос многомерных выражений на основе инструкции SELECT:
SELECT
{ [Measures].[Sales Amount],
[Measures].[Tax Amount] } ON COLUMNS,
{ [Date].[Fiscal].[Fiscal Year].&[2002],
[Date].[Fiscal].[Fiscal Year].&[2003] } ON ROWS
WHERE ( [Sales Territory].[Southwest] )
Этот запрос возвращает результирующий набор, содержащий продажи за 2002 и 2003 годы и сумму
налогов для юго-западных областей продаж. Запрос содержит следующие сведения о результирующем
наборе:
 предложение SELECT задает оси запроса как элементы Sales Amount и Tax Amount в измерении
Measures и как элементы 2002 и 2003 в измерении Date;
 предложение FROM указывает, что источником данных является куб Adventure Works;
51
 предложение WHERE определяет ось среза как элемент Southwest измерения Sales Territory.
Обратите внимание, что в запросе используются псевдонимы осей COLUMNS и ROWS.
4.2.5. Основные понятия о сценариях многомерных выражений

В службах SSAS сценарии многомерных выражений состоят из одного или нескольких многомерных
выражений или инструкций, заполняющих куб вычислениями.
Сценарий многомерных выражений определяет процесс вычислений для куба. Сценарий многомерных
выражений также считается частью самого куба. Поэтому изменение сценария многомерных выражений,
связанного с кубом, сразу изменяет процесс вычислений для куба.
Для создания сценариев многомерных выражений можно воспользоваться конструктором кубов в среде BI
Dev Studio.
Существует два типа сценариев многомерных выражений:
1. Сценарий многомерных выражений по умолчанию. При создании куба службы SSAS создают
стандартный сценарий многомерных выражений для этого куба. В этом сценарии определяется этап
вычисления для всего куба.
2. Пользовательский сценарий многомерных выражений. После создания куба можно добавить

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

именованные наборы, назначения и вычисляемые элементы, созданные в конструкторе кубов:
 службы SSAS добавляют команды непосредственно в сценарий многомерных выражений по

умолчанию;
 для каждого именованного набора в кубе в сценарий многомерных выражений по умолчанию

добавляется соответствующая инструкция CREATE SET.
 для каждого вычисляемого элемента в кубе в сценарий многомерных выражений по умолчанию

добавляется соответствующая инструкция CREATE MEMBER.
Если с кубом не связан ни один сценарий многомерных выражений, куб вычисляется по сценарию
многомерных выражений по умолчанию. Куб должен быть связан хотя бы с одним сценарием
многомерных выражений, поскольку только в сценарии определяется порядок вычисления куба.
52
5. Использование служб Integration Services со службами Analysis Services
5.1. Возможности Integration Services для работы с OLAP

Службы SQL Server Integration Services (SSIS) представляют собой платформу для построения
высокопроизводительных решений интеграции данных и решений потока операций, включая операции
извлечения, преобразования и загрузки (Extract, Transform, Load - ETL) для хранилищ данных.
Службы SSIS содержат графические инструменты и мастера для построения и отладки пакетов; задачи для
выполнения функций потока операций, таких как:
 выполнение инструкций SQL и работа с сообщениями электронной почты;
 источники данных и назначения для извлечения и загрузки данных;
 преобразования для очистки, статистической обработки, слияния и копирования данных;
 службу управления, службу SSIS для администрирования пакетов служб SSIS;
 API-интерфейсы для программирования объектной модели служб SSIS.
Типичные случаи применение пакетов служб SSIS совместно с SSAS включают в себя:
1. слияние данных из разнородных хранилищ данных;
2. заполнение хранилищ данных и витрин данных;
3. очистка и стандартизация данных.
5.1.1. Слияние данных из разнородных хранилищ данных

Данные обычно хранятся во множестве различных систем хранилищ данных, и извлечение данных из всех
источников и их слияние в единый согласованный набор данных может представлять собой довольно
сложную задачу. Эта ситуация может возникнуть по ряду причин, например:
1. Множество организаций хранят архивные данные в традиционных системах хранилищ данных. Эти
данные могут быть не слишком важными для ежедневных операций, однако они могут иметь
ценность для анализа трендов, которому необходимы данные за длительный период.
2. Филиалы организации могут использовать разные технологии хранения данных для хранения
операционных данных. Пакету может потребоваться извлечь данные из электронных таблиц, а
также из реляционных БД перед тем, как он сможет объединить эти данные.
3. Данные могут храниться в базах данных, которые используют различные схемы для одних и тех же
данных. Пакету может потребоваться изменить тип данных столбца или объединить данные из
нескольких столбцов в один перед тем, как он сможет объединить данные.
Службы SSIS могут подключиться ко многим типам источников данных, включая несколько источников
данных одного пакета. Пакет может подключиться к реляционным базам данных, используя
поставщиков .NET и OLE DB, а также ко множеству традиционных баз данных, используя драйверы ODBC.
Он также может подключиться к плоским файлам, файлам Excel и проектам служб SSAS.
53
Службы SSIS содержат компоненты источника, осуществляющие работу по извлечению данных из плоских
файлов, рабочих листов Excel, XML-документов, а также таблиц и представлений реляционных БД из
источника данных, к которому подключается пакет.
Затем данные обычно преобразуются с помощью преобразований, содержащихся в службах SSIS. После
того, как данные преобразованы в совместимые форматы, они могут быть физически объединены в один
набор.
После успешного слияния данных и применения преобразований данные загружаются по одному или
нескольким назначениям. Службы SSIS содержат назначения для загрузки данных в плоские файлы,
необработанные файлы, а также реляционные базы данных. Данные также могут быть загружены в набор
записей, хранимых в памяти, и быть доступны для других элементов пакета.
5.1.2. Заполнение хранилищ данных и витрин данных

Данные в хранилищах и витринах данных обновляются часто, а объем загружаемых данных обычно
довольно велик.
Службы SSIS содержат задачу, которая производит массовую загрузку данных прямо из плоского файла в
таблицы и представления SQL Server, а также компонент назначения, производящий массовую загрузку
данных в базу данных SQL Server в качестве последнего шага преобразования данных.
Пакет служб SSIS может быть настроен с возможностью перезапуска. Это означает, что можно
перезапустить пакет с предопределенной контрольной точки — задачи или контейнера пакета.
Возможность перезапуска пакета может значительно экономить время, особенно если пакет обрабатывает
данные из большого количества источников.
Можно использовать пакеты служб SSIS для загрузки в базу данных таблиц измерений и фактов. Если
источник данных для таблицы измерения хранится в нескольких источниках данных, то пакет может
объединить данные в один набор и загрузить таблицу измерения в течение одного процесса, вместо
использования отдельных процессов для каждого источника данных.
Обновление данных в хранилищах и витринах данных может стать сложной задачей, так как оба типа
хранилищ данных обычно содержат медленно изменяющиеся измерения, которыми бывает сложно
управлять с помощью преобразования данных. Мастер медленно изменяющихся измерений
автоматизирует поддержку медленно изменяющихся измерений, динамически создавая инструкции SQL,
которые обновляют и заменяют записи, обновляют связанные записи, а также добавляют новые столбцы в
таблицы.
Кроме того, задачи и преобразования в пакетах служб SSIS могут обрабатывать кубы и измерения служб
SSAS. Когда пакет обновляет таблицу в базе данных, на основе которой построен куб, можно использовать
задачи и преобразования служб SSIS для автоматической обработки куба, а также для автоматической
обработки измерений. Автоматическая обработка кубов и измерений помогает предоставлять текущие
данные для пользователей обеих сред: пользователям, которые получают данные из кубов и измерений, и
пользователям, которые получают доступ к данным в реляционной базе данных.
Службы SSIS могут также вычислять функции перед загрузкой данных в назначение. Если хранилища и
витрины данных содержат статистические данные, то пакет служб SSIS может рассчитать такие функции,
как SUM, AVERAGE и COUNT. Преобразование служб SSIS может также свести реляционные данные и
54
преобразовать их в менее нормализованный формат, который является более совместимым с табличными
структурами хранилища данных.
5.1.3. Очистка и стандартизация данных

Перед загрузкой данных для оперативной обработки транзакций (OLTP) или в базу данных оперативной
аналитической обработки (OLAP), рабочий лист Excel или файл, данные необходимо очистить и
стандартизировать. Данные могут требовать обновления по следующим причинам:
1. Данные были получены из нескольких филиалов организации, и каждый филиал использует разные
стандарты и соглашения. Перед тем, как данные могут быть использованы, может потребоваться
преобразовать их в другой формат. Например, может потребоваться объединить имя и фамилию в
один столбец.
2. Данные могут быть арендованными или приобретенными. Перед тем, как данные могут быть
использованы, может потребоваться их стандартизация и очистка для соответствия стандартам
делопроизводства. Например, какая-либо организация желает проверить, что все записи содержат
один набор кодов регионов или один и тот же набор названий продукции.
3. Формат данных зависит от языкового стандарта. Например, данные могут иметь различные
форматы даты-времени, а также форматы чисел. Если данные объединены из источников разных
языковых стандартов, то перед загрузкой их необходимо привести в один формат во избежание
повреждения данных.
Службы SSIS содержат встроенные преобразования, которые можно добавить к пакетам для очистки и
стандартизации данных, изменения регистра данных, преобразования данных в иной тип или формат, а
также для создания нового столбца данных на основе выражений. Например, пакет может объединить
столбцы, содержащие имена и фамилии, в общей столбец полного имени, а затем перевести все символы
в верхний регистр.
Пакет служб SSIS также может произвести очистку данных путем замены значений в столбцах на значения
ссылочной таблицы, используя уточняющие запросы или нечеткие уточняющие запросы для поиска
значений в ссылочной таблице. Часто пакет сначала применяет уточняющий запрос и, в случае неудачи,
нечеткий уточняющий запрос. Например, сначала пакет пытается провести поиск названия продукта в
ссылочной таблице, используя значение первичного ключа. Если этот поиск не смог вернуть название
продукта, то пакет повторяет попытку с применением нестрогого соответствия наименования продукта.
Другое преобразование производит очистку данных с помощью группирования похожих значений набора
данных. Это полезно при распознавании записей, которые могут быть дубликатами и поэтому не должны
быть включены в базу данных без дальнейшей оценки. Например, сравнивая адреса в списке записей
клиентов, можно найти несколько дублирующих записей.
5.2. Архитектура служб SSIS

Службы SSIS состоят из различных компонентов (Рисунок 33).
55
Рисунок 33. Архитектура служб SSIS
Конструктор служб SSIS — это графическое средство, с помощью которого можно создавать и обслуживать
пакеты служб Integration Services. Конструктор служб SSIS доступен в среде BI Dev Studio как часть проекта
служб SSIS.
Среда выполнения служб SSIS сохраняет макет пакетов, выполняет пакеты и обеспечивает поддержку
ведения журналов, точек останова, настройки, соединений и транзакций.
Исполняемые объекты времени выполнения служб SSIS — это пакеты, контейнеры, задачи и обработчики
событий, содержащиеся в службах SSIS. К числу исполняемых объектов среды выполнения принадлежат
также разрабатываемые пользовательские задачи.
Задача потока данных инкапсулирует подсистему обработки потока данных. Подсистема обработки потока
данных предоставляет размещенные в памяти буферы для перемещения данных из источника на целевой
объект и вызова средств для извлечения данных из файлов и реляционных баз данных. Подсистема
обработки потока данных также управляет преобразованиями, которые изменяют данные, и
назначениями, которые загружают данные или делают их доступными для других процессов.
56
Компонентами потока данных служб SSIS являются источники, преобразования и назначения, включенные
в службы SSIS. Можно также добавлять к потоку данных пользовательские компоненты.
Модель объектов служб SSIS включает управляемые прикладные программные интерфейсы (API) для
создания пользовательских компонентов, используемых в пакетах, или пользовательских приложений для
создания, загрузки, выполнения пакетов и управления ими. Разработчик может написать пользовательские
приложения, пользовательские задачи или преобразования, применяя любой язык, совместимый со
средой CLR.
Служба SSIS позволяет использовать среду SQL Server Management Studio для наблюдения за работой
пакетов служб SSIS и управления хранением пакетов.
Мастер импорта и экспорта SQL Server может копировать данные из любого источника данных и в любой
источник данных, для которого доступен управляемый поставщик данных .NET Framework или собственный
поставщик данных OLE DB. Этот мастер также предоставляет простейший метод создания пакета служб
SSIS, в котором данные копируются из источника в назначение.
Службы SSIS включают дополнительные средства, мастера и программы командной строки для
выполнения пакетов служб SSIS и управления ими.
5.3. Пакет SSIS

Пакет представляет собой объект, который реализует функциональность служб SSIS по извлечению,
преобразованию и загрузке данных. Пакет создается с помощью конструктора служб SSIS в среде BI Dev
Studio. Его можно также создать с помощью мастера импорта и экспорта SQL Server либо мастера проекта
соединений служб SSIS.
Пакет включает следующие элементы:
 элементы потока управления - эти обязательные элементы выполняют различные функции,

поддерживают структуру и управляют порядком выполнения элементов. Основными элементами
потока управления являются задачи, контейнеры и управления очередностью. В пакете должен
быть, по крайней мере, один элемент потока управления;
 элементы потока данных - эти необязательные элементы извлекают, изменяют и загружают данные
в источники данных. Основными элементами потока данных являются источники, преобразования
и назначения. Присутствие каких-либо элементов потока данных в пакете необязательно.
5.3.1. Элементы потока управления

Пакет состоит из потока управления, а также может включать один или более потоков данных. Службы SSIS
предоставляют три различных типа элементов потока управления: контейнеры, которые обеспечивают
структуры в пакетах; задачи, которые обеспечивают функциональность; элементы управления
очередностью, соединяющие выполняемые компоненты, контейнеры и задачи в упорядоченный поток
управления.
На Рисунок 34 приведен пример потока управления, который имеет один контейнер и шесть задач. Пять
задач пакетного уровня и одна задача уровня контейнера. Задача находится в контейнере.
57
Рисунок 34. Пример потока управления
5.3.1.1. Контейнеры
Архитектура служб SSIS поддерживает вложение контейнеров, и поток управления может включать
множество уровней вложенных контейнеров. Так, пакет может содержать контейнер, например контейнер
«цикл по каждому элементу», который в свою очередь может содержать другой контейнер «цикл по
каждому элементу», и так далее.
Контейнеры обеспечивают структуру в пакетах и службах для задач в потоке управления. SSIS содержит
следующие типы контейнеров для группирования задач и внедрения повторяющихся потоков управления:
 контейнер «цикл по каждому элементу» перечисляет коллекцию данных и повторяет этот поток
управления для каждого члена коллекции;
 контейнер «цикл по элементам» повторяет это управление потоком до тех пор, пока определенное
выражение не примет значение FALSE;
 контейнер последовательности позволяет определить подмножества потока управления и

управлять задачами и контейнерами как модулями.
5.3.1.2. Задачи
Задачами называются элементы потока управления, которые определяют рабочие модули,
выполняющиеся в потоке управления пакета. Пакет служб SSIS состоит из одной или более задач. Если в
пакете несколько задач, они связаны и упорядочены в потоке управления с помощью управления
очередностью.
Можно также создавать пользовательские задачи на языке программирования, поддерживающем COM,

например на Visual Basic, или на языке программирования для платформы .NET, например на C#.
Конструктор служб SSIS — графическое средство служб SSIS для работы с пакетами — предоставляет
область конструктора для создания потока управления пакета и специальные редакторы для настройки
задач. Можно также использовать объектную модель служб SSIS для программного создания пакетов.
Службы SSIS включают в себя следующие типы задач для выполнения разнообразных функций:
 задача потока данных определяет и выполняет потоки данных, которые извлекают данные,
применяют преобразования и загружают данные;
58
 задачи подготовки данных копируют файлы и каталоги, загружают файлы и данные, сохраняют
данные, возвращенные при помощи веб-методов, или работают с XML-документами;
 задачи технологического процесса связываются с другими процессами для загрузки пакетов или
программ, отправляют и получают сообщения между пакетами, отправляют сообщения
электронной почты, считывают данные инструментария управления Windows (WMI) или наблюдают
за событиями WMI;
 задачи SQL Server позволяют получить доступ, копировать, вставлять, удалять или изменять
объекты или данные SQL Server;
 задачи служб SSAS позволяют создать, изменить, удалить или обработать объекты служб SSAS;
 задачи сценариев расширяют функциональные возможности пакета посредством использования

пользовательских сценариев;
 задачи обслуживания выполняют административные функции: резервное копирование и сжатие

баз данных SQL Server, восстановление и перестройка индексов, а также выполнение заданий
агента SQL Server.
5.3.2. Элементы потока данных

Службы SSIS предоставляют три различных типа компонентов потока данных: источники, преобразования и
целевые объекты. Источники извлекают данные из хранилищ, таких как таблицы и представления
реляционных баз данных, файлы и базы данных служб SSAS. Преобразования изменяют, объединяют и
очищают данные. Целевые объекты загружают данные в хранилища или создают наборы данных в памяти.
Кроме того, службы SSIS предоставляют пути, соединяющие выход одного компонента с входом другого.
Пути определяют последовательность компонентов и дают возможность добавлять заметки к потоку
данных или просматривать источник столбца.
На Рисунок 35 приведен пример потока данных с источником, преобразованием с одним входом и одним
выходом и целевым объектом. На диаграмме присутствуют входы, выходы, выходы ошибок, а также
входные, выходные и внешние столбцы.
59
Рисунок 35. Пример потока данных
5.3.2.1. Источники
В службах SSIS источником называется компонент потока данных, который делает данные из внешнего
источника данных доступными для других компонентов потока данных.
У источника потока данных обычно есть один стандартный выход. В стандартном выходе содержатся
выходные столбцы, которые источник добавляет к потоку данных. Стандартный выход ссылается на
внешние столбцы. Внешним называется столбец в источнике. Метаданные внешних столбцов хранят
информацию об имени исходного столбца, типе и длине хранящихся в нем данных.
Выход ошибок источника хранит те же столбцы, что и стандартный выход, а также два дополнительных
столбца, предоставляющих информацию об ошибках. Объектная модель служб SSIS не ограничивает число
стандартных выходов и выходов ошибок, которые могут быть связаны с источником. У большей части
включенных в службы SSIS источников, за исключением компонента сценария, имеется один стандартный
выход, а у многих также есть один выход ошибок. Пользовательские источники могут быть спроектированы
так, чтобы содержать несколько стандартных выходов и выходов ошибок.
Все выходные столбцы доступны в качестве входных столбцов для следующего компонента потока данных.
5.3.2.2. Преобразования
Возможности преобразований очень разнообразны. Преобразования могут выполнять такие задачи, как
обновление, очистка, слияние и распространение данных и сбор статистики о них.
60
Входы и выходы преобразований определяют столбцы входных и выходных данных. В зависимости от
выполняемых операций над данными у одних преобразований может быть один вход и несколько
выходов, а у других — несколько входов и один выход. У преобразований также могут быть выходы
ошибок, которые предоставляют информацию о произошедших ошибках, и сами данные, вызвавшие
ошибку: например, строковые данные, которые не могут быть преобразованы в целое число. Объектная
модель служб SSIS не ограничивает число входов, стандартных выходов и выходов ошибок, которые могут
быть связаны с преобразованием. Пользовательские преобразования могут реализовывать любое
сочетание входов, стандартных выходов и выходов ошибок.
Вход преобразования определяется как один или более входных столбцов. Некоторые преобразования
служб SSIS также могут ссылаться на внешние входные столбцы. Например, вход преобразования
«Команда OLE DB» включает в себя внешние столбцы. Выходным называется столбец, который
добавляется преобразованием в поток данных. И стандартные выходы, и выходы ошибок содержат
выходные столбцы. Эти выходные столбцы, в свою очередь, служат входными столбцами для следующего
компонента потока данных: или другого преобразования, или целевого объекта.
5.3.2.3. Целевые объекты (назначения)

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

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

У источников есть выходы, у целевых объектов — входы, а у преобразований есть и входы, и выходы.
Кроме того, многие компоненты потока данных могут быть настроены для использования выхода ошибок.
61
Вход содержит один или более входных столбцов, которые могут ссылаться на внешние столбцы, если
компонент потока данных настроен так, чтобы использовать их. Входы могут быть настроены для контроля
над потоком данных и управления им: например, можно определить, что компонент должен прервать
нормальный ход работы в ответ на ошибку, или пропускать ошибки, или перенаправлять строки,
содержащие ошибки, на вывод ошибок. Можно также задавать описание входа или обновлять имя входа.
Выход содержит один или более выходных столбцов, которые могут ссылаться на внешние столбцы, если
компонент потока данных настроен так, чтобы использовать их. Выходы могут предоставлять информацию,
полезную при последующей обработке данных. Например, можно указать, что данные на выходе
отсортированы. Можно также задавать описание выхода или обновлять имя выхода.
Можно определить, как компонент потока данных будет реагировать на ошибки в каждом входном и
выходном столбце. Если во время выполнения произошла ошибка или усечение данных, а компонент
потока данных настроен так, чтобы перенаправлять строки, строки данных, содержащие ошибки, будут
отправлены на выход ошибок. По умолчанию вывод ошибок содержит выходные столбцы и два столбца с
данными об ошибках: ErrorCode и ErrorColumn. Выходные столбцы содержат данные из строки с ошибкой,
ErrorCode хранит код ошибки, а ErrorColumn определяет столбец, в котором произошла ошибка.
5.3.2.6. Пути
Пути соединяют компоненты потока данных. В конструкторе SSIS можно просматривать и изменять
свойства путей, просматривать выходные метаданные для начальной точки пути и связывать с путем
средства просмотра данных.
6.3.2.7. Настройка компонентов потока данных

Компоненты потока данных могут настраиваться на уровне компонента в целом; на уровне входа, выхода и
выхода ошибок, а также на уровне столбцов:
1. на уровне компонента определяются общие для всех компонентов свойства, а также свойства,
характерные для конкретного компонента;
2. на уровне входа, выхода и выхода ошибок определяются общие свойства входов, выходов и
выходов ошибок компонента. Если компонент поддерживает работу с несколькими выходами, то
их можно добавить;
3. на уровне столбцов в дополнение к общим для всех столбцов свойствам задаются характерные
свойства, предоставляемые компонентом для столбцов. Если компонент поддерживает
добавление выходных столбцов, то их можно добавить к выходам;
Свойства задаются посредством конструктора служб SSIS или программно.
6. Развертывание служб SSAS
6.1. Планирование развертывания служб Analysis Services

После завершения разработки проекта служб SSAS в среде BI Dev Studio, а также после развертывания и
тестирования проекта в собственной среде разработки можно перейти к развертыванию базы данных
служб SSAS на отладочном и рабочем серверах.
62
При развертывании проекта служб SSAS необходимо ответить на следующие вопросы:
1. какие программные ресурсы и ресурсы оборудования требуются на целевом сервере?
2. как развертывать дополнительные объекты, выходящие за область проекта служб SSAS, а именно:
пакеты, отчеты или схемы реляционных баз данных служб SSIS?
3. как загружать и обновлять данные в развернутой базе данных служб SSAS?
4. как обновлять метаданные (например, вычисления) в развернутой базе данных служб SSAS?
5. нужно ли предоставлять пользователям доступ к данным служб SSAS через сеть Интернет?
6. нужно ли предоставлять запросам возможность непрерывного доступа к данным служб SSAS?
7. нужно развертывать объекты в распределенной среде при помощи связанных кубов или удаленных
секций?
8. как обеспечить безопасность данных служб SSAS?
6.1.1. Требования к ресурсам

Перед развертыванием проекта служб SSAS следует рассмотреть требования к ресурсам. В частности,
следует рассмотреть необходимые ресурсы памяти, процессора и требования к месту на диске. Сведения о
ресурсах памяти и процесса, требуемых для служб SSAS, зависящих от версии Microsoft Windows,
установленной на сервере, могут быть найдены на сайте Microsoft. В следующих случаях требуется больше
ресурсов памяти и процессора:
1. при обработке больших или сложных кубов. Для этого требуется больше ресурсов памяти и процессора
в сравнении с обработкой малых или простых кубов;
2. при увеличении количества кубов в одной базе данных;
3. при увеличении количества БД в одном экземпляре служб SSAS;
4. при увеличении количества экземпляров служб SSAS на одном компьютере;
5. при увеличении количества пользователей с одновременным доступом к ресурсам служб SSAS.
Объем требуемого места на диске зависит от различных аспектов установки служб SSAS и задач, связанных
с обработкой объектов.
Кубы с большими таблицами фактов требуют больше места на диске, чем кубы с небольшими таблицами
фактов. Аналогично, хотя и в меньшей степени, кубы с большим количеством измерений требуют большего
места на диске. Как правило, для базы данных служб SSAS требуется примерно на 20% больше объема
места на диске в сравнении с таким же объемом данных, хранящемся в базовой реляционной базе данных.
Для агрегатов требуется дополнительное место, пропорциональное добавлению самих агрегатов: чем
больше добавляется агрегатов, тем больше требуется места на диске. Если лишние агрегаты не
используются, то дополнительное место на диске, необходимое для агрегатов, обычно не должно
превышать 10% от размера данных, хранящихся в базовой реляционной базе данных.
63
По умолчанию структуры интеллектуального анализа данных кэшируют на диск набор данных, которые
использовались для обучения.
Во время обработки службы Analysis Services хранят на диске копии объектов, которые участвуют в
обработке транзакций, до завершения обработки. Затем обработанные копии объектов замещают
исходные объекты. Следовательно, необходимо предоставить значительный объем дополнительного
места на диске для второй копии обрабатываемых объектов. Например, если планируется обрабатывать в
одной транзакции весь куб, то необходимо обеспечить достаточный объем места на диске для хранения
второй копии всего куба.
6.1.2. Поддержание доступности

В среде служб SSAS куб или модель интеллектуального анализа данных могут быть недоступны для
запросов вследствие возникновения сбоев оборудования или ошибок программного обеспечения.
Поддержание доступности установки служб SSAS заключается в первую очередь в обеспечении

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

Службы SSAS предоставляют следующие средства для развертывания базы данных служб SSAS на сервер
служб SSAS в рабочей среде:
1. использование ASSL-сценария. При помощи SQL Server Management Studio создается XML-сценарий
метаданных существующей базы данных служб SSAS, затем этот сценарий запускается на другом
сервере для воссоздания начальной базы данных;
2. использование мастера развертывания служб, чтобы использовать выходные файлы формата XMLA,
созданные проектом служб SSAS для развертывания метаданных проекта на целевой сервер;
3. синхронизация баз данных служб SSAS при помощи мастера синхронизации БД;
4. функция резервного копирования и восстановления.
Сценарий развертывания XMLA, сформированный мастером развертывания служб SSAS, состоит из двух
частей:
64
1. Первая часть сценария содержит команды, необходимые для создания, изменения или удаления
соответствующих объектов служб Microsoft SQL Server в целевой базе данных. По умолчанию входные
файлы, сформированные проектом служб SSAS, основываются на добавочном развертывании. В
результате сценарий развертывания XMLA влияет только на те объекты, которые были изменены или
удалены.
2. Вторая часть сценария развертывания содержит команды, необходимые для обработки только тех
объектов, которые были созданы или изменены на целевом сервере или для полной обработки
целевой базы данных.
6.2. Настройка безопасности
6.2.1. Обеспечение безопасности служб SSAS

Чтобы обеспечить надлежащую безопасность данных, хранимых в службах SSAS, необходимо обеспечить
безопасность всех точек доступа к экземпляру служб SSAS. Эти точки доступа включают:
1. Защита компьютера со службами SSAS. Как и в случае любого приложения, наиболее простым
способом доступа к данным в службах SSAS является физическое использование компьютера, на
котором запущено приложение. Если несанкционированный пользователь получит физический доступ
к компьютеру, на котором запущены службы SSAS, то этот пользователь потенциально может получить
доступ к любым данных, хранящимся на этом компьютере, независимо от других мер безопасности,
используемых для защиты данных. Чтобы повысить физическую безопасность компьютера, на котором
запущены службы SSAS, выполните следующие шаги:
 убедитесь в том, что только санкционированные пользователи имеют физический доступ к

компьютеру. По возможности установите компьютер в запертой комнате с ограниченным
доступом;
 отключите функцию загрузки с дискеты, если это возможно в настройках BIOS материнской платы, и
рассмотрите возможность полного удаления дисковода;
 отключите функцию загрузки с CD-ROM, если это возможно в настройках BIOS материнской платы;
 увеличьте защиту компьютера путем использования пароля при включении и повысьте защиту
настроек BIOS материнской платы, используя пароль доступа к BIOS;
 используйте корпус для компьютера, который поддерживает обнаружение проникновения, и

который невозможно открыть без ключа; храните ключ в безопасном месте вдали от компьютера;
2. Защита операционной системы Windows для служб SSAS. Операционная система с неверно
выставленными параметрами безопасности может подвергнуть риску безопасность экземпляра служб
SSAS. Следующие мероприятия позволят повысить защищенность операционной системы:
 ограничение интерактивного доступа;
 ограничение сетевого доступа;
 отключение ненужных служб;

65
 указание и ограничение портов. Экземпляр по умолчанию служб SSAS осуществляет прослушивание
порта 2383. Если именованный экземпляр использует другой порт, то этот порт нужно открыть на
межсетевом экране;
 предоставление прав локального администрирования. Только члены группы локальных

администраторов обладают правом запускать, останавливать и настраивать службы Microsoft
Windows. Чтобы предоставить пользователям, ответственным за управление всем экземпляром
служб SSAS, права на управление службами Windows, необходимыми для экземпляра служб SSAS,
этих пользователей следует сделать членами группы локальных администраторов.
3. Защита программных файлов, общих компонентов и файлов данных. Местоположение по умолчанию

для файлов служб SSAS — «\Program Files\Microsoft SQL Server\MSAS10.#\OLAP», где # представляет
собой номер экземпляра. В этой структуре папок имеются четыре вложенные папки: Backup, Bin, Data и
Log. В этих папках хранятся данные резервного копирования, важные файлы для самой службы SSAS,
фактические данные измерений и кубов, а также данные журналов. Эти данные должны быть
защищены. Программа установки предоставляет доступ ко всем файлам в этой структуре папок только
членам локальной группы «Администраторы» и учетной записи входа в службы SSAS. Пользователям
доступ к файлам в этих папках не требуется.
4. Безопасность взаимодействия клиентов с экземпляром служб SSAS, что включает шифрование данных,
проверку подлинности клиента, установку пакетов безопасности, и указание частоты обновления кэша
ролей.
5. Защита источников данных, используемых службами SSAS. Если неавторизованные пользователи

получат доступ к источникам данных, из которых службы SSAS загружают данные, эти пользователи
будут иметь доступ к сведениям, которые хранятся в экземпляре служб SSAS. Следует ограничить
доступ к этим источникам данных. Для просмотра кубов и измерений пользователям служб SSAS не
нужны разрешения на эти источники данных.
6. Обеспечение безопасности доступа с помощью служб SSAS. Службы SSAS разрешают устанавливать
соединения только пользователям, прошедшим проверку подлинности Windows, если только не
разрешены анонимные подключения, и пользователям, которым предоставлены разрешения в
экземпляре служб SSAS. Пользователям, не имеющим разрешений, устанавливать соединения
запрещено. Службы SSAS не выполняют собственной проверки подлинности пользователей. При
проверке подлинности всех пользователей перед авторизацией доступа к данным служб SSAS или
перед предоставлением пользователям возможности выполнения административных задач службы
SSAS полагаются на операционную систему Windows.
По умолчанию любой пользователь, не являющийся членом роли сервера, не имеет разрешений служб
SSAS. Чтобы получить разрешения, член роли сервера должен сначала создать пользовательскую роль
базы данных, а затем предоставить этой роли разрешения.
Пользовательской роли базы данных могут быть предоставлены ограниченные или полные
административные разрешения в базе данных. Этой роли также могут быть предоставлены ограниченные
или полные разрешения на доступ к данным.
После создания пользовательской роли базы данных член роли сервера должен добавить
соответствующих пользователей и группы Windows. Пользователь получает разрешения в службах SSAS
только после его добавления к пользовательской роли базы данных.
66
6.2.2. Настройка безопасности служб SSAS
После установки экземпляра служб SSAS все члены локальной группы «Администраторы» становятся
членами роли сервера на этом экземпляре и обладают разрешениями уровня сервера для выполнения
любой задачи в пределах этого экземпляра служб SSAS. По умолчанию никакие другие пользователи не
имеют разрешений на доступ к объектам в экземпляре. Члены роли сервера служб SSAS могут
предоставлять другим пользователям доступ к объектам сервера и базы данных, используя среду SQL
Server Management Studio, среду BI Dev Studio или XMLA-сценарий.
Член роли сервера служб SSAS может предоставить другим пользователям доступ к службам SSAS
следующими способами:
1. путем предоставления пользователям административного доступа либо уровня сервера, либо

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

Административный доступ к объектам в экземпляре служб SSAS предоставляется пользователям и группам
Microsoft Windows следующими способами:
1. Пользователи и группы могут получить административный доступ к службам SSAS на уровне

сервера с помощью роли сервера. Члены роли сервера на экземпляре службSSAS имеют
неограниченный доступ ко всем объектам и данным данного экземпляра служб SSAS. Член роли
сервера служб SSAS может добавлять пользователей и группы Microsoft Windows в роль сервера
служб SSAS. Для выполнения любых задач на уровне сервера, например для создания базы данных,
изменения свойств сервера или запуска трассировки (кроме обработки событий) пользователь
должен входить в состав роли сервера служб SSAS. По умолчанию члены локальной группы
«Администраторы» входят в состав роли сервера служб SSAS. Тем не менее, их принадлежность к
этой роли сервера не отражается в пользовательском интерфейсе.
2. Пользователи и группы могут получить административный доступ к определенной базе данных

служб SSAS с помощью роли базы данных. В службах Microsoft SQL Server члены роли сервера
служб SSAS могут создавать в базе данных роли базы данных и предоставлять этим ролям полные
или ограниченные административные разрешения в базе данных. Члены роли сервера служб SSAS
могут добавлять к этим ролям базы данных пользователей и группы Microsoft Windows.
6.2.4. Разрешения, которые роль сервера служб SSAS может предоставить роли
базы данных
Роль сервера служб SSAS может предоставить роли базы данных следующие разрешения:
1. полные административные разрешения в базе данных. В качестве члена роли базы данных с
разрешениями «Полный доступ» (администратор) пользователь Windows может выполнять в
рамках базы данных любую задачу, включая следующие:
67
 обработка объектов базы данных;
 чтение данных базы данных;
 чтение метаданных базы данных;
 добавление пользователей к существующим ролям базы данных;
 создание новых ролей базы данных;
 определение разрешений для ролей базы данных.
2. только разрешение на обработку некоторых объектов служб SSAS. При предоставлении роли базы
данных разрешения на обработку объекта данных администратор получает возможность передать
задачу обработки некоторых объектов без предоставления дополнительных внешних разрешений
пользователю, выполняющему обработку. При предоставлении роли базы данных разрешений на
обработку следует иметь в виду то, что разрешения носят аддитивный характер. Например, одна
роль базы данных разрешает пользователю обрабатывать определенный куб, в то время как другая
роль базы данных предоставляет тому же пользователю разрешение на обработку измерения в
этом же кубе. Разрешения из двух различных ролей объединяются, в результате чего пользователь
получает разрешение на обработку как куба, так и заданного измерения в рамках такого куба.
Пользователь, роль базы данных которого имеет только разрешения на обработку одного или
нескольких объектов базы данных, не сможет воспользоваться средой SQL Server Management
Studio или BI Dev Studio для подключения к службам SSAS и выполнения обработки объектов. Для
данных средств необходимо, чтобы у пользователя было разрешение на доступ к метаданным
объекта. Следовательно, для обработки таких объектов пользователю, располагающему только
разрешениями на обработку объектов, необходимо будет использовать XMLA-сценарий.
Разрешения на обработку могут быть предоставлены на уровнях базы данных, куба, измерения и
структуры интеллектуального анализа данных.
3. разрешение на просмотр определения объекта служб SSAS, но не обработку объекта или

представление фактических данных. Предоставление роли базы данных разрешения на чтение
метаданных выбранных объектов позволяет администратору предоставить пользователям
разрешения на просмотр определений объектов, при этом не предоставляя этим пользователям
разрешение на изменение определения объекта, изменение структуры базы данных или просмотр
реальных данных для объекта. При предоставлении роли базы данных разрешения на чтение
метаданных следует помнить, что разрешения являются аддитивными. Например, одна роль базы
данных может предоставлять пользователю разрешение на чтение метаданных для конкретного
куба, в то время как другая роль базы данных может предоставлять тому же пользователю
разрешение на чтение метаданных для измерения в этом кубе. Разрешения из этих двух различных
ролей комбинируются, предоставляя пользователю разрешение на чтение как метаданных для
куба, так и метаданных для измерения в пределах этого куба. Чтобы просмотреть определение
объекта в среде SQL Server Management Studio или в среде BI Dev Studio, пользователь должен
иметь роль базы данных, которая предоставляет разрешение на чтение метаданных базы данных.
Контрольные вопросы
1. Опишите назначение служб Analysis Services.
68
2. Какие инструментальные средства используются для создания, управления и работы с OLAP-
кубами?
3. Каким образом устанавливаются службы Analysis Services?
4. Какие требования к файловой системе, программному и аппаратному обеспечению предъявляет

MS SQL Server 2008?
5. Какие существуют редакции SQL Server 2008?
6. В каких редакциях SQL Server 2008 предусмотрена возможность работы с хранилищами данных? В
чем заключается отличие между этими версиями с точки зрения функционала при работе с
хранилищами данных?
69

Лекции ММПР

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Лекции ММПР

Загружено:

Авторское право:

Доступные форматы

Полубояров В.В.

Использование MS SQL Server Analysis Services 2008 для построения

1. Введение в основы OLAP

1.1. Хранилища данных

1.1.1. Понятие и архитектура системы поддержки принятия решений

В соответствии с определением Gartner, бизнес-анализ (BI, Business Intelligence) – это категория

Оператор Подсистема Аналитик

Рисунок 1. Архитектура СППР

Подсистема анализа может быть построена на основе:

1. подсистемы информационно-поискового анализа на базе реляционных СУБД и статических

2. подсистемы оперативного анализа. Для реализации таких подсистем применяется технология

3. подсистемы интеллектуального анализа, реализующие методы и алгоритмы Data Mining.

1.1.2. Понятие хранилища данных

ХД – предметно-ориентированный, интегрированный, редко меняющийся, поддерживающий хронологию

Кроме возможности работать с единым источником информации, руководители и аналитики должны

Подсистема ввода Оперативный

Подсистема ввода Оперативный Хранилище Подсистема

Подсистема ввода Оперативный

Рисунок 2. Структура СППР с физическим ХД

Достоинства виртуального ХД:

 минимизация объема хранимых данных;

 работа с текущими, актуальными данными.

Недостатки виртуального ХД:

 более высокое, по сравнению с физическим ХД время обработки запросов;

 необходимость постоянной доступности всех OLTP-источников;

 снижение быстродействия OLTP-систем;

 OLTP-системы не ориентированы на хранение данных за длительный период времени, по мере

1.1.4. Проблематика построения хранилищ данных

2. эффективное хранение и обработка больших объемов данных. Построение ХД предполагает

3. организация многоуровневых справочников метаданных. Конечным пользователям СППР

4. обеспечение информационной безопасности ХД. Сводная информация о деятельности компании,

1.1.5. Витрины данных

Подсистема ввода Оперативный

Рисунок 3. Структура СППР с самостоятельными ВД

ВД содержит данные, ориентированные на конкретного пользователя, существенно меньше по объему, и

Обычно информация попадает в ВД из ХД в этом случае ВД называются зависимыми. Возможна также

Подсистема ввода Оперативный Хранилище

Рисунок 4. Структура СППР с ХД и ВД

1.2. Понятие и модель данных OLAP

1.2.1. Понятие OLAP

Основное назначение OLAP-систем – поддержка аналитической деятельности, произвольных запросов

Подсистема ввода Оперативный

Подсистема ввода Оперативный Входной Детальные Выходной Подсистема

Подсистема ввода Оперативный Репозиторий Архивные

1. детальные данные – данные, переносимые непосредственно из OLTP-подсистем. Соответствуют

 измерения – наборы данных, необходимые для описания событий (товар, продавец,

 факты – данные, отражающие сущность события (количество проданного товара, сумма

2. агрегированные (обобщенные) данные – данные, получаемые на основании детальных путем

3. метаданные – данные о данных, содержащихся в ХД. Могут описывать:

 объекты предметной области, информация о которых содержится в ХД;

 категории пользователей, использующих данные в ХД;

 места и способы хранения данных;

 действия, выполняемые над данными;

 время выполнения различных действий над данными;

 причины выполнения различных действий над данными.

1.2.3. Информационные потоки в ХД

 поток обобщения – образуется агрегированием детальных данных и их сохранением в ХД;

 архивный поток – образуется перемещением детальных данных, количество обращений к которым

 поток метаданных – образуется потоком информации о данных в репозиторий данных;

 выходной поток – образуется данными, извлекаемыми пользователями;

 обратный поток – образуется очищенными данными, записываемыми обратно в OLTP-системы.

1.3. Структура OLAP-куба

Под измерением будем понимать последовательность значений одного из анализируемых параметров.

Возможность анализа зависимостей между различными параметрами предполагает возможность