Технологии хранилища данных

Хранилища данных

Контрольные вопросы по предмету

0


Подпишитесь на бесплатную рассылку видео-курсов:

Смотреть лекцию по частям


Текст видеолекции

Хранилища данных

Лекция 1

Тема лекции: «Технологии хранилища данных»

    1. Концепция хранилища данных.
    2. Организация хранилища данных.
    3. Очистка данных.
 
1.    КОНЦЕПЦИЯ ХРАНИЛИЩА ДАННЫХ.

В области информационных технологий, всегда существовали два взаимодополняющих друг друга направления развития:

Системы, ориентированные на операционную обработку данных - системы обработки данных (СОД).

Системы, ориентированные на анализ данных - системы поддержки принятия решений (СППР).

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

На первых этапах автоматизации требовалось и требуется навести порядок именно в процессах повседневной рутинной обработки (переработки) данных, на что и ориентированы традиционные СОД. Более того, системы СППР являются в определенном смысле вторичными, по отношению к ним. Здесь возможна аналогия с производством. Любая продукция, прежде чем попасть на склад и быть отгружена потребителю, должна быть сначала произведена. И прежде чем заниматься анализом данных, необходимо эти данные иметь (произвести). А именно, это и является одной из функций СОД.

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

Необходимо сделать небольшое терминологическое (или,  если хотите,  историческое) отступление. Сегодня используются два основных варианта перевода термина «Data Warehouse»: Хранилище Данных и Информационное Хранилище. Однако второй вариант перевода, возможно более точно отражая смысл концепции, не совсем корректен. Дело в том, что термин Warehouse используется в информационных технологиях достаточно давно. Ещё в 80-х годах фирмой IBM была предложена концепция «Information Warehouse». И более корректно, оставить термин «Информационное Хранилище» за самостоятельной концепцией развиваемой фирмой IBM.  Каждый из этих терминов несёт самостоятельную смысловую нагрузку, и фирма IBM говорит о том, что «Information Warehouse»  –  это «Data Warehouse Plus».

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

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

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

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

В основе концепции Хранилищ Данных лежат две основополагающие идеи:

1.    Интеграция ранее разъединенных детализированных данных:
- исторические архивы,
- данные из традиционных СОД,
- данные из внешних источников
в едином Хранилище Данных, их согласование и, возможно,  агрегация.

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

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

В 1992 году Уильман Г. Инмон подробно описал данную концепцию в своей монографии «Построение хранилищ данных».

В своей работе Инмон дал следующее определение ХД.

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

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

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

Рассмотрим свойства ХД более подробно.

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

ИНТЕГРАЦИЯ  – ОИД, как правило, разрабатываются в разное время несколькими коллективами с собственным инструментарием. Это приводит к тому, что данные, отражающие один и тот же объект реального мира в разных системах, описывают его по-разному. Обязательная интеграция данных в ХД позволяет решить эту проблему, приведя данные к единому формату.

ПОДДЕРЖКА ХРОНОЛОГИИ – данные в ОИД необходимы для выполнения над ними операций в текущий момент времени. Поэтому они могут не иметь привязки ко времени. Для анализа данных часто важно иметь возможность отслеживать хронологию изменений показателей предметной области. Поэтому все данные, хранящиеся в ХД, должны соответствовать последовательным интервалам времени.

НЕИЗМЕНЯЕМОСТЬ    –   требования к ОИД накладывают ограничения на время хранения в них данных. Те данные, которые не нужны для оперативной обработки, как правило, удаляются из ОИД для уменьшения занимаемых ресурсов. Для анализа, наоборот, требуются данные за максимально больший период времени. Поэтому, в отличие от ОИД, данные в ХД после загрузки только читаются. Это позволяет существенно повысить скорость доступа к данным, как за счет возможной избыточности хранящейся информации, так и за счет исключения операций модификации. При реализации в СППР концепции ХД данные из разных ОИД копируются в единое хранилище. Собранные данные приводятся к единому формату, согласовываются и обобщаются. Аналитические запросы адресуются к ХД (рисунок 1).

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

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

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

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

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

