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

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

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

введение иерархии в пределах одного измерения - общее понятие ВРЕМЯ естественным образом связано с иерархией значений: год состоит из кварталов, квартал из месяцев и т. д.

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

• базовые операции:
• поворот;
• проекция. При проекции значения в ячейках, лежащих на оси проекции, суммируются по некоторому предопределенному закону;
• раскрытие (drill-down). Одно из значений измерения заменяется совокупностью значений из следующего уровня иерархии измерения; соответственно заменяются значения в ячейках гиперкуба;
• свертка (roll-up/drill-up). Операция, обратная раскрытию;
• сечение (slice-and-dice).

      В зависимости от ответа на вопрос, существует ли гиперкуб как отдельная физическая структура или лишь как виртуальная  модель данных, различают системы MOLAP (Multidimensional OLAP) и ROLAP (Relational OLAP). В первых гиперкуб реализуется как отдельная база данных специальной нереляционной структуры, обеспечивающая максимально эффективный по скорости доступ к данным, но требующая дополнительного ресурса памяти. MOLAP-системы весьма чувствительны к объемам хранимых данных. Поэтому данные из хранилища сначала помещаются в специальную многомерную базу (Multidimensional Data Base, MDB), а затем эффективно обрабатываются OLAP-сервером.

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

      В настоящее время получили развитие HOLAP системы, в которых часть данных хранится в ROLAP, а часть в MOLAP.

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

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

      Несмотря  на то что предсказать, какую именно информацию и в каком виде захочет получить пользователь, работая с СППР, практически невозможно, измерения, по которым проводится анализ, достаточно стабильны. В процессе подготовки того или иного решения пользователь анализирует срез фактов по одному или нескольким измерениям. Анализ информации, исходя из понятий измерений и фактов, иногда называют многомерным моделированием данных (MultiDimensional Modelling, MDM). Таблицы фактов обычно содержат большие объемы данных, тогда как таблицы измерений стараются сделать поменьше. Этого подхода желательно придерживаться потому, что запрос по выборке из объединения таблиц выполняется быстрее, когда одна большая таблица объединяется с несколькими малыми. При практической реализации ХД небольшие таблицы измерений иногда удается целиком разместить в оперативной памяти, что резко повышает эффективность выполнения запросов.

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

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

      При проектировании структуры хранилища  часто возникает желание использовать как можно больше агрегатов и  за счет этого повысить производительность системы. Нетрудно подсчитать, что для модели "звезда" с 10 измерениями можно построить 10!=3.63 миллиона различных агрегированных значений, размещение которых в памяти при установлении связей с соответствующими измерениями приведет к резкому увеличению занимаемого дискового пространства и замедлению доступа к данным. Другая крайность состоит в использовании слишком малого числа агрегатов, а это может привести к необходимости выполнять агрегирование динамически, что заметно снижает эффективность запросов. По некоторым оценкам, при определении оптимального количества агрегатов следует придерживаться принципа 80:20 - 80% ускорения достигается за счет использования 20% кандидатов на агрегаты.  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

     3. глава Проектирование  Хранилищ Данных 

     3.1 Методология проектирования  Хранилищ Данных

1. Планирование и проектирование

         Этот этап включает в себя  следующие задачи:

  Подготовка проекта. Включает в себя составление проектного соглашения. Здесь определяются цели ХД. Составляется календарный график выполнения работ.

     Сбор  требований. Здесь происходит уяснение целей бизнеса. Определяются предметные области. Составляется предварительная библиотека запросов.

          Определение модели данных. Составляется модель данных ХД «звезда».  Определяются объекты,  отношения, элементы данных, спецификации защиты.  Здесь определяем измерения и меры, а также иерархию измерений.

      Модель  процессов загрузки.  Определяются спецификации переноса данных и способы доступа к данным.

      Модель  приложений.   Определяются способы представления информации пользователю.

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

     Оценка  проекта. Здесь проводится  анализ результатов. Анализ риска, стоимости и выгод.

     Далее если оценка удовлетворительная, то переходим  к следующему этапу. Если нет, то возвращаемся на один из предыдущих этапов.

     Проектное предложение  Составляется акт о завершении этапа. Имеется уже готовый проект. 

2. Разработка

     Этот  этап включает в себя следующие задачи:

      Построение  БД   Необходимо оценить неоходимый размер

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

     Прототипы запросов и отчетов

     Оценка  проекта. Здесь проводится  анализ результатов.

       Далее если оценка удовлетворительная, то переходим к следующему этапу. Если нет, то возвращаемся на один из предыдущих этапов.

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

     Процедуры регулярной загрузки данных.  Утверждение расписания загрузки.

     Приложения

     Финальное тестирование системы

     Оценка  проекта. Здесь проводится  анализ результатов.

         Далее если оценка удовлетворительная, то переходим к следующему этапу. Если нет, то возвращаемся на один из предыдущих этапов.

     Документация  всех процедур.

          Определение инфраструктуры поддержки.  Определение администраторов,  регламент загрузки данных и создания  резервной копии)

           Обучение пользователей

3. Установка системы и эксплуатация

     Инсталяция  системных компонентов

      Инициализация расписания процедур регулярной загрузки

     Ввод  в эксплуатацию

4. Анализ протекающих процессов в системе

     Анализ  работы системы

     Подготовка  отчета

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

     3.2 Тестовый проект  по созданию витрины  данных.

       Исходя из вышеприведенной  методологии определим  этапы создания  ВД:

1. Определение предметной области для данной организации.
2. Определение цели создания ВД.
3. Определение библиотеки запросов.
4. Определение объектов изучения. Выделение необходимой части из совокупности первичных источников данных
5. Создание модели ВД (звезда).
6. Определение отношений.
7. Модель процесса загрузки.
8. Модель приложения.
9. Определение архитектуры.
10. Построение базы данных.
11. Загрузка данных.
12. Тестирование. Запросы и отчеты.

 

     А теперь выполним эту цепочку для  создания ВД.

1. Определение предметной области для данной организации.

     Организация представляет собой страховую компанию. Предметная область:

Страховой рынок.

2. Определение цели создания ВД.

     Цель  создания ВД – получение возможности  наблюдать динамику изменения изучаемых  параметров во времени, по продуктам  и по филиалам. Причем необходима возможность  задавания нерегламентированных запросов и получение отчетов в виде удобном пользователю. Получение отчетности по фирме и по филиалам.

3. Определение библиотеки запросов.

Пример необходимых  запросов:

1. Как изменялась продажа продукта «Страхование имущества физ. лиц» в Кукморском филиале с 3-го квартала 1998 года по 3-й квартал 1999 года включительно?
2. Как продавался продукт «Семейное страхование жизни» во всех филиалах в 4-м квартале 1999 года.
3. …………..