🗊Презентация Технология баз данных в системах поддержки принятия решений

Технология баз данных в системах поддержки принятия решений Лекция №6 для студентов 4-го курса специальности «Прикладная информатика»

Вопросы Компоненты систем поддержки принятия решений. Структура хранилища данных. Материализованные представления. Оперативные аналитические приложения.

Системы поддержки принятия решений – основа ИТ-инфрас-труктуры различных компаний, поскольку эти системы дают возможность преобразовывать обширную бизнес-информа-цию в ясные и полезные выводы. Системы поддержки принятия решений – основа ИТ-инфрас-труктуры различных компаний, поскольку эти системы дают возможность преобразовывать обширную бизнес-информа-цию в ясные и полезные выводы. Сбор, обслуживание и анализ больших объемов данных, – это гигантские задачи, которые требуют преодоления серь-езных технических трудностей, огромных затрат и адекват-ных организационных решений. Системы оперативной обработки транзакций (online trans-action processing – OLTP) позволяют накапливать большие объемы данных, ежедневно поступающих из пунктов про-даж. Приложения OLTP, как правило, автоматизируют струк-турированные, повторяющиеся задачи обработки данных, такие как ввод заказов и банковские транзакции. Эти под-робные, актуальные данные из различных независимых то-чек ввода объединяются в одном месте, и затем аналитики смогут извлечь из них значимую информацию. Агрегирован-ные данные применяются для принятия каждодневных биз-нес-решений – от управления складом до координации рек-ламных рассылок.

1 Компоненты систем поддержки принятия решений Система поддержки принятия решений – сложная структу-ра с многочисленными компонентами. Рассмотрим гипоте-тическую компанию Footwear Sellers Company, которая производит обувь и предлагает ее покупателям по каналам прямых продаж и через реселлеров. Руководителям отдела маркетинга FSC необходимо изв-лечь следующую информацию из агрегированных бизнес-данных: пять штатов, сообщивших о самых больших за последний год тем-пах роста объема продаж в категории продуктов для молодежи; общий объем продаж обуви в Нью-Йорке за последний месяц по различным видам продуктов; 50 городов с самым большим количеством индивидуаль-ных клиентов; один миллион клиентов, которые, скорее всего, приоб-ретут новую модель обуви Walk-on-Air.

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

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

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

2.1 Логическая архитектура базы данных В архитектуре, основанной на схеме «звезда», база данных состоит из таблицы фактов, которая описывает все транз-акции, и таблицы измерений для каждой из сущностей. В примере с FSC каждая транзакция охватывает несколько сущностей – клиент, продавец, продукт, заказ, дата сделки и город, где сделка состоялась. Каждая сделка также имеет параметры – в нашем случае число проданных экземпляров продукта и общая сумма, которую заплатил покупатель. Схема «снежинка» – усовершенствованная схема «звезда», в которой иерархия измерений представляется точным об-разом благодаря нормализации таблиц измерений. В «зве-зде» набор атрибутов описывает каждое измерение и мо-жет быть связан иерархией отношений.

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

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

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

4 Оперативные аналитические приложения

4.1 Концептуальная модель данных Многомерная модель, изображенная на рисунке, ис-пользует численные параметры как объекты своего анализа.

Каждый численный параметр в концептуальной модели дан-ных зависит от измерений, которые описывают сущности в транзакции. Например, измерения, связанные с продажами в примере FSC, – это клиент, продавец, город, название проду-кта и дата совершения сделки. Все вместе измерения уника-льным образом определяют параметр, поэтому многомерная модель данных трактует параметр как значение в многомер-ном пространстве. Каждый численный параметр в концептуальной модели дан-ных зависит от измерений, которые описывают сущности в транзакции. Например, измерения, связанные с продажами в примере FSC, – это клиент, продавец, город, название проду-кта и дата совершения сделки. Все вместе измерения уника-льным образом определяют параметр, поэтому многомерная модель данных трактует параметр как значение в многомер-ном пространстве. В многомерном представлении данных запросы drill-down и roll-up – это логические операции на кубе. Еще одна популяр-ная операция – сравнить два параметра, которые агрегиро-ваны по одним и тем же измерениям, такими как продажи и бюджет.

OLAP-анализ может включать в себя более сложные статис-тические вычисления, нежели простые агрегаты, такие как сумма или среднее. Примером может служить такая функ-ция, как изменение процента агрегата в определенный пери-од по сравнению с различными периодами времени. Подоб-ные дополнительные функции поддерживают многие ком-мерческие средства OLAP. OLAP-анализ может включать в себя более сложные статис-тические вычисления, нежели простые агрегаты, такие как сумма или среднее. Примером может служить такая функ-ция, как изменение процента агрегата в определенный пери-од по сравнению с различными периодами времени. Подоб-ные дополнительные функции поддерживают многие ком-мерческие средства OLAP. Измерение «Время» имеет особое значение для таких про-цессов поддержки принятия решений, как анализ тенденций. К примеру, аналитикам FSC может понадобиться проследить покупательскую активность в отношении спортивной обуви перед крупнейшими национальными легкоатлетическими соревнованиями или после них. Развернутый анализ тенденций возможен, если база данных поддерживает встроенную информацию о календаре и ряд других характеристик «Времени». OLAP Council определил перечень операций для многомерных кубов.