Основными достоинствами виртуального ХД являются:

1)    минимизация объема памяти, занимаемой на носителе информацией;

2)    работа с текущими, детализированными данными.
 
Рисунок 2. Структура СППР с виртуальным ХД.

Однако такой подход обладает многими недостатками.

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

2)    Интегрированный взгляд на виртуальное хранилище возможен только при выполнении условия постоянной доступности всех ОИД. Таким образом, временная недоступность хотя бы одного из источников может привести либо к невыполнению аналитических запросов, либо к неверным результатам.

3)    Выполнение сложных аналитических запросов над ОИД занимает большой объем ресурсов компьютеров, на которых они работают. Это приводит к снижению быстродействия OLTP-систем, что недопустимо, т. к. время выполнения операций в таких системах часто весьма критично.

4)    Различные ОИД могут поддерживать разные форматы и кодировки данных. Часто на один и тот же вопрос может быть получено несколько вариантов ответа. Это может быть связано с несинхронностью моментов обновления данных в разных ОИД, отличиями в описании одинаковых объектов и событий предметной области, ошибками при вводе, утерей фрагментов архивов и т. д. В таком случае цель— формирование единого непротиворечивого взгляда на объект управления — может быть не достигнута.

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

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

Остановимся на основных проблемах создания ХД:

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

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

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

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

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

НЕОБХОДИМОСТЬ ИНТЕГРАЦИИ ДАННЫХ ИЗ НЕОДНОРОДНЫХ ИСТОЧНИКОВ В РАСПРЕДЕЛЕННОЙ СРЕДЕ.

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

ПОТРЕБНОСТЬ В ЭФФЕКТИВНОМ ХРАНЕНИИ И ОБРАБОТКЕ ОЧЕНЬ БОЛЬШИХ ОБЪЕМОВ ИНФОРМАЦИИ.

Свойство неизменности ХД предполагает накопление в нем информации за долгий период времени, что должно поддерживаться постоянным ростом объемов дисковой памяти. Ориентация на выполнение аналитических запросов и связанная с этим денормализация данных приводят к нелинейному росту объемов памяти, занимаемой ХД при возрастании объема данных. Исследования, проведенные на основе тестового набора TPC-D, показали, что для баз данных объемом в 100 Гбайт потребуется память объемом в 4,87 раза большая, чем нужно для хранения полезных данных.

НЕОБХОДИМОСТЬ МНОГОУРОВНЕВЫХ СПРАВОЧНИКОВ МЕТАДАННЫХ.

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

ПОВЫШЕНИЕ ТРЕБОВАНИЙ К БЕЗОПАСНОСТИ ДАННЫХ.

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

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

Витрина данных (ВД)— это упрощенный вариант ХД, содержащий только тематически объединенные данные.

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

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

 
Рисунок 3. Структура СППР с самостоятельными ВД.
Достоинствами такого подхода являются:

- проектирование ВД для ответов на определенный круг вопросов;

- быстрое внедрение автономных ВД и получение отдачи;

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

Недостатками автономных ВД являются:

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

- отсутствие консолидированности данных на уровне предметной области, а,  следовательно,  отсутствие единой картины.

В последнее время все более популярной становится идея совместить ХД и ВД в одной системе. В этом случае ХД используется в качестве единственного источника интегрированных данных для всех ВД (рисунок 4).
 
Рисунок 4. Структура СППР с ХД и ВД.

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

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

- простота создания и наполнения ВД, поскольку наполнение происходит из единого стандартизованного надежного источника очищенных данных — из ХД;

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

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

К недостаткам относятся:

- избыточность (данные хранятся как в ХД, так и в ВД);

- дополнительные затраты на разработку СППР с ХД и ВД.

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

- СППР с физическим (классическим) ХД (см. рисунок 1);

- СППР с виртуальным ХД (см. рисунок 2);

- СППР с ВД (см. рисунок 3);

