Технология OLAP и 1С:Предприятие

Технология OLAP и 1С:Предприятие

В среде общения программистов 1С все чаще стали возникать вопросы о технологии OLAP. Первым человеком, соединившим эту технологию с программами семейства 1С:Предпрития стал А. Любимов, разработавший продукт Акселератор (в него входят кубы, обработка выгрузки данных из 1С и OLAP-клиент от фирмы Digital Design - Data Vision Analyzer). Акселератор в настоящее время распространяется его фирмой АТТ. Однако агрессивное продвижение этого продукта Любимовым вошло в историю, и благодаря ему упоминание аббревиатуры OLAP на Территории 1С до сих пор вызывает у некоторых ее обитателей беспричинную ярость: А зря. Технология очень интересная.

Итак, OLAP - что, зачем и как.

Сначала просто расшифруем аббревиатуру. OLAP - On-Line Analytical Processing, то есть анализирование на лету. Такое вот название было придумано для технологии. Кроме названия было придумано 5 принципов OLAP - если принципы не соблюдаются, то как бы и не OLAP это, а так, что-то другое (Гиперкуб, например). Эти принципы чуть ниже. Сначала все-таки неформальное определение так, как его понимаю я. Итак, предназначение этой технологии - давать аналитику (менеджеру, как правило) интересующую информацию со скоростью, которая не будет отставать от его мысли. Здесь имеется в виду и скорость построения отчета, и возможность легко извлечь нужные данные. И принципы следуют именно отсюда. Вот они:

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

Теперь - ближе к делу. OLAP - это технология, а не программа. Есть решения от Оракл, от других производителей ПО, но куда нам деться от родного Билли Гейтса! Рассмотрим решение от Майкрософт, всеми ругаемой и всеми используемой. Они начали включать OLAP в SQL-сервер с версии 7.0. Там он называется OLAP-Services. В SQL-2000 название почему-то сменили на Analysis Services. Но суть осталась.

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

Теперь - как это реализуется чуть ближе. Итак, имеем какой-то набор таблиц, проще говоря - базу данных. Эта БД называется источником данных (Data source). В одной из таблиц - набор собственно данных. Она называется таблицей фактов (fact table). В кубе может быть только одна такая таблица. Кроме того, может быть любое количество таблиц с данными об измерениях куба. Указав, какие поля содержат данные, а также задав свойства измерений и взаимосвязи между ними, получаем структуру куба. Например, такую:

Это - не очень сложный куб. Однако, он дает возможность получать информацию о количестве, сумме, себестоимости (а заодно о вычисленных на их основе прибыли и проценте прибыли) а также об остатках на начало и конец любого выбранного периода. И это в любом разрезе данных по 7-ми измерениям с любым уровнем детализации. И это очень быстро и без помощи программиста. Очень быстро - потому, что все возможные данные на пересечении всех осей рассчитываются заранее. Без помощи программиста - потому, что существует множество клиентских программ для удобного извлечения информации. От безумно дешевого в нашей стране Office 2000 и Office XP до достаточно дорогого, но с мощнейшими возможностями ProClarity:

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

Для начала - MS Office (а точнее - Excel). 2000-й рассматривать не буду, потому что избалован нормальными клиентами: Даже по сравнению с малость недоделанной Data Vision Analyzer он выглядит слишком бледно. А вот XP - уже вполне неплохо. Опять же многого не хватает, но при том, что MS office стоит в любом, простите за каламбур, офисе доступность очевидна. На лицензионности я внимание не заостряю. Итак, скриншот:

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

Второй вариант - Data Vision Analyzer от питерской фирмы Digital Design. Он стоит денег. Однако его возможности все-таки посерьезней, чем у Excel. Очень удобный выбор строк и столбцов, возможность отборов, сортировок, выделения цветом определенных значений: экспорт результата в Excel, управление доступами, журнал регистрации...:

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

А теперь - клиент, который позволяет получить что угодно. ProClarity 3.0.

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

Но и стандартные представления тоже есть, с очень удобным выбором чего бы то ни было: В таблице и диаграмме, как и в дереве декомпозиции, можно детализировать данные, либо углубляясь (drill down) на следующий иерархический уровень (что доступно в любом клиенте), либо подключая новое измерение. Элементарно раскрывается, например, товар по покупателям, причем сразу можно выбрать, на какой уровень попадешь. Все отборы и сортировки можно установить в любой момент. При работе с таблицей выбор измерений для строк и столбцов мне сначала казался немного неудобным, но это прошло. В общем, отличнейший клиент. Действительно позволяет ProЯснить ситуацию :-). Огорчает одно - стоимость. Около 800$ на одно рабочее место. Также может несколько затруднить работу английский интерфейс, но эта проблема в принципе решаема.

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

