Многомерные кубы, OLAP и MDX. 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) когда требуется сохранить куб на сетевом сервере для обеспечения доступа к нему других пользователей при создании отчетов. Файл куба может предоставить определенные данные из исходной базы данных, опуская при этом секретные или конфиденциальные данные, доступ к которым для других пользователей требуется закрыть.

Главная Термины Статьи Курсы Опыт компаний Блог Советы Скачать Партнерам Контакты Акции

Статьи > Автоматизация бюджетирования и управленческого учета >

Александр Карпов, руководитель проекта bud-tech.ru, автор серии книг «100% практического бюджетирования» и книги «Постановка и автоматизация управленческого учета»

www.bud-tech.ru

Возможно, для кого-то использование OLAP-технологии (On-line Analytic Processing) при построении отчетности покажется какой-то экзотикой, поэтому применение OLAP-КУБа для них вовсе не является одним из важнейших требований при автоматизации бюджетирования и управленческого учета.

На самом деле очень удобно пользоваться многомерным КУБом при работе с управленческой отчетностью. При разработке форматов бюджетов можно столкнуться с проблемой многовариантности форм (подробнее об этом можно прочитать в Книге 8 «Технология постановки бюджетирования в компании» и в книге «Постановка и автоматизация управленческого учета»).

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

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

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

Причем нужно уметь отличать настоящие КУБы от имитации. Одной из таких имитаций являются сводные таблицы в MS Excel. Да, этот инструмент похож на КУБ, но на самом деле таковым не является, поскольку это статические, а не динамические таблицы. Кроме того, в них гораздо хуже реализована возможность построения отчетов, использующих элементы из иерархических справочников.

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

Следует отметить, что если создавать строки бюджетов на основе трех аналитических срезов (как в рассматриваемом примере), это позволяет создавать достаточно сложные бюджетные модели и составлять детализированные отчеты с использованием КУБа.

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

Рис. 1. Пример бюджета продаж, построенного на основе одной аналитики «Продукты» в OLAP-КУБе программного комплекса «ИНТЕГРАЛ»

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

Рис. 2. Пример бюджета продаж, построенного на основе двух аналитик «Продукты» и «Филиалы» в OLAP-КУБе программного комплекса «ИНТЕГРАЛ»

.

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

Рис. 3. Пример бюджета продаж, построенного на основе трех аналитик «Продукты», «Филиалы» и «Каналы сбыта» в OLAP-КУБе программного комплекса «ИНТЕГРАЛ»

Нужно напомнить о том, что КУБ, используемый для формирования отчетов, позволяет выводить данные в различной последовательности. На рисунке 3 бюджет продаж сначала «разворачивается» по продуктам, затем по филиалам, а потом по каналам сбыта.

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

Рис. 4. Пример бюджета продаж, построенного на основе трех аналитик «Продукты», «Каналы сбыта» и «Филиалы» в OLAP-КУБе программного комплекса «ИНТЕГРАЛ»

На рисунке 5 тот же самый бюджет продаж «разворачивается» сначала по филиалам, затем по продуктам, а потом по каналам сбыта.

Рис. 5. Пример бюджета продаж, построенного на основе трех аналитик «Филиалы», «Продукты» и «Каналы сбыта» в OLAP-КУБепрограммного комплекса «ИНТЕГРАЛ»

На самом деле это не все возможные варианты вывода бюджета продаж.

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

С точки зрения пользователя он в данном примере получает несколько управленческих отчетов (см. Рис. 1-5 ), а с точки зрения настроек в программном продукте – это один отчет. Просто с помощью КУБа его можно просматривать несколькими способами.

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

Необходимо упомянуть еще о нескольких возможностях OLAP-КУБа.

В многомерном иерархическом OLAP-КУБе есть несколько измерений: тип строки, дата, строки, справочник 1, справочник 2 и справочник 3 (см. Рис. 6 ). Естественно, в отчет выводится столько кнопок со справочниками, сколько есть в строке бюджета, содержащей максимальное количество справочников. Если ни в одной строке бюджета нет ни одного справочника, то в отчете не будет ни одной кнопки со справочниками.

Рис. 6. Измерения OLAP-КУБа программного комплекса «ИНТЕГРАЛ»

Изначально OLAP-КУБ строится по всем измерениям. По умолчанию при первоначальном построении отчета измерения расположены именно в тех областях, как показано на рисунке 6 . То есть такое измерение, как «Дата», располагается в области вертикальных измерений (измерения в области столбцов), измерения «Строки», «Справочник 1», «Справочник 2» и «Справочник 3» – в области горизонтальных измерений (измерения в области строк), а измерение «Тип строки» – в области «нераскрываемых» измерений (измерения в страничной области). Если измерение находится в последней области, то данные в отчете не будут «раскрываться» по этому измерению.

Каждое из этих измерений можно поместить в любую из трех областей. После переноса измерений отчет мгновенно перестраивается в соответствии с новой конфигурацией измерений. Например, можно поменять местами дату и строки со справочниками. Или можно в вертикальную область измерений перенести один из справочников (см. Рис. 7 ). Иными словами, отчет в OLAP-КУБе можно «крутить» и выбирать тот вариант вывода отчета, который является наиболее удобным для пользователя.

Рис. 7. Пример перестройки отчета после изменения конфигурации измерений программного комплекса «ИНТЕГРАЛ»

Конфигурацию измерений можно менять либо в основной форме КУБа, либо в редакторе карты изменений (см. Рис. 8 ). В этом редакторе также можно мышкой перетаскивать измерения из одной области в другую. Помимо этого, можно менять местами измерения в одной области.

Кроме того, в этой же форме можно настраивать некоторые параметры измерений. По каждому измерению можно настраивать расположение итогов, порядок сортировки элементов и названия элементов (см. Рис. 8 ). Также можно задавать, какое название элементов выводить в отчет: сокращенное (Name) или полное (FullName).

Рис. 8. Редактор карты измерений программного комплекса «ИНТЕГРАЛ»

