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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример

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

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

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

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

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

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

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

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

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

Обработка данных Язык 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] ) Графический интерфейс

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Коммерческие решения Analysis Services Hyperion Essbase Cognos PowerPlay, BusinessObjects,  MicroStrategy  SAP BW Cartesis Magnitude Oracle Express OLAP Option Applix TM1

Open-source решения Mondrian Palo

Сравнение