|
|
Информационные технологии управления. Информационные технологии и информационные системы Информация. Информатика. Микроэлектроника
Консолидация (rolling up, roll-up, drill-up)
Включает такие обобщающие операции, как простое суммирование значений (свертка) или расчет с использованием сложных вычислений, включающих другие связанные данные. Например, показателю для отдельных компаний могут быть просто просуммированы с целью получения показателей для каждого города, а показатели для городов могут быть "свернуты" до показателей по отдельным странам.
Операция спуска (раскрытия) (drill down)
Операция, обратная консолидации, которая включает отображение подробных сведений для рассматриваемых консолидированных данных. Одно из значений измерения заменяется совокупностью значений из следующего уровня иерархии измерения, при этом заменяются значения в ячейках гиперкуба
Классификация OLAP
Обеспечивая многомерное концептуальное представление со стороны пользовательского интерфейса к исходной БД, все продукты OLAP делятся на несколько классов по типу исходной БД. Многомерный гиперкуб, используемый в OLAP-технологии, может быть реализован в рамках реляционной модели или существовать как отдельная база данных специальной многомерной структуры.
|
Классификация OLAP по назначению
В настоящее время существует два типа OLAP-систем: универсальные, способные решать проблемы создания отчетов в любой из сфер, и «отраслевые», ориентированные на использование лишь в определенных областях. В наших условиях реальный спрос на OLAP-системы сегодня ощущается лишь в сфере банковских и финансовых решений. На Западе же OLAP-системы получили широкое распространение еще и в инженерных и научных учреждениях, где с их помощью выявляются сложные связи различных параметров, в частности, при проведении практических исследований.
Сегодня на отечественном рынке представлено достаточно много OLAP-систем, цены, за клиентскую лицензию которых колеблются в пределах $500 до $3000, в зависимости от уровня сложности и ориентации. Системы, ориентированные на использование на крупных предприятиях с поддержкой многопользовательского режима, могут стоить еще дороже. Впрочем, указанные цены касаются лишь стоимости самих программных продуктов. Как и любая другая система автоматизации, OLAP для адекватной работы требует услуг интегратора (чья стоимость может многократно превышать цену самой системы), связанных с правильным отбором и настройкой источников данных для проведения анализа.
Таким образом, можно констатировать, что OLAP – удовольствие не из дешевых и по-настоящему эффективным станет лишь при использовании его инструментов не только ведущим менеджером компании, но и его ближайшими подшефными. Что же касается длительности развертывания OLAP-системы, нужно быть готовым к срокам внедрения от одного, двух месяцев до нескольких, в случае внедрения масштабных решений со «сложными» источниками данных.
|
Классификация OLAP по типу доступа к БД
Как детальные данные, так и агрегаты могут храниться либо в реляционных, либо в многомерных структурах. Многомерное хранение позволяет обращаться с данными как с многомерным массивом, благодаря чему обеспечиваются одинаково быстрые вычисления суммарных показателей и различные многомерные преобразования по любому из измерений. Некоторое время назад OLAP-продукты поддерживали либо реляционное, либо многомерное хранение. Сегодня, как правило, один и тот же продукт обеспечивает оба этих вида хранения, а также третий вид - смешанный.
Все продукты OLAP делятся на следующие классы по типу исходной БД.
|
MOLAP
Это многомерная (multidimensional) OLAP
В основе продукта лежит не реляционная структура данных, обеспечивающая многомерное хранение, обработку и представление данных - исходные и многомерные данные хранятся в многомерной БД или в многомерном локальном кубе. В этом случае получается наибольшая избыточность, так как многомерные данные полностью содержат реляционные.
Такой способ хранения обеспечивает высокую скорость выполнения OLAP-операций. Но многомерная база в этом случае чаще всего будет избыточной. Куб, построенный на ее основе, будет сильно зависеть от числа измерений. При увеличении количества измерений объем куба будет экспоненциально расти. Иногда это может привести к "взрывному росту" объема данных, парализующему в результате запросы пользователей.
Многомерная база данных (MDB, Multidimensional Database)
Мощная база данных со специальной организацией хранения - кубами, позволяющая пользователям анализировать большие объемы данных. Многомерная база данных позволяет обеспечивать высокую скорость работы с данными, хранящимися как совокупность фактов, измерений и заранее вычисленных агрегатов.
В специализированных СУБД, основанных на многомерном представлении данных, данные организованы не в форме реляционных таблиц, а в виде упорядоченных многомерных массивов:
Все хранимые в БД ячейки должны иметь одинаковую размерность, то есть находиться в максимально полном базисе измерений
Каждая переменная хранится с собственным набором измерений, и все связанные с этим сложности обработки перекладываются на внутренние механизмы системы.
Использование многомерных БД в системах оперативной аналитической обработки имеет следующие достоинства:
высокая производительность. Продукты, относящиеся к этому классу, обычно имеют сервер многомерных БД. Данные в процессе анализа выбираются исключительно из многомерной структуры, а в таком случае поиск и выборка данных осуществляется значительно быстрее, чем при многомерном концептуальном взгляде на реляционную базу данных, так как многомерная база данных денормализована, содержит заранее агрегированные показатели и обеспечивает оптимизированный доступ к запрашиваемым ячейкам
поиск и выборка данных осуществляется значительно быстрее, чем при многомерном концептуальном взгляде на реляционную базу данных -среднее время ответа на нерегламентированный запрос при использовании многомерной СУБД обычно на один - два порядка меньше, чем в случае реляционной СУБД с нормализованной схемой данных
структура и интерфейсы наилучшим образом соответствуют структуре аналитических запросов. Этот способ более родственен ментальной модели человека, так как аналитик привык оперировать плоскими таблицами. Производя сечение куба двумерной плоскостью в том или ином направлении, легко получить взаимозависимость любой пары величин относительно выбранной меры. Например, как изменялась стоимость изготовления изделия (мера) во времени (измерение) в разрезе по участкам, цехам и производствам (другое измерение)
многомерные СУБД легко справляются с задачами включения в информационную модель разнообразных встроенных функций, тогда как объективно существующие ограничения языка SQL делают выполнение этих задач на основе реляционных СУБД достаточно сложным, а иногда и невозможным.
MOLAP могут работать только со своими собственными многомерными БД и основываются на патентованных технологиях для многомерных СУБД, поэтому являются наиболее дорогими. Эти системы обеспечивают полный цикл OLAP-обработки и либо включают в себя, помимо серверного компонента, собственный интегрированный клиентский интерфейс, либо используют для связи с пользователем внешние программы работы с электронными таблицами. Для обслуживания таких систем требуется специальный штат сотрудников, занимающихся установкой, сопровождением системы, формированием представлений данных для конечных пользователей.
Еще к недостаткам MOLAP-моделей можно отнести:
не позволяют работать с большими БД. На сегодняшний день их реальный предел – 10-20 гигабайт. К тому же за счет денормализации и предварительно выполненной агрегации 20 гигабайт в многомерной базе, как правило, соответствуют (по оценке Кодда) в 2.5-100 раз меньшему объему исходных детализированных данных, то есть в лучшем случае нескольким гигабайтам.
по сравнению с реляционными, очень неэффективно используют внешнюю память. Ячейки гиперкуба хранятся в них в виде логически упорядоченных массивов (блоков фиксированной длины), причем именно такой блок является минимальной индексируемой единицей. Хотя в многомерных СУБД блоки, не содержащие ни одного определенного значения, не хранятся, это решает проблему только частично. Поскольку данные хранятся в упорядоченном виде, неопределенные значения не всегда удаляются полностью, да и то лишь в том случае, когда за счет выбора порядка сортировки данные удается организовать в максимально большие непрерывные группы. Но порядок сортировки, чаще всего используемый в запросах, может не совпадать с порядком, в котором они должны быть отсортированы в целях максимального устранения несуществующих значений. Таким образом, при проектировании многомерной БД часто приходится жертвовать либо быстродействием (а это одно из первых достоинств и главная причина выбора именно многомерной СУБД), либо внешней памятью (хотя, как отмечалось, максимальный размер многомерных БД ограничен)
отсутствуют единые стандарты на интерфейс, языки описания и манипулирования данными
не поддерживают репликацию данных, часто используемую в качестве механизма загрузки. Следовательно, использование многомерных СУБД оправдано только при следующих условиях:
объем исходных данных для анализа не слишком велик (не более нескольких гигабайт), то есть уровень агрегации данных достаточно высок.
набор информационных измерений стабилен (поскольку любое изменение в их структуре почти всегда требует полной перестройки гиперкуба).
время ответа системы на нерегламентированные запросы является наиболее критичным параметром.
требуется широкое использование сложных встроенных функций для выполнения кроссмерных вычислений над ячейками гиперкуба, в том числе возможность написания пользовательских формул и функций.
|
ROLAP
Программный продукт ROLAP (Реляционный OLAP, Relational OLAP) предназначен для многомерного анализа данных, метаданных и вычисленных агрегатов. Настоящий ROLAP-продукт обеспечивает многомерный анализ данных, хранящихся в реляционной БД, и может работать с любой стандартной реляционной СУБД. Для физической реализации многомерной модели данных используется реляционный сервер БД. Многомерная обработка данных выполняется либо на сервере реляционной БД, либо на сервере промежуточного уровня, либо на стороне клиента.
ROLAP-системы позволяют представлять данные, хранимые в классической реляционной базе, в многомерной форме или в плоских локальных таблицах на файл-сервере, обеспечивая преобразование информации в многомерную модель через промежуточный слой метаданных. Агрегаты хранятся в той же БД в специально созданных служебных таблицах. В этом случае гиперкуб эмулируется СУБД на логическом уровне.
|
Достоинства и недостатки ROLAP
Непосредственное использование реляционных БД в качестве исходных данных в системах аналитической оперативной обработки имеет следующие достоинства:
реляционные СУБД имеют реальный опыт работы с очень большими БД и развитые средства администрирования. При использовании ROLAP размер хранилища не является таким критичным параметром, как в случае MOLAP.
при оперативной аналитической обработке содержимого ХД инструменты ROLAP позволяют производить анализ непосредственно над хранилищем (потому что в подавляющем большинстве случаев корпоративные ХД реализуются средствами реляционных СУБД)
в случае переменной размерности задачи, когда изменения в структуру измерений приходится вносить достаточно часто, ROLAP системы с динамическим представлением размерности являются оптимальным решением, так как в них такие модификации не требуют физической реорганизации БД, как в случае MOLAP.
системы ROLAP могут функционировать на гораздо менее мощных клиентских станциях, чем системы MOLAP, поскольку основная вычислительная нагрузка в них ложится на сервер, где выполняются сложные аналитические SQL-запросы, формируемые системой
реляционные СУБД обеспечивают значительно более высокий уровень защиты данных и хорошие возможности разграничения прав доступа.
О недостатках ROLAP-систем уже говорилось при перечислении преимуществ использования многомерных БД. Это, во-первых, ограниченные возможности с точки зрения расчета значений функционального типа, а во-вторых – меньшая производительность. Для обеспечения сравнимой с MOLAP производительности реляционные системы требуют тщательной проработки схемы БД и специальной настройки индексов. Но в результате этих операций производительность хорошо настроенных реляционных систем при использовании схемы «звезда» вполне сравнима с производительностью систем на основе многомерных БД.
|
Метаданные
Данные о данных
Метаданные (Metadata) - это данные о данных. Метаданные представляют собой описание структуры данных и методов их обработки. Кроме того, в метаданных может содержаться дополнительная информация о БД, являющихся источниками и получателями информации, о сведениях, помещаемых в хранилище, а также о качестве данных в хранилище. Также метаданные включают сведения о преобразованиях данных, о дате последнего обновления и о правах доступа пользователей к информации.
Плотная БД (Dense DB)
Хотя MOLAP обеспечивает лучшую производительность, но их структуры нельзя использовать для обработки больших объемов данных, поскольку большая размерность потребует больших аппаратных ресурсов, а вместе с тем плотность гиперкубов может быть очень низкой и, следовательно, использование аппаратных мощностей не будет оправданным. Наоборот, ROLAP обеспечивает обработку на больших массивах хранимых данных, так как возможно обеспечение более экономичного хранения, но, вместе с тем, значительно проигрывает в скорости работы многомерной. Плотная БД (Dense DB) – это многомерная база данных, если относительно высокий процент (по крайней мере, 10%) возможных комбинаций ее измерений содержит данные.
Агрегатные данные могут помещаться в служебные таблицы в той же БД. Преобразование данных из реляционной БД в многомерные кубы происходит по запросу OLAP-средства. При этом скорость построения куба будет сильно зависеть от типа источника данных и порой приводит к неприемлемому времени отклика системы. Для большинства ХД наиболее эффективным способом моделирования N-мерного куба фактов является схема "звезда" (star schema).
|
Схема звезды
Схема звезды (Star schema) - схема построения большинство реляционных БД, ориентированных на использование средствами многомерного анализа. Ее идея заключается в том, что имеются таблицы для каждого измерения, а все факты помещаются в одну таблицу. Обычно измерения имеют несколько уровней, каждый из которых представлен в виде заголовка столбца таблицы измерения.
Основными составляющими структуры ХД являются таблица фактов (fact table) и таблицы измерений (dimension tables).
| |
|
|
Скачать 2.04 Mb.