Olap в узком смысле слова трактуется как: олап кубы. Проектирование кубов данных

Синие стрелки - пути, которыми информация попадает в систему, зеленными – как информация в дальнейшем используется.

1. Информация о заказах заносится в систему 1с – dbf версия.
2. Загрузка данных «автообмен». Вообще – то это лишний шаг. Данные можно получать напрямую из dbf базы. Но программисты 1с решили что стандартный (для 1с) механизм выгрузки данных, принесет меньше вреда.
3. Раз в сутки изменения за прошедший день выгружаются в специально подготовленную базу MsSql – хранилище. Выгружается не вся информация, а только то, что нужно для кубов.

   В принципе необязательно строить «хранилище». Данные для куба можно получать напрямую из базы 1с (MsSQL или dbf). Но в моем случае из 1с данные прошлых периодов периодически удаляются и очищаются справочники. Кроме того перед загрузкой в хранилище данные немного «чистятся».

4. Происходит пересчет куба – данные попадают в куб.

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

С кубами работают сотрудники в офисе – руководство, менеджеры, маркетинг, бухгалтерия. Так же информация отправляется поставщикам и торговым представителям в разных городах области.

Любой пользователь может получить информацию разными путями:

1. Построить отчет самостоятельно на web-странице или в excel

   Сначала использовался только excel, но возникало много проблем с тем, что екселевские файлы «разбредались», нужно было получить одну «точку входа» для выбора информации.
   Поэтому был создан локальный сайт, на котором опубликованы страницы с PivotTable. Сотрудник, который хочет получить пару цифр «здесь и сейчас» заходит на этот сайт и строит отчет в нужной ему форме. Если человеку нужно использовать этот отчет в дальнейшем – он может написать заявку, чтобы его отчет опубликовали в SSRS или сам сохраняет его в excel.

2. Посмотреть стандартный отчет, опубликованный в SQL Server Reporting Services (SSRS)
3. Получить локальный куб – и вне офиса «вращать» данные с помощью excel
4. Подписаться на рассылку и получать стандартные отчеты из SSRS на e-mail
5. Отдел маркетинга кроме того использует программу CubeSlice. В ней можно создавать локальные кубы самостоятельно и гораздо удобнее, чем в excel

Локальные кубы

Иногда пользователю нужно периодически получать отчеты, содержащие большие объемы данных. Например, отдел маркетинга отправлял отчеты поставщикам в виде екселевских файлов содержащих по несколько десятков страниц.
Olap не «заточен» для получение такой информации – отчеты формировались очень долго.

Как правило, поставщику тоже неудобно работать с большими отчетами. Поэтому большая часть, попробовав работать с локальными кубами, согласилась получать отчетность в таком виде. Список отчетов, которые формировал отдел маркетинга, значительно сократился. Оставшиеся тяжелые отчеты были реализованы в SSRS, созданы подписки (отчеты формируются автоматически и рассылаются поставщикам по расписанию)

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

Конфигурация сервера:

процессор: 2xAMD Opteron 280
память: 4Gb
дисковые массивы:
операционная система: RAID 1 (зеркало) 2xSCSI 15k
данные: RAID 0+1 4xSCSI 10k

Согласитесь, такую машинку сложно назвать «мощным» сервером

Объем данных:

хранилище 10Гб, данные с 2002 года
агрегация 30%
Размер многомерной базы 350М
кол-во членов «больших измерений»: товары 25 тыс., адреса – 20 тыс.
кол-во документов в день - 400. среднее кол-во строк в документе - 30

Что в итоге получила компания:

Плюсы

• Для руководства предприятия

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

• Для менеджера

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

• Для поставщиков

  Возможность интерактивной работы с информацией

• С точки зрения it-специалиста

  Уменьшение рутинной работы. Большую часть отчетов пользователь получает самостоятельно.

Минусы:

• Стоимость внедрения. Необходимо дополнительное оборудование и программное обеспечение.
• Нехватка подготовленных специалистов. Расходы на обучение сотрудников it-отдела.

