Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Хранилища данных и OLAP-технологии. Учебное пособие.pdf
Скачиваний:
0
Добавлен:
07.09.2026
Размер:
1 Мб
Скачать
☆
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. Настройка параметров ХД
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]