- СППР с физическим ХД и с ВД (см. рисунок 4).

В случае архитектур с физическим ХД и/или ВД необходимо уделить внимание вопросам организации (архитектуры) ХД и переносу данных из ОИД в ХД.

2. ОРГАНИЗАЦИЯ ХРАНИЛИЩА ДАННЫХ.

2.1.    Категории данных в ХД.

Все данные в ХД делятся на три основные категории (рисунок 5):

- детальные данные;

- агрегированные данные;

-  метаданные.
 

Рисунок 5. Архитектура ХД.

Детальными являются данные, переносимые непосредственно из ОИД. Они соответствуют элементарным событиям, фиксируемым OLTP-системами (например, продажи, эксперименты и др.).

Принято разделять все данные на измерения и факты.

Измерениями называются наборы данных, необходимые для описания событий (например, города, товары, люди и т. п.).

Фактами называются данные, отражающие сущность события (например, количество проданного товара, результаты экспериментов и т. п.).

Фактические данные могут быть представлены в виде числовых или категориальных значений.

В процессе эксплуатации ХД необходимость в ряде детальных данных может снизиться. Ненужные детальные данные могут храниться в архивах в сжатом виде на более емких накопителях с более медленным доступом (например, на магнитных лентах). Данные в архиве остаются доступными для обработки и анализа. Регулярно используемые для анализа данные должны храниться на накопителях с быстрым доступом (например, на жестких дисках).

На основании детальных данных могут быть получены агрегированные (обобщенные) данные.

Агрегирование происходит путем суммирования числовых фактических данных по определенным измерениям.

В зависимости от возможности агрегировать данные они подразделяются на следующие типы:

-  аддитивные  – числовые фактические данные, которые могут быть просуммированы по всем измерениям;

- полуаддитивные – числовые фактические данные, которые могут быть просуммированы только по определенным измерениям;

- неаддитивные  – фактические данные, которые не могут быть просуммированы ни по одному измерению.

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

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

Согласно концепции Захмана (см. лекции по предмету «Архитектура предприятия») метаданные должны отвечать на следующие вопросы — что, кто, где, как, когда и почему:

- что (описание объектов). Метаданные описывают объекты предметной области, информация о которых хранится в ХД. Такое описание включает: атрибуты объектов, их возможные значения, соответствующие поля в информационных структурах ХД, источники информации об объектах и т. п.;

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

- где (описание места хранения). Метаданные описывают местоположение серверов, рабочих станций, ОИД, размещенные на них программные средства и распределение между ними данных;

-  как (описание действий). Метаданные описывают действия, выполняемые над данными. Описываемые действия могли выполняться как в процессе переноса из ОИД (например, исправление ошибок, расщепление полей и т. п.), так и в процессе их эксплуатации в ХД;

-  когда (описание времени). Метаданные описывают время выполнения разных операций над данными (например, загрузка, агрегирование, архивирование, извлечение и т. п.);

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

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

Данные, поступающие из ОИД в ХД, перемещаемые внутри ХД и поступающие из ХД к аналитикам, образуют следующие информационные потоки (см. рисунок 5):

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

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

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

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

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

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

Самый мощный из информационных потоков – входной – связан с переносом данных из ОИД. Обычно информация не просто копируется в ХД, а подвергается обработке: данные очищаются и обогащаются за счет добавления новых атрибутов. Исходные данные из ОИД объединяются с информацией из внешних источников: текстовых файлов, сообщений электронной почты, электронных таблиц и др. При разработке ХД не менее 60% всех затрат связано с переносом данных.

2.2.    ELT-процесс.

Процесс переноса, включающий в себя этапы извлечения, преобразования и загрузки, называют ETL-процессом (Е — extraction, Т — transformation, L — loading: извлечение, преобразование и загрузка, соответственно).

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

Традиционно ETL-системы использовались для переноса информации из устаревших версий информационных систем в новые ИС. В настоящее время ETL-процесс находит все большее применение для переноса данных из ОИД в ХД и ВД.

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