07.04.2011 Дерек Комингор

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

Что такое куб?

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

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

Куб - центральная конструкция данных в оперативной системе анализа данных OLAP аналитических служб SQL Server (SSAS). Кубы обычно строятся из основной реляционной базы данных, называемой моделью размерностей, но представляют собой отдельные технические сущности. Логически куб является складом данных, который составлен из размерностей (dimensions) и измерений (measures). Размерности содержат описательные признаки и иерархии, в то время как измерения - это факты, которые вы описываете в размерностях. Измерения объединены в логические сочетания, которые называются группами измерений. Вы привязываете размерности к группам измерений на основе признака - степени детализации.

В файловой системе куб реализован как последовательность связанных бинарных файлов. Бинарная архитектура куба облегчает быстрое извлечение больших объемов многомерных данных.

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

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

Требования к программному обеспечению

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

Мой пример куба «Продажи через Интернет» будет построен на основе тестовой базы данных AdventureWorksDW 2005. Я буду строить тестовый куб из подмножества таблиц, найденных в тестовой базе данных, которые будут полезны для анализа данных о сбыте через Интернет. На рисунке 1 представлена основная схема таблиц базы данных. Поскольку я использую версию 2005, вы можете следовать моим указаниям, применяя либо SQL Server 2005, либо SQL Server 2008.

Рисунок 1. Подмножество витрины данных Adventure Works Internet Sales

