Смекни!
smekni.com

Технология хранилищ данных (стр. 3 из 11)

Без поддержки хронологии (наличия исторических данных) нельзя говорить о решении задач прогнозирования и анализа тенденций. Но наиболее критичными и болезненными оказываются вопросы, связанные с согласованием данных.

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

1.2.2 Свойства Хранилищ Данных.

Подробнее опишем – какими свойствами должно обладать содержимое ХД:

1. Предметная ориентация

2. Интегрированность данных

3. Инвариантность во времени

4. Неразрушаемость - cтабильность информации

5. Минимизация избыточности информации

1 Предметная ориентация

В отличие от БД в традиционных OLTP-системах, где данные подобраны в соответствии с конкретными приложениями, информация в DW ориентирована на задачи поддержки принятия решений.. Для системы поддержки принятия решений требуются "исторические" данные - факты продаж за определенные интервалы времени. Хорошо спроектированные структуры ХД отражают развитие всех направлений бизнеса компании во времени.

Поскольку в технологии ХД объекты данных выходят на первый план, то особые требования предъявляются к структурам БД, используемым для создания информационных хранилищ. Принципиально отличаются и структуры баз данных для OLTP сиитем и систем ХД. Во втором случае в них помещается только та информация, которая может быть полезной для работы систем поддержки принятия решений (DSS).

2 Интегрированность данных

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

Если в четырех разных приложениях пол клиента кодировался четырьмя различными способами, то в информационном хранилище будет использована единая для всех данных схема кодировки (например, f,m).

3 Инвариантность во времени

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

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

4 Неразрушаемость - cтабильность информации

В OLTP-системах записи могут регулярно добавляться, удаляться и редактироваться. В ХД, как следует из требования временной инвариантности, однажды загруженные данные теоретически никогда не меняются. По отношению к ним возможны только две операции: начальная загрузка и чтение (доступ). Это и определяет специфику проектирования структуры базы данных для ХД. Если при создании OLTP-систем разработчики должны учитывать такие моменты, как откаты транзакций после сбоя сервера, борьба с взаимными блокировками процессов (deadlocks), сохранение целостности данных, то для DW данные проблемы не столь актуальны - перед разработчиками стоят другие задачи, связанные, например, с обеспечением высокой скорости доступа к данным.

5 Минимизация избыточности информации

Поскольку информация в DW загружается из OLTP-систем, возникает вопрос, не ведет ли это к чрезмерной избыточности данных? Не обязательно. И это объясняется следующими причинами:

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

1.2.3 Взаимное соотношение концепции Хранилищ Данных и концепций анализа данных

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

То есть она фактически не затрагивает и оставляет свободу выбора в вопросах, относящихся:

- к конкретным способам представления данных в целевой БД (например многомерное, реляционное или смешанное);

- режимам анализа данных (статический или динамический).

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

- традиционный статический анализ данных;

- динамический интерактивный многомерный анализ данных.

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

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

Характеристика Статический анализ Динамический анализ
Типы вопросов Сколько? Как? Когда? Почему? Что будет, если?
Время отклика Не регламентируется Секунды
Типичные операции Регламентированный отчет, диаграмма Последовательность интерактивных отчетов, диаграмм, экранных форм.
Динамическое изменение уровней агрегации и срезов данных.
Уровень аналитических требований Средний Высокий
Тип экранных форм В основном, определенный заранее, регламентированный Определяемый пользователем
Уровень агрегации данных Детализированные и суммарные В основном, суммарные
Возраст данных Исторические и текущие и прогнозируемые Исторические, текущие и прогнозируемые
Типы запросов В основном, предсказуемые Непредсказуемые, от случаю к случаю
Назначение Регламентированная аналитическая обработка Многопроходный анализ, моделирование и построение прогнозов

Таблица 3. Сравнение характеристик статического и динамического анализа.

У истоков концепции многомерного динамического анализа - OLAP, стоит основоположник реляционного подхода Э. Кодд [2], сформулировавший 12 основных требований к средствам реализации OLAP.

Заметим, что у Кодда, термин "OLAP" обозначает исключительно конкретный способ представления данных на концептуальном уровне - многомерный.

Однако исторически сложилось так, что сегодня термин "OLAP" подразумевает не только многомерный взгляд на данные со стороны конечного пользователя, но и многомерное представление данных в целевой БД [33]. Именно с этим связано появление в качестве самостоятельного термина "Реляционный OLAP" (ROLAP).

Закономерен вопрос, как взаимно соотносятся концепции: Хранилищ Данных и различные концепции анализа данных (например, как соотносятся концепция Хранилищ Данных и OLAP/ROLAP)? По-видимому, правильный ответ состоит в том, что формально обе они говорят об одном и том же: "Что требуется для успешной реализации информационной системы, ориентированной на аналитическую работу с данными". Но, однако, это два различных взгляда.

Взгляд со стороны конечного пользователя (выраженный Э. Коддом), который главным образом сосредоточен на концептуальном уровне представления данных и на выработке методологии анализа данных. При этом он, естественно, говорит о том, что исходные данные могут храниться в различных источниках и должны быть обеспечены эффективные средства для их выборки и транспортировки. Но для него эти процессы вторичны, а главное состоит в том, что конечному пользователю должен быть предоставлен максимально комфортный и эффективный инструментарий визуализации и манипулирования данными - OLAP Tools.