Рисунок 6. ETL-процесс.

ИЗВЛЕЧЕНИЕ ДАННЫХ. Чтобы начать ETL-процесс, необходимо извлечь данные из одного или нескольких источников и подготовить их к этапу преобразования.

Можно выделить два способа извлечения данных:

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

Достоинствами такого способа извлечения данных являются:

- отсутствие необходимости расширять OLTP-систему (это особенно важно, если ее структура закрыта);

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

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

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

- возможность использовать средства OLTP-систем, адаптированные к структурам данных;

- средства выгрузки изменяются вместе с изменениями OLTP-систем и ОИД;

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

ПРЕОБРАЗОВАНИЕ ДАННЫХ. После того как сбор данных завершен, необходимо преобразовать их для размещения на новом месте. На этом этапе выполняются следующие процедуры:

- обобщение данных (aggregation)  – перед загрузкой данные обобщаются.

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

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

- создание полей (field derivation) – при создании полей для конечных пользователей создается и новая информация. Например, ОИД содержит одно поле для указания количества проданных товаров, а второе — для указания цены одного экземпляра. Для исключения операции вычисления стоимости всех товаров можно создать специальное поле для ее хранения во время преобразования данных;

 - очистка данных (cleaning) – направлена на выявление и удаление ошибок и несоответствий в данных с целью улучшения их качества. Проблемы с качеством встречаются в отдельных ОИД, например, в файлах и БД могут быть ошибки при вводе, отдельная информация может быть утрачена, могут присутствовать «загрязнения» данных и др. Очистка также применяется для согласования атрибутов полей таким образом, чтобы они соответствовали атрибутам базы данных назначения.

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

3. ОЧИСТКА ДАННЫХ.

    3.1. Проблемы очистки данных.

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

Основные проблемы очистки данных можно классифицировать по следующим уровням:

- уровень ячейки таблицы;

- уровень записи;

- уровень таблицы БД;

- уровень одиночной БД;

-  уровень множества БД.

Рассмотрим перечисленные уровни и соответствующие им проблемы более подробно.

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

К таким ошибкам можно отнести следующие.

1. Орфографические ошибки (опечатки).  Ошибки, возникающие при вводе информации. Они могут привести к неправильному пониманию, а также к искажению реальных данных. Например, при продаже товара вместо количества 1000 было введено 10 000 или вместо названия товара «Водка» было введено название «Вода».

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

3. Фиктивные значения.  Значения, введенные оператором, но не имеющие смысла. Наиболее часто такая проблема встречается в полях, обязательных для заполнения, но при отсутствии у оператора реальных данных, он вынужден вводить бессмысленные данные. Например: номер социального страхования 999-99-9999, или возраст клиента 999, или почтовый индекс 99999. Проблема усугубляется, если существует вероятность появления реальных данных, которые могут быть приняты за фиктивные. Например, номер социального страхования 888-88-8888 для указания на статус клиента-иностранца "нерезидент" или месячный доход в размере $99,999.99 для указания на то, что клиент имеет работу.

4. Логически неверные значения. Значения, не соответствующие логическому смыслу, вкладываемому в данное поле таблицы. Например, в поле «Город» находится значение «Россия» или в поле «возраст больного» значение 1000.

5. Закодированные значения.  Сокращенная запись или кодировка реальных данных, используемая для уменьшения занимаемого места.

6. Составные значения. Значения, содержащие несколько логических данных в одной ячейке таблицы. Такая ситуация возможна в полях произвольного формата (например, строковых или текстовых). Проблема усугубляется, если отсутствует строгий формат записи информации в такие поля.

Уровень записи.   На данном уровне возникает проблема противоречивости значений в разных полях записи, описывающей один и тот же объект предметной области. Например: для человека возраст не соответствует году рождения: age = 22, bdate = 12.02.50.

Уровень таблицы БД.   На данном уровне возникают проблемы, связанные с несоответствием информации, хранящейся в таблице и относящейся к разным объектам.