Учебную базу данных Adventure WorksDW 2005 можно найти на сайте CodePlex: msftdbprodsamples.codeplex.com. Найдите ссылку «SQL Server 2005 product sample databases are still available» (http://codeplex.com/MSFTDBProdSamples/Release/ProjectReleases.aspx?ReleaseId=4004). Учебная база данных содержится в файле AdventureWorksBI.msi (http://msftdbprodsamples.codeplex.com/releases/view/4004#DownloadId=11755).

Как уже упоминалось, необходимо иметь доступ к экземпляру SQL Server 2008 или 2005, в том числе SSAS и к компонентам Business Intelligence Development Studio (BIDS). Я буду использовать SQL Server 2008, так что вы можете увидеть некоторые тонкие различия, если используете SQL Server 2005.

Создание проекта SSAS

Первое, что вы должны сделать, - это создать проект SSAS, используя BIDS. Найдите BIDS в меню Start и далее в меню Microsoft SQL Server 2008/2005 подпункт SQL Server Business Intelligence Development Studio. При нажатии на эту кнопку запустится BIDS c экраном заставки по умолчанию. Создайте новый проект SSAS, выбрав File, New, Project. Вы увидите диалоговое окно New Project (новый проект), которое показано на экране 1. Выберите папку проекта Analysis Services Project и задайте описание этому проекту «SQLMAG_MyFirstCube». Нажмите кнопку ОК.

Когда проект будет создан, щелкните по нему правой кнопкой мыши в Solution Explorer и выберите в контекстном меню пункт свойств Properties. Теперь выберите раздел Deployment в левой части диалогового окна SQLMAG_MyFirstCube: Property Pages и проверьте установки значений для параметров Target Server и Database settings, как показано на экране 2. Если вы работаете в распределенной среде SQL Server, вам необходимо уточнить значение свойства Target Server именем сервера, на который вы собираетесь производить развертывание. Щелкните OK, когда вас устроят установленные значения параметров развертывания для данного проекта SSAS.

Определение источника данных

Первый объект, который нужно создать, - это источник данных. Объект источника данных обеспечивает схему и данные, используемые при построении связанных с кубом и расположенных в его основании объектов. Чтобы создать объект источника данных в BIDS, задействуйте мастер источников данных Data Source Wizard.

Начните работу мастера источника данных щелчком правой кнопкой мыши по папке Data Source на панели Solution Explorer, с выбора пункта New Data Source. Вы обнаружите, что создание объектов SSAS в BIDS имеет характер разработки. Сначала мастер проводит вас через процесс создания объекта и общие настройки. А затем вы открываете полученный объект SSAS в проектировщике и детально подстраиваете его, если нужно. Как только вы проходите экран приглашения, определите новое соединение с данными, нажимая кнопку New. Выберите и создайте новое соединение на основе Native OLEDB\SQL Server Native Client 10, указывающее на желательный для вас сервер SQL Server, который владеет нужным экземпляром базы данных. Вы можете использовать либо аутентификацию Windows, либо SQL Server, в зависимости от настроек окружающей среды SQL Server. Нажмите кнопку Test Connection, чтобы удостовериться, что вы правильно определили соединение с базой данных, а затем кнопку OK.

Далее следует Impersonation Infor­mation (информация о настрой­ке заимствования прав), которая, как и связь с данными, зависит от того, как устроена среда SQL Server. Заимствование прав - это контекст безопасности, на который полагается SSAS, обрабатывая свои объекты. Если вы управляете развертыванием на основном, единственном сервере (или ноутбуке), как, я полагаю, большинство читателей, вы можете просто выбрать вариант использования учетной записи службы Use the service account. Нажмите Next для завершения работы мастера источника данных и задайте AWDW2005 в качестве имени источника данных. Весьма удобно, что можно задействовать этот метод для целей тестирования, но в реальной производственной среде это не самая лучшая практика - использовать учетную запись службы. Лучше указать доменные учетные записи для заимствования прав подключения SSAS к источнику данных.

Представление источника данных

Для определенного вами источника данных на следующем шаге в процессе построения куба SSAS следует создать представление Data Source View (DSV). DSV обеспечивает возможность разделения схемы, которую ожидает ваш куб, от подобной схемы основной базы данных. В результате DSV можно использовать для того, чтобы расширить основную реляционную схему при построении куба. Некоторые из ключевых возможностей DSV для расширения схем источников данных включают именованные запросы, логические отношения между таблицами и именованные вычисляемые столбцы.

Пойдем дальше, щелкнем правой кнопкой мыши по папке DSV и выберем пункт New Data Source View, чтобы запустить мастер создания новых представлений DSV. В диалоговом окне, на шаге Select a Data Source, выберите соединение с реляционной базой данных и нажмите кнопку Next. Выберите таблицы FactInternetSales, DimProduct, DimTime, DimCustomer и щелкните кнопку с одиночной стрелкой направо, чтобы перенести эти таблицы в колонку Included. Наконец, кликните Next и завершите работу мастера, принимая имя по умолчанию и нажимая кнопку Finish.

На данном этапе у вас должно быть представление DSV, которое расположено под папкой Data Source Views в Solution Explorer. Выполните двойной щелчок по новому DSV, чтобы запустить конструктор DSV. Вы должны увидеть все четыре таблицы для данного DSV, как показано на рисунке 2.

Создание размерностей базы данных

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

Размерности базы данных и куба обеспечивают изящное решение для концепции, известной как «ролевые размерности». Ролевые размерности применяются, когда вам необходимо использовать единственную размерность в кубе многократно. Дата - прекрасный пример в данном экземпляре куба: вы будете строить единственную размерность даты и ссылаться на нее один раз для каждой даты, для которой хотите анализировать продажи через Интернет. Календарная дата будет первой размерностью, которую вы создадите. Щелкните правой кнопкой мышки по папке Dimensions в Solution Explorer и выберите пункт New Dimension, чтобы запустить мастер размерностей Dimension Wizard. Выберите пункт Use an existing table и щелкните Next на шаге выбора метода создания Select Creation Method. На шаге определения источника информации Specify Source Information укажите таблицу DimTime в раскрывающемся списке Main table и нажмите кнопку Next. Теперь, на шаге выбора признака размерности Select Dimension Attributes, вам необходимо отобрать атрибуты размерности времени. Выберите каждый атрибут, как показано на экране 3.

Нажмите Next. На завершающем шаге введите Dim Date в поле Name и нажмите кнопку Finish для завершения работы мастера размерности. Теперь вы должны увидеть новую размерность даты Dim Date, расположенную под папкой Dimensions в Solution Explorer.

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

Создание куба продаж по Интернету

Теперь, подготовив размерности базы данных, вы можете приступить к строительству куба. В Solution Explorer щелкните правой кнопкой мыши на папке Cubes и выберите New Cube для запуска мастера создания кубов Cube Wizard. В окне Select Creation Method выберите вариант использования существующих таблиц Use existing tables. Выберите таблицу FactInternetSales для Measure Group на шаге выбора таблицы групп измерения Select Measure Group Tables. Удалите флажок рядом с измерениями Promotion Key, Currency Key, Sales Territory Key и Revision Number на шаге Select Measures и нажмите Next.

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

Нажмите кнопку Next, чтобы перей­ти к шагу Completing the Wizard, и введите «Мой первый куб» в поле имени куба. Нажмите кнопку Finish, чтобы завершить процесс работы мастера создания куба.

Развертывание и обработка куба

Теперь все готово к развертыванию и обработке первого куба. Щелкните правой кнопкой мыши по значку нового куба в Solution Explorer и выберите пункт Process. Вы увидите окно с сообщением о том, что содержание представляется устаревшим. Щелкните Yes для развертывания нового куба на целевом сервере SSAS. При развертывании куба вы посылаете файл XML for Analisis (XMLA) на целевой сервер SSAS, который создает куб на самом сервере. Как уже упоминалось, обработка куба заполняет его двоичные файлы на диске данными из основного источника, а также дополнительными метаданными, которые вы добавили (размерности, измерения и настройки куба).

Как только процесс развертывания будет завершен, появляется новое диалоговое окно Process Cube. Нажмите кнопку Run, чтобы начать процесс обработки куба, который открывается окном Process Progress. При завершении обработки нажмите кнопку Close (два раза, чтобы закрыть оба диалоговых окна) для завершения процессов развертывания и обработки куба.

Теперь вы построили, развернули и обработали свой первый куб. Вы можете просматривать этот новый куб, щелкая по нему правой кнопкой мыши в окне Solution Explorer и выбирая пункт Browse. Перетащите измерения в центр сводной таблицы, а атрибуты размерностей на строки и столбцы, чтобы исследовать свой новый куб. Обратите внимание, как быстро куб отрабатывает различные запросы с агрегированием. Теперь вы можете оценить неограниченную мощь и, значит, ценность для бизнеса, куба OLAP.

Дерек Комингор ([email protected]) - старший архитектор в компании B. I. Voyage, имеющей статус Microsoft Partner в области бизнес-аналитики. Имеет звание SQL Server MVP и несколько сертификатов Microsoft

Механизм OLAP является на сегодня одним из популярных методов анализа данных. Есть два основных подхода к решению этой задачи. Первый из них называется Multidimensional OLAP (MOLAP) – реализация механизма при помощи многомерной базы данных на стороне сервера, а второй Relational OLAP (ROLAP) – построение кубов "на лету" на основе SQL запросов к реляционной СУБД. Каждый из этих подходов имеет свои плюсы и минусы. Их сравнительный анализ выходит за рамки этой статьи. Мы же опишем нашу реализацию ядра настольного ROLAP модуля.

Такая задача возникла после применения ROLAP системы, построенной на основе компонентов Decision Cube, входящих в состав Borland Delphi. К сожалению, использование этого набора компонент показало низкую производительность на больших объемах данных. Остроту этой проблемы можно снизить, стараясь отсечь как можно больше данных перед подачей их для построения кубов. Но этого не всегда бывает достаточно.

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

Схема работы

Общую схему работы настольной OLAP системы можно представить следующим образом:

Алгоритм работы следующий:

1. Получение данных в виде плоской таблицы или результата выполнения SQL запроса.
2. Кэширование данных и преобразование их к многомерному кубу.
3. Отображение построенного куба при помощи кросс-таблицы или диаграммы и т.п. В общем случае, к одному кубу может быть подключено произвольное количество отображений.

Рассмотрим как подобная система может быть устроена внутри. Начнем мы это с той стороны, которую можно посмотреть и пощупать, то есть с отображений.

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

Кросс-таблица

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

Таким образом, таблицу можно разделить на следующие элементы, с которыми мы и будем работать в дальнейшем:

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

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

При этом нужно отметить то, что полученная матрица будет сильно разреженной, почему ее организация в виде двумерного массива (вариант, лежащий на поверхности) не только нерациональна, но, скорее всего, и невозможна в связи с большой размерностью этой матрицы, для хранения которой не хватит никакого объема оперативной памяти. Например, если наш куб содержит информацию о продажах за один год, и если в нем будет всего 3 измерения – Клиенты (250), Продукты (500) и Дата (365), то мы получим матрицу фактов следующих размеров:

Кол-во элементов = 250 х 500 х 365 = 45 625 000

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

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

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

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

Подготовка данных

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

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

Библиотека компонентов CubeBase

Описанные выше идеи были положены в основу при создании библиотеки компонентов CubeBase.

TСubeSource осуществляет кэширование и преобразование данных во внутренний формат, а также предварительное агрегирование данных. Компонент TСubeEngine осуществляет вычисление гиперкуба и операции с ним. Фактически, он является OLAP-машиной, осуществляющей преобразование плоской таблицы в многомерный набор данных. Компонент TCubeGrid выполняет вывод на экран кросс-таблицы и управление отображением гиперкуба. TСubeChart позволяет увидеть гиперкуб в виде графиков, а компонент TСubePivote управляет работой ядра куба.

Сравнение производительности

Данный набор компонент показал намного более высокое быстродействие, чем Decision Cube. Так на наборе из 45 тыс. записей компоненты Decision Cube потребовали 8 мин. на построение сводной таблицы. CubeBase осуществил загрузку данных за 7сек. и построение сводной таблицы за 4 сек. При тестировании на 700 тыс. записей Decision Cube мы не дождались отклика в течение 30 минут, после чего сняли задачу. CubeBase осуществил загрузку данных за 45 сек. и построение куба за 15 сек.

На объемах данных в тысячи записей CubeBase отрабатывал в десятки раз быстрее Decision Cube. На таблицах в сотни тысяч записей – в сотни раз быстрее. А высокая производительность – один из самых важных показателей OLAP систем.

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

Концепция OLAP была описана в 1993 г. известным исследователем баз данных и автором реляционной модели данных Э. Ф. Коддом. В настоящее время поддержка OLAP реализована во многих СУБД и иных инструментах.

Куб OLAP содержит два типа данных:

· итоговые значения, значения, для которых требуется подвести итог, представляющие вычисляемые поля данных ;

· описательные сведения, представляющие измерения или размерности . Описательные сведения обычно распределяются по уровням детализации. Например: «Год», «Квартал», «Месяц» и «День» в размерности «Время». Распределение полей по уровням детализации позволяет пользователям, работающим с отчетами, выбирать требуемый уровень детализации для просмотра, начиная с итоговых данных высокого уровня и затем переходя к более подробному представлению, и наоборот.

Средства Microsoft Query также позволяют создавать кубы OLAP из запроса, который загружает данные реляционной базы данных, например Microsoft Access, при этом происходит преобразование линейной таблицы в структурную иерархию (куб).

Мастер создания куба OLAP является встроенным средством Microsoft Query. Для создания куба OLAP на основе реляционной базы данных перед запуском мастера необходимо выполнить следующие действия.

1. Определить источник данных (см. рис. 6.1).

2. С помощью Microsoft Query создать запрос, включая в него только те поля, которые будут являться либо полями данных, либо полями размерностей куба OLAP, если поле в кубе используется больше одного раза, то его необходимо включить в запрос нужное число раз.

3. На последнем шаге мастера создания запросов установить переключатель на пункте Создание куба OLAP из данного запроса (см. рис. 6.2) или после того как запрос создан средствами непосредственно Query в меню Файл выбрать команду Создать куб OLAP , после чего мастер создания куба OLAP будет запущен.

Работа мастера создания куба OLAP состоит из трех шагов.

На первом шаге мастера (см. рис. 6.6) определяются поля данных –вычисляемые поля, для которых необходимо определить итоговые значения.

Рис. 6.6. Определение полей данных

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

При создании OLAP куба можно использовать четыре итоговых функции – Сумма , Число (количество значений), Минимум , Максимум для числовых полей и одну функцию Число для всех остальных полей. Если нужно использовать несколько различных итоговых функций одного и того же поля, это поле должно быть включено в запрос нужное количество раз.

Имя вычисляемого поля можно изменить в столбце Имя поля данных .

На втором шаге мастера определяются описательные данные и их размерности (см. рис. 6.7). Для выбора поля измерения необходимо из списка Исходные поля перетащить нужное поле размерности верхнего уровня в список Измерения в область, помеченную как Перетащите сюда поля для создания размерности . Для создания куба OLAP необходимо определить хотя бы одну размерность. На этом же шаге мастера с помощью контекстного меню можно изменить имя поля размерности или уровня.

Рис. 6.7. Определение полей измерений

Поля, содержащие изолированные или обособленные данные и не принадлежащие к иерархии, можно определить как размерности с одним уровнем. Однако использование куба будет более эффективным, если некоторые из полей организованы в уровни. Чтобы создать уровень в составе размерности, перетащите поле из списка Исходные поля на поле, являющееся размерностью или уровнем. Поля, содержащие более подробные сведения, должны располагаться на более низких уровнях. Например, на рисунке 6.7 поле Должность является уровнем поля НазваниеОтдела .

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

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

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

На третьем шаге мастера определяется типа куба, создаваемого мастером, при этом возможны три варианта (см. рис. 6.8).

Рис. 6.8. Выбор типа создаваемого куба на третьем шаге мастера

· Первые два варианта предполагают создание куба при каждом открытии отчета (если куб просматривается из Excel, то речь идет о сводной таблице). В этом случае сохраняется файл запроса и файл определения куба *.oqy , содержащий инструкции по созданию куба. Файл *.oqy может быть открыт в программе Excel для создания отчетов на основе куба, а при необходимости внесения изменений в куб, можно его открыть Query для повторного запуска мастера создания куба.

По умолчанию файлы определения куба так же, как и файлы запросов, хранятся в папке профиля пользователя в Application Data\Microsoft\Que-ries. При сохранении файла *.oqy в стандартной папке, имя файла определения куба выводится на вкладке Кубы OLAP при открытии нового запроса в Microsoft Query или при выборе команды Создать запрос (меню Данные , подменю Импорт внешних данных ) в Microsoft Excel.

· В случае выбора третьего варианта типа куба Сохранение файла куба, содержащего все данные для куба , извлекаются все данные для куба и в указанном пользователем месте создается файл куба с расширением *.cub , в котором эти данные хранятся. Создание данного файла не происходит немедленно при нажатии кнопки Готово ; файл создается либо при сохранении определения куба в файле, либо при создании отчета на основе куба.

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

Отдельный файл куба *.cub следует создавать в следующих случаях:

1) для часто изменяемых интерактивных отчетов при наличии достаточного дискового пространства;

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

