Построение хранилища данных на базе информационной системы предприятия
Введение
хранилище информационный процессор сервер
После применения традиционных методов увеличения доходов (маркетинговые исследования и действия на рынке, работа с конкурентами) или уменьшения расходов (изменение технологии, работа с поставщиками), перед менеджерами высшего звена встает задача по дальнейшему увеличению прибыли, как основной цели деятельности любого коммерческого предприятия.
В базах данных информационных систем торговых компаний в процессе экономической деятельности накапливаются большие объёмы данных. К ним относятся как справочные таблицы: справочники товаров, партнёров, адресов и т.д., так и таблицы фактов: история приходных и расходных накладных, перемещения товаров. Падение цен на аппаратное обеспечение с одновременным увеличением быстродействия способствует развитию технологий связанных с обработкой и исследованием огромных массивов данных. В результате этого было может быть преодолено множество барьеров стоящих на пути нахождения нового знания. [1]
Для разработки эффективных экономических решений и достижения необходимого экономического результата с информационной точки зрения алгоритм исследования универсален и содержит следующие этапы:
сбор или идентификацию информации;
накопление, хранение, обработку, анализ и интерпретацию информации;
подготовку и представление информации, необходимой заинтересованным пользователям. [2]
В данной работе предлагаются методы построения хранилища данных на основе информационной системы реального коммерческого предприятия, ООО «Н».
1.
Постановка задачи
Основные аналитические задачи, для решения которых планируется внедрение хранилищ данных
1. Подготовка ежедневных, месячных, квартальных, годовых отчётов для бухгалтерии, поставщиков, отдела закупок, коммерческой администрации и других подразделений.
. Подготовка ежемесячных прогнозов оптовых продаж на основании предыдущих данных в разрезах по клиентам, территориям, товарам, группам товаров с учётом сезонности для постановки наиболее оптимальных планов продаж, подлежащих наименьшим правкам финансовыми менеджерами.
. Генеральный мастер-план торговых представителей по работе с клиентами для увеличения процента выполнения планов продаж и повышения эффективности рекламы.
. Прогнозы отдела закупок для формирования заказов поставщикам.
. Подготовка ежедневных (ночных) прогнозов розничных продаж на основании предыдущих данных, где наибольшим весом обладают продажи за предыдущую дату, для предупреждения дефицита или избытка товара.
. Расчёт дебиторской задолженности и выявление ответственных лиц.
. Выявление нелояльности персонала и клиентов.
. Обнаружение новых трендов.
Информационная среда
Бизнес-процессы компании «Н» поддерживаются несколькими связанными информационными системами:
. Центральная база «Филиал» содержит справочники и оперативные транзакционные данные (OLTP-система). Ежедневно в процессе синхронизации старые данные удаляются и передаются в «Офис». Данные «Филиала»: Таблицы фактов: расходных накладных, приходных накладных, заказов, листы сборки склада, размещение товаров по ячейкам склада, бухгалтерские документы. Таблицы измерений: справочники партнёров, поставщиков, сотрудников, товаров, складов, адресов.
. База «Офис» частично дублирует структуру «Филиала» и содержит большой объём данных «Филиала» за последние несколько лет.
. Данные «Офиса» старше 5 лет отрезаются и переносятся в отдельный архив.
. Система «Планировщик» представляет собой инструмент отдела кадров и содержит табели персонала.
. На розничных торговых точках компании используется система «1С: Розница».
. Система EDI (Electronic Document Interchange) используется для электронного обмена данными между клиентами компании и системами «Филиал-Офис» через Интернет.
Обоснование актуальности
В настоящий момент «Офис» имеет реляционную структуру, аналогичную структуре «Филиала» и используется для решения задач 1-6, указанных в п. 2.1.
Работа с OLTP-системами, как правило, выполняется в режиме реального времени. Документы продажи или прихода товара оформляются в общем случае постоянно в течение всего рабочего дня. Аналитик при работе с системой анализа обращается к ней для проверки некоторых своих гипотез и получения отчётов, графиков и т.п. При выполнении запросов степень загрузки системы высокая, т. к. обрабатывается большое количество данных, выполняются операции суммирования, группирования, таким образом характер загрузки систем анализа является пиковым. На (рисунке 1) приведены данные фирмы Oracle, отражающие загрузку процессора в течение дня для OLTP и OLAP систем. [5]
Рисунок 1. Степень загрузки ЦП на OLTP и OLAP серверах в течение дня
Один из недостатков OLTP-систем в том, что они не рассчитаны на выполнение сложных нерегламентированных запросов - большое количество таблиц как следствие нормализации, из-за чего для получения какой-либо информации нужно делать выборку из многих таблиц одновременно, что приводит к ухудшению производительности системы. На подготовку сложных агрегированных соединений множества сущностей в разрезе, например, большого временного интервала, вместе с разработкой алгоритма получения необходимой информации требуются значительные трудозатраты сотрудников IT-отдела, и выполняться такие запросы на SQL-сервере могут несколько часов.
Хранилище данных это система, которая собирает и консолидирует данные периодически из разных источников в многомерную или нормализованную предметно-ориентированную информационную базу данных. [3] Строится на базе систем управления базами данных и систем поддержки принятия решений. Данные, поступающие в хранилище данных, как правило, доступны только для чтения. Данные из OLTP-системы копируются в хранилище данных таким образом, чтобы построение отчётов и OLAP-анализ не использовал ресурсы транзакционной системы и не нарушал её стабильность. Как правило, данные загружаются в хранилище с определённой периодичностью, поэтому актуальность данных может несколько отставать от OLTP-системы. Логическая структура данных хранилища данных отличается от структуры данных источников.
Поэтому для эффективного решения задач бизнес-аналитики средствами информационных технологий перспектива построения хранилища данных обладает в настоящий момент высокой актуальностью.
2.
Обзор способов реализации
Рисунок 2. Диаграмма системы БД + ХД
Sources (источники) - базы данных информационных систем предприятия. Не являются частью системы хранилища данных.
ETL (Extract, transform, load) - чтение, извлечение данных из источников, их преобразование и загрузка в ХД.
Data quality, clean - очистка данных от избыточности и проверка их целостности.
Dimensional data store - база данных, хранящая данные в форматах, отличных от форматов на источниках.
Multidimensional database - многомерная база данных.
Схемы хранения данных
· Денормализованное хранение. Содержит коллекцию витрин данных как групп связанных таблиц фактов и их соответствующими таблицами измерений, содержащих соединения измерений бизнес-событий. Для соединения таблиц используется схема звезды или схема галактики.
· Нормализованное хранение. Отличается малой избыточностью данных и высокой степенью нормализации отношений (до 5НФ). Для опроса нормализованного хранилища используется схема соединения снежинка.
Рисунок 3. Схема звезды
Рисунок 4. Схема снежинки
В схеме галактики (или созвездия) две или более связанных таблицы фактов окружены соответствующими таблицами измерений.
· Многомерная база данных. Данные хранятся в ячейках многомерного массива, каждая ячейка представляет собой событие, а значения позиций ячейки в массиве определяют измерения события, где и когда оно имело место быть, к какой группе событий оно относится, какие объекты были в него вовлечены, и другие возможные измерения. На (рисунке 5.) изображён трёхмерный куб с трёхмерными ячейками.
Рисунок 5. Визуализация многомерной БД с тремя измерениями
Денормализованное хранение лучше подходит для различных запросов и интеллектуального анализа данных, чем нормализованное, потому что оно организовано проще (меньше уровней иерархической вложенности) и имеет более хорошие результаты в производительности. Нормализованное хранилище удобнее для интеграции данных из различных источников, задача ETL реализуется проще, т. к. нормализованные таблицы легко копировать и обновлять по ключу, избыточных данных нет. [3]
Т.к. БД «Офис» уже представляет собой в некотором роде хранилище нормализованных данных, нужно построить денормализованное хранилище для аналитической обработки данных, и последующей реализации многомерных баз данных для внедрения инструментария Data mining.