Использование OLAP-технологий применительно к системам 1С:Предприятие

Размещено на http://allbest.ru/

Министерство образования и науки Российской Федерации

Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования

«Донской государственный технический университет»

Кафедра «Информационные технологии»

Реферат

по дисциплине: «Инструментальные методы поддержки принятия решений»

на тему: «Использование OLAP-технологий применительно к системам 1С:Предприятие»

Выполнил:

ст. гр. ВМИС21

Абраменков Д.В.

Проверил:

к.т.н, доц. Венцов Н.Н.

Ростов-на-Дону 2013г.



Содержание

• Введение
• 1. СППР: OLAP-системы, OLAP-куб
• 2. Интеграция OLAP в 1С
• 3. OLAP-решения, используемые в среде 1С
• 3.1 Контур Стандарт
• 3.2 Deductor
• Заключение
• Использованная литература


Введение

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

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

Целью данной работы является рассмотрение технологии анализа данных OLAP и её применение к системе программ «1С:Предприятие».



• 1. СППР: OLAP-системы, OLAP-куб

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

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

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

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

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

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

OLAP является эффективной методикой анализа больших объемов данных, которые позволяют строить отчеты за считанные секунды и также быстро раскрыть по произвольной аналитике. Система должна удовлетворять 12 правилам:

1. Концептуальное многомерное представление (Multi-Dimensional Conceptual View). Многомерная концептуальная схема облегчает моделирование.

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

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

4. Постоянная производительность при разработке отчетов (Consistent Reporting Performance). Если число измерений или объем базы данных увеличиваются, пользователь не должен чувствовать какой-либо существенной деградации в производительности.

5. Клиент-серверная архитектура (Client-Server Architecture).

6. Общая многомерность, равноправие измерений (Generic Dimensionality). Каждое измерение должно применяться безотносительно своей структуры и операционных способностей.

7. Динамическое управление разреженными матрицами (Dynamic Sparse Matrix Handling).

8. Многопользовательская поддержка (Multi-User Support). Часто несколько пользователей испытывают потребность работать совместно с одной аналитической моделью или создавать различные модели из единых данных.

9. Неограниченные перекрестные операции (Unrestricted Cross-dimensional Operations). Инструмент должен подразумевать вычисления и не требовать от пользователя вновь определять эти вычисления и операции.

10. Интуитивная манипуляция данными (Intuitive Data Manipulation). Взгляд пользователя на измерения, определенный в аналитической модели, должен содержать всю необходимую информацию, чтобы выполнять все необходимые действия.

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

12. Неограниченная размерность и число уровней агрегации (Unlimited Dimensions and AggregationLevels). Каждое из общих измерений не должно быть ограничено по числу определяемых пользователем уровней агрегации и путей консолидации.

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

Забегая вперёд, отметим, что среди некоторых разработчиков 1С бытует предвзятое отношение к OLAP (слово в этой сфере считается «ругательным»). Также интересной является формулировка, что регистры «Предприятия» являются «OLAPом для бедных». Но в целом такое утверждение не верно - цели у регистров и OLAP-кубов разные. Первые заточены на быстрое занесение информации и её получение в один конкретный момент времени, вторые - на максимально удобное извлечение информации. Поместить её в OLAP-куб - процесс не быстрый.

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

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

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

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

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

3. Многомерное хранение - средства физической организации данных, обеспечивающие эффективное выполнение многомерных запросов.

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

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

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



2. Интеграция OLAP в 1С

Как было сказано ранее, требования к системе построения отчетности, которую действительно можно назвать OLAP-системой достаточно жесткие (12 правил). Изначально, 1С задумывалась как несложная система для учета деятельности небольших предприятий. Со временем круг задач, которые позволяет решить 1С, значительно расширился, что привело к появлению в системе OLAP-технологий, позволяющих создавать новые виды отчетов и предоставлять современный способ работы с данными - динамический отчет. Рассмотрим подробнее хронологию.

В 6-7 версии «1С:Предприятие» были созданы «регистры». Регистры «1С:Предприятие» предназначены для хранения и обработки различной информации, отражающей хозяйственную деятельность предприятия. Далее в версии 8.x появились «виртуальные таблицы». Этот механизм существенно ускорил работу. Так же появилась «система компоновки данных». Система компоновки данных представляет собой механизм, основанный на декларативном описании отчетов. Он предназначен для построения отчетов, а также вывода информации, имеющей сложную структуру и содержащий произвольный набор таблиц и диаграмм. Это был первый серьезный механизм, который занимается вопросом произвольной аналитики. Компоновка данных - встроенное средство для написания отчетности, позволяющая показать данные в виде n-мерного отчета. Компоновка данных внешне похожа на OLAP-инструменты, но данные она собирает в момент формирования отчета, а не хранит в предварительно рассчитанном кубе. Важной особенностью системы компоновки данных, является возможность создания отчетов без программирования.

