Logo    
Продукты, технологии Проекты, внедрения Новости мира IT Форумы Курилка Новые публикации Учебный центр
CitForum    CITForum на CD Море(!) аналитической информации! :: CITFORUM.RU   
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware HOWTO

14.06.2004

Новости мира IT:

  • 11.06 - SCO понесла очередные убытки
  • 11.06 - Microsoft подала серию исков против спамеров
  • 11.06 - В интернете появится киберполиция нравов
  • 11.06 - Новая технология передачи файлов
  • 11.06 - Россия поставила рекорд по росту рынка DSL-доступа в интернет
  • 11.06 - Четвертый визит Крейга Баррета в Россию
  • 11.06 - Вэс Хайден (Wes Hayden) назначен президентом и CEO компании Genesys
  • 11.06 - Хотите узнать, читают ли ваши письма?
  • 11.06 - 80% спама рассылают компьютеры-зомби
  • 11.06 - МТС может лишиться Украины
  • 11.06 - McDonald’s подключит своих клиентов к интернету
  • 11.06 - Россияне смогут менять сотовых операторов без потери номера
  • 11.06 - LG Electronics наращивает свое присутствие на российском рынке ноутбуков
  • 11.06 - Рынок КПК : взрыв популярности в России
  • 10.06 - Начались поставки ЖК-мониторов Prology на российский рынок
  • 10.06 - Первый в мире mp3-плеер с фотокамерой от IRIVER - iFP-1000 Prism Eye
  • 10.06 - Червь Korgo: опасный эксперимент?
  • 10.06 - Владимир Крюков назначен на должность менеджера регионального развития корпорации INTEL в странах СНГ
  • 10.06 - SCO запрещает Sun открывать код Solaris
  • 10.06 - IBM обвиняется в нарушении авторских прав
  • 10.06 - Серьезная ошибка в Fedora Core 2
  • 10.06 - Критические дыры в браузере Internet Explorer
  • 10.06 - Новый Bluetooth-адаптер CNet CBD-021 с USB-интерфейсом
  • 10.06 - Открыт способ скрещивать оптоволокно
  • 10.06 - Реализован проект внедрения Microsoft Navision в компании «СМАЙЛ».
  • 10.06 - Kyocera Mita открыла учебный центр на базе компании «Микроинформ»
  • 10.06 - Самый маленький смартфон
  • 10.06 - Verbatim начинает поставки двуслойных дисков DVD+R DL
  • 10.06 - Microsoft оспорила решение суда по патентному иску компании Eolas
  • 10.06 - Американские и российские ученые создадут искусственный мозжечок
  • 10.06 - IBM и INTEL объявляют о начале пилотного проекта по выпуску мобильных рабочих станций для разработчиков
  • 09.06 - Алексей Загоренко назначен заместителем генерального директора CSBI по продажам и маркетингу
  • 09.06 - Конкурс по оптимизации под Google
  • 09.06 - Национальным доменом .ua будут управлять «люди в штатском»
  • 09.06 - 63 миллиона доменных имен
  • 09.06 - Школьника, заблокировавшего минское метро, простили
  • 09.06 - 600 млн. мобильников: план-минимум на 2004 г.
  • 09.06 - Французский спамер приговорен к крупному штрафу
  • 09.06 - Найдены еще две модификации червя Korgo
  • 09.06 - В Санкт-Петербурге проходит конференция "Телематика-2004"

    Архив новостей >>>

  • Семинар "Мобильное программирование"
    Москва, 30 июня 2004г


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

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

    В большом числе публикаций аббревиатурой OLAP обозначается не только многомерный взгляд на данные, но и хранение самих данных в многомерной БД [6]. Вообще говоря, это неверно, поскольку сам Кодд отмечает, что "Реляционные БД были, есть и будут наиболее подходящей технологией для хранения корпоративных данных. Необходимость существует не в новой технологии БД, а, скорее, в средствах анализа, дополняющих функции существующих СУБД и достаточно гибких, чтобы предусмотреть и автоматизировать разные виды интеллектуального анализа, присущие OLAP". Такая путаница приводит к противопоставлениям наподобие "OLAP или ROLAP", что не совсем корректно, поскольку ROLAP (реляционный OLAP) на концептуальном уровне поддерживает всю определенную термином OLAP функциональность. Более предпочтительным кажется использование для OLAP на основе многомерных СУБД специального термина MOLAP, как это и сделано в [4, 9].

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

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

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

    Требования к средствам оперативной аналитической обработки

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

    Таблица 1 Правила оценки программных продуктов класса 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 работать в среде клиент-сервер. Главной идеей здесь является то, что серверный компонент инструмента 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. Около 30 наиболее известных перечислены в списке обзорного Web-сервера http://www.olapreport.com/. Обеспечивая многомерное концептуальное представление со стороны пользовательского интерфейса к исходной базе данных, все продукты OLAP делятся на три класса по типу исходной БД.

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

    Помимо перечисленных средств существует еще один класс - инструменты генерации запросов и отчетов для настольных ПК, дополненные функциями OLAP или интегрированные с внешними средствами, выполняющими такие функции. Эти хорошо развитые системы осуществляют выборку данных из исходных источников, преобразуют их и помещают в динамическую многомерную БД, функционирующую на клиентской станции конечного пользователя. Основными представителями этого класса являются BusinessObjects одноименной компании [18], BrioQuery компании Brio Technology [7] и PowerPlay компании Cognos [7].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Описанию схемы звезды (star schema) и рекомендациям по ее применению полностью посвящены работы [14, 22, 16]. Ее идея заключается в том, что имеются таблицы для каждого измерения, а все факты помещаются в одну таблицу, индексируемую множественным ключом, составленным из ключей отдельных измерений (рис. 3). Каждый луч схемы звезды задает, в терминологии Кодда, направление консолидации данных по соответствующему измерению.

    Рис. 3. Пример схемы "звезды"

    В сложных задачах с многоуровневыми измерениями имеет смысл обратиться к расширениям схемы звезды - схеме созвездия (fact constellation schema) и схеме снежинки (snowflake schema) [22]. В этих случаях отдельные таблицы фактов создаются для возможных сочетаний уровней обобщения различных измерений (рис. 4). Это позволяет добиться лучшей производительности, но часто приводит к избыточности данных и к значительным усложнениям в структуре базы данных, в которой оказывается огромное количество таблиц фактов.

    Рис. 4. Пример схемы "снежинки" (фрагмент для одного измерения)

    Увеличение числа таблиц фактов в базе данных может проистекать не только из множественности уровней различных измерений, но и из того обстоятельства, что в общем случае факты имеют разные множества измерений. При абстрагировании от отдельных измерений пользователь должен получать проекцию максимально полного гиперкуба, причем далеко не всегда значения показателей в ней должны являться результатом элементарного суммирования. Таким образом, при большом числе независимых измерений необходимо поддерживать множество таблиц фактов, соответствующих каждому возможному сочетанию выбранных в запросе измерений, что также приводит к неэкономному использованию внешней памяти, увеличению времени загрузки данных в БД схемы звезды из внешних источников и сложностям администрирования. Частично решают эту проблему расширения языка SQL (операторы "GROUP BY CUBE", "GROUP BY ROLLUP" и "GROUP BY GROUPING SETS"); кроме того, авторы статей [14, 16] предлагают механизм поиска компромисса между избыточностью и быстродействием, рекомендуя создавать таблицы фактов не для всех возможных сочетаний измерений, а только для тех, значения ячеек которых не могут быть получены с помощью последующей агрегации более полных таблиц фактов (рис. 5).

    Таблицы фактов для разных сочетаний измерений в запросе

    Рис. 5. Таблицы фактов для разных сочетаний измерений в запросе

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

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

    Назад | Содержание | Вперед

     

    Подписка на новости библиотеки:

    Новые поступления в on-line библиотеку:

    10 июня

  • Oracle: ваш первый шаг к web-службам
  • Винты отдыхают: бездисковая загрузка Windows
  • Как я оживлял Linux
  • Cygwin: начинающим пользователям Linux посвящается
  • Многопотоковые вычисления в системе Linux

    8 июня

  • К вопросу об OLAP
  • Web-сервисы == или != распределенные объекты?
  • Жизнь с Linux: совместно используемые ресурсы и... идеи
  • Алгоритмы триангуляции

    3 июня

  • Конструктор от Microsoft, или Переделываем Internet Explorer своими руками
  • Zope - платформа для веб-хостинга
  • Информация о клиенте - стратегический ресурс
  • Анализ клиентской базы приносит пользу CRM
  • Использование прогнозирующей аналитики в маркетинговых кампаниях

    2 июня
    Обзоры журнала Computer:

  • Всегда ли стоит рассчитывать на худшее?
  • Медные пули в программной индустрии

    1 июня

  • DHCP под Windwos XP: полет нормальный
  • Дельфийское слово
  • Достоинства и проблемы HTML Application
  • Социальная инженерия: защита от умного, который использует дурака

    26 мая

  • Спецификация и форматы обмена данными в разнородных информационных системах на базе XML-технологий
  • Антивирусное программное обеспечение. Исследование эффективности
  • Обустройство пингвинария: IBM ThinkPad notebook
  • Передача данных в интернет при помощи InternetExpress
  • Особенности реализации типа byte в Java Sun's J2SDK

    24 мая

  • Электронная почта в MS SQL Server 2000
  • СОМ-хранилища: подпольная файловая система
  • XML: свобода, ограниченная только фантазией
  • Безопасность сети: то, что должен знать каждый
  • Проблемы отчетов в ACCESS

    20 мая

  • Оперативная интеграция данных на основе XML: системная архитектура BizQuery
  • Математика криптологии
  • Использование USB Flash под Linux
  • Мониторинг материнских плат в Linux
  • Работа с последовательными портами
  • Три письма на Perl

    18 мая

  • Xabre 600: GPU с претензиями
  • Linux: укрощение мыши и монитора
  • Семь вещей, которые нужно знать о VMWare и VirtualPC
  • BlueJ: учебная оболочка или полноценная среда разработки?
  • Inferno - виртуальный пост-Unix в кармане
  • CVS - система управления версиями

    12 мая

  • Бесполезный Perl и общая теория улучшения мира
  • Как подружить Olympus c ПК?
  • Шесть правил ухода за монитором
  • Веб-сервер своими руками
  • Поддержка MS-макросов в DELPHI
  • Интеграция Tomcat с Apache. Развертывание веб-приложений Java2 на Linux-платформе
  • Экстремальное программирование: новые возможности

    29 апреля

  • Linux на работе и дома
  • Автоматическая установка Windows
  • Гостевая книга из Perl'овки
  • HTML Help ActiveX control: всплывающие окна
  • NQL: твои агенты в Сети

    27 апреля

  • Материалы конференции "Корпоративные базы данных-2004"
  • Практическая реализация DNS
  • Shell Extensions и как с ними бороться
  • BI для массового использования:
    Барьеры, которые нужно преодолеть:: Поиск наилучшего способа реализации:: Расчет окупаемости вложений в BI-проект
  • SOAP 1.2 и запрос GET

    22 апреля

  • Обзор XML-стандартов
  • Windows и Delphi на защите секретов
  • Один в поле не воин: межсетевые экраны и антивирусы - братья навеки!
  • Все будет Samba!
  • ISPMail-HOWTO v.2.0

    20 апреля

  • Семейство алгоритмов ARIES
  • Русификация OpenBSD

    19 апреля

  • Как правильно задавать вопросы
  • Сжатие данных в целях экономии места и ускорения работы
  • Концепции построения ERP-систем на предприятии

    15 апреля

  • XML-схема. Часть 0: пример (Рекомендации W3C)
  • Сжатие таблиц в СУБД Oracle9i release 2: анализ эффективности
  • Как правильно деинсталлировать СУБД Informix на платформе Windows
  • Как написать драйвер принтера в BeOS

    Все новости >>>



  • IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware HOWTO

    Реклама на IT-портале citforum.ru

    Нестандартные PR-акции - pr@citforum.ru
    Пресс-релизы и информация в каталог компаний - manager@citforum.ru
    Комментарии: mailto:info@citforum.ru?Subject='From bottom of CIT FORUM' Rambler's Top100 TopList This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2004 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав.