OLAP - это не отдельно взятый программный продукт, не язык программирования и даже не конкретная технология. Если постараться охватить OLAP во всех его проявлениях, то это совокупность концепций, принципов и требований, лежащих в основе программных продуктов, облегчающих аналитикам доступ к данным. Выясним, зачем аналитикам надо как-то специально облегчать доступ к данным.
Дело в том, что аналитики - это особые потребители корпоративной информации. Задача аналитика - находить закономерности в больших массивах данных . Поэтому аналитик не будет обращать внимания на отдельно взятый факт, что в четверг четвертого числа контрагенту Чернову была продана партия черных чернил - ему нужна информация о сотнях и тысячах подобных событий. Одиночные факты в базе данных могут заинтересовать, к примеру, бухгалтера или начальника отдела продаж, в компетенции которого находится сделка. Аналитику одной записи мало - ему, к примеру, могут понадобиться все сделки данного филиала или представительства за месяц, год. Заодно аналитик отбрасывает ненужные ему подробности вроде ИНН покупателя, его точного адреса и номера телефона, индекса контракта и тому подобного. В то же время данные, которые требуются аналитику для работы, обязательно содержат числовые значения - это обусловлено самой сущностью его деятельности.
Итак, аналитику нужно много данных, эти данные являются выборочными, а также носят характер "набор атрибутов - число ". Последнее означает, что аналитик работает с таблицами следующего типа:
Здесь "Страна ", "Товар ", "Год " являются атрибутами или измерениями , а "Объем продаж " - тем самым числовым значением или мерой . Задачей аналитика, повторимся, является выявление стойких взаимосвязей между атрибутами и числовыми параметрами . Посмотрев на таблицу, можно заметить, что ее легко можно перевести в три измерения: по одной из осей отложим страны, по другой - товары, по третьей - годы. А значениями в этом трехмерном массиве у нас будут соответствующие объемы продаж.
Трехмерное представление таблицы. Серым сегментом показано, что для Аргентины в 1988 году данных нет
Вот именно такой трехмерный массив в терминах OLAP и называется кубом. На самом деле, с точки зрения строгой математики кубом такой массив будет далеко не всегда: у настоящего куба количество элементов во всех измерениях должно быть одинаковым, а у кубов OLAP такого ограничения нет. Тем не менее, несмотря на эти детали, термин "кубы OLAP" ввиду своей краткости и образности стал общепринятым. Куб OLAP совсем не обязательно должен быть трехмерным. Он может быть и двух-, и многомерным - в зависимости от решаемой задачи. Особо матерым аналитикам может понадобиться порядка 20 измерений - и серьезные OLAP-продукты именно на такое количество и рассчитаны. Более простые настольные приложения поддерживают где-то 6 измерений.
Измерения OLAP-кубов состоят из так называемых меток или членов (members). Например, измерение "Страна" состоит из меток "Аргентина", "Бразилия", "Венесуэла" и так далее.
Должны быть заполнены далеко не все элементы куба: если нет информации о продажах резиновых изделий в Аргентине в 1988 году, значение в соответствующей ячейке просто не будет определено. Совершенно необязательно также, чтобы приложение OLAP хранило данные непременно в многомерной структуре - главное, чтобы для пользователя эти данные выглядели именно так. Кстати именно специальным способам компактного хранения многомерных данных, "вакуум" (незаполненные элементы) в кубах не приводят к бесполезной трате памяти.
Однако куб сам по себе для анализа не пригоден. Если еще можно адекватно представить или изобразить трехмерный куб, то с шести - или девятнадцатимерным дело обстоит значительно хуже. Поэтому перед употреблением из многомерного куба извлекают обычные двумерные таблицы . Эта операция называется "разрезанием" куба. Термин этот, опять же, образный. Аналитик как бы берет и "разрезает" измерения куба по интересующим его меткам. Этим способом аналитик получает двумерный срез куба и с ним работает. Примерно так же лесорубы считают годовые кольца на спиле.
Соответственно, "неразрезанными", как правило, остаются только два измерения - по числу измерений таблицы. Бывает, "неразрезанным" остается только измерение - если куб содержит несколько видов числовых значений, они могут откладываться по одному из измерений таблицы.
Если еще внимательнее всмотреться в таблицу, которую мы изобразили первой, можно заметить, что находящиеся в ней данные, скорее всего, не являются первичными, а получены в результате суммирования по более мелким элементам. Например, год делится на кварталы, кварталы на месяцы, месяцы на недели, недели на дни. Страна состоит из регионов, а регионы - из населенных пунктов. Наконец в самих городах можно выделить районы и конкретные торговые точки. Товары можно объединять в товарные группы и так далее. В терминах OLAP такие многоуровневые объединения совершенно логично называется иерархиями . Средства OLAP дают возможность в любой момент перейти на нужный уровень иерархии. Причем, как правило, для одних и тех же элементов поддерживается несколько видов иерархий: например день-неделя-месяц или день-декада-квартал. Исходные данные берутся из нижних уровней иерархий, а затем суммируются для получения значений более высоких уровней. Для того, чтобы ускорить процесс перехода, просуммированные значения для разных уровней хранятся в кубе. Таким образом, то, что со стороны пользователя выглядит одним кубом, грубо говоря, состоит из множества более примитивных кубов.
Пример иерархии
В этом заключается один из существенных моментов, которые привели к появлению OLAP - производительности и эффективности. Представим себе, что происходит, когда аналитику необходимо получить информацию, а средства OLAP на предприятии отсутствуют. Аналитик самостоятельно (что маловероятно) или с помощью программиста делает соответствующий SQL-запрос и получает интересующие данные в виде отчета или экспортирует их в электронную таблицу. Проблем при этом возникает великое множество. Во-первых, аналитик вынужден заниматься не своей работой (SQL-программированием) либо ждать, когда за него задачу выполнят программисты - все это отрицательно сказывается на производительности труда, повышаются штурмовщина, инфарктно-инсультный уровень и так далее. Во-вторых, один-единственный отчет или таблица, как правило, не спасает гигантов мысли и отцов русского анализа - и всю процедуру придется повторять снова и снова. В-третьих, как мы уже выяснили, аналитики по мелочам не спрашивают - им нужно все и сразу. Это означает (хотя техника и идет вперед семимильными шагами), что сервер корпоративной реляционной СУБД, к которому обращается аналитик, может задуматься глубоко и надолго, заблокировав остальные транзакции.
Концепция OLAP появилась именно для разрешения подобных проблем. Кубы OLAP представляют собой, по сути, мета-отчеты. Разрезая мета-отчеты (кубы, то есть) по измерениям, аналитик получает, фактически, интересующие его "обычные" двумерные отчеты (это не обязательно отчеты в обычном понимании этого термина - речь идет о структурах данных с такими же функциями). Преимущества кубов очевидны - данные необходимо запросить из реляционной СУБД всего один раз - при построении куба. Поскольку аналитики, как правило, не работают с информацией, которая дополняется и меняется "на лету", сформированный куб является актуальным в течение достаточно продолжительного времени. Благодаря этому, не только исключаются перебои в работе сервера реляционной СУБД (нет запросов с тысячами и миллионами строк ответов), но и резко повышается скорость доступа к данным для самого аналитика. Кроме того, как уже отмечалось, производительность повышается и за счет подсчета промежуточных сумм иерархий и других агрегированных значений в момент построения куба. То есть, если изначально наши данные содержали информацию о дневной выручке по конкретному товару в отдельно взятом магазине, то при формировании куба OLAP-приложение считает итоговые суммы для разных уровней иерархий (недель и месяцев, городов и стран).
Конечно, за повышение таким способом производительности надо платить. Иногда говорят, что структура данных просто "взрывается" - куб OLAP может занимать в десятки и даже сотни раз больше места, чем исходные данные.
Ответить на вопросы:
Что такое куб OLAP?
Что такое метки конкретного измерения? Привести примеры.
Могут ли меры в кубе OLAP, содержать нечисловые значения.
Данных, как правило, разрежённый и долговременно хранимый. Может быть реализован на основе универсальных реляционных СУБД или специализированным программным обеспечением (см. также OLAP). В программных продуктах компании SAP используется термин «инфокуб».
Индексам массива соответствуют измерения (dimensions) или оси куба, а значениям элементов массива - меры (measures) куба.
w : (x ,y ,z ) → w xyz ,где x , y , z - измерения, w - мера.
В отличие от обычного массива в языке программирования, доступ к элементам- OLAP-куба может осуществляться как по полному набору индексов-измерений, так и по их подмножеству, и тогда результатом будет не один элемент, а их множество.
W : (x ,y ) → W = {w z1 , w z2 , …, w zn }Также известно описание OLAP-куба с использованием терминологии реляционной алгебры, как проекции отношений .
См. также
Wikimedia Foundation . 2010 .
- Схема звезды
- Наш дом - Россия (фракция)
Смотреть что такое "OLAP-куб" в других словарях:
OLAP куб - … Википедия
OLAP - (англ. online analytical processing, аналитическая обработка в реальном времени) технология обработки данных, заключающаяся в подготовке суммарной (агрегированной) информации на основе больших массивов данных, структурированных по… … Википедия
Куб (значения) - Куб многозначный термин: В математике В стереометрии куб шестигранный правильный многогранник В алгебре третья степень числа Фильм Серия фантастических фильмов: «Куб» «Куб 2: Гиперкуб» «Куб Ноль» Сленг и жаргон медицинское… … Википедия
Куб - У этого термина существуют и другие значения, см. Куб (значения). Куб Тип Правильный многогранник Грань квадрат … Википедия
Mondrian - OLAP Server Тип OLAP сервер Разработчик Pentaho Операционная система кроссплатформенное программное обеспечение Последняя версия 3.4.1 (2012 05 07) Лицензия свободное программное обеспечение … Википедия - Информационно аналитическая система автоматизированная система позволяющая экспертам быстро анализировать большие объемы данных, как правило является одним из элементов ситуационных центров. Так же, иногда в состав ИАС включают систему сбора… … Википедия
В цикле статей «Введение в базы данных», публиковавшемся в последнее время (см. КомпьютерПресс №3’2000 - 3’2001), мы обсуждали различные технологии и программные средства, применяемые при создании информационных систем - настольные и серверные СУБД, средства проектирования данных, средства разработки приложений, а также Business Intelligence - средства анализа и обработки данных масштаба предприятия, которые в настоящее время становятся все более популярными в мире, в том числе и в нашей стране. Отметим, однако, что вопросы применения средств Business Intelligence и технологии, используемые при создании приложений такого класса, в отечественной литературе пока еще освещены недостаточно. В новом цикле статей мы попробуем восполнить этот пробел и рассказать о том, что представляют собой технологии, лежащие в основе подобных приложений. В качестве примеров реализации мы будем использовать в основном OLAP-технологии фирмы Microsoft (главным образом Analysis Services в Microsoft SQL Server 2000), но надеемся, что основная часть материала будет полезна и пользователям других средств.
Первая статья в данном цикле посвящена основам OLAP (On-Line Analytical Processing) - технологии многомерного анализа данных. В ней мы рассмотрим концепции хранилищ данных и OLAP, требования к хранилищам данных и OLAP-средствам, логическую организацию OLAP-данных, а также основные термины и понятия, применяемые при обсуждении многомерного анализа.
Что такое хранилище данных
Информационные системы масштаба предприятия, как правило, содержат приложения, предназначенные для комплексного многомерного анализа данных, их динамики, тенденций и т.п. Такой анализ в конечном итоге призван содействовать принятию решений. Нередко эти системы так и называются - системы поддержки принятия решений.
Принять любое управленческое решение невозможно не обладая необходимой для этого информацией, обычно количественной. Для этого необходимо создание хранилищ данных (Data warehouses), то есть процесс сбора, отсеивания и предварительной обработки данных с целью предоставления результирующей информации пользователям для статистического анализа (а нередко и создания аналитических отчетов).
Ральф Кимбалл (Ralph Kimball), один из авторов концепции хранилищ данных, описывал хранилище данных как «место, где люди могут получить доступ к своим данным» (см., например, Ralph Kimball, «The Data Warehouse Toolkit: Practical Techniques for Building Dimensional Data Warehouses», John Wiley & Sons, 1996 и «The Data Webhouse Toolkit: Building the Web-Enabled Data Warehouse», John Wiley & Sons, 2000). Он же сформулировал и основные требования к хранилищам данных:
- поддержка высокой скорости получения данных из хранилища;
- поддержка внутренней непротиворечивости данных;
- возможность получения и сравнения так называемых срезов данных (slice and dice);
- наличие удобных утилит просмотра данных в хранилище;
- полнота и достоверность хранимых данных;
- поддержка качественного процесса пополнения данных.
Удовлетворять всем перечисленным требованиям в рамках одного и того же продукта зачастую не удается. Поэтому для реализации хранилищ данных обычно используется несколько продуктов, одни их которых представляют собой собственно средства хранения данных, другие - средства их извлечения и просмотра, третьи - средства их пополнения и т.д.
Типичное хранилище данных, как правило, отличается от обычной реляционной базы данных. Во-первых, обычные базы данных предназначены для того, чтобы помочь пользователям выполнять повседневную работу, тогда как хранилища данных предназначены для принятия решений. Например, продажа товара и выписка счета производятся с использованием базы данных, предназначенной для обработки транзакций, а анализ динамики продаж за несколько лет, позволяющий спланировать работу с поставщиками, - с помощью хранилища данных.
Во-вторых, обычные базы данных подвержены постоянным изменениям в процессе работы пользователей, а хранилище данных относительно стабильно: данные в нем обычно обновляются согласно расписанию (например, еженедельно, ежедневно или ежечасно - в зависимости от потребностей). В идеале процесс пополнения представляет собой просто добавление новых данных за определенный период времени без изменения прежней информации, уже находящейся в хранилище.
И в-третьих, обычные базы данных чаще всего являются источником данных, попадающих в хранилище. Кроме того, хранилище может пополняться за счет внешних источников, например статистических отчетов.
Что такое OLAP
Системы поддержки принятия решений обычно обладают средствами предоставления пользователю агрегатных данных для различных выборок из исходного набора в удобном для восприятия и анализа виде. Как правило, такие агрегатные функции образуют многомерный (и, следовательно, нереляционный) набор данных (нередко называемый гиперкубом или метакубом), оси которого содержат параметры, а ячейки - зависящие от них агрегатные данные . Вдоль каждой оси данные могут быть организованы в виде иерархии, представляющей различные уровни их детализации. Благодаря такой модели данных пользователи могут формулировать сложные запросы, генерировать отчеты, получать подмножества данных.
Технология комплексного многомерного анализа данных получила название OLAP (On-Line Analytical Processing). OLAP - это ключевой компонент организации хранилищ данных. Концепция OLAP была описана в 1993 году Эдгаром Коддом, известным исследователем баз данных и автором реляционной модели данных (см. E.F. Codd, S.B. Codd, and C.T.Salley, Providing OLAP (on-line analytical processing) to user-analysts: An IT mandate. Technical report, 1993). В 1995 году на основе требований, изложенных Коддом, был сформулирован так называемый тест FASMI (Fast Analysis of Shared Multidimensional Information - быстрый анализ разделяемой многомерной информации), включающий следующие требования к приложениям для многомерного анализа:
- предоставление пользователю результатов анализа за приемлемое время (обычно не более 5 с), пусть даже ценой менее детального анализа;
- возможность осуществления любого логического и статистического анализа, характерного для данного приложения, и его сохранения в доступном для конечного пользователя виде;
- многопользовательский доступ к данным с поддержкой соответствующих механизмов блокировок и средств авторизованного доступа;
- многомерное концептуальное представление данных, включая полную поддержку для иерархий и множественных иерархий (это - ключевое требование OLAP);
- возможность обращаться к любой нужной информации независимо от ее объема и места хранения.
Следует отметить, что OLAP-функциональность может быть реализована различными способами, начиная с простейших средств анализа данных в офисных приложениях и заканчивая распределенными аналитическими системами, основанными на серверных продуктах. Но прежде чем говорить о различных реализациях этой функциональности, давайте рассмотрим, что же представляют собой кубы OLAP с логической точки зрения.
Многомерные кубы
В данном разделе мы более подробно рассмотрим концепцию OLAP и многомерных кубов. В качестве примера реляционной базы данных, который мы будем использовать для иллюстрации принципов OLAP, воспользуемся базой данных Northwind, входящей в комплекты поставки Microsoft SQL Server или Microsoft Access и представляющей собой типичную базу данных, хранящую сведения о торговых операциях компании, занимающейся оптовыми поставками продовольствия. К таким данным относятся сведения о поставщиках, клиентах, компаниях, осуществляющих доставку, список поставляемых товаров и их категорий, данные о заказах и заказанных товарах, список сотрудников компании. Подробное описание базы данных Northwind можно найти в справочных системах Microsoft SQL Server или Microsoft Access - здесь за недостатком места мы его не приводим.
Для рассмотрения концепции OLAP воспользуемся представлением Invoices и таблицами Products и Categories из базы данных Northwind, создав запрос, в результате которого получим подробные сведения о всех заказанных товарах и выписанных счетах:
SELECT dbo.Invoices.Country, dbo.Invoices.City, dbo.Invoices.CustomerName, dbo.Invoices.Salesperson, dbo.Invoices.OrderDate, dbo.Categories.CategoryName, dbo.Invoices.ProductName, dbo.Invoices.ShipperName, dbo.Invoices.ExtendedPrice FROM dbo.Products INNER JOIN dbo.Categories ON dbo.Products.CategoryID = dbo.Categories.CategoryID INNER JOIN dbo.Invoices ON dbo.Products.ProductID = dbo.Invoices.ProductID
В Access 2000 аналогичный запрос имеет вид:
SELECT Invoices.Country, Invoices.City, Invoices.Customers.CompanyName AS CustomerName, Invoices.Salesperson, Invoices.OrderDate, Categories.CategoryName, Invoices.ProductName, Invoices.Shippers.CompanyName AS ShipperName, Invoices.ExtendedPrice FROM Categories INNER JOIN (Invoices INNER JOIN Products ON Invoices.ProductID = Products.ProductID) ON Categories.CategoryID = Products.CategoryID;
Этот запрос обращается к представлению Invoices, содержащему сведения обо всех выписанных счетах, а также к таблицам Categories и Products, содержащим сведения о категориях продуктов, которые заказывались, и о самих продуктах соответственно. В результате этого запроса мы получим набор данных о заказах, включающий категорию и наименование заказанного товара, дату размещения заказа, имя сотрудника, выписавшего счет, город, страну и название компании-заказчика, а также наименование компании, отвечающей за доставку.
Для удобства сохраним этот запрос в виде представления, назвав его Invoices1. Результат обращения к этому представлению приведен на рис. 1 .
Какие агрегатные данные мы можем получить на основе этого представления? Обычно это ответы на вопросы типа:
- Какова суммарная стоимость заказов, сделанных клиентами из Франции?
- Какова суммарная стоимость заказов, сделанных клиентами из Франции и доставленных компанией Speedy Express?
- Какова суммарная стоимость заказов, сделанных клиентами из Франции в 1997 году и доставленных компанией Speedy Express?
Переведем эти вопросы в запросы на языке SQL (табл. 1).
Результатом любого из перечисленных выше запросов является число. Если в первом из запросов заменить параметр ‘France’ на ‘Austria’ или на название иной страны, можно снова выполнить этот запрос и получить другое число. Выполнив эту процедуру со всеми странами, мы получим следующий набор данных (ниже показан фрагмент):
| 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 |
| Germany | 209373.6 |
| … | … |
Полученный набор агрегатных значений (в данном случае - сумм) может быть интерпретирован как одномерный набор данных. Этот же набор данных можно получить и в результате запроса с предложением GROUP BY следующего вида:
SELECT Country, SUM (ExtendedPrice) FROM invoices1 GROUP BY Country
Теперь обратимся ко второму из приведенных выше запросов, который содержит два условия в предложении WHERE. Если выполнять этот запрос, подставляя в него все возможные значения параметров Country и ShipperName, мы получим двухмерный набор данных следующего вида (ниже показан фрагмент):
| ShipperName | |||
| Country | Federal Shipping | Speedy Express | United Package |
| Argentina | 1 210.30 | 1 816.20 | 5 092.60 |
| Austria | 40 870.77 | 41 004.13 | 46 128.93 |
| Belgium | 11 393.30 | 4 717.56 | 17 713.99 |
| Brazil | 16 514.56 | 35 398.14 | 55 013.08 |
| Canada | 19 598.78 | 5 440.42 | 25 157.08 |
| Denmark | 18 295.30 | 6 573.97 | 7 791.74 |
| Finland | 4 889.84 | 5 966.21 | 7 954.00 |
| France | 28 737.23 | 21 140.18 | 31 480.90 |
| Germany | 53 474.88 | 94 847.12 | 81 962.58 |
| … | … | … | … |
Такой набор данных называется сводной таблицей (pivot table) или кросс-таблицей (cross table, crosstab). Создавать подобные таблицы позволяют многие электронные таблицы и настольные СУБД - от Paradox для DOS до Microsoft Excel 2000. Вот так, например, выглядит подобный запрос в Microsoft Access 2000:
TRANSFORM Sum(Invoices1.ExtendedPrice) AS SumOfExtendedPrice SELECT Invoices1.Country FROM Invoices1 GROUP BY Invoices1.Country PIVOT Invoices1.ShipperName;
Агрегатные данные для подобной сводной таблицы можно получить и с помощью обычного запроса GROUP BY:
SELECT Country,ShipperName, SUM (ExtendedPrice) FROM invoices1 GROUP BY COUNTRY,ShipperName Отметим, однако, что результатом этого запроса будет не сама сводная таблица, а лишь набор агрегатных данных для ее построения (ниже показан фрагмент):
| Country | ShipperName | SUM (ExtendedPrice) |
| Argentina | Federal Shipping | 845.5 |
| Austria | Federal Shipping | 35696.78 |
| Belgium | Federal Shipping | 8747.3 |
| Brazil | Federal Shipping | 13998.26 |
| … | … | … |
Третий из рассмотренных выше запросов имеет уже три параметра в условии WHERE. Варьируя их, мы получим трехмерный набор данных (рис. 2).
Ячейки куба, показанного на рис. 2 , содержат агрегатные данные, соответствующие находящимся на осях куба значениям параметров запроса в предложении WHERE.
Можно получить набор двухмерных таблиц с помощью сечения куба плоскостями, параллельными его граням (для их обозначения используют термины cross-sections и slices).
Очевидно, что данные, содержащиеся в ячейках куба, можно получить и с помощью соответствующего запроса с предложением GROUP BY. Кроме того, некоторые электронные таблицы (в частности, Microsoft Excel 2000) также позволяют построить трехмерный набор данных и просматривать различные сечения куба, параллельные его грани, изображенной на листе рабочей книги (workbook).
Если в предложении WHERE содержится четыре или более параметров, результирующий набор значений (также называемый OLAP-кубом) может быть 4-мерным, 5-мерным и т.д.
Рассмотрев, что представляют собой многомерные OLAP-кубы, перейдем к некоторым ключевым терминам и понятиям, используемым при многомерном анализе данных.
Некоторые термины и понятия
Наряду с суммами в ячейках OLAP-куба могут содержаться результаты выполнения иных агрегатных функций языка SQL, таких как MIN, MAX, AVG, COUNT, а в некоторых случаях - и других (дисперсии, среднеквадратичного отклонения и т.д.). Для описания значений данных в ячейках используется термин summary (в общем случае в одном кубе их может быть несколько), для обозначения исходных данных, на основе которых они вычисляются, - термин measure, а для обозначения параметров запросов - термин dimension (переводимый на русский язык обычно как «измерение», когда речь идет об OLAP-кубах, и как «размерность», когда речь идет о хранилищах данных). Значения, откладываемые на осях, называются членами измерений (members).
Говоря об измерениях, следует упомянуть о том, что значения, наносимые на оси, могут иметь различные уровни детализации. Например, нас может интересовать суммарная стоимость заказов, сделанных клиентами в разных странах, либо суммарная стоимость заказов, сделанных иногородними клиентами или даже отдельными клиентами. Естественно, результирующий набор агрегатных данных во втором и третьем случаях будет более детальным, чем в первом. Заметим, что возможность получения агрегатных данных с различной степенью детализации соответствует одному из требований, предъявляемых к хранилищам данных, - требованию доступности различных срезов данных для сравнения и анализа.
Поскольку в рассмотренном примере в общем случае в каждой стране может быть несколько городов, а в городе - несколько клиентов, можно говорить об иерархиях значений в измерениях. В этом случае на первом уровне иерархии располагаются страны, на втором - города, а на третьем - клиенты (рис. 3).
Отметим, что иерархии могут быть сбалансированными (balanced), как, например, иерархия, представленная на рис. 3 , а также иерархии, основанные на данных типа «дата-время», и несбалансированными (unbalanced). Типичный пример несбалансированной иерархии - иерархия типа «начальник-подчиненный» (ее можно построить, например, используя значения поля Salesperson исходного набора данных из рассмотренного выше примера), представлен на рис. 4 .
Иногда для таких иерархий используется термин Parent-child hierarchy.
Существуют также иерархии, занимающие промежуточное положение между сбалансированными и несбалансированными (они обозначаются термином ragged - «неровный»). Обычно они содержат такие члены, логические «родители» которых находятся не на непосредственно вышестоящем уровне (например, в географической иерархии есть уровни Country, City и State, но при этом в наборе данных имеются страны, не имеющие штатов или регионов между уровнями Country и City; рис. 5).
Отметим, что несбалансированные и «неровные» иерархии поддерживаются далеко не всеми OLAP-средствами. Например, в Microsoft Analysis Services 2000 поддерживаются оба типа иерархии, а в Microsoft OLAP Services 7.0 - только сбалансированные. Различным в разных OLAP-средствах может быть и число уровней иерархии, и максимально допустимое число членов одного уровня, и максимально возможное число самих измерений.
Заключение
В данной статье мы ознакомились с основами OLAP. Мы узнали следующее:
- Назначение хранилищ данных - предоставление пользователям информации для статистического анализа и принятия управленческих решений.
- Хранилища данных должны обеспечивать высокую скорость получения данных, возможность получения и сравнения так называемых срезов данных, а также непротиворечивость, полноту и достоверность данных.
- OLAP (On-Line Analytical Processing) является ключевым компонентом построения и применения хранилищ данных. Эта технология основана на построении многомерных наборов данных - OLAP-кубов, оси которого содержат параметры, а ячейки - зависящие от них агрегатные данные.
- Приложения с OLAP-функциональностью должны предоставлять пользователю результаты анализа за приемлемое время, осуществлять логический и статистический анализ, поддерживать многопользовательский доступ к данным, осуществлять многомерное концептуальное представление данных и иметь возможность обращаться к любой нужной информации.
Кроме того, мы рассмотрели основные принципы логической организации OLAP-кубов, а также узнали основные термины и понятия, применяемые при многомерном анализе. И наконец, мы выяснили, что представляют собой различные типы иерархий в измерениях OLAP-кубов.
В следующей статье данного цикла мы рассмотрим типичную структуру хранилищ данных, поговорим о том, что представляет собой клиентский и серверный OLAP, а также остановимся на некоторых технических аспектах многомерного хранения данных.
КомпьютерПресс 4"2001
Аннотация: В настоящей лекции рассматриваются основы проектирования кубов данных для OLAP-хранилищ данных. На примере показана методика построения куба данных с помощью CASE-инструмента.
Цель лекции
Изучив материал настоящей лекции, вы будете знать:
- что такое куб данных в OLAP-хранилище данных ;
- как проектировать куб данных для OLAP-хранилищ данных ;
- что такое измерение куба данных ;
- как факт связан с кубом данных ;
- что такое атрибуты измерения ;
- что такое иерархия ;
- что такое метрика куба данных ;
и научитесь:
- строить многомерные диаграммы ;
- проектировать простые многомерные диаграммы .
Введение
Технология OLAP - это не отдельно взятый программный продукт , не язык программирования . Если постараться охватить OLAP во всех его проявлениях, то это совокупность концепций, принципов и требований, лежащих в основе программных продуктов, облегчающих аналитикам доступ к данным.
Аналитики являются основными потребителями корпоративной информации. Задача аналитика состоит в том, чтобы находить закономерности в больших массивах данных. Поэтому аналитик не будет обращать внимания на отдельно взятый факт , что в определенный день покупателю Иванову была продана партия шариковых авторучек, - ему нужна информация о сотнях и тысячах подобных событий. Одиночные факты в ХД могут заинтересовать, к примеру, бухгалтера или начальника отдела продаж, в компетенции которого находится сопровождение определенного контракта. Аналитику одной записи недостаточно - ему, например, может понадобиться информация обо всех контрактах точки продажи за месяц, квартал или год. Аналитика может не интересовать ИНН покупателя или его телефон, - он работает с конкретными числовыми данными, что составляет сущность его профессиональной деятельности.
Централизация и удобное структурирование - это далеко не все, что нужно аналитику. Ему требуется инструмент для просмотра, визуализации информации. Традиционные отчеты, даже построенные на основе единого ХД, лишены, однако, определенной гибкости. Их нельзя "покрутить", "развернуть" или "свернуть", чтобы получить необходимое представление данных. Чем больше "срезов" и "разрезов" данных аналитик может исследовать, тем больше у него идей, которые, в свою очередь , для проверки требуют все новых и новых "срезов". В качестве такого инструмента для исследования данных аналитиком выступает OLAP .
Хотя OLAP и не представляет собой необходимый атрибут ХД, он все чаще и чаще применяется для анализа накопленных в этом ХД сведений.
Оперативные данные собираются из различных источников, очищаются, интегрируются и складываются в ХД. При этом они уже доступны для анализа при помощи различных средств построения отчетов. Затем данные (полностью или частично) подготавливаются для OLAP -анализа. Они могут быть загружены в специальную БД OLAP или оставлены в реляционном ХД. Важнейшим элементом использования OLAP являются метаданные , т. е. информация о структуре, размещении и трансформации данных . Благодаря им обеспечивается эффективное взаимодействие различных компонентов хранилища.
Таким образом, OLAP можно определить как совокупность средств многомерного анализа данных, накопленных в ХД . Теоретически средства OLAP можно применять и непосредственно к оперативным данным или их точным копиям. Однако при этом существует риск подвергнуть анализу данные, которые для этого анализа не пригодны.
OLAP на клиенте и на сервере
В основе OLAP лежит многомерный анализ данных . Он может быть произведен с помощью различных средств, которые условно можно разделить на клиентские и серверные OLAP -средства.
Клиентские OLAP-средства представляют собой приложения, осуществляющие вычисление агрегатных данных (сумм, средних величин, максимальных или минимальных значений) и их отображение, при этом сами агрегатные данные содержатся в кэше внутри адресного пространства такого OLAP-средства .
Если исходные данные содержатся в настольной СУБД , вычисление агрегатных данных производится самим OLAP -средством. Если же источник исходных данных - серверная СУБД , многие из клиентских OLAP -средств посылают на сервер SQL -запросы, содержащие оператор GROUP BY , и в результате получают агрегатные данные, вычисленные на сервере.
Как правило, OLAP -функциональность реализована в средствах статистической обработки данных (из продуктов этого класса на российском рынке широко распространены продукты компаний Stat Soft и SPSS) и в некоторых электронных таблицах. В частности, неплохими средствами многомерного анализа обладает Microsoft Excel 2000. С помощью этого продукта можно создать и сохранить в виде файла небольшой локальный многомерный OLAP -куб и отобразить его двух- или трехмерные сечения.
Многие средства разработки содержат библиотеки классов или компонентов, позволяющие создавать приложения, реализующие простейшую OLAP -функциональность (такие, например, как компоненты Decision Cube в Borland Delphi и Borland C++Builder). Помимо этого многие компании предлагают элементы управления ActiveX и другие библиотеки, реализующие подобную функциональность.
Отметим, что клиентские OLAP -средства применяются, как правило, при малом числе измерений (обычно рекомендуется не более шести) и небольшом разнообразии значений этих параметров - ведь полученные агрегатные данные должны умещаться в адресном пространстве подобного средства, а их количество растет экспоненциально при увеличении числа измерений . Поэтому даже самые примитивные клиентские OLAP -средства, как правило, позволяют произвести предварительный подсчет объема требуемой оперативной памяти для создания в ней многомерного куба.
Многие (но не все) клиентские OLAP -средства позволяют сохранить содержимое кэша с агрегатными данными в виде файла, что, в свою очередь , позволяет не производить их повторное вычисление . Отметим, что нередко такая возможность используется для отчуждения агрегатных данных с целью передачи их другим организациям или для публикации. Типичным примером таких отчуждаемых агрегатных данных является статистика заболеваемости в разных регионах и в различных возрастных группах, которая является открытой информацией, публикуемой министерствами здравоохранения различных стран и Всемирной организацией здравоохранения. При этом собственно исходные данные, представляющие собой сведения о конкретных случаях заболеваний, являются конфиденциальными данными медицинских учреждений и ни в коем случае не должны попадать в руки страховых компаний и тем более становиться достоянием гласности.
Идея сохранения кэша с агрегатными данными в файле получила свое дальнейшее развитие в серверных OLAP-средствах, в которых сохранение и изменение агрегатных данных, а также поддержка содержащего их хранилища осуществляются отдельным приложением или процессом, называемым OLAP-сервером . Клиентские приложения могут запрашивать подобное многомерное хранилище и в ответ получать те или иные данные. Некоторые клиентские приложения могут также создавать такие хранилища или обновлять их в соответствии с изменившимися исходными данными.
Преимущества применения серверных OLAP -средств по сравнению с клиентскими OLAP -средствами сходны с преимуществами применения серверных СУБД по сравнению с настольными: в случае применения серверных средств вычисление и хранение агрегатных данных происходит на сервере, а клиентское приложение получает лишь результаты запросов к ним, что позволяет в общем случае снизить сетевой трафик, время выполнения запросов и требования к ресурсам, потребляемым клиентским приложением. Отметим, что средства анализа и обработка данных масштаба предприятия, как правило, базируются именно на серверных OLAP -средствах, например, таких как Oracle Express Server , Microsoft SQL Server 2000 Analysis Services, Hyperion Essbase, продуктах компаний Crystal Decisions, Business Objects, Cognos, SAS Institute. Поскольку все ведущие производители серверных СУБД производят (либо лицензировали у других компаний) те или иные серверные OLAP -средства, выбор их достаточно широк, и почти во всех случаях можно приобрести OLAP - сервер того же производителя, что и у самого сервера баз данных.
Отметим, что многие клиентские OLAP -средства (в частности, Microsoft Excel 2003, Seagate Analysis и др.) позволяют обращаться к серверным OLAP-хранилищам , выступая в этом случае в роли клиентских приложений, выполняющих подобные запросы. Помимо этого имеется немало продуктов, представляющих собой клиентские приложения к OLAP -средствам различных производителей.
Технические аспекты многомерного хранения данных
В многомерных ХД содержатся агрегатные данные различной степени подробности, например, объемы продаж по дням, месяцам, годам, по категориям товаров и т.п. Цель хранения агрегатных данных - сократить время выполнения запросов, поскольку в большинстве случаев для анализа и прогнозов интересны не детальные, а суммарные данные. Поэтому при создании многомерной базы данных всегда вычисляются и сохраняются некоторые агрегатные данные.
Отметим, что сохранение всех агрегатных данных не всегда оправданно. Дело в том, что при добавлении новых измерений объем данных, составляющих куб, растет экспоненциально (иногда говорят о "взрывном росте" объема данных). Если говорить более точно, степень роста объема агрегатных данных зависит от количества измерений куба и членов измерений на различных уровнях иерархий этих измерений . Для решения проблемы "взрывного роста" применяются разнообразные схемы, позволяющие при вычислении далеко не всех возможных агрегатных данных достичь приемлемой скорости выполнения запросов.
Как исходные, так и агрегатные данные могут храниться либо в реляционных, либо в многомерных структурах. Поэтому в настоящее время применяются три способа хранения данных.
- MOLAP ( Multidimensional OLAP) - исходные и агрегатные данные хранятся в многомерной базе данных. Хранение данных в многомерных структурах позволяет манипулировать данными как многомерным массивом, благодаря чему скорость вычисления агрегатных значений одинакова для любого из измерений . Однако в этом случае многомерная база данных оказывается избыточной, так как многомерные данные полностью содержат исходные реляционные данные.
- ROLAP (Relational OLAP) - исходные данные остаются в той же реляционной базе данных, где они изначально и находились. Агрегатные же данные помещают в специально созданные для их хранения служебные таблицы в той же базе данных.
- HOLAP ( Hybrid OLAP) - исходные данные остаются в той же реляционной базе данных, где они изначально находились, а агрегатные данные хранятся в многомерной базе данных.
Некоторые OLAP -средства поддерживают хранение данных только в реляционных структурах, некоторые - только в многомерных. Однако большинство современных серверных OLAP -средств поддерживают все три способа хранения данных. Выбор способа хранения зависит от объема и структуры исходных данных, требований к скорости выполнения запросов и частоты обновления OLAP -кубов.
Отметим также, что подавляющее большинство современных OLAP -средств не хранит "пустых" значений (примером "пустого" значения может быть отсутствие продаж сезонного товара вне сезона).
Основные понятия OLAP
Тест FAMSI
Технология комплексного многомерного анализа данных получила название OLAP (On-Line Analytical Processing). OLAP - это ключевой компонент организации ХД. Концепция OLAP была описана в 1993 году Эдгаром Коддом, известным исследователем баз данных и автором реляционной модели данных. В 1995 году на основе требований, изложенных Коддом, был сформулирован так называемый тест FASMI (Fast Analysis of Shared Multidimensional Information) - быстрый анализ разделяемой многомерной информации, включающий следующие требования к приложениям для многомерного анализа :
- Fast (Быстрый) - предоставление пользователю результатов анализа за приемлемое время (обычно не более 5 с), пусть даже ценой менее детального анализа;
- Analysis (Анализ) - возможность осуществления любого логического и статистического анализа, характерного для данного приложения, и его сохранения в доступном для конечного пользователя виде;
- Shared (Разделяемый) - многопользовательский доступ к данным с поддержкой соответствующих механизмов блокировок и средств авторизованного доступа;
- Multidimensional (Многомерный) - многомерное концептуальное представление данных, включая полную поддержку для иерархий и множественных иерархий (это ключевое требование OLAP);
- Information (Информация) - приложение должно иметь возможность обращаться к любой нужной информации, независимо от ее объема и места хранения.
Следует отметить, что OLAP-функциональность может быть реализована различными способами, начиная с простейших средств анализа данных в офисных приложениях и заканчивая распределенными аналитическими системами, основанными на серверных продуктах.
Многомерное представление информации
Кубы
OLAP предоставляет удобные быстродействующие средства доступа, просмотра и анализа деловой информации. Пользователь получает естественную, интуитивно понятную модель данных, организуя их в виде многомерных кубов (Cubes) . Осями многомерной системы координат служат основные атрибуты анализируемого бизнес-процесса. Например, для продаж это могут быть товар, регион, тип покупателя. В качестве одного из измерений используется время. На пересечениях осей измерений (Dimensions) находятся данные, количественно характеризующие процесс - меры (Measures). Это могут быть объемы продаж в штуках или в денежном выражении, остатки на складе, издержки и т. п. Пользователь, анализирующий информацию, может "разрезать" куб по разным направлениям, получать сводные (например, по годам) или, наоборот, детальные (по неделям) сведения и осуществлять прочие манипуляции, которые ему придут в голову в процессе анализа.
В качестве мер в трехмерном кубе, изображенном на рис. 26.1 , использованы суммы продаж, а в качестве измерений - время, товар и магазин. Измерения представлены на определенных уровнях группировки: товары группируются по категориям, магазины - по странам, а данные о времени совершения операций - по месяцам. Чуть позже мы рассмотрим уровни группировки (иерархии ) подробнее.
Рис.
26.1.
"Разрезание" куба
Даже трехмерный куб сложно отобразить на экране компьютера так, чтобы были видны значения интересующих мер. Что уж говорить о кубах с количеством измерений , большим трех. Для визуализации данных, хранящихся в кубе, применяются, как правило, привычные двумерные, т. е. табличные представления, имеющие сложные иерархические заголовки строк и столбцов.
Двумерное представление куба можно получить, "разрезав" его поперек вдоль одной или нескольких осей (измерений ): мы фиксируем значения всех измерений , кроме двух, - и получаем обычную двумерную таблицу. В горизонтальной оси таблицы (заголовки столбцов) представлено одно измерение , в вертикальной (заголовки строк) - другое, а в ячейках таблицы - значения мер. При этом набор мер фактически рассматривается как одно из измерений : мы либо выбираем для показа одну меру (и тогда можем разместить в заголовках строк и столбцов два измерения ), либо показываем несколько мер (и тогда одну из осей таблицы займут названия мер, а другую - значения единственного "неразрезанного" измерения ).
(levels). Например, метки, представленная на поддерживаются далеко не всеми OLAP-средствами. Например, в Microsoft Analysis Services 2000 поддерживаются оба типа иерархии , а в Microsoft OLAP Services 7.0 - только сбалансированные. Различными в разных OLAP-средствах могут быть и число уровней иерархии , и максимально допустимое число членов одного уровня, и максимально возможное число самих измерений .Архитектура 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-технологии (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 ). Естественно, в отчет выводится столько кнопок со справочниками, сколько есть в строке бюджета, содержащей максимальное количество справочников. Если ни в одной строке бюджета нет ни одного справочника, то в отчете не будет ни одной кнопки со справочниками.
Изначально OLAP-КУБ строится по всем измерениям. По умолчанию при первоначальном построении отчета измерения расположены именно в тех областях, как показано на рисунке 6 . То есть такое измерение, как «Дата», располагается в области вертикальных измерений (измерения в области столбцов), измерения «Строки», «Справочник 1», «Справочник 2» и «Справочник 3» – в области горизонтальных измерений (измерения в области строк), а измерение «Тип строки» – в области «нераскрываемых» измерений (измерения в страничной области). Если измерение находится в последней области, то данные в отчете не будут «раскрываться» по этому измерению.
Каждое из этих измерений можно поместить в любую из трех областей. После переноса измерений отчет мгновенно перестраивается в соответствии с новой конфигурацией измерений. Например, можно поменять местами дату и строки со справочниками. Или можно в вертикальную область измерений перенести один из справочников (см. Рис. 7 ). Иными словами, отчет в OLAP-КУБе можно «крутить» и выбирать тот вариант вывода отчета, который является наиболее удобным для пользователя.
Рис. 7. Пример перестройки отчета после изменения конфигурации измерений программного комплекса "ИНТЕГРАЛ"
Конфигурацию измерений можно менять либо в основной форме КУБа, либо в редакторе карты изменений (см. Рис. 8
). В этом редакторе также можно мышкой перетаскивать измерения из одной области в другую. Помимо этого, можно менять местами измерения в одной области.
Кроме того, в этой же форме можно настраивать некоторые параметры измерений. По каждому измерению можно настраивать расположение итогов, порядок сортировки элементов и названия элементов (см. Рис. 8 ). Также можно задавать, какое название элементов выводить в отчет: сокращенное (Name) или полное (FullName).
Рис. 8. Редактор карты измерений программного комплекса "ИНТЕГРАЛ"
Редактировать параметры измерений можно непосредственно в каждом из них (см. Рис. 9 ). Для этого нужно нажать на пиктограмму, расположенную на кнопке рядом с названием измерения.
Рис. 9. Пример редактирования справочника 1 Продукты и услуги в
С помощью этого редактора можно выбирать элементы, которые нужно показывать в отчете. По умолчанию в отчет выводятся все элементы, но при необходимости часть элементов или папок можно не показывать. Например, если нужно выводить в отчет только одну продуктовую группу, то у всех остальных необходимо убрать галочки в редакторе измерений. После чего в отчете будет только одна продуктовая группа (см. Рис. 10 ).
Также в этом редакторе можно сортировать элементы. Кроме того, элементы можно перегруппировывать различными способами. После такой перегруппировки отчет мгновенно перестраивается.
Рис. 10. Пример вывода в отчете только одной продуктовой группы (папки) в программном комплексе "ИНТЕГРАЛ"
В редакторе измерения можно оперативно создавать свои группы, перетаскивать туда элементы из справочников и т.д. По умолчанию автоматически создается только группа «Прочие», но можно создавать и другие группы. Таким образом, с помощью редактора измерений можно настраивать, какие элементы справочников и в каком порядке нужно выводить в отчет.
|
|
Следует отметить, что все такие перегруппировки не записываются. То есть после закрытия отчета или после его перерасчета в отчет будут выводиться все справочники в соответствии с настроенной методикой.
На самом деле все такие изменения можно было сделать изначально при настройке строк.
Например, с помощью ограничений также можно задавать, какие элементы или группы справочников нужно выводить в отчет, а какие – нет.
Примечание : более подробно тема данной статьи рассматривается на семинарах-практикумах "Бюджетное управление предприятием" и "Постановка и автоматизация управленческого учета" , которые проводит автор данной статьи - Александр Карпов .
Если пользователю практически регулярно нужно выводить в отчет только определенные элементы или папки справочников, то подобные настройки лучше заранее сделать при создании строк отчетов. Если же для пользователя важны различные комбинации элементов справочников в отчетах, тогда при настройке методики никакие ограничения ставить не нужно. Все такие ограничения можно будет оперативно настраивать с помощью редактора измерения.