Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Хранилища данных и OLAP-технологии. Учебное пособие.pdf
X
- •Оглавление
- •1.1. Краткая история развития технологий ХД
- •1.2. Источники данных для ХД
- •1.3. Основные свойства хранилищ данных
- •1.4. Структура данных в хранилище
- •1.5. Операции над данными в хранилище
- •1.6. Витрины данных
- •1.7. Виртуальные хранилища данных
- •1.8. Практический пример построения ХД в АП Deductor
- •Вопросы для самопроверки
- •2.1. Методы обнаружения проблем в данных
- •2.2. Методы очистки данных
- •2.3. Пример очистки данных в АП Deductor
- •3. OLAP-технологии
- •3.1. Цели и задачи OLAP
- •3.2. Представление данных в виде гиперкубов
- •3.3. Пример работы с OLAP-системой в АП Deductor
- •Библиографический список

11
таблица измерений должна находиться в отношении «один к одному»
с таблицей фактов. Схема «снежинка» отличается от схемы «звезда»
тем, что содержит хотя бы одну таблицу измерений, ссылающуюся на
таблицу, которая находится по отношению к ней в связи «один ко
многим». Иными словами, измерения в «снежинке» могут иметь иерархически подчиненные измерения. Например, измерение «Регион»
может быть связано с измерением «Город», т.е. для каждого региона
будет содержаться список расположенных в нем городов. В ХД, где
скорость доступа к данным является наиболее критическим фактором,
отдают предпочтение схеме «снежинка».
Таблица фактов является основной таблицей процесса. Она
содержит сведения об объектах или событиях, совокупность которых
будет в дальнейшем анализироваться. Обычно такая таблица содержит уникальный составной ключ, объединяющий первичные ключи
таблиц измерений. Помимо этого таблица фактов содержит одно или
несколько числовых полей, на основании которых в процессе выполнения аналитических запросов вычисляются агрегатные данные.
Агрегатными (агрегированными) называются значения, вы-
численные на основе совокупности некоторого набора исходных
значений. Например, суммы продаж за неделю (месяц, год) есть ре-
зультат агрегирования ежедневных продаж с помощью функции
суммирования. Агрегирование позволяет управлять детальностью
представления явлений в анализируемых данных, что снижает коли-
чество обрабатываемых значений, исключает случайные флуктуации.
Агрегатные данные могут формироваться и содержаться в ХД,
что при большом количестве автоматически вычисляемых агрегатов
может привести к информационному взрыву хранилища. Другой вариант – вычислять агрегаты «на лету», в процессе выполнения запроса к
ХД, что может увеличить время ожидания. Все загружаемые в ХД
данные обязательно должны быть определены как измерение, атрибут
либо факт. Пример процесса в ХД, содержащего сведения о производстве и сбыте изделий на основе реляционной модели, представлен на
рис. 1.1.
Тот же процесс на основе многомерной модели по схемам
«звезда» и «снежинка» представлен на рис. 1.2.
Кроме собственно данных, описывающих исследуемые процес-
сы и явления, важнейшую роль в построении ХД играют метаданные
(от лат. meta — цель, конечный пункт, предел, край). Метаданные
(данные о данных) – это служебные данные, описывающие структуру
хранилища, содержащие информацию о принадлежности данных к
тому или иному типу (измерение, атрибут или факт).

12
Рис. 1.1. Процесс «Производство и сбыт изделий» - реляционная модель
а б
Рис. 1.2. Процесс «Производство и сбыт изделий» - многомерная модель:
а - схема «снежинка», б - схема «звезда»
С помощью метаданных формируется семантический слой, ко-
торый обеспечивает визуальное представление хранилища и визуальные средства манипуляции с данными и метаданными. Метаданные в
ХД можно разделить на два вида:
- технические – обеспечивают работу собственно ХД;