На этом уровне наиболее часто встречаются нижеприведенные проблемы.

1)    Нарушение уникальности. Значения, соответствующие уникальным атрибутам разных объектов предметной области, являются одинаковыми.

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

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

empl=(name="John Smith",...);

emp2= (name="J. Smith", . . .) ;

-  противоречивые записи (например, об одном человеке в разных случаях введена разная информация о дате рождения, хотя значения полей уникальны):

empl=(name="John Smith", bdate=12.02.70);

emp2=(name="J.Smith", bdate=12.12.70).

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

Уровень множества БД. На данном уровне возникают проблемы, связанные с неоднородностью,  как структур БД, так и хранящейся в них информации. Можно выделить следующие основные проблемы этого уровня:

- различие структур БД: различие наименований полей, типов, размеров и др.;

-  в разных БД существуют одинаковые наименования разных атрибутов;

- в разных БД одинаковые данные представлены по-разному;

- в разных БД классификация элементов разная;

- в разных БД временная градация разная;

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

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

В целом, очистка данных включает несколько этапов:

1.    Выявление проблем в данных;

2.    Определение правил очистки данных;

3.    Тестирование правил очистки данных;

4.    Непосредственная очистка данных.

1. ВЫЯВЛЕНИЕ ПРОБЛЕМ В ДАННЫХ. Для выявления подлежащих удалению видов ошибок и несоответствий необходим подробный анализ данных. Наряду с ручной проверкой следует использовать аналитические программы. Существует два взаимосвязанных метода анализа: профайлинг данных и Data Mining.

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

Data Mining помогает найти специфические модели в больших наборах данных, например отношения между несколькими атрибутами. Именно на это направлены так называемые описательные модели Data Mining, включая группировку, обобщение, поиск ассоциаций и последовательностей. При этом могут быть получены ограничения целостности в атрибутах. Например, функциональные зависимости или характерные для конкретных приложений бизнес-правила, которые можно использовать для восполнения утраченных и исправления недопустимых значений, а также для выявления дубликатов записей в источниках данных. Например, правило объединения с высокой вероятностью может предсказать проблемы с качеством данных в элементах данных, нарушающих это правило. Таким образом, 99% вероятность правила «итого = количество X единицу» демонстрирует несоответствие и потребность в более детальном исследовании для 1% записей.

2. ОПРЕДЕЛЕНИЕ ПРАВИЛ ОЧИСТКИ ДАННЫХ. В зависимости от числа источников данных, степени их неоднородности и загрязненности, они могут требовать достаточно обширного преобразования и очистки. Первые шаги по очистке данных могут скорректировать проблемы отдельных источников данных и подготовить данные для интеграции. Дальнейшие шаги должны быть направлены на интеграцию данных и устранение проблем множественных источников.

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

3. ТЕСТИРОВАНИЕ ПРАВИЛ ОЧИСТКИ ДАННЫХ. Корректность и эффективность правил очистки данных должны тестироваться и оцениваться, например, на копиях данных источника. Это необходимо для выяснения необходимости корректировки правил с целью их улучшения или исправления ошибок. Этапы определения правил и их тестирование могут выполняться итерационно несколько раз, например, из-за того, что некоторые ошибки становятся заметны только после определенных преобразований.

4. НЕПОСРЕДСТВЕННАЯ ОЧИСТКА ДАННЫХ. На этом этапе выполняются преобразования в соответствии с определенными ранее правилами. Очистка выполняется в два приема. Сначала устраняются проблемы, связанные с отдельными источниками данных, а за тем — проблемы множества БД.

Над отдельными оперативными источниками данных (ОИД) выполняются следующие процедуры.

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

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

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

ПРИМЕР.

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

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

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

После завершения преобразований над данными из отдельных источников можно приступать к их ИНТЕГРАЦИИ. При этом выполняются следующие процедуры.