Довольно давно являюсь обитателем Хабра, но так и не доводилось читать статьи на тему многомерных кубов, OLAP и MDX, хотя тема очень интересная и с каждым днем становится все более актуальной.
Не секрет, что за тот небольшой промежуток времени развития баз данных, электронного учета и онлайн систем, самих данных накопилось очень много. Теперь же интерес также представляет полноценный анализ архивов, а возможно и попытка прогнозирования ситуаций для подобных моделей в будущем.
С другой стороны, большие компании даже за несколько лет, месяцев или даже недель могут накапливать настолько большие массивы данных, что даже их элементарный анализ требует неординарных подходов и жестких аппаратных требований. Такими могут быть системы обработки банковских транзакций, биржевые агенты, телефонные операторы и т.д.
Думаю, всем хорошо известны 2 разных подхода построения дизайна баз данных: OLTP и OLAP. Первый подход (Online Transaction Processing - обработка транзакций в реальном времени) рассчитан на эффективный сбор данных в реальном времени, второй же (Online Analytical Processing – аналитическая обработка в реальном времени) нацелен именно на выборку и обработку данных максимально эффективным способом.

Давайте рассмотрим основные возможности современных OLAP кубов, и какие задачи они решают (за основу взяты Analysis Services 2005/2008):

• быстрый доступ к данным
• преагрегация
• иерархии
• работа с временем
• язык доступа к многомерным данным
• KPI (Key Performance Indicators)
• дата майнинг
• многоуровневое кэширование
• поддержка мультиязычности

