Многомерные базы данных, витрины и хранилища данных

1. Введение в распределенные методы обработки информации

Лекция №5
Многомерные базы данных,
витрины
и хранилища данных

2. Недостатки реляционных СУБД

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

3. Недостатки реляционных СУБД

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

4. Недостатки реляционных СУБД

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

5. Расширение использования реляционных БД

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

6. Недостатки реляционных СУБД

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

7. Расширение использования реляционных БД

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

8. Вложенные таблицы

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

9. Вложенные таблицы

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

10. Базы данных для сложных объектов

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

11. Постреляционные СУБД

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

12. Недостатки реляционных систем 

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

13. OLTP и OLAP

Направления в развитии концепций
информационных систем :
• системы оперативной (транзакционной)
обработки: OLTP (Online Transaction Processing)
• системы аналитической обработки (системы
поддержки принятия решений): OLAP (Online
Analytical Processing)

14. Сравнение системных характеристик OLTP и OLAP

Системная характеристика
Учетная система (OLTP)
OLAP
Взаимодействие с
пользователем
На уровне транзакции
На уровне всей базы данных
Данные, используемые при
обращении пользователя к
системе
Отдельные записи
Группы записей
Время отклика
Секунды
От нескольких секунд до
нескольких минут
Использование аппаратных
ресурсов
Стабильное
Динамическое
Характер данных
Главным образом первичные
(самый низкий уровень
детализации)
В основном производные
(сводные значения)
Характер доступа к базе
данных
Предопределенные или
статические пути доступа и
отношения данных
Неопределенные или
динамические пути доступа и
отношения данных
Изменчивость данных
Высокая (данные обновляются с Низкая (во время запроса данные
каждой транзакцией)
обновляются редко)
Приоритеты
Высокая производительность
Высокая доступность
Гибкость
Автономность пользователя

15. Сравнение реляционных терминов и понятий и соответствующих эквивалентов в OLAP.