СОПОСТАВЛЕНИЕ ДАННЫХ, ОТНОСЯЩИХСЯ К ОДНОМУ ЭЛЕМЕНТУ. Данная процедура устраняет противоречивость и дублирование данных из разных источников, относящихся к одному объекту предметной области. Для сопоставления записей из разных источников используются идентификационные атрибуты или комбинация атрибутов. Такими атрибутами могут выступать общие первичные ключи или другие общие уникальные атрибуты. К сожалению, без таких атрибутов процесс сопоставления данных затруднителен.

СЛИЯНИЕ ЗАПИСЕЙ.  Данная процедура объединяет интегрированные записи, относящиеся к одному объекту. Объединение выполняется, если информация из разных записей дополняет или корректирует одна другую.

ИСКЛЮЧЕНИЕ ДУБЛИКАТОВ.  Данная процедура удаляет дублирующие записи. Она производится либо над двумя очищенными источниками одновременно, либо над отдельным, уже интегрированным набором данных. Исключение дубликатов требует, в первую очередь, выявления (сопоставления) похожих записей, относящихся к одному и тому же объекту реального окружения.

Очищенные данные сохраняются в ХД и могут использоваться для анализа и принятия на их основе решений. За формирование аналитических запросов к данным и представление результатов их выполнения в СППР отвечают подсистемы анализа. От вида анализа также зависит и непосредственная реализация структур хранения данных в ХД.

    3.3. Хранилища данных и анализ.

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

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

Необходимо понимать, что концепция ХД:

- это не концепция анализа данных, скорее, это концепция подготовки данных для анализа;

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

Таким образом, КОНЦЕПЦИЯ ХД ОПРЕДЕЛЯЕТ ЛИШЬ САМЫЕ ОБЩИЕ ПРИНЦИПЫ ПОСТРОЕНИЯ АНАЛИТИЧЕСКОЙ СИСТЕМЫ И В ПЕРВУЮ ОЧЕРЕДЬ СКОНЦЕНТРИРОВАНА НА СВОЙСТВАХ И ТРЕБОВАНИЯХ К ДАННЫМ, но не на способах их организации и представления в целевой БД и режимах их использования.

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

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

- организация доступа к данным;

- использование технологии анализа.

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

- регламентированные запросы;

- оперативный анализ данных;

- интеллектуальный анализ данных.

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

ВЫВОДЫ.

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

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

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

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

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

6.  Детальные данные разделяют на два класса: измерения и факты. Измерениями называются наборы данных, необходимые для описания событий. Фактами называются данные, отражающие сущность события.

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

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

9. Наиболее мощным информационным потоком в ХД является входной — поток переноса данных из ОИД в ХД. Процесс переноса, включающий этапы сбора, преобразования и загрузки, называют ETL-процессом.

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

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

12. Очищенные данные сохраняются в ХД и могут использоваться для анализа и принятия на их основе решений. За формирование аналитических запросов к данным и представление результатов их выполнения в СППР отвечают подсистемы анализа. От вида анализа также зависит и непосредственная реализация структур хранения данных в ХД.


СПИСОК РЕКОМЕНДОВАННОЙ ЛИТЕРАТУРЫ.

[1] Барсегян А.А., Куприянов М.С., Степаненко В.В., Холод И.И. Методы и модели анализа данных: OLAP и Data Mining. – СПб.: БХВ-Петербург, 2004. - 336 с.

[2] Елманова Н., Федоров А.  Введение в OLAP-технологии Microsoft. - М.: Диалог-МИФИ, 2002. - 272 с.

[3] Кудрявцев Ю.А. OLAP технологии: обзор решаемых задач и исследований // Бизнес-информатика. – 2008. №1. – С. 66-70.

[4] Фоменко Е.Ю. Хранилища данных. Анализ данных: Курс лекций. - М.: Ф-т ВМиК МГУ им. М.В. Ломоносова, 2007.

[5] Хоббс   Л., Хилсон С., Лоуэнд  Ш. Oracle9iR2: разработка и эксплуатация хранилищ баз данных. Учебно-справочное издание. Пер. С англ. - М.: КУДИЦ-ОБРАЗ, 2004. – 592 с.