Итак, рассмотрим возможности OLAP кубов немного подробнее.

Немного подробнее о возможностях

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

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

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

Работа с временем
Так как в основном анализ данных происходит на временных участках, именно времени в OLAP системах выделено особое значение, а значит, просто определив для системы, где у нас тут время, в дальнейшем можно с легкостью пользоваться функциями типа Year To Date, Month To Date (период от начала года/месяца и до текущей даты), Parallel Period (в этот же день или месяц, но в прошлом году) и т.п.

Язык доступа к многомерным данным
MDX (Multidimensional Expressions) - язык запросов для простого и эффективного доступа к многомерным структурам данных. И этим все сказано – внизу будет несколько примеров.

Key Performance Indicators (KPI)
Ключевые показатели эффективности - это финансовая и нефинансовая система оценки, которая помогает организации определить достижение стратегических целей. Ключевые показатели эффективности могут быть достаточно просто определены в OLAP системах и использоваться в отчетах.

Дата майнинг
Интеллектуальный анализ данных (Data Mining) - по сути, выявление скрытых закономерностей или взаимосвязей между переменными в больших массивах данных.
Английский термин «Data Mining» не имеет однозначного перевода на русский язык (добыча данных, вскрытие данных, информационная проходка, извлечение данных/информации) поэтому в большинстве случаев используется в оригинале. Наиболее удачным непрямым переводом считается термин «интеллектуальный анализ данных» (ИАД). Впрочем, это отдельная, не менее интересная тема для рассмотрения.

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