В блоке финансового и бухгалтерского учета функциональности системы «1С:Предприятие» достаточно, а вот в плане гибкости анализа есть большой пробел.

Описанный подход оказался достаточно успешным для небольших баз, однако для крупных предприятий обернулся довольно значительными проблемами. Одна из них заключается в том, что высокая вычислительная сложность внесения данных серьезно удлиняет транзакции и вызывает взаимоблокировки, мешающие нормальному использованию системы. Например, подобные проблемы проявляются при расчете себестоимости товара, учитываемого по партиям. Кроме того, 1С не удалось найти методику, которая бы сочетала быстрый доступ и универсальное хранение для регистров бухгалтерии. В результате оказалась низкой скорость выполнения запросов для планов счетов с большим числом субконто. По той же причине осталась нереализованной ролевая безопасность (РЛС) для субконто.

Что же касается схемы компоновки, то она, как и все Desktop OLAP-системы, требует жесткого ограничения объема анализируемых данных, т.к. они полностью передаются с сервера на клиента и после этого анализируются в памяти клиентского компьютера. Любое изменение аналитик-анализа, например, желание развернуть складские продажи по группам товаров, не включенных изначально в запрос, требуют повторного запроса всех данных. Понятно, что скорость такого анализа на объемных базах невелика.

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

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

При создании серверных OLAP-систем для 1С, как правило, используется следующий подход. На первом этапе данные из 1С извлекаются в так называемое SQL-хранилище и преобразуются в удобный для анализа вид. Здесь, как правило, возникают основные проблемы, связанные с тем, что 1С использует систему автоматических названий объектов и их полей в SQL-базе, а также логические связи объектов, непонятные «извне».

На втором этапе по хранилищу данных строятся OLAP-кубы и настраиваются модели Data Mining. При этом могут использоваться OLAP-сервера различных поставщиков ПО.

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

Разработка OLAP-решений для 1С, как правило, ведется либо IT-отделами крупных предприятий, либо путем привлечения фирм специализирующихся в области обработки данных.

В последнее время появились OLAP системы, интегрированные с 1С. Примером может служить программа «Контур Стандарт» (Intersoft Lab). Идея состояла в том, что пользователям 1С удобнее и привычней конфигурировать отчеты, оставаясь в среде 1С. Это позволяет сформировать запрос на получение данных в диалоге и в терминах предметной области, например, предлагая пользователю выбор необходимых данных из списка учетных регистров, справочников, документов действующей конфигурации.

Утилита от Intersoft Lab более подробно будет рассмотрена в следующем разделе, сейчас отметим другие программные продукты OLAP-решений для 1С. Среди российских, это «Deductor» (компания BaseGroup Labs), «BIX BI» (Business Intelligence), «Акселератор Любимова» (ATT), «Инталев Гиперкуб» (Инталев), «1С:Бизнес сканнер» и другие. Что касается программного продукта «Deductor», то OLAP анализ не является основным направлением, но присутствует в виде отдельного модуля, а само внедрение ведется не собственными сотрудниками после обучения, а поставщиками. Решение от «BIX BI» не требует больших затрат, т.е. если организация использует Microsoft SQL Server, то затраты ложатся только на покупку дополнительных лицензий. В программных продуктах «Акселератор Любимова», «1С:Бизнес сканнер» в качестве OLAP сервера используют разработку компании Microsoft, а «Инталев Гиперкуб» собственную разработку. Что касается стоимости, то средняя колеблется в районе 1000-1500$.



3. OLAP-решения, используемые в среде 1С

В данном разделе рассмотрим более подробно продукты компаний Intersoft Lab и BaseGroup Labs - Контур Стандарт и Deductor, соответственно.

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

3.1 Контур Стандарт

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

Опишем архитектуру самой системы Контур Стандарт, архитектуры информационных систем, которые можно построить с ее помощью.

На верхнем уровне система состоит из трех частей:

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

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

3. Аналитических интерфейсов - четырех видов интерфейсов, использующих «выборки» и некоторые дополнительные настройки. Эти интерфейсы позволяют конечному пользователю интерактивно управлять расчетами и отображением и выпускать разнообразные отчеты.

Рисунок 2 Структура Контур Стандарт

Для доступа к данным используются BDE и ODBC, что позволяет получать данные практически из всех типов СУБД.

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

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

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

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

Контур Стандарт, будучи OLAP-клиентом, решает следующие собственные задачи в структуре информационной системы:

1. Выполнение запросов к базе данных.

2. Визуализация данных.

3. Манипуляции с данными.

4. Выпуск отчетов некоторой предопределенной в системе формы.

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

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

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

Рисунок 3 База данных Контур стандарт

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

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

Рисунок 4 Доступ к оперативной системе

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

Рисунок 5 Создание хранилища

Все эти архитектурные решения могут использоваться одновременно. Система Контур Стандарт может быть настроена сразу на несколько баз данных, которые расположены в локальной сети. Эти базы данных могут иметь различные типы: SQL-сервера, локальные таблицы, и различное назначение: бухгалтерская система, Хранилище данных, витрина данных.

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

3.2 Deductor

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

В программе используются как механизмы быстрого прямого доступа к наиболее популярным базам данных, так и универсальные драйвера: ADO, OLE DB, ODBC, dbExpress. Полный список поддерживаемых форматов включает: Direct, OLE DB, Direct-OLE, Direct-COM, dbExpress, ODBC, ADO.

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

Хотя Deductor Warehouse является одним из множества источников данных, это наиболее предпочтительный способ хранения анализируемой информации. Отличается он от остальных более полной интеграцией с Deductor Studio и простотой использования. Благодаря реализации в Deductor Warehouse специальной структуры данных (семантического слоя) пользователь манипулирует не таблицами и запросами (как в случае с другими источниками), что может представлять проблему для человека, не изучавшего принципы работы СУБД, а с процессами, фактами и измерениями. Deductor Warehouse содержит метаданные, позволяющие изолировать пользователей от технических сложностей работы с запросами и представляющий модель объектов в виде бизнес-терминов, понятных специалисту в предметной области.

Рисунок 6 Мастер подключений Deductor Studio

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

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

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

В качестве приёмников могут выступать данные с форматами соответствующими таковым в перечне источников. Поддержка автоматического экспорта данных во множество приемников позволяет использовать Deductor как ETL-средство. Благодаря наличию множества механизмов обработки и способность экспортировать данные после любого из них возможности Deductor выходят далеко за рамки стандартных средств загрузки.

При помощи Deductor Studio можно провести не только элементарную обработку данных, но и сложную очистку, построить модели и экспортировать результаты, например, в Deductor Warehouse. Таким образом, в хранилище попадают не «сырые», а очищенные и специальным образом трансформированные данные.

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

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

Рисунок 7 Схема обработки данных

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

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

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

Визуализировать данные в Deductor Studio можно на любом этапе обработки. Система самостоятельно определяет, каким способом она может это сделать, например, если будет обучена нейронная сеть, то помимо таблиц и диаграмм можно просмотреть граф нейросети. Пользователю необходимо выбрать нужный вариант из списка и настроить несколько параметров. Настроенные визуализаторы могут быть вынесены на панель Отчеты. Таким образом, конечный пользователь сможет просто получить и просмотреть необходимый результат, не задумываясь, каким способом он был получен. Кроме того, конечный пользователь для визуализации данных может воспользоваться специализированным приложением Deductor Viewer.

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

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



Заключение

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

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

Поскольку технология OLAP становится все более распространенной, то интерес к СППР, включающим в себя подсистему OLAP, будет расти.



Использованная литература

1. Узденёва Т. А. Система поддержки принятия решений, интегрированная с «1С:Предприятие» [Текст] / Т. А. Узденёва // Молодой ученый. -- 2011. -- №3. Т.1. -- С. 105-107.

2. Подопригора Ф., Технология OLAP и 1С:Предприятие: [Электронный документ] (http://www.klerk.ru/soft/articles/630/). Проверено 25.12.2013.

3. Сравнение OLAP-продуктов для платформы 1С: Предприятие: [Электронный документ] (http://ivn73.tripod.com/1c_olap.htm). Проверено 25.12.2013.

4. Официальный сайт ООО «Intersofr Lab». Архитектура Контур-Стандарт: [Электронный документ] (http://www.iso.ru/rus/document5779.phtml). Проверено 25.12.2013.

5. Официальный сайт ООО «BaseGroup Labs». Deductor: [Электронный документ] (http://www.basegroup.ru/deductor/). Проверено 25.12.2013.

6. Интернет-энциклопедия Википедия. Системы поддержки принятия решений: [Электронный документ] (http://ru.wikipedia.org/wiki/Система_поддержки_принятия_решений). Проверено 25.12.2013.

7. Интернет-проект «Корпоративный менеджмент». Применение OLAP-технологий для учётных систем на платформе 1С: [Электронный документ] (http://www.cfin.ru/itm/olap/1c.shtml). Проверено 25.12.2013.

Размещено на Аllbest.ru

...