13
- бизнес-метаданные – описывают структуру данных в рамках
заданной бизнес-модели.
1.5. Операции над данными в хранилище
Как правило, непосредственное перемещение данных из источников в хранилище невозможно. Это связано с тем, что данные представлены в различных форматах, могут быть противоречивыми, дублирующими, неполными и т.д. В то же время в ХД данные должны
храниться в едином формате, интегрироваться из источников различных типов, быть целостными и непротиворечивыми. Поэтому в процессе перемещения данных из источников в ХД предусмотрена специальная процедура, называемая ETL (Extract, Transform, Load) – извлечение, преобразование, загрузка [7].
Извлечение – процесс получения доступа к данным в источнике, их выгрузка и помещение в специальную область памяти, называемую промежуточной областью (staged area). Использование промежуточной области необходимо еще и потому, что различные источники, данные из которых должны быть интегрированы, могут располагаться как на локальных носителях, так и на сетевых, что обусловливает различное время их получения. Следовательно, данные, полученные раньше, должны где-то ожидать данные, которые поступят позже.
Таким местом и является промежуточная область. Данные в промежуточной области хранятся в виде временных таблиц, которые удаляются после завершения работы с данными. Выгрузка данных из источников может производиться как средствами самого ХД, так и средствами
ИС, в которой они содержатся (например, системы OLTP, АСУП и
т.д.).
Преобразование – производится в промежуточной области и
включает в себя преобразование данных различных типов и форматов
к единому формату хранилища. Кроме этого, на данном этапе производится первичная предобработка данных с целью их дедупликации
(исключения повторяющихся элементов данных), устранения противоречий, поиска ошибок, разбора составных значений (например, адресов) и других операций, определенных разработчиком системы. Эти
операции должны обеспечить представление данных в ХД, которое
наилучшим образом соответствует бизнес-модели организации, и способствовать наиболее быстрому выполнению аналитических запросов
к хранилищу. К таким операциям относится агрегирование числовых
значений, их округление и т.д.
Загрузка. Заключается в переносе данных из промежуточных
таблиц в структуры ХД. При загрузке в хранилище переносится не вся
информация из источников, а только та, которая была изменена в те-

14
чение некоторого промежутка времени, прошедшего с предыдущей
загрузки. При этом, как правило, формируется два потока данных: поток добавления и поток обновления. В первом потоке передаются новые, ранее не существовавшие данные, а во втором – данные, которые
существовали и ранее, но были изменены со времени предыдущей загрузки. Для организации такого процесса должны быть предусмотрены специальные средства регистрации изменений в данных.
Как правило, в ИС предприятий загрузка данных в корпоративные ХД производится не произвольно, а в соответствии с определенным регламентом. В частности, периодичность загрузки должна соответствовать времени, в течение которого в источниках данных накапливается значительное количество новых данных. Выбор времени загрузки хранилища также имеет значение – оно должно выбираться так,
чтобы не перегружать ЛВС организации (например, в обеденный перерыв или ночью).
Таким образом, обобщенная структура корпоративного ХД и схема движения данных могут быть представлены в виде схемы на рис. 1.3.
Рис. 1.3. Информационная система с централизованным хранилищем и
витринами данных
1.6. Витрины данных
Из реальной жизни известно, что крупные магазины хранят основную массу товаров на складе, доступ к которым занимает определенное время. А для быстрого доступа покупателей к товарам используют витрины или киоски. При этом на витринах и в киосках размещают наиболее часто покупаемые товары, что позволяет снизить время обслуживания клиента и стимулировать продажи. Примерно таки-

15
ми же соображениями можно объяснить появление концепции витрин
или киосков данных (data mart) в структуре корпоративных ХД [7].
Действительно, несмотря на то, что данные в ХД оптимизированы в соответствии с бизнес-моделью компании и по скорости выполнения аналитических запросов, время доступа к нужным данным,
особенно в условиях параллельной работы множества пользователей,
может оказаться достаточно большим. В этой связи видится целесообразным выделить отдельные подструктуры корпоративного ХД, в которых будет храниться тематическая информация по направлениям
работы компании (например, закупки, продажи) или данные, связанные с деятельностью определенных подразделений (например, бухгалтерия, администрация). Именно такие подструктуры и получили название витрин или киосков данных.
Следует отметить, что изначально появление концепции витрин данных в 1991 году как массивов тематической, узконаправленной информации, ориентированной на пользователей одной рабочей
группы или подразделения организации, не было связано с хранилищами данных. Идея объединить концепции ХД и витрин данных
появилась только в 1994 году, что привело к появлению ставшей
стандартом де-факто двухуровневой архитектуры. На верхнем уровне ХД используются высоконормализованные структуры больших
массивов данных, обеспечивающие компактность хранения, но не
оптимальные с точки зрения скорости доступа. На втором уровне
(витрины данных) используются структуры, которые благодаря узкой тематической направленности данных не требуют больших объёмов, что позволяет хранить их в денормализованном виде и обеспечивать быстрой доступ к ним.
Кроме ускорения выполнения запросов, витрины данных позволяют обеспечить еще ряд преимуществ. Во-первых, повышаются возможности администрирования: доступ к данным в витрине можно ограничить только теми пользователями, с работой которых они связаны. Во-вторых, повышается уровень защиты данных: повреждение
или потеря данных в витрине не приводит к их повреждению или потере в центральном ХД.
Таким образом, с учётом ETL и витрин данных структура информационной системы на основе ХД может быть представлена в виде
схемы на рис. 1.3.
Согласно схеме, источниками данных на предприятии являются
системы оперативной регистрации транзакций, получаемых в результате продаж, маркетинговых мероприятий, поступающие из производственных систем управления (ERP), системы управления отношений с

