Найгель Пендс, OLAP Report
Перевод Шамиля Абушаева, Социо Прогресс
Проблема, которая встала перед нами с самого начала исследований OLAP,
заключалась в решении того, какой продукт правомерно относить к категории
OLAP. Решить является ли продукт "именно OLAP" становилось все сложнее
в связи с тем, что все больше и больше поставщиков утверждали, что они
имеют "именно OLAP", в то время как это могло означать все что угодно.
Нельзя было полагаться на собственные описания поставщиков независимо от
их членства в Совете OLAP (OLAP Council). Такое членство не являлось надежным
индикатором того, что компания действительно производит OLAP продукт.
Например, несколько известных поставщиков OLAP не являются членами Совета,
в то же время существуют члены Совета, которые не являются поставщиками
OLAP.
Правила Кодда также, как оказалось, не были удовлетворительным способом
обнаружения "именно OLAP". Так что мы были вынуждены создать наше
собственное определение. Мы исходили из того, что оно должно было быть
простым, незабываемым и независимым от продукта. Такое определение мы назвали
тестом 'FASMI'. Ключевой особенностью, которую все OLAP продукты имеют
- это мультиразмерность или многомерность, но это - не единственное требование
для OLAP изделия.
Тест FASMI
Мы хотели определить характеристики OLAP приложения специфическим образом
без указания на то, каким образом оно должно быть осуществлено. Поскольку
наше исследование показало, что имеется много путей реализации OLAP приложений,
то никакая конкретная технология не должна была быть обязательной, или
даже рекомендованной. Конечно, мы изучили технологии, используемые в коммерческих
OLAP продуктах, и в этом отчете затрагиваются многие детали реализации.
Мы предположили, что при разных условиях и обстоятельствах один подход
может быть предпочтительнее другого, а также идентифицировали области,
где, как мы полагаем, все продукты в настоящее время теряют то, что мы
считали бы идеалом технологии.
Наше определение должно было быть коротким и простым. Помнить 12 правил
или 18 особенностей слишком обременительно для большинства людей. Мы довольны
тем, что оказались способны резюмировать OLAP-определение только пятью
ключевыми словами: Быстрый Анализ Разделяемой Многомерной Информации -
или, кратко - FASMI (в переводе с английского: Fast
Analysis
of Shared
Multidimensional
Information).
Это определение впервые было сформулировано в начале 1995 и с тех пор не
нуждалось в пересмотре.
FAST
(Быстрый) - означает, что система должна обеспечивать выдачу
большинства ответов пользователям в пределах приблизительно пяти секунд.
При этом самые простые запросы обрабатываются в течение одной секунды и
очень немногие - более 20-ти секунд. Недавнее исследование в Нидерландах
показало, что конечные пользователи воспринимают процесс неудачным, если
результаты не получены по истечении 30 секунд.Они способны нажать
"Alt+Ctrl+Del", если система не предупредит их, что обработка данных требует
больше времени. Даже если система предупредит, что процесс будет длиться
существенно дольше, пользователи, могут отвлечься и потерять мысль, при
этом качество анализа страдает. Такую скорость не просто достигнуть с большими
количествами данных, особенно, если требуются специальные вычисления "на
лету". Поставщики прибегают к широкому разнообразию методов, чтобы достигнуть
этой цели, включая специализированные формы хранения данных, обширные предварительные
вычисления, или же ужесточая аппаратные требования. Мы не думаем, что есть
продукты, которые полностью оптимизированы, так что это будет областью
развития технологии. В частности, подход предварительных вычислений дает
сбои с очень большими, разреженными приложениями, так как базы данных просто
становятся слишком большими (проблема взрыва базы данных). Следует принять
во внимание, что выполнение вычислений "на лету" - слишком медленное при
работе с большими базами данных, даже при использовании экзотических аппаратных
средств. На первый взгляд может казаться удивительным, что при получении
отчета за минуту, на который не так давно требовались дни, пользователь
очень быстро начинает скучать во время ожиданий, и проект оказывается намного
менее успешным, чем в случае мгновенного ответа, даже ценой менее детального
анализа.
ANALYSIS
(Анализ) означает, что система может справляться с
любым логическим и статистическим анализом, характерным для данного приложения,
и обеспечивает его сохранение в виде, доступном для конечного пользователя.
Хотя некоторое "предварительное программирование" может быть необходимо,
мы не думаем, что это приемлемый подход, когда все прикладные определения
должны быть выполнены профессионалом языка 4GL. Естественно, необходимо
позволить пользователю определять новые специальные вычисления как часть
анализа и формировать отчеты любым желательным способом, без необходимости
программирования, поэтому мы исключаем продукты (подобно Oracle Discoverer
3.1), которые не предоставляют гибкие средства вычислений, ориентированные
на конечного пользователя. Не так важно, выполнен ли этот анализ в собственных
инструментальных средствах поставщика или в связанном внешнем программном
продукте типа электронной таблицы, просто все требуемые функциональные
возможности анализа должны обеспечиваться интуитивным способом для конечных
пользователей. Средства анализа могли бы включать определенные процедуры,
типа анализа временных рядов, распределения затрат, валютных переводов,
поиска целей, изменения многомерных структур, непроцедурного моделирования,
выявления исключительных ситуаций, извлечения данных и другие операции
зависимые от приложения. Такие возможности широко отличаются среди продуктов,
в зависимости от целевой ориентации.
SHARED
(Разделяемой) означает, что система осуществляет все требования
защиты конфиденциальности (возможно до уровня ячейки) и, если множественный
доступ для записи необходим, обеспечивает блокировку модификаций на соответствующем
уровне. Не во всех приложениях есть необходимость обратной записи данных.
Однако количество таких приложений растет, и система должна быть способна
обработать множественные модификации своевременным, безопасным способом.
Это - главная слабость многих OLAP продуктов, которые имеют тенденцию предполагать,
что во всех приложениях OLAP требуется только чтение, и предоставляют упрощенные
средства защиты. Даже продукты с многопользовательским чтением - записью
часто имеют сырые модели защиты; пример - Microsoft OLAP Services .
MULTIDIMENSIONAL
(Многомерной) -наше ключевое
требование. Если бы мы должны были определить OLAP одним словом, то выбрали
бы его. Система должна обеспечить многомерное концептуальное представление
данных, включая полную поддержку для иерархий и множественных иерархий,
поскольку это определенно наиболее логичный способ анализировать бизнес
и организации. Мы не устанавливаем минимальное число измерений, которые
должны быть обработаны, поскольку оно также зависит от приложения, и большинство
продуктов OLAP, как нам кажется, имеет достаточное количество измерений
для тех рынков, на которые они нацелены. И опять же, мы не определяем,
какая основная технология базы данных должна использоваться, если пользователь
получает действительно многомерное концептуальное представление информации.
INFORMATION
(Информации) - это все. Необходимая информация должна быть
получена там, где она необходима. Однако многое зависит от приложения.
Мы измеряем мощность различных продуктов в терминах того, сколько входных
данных они могут обрабатывать, но не сколько гигабайт они могут хранить.
Мощность продуктов весьма различна - самые большие OLAP продукты могут
оперировать по крайней мере в тысячу раз большим количеством данных по
сравнению с самыми маленькими. По этому поводу следует учитывать много
факторов, включая дублирование данных, требуемую оперативная память, использование
дискового пространства, эксплуатационные показатели, интеграцию с информационными
хранилищами и т.п..
Мы думаем, что тест FASMI - разумное и понятное определение целей, на
достижение которых ориентированы OLAP. Мы предлагаем пользователям и поставщикам
принять это определение, которое, мы надеемся, позволит избежать
имеющихся противоречий.
Техника реализации включает много различных патентованных идей, которыми
так гордятся поставщики: разновидности архитектуры "клиент-сервер", анализ
временных рядов, объектная ориентация, оптимизация хранения данных, параллельные
процессы и т.д. Мы также имеем свое представление об этом, но мы не хотели
бы, чтобы какие-то технологии стали частью определения OLAP. Поставщики,
которые охвачены нашим отчетом, имели все возможности сообщить нам о своих
технологиях, однако нас интересовала более всего их способность достигнуть
целей OLAP в соответствующих прикладных областях, выбранных ими.
Правила
и особенности Кодда
В 1993 Е. Ф. Кодд с партнерами опубликовали статью, инициированную
компанией Arbor Software(сегодня это Hyperion Solutions), озаглавленную
«Обеспечение OLAP (оперативной аналитической обработки) для пользователей
- аналитиков», как некий "мандат" информационной технологии. Доктор Кодд,
конечно, хорошо известен, как классик теории реляционных баз данных, созданной
в период 60-80-х годов, однако его требования к OLAP оказались достаточно
спорными, так как были спонсированы поставщиком, а не обоснованы математически.
Кроме того, не очень ясно, насколько велика роль самого Кодда в написании
этой статьи, есть основания полагать, что его роль, вероятно, не очень
значительна. Эта статья воспринимается как документ, опубликованный
поставщиком (а так оно и есть) скорее, нежели как научный труд (каковой
эта публикация и не является).
Эта статья включала 12 правил, которые теперь хорошо известны. В 1995
году к ним были добавлены еще шесть (которые известны в значительно меньшей
степени). Доктор Кодд разбил на четыре группы эти правила, назвав их "особенностями".
Ниже дано краткое описание этих особенностей, однако заметим, что сегодня
они редко цитируются и мало используются.
Основные особенности
(B)
F1:
Многомерное
концептуальное представление данных (Оригинальное правило 1). Вряд
ли кто будет возражать против этого.Подобно д-ру Кодду мы полагаем,
что эта особенность - сердцевина OLAP.
F2:
Интуитивное
манипулирование данными (Оригинальное правило 10). Д-р Кодд предпочитает,
чтобы манипулирование данными осуществлялось посредством прямых действий
над ячейками в режиме просмотра без использования меню и множественных
операций. Некоторые полагают, что это означает использование мыши (или
эквивалентных средств), но д-р Кодд в действительности не утверждал этого.
Во многих продуктах этого нет, потому что они не нуждаются в поддержке
таких операций, как double clicking (двойной щелчок мышью) или drag-and-drop
(перетаскивание объектов). Все поставщики, как правило, утверждают обратное.
На наш взгляд, эта особенность имеет небольшое значение для оценки продукта.
Мы полагаем, что инструмент должен предлагать выбор того или иного режима
(во всех случаях), так как не всем пользователям нравится подобный подход.
F3:
Доступность:
OLAP как посредник (Оригинальное правило 3). В этом правиле д-р Кодд особенно
подчеркивает роль OLAP в качестве прослойки между гетерогенными источниками
данных и представлением для конечного пользователя. Большинство продуктов
обеспечивает это, но часто посредством гораздо более многочисленных этапов
и пакетирования, чем хотел бы поставщик.
F4:
Пакетное
извлечение против интерпретации (Новое). Это правило требует, чтобы
продукт в равной степени эффективно обеспечивал доступ как к собственному
хранилищу данных, так и к внешним данным. Относительно этой особенности
мы согласны с доктором Коддом. К большому сожалению лишь небольшая часть
OLAP продуктов должным образом соответствует ей, и среди них редкие делают
это легко или автоматически. В сущности д-р Кодд настаивал на многомерном
представлении данных с частичными предварительными вычислениями для больших
многомерных баз данных, так чтобы любые детальные данные были прозрачны
и доступны. Сегодня это соответствует определению гибридных OLAP, которые
в самом деле становятся наиболее популярной архитектурой, так что д-р Кодд
оказался весьма прозорлив в этой области.
F5:
Модели
анализа OLAP (Новое). Д-р Кодд требует, чтобы OLAP проукты поддерживали
все четыре модели анализа, которые он описывает в своей статье (Категориальный,
Толковательный, Умозрительный и Стереотипный). Нам неловко упрощать формулировки
эрудита доктора Кодда, но мы назвали бы их как формирование параметрически
настраиваемых отчетов, формирование разрезов и группировок с обращением,
анализом в стиле "что, если" и моделями поиска целей, соответственно.
Все OLAP инструменты, рассматриваемые в нашем издании ("The OLAP Report"),
поддерживают первые два (хотя некоторые поддерживают второй не в полной
мере), большинство поддерживают третий в той или иной степени (вероятно
в меньшей, чем этого хотел бы д-р Кодд), и лишь некоторые поддерживают
четвертый в отдельных полезных расширениях. Возможно д-р Кодд предвосхищал
системы добычи данных (data mining) в этом правиле?
F6:
Архитектура
"клиент-сервер" (Оригинальное правило 5). Д-р Кодд требует, чтобы продукт
был не только клиент-серверным, но и чтобы серверный компонент был бы достаточно
интеллектуальным для того, чтобы различные клиенты могли подключаться с
минимумом усилий и программирования. Это требование существенно сильнее,
чем просто архитектура "клиент-сервер", и относительно небольшое количество
продуктов удовлетворяют ему. Мы хотели бы возразить, это требование гораздо
жестче, чем необходимо. Мы предпочитаем не диктовать архитектуру. Однако,
если Вы согласны с этим требованием, то Вы должны знать, что большинство
поставщиков, которые утверждают соответствие этому требованию, делают это
ошибочно. В сущности, это косвенно означает, что OLAP доступен с Вашего
рабочего стола. Может быть д-р Кодд предполагал доступ через Web, не используя
этого понятия? Или он предвосхищал повсеместное принятие стандарта, которым
обещает стать OLE DB для OLAP?
F7:
Прозрачность
(Оригинальное правило 2). Это также очень сильное требование. Полное соответствие
ему означает, что, скажем, пользователь электронной таблицы способен получить
все необходимые данные из OLAP-машины, даже не подозревая, откуда они в
конечном счете берутся. Чтобы выполнить это, продукт должен обеспечивать
непосредственный живой доступ к гетерогенным источникам данных и одновременно
иметь встроенную полнофункциональную электронную таблицу. Хотя все
поставщики утверждают соответствие этому требованию, многие делают это,
возмутительным способом переиначивая слова д-ра Кодда. Даже сам д-р Кодд
в своем анализе Essbase и TM1 частично игнорирует это требование. В действительности
есть несколько продуктов, которые полностью соответствуют этому требованию,
включая Acumate и Express, но это ни Essbase, ни TM1, несмотря
на очевидные утверждения д-ра Кодда (потому что они не поддерживают непосредственный
прозрачный доступ к внешним данным). Большинство продуктов не предоставляют
либо доступ к электронным таблицам, либо непосредственный доступ к гетерогенным
источникам. Как и предыдущая особенность это требование слишком сильное
для прямого применения.
F8:
Многопользовательская
поддержка (Оригинальное правило 8). Д-р Кодд признает, что не все OLAP
приложения работают только в режиме чтения данных, и этим правилом указываает
стратегическое направление развития. Инструменты OLAP должны обеспечивать
одновременный доступ (чтение и запись), интеграцию и конфиденциальность.
Мы соглашаемся с доктором Коддом, но также знаем, что еще многие приложения
OLAP работают только в режиме чтения. Напротив, все поставщики заявляют
о соответствиии этому требованию, хотя немногие удовлетворяют ему.
Специальные
особенности (S)
F9:
Обработка
ненормализованных данных (Новое). Оно указывает на нобходимость интеграции
между OLAP-машиной и ненормализованными источниками данных. Доктор
Кодд указывает, что модификации данных, выполненные в среде OLAP не должны
приводить к изменениям данных хранимых в исходных внешних системах. Сказанное
им можно интерпретировать и как то, что не должны допускаться изменения
данных, которые обычно расцениваются как расчетные ячейки в пределах базы
данных OLAP. Например, Essbase позволяет это делать, что вероятно
не получило бы одобрение д-ра Кодда.
F10:
Сохранение
результатов OLAP: хранение их отдельно от исходных данных (Новое).
В дествительности это боле относится к реализации, чем к сущности продукта,
но не многие будут возражать против этого. В сущности д-р Кодд придерживается
широко распространенного мнения о том, что OLAP приложения, работающие
в режиме чтения-записи не должны воздействовать напрямую на обрабатываеме
данные, и данные, модифицированные в OLAP, должны сохраняться отдельно
от данных транзакций. Метод обратной записи данных, использованный в Microsoft
OLAP Services, является лучшей реализацией этого, поскольку позволяет сохранять
данные, измененные в среде OLAP, отдельно от основных данных.
F11:
Исключение
отсутствующих значений (Новое). Все отсутствующие значения отбрасываются
в представлении, определенном версией 2 реляционной модели данных. Мы интерпретируем
это так, что отсутствующие значения должны отличаться от нулевых значений.
В действительности это интересно только с точки зрения компактности хранения
данных, некоторые OLAP инструменты игнорируют это правило без больших потерь
в функциональности.
F12:
Обработка
отсутствующих значений (Новое). Все отсутствующие значения будут игнорироваться
OLAP анализатором без учета их источника. Эта особенность связана с 11-й
и является почти неизбежным следствием того, как OLAP-машина обрабатывает
все данные.
Особенности
представления отчетов (R)
F13:
Гибкость
формирования отчетов (Оригинальное правило 11). Д-р Кодд требует, чтобы
измерения могли быть размещены в отчете так, как это нужно пользователю.
Мы согласны, и большинство продуктов способны это обеспечить в своих средствах
формирования отчетов. Д-р Кодд не уточняет, должна ли эта гибкость обеспечиваться
интерактивно при просмотре. Мы предпочитаем, чтобы это было именно так,
но заметим, что относительно немногие средства просмотра способны к этому.
Поэтому мы предпочитаем, чтобы средства анализа и возможности формирования
отчетов были комбинированы в одном модуле.
F14:
Стандартная
производительность отчетов (Оригинальное правило 4). Д-р Кодд требует,
чтобы производительность формирования отчетов существенно не падала с ростом
количества измерений и размеров базы данных. Странно, но он нигде не упоминал,
что производительность должны быть быстрой, это как бы подразумевалось.
В действительности, наш опыт показывает, что простое увеличение числа измерений
или размеров базы данных существенно не влияет на производительность в
базах данных с полными предварительными вычислениями, что видимо и предполагал
д-р Кодд в своем утверждении. Однако, отчеты с большим содержимым формируются
дольше (в хороших продуктах производительность практически линейно зависит
от количества ячеек, используемых при формировании отчета, которых может
быть гораздо больше, чем тех, что появляются в окончательном отчете). Некоторые
размещения измерений в отчете могут быть медленнее, чем другие, так как
требуют большего количества операций чтения с диска. Относительно данной
особенности между продуктами имеются большие различия, однако принципиальным
фактором, влияющим на производительность, является количество выполняемых
вычислений и где они выполняются (на клиентской машине, на сервере многомерной
базы данных или в реляционной СУБД). Это гораздо важнее, чем размеры базы
данных, количество измерений или сложность формируемого отчета.
F15:
Автоматическая
настройка физического уровня (Замена оригиналього правила 7). Д-р Кодд
требует, чтобы OLAP системы автоматически настраивали свою физическую схему
в зависимости от типа модели, объемов данных и разряженности базы данных.
Мы согласны с ним и очень разочарованы тем, что большинство поставщиков
весьма далеки от этого прекрасного идеала. Мы хотели бы наблюдать больший
прогресс в этой области, а также в связанной с ней области определения
степени использования предварительных вычислений (главная проблема, которую
игнорирует д-р Кодд). Компания Panorama technology, приобретенная компанией
Microsoft в октябре 1996г, заложила здесь новый фундамент, и пользователи
теперь могут извлечь выгоды из Microsoft OLAP Services.
Управление
измерениями (D)
F16:
Универсальность
измерений (Оригинальное правило 6). Д-р Кодд придерживается непорочного
взгляда на то, что все измерения должны быть равноправны, каждое измерение
должно быть эквивалентно и в структуре и в операционных возможностях. Правда
он допускает дополнительные операционные возможности для отдельных измерений
(видимо, подразумевая время), но настаивает на том, чтобы такие дополнительные
функции могли быть предоставлены любому измерению. Он не желает, чтобы
базовые структуры данных, вычислительные или отчетные форматы были более
свойственны какому-то одному измерению. Опытом доказано, что это наиболее
спорное правило из всех 12-ти первоначальных (оригинальных) правил. Технология
ориентирует продукты на соответствие этому правилу, и поставщики соответствующих
продуктов поддерживают его. Приложения ориентируют продукты не прилагать
усилия на его соблюдении, и поставщики таких продуктов с горечью нападают
на это правило.Со строгих пуристских позиций немного продуктов полностью
соблюдают это правило. Мы хотели бы предложить свой взгляд. Если Вы покупаете
инструмент для универсальных целей, для множественных исследований, то
можете рассматривать это правило, но и в этом случае, с более низким приоритетом.
Если Вы покупаете продукт для специфического приложения, то можете спокойно
проигнорировать его.
F17:
Неограниченное
число измерений и уровней агрегации (Оригинальное правило 12). Технически
нет продукта, который мог бы соответствовать этому требованию, потому что
нет такой вещи, как неограниченный объект на ограниченном компьютере. В
любом случае, немного приложений нуждаются в более, чем порядка 8-ми или
10-ти измерениях, немного приложений имеют иерархию более шести консолидированных
уровней. Д-р Кодд предлагает, что в случае принятия некоторого максимума,
он должен обеспечивать по крайней мере 15 измерений, а предпочтительнее
- 20. Мы полагаем, что это тоже очень произвольно и не подтверждается реальной
практикой. Вас могут убеждать, что некоторый продукт имеет слишком большие
ограничения для Вас, однако имеются другие ограничения в OLAP продуктах,
о которых Вы должны беспокоиться больше, чем об этом. Следовательно, на
практике Вы можете вероятно игнорировать это требование.
F18:
Неограниченные
операции между размерностями (Оригинальное правило 9). Д-р Кодд утверждает,
и мы соглашаемся, что все виды операций должны быть дозволены для любых
измерений, а не только для измерений типа "показатель" (мера). В действительности,
многие продукты, которые используют реляционную структуру хранения данных,
слабы в этой области. Большинство продуктов с многомерной базой данных
здесь сильны. Этот тип операций важен, если Вам нужны комплексные сложные
исследования, а не только перекрестные выборки данных, в частности они
уместны в приложениях анализа рентабельности.
Комментарий переводчика
Я согласен с мнением Сахарова А.А., который, рассматривая в своей статье оригинальные 12 правил д-ра Кодда, обратил внимание на то, что в них смешаны:
собственно требования (п.п. 1,2,3,6);
не формализуемые пожелания (п.п.10,11)
Поскольку мы начинали разработку своей системы (МИСТЕР) задолго до появления статьи д-ра Кодда, то я с большим удивлением и удовлетворением нашел, что наш продукт практически полностью удовлетворяет соображениям авторов издания The OLAP Report.
Например, у нас в каждом конкретном отчете, создаваемом пользователем, количество измерений не может быть больше 9-ти, но за многолетний опыт эксплуатации мы не встречали задачу, которая требовала бы увеличения размерности.
Мнение о том, что средства анализа данных и формирования отчетов должны быть объединены в одном модуле, я не только разделяю, но и в опреденной мере иду дальше, у нас в этом же модуле - электронной таблице, с этими средствами объединены и средства формирования запросов. Это означает, что пользователь создавая выходной документ, тем самым формирует запрос. Нет специального языка запросов, на основе созданной таблицы система сама генерирует все необходимые SQL-запросы.
Знаете ли Вы, что в 1974 - 1980 годах профессор Стефан Маринов из г. Грац, Австрия, проделал серию экспериментов, в которых показал, что Земля движется по отношению к некоторой космической системе отсчета со скоростью 360±30 км/с, которая явно имеет какой-то абсолютный статус. Естественно, ему не давали нигде выступать и он вынужден был начать выпуск своего научного журнала "Deutsche Physik", где объяснял открытое им явление. Подробнее читайте в FAQ по эфирной физике.
