хранилищ данных и их оперативной аналитической обработки. Материал проиллюстрирован практическими примерами построения хранилища данных и OLAP-куба в аналитическом приложении Deductor.

Предназначено для магистров направлений 09.04.01 «Информа-

тика и вычислительная техника» и 38.04.04 «Государственное и муниципальное управление».

Табл. 8. Ил. 60. Библиогр.: 20 назв.

Хранилище данных, витрина данных, гиперкуб, агрегирование,

измерение, срез, очистка данных

Печатается по решению редакционно-издательского совета Ря-

занского государственного радиотехнического университета.

Рецензент: кафедра САПР вычислительных средств Рязанского

государственного радиотехнического университета (зав. кафедрой д-р техн. наук, проф. В.П. Корячко)

О р е ш к о в Вячеслав Игоревич

Хранилища данных и OLAP-технологии

Редактор Р. К. Мангутова

Корректор С.В. Макушина

Подписано в печать 15.07.17. Формат бумаги 6084 1/16.

Бумага писчая. Печать трафаретная. Усл. печ. л. 4,0.

Тираж 20 экз. Заказ

Рязанский государственный радиотехнический университет.

390005, Рязань, ул. Гагарина, 59/1.

Редакционно-издательский центр РГРТУ.

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

С точки зрения ценности обнаруженных знаний наибольший

интерес представляют именно закономерности и зависимости, скрытые в больших массивах данных, таких как клиентские базы банков, торговых сетей и телекоммуникационных компаний, истории продаж за длительный период времени, базы данных систем бронирования авиа- и железнодорожных билетов и т.д. Знания, лежащие на поверхности, являются тривиальными, общеизвестными и не позволяют добиться конкурентных преимуществ. Поэтому предприятия заинтересованы в организации процессов добычи из данных именно глубинных, «новых, нетривиальных, интерпретируемых и практически полезных знаний, которые могут быть использованы при принятии управленческих решений» [15].

Потребность в аналитической обработке больших массивов

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

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

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

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

Хранилище данных (ХД), как определил автор концепции Б. Инмон, представляет собой «предметно-ориентированный, интегрированный, неизменчивый и поддерживающий хронологию набор данных, организованный для целей поддержки принятия решений» [16].

1.1. Краткая история развития технологий ХД

Концепция ХД появилась и начала развиваться не «на пустом месте», а как результат эволюционного процесса поиска конфигураций для систем хранения данных, оптимизированных сточки зрения аналитической обработки в интересах поддержки принятия решений. В 1960-х годах компания General Mills совместно с Дартмутским колледжем реализовали исследовательский проект, в котором были использованы концепции измерений и фактов, основополагающих для ХД. В 1970-х компания Nielsen Corporation, специализирующаяся в области маркетинговых исследований, представила витрины данных для розничных торговых сетей. В то же время Билл Инмон ввёл термин «хранилище данных». В 1988 году Барри Девлин и Пол Мёрфи опубликовали статью «Архитектура информационных систем для бизнеса», где впервые ввели понятие "хранилище бизнес-данных".

В 1990 году компания Red Brick Systems, основанная Ральфом Кимбаллом выпустила СУБД Red Brick Warehouse, в которой впервые был реализован весь функционал ХД. В 1991 году компания Prism Solutions., основанная Б. Инмоном, выпустили систему Prism Warehouse Manager, которая позволяла разрабатывать хранилища данных, а уже в 1992 увидела свет книга Б. Инмона «Построение хранилищ данных» [16]. И, наконец, в 1996 Ральф Кимбалл опубликовал работу «Руково-

дство по хранилищам данных» [17]. Таким образом, к началу XXI в. хранилища данных стали не только классом информационных систем, ориентированных на хранение и анализ бизнес-информации, но и технологией управления данными для поддержки принятия управленческих решений (для обозначения которой даже появилось новое слово –

datawarehousing).

1.2. Источники данных для ХД

В промышленной эксплуатации основными источниками данных для ХД являются системы оперативной обработки транзакций (OLTP - Online Transaction Processing). Такие системы охватывают широкий спектр задач в различных отраслях — автоматизированные банковские системы (регистрация обращений клиентов), системы управления производством (регистрация прохождения детали на конвейере), интернет-продажи (регистрация в статистике посещений очередного посетителя веб-сайта), розничная торговля (продажа набора товаров в супермаркете по одному чеку), бронирование авиа- или железнодорожных билетов и т. д. Как правило, каждое такое действие связано с обращением к базе данных и внесением в неё изменений и отражает логически целостное событие в системе (например, снятие клиентом денежных средств через банкомат). Такая операция и называется транзакцией.

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

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

OLTP-систем используются сильно нормализованные модели данных.