Редактировать параметры измерений можно непосредственно в каждом из них (см. Рис. 9 ). Для этого нужно нажать на пиктограмму, расположенную на кнопке рядом с названием измерения.

Рис. 9. Пример редактирования справочника 1 Продукты и услуги в программном комплексе «ИНТЕГРАЛ»

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

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

Рис. 10. Пример вывода в отчете только одной продуктовой группы (папки) в программном комплексе «ИНТЕГРАЛ»

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

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

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

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

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

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

Общие сведения

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

Получение данных и обновить различия

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

С внешними базами данных не OLAP возвращаются все отдельные записи, а Excel выполняет обобщение. Следовательно базы данных OLAP дают Excel возможность анализировать значительно большие объемы внешних данных.

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

Не-OLAP данные могут быть возвращены в Microsoft Excel как диапазон внешних данных или отчет сводной таблицы или сводная диаграмма. Данные OLAP могут быть возвращены в Excel только в виде отчета сводной таблицы или сводная диаграмма.

Фоновый запрос

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

Запросы с параметрами

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

Оптимизация памяти

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

Параметры поля страницы

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

Различия в расчет

Параметры поля страницы

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

Не удается создать вычисляемое поле или вычисляемого элемента в сводной таблице на основе источника данных OLAP.

Вычисляемые поля и вычисляемые элементы

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

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

OLAP-КУБ (динамическая управленческая отчетность)

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

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

Промежуточные итоги

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

Макет и Дизайн различия

Измерения и меры

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

Поле, которое нужно переместить не может быть помещен в эту область сводной таблицы.

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

Измерения и меры

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

Группирование и разгруппирование элементов

В Excel 2000 нельзя группировать элементы в отчете сводной таблицы, основанный на исходных данных OLAP;

Переименование полей

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

Группировка и разгруппирование элементов

Для не OLAP исходных данных элементы в новом отчете сводной таблицы сначала появляются отсортированный в порядке возрастания по имени элемента.

Подробные данные

Команда Показать страницы не доступны в отчетах сводных таблиц, основанных на исходных данных OLAP.

Show Items With No Data

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

Ниже представлен список вопросов по предмету Информационные технологии в менеджменте МФПУ/МФПА «Синергия»

… – интерактивная автоматизированная система, которая помогает по…

OLAP в узком смысле слова трактуется как …

OLAP-системы (online analytical processing) – это …

OLTP-системы оказались мало пригодны потому что …

Автоматизированная система управления (автоматизированная информа…

В программе MS Project …

В системе OLTP обновления данных происходит…

Диаграмма, предназначенная для анализа плана работ с помощью мето…

Информационная система – это множество взаимосвязанных элементов …

Информационная технология – это …

Информационное обеспечение – это …

Информационные технологии на развитие общества влияют следующим о…

Информационный обмен в структуре органов управления организации о…

Исполнительские информационные системы (Executive Information Sys…

К признакам «малых» информационных систем относится …

К признакам информационных систем «среднего» масштаба относят …

Методы обработки информации представляют собой …

Модульный принцип построения бухгалтерских информационных систем …

На рисунке приведен фрагмент диаграммы типа …, выполненной в про…

На сетевом графике в программе MS Project задачу из внешнего прое…

На сетевом графике в программе MS Project задачу, не относящуюся …

На сетевом графике в программе MS Project задачу, являющуюся заве…

На сетевом графике в программе MS Project сводную задачу, объедин

На состав и количество автоматизированных рабочих мест, входящих …

Наука об информационной деятельности, ин¬формационных процессах и…

Организация информационной системы, при которой на удаленном серв…

Основное назначение системы OLAP заключается в …

Основным назначением ERP-систем является автоматизация …

Основным назначением методологии MPS является …

Основными характеристиками OLAP-систем является …

Подсистема технического обеспечения включает в себя …

Последовательность технологических этапов по модификации первично…

При сетевом объединении персональных компьютеров в виде внутрипро…

Прикладное программное обеспечение ЭВМ предназначено для …

Примером предметной информационной технологии является технология…

Процесс поддержки принятия решения подразумевает под собой …

Сеть Масштаба Предприятия или Корпоративная Сеть – это информацио…

Система искусственного интеллекта представляет собой …

Системы обработки трансакций – это системы предназначенные для …

Системы обработки трансакций соответствуют …

Системы поддержки принятия решений (Decision Support Systems – DS…

Современные методы и средства анализа и планирования процессов пр…

Создание интегрированной автоматизированной информационной систем…

Созданные информационные системы становятся не пригодными для исп…

Специфика информационной системы поддержки руководства проявляетс…

Средствами традиционных OLTP-систем можно …

Структура корпоративных информационных систем является …

Ускорить и упростить работу менеджеров по персоналу на фирме позв..

Ускорить и упростить работу менеджеров по персоналу на фирме позв…

Фиксируемые воспринимаемые факты окружающего мира представляют со…

Цепочка действий, наиболее точно отражающую процесс управления пр…

Экономические задачи, решаемые в диалоговом режиме, характеризуют…

Экспертные системы предназначены для обработки …

Является нарушением безопасности или относится к сфере безопаснос…

OLAP — это просто

Удивительное — рядом …

По ходу работы мне часто требовалось делать сложные отчеты, я все время пытался найти в них что-то общее, чтобы составлять их более просто и универсально, даже написал и опубликовал по этому поводу статью «Дерево Осипова». Однако мою статью раскритиковали и сказали, что все те проблемы, которые я поднял, давно уже решены в OLAP (www.molap.rgtu.ru) и порекомендовали посмотреть сводные таблицы в EXCEL.
Это оказалось настолько простым, что приложив к этому свои гениальные ручонки, у меня получилась очень простая схема для выгрузки данных из 1С7 или любой другой базы данных (в дальнейшем под 1С подразумевается любая база данных) и анализа в OLAP.
Я думаю, многие схемы выгрузки в OLAP слишком усложнены, я выбираю простоту.

Характеристики :

1. Для работы требуется только EXCEL 2000.
2. Пользователь сам может конструировать отчеты без программирования.
3. Выгрузка из 1С7 в простом формате текстового файла.
4. Для бухгалтерских проводок уже имеется универсальная обработка для выгрузки, работающая в любой конфигурации. Для выгрузки других данных имеются обработки-образцы.
5. Можно заранее сконструировать формы отчетов, а затем применять их к разным данным без их повторного конструирования.
6. Довольно хорошая производительность. На первом длительном этапе данные сначала импортируются в EXCEL из текстового файла и строится куб OLAP, а затем довольно быстро на основе этого куба может быть построен любой отчет. Например, данные о продажах товара по магазину за 3 месяца с ассортиментом 6000 товаров, загружаются в EXCEL 8 минут на Cel600-128M, рейтинг по товарам и группам (OLAP-отчет) пересчитывается за 1 минуту.
7. Данные выгружаются из 1С7 полностью за указанный период (все движения, по всем складам, фирмам, счетам). При импорте в EXCEL возможно использование фильтров, загружающих для анализа только нужные данные (например, из всех движений, только продажи).
8. В настоящее время разработаны способы анализа движений или остатков, но не движений и остатков вместе, хотя это в принципе возможно.

Что такое OLAP : (www.molap.rgtu.ru)

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

Дата — дата операции
Месяц — месяц операции
Неделя — неделя операции
Вид — закуп, продажа, возврат, списание
Контрагент — внешняя организация, учавствующая в операции
Автор — человек, выписавший накладную

В 1С, например, одна строка этой таблицы будет соответствовать одной строке накладной, некоторые поля (Контрагент, Дата) при этом берутся из шапки накладной.

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

Эта таблица является исходной для OLAP-анализа.

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

Как использовать у себя :

Данные из дистрибутива распаковать именно в каталог c:\fixin (для торговой системы возможно в c:\reports). Прочитайте readme.txt и выполните все инструкции в нем.

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

Дата|ДеньНедели|Неделя|Год|Квартал|Месяц|Документ|Фирма|Дебет|ДтНоменклатура
|ДтГруппаНоменклатура|ДтРазделНоменклатура|Кредит|Сумма|ВалСумма|Количество
|Валюта|ДтКонтрагенты|ДтГруппаКонтрагенты|КтКонтрагенты|КтГруппаКонтрагенты|
КтРазныеОбъекты

Где под префиксами Дт(Кт) идут субконто Дебета (Кредита), Группа — это группа данного субконто (если имеется), Раздел — группа группы, Класс — группа раздела.

Для торговой системы поля могут быть такие:

Направление|ВидДвижения|ЗаНал|Товар|Количество|Цена|Сумма|Дата|Фирма
|Склад|Валюта|Документ|ДеньНедели|Неделя|Год|Квартал|Месяц|Автор
|КатегорияТовара|КатегорияДвижения|КатегорияКонтрагента|ГруппаТовара
|ВалСумма|Себестоимость|Контрагент

Для анализа данных используются таблицы "Анализ движений.xls" ("Анализ бухгалтерии.xls"). Открывая их, не отключайте макросы, иначе вы не сможете обновлять отчеты (они запускаются макросами на языке VBA). Исходные данные эти файлы берут из файлов C:\fixin\motions.txt (C:\fixin\buh.txt), в остальном они одинаковые.

Основы OLAP

Поэтому возможно, вам придется скопировать ваши данные в один из этих файлов.
Чтобы в EXCEL загрузились ваши данные, выберите или напишите свой фильтр и нажмите кнопку "Сформировать" на листе "Условия".
Листы отчетов начинаются префиксом "Отч". Перейдите на лист отчета, нажмите "Обновить" и данные отчета изменятся в соотсветсвии с последними загруженными данными.
Если вас не устраивают стандартные отчеты, есть лист ОтчШаблон. Скопируйте его в новый лист и настройте вид отчета, работая со сводной таблицей на этом листе (о работе со сводными таблицами — в любой книге по EXEL 2000). Рекомендую настраивать отчеты на небольшом наборе данных, а затем уже запускать их на большом массиве, т.к. нет никакой возможности отключить перерисовку таблиц при каждом изменении макета отчета.

Технические комментарии :

При выгрузке данных из 1С пользователь выбирает папку, куда ему выгружать файл. Я сделал это потому, что вполне вероятно в ближайшем будующем будут выгружаться несколько файлов (остатки и движения). Затем по нажатию в Проводнике кнопки "Отправить" —> "На OLAP-анализ в EXCEL 2000" данные копируются из выбранной папки в папку C:\fixin. (чтобы эта команда появилась в списке команды "Отправить" и нужно скопировать файл "На OLAP-анализ в EXCEL 2000.bat" в каталог C:\Windows\SendTo) Поэтому выгружайте данные сразу давая имена файлам motions.txt или buh.txt.

Формат текстового файла:
Первая строка текстового файла — заголовки колонок разделенные "|", остальные строки содержат значения этих колонок, разделенные "|".

Для импорта текстовых файлов в Excel используется Microsoft Query (составная часть EXCEL) для его работы необходимо наличие в каталоге импорта (C:\fixin) файла shema.ini, содержащего следующую информацию:

ColNameHeader=True
Format=Delimited(|)
MaxScanRows=3
CharacterSet=ANSI
ColNameHeader=True
Format=Delimited(|)
MaxScanRows=3
CharacterSet=ANSI

Пояснение: motions.txt и buh.txt — это название раздела, соответствует имени импортируемого файла, описывает, как импортировать текстовый файл в Эксель. Остальные параметры означают, что первая строка содержит названия колонок, разделителем колонок является "|", набор символов — Windows ANSI (для ДОС — OEM).
Тип полей определяется автоматически исходя из содержащихся в колонке данных (дата, число, строка).
Перечень полей не нужно нигде описывать — EXCEL и OLAP сами определят, какие поля содержатся в файле по заголовкам в первой строке.

Внимание, проверьте ваши региональные настройки "Панель управления" —> "Региональные настройки" . В моих обработках числа выгружаются с разделителем запятая, а даты в формате "ДД.ММ.ГГГГ".

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

Я понимаю, что любители MS SQL Server и мощных баз данных начнут ворчать, что у меня слишком все упрощено, что моя обработка загнется на годичной выборке, но в первую очередь я хочу дать преимущества OLAP-анализа для средних организаций. Я бы позиционировал этот продукт как инструмент годичного анализа для оптовых компаний, квартального анализа для розничной торговли и оперативного анализа для любой организации.

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

Описание работы в EXCEL (для пользователей):

Инструкция по использованию отчетов:
1. Отправьте на анализ выгруженные данные (уточните у администратора). Для этого нажмите правой кнопкой на папке, в которую у вас выгрузились данные из 1С и выберите команду "Отправить", затем "На OLAP-анализ в EXCEL 2000".
2. Откройте файл "Анализ движений.xls"
3. Выберите Значение фильтра, нужные вам фильтры можно дописать на закладке "Значения".
4. Нажмите кнопку "Сформировать", при этом выгруженные данные будут загружены в EXCEL.
5. После загрузки данных в EXCEL, можно смотреть различные отчеты. Для этого достаточно нажать кнопку "Обновить" в выбранном отчете. Листы с отчетами начинаются на Отч.
Внимание! После того как вы поменяете значение фильтра, нужно еще раз нажать кнопку "Сформировать", чтобы данные в EXCEL перезагрузились из файла выгрузки в соответствие с фильтрами.

Обработки из демо-примера:

Обработка motionsbuh2011.ert – последняя версия выгрузки проводок из Бухгалтерии 7.7 для анализа в Excel. В ней есть галочка «Присоединить в файл», которая позволяет выгружать данные частями по периодам, присоединяя их в один и тот же файл, а не выгружая в один и тот же файл заново:

Обработка motionswork.ert выгружает данные о продажах для анализа в Excel.

Примеры отчетов :

Шахматка по проводкам:

Загруженность операторов по видам накладных:

P.S. :

Понятно, что по аналогичной схеме можно организовать выгрузку данных из 1С8.
В 2011 году ко мне обращался пользователь, которому нужно было доработать эту обработку в 1С7, чтобы она выгружала большие объемы данных, я нашел аутсорсера и выполнил эту работу. Так что разработка вполне актуальна.

Обработка motionsbuh2011.ert доработана, чтобы справляться с выгрузкой большого объема данных.

Первое четкое определение OLAP (On-line Analytical Processing) предложено в 1993 году Е.Ф.Коддом (E.F.Codd) в статье, опубликованной при поддержке Arbor Software (теперь — Hyperion Software). Статья включала 12 правил, которые сейчас уже стали широко известными и описаны на сайте любого поставщика OLAP приложений. Позже, в 1995 году, к ним были добавлены еще шесть менее известных правил, все они были разделены на четыре группы и названы «характеристиками» (features). Вот эти правила, дающие определение OLAP приложения с комментариями Найджела Пендса (Nigel Pendse), одного из создателей сайта OLAP Report.

Основные характеристики OLAP включают:

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

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

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

4. Пакетное извлечение данных . Это правило требует, чтобы продукты предлагали как собственные базы для хранения анализируемых данных, так и динамический (live) доступ к внешним данным. Мы согласны с Коддом в этом пункте и сожалеем, что лишь немногие OLAP продукты соответствуют ему. Даже те программы, которые предлагают такие функции, редко делают их легкими и достаточно автоматизированными. В результате, Кодд поддерживает многомерное представление данных плюс частичный предварительный обсчет больших многомерных баз данных с прозрачным сквозным доступом к детальной информации. Сегодня это рассматривается как определение гибридного OLAP, которая становится наиболее популярной архитектурой, так что Кодд очень точно увидел основные тенденции в этой области.

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

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

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

Специальные характеристики

8. Обработка ненормализованных данных . Это означает возможность интеграции между ядром OLAP и ненормализованным источником данных. Кодд выделяет то, что при обновлении данных, выполненном в среде OLAP, должна быть возможность изменять ненормализованные данные во внешних системах.

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

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

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

Характеристики построения отчетов

12. Гибкое построение отчетов . Различные измерения должны выстраиваться любым способом в соответствии с потребностями пользователя. Большинство продуктов соответствует этому требованию в рамках специальных редакторов отчетов. Хотелось бы, чтобы такие же возможности были доступны и в интерактивных средствах просмотра, но это встречается значительно реже. Это — одна из причин, по которой мы предпочитаем, чтобы функционал анализа и построения отчетов был объединен в одном модуле.

1. Понятие куба olap

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

14. Автоматическое регулирование физического уровня . OLAP система должна автоматически регулировать физическую структуру для адаптации ее к типу и структуре модели.

Управление размерностью

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

16. Неограниченное число измерений и уровней агрегирования . Фактически, под неограниченным числом Кодд подразумевает 15-20, т.е. число, заведомо превышающее максимальные потребности аналитика.

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

Подробности о продуктах Hyperion — на сайте www.hyperion.ru

Версия для печати

Назад

10.8 Работа со сводными таблицами (объект PivotTable)

Объект Excel.PivotTable, программная работа со сводными таблицами и кубами OLAP в Excel средствами VBA, объект PivotCache, создание макета сводной таблицы

В процессе работы большинства предприятий накапливаются так называемые необработанные данные (raw data) о деятельности. Например, для торгового предприятия могут накапливаться данные о продажах товаров - по каждой покупке отдельно, для предприятий сотовой связи - статистика нагрузки на базовые станции и т.п. Очень часто менеджменту предприятия необходима аналитическая информация, которая генерируется на основе необработанной - например, посчитать вклад каждого вида товара в доходы предприятия или качество обслуживания в зоне данной станции. Из необработанной информации такие сведения извлечь очень тяжело: нужно выполнять очень сложные SQL-запросы, которые выполняются долго и часто мешают текущей работе. Поэтому все чаще в настоящее время необработанные данные сводятся вначале в хранилище архивных данных - Data Warehouse, а затем - в кубы OLAP, которые очень удобны для интерактивного анализа. Проще всего представить себе кубы OLAP как многомерные таблицы, в которых вместо стандартных двух измерений (столбцы и строки, как в обычных таблицах), измерений может быть очень много. Обычно для описания измерений в кубе используется термин «в разрезе». Например, отделу маркетинга может быть нужна информация во временном разрезе, в региональном разрезе, в разрезе типов продукта, в разрезе каналов продаж и т.п. При помощи кубов (в отличие от стандартных SQL-запросов) очень просто получать ответы на вопросы типа «сколько товаров такого-то типа было продано в четвертом квартале прошлого года в Северо-Западном регионе через региональных дистрибьюторов.

Конечно же, в обычных базах данных такие кубы не создать. Для работы с кубами OLAP требуются специализированные программные продукты. Вместе с SQL Server поставляется база данных OLAP от Microsoft, которая называется Analysis Services. Есть OLAP-решения от Oracle, IBM, Sybase и т.п.

Для работы с такими кубами в Excel встроен специальный клиент.

По-русски он называется Сводная таблица (на графическом экране он доступен через меню Данные -> Сводная таблица ), а по-английски - Pivot Table . Соответственно, объект, который представляет этот клиент, называется PivotTable. Необходимо отметить, что он умеет работать не только с кубами OLAP, но и с обычными данными в таблицах Excel или баз данных, но многие возможности при этом теряются.

Сводная таблица и объект PivotTable - это программные продукты фирмы Panorama Software, которые были приобретены Microsoft и интегрированы в Excel.

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

Как выглядит программная работа со сводной таблицей?

Первое, что нам потребуется сделать - создать объект PivotCache, который будет представлять набор записей, полученных с источника OLAP. Очень условно этот объект PivotCache можно сравнить с QueryTable. Для каждого объекта PivotTable можно использовать только один объект PivotCache. Создание объекта PivotCache производится при помощи метода Add() коллекции PivotCaches:

Dim PC1 As PivotCache

Set PC1 = ActiveWorkbook.PivotCaches.Add(xlExternal)

PivotCaches - стандартная коллекция, и из методов, которые заслуживают подробного рассмотрения, в ней можно назвать только метод Add(). Этот метод принимает два параметра:

• SourceType - обязательный, определяет тип источника данных для сводной таблицы. Можно указать создание PivotTable на основе диапазона в Excel, данных из базы данных, во внешнем источнике данных, другой PivotTable и т.п. На практике обычно OLAP есть смысл использовать только тогда, когда данных много - соответственно нужно специализированное внешнее хранилище (например, Microsoft Analysis Services). В этой ситуации выбирается значение xlExternal.
• SourceData - обязательный во всех случаях, кроме тех, когда значение первого параметра - xlExternal. Собственно говоря, определяет тот диапазон данных, на основе которого и будет создаваться PivotTable. Обычно принимает объект Range.

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

• ADOConnection - возможность возвратить объект ADO Connection, который автоматически создается для подключения к внешнему источнику данных. Используется для дополнительной настройки свойств подключения.
• Connection - работает точно так же, как и одноименное свойство объекта QueryTable. Может принимать строку подключения, готовый объект Recordset, текстовый файл, Web-запрос. файл Microsoft Query. Чаще всего при работе с OLAP прописывается строка подключения напрямую (поскольку получать объект Recordset, например для изменения данных, большого смысла нет - источники данных OLAP практически всегда доступны только на чтение). Например, настройка этого свойства для подключения к базе данных Foodmart (учебная база данных Analysis Services) на сервере LONDON может выглядеть так:

PC1.Connection = «OLEDB;Provider=MSOLAP.2;Data Source=LONDON1;Initial Catalog = FoodMart 2000»

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

PC1.CommandType = xlCmdCube

PC1.CommandText = Array(«Sales»)

• свойство LocalConnection позволяет подключиться к локальному кубу (файлу *.cub), созданному средствами Excel. Конечно, такие файлы для работы с «производственными» объемами данных использовать очень не рекомендуется - только для целей создания макетов и т.п.
• свойство MemoryUsed возвращает количество оперативной памяти, используемой PivotCache. Если PivotTable на основе этого PivotCache еще не создана и не открыта, возвращает 0. Можно использовать для проверок, если ваше приложение будет работать на слабых клиентах.
• свойство OLAP возвращает True, если PivotCache подключен к серверу OLAP.
• OptimizeCache - возможность оптимизировать структуру кэша. Изначальная загрузка данных будет производиться дольше, но потом скорость работы может возрасти. Для источников OLE DB не работает.

Остальные свойства объекта PivotCache совпадают с аналогичными свойствами объекта QueryTable, и поэтому здесь рассматриваться не будут.

Главный метод объекта PivotCache - это метод CreatePivotTable(). При помощи этого метода и производится следующий этап - создание сводной таблицы (объекта PivotTable). Этот метод принимает четыре параметра:

• TableDestination - единственный обязательный параметр.

  Принимает объект Range, в верхний левый угол которого будет помещена сводная таблица.

• TableName - имя сводной таблицы. Если не указано, то автоматически сгенерируется имя вида «СводнаяТаблица1».
• ReadData - если установить в True, то все содержимое куба будет автоматически помещено в кэш. С этим параметром нужно быть очень осторожным, поскольку неправильное его применение может резко увеличить нагрузку на клиента.
• DefaultVersion - это свойство обычно не указывается. Позволяет определить версию создаваемой сводной таблицы. По умолчанию используется наиболее свежая версия.

Создание сводной таблицы в первой ячейке первого листа книги может выглядеть так:

PC1.CreatePivotTable Range («A1»)

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

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

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

Кроме того, это может занять определенное время. Поэтому часто требуется расположить данные в сводной таблице программным образом. Эта операция производится при помощи объекта CubeField. Главное свойство этого объекта - Orientation, оно определяет, где будет находиться то или иное поле. Например, помещаем измерение Customers в область столбцов:

PT1.CubeFields («»).Orientation = xlColumnField

Затем - измерение Time в область строк:

PT1.CubeFields («»).Orientation = xlRowField

Затем - измерение Product в область страницы:

PT1.CubeFields («»).Orientation = xlPageField

И наконец, показатель (числовые данные для анализа) Unit Sales:

PT1.CubeFields(«.»).Orientation = xlDataField

Теперь сводная таблица создана и с ней вполне можно работать. Однако часто необходимо выполнить еще одну операцию - раскрыть нужный уровень иерархии измерения. Например, если нас интересует поквартальный анализ, то нужно раскрыть уровень Quarter измерения Time (по умолчанию показывается только самый верхний уровень). Конечно, пользователь может сделать это самостоятельно, но не всегда можно рассчитывать, что он догадается, куда щелкнуть мышью. Программным образом раскрыть, например, иерархию измерения Time на уровень кварталов для 1997 года можно при помощи объектов PivotField и PivotItem:

PT1.PivotFields(«.»).PivotItems(«.»).DrilledDown = True

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

Хранилища данных (место OLAP в информационной структуре предприятия)

Термин "OLAP" неразрывно связан с термином "хранилище данных" (Data Warehouse).

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

Данные в хранилище попадают из оперативных систем (OLTP-систем), которые предназначены для автоматизации бизнес-процессов. Кроме того, хранилище может пополняться за счет внешних источников, например статистических отчетов.

Зачем строить хранилища данных - ведь они содержат заведомо избыточную информацию, которая и так "живет" в базах или файлах оперативных систем? Ответить можно кратко: анализировать данные оперативных систем напрямую невозможно или очень затруднительно. Это объясняется различными причинами, в том числе разрозненностью данных, хранением их в форматах различных СУБД и в разных "уголках" корпоративной сети. Но даже если на предприятии все данные хранятся на центральном сервере БД (что бывает крайне редко), аналитик почти наверняка не разберется в их сложных, подчас запутанных структурах. Автор имеет достаточно печальный опыт попыток "накормить" голодных аналитиков "сырыми" данными из оперативных систем - им это оказалось "не по зубам".

Таким образом, задача хранилища - предоставить "сырье" для анализа в одном месте и в простой, понятной структуре. Ральф Кимбалл в предисловии к своей книге "The Data Warehouse Toolkit" пишет, что если по прочтении всей книги читатель поймет только одну вещь, а именно: структура хранилища должна быть простой, - автор будет считать свою задачу выполненной.

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

На мой взгляд, под хранилищем можно понимать не обязательно гигантское скопление данных - главное, чтобы оно было удобно для анализа. Вообще говоря, для маленьких хранилищ предназначается отдельный термин - Data Marts (киоски данных), но в нашей российской практике его не часто услышишь.

OLAP - удобный инструмент анализа

Централизация и удобное структурирование - это далеко не все, что нужно аналитику. Ему ведь еще требуется инструмент для просмотра, визуализации информации. Традиционные отчеты, даже построенные на основе единого хранилища, лишены одного - гибкости. Их нельзя "покрутить", "развернуть" или "свернуть", чтобы получить желаемое представление данных. Конечно, можно вызвать программиста (если он захочет придти), и он (если не занят) сделает новый отчет достаточно быстро - скажем, в течение часа (пишу и сам не верю - так быстро в жизни не бывает; давайте дадим ему часа три). Получается, что аналитик может проверить за день не более двух идей. А ему (если он хороший аналитик) таких идей может приходить в голову по нескольку в час. И чем больше "срезов" и "разрезов" данных аналитик видит, тем больше у него идей, которые, в свою очередь, для проверки требуют все новых и новых "срезов". Вот бы ему такой инструмент, который позволил бы разворачивать и сворачивать данные просто и удобно! В качестве такого инструмента и выступает OLAP.

Хотя OLAP и не представляет собой необходимый атрибут хранилища данных, он все чаще и чаще применяется для анализа накопленных в этом хранилище сведений.

Компоненты, входящие в типичное хранилище, представлены на рис. 1.

Рис. 1. Структура хранилища данных

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

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

Определение и основные понятия OLAP

Для начала расшифруем: OLAP - это Online Analytical Processing, т. е. оперативный анализ данных. 12 определяющих принципов OLAP сформулировал в 1993 г. Е. Ф. Кодд - "изобретатель" реляционных БД. Позже его определение было переработано в так называемый тест FASMI, требующий, чтобы OLAP-приложение предоставляло возможности быстрого анализа разделяемой многомерной информации ().

Тест FASMI

Fast (Быстрый) - анализ должен производиться одинаково быстро по всем аспектам информации. Приемлемое время отклика - 5 с или менее.

Analysis (Анализ) - должна быть возможность осуществлять основные типы числового и статистического анализа, предопределенного разработчиком приложения или произвольно определяемого пользователем.

Shared (Разделяемой) - множество пользователей должно иметь доступ к данным, при этом необходимо контролировать доступ к конфиденциальной информации.

Multidimensional (Многомерной) - это основная, наиболее существенная характеристика OLAP.

Information (Информации) - приложение должно иметь возможность обращаться к любой нужной информации, независимо от ее объема и места хранения.

OLAP = многомерное представление = Куб

OLAP предоставляет удобные быстродействующие средства доступа, просмотра и анализа деловой информации. Пользователь получает естественную, интуитивно понятную модель данных, организуя их в виде многомерных кубов (Cubes). Осями многомерной системы координат служат основные атрибуты анализируемого бизнес-процесса. Например, для продаж это могут быть товар, регион, тип покупателя. В качестве одного из измерений используется время. На пересечениях осей - измерений (Dimensions) - находятся данные, количественно характеризующие процесс - меры (Measures). Это могут быть объемы продаж в штуках или в денежном выражении, остатки на складе, издержки и т. п. Пользователь, анализирующий информацию, может "разрезать" куб по разным направлениям, получать сводные (например, по годам) или, наоборот, детальные (по неделям) сведения и осуществлять прочие манипуляции, которые ему придут в голову в процессе анализа.

В качестве мер в трехмерном кубе, изображенном на рис. 2, использованы суммы продаж, а в качестве измерений - время, товар и магазин. Измерения представлены на определенных уровнях группировки: товары группируются по категориям, магазины - по странам, а данные о времени совершения операций - по месяцам. Чуть позже мы рассмотрим уровни группировки (иерархии) подробнее.

Рис. 2. Пример куба

"Разрезание" куба

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

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

Взгляните на рис. 3 - здесь изображен двумерный срез куба для одной меры - Unit Sales (продано штук) и двух "неразрезанных" измерений - Store (Магазин) и Время (Time).

Рис. 3. Двумерный срез куба для одной меры

На рис. 4 представлено лишь одно "неразрезанное" измерение - Store, но зато здесь отображаются значения нескольких мер - Unit Sales (продано штук), Store Sales (сумма продажи) и Store Cost (расходы магазина).

Рис. 4. Двумерный срез куба для нескольких мер

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

Рис. 5. Двумерный срез куба с несколькими измерениями на одной оси

Метки

Значения, "откладываемые" вдоль измерений, называются членами или метками (members). Метки используются как для "разрезания" куба, так и для ограничения (фильтрации) выбираемых данных - когда в измерении, остающемся "неразрезанным", нас интересуют не все значения, а их подмножество, например три города из нескольких десятков. Значения меток отображаются в двумерном представлении куба как заголовки строк и столбцов.

Иерархии и уровни

Метки могут объединяться в иерархии, состоящие из одного или нескольких уровней (levels). Например, метки измерения "Магазин" (Store) естественно объединяются в иерархию с уровнями:

Country (Страна)

State (Штат)

City (Город)

Store (Магазин).

В соответствии с уровнями иерархии вычисляются агрегатные значения, например объем продаж для USA (уровень "Country") или для штата California (уровень "State"). В одном измерении можно реализовать более одной иерархии - скажем, для времени: {Год, Квартал, Месяц, День} и {Год, Неделя, День}.

Архитектура OLAP-приложений

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

Многомерность в OLAP-приложениях может быть разделена на три уровня:

• Многомерное представление данных - средства конечного пользователя, обеспечивающие многомерную визуализацию и манипулирование данными; слой многомерного представления абстрагирован от физической структуры данных и воспринимает данные как многомерные.
• Многомерная обработка - средство (язык) формулирования многомерных запросов (традиционный реляционный язык SQL здесь оказывается непригодным) и процессор, умеющий обработать и выполнить такой запрос.
• Многомерное хранение - средства физической организации данных, обеспечивающие эффективное выполнение многомерных запросов.

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

Конкретные OLAP-продукты, как правило, представляют собой либо средство многомерного представления данных, OLAP-клиент (например, Pivot Tables в Excel 2000 фирмы Microsoft или ProClarity фирмы Knosys), либо многомерную серверную СУБД, OLAP-сервер (например, Oracle Express Server или Microsoft OLAP Services).

Слой многомерной обработки обычно бывает встроен в OLAP-клиент и/или в OLAP-сервер, но может быть выделен в чистом виде, как, например, компонент Pivot Table Service фирмы Microsoft.

Технические аспекты многомерного хранения данных

Как уже говорилось выше, средства OLAP-анализа могут извлекать данные и непосредственно из реляционных систем. Такой подход был более привлекательным в те времена, когда OLAP-серверы отсутствовали в прайс-листах ведущих производителей СУБД. Но сегодня и Oracle, и Informix, и Microsoft предлагают полноценные OLAP-серверы, и даже те IT-менеджеры, которые не любят разводить в своих сетях "зоопарк" из ПО разных производителей, могут купить (точнее, обратиться с соответствующей просьбой к руководству компании) OLAP-сервер той же марки, что и основной сервер баз данных.

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

Но, как известно, за все надо платить. И за скорость обработки запросов к суммарным данным приходится платить увеличением объемов данных и времени на их загрузку. Причем увеличение объема может стать буквально катастрофическим - в одном из опубликованных стандартных тестов полный подсчет агрегатов для 10 Мб исходных данных потребовал 2,4 Гб, т. е. данные выросли в 240 раз! Степень "разбухания" данных при вычислении агрегатов зависит от количества измерений куба и структуры этих измерений, т. е. соотношения количества "отцов" и "детей" на разных уровнях измерения. Для решения проблемы хранения агрегатов применяются подчас сложные схемы, позволяющие при вычислении далеко не всех возможных агрегатов достигать значительного повышения производительности выполнения запросов.

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

• MOLAP (Multidimensional OLAP) - и детальные данные, и агрегаты хранятся в многомерной БД. В этом случае получается наибольшая избыточность, так как многомерные данные полностью содержат реляционные.
• ROLAP (Relational OLAP) - детальные данные остаются там, где они "жили" изначально - в реляционной БД; агрегаты хранятся в той же БД в специально созданных служебных таблицах.
• HOLAP (Hybrid OLAP) - детальные данные остаются на месте (в реляционной БД), а агрегаты хранятся в многомерной БД.

Каждый из этих способов имеет свои преимущества и недостатки и должен применяться в зависимости от условий - объема данных, мощности реляционной СУБД и т. д.

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

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

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

В предыдущей статье данного цикла (см. № 2’2005) мы рассказали об основных новшествах аналитических служб SQL Server 2005. Сегодня мы подробнее рассмотрим средства создания OLAP-решений, входящие в этот продукт.

Коротко об основах OLAP

режде чем начать разговор о средствах создания OLAP-решений, напомним, что OLAP (On-Line Analytical Processing) — это технология комплексного многомерного анализа данных, концепция которой была описана в 1993 году Э.Ф.Коддом, знаменитым автором реляционной модели данных. В настоящее время поддержка OLAP реализована во многих СУБД и иных инструментах.

OLAP-кубы

Что представляют собой OLAP-данные? В качестве ответа на этот вопрос рассмотрим простейший пример. Предположим, в корпоративной базе данных некоего предприятия имеется набор таблиц, содержащих сведения о продажах товаров или услуг, и на их основе создано представление Invoices с полями Country (страна), City (город), CustomerName (название компании-клиента), Salesperson (менеджер по продажам), OrderDate (дата размещения заказа), CategoryName (категория товара), ProductName (наименование товара), ShipperName (компания-перевозчик), ExtendedPrice (оплата за товар), при этом последнее из перечисленных полей, собственно, и является объектом анализа.

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

SELECT Country, City, CustomerName, Salesperson,

OrderDate, CategoryName, ProductName, ShipperName, ExtendedPrice

FROM Invoices

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

SELECT Country, SUM (ExtendedPrice) FROM Invoices

GROUP BY Country

Результатом этого запроса будет одномерный набор агрегатных данных (в данном случае — сумм):

Country	SUM (ExtendedPrice)
Argentina	7327.3
Austria	110788.4
Belgium	28491.65
Brazil	97407.74
Canada	46190.1
Denmark	28392.32
Finland	15296.35
France	69185.48
	209373.6
	...

Если же мы хотим узнать, какова суммарная стоимость заказов, сделанных клиентами из разных стран и доставленных различными службами доставки, мы должны выполнить запрос, содержащий два параметра в предложении GROUP BY:

SELECT Country, ShipperName, SUM (ExtendedPrice) FROM Invoices

GROUP BY COUNTRY, ShipperName

Исходя из результатов этого запроса можно создать таблицу следующего вида:

Такой набор данных называется сводной таблицей (pivot table).

SELECT Country, ShipperName, SalesPerson SUM (ExtendedPrice) FROM Invoices

GROUP BY COUNTRY, ShipperName, Year

На основании результатов этого запроса можно построить трехмерный куб (рис. 1).

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

Иерархии в измерениях

Предположим, нас интересует не только суммарная стоимость заказов, сделанных клиентами в разных странах, но и суммарная стоимость заказов, сделанных клиентами в разных городах одной страны. В этом случае можно воспользоваться тем, что значения, наносимые на оси, имеют различные уровни детализации — это описывается в рамках концепции иерархии изменений. Скажем, на первом уровне иерархии располагаются страны, на втором — города. Отметим, что начиная с SQL Server 2000 аналитические службы поддерживают так называемые несбалансированные иерархии, содержащие, например, такие члены, «дети» которых содержатся не на соседних уровнях иерархии или отсутствуют для некоторых членов изменения. Типичный пример подобной иерархии — учет того факта, что в разных странах могут существовать, либо отсутствовать такие административно-территориальные единицы, как штат или область, размещающиеся в географической иерархии между странами и городами (рис. 2).

Отметим, что в последнее время принято выделять типичные иерархии, например содержащие географические или временные данные, а также поддерживать существование нескольких иерархий в одном измерении (в частности, для календарного и финансового года).

Создание OLAP-кубов в SQL Server 2005

SQL Server 2005 кубы создаются с помощью SQL Server Business Intelligence Development Studio. Этот инструмент представляет собой специальную версию Visual Studio 2005, предназначенную для решения данного класса задач (а при наличии уже установленной среды разработки список шаблонов проектов пополняется проектами, предназначенными для создания решений на основе SQL Sever и его аналитических служб). В частности, для создания решений на основе аналитических служб предназначен шаблон Analysis Services Project (рис. 3).

Для создания OLAP-куба в первую очередь следует решить, на основе каких данных его формировать. Наиболее часто OLAP-кубы строятся на основе реляционных хранилищ данных со схемами «звезда» или «снежинка» (о них мы рассказывали в предыдущей части статьи). В комплекте поставки SQL имеется пример такого хранилища — база данных AdventureWorksDW, для использования которой в качестве источника следует найти в Solution Explorer папку Data Sources, выбрать пункт контекстного меню New Data Source и последовательно ответить на вопросы соответствующего мастера (рис. 4).

Затем рекомендуется создать Data Source View — представление, на основе которого будет создаваться куб. Для этого необходимо выбрать соответствующий пункт контекстного меню папки Data Source Views и последовательно ответить на вопросы мастера. Результатом указанных действий станет схема данных, с помощью которых будет построено представление источников данных, при этом в полученной схеме вместо исходных можно указать «дружественные» имена таблиц (рис. 5).

Описанный таким образом куб можно перенести на сервер аналитических служб, выбрав из контекстного меню проекта опцию Deploy, и осуществить просмотр его данных (рис. 7).

При создании кубов в настоящее время используются многие особенности новой версии SQL Server, такие, например, как представление источников данных. Описание исходных данных для построения куба, равно как и описание структуры куба, теперь производится с помощью знакомого многим разработчикам инструмента Visual Studio, что является немалым достоинством новой версии этого продукта — изучение разработчиками аналитических решений нового инструментария в этом случае сведено к минимуму.

Отметим, что в созданном кубе можно менять состав мер, удалять и добавлять атрибуты измерений и добавлять вычисляемые атрибуты членов измерений на основе имеющихся атрибутов (рис. 8).

Рис. 8. Добавление вычисляемого атрибута

Кроме того, в кубах SQL Server 2005 можно осуществлять автоматическую группировку или сортировку членов измерения по значению атрибута, определять связи между атрибутами, реализовывать связи «многие ко многим», определять ключевые показатели бизнеса, а также решать многие другие задачи (подробности о том, как выполняются все эти действия, можно найти в разделе SQL Server Analysis Services Tutorial справочной системы данного продукта).

В последующих частях данной публикации мы продолжим знакомство с аналитическими службами SQL Server 2005 и выясним, что нового появилось в области поддержки Data Mining.