Лекция 18 ХРАНИЛИЩА ДАННЫХ Вопрос 1. Типичная

Лекция 18
ХРАНИЛИЩА ДАННЫХ
Вопрос 1. Типичная конфигурация хранилища данных
Систем-источников много, причем разных. Данные переносятся их них
в загрузочную секцию, оттуда они поступают на трансформацию и
интеграцию, а затем загружаются в хранилище. Попав в хранилище, данные
становятся доступными пользователям, выполняющим исследование данных
с помощью OLAP-приложений.
Загрузочная секция представляет собой логический объект, при
помощи которого обозначают место, где входящие данные содержатся в
необработанном формате до передачи их в хранилище. Данные загрузочной
секции физически могут храниться отдельно как двумерные ASCII-файлы
или в БД в виде временных промежуточных таблиц, которые могут быть
снимками или реплицированными из других источников таблицами. Данные
загрузочной секции могут храниться даже во внутреннем формате системы,
обеспечивающей пересылку данных. Пока данные находятся в загрузочной
секции, для анализа они не доступны, поскольку еще не попали в хранилище.
Процесс транзакции на рисунке должным образом не представлен, хотя
именно он обеспечивает пересылку данных из загрузочной секции в
хранилище.
Именно
здесь
располагается
логика,
осуществляющая
транзакцию и интеграцию.
Например, если две подающие системы содержат сведения о клиентах,
но используют разные идентификаторы, то эти данные необходимо
согласовать, а некоторые из них, возможно, дополнить или отбросить. Этот
процесс называется очисткой данных (data scrubbing).
Компьютер, на котором расположено хранилище, это, скорее всего,
мощная многопроцессорная машина. Хранилище может быть реализовано в
виде распределенной среды или трехуровневой архитектуры, где между
клиентом и сервером находится сервер приложений.
Наиболее важный вопрос для хранилища – структура его данных. Ее
хранителем является сервер. В самом простом случае структура данных
хранилища является копией структуры одной из эксплуатируемой базы
данных, в которой выполнена интенсивная денормализация.
Она может быть и довольно сложной и представлять собой результат
слияния нескольких эксплуатируемых БД с последующим выполнением
обобщения результатов и денормалзацией. В таких случаях процесс очистки
или загрузки данных почти наверняка будет происходить при участии
механизма разрешения несоответствия.
Если речь идет о «серьезном» хранилище данных, то модель данных
будет
представлять
собой
очень
сложную
звездообразную
схему,
полученную путем комбинирования данных из внутренних и внешних
источников
с
вероятным
включением
данных
текстур
и
(или)
мультимедийных данных.
Вопрос 2. Многомерные и пространственные модели хранилищ
данных
БД, на которой строится хранилище данных, не обязательно должна
быть реляционной. Многие такие БД основаны не на реляционной, а на
многомерной
модели.
Многомерные
серверы
предназначены
для
оптимизации хранения и выборки многомерных данных с тем уровнем
производительности, которого трудно достичь с помощью реляционной
архитектуры.
В версии 7.3. Oracle успешно реализовала ряд расширений своей
реляционной БД с тем, чтобы при использовании Oracle Spatial Data Option
система непосредственно поддерживала пространственные запросы.
Проблема пространственных данных остра для реляционной БД.
Единственный эффективный путь состоит в том, чтобы разделить двумерное
пространство на некоторое число блоков. Для каждого блока придется
хранить данные о блоке. Условие запроса можно преобразовать в список
уточняющих блоков, который будет служить основой индексного доступа.
Список уточняющих блоков для некоторых запросов может быть очень
длинным, поэтому в Oracle Spatial Data Option используется иерархический
подход. (Oracle Spatial Data Option отдельно не существует).
Основные особенности хранилища данных
1.
данные в ООТ-системе постоянно изменяются, так как в
процессе ввода все время появляются новые и обновленные данные. С
нестатическими данными
нельзя выполнять анализ возможных
ситуаций.
моделирования
В
процессе
пользователю
может
потребоваться одни данные изменить, а другие - нет, чтобы увидеть,
какой от этого получается эффект. Но если за это время изменятся
базовые данные, то особые сравнения абсолютно бесполезны. В Oracle
7 есть метод, который позволяет просмотреть данные, обеспечив при
этом непротиворечивость по чтению. Этот метод заключается в
использовании предложения SET TRANSACTION READ ONLY, но
просматривать данные таким образом можно лишь в течение
относительно короткого промежутка времени.
2.
Данные в организации часто рассредоточены может
хранятся в разнообразных вычислительных системах далеко друг от
друга. Даже если использовать преимущества технологии реляционной
БД, то все равно создать интегрированное представление для таких
данных без предварительного их переноса технически очень сложно.
3.
ООТ- база данных обычно проектируется и оптимизируется
под задачу ввода и сопровождения данных. Перемещение по этим
данным осуществляется под управлением ООТ-приложений. Не всегда
можно обеспечить возможность незапланированного доступа или
перемещения.
4.
Многие ООТ-системы хранят данные только за короткий
промежуток времени. Поэтому они вряд ли будут полезны для анализа
тенденций.
Хранилища данных не возникли за один день, а развивались из
системы поддержки принятия решений (СППР-DSS) и информационных
систем руководителей (ИСР-EIS). Эти системы традиционно работали с
данными, который были идентичны данным в той ОС, где сопровождались
эти данные. Такие системы обращались либо к «живым» данным, либо к их
последней неизменяемой копии.
Хранилища данных не обязательно берут непосредственные копии
рабочих данных из ООТ-системы. Их таблицы строятся на рабочих данных,
но, как правило, включают только те данные, которые касаются процесса
принятия решений.
Источниками данных для хранилища могут являться маркетинговые
агентства, различного рода сервисные системы.
Для принятия стратегических решений обязательно нужно иметь
доступ к представлению рабочих данных корпорации, а в некоторых случаях
– и к данным всего рынка. Чтобы составить полную картину состояния
бизнеса, пользователь должен иметь возможность «пересекать» границы
подразделений, а также иметь в своем распоряжении внешние данные
(например, данные о конкурентах). В такой среде архивные данные так же
важны, как и текущие, следовательно, сопровождать нужно и те и другие.
Сводная информация о бизнесе вместе с интеллектуальными средствами
анализа данных, позволяющего выполнять нерегламентированные запросы,
дает мощный инструмент для принятия решений.
Под хранилищем данных можно понимать не обязательно гигантское
скопление данные, главное – чтобы оно было удобно для анализа. Для
маленьких хранилищ предназначается отдельный термин – киоск данные
(Data Marts).
Хранилище
данных
–
пожиратель
ресурсов,
поэтому
требует
тщательного проектирования и администрирования.
Вопрос 3. Многомерное моделирование и звездообразные схемы
хранилищ данных
Звездообразная схема имеет несколько синонимов: многомерная схема,
куб данных, соединенные по схеме «звезда». Звездообразной называется
потому, что графическое представление напоминает звезду.
Состоит из центральной таблицы фактов (fact table), которая окружена
несколькими таблицами измерений (dimension table). Физическая таблица
фактов часто представляет собой несколько секционированных таблиц.
Таблица измерений
Таблица измерений
Таблица фактов
Таблица измерений
Таблица измерений
Звездообразная схема
Отношения между таблицами фактов и измерений должны быть
простыми, чтобы существовал только один возможный путь соединения
любых двух таблиц и чтобы смысл этого соединения был очевиден и хорошо
понятен.
Ориентированные на конечного пользователя средства нерегламентных
запросов в традиционной реляционной БД не прижились. Даже если
столбцам этой БД дать информативные имена, проблема останется:
отношения внутри модели данных останутся
сложными, а число этих
отношений – большим.
При многомерном моделировании необходимо выявить факты и их
измерения.
Факты
обычно
представляют
собой
основные
виды
бизнес-
деятельности и факторы, влияющие на данный бизнес. Если у организации
есть цель, то требуется определить, какие элементы ее бизнеса играют
главную роль в достижении этой цели.
Таблица измерений – это элементы, которые могут оказывать
определенное влияние или порождать различные тенденции в развитии
фактов. Измерения можно разбить на следующие категории: люди, места,
вещи, время.
Люди
Места
Таблица фактов
Время
Вещи
Таблица фактов может включать и описательную информацию, но это
бывает нечасто. Обычно описательная информация находится в таблице
измерений.
Временное измерение в звездообразной схеме обладает рядом
интересных свойств. Факт, скорее всего, будет связан не с одним моментом
времени, а с каким-то промежутком времени. Следовательно, временное
измерение обычно является обобщающим (например, данные будут
выбираться за месяц по данному товару). Единицей измерения может быть и
день, и неделя, и месяц.
Временное измерение часто выступает в качестве основы для
секционирования таблиц факторов.
Вопрос 4. Извлечение и загрузка данных в хранилища данных
Процесс извлечения и загрузки данных состоит из нескольких этапов.
Один из них выполняется подающей системой, другой – системой хранилища
данных.
Этап 1. Чтение данных
Самая сложная часть задачи состоит в поиске документации,
описывающей элементы данных так, чтобы можно было определить, какие из
них важны и в каком формате они существуют.
Определившись с тем, какие данные нужны, необходимо определить, в
каком формате их использовать. Наиболее распространенным форматом до
сих пор является двумерный файл. Двумерные файлы двух типов: с записями
фиксированной длины и переменной длины.
Этап 2. Фильтрация данных
В идеале нужны только те данные, которые не изменились или
добавились после последнего извлечения. Некоторые хранилища данных
полностью очищают и перезагружают при каждой регенерации, но это
подходит только для небольших хранилищ.
Необходимо определить, какие данные изменились после последнего
извлечения.
В исходной базе данных будут столбцы DATE_CHANGED и
DATE_CREATED, и, извлекая данные, можно построить фильтр на базе этих
столбцов.
Но это не поможет для выявления удаленных записей (если в системе
имеется логическое удаление, то появится столбец DATE_DELETED).
Если же логического удаления нет, то единственный способ выявить
изменения – сравнить полный dump данных с предыдущим (это можно
сделать путем сортировки файлов по ключам и построчного сравнения).
Этап 3. Предотвращение потерь ретроспективных данных
В хранилище важно обеспечить поддержку полной ретроспективной
картины. Например, изменение марки товара может оказать существенное
влияние на сбыт и долю рынка.
Этап 4. Обработка данных
Формат данных, поступающих из механизмов подачи действующих
систем, который необходим для хранилищ, наверняка будет не тем. Таблицы
фактов могут быть довольно близки к требуемой форме, но таблица
измерений, скорее всего, потребует дополнительной обработки и, возможно,
объединения.
Объединяя данные из разных приложений, необходимо искать
компромиссы.
Например, данные поступившие из одной дочерней компании,
содержат только прейскурантную цену, из другой дочерней компании –
содержат только цену реализации, третья компания – передадут обе эти
цены.
Решение, которое будет принято в данном случае, зависит от того, как
эти данные будут интегрированы в хранилище, то есть однозначных
рекомендаций здесь нет.
Этап 5. Перемещение данных
На этом этапе осуществляется перемещение данных из некоторой
системы в загрузочную секцию хранилища. Как правило, используется
форма пересылки файлов. Часто данные необходимо перемещать до их
преобразования, так как в проекте хранилища данных выставляется
требование как можно скорее установить полный контроль над данными.
Этап 6. Загрузка данных в хранилище
Данные переходят из загрузочной секции в хранилище и становятся
доступными. Если данные не подлежат загрузке вразброс (то есть когда
данные из одной записи направляются в несколько таблиц), то SQL*Loader –
один из лучших вариантов, так как обеспечит достаточно эффективную
загрузку, особенно когда используется прямая загрузка, позволяющая
практически обойтись без дополнительных расходов, связанных с вставкой
данных в таблицы Oracle.
Этап 7. Сортировка отклоненных записей
Часто при загрузке генерируются подключения. Причины самые
разные:
В исходной системе «нечистые» данные;
Неправильный порядок загрузки;
Недостаток места в хранилище;
Прерванная, остановленная или частично завершенная загрузка и т.д.
Хранилище, содержащее не полностью загруженные данные, должно
иметь в таблице явный предупреждающий признак. Он должен проверяться
пользовательской системой.
При появлении отброшенных данных на этапе загрузки их нужно
проработать, оценить их важность, исправить. Если исправить нельзя, то
нужен план экстренных действий – например, восстановление хранилища по
недавней резервной копии.
Этап 8. Верификация
Если загрузка произошла успешно, то система почти готова к работе.
Однако, перед работой необходимо прогнать несколько верификационных
тестов. Это может быть набор простых SQL-скриптов, проверяющих
некоторые очевидные вещи, например, если суммируются продажи по
одному измерению, то результат должен совпадать с суммой, полученной
при помощи других измерений и т.д.