Оперативная аналитическая обработка данных ( OLAP )

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

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

В основе OLAP лежит многомерное концептуальное представление (multi-dimensional conceptual view) – наиболее естественный взгляд управляющего персонала на объект управления; множественная перспектива из нескольких независимых измерений, вдоль которых могут быть проанализированы определенные совокупности данных. Одновременный анализ по нескольким измерениям данных определяется как многомерный анализ .

Каждое измерение включает направления консолидации данных из серии последовательных уровней обобщения, где каждый вышестоящий уровень соответствует большей степени агрегации данных по соответствующему измерению. Так, измерение Исполнитель может определяться направлением консолидации, состоящим из уровней обобщения «предприятие – подразделение – отдел – служащий». Измерение Время может даже включать два направления консолидации – «год – квартал – месяц – день» и «неделя – день», поскольку счет времени по месяцам и по неделям несовместим. В этом случае возможен произвольный выбор желаемого уровня детализации информации по каждому из измерений. Операция раскрытия или спуска (drilling down) соответствует движению от высших ступеней консолидации к низшим; напротив, операция свертки или подъема (rolling up) означает движение от низших уровней к высшим.

Концептуальное представление модели данных в продукте OLAP должно быть многомерным по своей природе, то есть позволять аналитикам выполнять интуитивные операции сечения «анализа вдоль и поперек» («slice and dice»), вращения (rotate) и размещения (pivot) направлений консолидации. Пользователь не должен знать, какие конкретные средства используются для хранения и обработки данных, как данные организованы и откуда берутся. Аналитик должен иметь возможность выполнять анализ в рамках общей концептуальной схемы. Преобразования, требующие произвольного определения, должны задаваться на функционально полном формальном языке. Переориентация направлений консолидации, детализация данных в колонках и строках, агрегация и другие манипуляции, свойственные структуре иерархии направлений консолидации, должны выполняться в максимально удобном, естественном и комфортном пользовательском интерфейсе. Настоятельно рекомендуется допущение в каждом серьезном OLAP‑ инструменте как минимум пятнадцати, а лучше двадцати измерений в аналитической модели. Каждое из этих измерений должно допускать практически неограниченное количество определенных пользователем уровней агрегации по любому направлению консолидации.

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

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

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

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

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

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

Благодаря многомерной модели данных пользователям очень легко формулировать сложные запросы, размещать данные в отчете, переходить от сводной информации к детальной или фильтровать данные, выделяя осмысленные подмножества. Например, в типичном кубе с информацией о продажах в качестве измерений выступали бы «Время», «География», «Продукт», «Канал», «Организация» и «Сценарий» (по бюджету и фактически). Типичными мерами могли бы стать «Продажи в долларах», «Продажи в единицах», «Запасы», «Численность персонала», «Доходы» и «Затраты».

В рамках каждого измерения модели данных OLAP могут быть организованы в виде иерархии, представляющей различные уровни их детализации. Например, в измерении «Время» можно выделить уровни «Годы», «Месяцы» и «Дни». Точно так же в рамках измерения «География» вы могли бы ввести уровни «Страна», «Регион», «Штат/провинция» и «Город». Каждая конкретная модель OLAP будет включать определенные значения для каждого уровня иерархии. При просмотре данных OLAP пользователь будет перемещаться вверх и вниз между уровнями данных, чтобы увидеть больше деталей или получить сводную информацию.

В зависимости от ответа на вопрос, существует ли гиперкуб как отдельная физическая структура или лишь как виртуальная модель данных, различают системы MOLAP (Multidimensional OLAP) и ROLAP (Relational OLAP). На заре развития технологии OLAP большинство производителей считало, что единственное возможное решение при создании OLAP‑ приложений связано с использованием специализированной, нереляционной модели хранения. Позднее другие производители обнаружили, что применение определенных структур базы данных (схемы «звезда» и «снежинка»), индексации и хранения агрегатов позволяет использовать для OLAP реляционные системы управления базами данных. Такие производители назвали свою технологию Relational OLAP (ROLAP). Поставщики более старых систем затем приняли термин MOLAP (multidimensional OLAP – многомерная OLAP).

Недавно разработаны гибридные решения для OLAP, которые иногда называют HOLAP (hybrid OLAP). Одновременно используя архитектуры ROLAP и MOLAP, они соединяют лучшие черты обоих решений – превосходную производительность и высокую масштабируемость. Один из подходов к созданию HOLAP включает в реляционную базу данных записи с детальной информацией (занимающие наибольший объем) и в то же время помещает агрегаты в отдельное хранилище архитектуры MOLAP.

Для большинства продуктов OLAP предварительное вычисление агрегатов – это основная стратегия, обеспечивающая выигрыш в производительности. В то же время предварительная агрегация связана со значительными затратами: число агрегатов легко может превысить число исходных точек с детальной информацией, что приводит к резкому росту объема хранимых данных, причем коэффициент взрыва данных может составить около 240, так что для управления 10 Мб входных данных потребовалась бы емкость устройства хранения 2, 4 Гб.

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

Ø

Ø 6. Классификация ИИС. ИИС как совокупность нескольких технологий

⇐ Предыдущая1234567Следующая ⇒

Поделиться: