экзамен

●оперативные источники данных (ОИД), к которым относятся электронные таблицы и файлы оперативного хранения, используемые для выполнения операций ввода, модификации, удаления и поиска;

●хранилище данных (ХД), к которым относятся структуры данных, используемых для выполнения аналитических запросов.

48. Хранилища данных и их свойства.

Хранилище данных - предметно ориентированный, интегрированный, неизменчивый, поддерживающий хронологию набор данных, организованный для целей поддержки принятия решений.

Основная цель хранилищ данных - интеграция в одном месте логического представления данных, содержащихся в разнотипных БД.

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

Основные свойства, присущие ХД:

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

●интеграция - приведение данных из разнородных источников к единому формату в рамках ХД;

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

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

49. Структура СППР с физическим хранилищем данных. Проблемы создания физического хранилища данных

В отличие от ОИД, в которых хранятся данные, необходимые только для оперативной обработки, для анализа требуются данные за максимально большой временной интервал, которые копируются в ХД из различных ОИД.

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

Такая модель неизбежно приводит к дублированию информации в ОИД и в ХД. Однако Уильям Инмон в своих исследованиях утверждает, что избыточность данных, хранящихся в СППР при использовании ХД, не превышает 1 %, что объясняется следующими причинами:

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

●2. Неактуальная информация оперативно удаляется из ОИД, тем самым в ХД остается незначительное количество дублирующих данных.

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

Достоинствами такого подхода являются:

●минимизация объема информации, занимаемой на физических носителях памяти;

●работа с текущими и детализированными данными.

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

Проблемы создания физического хранилища данных

●необходимость интеграции данных из неоднородных источников в распределенной среде;

●потребность в эффективном хранении и обработке очень больших объемов информации;

●необходимость наличия многоуровневых справочников метаданных;

●повышенные требования к безопасности данных.

50. Различные способы интеграции в СППР ХД и ВД

Подходы интеграции в СППР ХД и ВД

1. Виртуальное хранилище

Структура данных в ОИД может содержаться в разных форматах и кодировках.

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

Процесс создания виртуального ХД достаточно трудоемкий.

Снижения затрат на создание ХД можно добиться, создавая его упрощенный вариант - витрину данных (ВД, Data Mart).

2. Витрина данных

Достоинствами такого подхода являются:

●ориентированность ВД на решение узкого круга вопросов и, как следствие, упрощенная структура данных;

●быстрое внедрение;

●высокая производительность.

Недостатки автономных ВД - это:

●дублирование данных (многократное хранение), как следствие, увеличение расходов на физические хранилища и работы по поддержке данных в консистентном состоянии на разных ВД;

●отсутствие консолидированных данных в едином источнике.

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

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

более полной информационной картины.

Достоинствами такого подхода являются:

●простота создания и наполнения витрин;

●простота расширения СППР за счет добавления новых витрин;

●снижение нагрузки на основное ХД.

К недостаткам относятся: избыточность хранения данных в ХД и ВД; дополнительные затраты на разработку СППР данного типа.

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

хранилищем, с виртуальным, с витринами данных, с интегрированными ВД и физическим хранилищем.

Различные способы интеграции в СППР ХД и ВД виртуальное ХД

самостоятельные ВД

интеграция в СППР ХД и ВД

51. Архитектура ХД. Информационные потоки в хранилища данных. Состав хранилища данных Архитектура ХД

Информационные потоки в хранилища данных

-входной поток (Inflow) образуется данными, копируемыми из ОИД в ХД;

-поток обобщения (Upflow) образуется аrреrированием детальных дaнных и их сохранением в ХД;

-архивный поток (Downflow) образуется перемещением детальных дaнных, количество обращений к которым снизилось;

-поток метаданных (MetaFlow) образуется переносом информации о данных в репозиторий данных;

-выходной поток (Outflow) образуется данными, извлекаемыми пользователями;

-обратный поток (Feedback Flow) образуется очищенными данными, записываемыми обратно в ОИД

Состав хранилища данных

Для удобства работы с ХД необходима информация о содержащихся в нем данных. Такая информация называется метаданными (данные о данных).

Coгласно концепции Дж. Захмана, метаданные должны отвечать на следующие вопросы:

что (описание объектов),

кто (описание пользователей),

где (описание места хранения),

как (описание действий),

когда (описание времени)

и почему (описание причин)

52. Оптимизация хранилища данных.

Для улучшения производительности ХД используют следующие приемы:

-создание таблиц предварительно агрегированных данных;

-индексирование (чтобы избежать необходимости просматривать слишком большие объемы данных);

-хранение данных в отсортированном виде, устраняющем необходимость в процессе "and sort".

-"денормализация" модели - размещение данных в одной таблице, а не в нескольких, которые необходимо соединять.

53. ETL-процесс, его этапы. Извлечение данных. 54. ETL-процесс, его этапы. Преобразование данных. 55. ETL-процесс, его этапы. Загрузка данных.

Процесс переноса, включающий в себя этапы извлечения, преобразования и загрузки, называется

ETL-процессом, где Е - extraction (извлечение), Т - transformation (преобразование), L - loading

(загрузка). Программные средства, обеспечивающие его выполнение, называются ETL-системами.

Рассмотрим более подробно этапы ETL-процесса.

1. Извлечение данных. Чтобы начать ETL-процесс, необходимо извлечь данные из одного или нескольких источников и подготовить их к этапу преобразования. Можно выделить два способа извлечения данных:

1.Извлечение данных вспомогательными программными средствами непосредственно из структур хранения информации (файлов, электронных таблиц, БД и т.п.). Достоинствами такого способа извлечения данных являются: отсутствие необходимости расширять OLTP-систему (это особенно важно, если ее структура закрыта); данные могут извлекаться с учетом потребностей процесса переноса.

2.Выгрузка данных средствами OLTP-систем в промежуточные структуры.

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

2. Преобразование данных. После того как сбор данных завершен, необходимо преобразовать их для размещения на новом месте. На этом этапе выполняются следующие процедуры:

-обобщение данных (aggregation)

-перевод значений (value translation)

-создание полей (field derivation)

-очистка данных (cleaning)

3. Загрузка данных. После того как данные преобразованы для размещения в ХД, осуществляется этап их загрузки. При загрузке выполняется запись преобразованных детальных и агрегированных данных. Кроме того, при записи новых детальных данных часть старых данных может переноситься в архив.

56. Функции хранилища данных.

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

Основные функции хранилища:

-Очистка данных (Data Cleaning)

-Слияние данных (Data Integration)

-Сопоставление данных (Data Mapping)

-Извлечение данных (Data Extraction)

-Преобразование данных (Data Transformation)

-Загрузка данных (Data Loading)

-Обновление (Refreshing)

57. Подходы к построению хранилища данных. Метод Кимбалла.

Метод Кимбалла

Ральф Кимбалл известен своими давними убеждениями, что хранилища данных должны быть понятными и быстрыми. Он создал концепцию, где модель данных строится по восходящему подходу к проектированию архитектуры хранилища данных (DW) - подход “снизу вверх” (bottomup aaproach):

- сначала на основе бизнес-требований формируются витрины данных.

-затем оцениваются первичные источники данных.

-выбирается инструмент извлечения, преобразования и загрузки (ETL) для извлечения различных типов форматов данных из нескольких источников.

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

-и на последнем этапе данные загружаются в размерную модель хранилища данных, денормализованую по своей природе (схема звезда)

58. Подходы к построению хранилища данных. Метод Инмона.

Метод Инмон

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

Билл Инмон, отец хранилищ данных, создал концепцию раработки хранилища данных, которая определяет основные предметные области и сущности, с которыми работает предприятие, такие как клиенты, продукт, поставщик и так далее.

Эта концепция наиболее часто применяется при создании корпоративного хранилища, и такой подход часто называется «сверху вниз» (top-down approach).

-сначала создается нормализованная модель хранилища данных.

-затем создаются витрины размерных данных на основе модели хранилища.

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

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