Лекции по "Информационные системы"

Автор работы: Пользователь скрыл имя, 13 Ноября 2011 в 11:59, курс лекций

Краткое описание

Курс лекций по дисциплине «Информационные системы» содержит в себе теоретические основы: множество понятий и определений, которые помогут вам в полной мере овладеть данным курсом.

Содержимое работы - 1 файл

лекции.doc

— 488.50 Кб (Скачать файл)

 

Системы аналитической  обработки данных (САОД)

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

В области  информационных технологий всегда существовало два взаимодополняющих направления:

    • Оперативная (транзакционная, пооперационная) обработка данных (OLTP);
    • Поддержка принятия решений через анализ данных (OLAP).

Оперативная аналитическая обработка и интеллектуальный анализ данных - две составные части  процесса поддержки принятия решений.

С точки зрения бизнес - анализа каждый анализируемый факт удобно рассматривать как функцию от его характеристик. Эти параметры носят название измерений. Естественная структура базы данных для подобного представления - это многомерный куб, ребра которого соответствуют измерениям, а внутренний объем - мерам. Производя сечение куба двумерной плоскостью в том или ином направлении, легко получить взаимозависимость любой пары величин относительно выбранной меры.

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

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

По Кодду, многомерное концептуальное представление (multi-dimensional conceptual view) представляет собой множественную перспективу, состоящую из нескольких независимых измерений, вдоль которых могут быть проанализированы определенные совокупности данных. Одновременный анализ по нескольким измерениям определяется как многомерный анализ. Каждое измерение включает направления консолидации данных, состоящие из серии последовательных уровней обобщения, где каждый вышестоящий уровень соответствует большей степени агрегации данных по соответствующему измерению. Операция спуска (drilling down) соответствует движению от высших ступеней консолидации к низшим; напротив, операция подъема (rolling up) означает движение от низших уровней к высшим (рис. 3.4).

Рис. 3.4. Измерения и направления консолидации данных

Кодд определил 12 правил, которым должен удовлетворять  программный продукт класса OLAP (табл. 3.2).

Таблица 3.2. Правила  оценки программных продуктов класса OLAP

1. Многомерное концептуальное представление данных (Multi-Dimensional Conceptual View) Концептуальное  представление модели данных в продукте OLAP должно быть многомерным по своей  природе, то есть позволять аналитикам выполнять интуитивные операции "анализа вдоль и поперек" ("slice and dice"), вращения (rotate) и размещения (pivot) направлений консолидации.
2. Прозрачность (Transparency) Пользователь  не должен знать о том, какие конкретные средства используются для хранения и обработки данных, как данные организованы и откуда берутся.
3. Доступность (Accessibility) Аналитик должен иметь возможность выполнять  анализ в рамках общей концептуальной схемы, но при этом данные могут оставаться под управлением оставшихся от старого  наследства СУБД, будучи при этом привязанными к общей аналитической модели. То есть инструментарий OLAP должен накладывать свою логическую схему на физические массивы данных, выполняя все преобразования, требующиеся для обеспечения единого, согласованного и целостного взгляда пользователя на информацию.
4. Устойчивая производительность (Consistent Reporting Performance) С увеличением  числа измерений и размеров БД аналитики не должны столкнуться  с каким бы то ни было уменьшением  производительности. Устойчивая производительность необходима для поддержания простоты использования и свободы от усложнений, которые требуются для доведения OLAP до конечного пользователя.
5. Клиент - серверная  архитектура (Client-Server Architecture) Серверный компонент  инструмента OLAP должен быть достаточно интеллектуальным и обладать способностью строить общую концептуальную схему на основе обобщения и консолидации различных логических и физических схем корпоративных баз данных для обеспечения эффекта прозрачности.
6. Равноправие измерений (Generic Dimensionality) Все измерения  данных должны быть равноправны. Дополнительные характеристики могут быть предоставлены  отдельным измерениям, но поскольку  все они симметричны, данная дополнительная функциональность может быть предоставлена  любому измерению. Базовая структура данных, формулы и форматы отчетов не должны опираться на какое-то одно измерение.
7. Динамическая  обработка разреженных матриц (Dynamic Sparse Matrix Handling) Инструмент OLAP должен обеспечивать оптимальную обработку  разреженных матриц. Скорость доступа должна сохраняться вне зависимости от расположения ячеек данных и быть постоянной величиной для моделей, имеющих разное число измерений и различную разреженность данных.
8. Поддержка многопользовательского режима (Multi-User Support) Зачастую несколько аналитиков имеют необходимость работать одновременно с одной аналитической моделью или создавать различные модели на основе одних корпоративных данных. Инструмент OLAP должен предоставлять им конкурентный доступ, обеспечивать целостность и защиту данных.
9. Неограниченная  поддержка кроссмерных операций (Unrestricted Cross-dimensional Operations) Вычисления  и манипуляция данными по любому числу измерений не должны запрещать  или ограничивать любые отношения  между ячейками данных. Преобразования, требующие произвольного определения, должны задаваться на функционально полном формульном языке.
10. Интуитивное манипулирование  данными (Intuitive Data Manipulation) Переориентация  направлений консолидации, детализация  данных в колонках и строках, агрегация и другие манипуляции, свойственные структуре иерархии направлений консолидации, должны выполняться в максимально удобном, естественном и комфортном пользовательском интерфейсе.
11. Гибкий механизм генерации отчетов (Flexible Reporting) Должны поддерживаться различные способы визуализации данных, то есть отчеты должны представляться в любой возможной ориентации.
12. Неограниченное  количество измерений и уровней  агрегации (Unlimited Dimensions and Aggregation Levels) Настоятельно  рекомендуется допущение в каждом серьезном OLAP инструменте как минимум пятнадцати, а лучше двадцати, измерений в аналитической модели. Более того, каждое из этих измерений должно допускать практически неограниченное количество определенных пользователем уровней агрегации по любому направлению консолидации.