Поддержка мультиязычности
Да-да-да. Как минимум Analysis Services 2005/2008 (правда, Enterprise Edition) нативно поддерживают мультиязычность. Достаточно привести перевод строковых параметров ваших данных, и клиенту, указавшему свой язык, будут приходить локализированные данные.

Многомерные кубы

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

Фактически, плоскость (или множество всех таких точек) и будет являться кубом, а, соответственно, Время, Товары и Покупатели – его измерениями.
Представить (и нарисовать) четырехмерный и более куб немного сложнее, но суть от этого не меняется, а главное, для OLAP систем совершенно неважно в скольких измерениях вы будете работать (в разумных пределах, конечно).

Немного MDX

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

SELECT
{ . } ON COLUMNS,
{ ., . } ON ROWS
FROM
WHERE (., .)

Что означает – хочу количество iPhone-ов, проданных в июне и июле в Мозамбике.
При этом я описываю какие именно данные я хочу и как именно я хочу их увидеть в отчете.
Красиво, не правда ли?

А вот чуть посложнее:

WITH MEMBER AverageSpend AS
. / .
SELECT
{ AverageSpend } ON COLUMNS,
{ .., .. } ON ROWS
FROM
WHERE (.)

* This source code was highlighted with Source Code Highlighter .

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

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

Заключение

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

P.S. Это мой первый пост об OLAP и первая публикацию на Хабре - буду очень признателен за конструктивный фидбек.
Update: Перенес в SQL, перенесу в OLAP как только разрешат создавать новые блоги.

Теги: Добавить метки