16
клиентами (CRM) и другие. Также могут быть и внешние по отношению к предприятию источники: файлы отдельных пользователей, содержащие структурированные данные, анализ которых может оказаться полезным, статистические сводки и т.д.
Данные из источников посредством процесса ETL выгружаются
в оперативный склад данных (ОСД) и временные таблицы. ОСД содержит неочищенные данные, необходимые для оперативного анализа
для принятия быстрых, тактических решений, для которых важна не
столько точность, сколько оперативность принятия. ОСД позволяет
избежать ожидания загрузки данных в центральное ХД, их предварительной обработки в нём и формирования соответствующего запроса
(всё это может занять несколько часов). В области временного хранения данные проходят предобработку, очистку, интегрирование, после
чего загружаются в ХД.
Получателями данных из ХД могут быть витрины данных, отдельные пользователи и аналитические системы, в которых данные
подвергаются различным алгоритмам и методам анализа с целью извлечения скрытых зависимостей, закономерностей и структур.
1.7. Виртуальные хранилища данных
Как было отмечено выше, одним из важнейших свойств ХД является неизменчивость – данные в хранилищах могут только добавляться,
а их изменение или удаление не предусмотрено. Это свойство позволяет
обеспечить поддержку целостности данных, когда на один и тот же запрос в любой момент времени хранилище формирует один и тот же отклик. Тем не менее, данный подход может вызвать ряд проблем, связанных с актуальностью данных. Действительно, в ХД накапливаются данные за весь период наблюдений, но со временем наиболее ранние данные могут утрачивать свою актуальность с точки зрения анализа. Например, если предприятие изменило номенклатуру изделий, товаров
или услуг, то данные, связанные с изделиями, товарами и услугами, работа с которыми прекратилась, не представляют интереса ни для анализа, ни для отчетности, но продолжают присутствовать в ХД в виде «балласта», что приводит к избыточности.
Чтобы решить данную проблему, была предложена концепция
виртуальных ХД, когда данные не консолидируются физически, а
структуры, эмулирующие работу хранилища, создаются в оперативной памяти с помощью запросов непосредственно к источникам данных. Очевидно, что в этом случае в хранилище попадают только
данные, которые содержатся в источниках на настоящий момент, и
если эти данные актуальны, то и данные в виртуальном хранилище

17
также будут актуальными. Виртуальные ХД так же, как и физические, содержат семантический слой, благодаря которому конечный
пользователь не видит разницы между виртуальным и физическим
ХД.
Кроме актуальности данных, виртуальные ХД обеспечивают
еще ряд преимуществ:
- не требуют места на внешних носителях;
- ускоряется процесс анализа, поскольку исключается процеду-
ра загрузки в физическое ХД, а аналитические запросы направляются
непосредственно к источникам данных.
Виртуальные ХД также имеют ряд очевидных недостатков:
- поскольку данные в виртуальном ХД содержатся в оператив-
ной памяти, выключение, перезагрузка или сбой в работе компьютера приводят к «исчезновению» данных из оперативной памяти;
- сетевые источники данных могут оказаться недоступными из-
за технических проблем;
- историческая информация недоступна для анализа, поскольку
в виртуальном ХД содержатся только текущие данные;
- отсутствует автоматический контроль непротиворечивости и
целостности данных.
Таким образом, выбор между виртуальным и физическим ХД
должен производиться с учётом как аппаратных возможностей информационной системы предприятия, так и используемой бизнесмодели, а также целей и задач анализа. Кроме этого, использование
виртуальных ХД можно порекомендовать предприятиям, у которых
нет технических и финансовых возможностей для развёртывания и
поддержки физических ХД.
1.8. Практический пример построения ХД в АП Deductor
Ниже рассмотрим в качестве примера процедуру развертывания
и загрузки хранилища данных Deductor Warehouse на базе аналитической платформы (АП) Deductior Academic (программа доступна на
сайте разработчика www.basegroup.ru).
Deductor Warehouse – многомерное кросс-платформенное ХД,
входящее в состав аналитической платформы Deductor Enterprise и её
учебной версии Deductor Academic. Хранилище позволяет консолидировать корпоративные данные для оперативного доступа к ним из аналитического приложения.
Первым шагом на пути к построению ХД является проектирование логической структуры данных на основе определенной бизнесмодели. Для этого рассмотрим источники данных, содержащие следующие таблицы (приведены фрагменты).

18
Таблица 1.1. Группы товаров
Код
группы
Наименование группы
33
Иммуномодуляторы
34
Иммунодепрессанты
38
Секретолитики и стимуляторы моторной функции
дыхательных путей
39
Противокашлевые средства
41
Стимуляторы дыхания
46
Психостимуляторы и ноотропы
48
Общетонизирующие средства и адаптогены
50
Местные анестетики
Таблица 1.2. Товары
Код
товара
Наименование товара
Код
группы
35
Адреналина гидрохлорида раствор 0,1% р-р д/ин.
0,1 % амп. 1 мл [с нож.амп.] уп.контурн.яч. 5
159
354
Андрокур табл. 50 мг фл. 20 кор. 1 Schering-Plough
Labo N.V.
178
477
Аспаркам табл. уп.контурн.б/яч. 10 Медисорб
108
485
Аспаркам табл. уп.контурн.б/яч. 10 УсольеСибирский ХФК
108
487
Аспаркам. уп.контурн.яч. 10 Ай Си Эн Лексредства
108
504
Аспирин табл. 500 мг бл. 10 кор. 2 Bayer C.C.
171
506
Аспирин табл. 100 мг бл. 10 кор. 2 Bayer C.C.
171
598
Ацетилсалициловая кислота табл. 0,5 г
уп.контурн.б/яч. 10 Татхимфармпрепараты
171
682
АЦЦ 100 табл.шип. 100 мг туба 20 кор. 1 Hexal AG
38
686
АЦЦ 200 табл.шип. 200 мг туба 20 кор. 1 Hexal
AG
38
690
АЦЦ лонг табл.шип. 600 мг туба 10 кор. 1 Hexal
AG
38
Таблица 1.3. Отделы
Код отдела
Наименование отдела
1
Аптека № 1
2
Аптека № 3

19
3
Аптека № 2
Таблица 1.4. Продажи
Дата про-
дажи
Товар.
Код
Отдел.
Код
Час по-
купки
Кол-во
Сумма
01.12.2008
477 1
11 1
4,45
01.12.2008
477 1
17 2
8,89
01.12.2008
485 1
11 1
4,56
01.12.2008
1813 1
15 1
54,17
01.12.2008
2206 1
14 1
11,58
01.12.2008
2290 1
16 1
179,38
01.12.2008
3381 1
15 1
98,08
01.12.2008
4138 1
15 1
78,74
01.12.2008
6100 1
10 2
116,73
01.12.2008
10208 1
10 1
6,6
Определим, какие данные являются измерениями, какие атрибутами, а какие фактами и что представляет собой процесс.
В табл. 1.1 Код группы является измерением, Наименование
группы - его атрибутом.
В табл. 1.2 Код товара - измерение, Наименование товара - его
атрибутом, а Код группы – ссылкой на одноименное измерение.
В табл. 1.3 Код отдела является измерением, Наименование
отдела - его атрибутом.
В табл. 1.4 Дата, Код отдела, Код товара и Час покупки являются измерениями, Количество и Сумма – фактами. То есть табл. 1.4
представляет собой описание процесса продаж в трех аптеках.
Создание нового ХД. Запустить приложение Deductor Studio.
Общий вид окна программы представлен на рис. 1.4.
Рис. 1.4. Общий вид главного окна аналитического приложения
Deductor Studio

20
Главное окно программы разделено на две части: панель сценариев (слева) и рабочую область (справа). В панели сценариев в виде
иерархического дерева отображается последовательность операций по
аналитической обработке данных начиная с импорта их из заданного
источника. В рабочей области отображаются таблицы с данными и
результаты их аналитической обработки, графики и диаграммы, визуализаторы для представления аналитических моделей в виде карт,
графиков, деревьев и т.д. В верхней части окна расположены панель
инструментов и строка меню. Для создания нового ХД требуется выполнить следующую последовательность действий.
1. Переходим на вкладку «Подключение» в меню «Вид» (или с
помощью кнопки на панели инструментов). В результате вместо
панели «Сценарии» в левой части окна откроется панель «Подключе-
ния», в которой следует воспользоваться кнопкой «Мастер подключений».
2. На 1-м шаге «Мастера подключений» выбрать тип объекта –
Deductor Warehouse (рис. 1.5), после чего нажать «Далее».
Рис. 1.5. Выбор ХД
3. На 2-м шаге требуется определить параметры ХД (рис. 1.6).
Рис. 1.6. Настройка параметров ХД
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]