Помимо транзакционных систем, источниками данных для ХД могут быть любые файлы в информационной системе предприятия, в которых содержится структурированная информация, анализ которой, как ожидается, может дать полезные знания. Такие файлы могут иметь различные типы и форматы - электронные таблицы (Excel), настольные СУБД (Access), текст с разделителями (TXT, CSV-файлы), файлы учетных систем (1С:Предприятие, Парус) и т.д. Поэтому для ХД очень важно иметь развитые средства для загрузки и интегрирования данных из различных типов и форматов.

1.3. Основные свойства хранилищ данных

Таким образом, ХД представляет собой предметноориентированную информационную БД, предназначенную для анализа больших массивов данных и формирования отчётности с целью поддержки принятия решений в организации. Хранилища строятся на базе СУБД и СППР. Для реализации поставленных целей ХД должны удовлетворять следующим свойствам [1].

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

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

Неизменчивость – внутри ХД данные не изменяются, могут только добавляться новые. Если нужны какие-либо изменения, «перегружается» все хранилище целиком. Необходимость такого подхода объясняется тем, что при промышленной эксплуатации ХД совместно с аналитическими системами один и тот же запрос к хранилищу, выполняемый в любое время, должен обеспечить предоставление одних и тех же данных. Очевидно, что если бы в ХД было разрешено изменять данные, то два одинаковых запроса, выполняемые с некоторым интервалом, в течение которого данные могли измениться, сформируют два различных набора данных, анализ которых может привести к противоречивым заключениям и выводам, что недопустимо.

Хронологичность – поддерживается хронология данных внутри ХД. Т.е. каждому элементу данных присваивается метка времени, что позволяет извлекать данные в хронологическом порядке и анализировать временные последовательности.

Непротиворечивость ХД предполагает наличие механизмов, исключающих противоречия в данных, когда один и тот же объект или явление имеет разные описания в различных наборах данных (например, два различных человека имеют один и тот же номер паспорта). Противо-

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

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

Таким образом, ХД обеспечивают возможность эффективнее, быстрее и качественнее предоставлять данные системам их аналитической обработки, чем обычные СУБД.

1.4. Структура данных в хранилище

В настоящее время существует несколько моделей организации данных в ХД, основными из которых являются многомерная и реляционная. Многомерное направление развивалось школой под управлением Ральфа Кимбалла, в то время как реляционное - под руководством Билла Инмона [16, 17].

В реляционных ХД данные содержатся в таблицах третьей нормальной формы. Их преимущество заключается в простоте разработки и управления. Недостатком является необходимость денормализации данных «на лету» при их извлечении из множества таблиц при выполнении сложных аналитических запросов. При формировании больших выборок это приводит к значительным задержкам в получении данных, требуемых для анализа. А если ХД и аналитическая система интегрированы в ИС предприятия, то возрастает нагрузка на всю систему, что может осложнить работу многих пользователей. Данную проблему частично удается решить, используя в ХД модель данных, основанную на измерениях.

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

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

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

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

По принципу организации функционирования можно выделить следующие типы ХД.

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

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

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

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

Рассмотрим более подробно многомерную модель данных, её свойства и основные элементы.

Измерение (таблица измерений - dimension table) — таблица в структуре многомерной модели данных, которая содержит значения признаков объектов (событий, явлений), сохраненных в таблице фактов. Признаки представляют собой текстовые или иные описания, логически объединенные в одно целое. Например, в таблице измерения «Товары» будут содержаться наименования товаров, а в таблице «Клиенты» - названия организаций или ФИО частных лиц. Очевидно, что кроме качественных характеристик объекты бизнеспроцессов имеют и количественные, например цена товара и сумма, на которую он был реализован. Для банка может быть важен возраст клиента и его доход. Такие количественные значения содержатся в таблице фактов. Таким образом, в многомерной модели данных используется два типа таблиц: таблица измерений, которая содержит качественные характеристики объектов, процессов и явлений, и таблица фактов, содержащая количественные значения.

В ХД могут использоваться две разновидности многомерных моделей данных – «звезда» и «снежинка». В основе обеих моделей лежат следующие понятия:

- измерение – последовательность значений определенного признака. Например, измерение «Клиент» будет содержать последовательность наименований клиентов, измерение «Товар» - перечень товаров и т.д.;

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

- факт – значение, определяющее количественное описание объекта, события или явления. Факты всегда связаны с определенным измерением. Например, для измерения «Товар» могут быть указаны следующие факты – цена, количество и сумма, для измерения «Клиент» - возраст, доход, стаж работы и т.д.;

- процесс – совокупность измерений и фактов, связанных с определенным объектом, процессом или явлением. Процессов в ХД может быть несколько и каждый из них образуется отдельной «снежинкой» или «звездой».

Схема «звезда» [4, 13] включает в себя единственную таблицу

фактов и множество таблиц соединенных с ней измерений. Каждая

1 / 71 2 3 4 5 6 7 > Следующая >>>

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

Оглавление

1.1. Краткая история развития технологий ХД

1.2. Источники данных для ХД

1.3. Основные свойства хранилищ данных

1.4. Структура данных в хранилище