Реляционная технология OLAP Технология
База данных
База данных
Оператор ORDER BY
Команда SORT
Таблица
Куб
Директива GRANT
PERMIT
Хранимые процедуры,
сценарии, хранимый SQL
Программы и
пользовательские функции
Null-столбцы
Null-значения
Null-значения всегда в
явном виде
Представление (Выборка) Формула
Первичный ключ
Измерения
Внешний ключ, не
являющийся частью
первичного ключа
Отношение
Столбец, не являющийся
частью первичного или
внешнего ключа
Переменная
Null-строки - не могут
быть в таблице или в
результирующем
множестве
Строка
Экземпляр нескольких
переменных
Управление потоковым
языком (PL/SQL, Transact- Язык хранимых процедур
SQL и др.)
Декларативная
целостность ссылочных
данных
Косвенно задается при
определении измерений
Процедурная целостность
Отсутствует
ссылочных данных
(триггеры)
Индексы
Отсутствует
Системный каталог
Метаданные
Оператор JOIN
Отсутствует (косвенно
задается общими
Агрегирование (SUM,
Функции и формулы
AVG, COUNT, MIN, MAX)
Формулы (+, -, /, *, **)
Операторы вычисления (+, более 100 математических,
финансовых,
-, /, *) и два-три десятка
математических,
статистических,
прогнозирующих,
строковых и временных
функций
моделирующих, строковых
и временных функций
Оператор SELECT
REPORT

16. Правила Кодда для OLAP систем

Концептуальное многомерное представление
Прозрачность
Доступность
Постоянная производительность при
разработке отчетов
Клиент-серверная архитектура
Общая многомерность
Динамическое управление разреженными матрицами
Многопользовательская поддержка
Неограниченные перекрестные операции
Интуитивная манипуляция данными
Гибкие возможности получения отчетов
Неограниченная размерность и число уровней агрегации

17. Многомерные СУБД. Основные понятия

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

18. Многомерные СУБД

Математический аппарат СУБД с
изменяемой размерностью или
многомерных СУБД был разработан
выдающимся американским математиком
Доном Нельсоном в 60-х годах по заказу
министерства обороны США.
С 1968 года по настоящее время
многомерные СУБД широко используются
федеральными службами многих стран
мира.

19. Многомерные СУБД

Под многомерной СУБД понимается система
управления базами данных, которая:
реализует т.н. Ненормализованную Реляционную
Форму (ННРФ),
способна обрабатывать модели данных,
адекватные представлениям реального мира
свободна от принципиальных общеизвестных
недостатков, присущих традиционным СУБД на
основе нормализованной реляционной формы
(SQL-подобные СУБД Oracle, Informix, MS SQL
Server и т.п.)

20. Организация данных в многомерных СУБД

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

21. Организация данных в многомерных СУБД

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

22. Многомерные базы данных

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

23. OLAP – On-Line Analytical Processing

Построение многомерных баз данных основано
на подходе OLAP (Online Analytical Processing –
аналитическая обработка в реальном времени),
который нацелен на выборку и обработку данных
максимально эффективным способом.
Принципы OLAP сформулировал в 1993 г. Е. Ф.
Кодд -"изобретатель" реляционных БД.
В 1995 – на основе принципов Э.Кодда возник
тест FASMI, который включает требования к
приложениям, реализующим многомерный
анализ

24. Тест FASMI

Fast - предоставление результатов анализа за
малое время (не более 5c)
Analysis of - возможность осуществления любого
логического и статистического анализа
Shared - многопользовательский доступ к данным с
поддержкой механизмов защиты данных
Multidimensional - многомерное представление
данных, включая поддержку иерархий
Information - возможность доступа к информации
независимо от ее объема и места хранения

25. OLAP -удобный инструмент анализа

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

26. OLAP подход

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

27. Пример

28. Пример (из доклада Савельева Д.М.)

Обычное решение

29. Пример (из доклада Савельева Д.М.)

Правильное современное решение

30. Многомерное представление данных - гиперкуб

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

31. Операции с данными

Срез (разрезание куба) – фильтрация
данных по одному или нескольким
измерениям
Проекция куба – агрегация данных по
одному или нескольким измерениям
(схлопывание куба)

32. OLAP = многомерное представление = Куб

Рис. 2. Пример куба
32

33. "Разрезание" куба

"Разрезание" куба
Рис. 3. Двумерный срез куба для одной
меры
33

34. "Разрезание" куба

"Разрезание" куба
Рис. 4. Двумерный срез куба для нескольких
мер
34

35. "Разрезание" куба

"Разрезание" куба
Рис. 5. Двумерный срез куба с несколькими
измерениями на одной оси
35

36. Метки

Метки нужны для:
"разрезания" куба
ограничения (фильтрации) выбираемых
данных
Значения меток отображаются в двумерном
представлении куба как заголовки строк и
столбцов.
36

37. Обработка данных

Язык MDX (MultiDimensional eXpressions), или
“многомерный SQL”
– Разработан фирмой Микрософт
– Адаптирован в базах данных других компаний (Oracle,
IBM, SAP)
Пример. Определим суммарный объем продаж в 2002-2003 гг в
магазинах Калифорнии, США:
SELECT
{ [Measures].[Store Sales] } ON COLUMNS,
{ [Date].[2002], [Date].[2003] } ON ROWS
FROM Sales
WHERE ( [Store].[USA].[CA] )
Графический интерфейс

38. Технические аспекты многомерного хранения данных

MOLAP(Multidimensional OLAP)
малое количество измерений (~100)
детальные данные –в многомерной БД
агрегаты –тоже в многомерной БД
быстро рассчитывает агрегаты и
возвращает ответы,
но: при работе генерируются огромные
объёмы данных
плохо масштабируемы

39. Технические аспекты многомерного хранения данных

ROLAP(Relational OLAP)
Большое количество измерений (~1000000)
детальные данные –в реляционной БД
агрегаты –в реляционной БД в специально
созданных служебных таблицах
масштабируется лучше, чем MOLAP
скорость обработки запросов значительно
ниже, чем у MOLAP

40. Технические аспекты многомерного хранения данных

HOLAP(Hybrid
OLAP)
вариативное количество измерений
детальные данные –в реляционной
БД
агрегаты –в многомерной БД
достаточно хорошо масштабируется
быстро обрабатывается

41. Реализации OLAP

Физическая OLAP. Программа, выполняющая на этапе
предварительной загрузки данных в OLAP
предварительный расчёт агрегатов, которые затем
сохраняются в специальную многомерную базу данных,
обеспечивающую быстрое извлечение и экономичное
хранение.
Виртуальная OLAP. Все данные хранятся и
обрабатываются в реляционных системах управления
базами данных, а агрегаты могут не существовать
вообще или создаваться по первому запросу в СУБД
или кэше аналитического программного обеспечения.
Гибридная OLAP. Реализация является комбинацией:
сами данные хранятся в реляционной базе данных, а
агрегаты — в многомерной.

42. Особенности OLAP решений

объем исходных данных для анализа должен
быть не слишком велик (не более нескольких
гигабайт)
данные должны быть полными и
непротиворечивыми
набор информационных измерений должен быть
стабилен
наиболее критичный параметр - время ответа
системы на нерегламентированные запросы =>
большинство современных продуктов OLAP
поставляются вместе с огромным количеством
предварительно настроенных запросов

43. Недостатки OLAP решений

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

44. Хранилища и витрины данных

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

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

Хранилище данных –
это предметно-ориентированное,
привязанное ко времени и неизменяемое
собрание данных для поддержки процесса
принятия управляющих решений
William H. Inmon

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

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

47. Различия типичных хранилищ данных от обычной реляционной базы данных: - Базы данных предназначены для автоматизации

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

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

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

49. Витрины данных - достоинства

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

50. Многоуровневое решение в использовании хранилища данных в качестве единого интегрированного источника данных для витрин данных:

- первый уровень — общекорпоративная БД на основе
реляционной СУБД с нормализованной или слабо
денормализованной схемой (детализированные данные);
- второй уровень — БД уровня подразделения (или конечного
пользователя), реализуемые на основе многомерной СУБД
(агрегированные данные);
- третий уровень — рабочие места конечных пользователей,
на которых непосредственно установлен аналитический
инструментарий.

51. Структура хранилища данных

51

52. Достоинства: - компактное хранение детализированных данных и поддержка очень больших БД, обеспечиваемые реляционными СУБД; -

простота настройки и хорошие времена
отклика, при работе с агрегированными
данными, обеспечиваемые
многомерными СУБД.

53. Коммерческие решения

Analysis Services
Hyperion Essbase
Cognos PowerPlay, BusinessObjects,
MicroStrategy
SAP BW
Cartesis Magnitude
Oracle Express
OLAP Option
Applix TM1
53

54. Open-source решения

Mondrian
Palo
54

55. Сравнение

MS Analysis
Services
Essbase
TM1
Mondrian
OLAP
Производител
ь
Microsoft
Oracle
IBM
Pentaho
Тип OLAP
M, R, H
M, R, H
M
R
Язык запросов и
поддержка
хранимых
процедур
XMLA, MDX,
есть
XMLA, MDX,
есть
XMLA, MDX,
нет
XMLA, MDX,
нет
ОС
Windows
Windows,
Linux, Unix
Windows,
Linux, Unix,
z/OS
Windows,
Linux, Unix,
z/OS
Исходный
код
закрыт
закрыт
закрыт
открыт