А теперь еще один вопрос - как загнать в эту красоту данные из 1С?

Собственно, ничего страшного. Есть два пути - один попроще, другой мне нравится :-).

Первый способ уже применяется довольно многими. На рынке даже есть решения для облегчения этого пути. Как правило, применяется на базах в формате SQL. Но и на dbf тоже работает. Суть в том, что в качестве источника данных используется непосредственно база 1С. Тогда как в качестве таблицы фактов мы используем таблицу какого-либо регистра, устанавливаем связи с таблицами справочников, и вперед. Дешево и сердито. Особенно хорошо при использовании Analysis Services (SQL 2000 ) - создание уровней измерений с помощью parent-child идеально ложится на структуру таблиц 1С. Для SQL 7.0 мы бы получили абсолютно плоские изменения товаров и покупателей, без групп (а это нарушило бы основное требование OLAP).

Плюсы достаточно очевидны - для обновления данных в кубе достаточно запустить процессинг (process) базы данных в OLAP-менеджере. В источнике данных информация всегда актуальна. Минусы - я с трудом представляю, как использовать такой подход на бухгалтерской компоненте и тем более на расчете. Определенно нельзя использовать в качестве измерений перечисления. Нельзя загнать в куб информацию из двух регистров (есть виртуальные кубы, позволяющие обЪединить несколько кубов, но у них свои недостатки). Нельзя создать многоуровневые измерения с использованием нескольких таблиц. Вообще структура куба достаточно жестко определяется структурой БД. А она может и изменятся: Кроме того, куб, разработанный для одной БД с большой долей вероятности не будет работать с другой, даже при аналогичной конфигурации. И вообще сама идея такого подхода основана на использовании недокументированной информации о хранении данных в 1С (человек, не знакомый со структурой файла 1cv7.dd этот подход использовать не сможет).

Второй способ (я использую именно его) - вынесение источника данных в промежуточное хранилище. Обычно это - база данных Access. Можно использовать таблицы SQL. Там создаются таблицы с учетом того, что мы хотим видеть, далее пишется обработка для переноса в это хранилище данных из рабочей базы (пример работы с Access доступен), и уже на основе этого хранилища делается OLAP -куб. Здесь мы имеем полную свободу - например я в одной не любимой мною конфигурации заношу данные в куб продаж не на основе регистров, а на основе расходных накладных, при этом беру только те, у которых покупатель принадлежит к определенной группе. Вот так приходится отсекать именно продажи от всего остального: А еще я добавляю в куб продаж остатки - чтобы увидеть, что, например, мало продавали просто из-за того, что не было товара на складе, или на линейной диаграмме показать остатки и продажи в штуках - легко оценивается запас товара на складе. А показывать остатки приходится на какого-то покупателя: маразм? Нет, просто требование OLAP. Я то просто выкрутился - добавил в таблицу с покупателями фиктивную запись, в таблицу с накладными тоже и отношу все записи информации об остатках в таблицу фактов на них: Готов держать пари, в первом способе такого не добьешься. Формат базы данных при таком способе абсолютно не важен. Есть также принципиальная возможность (я пока только обдумываю, но делать буду определенно) добавлять информацию из внешних источников - например из файла MS Excel определенного формата: там могут быть данные, скажем, о планах на продажи или о затратах на рекламную компанию - сравнение этих данных прямо на месте с информацией о продажах может оказаться очень интересным. Понятно, что подобная гибкость недостижима при использовании первого подхода.

На этом, пожалуй, и все. Разумеется, получился весьма поверхностный обзор, но, надеюсь, я сумел передать основную идею технологии. Очень много различного материала можно найти на сайте www.olap.ru. Также есть обзоры применения OLAP именно на основе данных 1С:Предприятия на сайте компании АТТ - с покупки ее продукта началось, кстати, мое знакомство с технологией.

Ссылки по теме:

• www.olap.ru
• Акселератор для 1С:Предприятия (разработчик - Активные Торговые Технологии)
• OLAP 7.7 (разработчик - компании "ПиБи")
• Выгрузка данных из 1С:Предприятия в MS Access
• Digital Design - разработчик OLAP-клиента Data Vision Analyzer
• Knosys ProClarity