Классификация продуктов OLAP по способу  представления данных

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

  1. Самые первые системы оперативной аналитической обработки (например, Essbase компании Arbor Software, Oracle Express Server компании Oracle) относились к классу MOLAP, то есть могли работать только со своими собственными многомерными базами данных. Они основываются на патентованных технологиях для многомерных СУБД и являются наиболее дорогими. Эти системы обеспечивают полный цикл OLAP-обработки. Они либо включают в себя, помимо серверного компонента, собственный интегрированный клиентский интерфейс, либо используют для связи с пользователем внешние программы работы с электронными таблицами. Для обслуживания таких систем требуется специальный штат сотрудников, занимающихся установкой, сопровождением системы, формированием представлений данных для конечных пользователей.
  2. Системы оперативной аналитической обработки реляционных данных (ROLAP) позволяют представлять данные, хранимые в реляционной базе, в многомерной форме, обеспечивая преобразование информации в многомерную модель через промежуточный слой метаданных. К этому классу относятся DSS Suite компании MicroStrategy, MetaCube компании Informix, DecisionSuite компании Information Advantage и другие. Подобно системам MOLAP, они требуют значительных затрат на обслуживание специалистами по информационным технологиям и предусматривают многопользовательский режим работы.
  3. Наконец, гибридные системы (Hybrid OLAP, HOLAP) разработаны с целью совмещения достоинств и минимизации недостатков, присущих предыдущим классам. К этому классу относится Media/MR компании Speedware. По утверждению разработчиков, он объединяет аналитическую гибкость и скорость ответа MOLAP с постоянным доступом к реальным данным, свойственным ROLAP.

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

Архитектура системы многомерного интеллектуального анализа данных представлена на рис. 3.5.

Рис. 3.5. Архитектура системы многомерного интеллектуального анализа данных

Многомерный OLAP (MOLAP)

В специализированных СУБД, основанных на многомерном представлении  данных, данные организованы не в форме  реляционных таблиц, а в виде упорядоченных  многомерных массивов:

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

2) поликубов  (каждая переменная хранится с  собственным набором измерений,  и все связанные с этим сложности  обработки перекладываются на  внутренние механизмы системы).

Использование многомерных БД в системах оперативной аналитической обработки имеет следующие достоинства.

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

С другой стороны, имеются существенные ограничения.

  1. Многомерные СУБД не позволяют работать с большими БД. К тому же за счет денормализации и предварительно выполненной агрегации объем данных в многомерной базе, как правило, соответствует (по оценке Кодда) в 2.5-100 раз меньшему объему исходных детализированных данных.
  2. Многомерные СУБД по сравнению с реляционными очень неэффективно используют внешнюю память. В подавляющем большинстве случаев информационный гиперкуб является сильно разреженным, а поскольку данные хранятся в упорядоченном виде, неопределенные значения удаётся удалить только за счет выбора оптимального порядка сортировки, позволяющего организовать данные в максимально большие непрерывные группы. Но даже в этом случае проблема решается только частично. Кроме того, оптимальный с точки зрения хранения разреженных данных порядок сортировки скорее всего не будет совпадать с порядком, который чаще всего используется в запросах. Поэтому в реальных системах приходится искать компромисс между быстродействием и избыточностью дискового пространства, занятого базой данных.

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

  1. Объем исходных данных для анализа не слишком велик (не более нескольких гигабайт), то есть уровень агрегации данных достаточно высок.
  2. Набор информационных измерений стабилен (поскольку любое изменение в их структуре почти всегда требует полной перестройки гиперкуба).
  3. Время ответа системы на нерегламентированные запросы является наиболее критичным параметром.
  4. Требуется широкое использование сложных встроенных функций для выполнения кроссмерных вычислений над ячейками гиперкуба, в том числе возможность написания пользовательских функций.

Реляционный OLAP (ROLAP)

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

  1. В большинстве случаев корпоративные хранилища данных реализуются средствами реляционных СУБД, и инструменты ROLAP позволяют производить анализ непосредственно над ними. При этом размер хранилища не является таким критичным параметром, как в случае MOLAP.
  2. В случае переменной размерности задачи, когда изменения в структуру измерений приходится вносить достаточно часто, ROLAP системы с динамическим представлением размерности являются оптимальным решением, так как в них такие модификации не требуют физической реорганизации БД.
  3. Реляционные СУБД обеспечивают значительно более высокий уровень защиты данных и хорошие возможности разграничения прав доступа.

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

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

Информация о работе Лекции по "Информационные системы"