ORACLE DISCOVERER 3.0: БЫСТРЫЕ НЕРЕГЛАМЕНТИРОВАННЫЕ ЗАПРОСЫ, МНОГОМЕРНЫЙ АНАЛИЗ И РЕЛЯЦИОННЫЕ СИСТЕМЫ

РУССКОЕ ИЗДАНИЕ ORACLE MAGAZINE - №2(4) 1997г.

КРИСТИНА ГИББ
МЕНЕДЖЕР ОТДЕЛА ТЕХНОЛОГИЙ DSS
КОРПОРАЦИЯ ORACLE

Хранилища данных привлекают все большее внимание как средство реализации анализа данных и оперативной аналитической обработки (On-Line Analytical Processing, OLAP); в тоже время идея реализации OLAP на реляционных базах данных вызывает дискуссии. В этой статье обсуждаются такие преимущества реализации OLAP на реляционных базах данных как уменьшение стоимости сопровождения, защита данных, простота присоединения к серверу и доступность подробных данных.

Кроме того, описывается, как повысить производительность OLAP на этих базах данных за счет введения уровня метаданных, который содержит предварительно агрегированные данные, специальной (smart) индексации, минимальной агрегации данных на клиентской стороне приложения и использования схем типа “звезда”. Для иллюстрации предлагаемой концепции используются продукт Oracle Discoverer/2000 и проект Odysseus.

1. OLAP И МНОГОМЕРНЫЙ АНАЛИЗ

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

1.1 КОДД И 12 “ПРАВИЛ” OLAP

Термин OLAP был введен в 1993 году коллективом в составе: E.F. Codd, S.B. Codd (его жена) и C.T. Salley в статье “Providing OLAP to User-Analysts: An IT Mandate”. В ней определены следующие 12 “правил” OLAP:

1. МНОГОМЕРНЫЕ КОНЦЕПТУАЛЬНЫЕ ПРЕДСТАВЛЕНИЯ

Данные для пользователя должны быть представлены в многомерной парадигме.

2. ПРОЗРАЧНОСТЬ

Пользователь не обязан знать, что он использует базу данных OLAP.

3. ДОСТУПНОСТЬ

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

4. СОГЛАСОВАННАЯ ПРОИЗВОДИТЕЛЬНОСТЬ ОТЧЕТОВ

Производительность должна быть одинаковой, независимо от числа используемых измерений.

5. АРХИТЕКТУРА КЛИЕНТ/СЕРВЕР

Программные средства должны работать в архитектуре клиент/сервер.

6. РАВНОПРАВНОСТЬ ИЗМЕРЕНИЙ

Все измерения должны быть равноправными; не может быть”крена” в сторону какого-то одного измерения.

7. ДИНАМИЧЕСКАЯ ОБРАБОТКА РАЗРЕЖЕННЫХ ДАННЫХ

Нулевые (null) значения должны храниться эффективно.

8. ПОДДЕРЖКА МНОГИХ ПОЛЬЗОВАТЕЛЕЙ

Программные средства должны поддерживать более одного пользователя!

9. ОТСУТСТВИЕ ОГРАНИЧЕНИЙ НА ОПЕРАЦИИ С РАЗНЫМИ ИЗМЕРЕНИЯМИ

Правила агрегации единообразно и согласованно применяются ко всем измерениям.

10.ПРОСТОТА МАНИПУЛИРОВАНИЯ ДАННЫМИ

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

11.ГИБКАЯ СИСТЕМА ОТЧЕТНОСТИ Пользователи должны иметь возможность представлять данные в любой удобной для них форме.

12.НЕОГРАНИЧЕННОЕ ЧИСЛО ИЗМЕРЕНИЙ И УРОВНЕЙ АГРЕГАЦИИ

Модель не должна иметь ограничений на число измерений и уровней агрегации.

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

Правила
(1) Многомерные концептуальные представления
(2) Прозрачность
(6) Равноправность измерений
требуют специальных функциональных возможностей, и можно легко проверить их наличие в том или ином конкретном продукте.

Правила
(9) Отсутствие ограничений на операции с разными измерениями
(12) Неограниченное число измерений и уровней агрегации
попросту говоря, напоминают, что не должно быть искусственных ограничений, налагаемых программным продуктом.

Эти правила являются точными, но можно и не требовать их точного выполнения в тех случаях, когда эти ограничения определяются достаточно большими значениями.

Правила
(3) Доступность
(5) Архитектура клиент/сервер
(7) Динамическая обработка разреженных данных
(8) Поддержка многих пользователей
являются просто архитектурными требованиями, причем довольно спорными. Насколько важны эти требования, следует определять в каждом конкретном случае. Например, для автономного анализа данных о ежегодных продажах может оказаться достаточно однопользовательской системы на базе ПК. Так стоит ли в этом случае беспокоиться о том, что нарушены правила (5) и (8)?

Правила
(4) Согласованная производительность отчетов
(10) Простота манипулирования данными
(11) Гибкая система отчетности
очень субъективны, и скорее похожи на добрые намерения, чем на конкретные правила, которые могут либо выполняться, либо нарушаться.

Правило (1) означает, что многомерность – неотъемлемая часть OLAP, а в других правилах идет речь о том, как должны поддерживаться эти многомерные представления, так что предлагаемые Коддом правила не являются полностью независимыми друг от друга.

1.2 МНОГОМЕРНАЯ ЛОГИЧЕСКАЯ МОДЕЛЬ ДАННЫХ

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

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

Правила многомерных моделей утверждают, что мы должны уметь делать плоские срезы (slice) многомерного куба и поворачивать (dice) его нужной гранью любым удобным нам образом. Это нужно для ответа на запросы типа:
  Каково общее количество сотрудников каждой категории в феврале?
  Каково среднее количество сотрудников каждой категории для каждого отдела в прошлом году?
  Проанализируйте изменение во времени числа сотрудников первой категории отдела 30.
Кроме того, мы должны также уметь выполнять суммирование по любому измерению(ям), а также выделять часть значений любого измерения(ий). Короче говоря, мы должны иметь возможность манипулировать данными, представленными в виде куба, а не в виде строк и столбцов, как в реляционной модели.

1.3 МНОГОМЕРНЫЕ ОПЕРАЦИИ

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

1.4 ЧТО НУЖНО БИЗНЕСУ

При обсуждении различий между разными моделями данных легко потерять из вида общую идею (как говорится, за деревьями не увидеть леса!). Темпы развития современного бизнеса и обострение конкурентной борьбы вызывают резкий рост потребности в самой свежей и точной информации обо всех аспектах деятельности организаций. Помимо выполнения запросов для оперативной обработки (кто из клиентов не оплатил счета за текущий месяц, уложился ли наш отдел в рамки бюджета на покупку аппаратуры), необходимо определить те области, где можно улучшить ведение бизнеса, сократить издержки, увеличить эффективность, выйти на новые рынки, выявить бесполезные затраты, определить тенденции изменения объемов продаж. По мере роста объема данных, содержащихся в корпоративных базах данных, растет и зависимость от них положения дел в организации. Это приводит к резкому повышению требований к доступу и анализу данных, а также к росту числа работающих с ними пользователей. А значит, необходимо существенное расширение функциональности средств анализа информации, среди которых многомерный анализ — это лишь одно из возможных направлений.

2. МНОГОМЕРНЫЕ И РЕЛЯЦИОННЫЕ МОДЕЛИ

2.1 РЕЛЯЦИОННЫЕ ХРАНИЛИЩА ДАННЫХ

Типичная ситуация такова, что структуры данных больших операционных реляционных баз данных лучше приспособлены к поддержке оперативной обработки данных (OLTP), чем для поддержки процессов принятия решений (DSS) и анализа информации. Причина этого ясна каждому, кто занимался созданием систем оперативной обработки данных: подсистемы ввода данных практически всегда разрабатываются и реализуются раньше, чем приступают к рассмотрению проблем анализа данных, что и приводит к упомянутой выше ситуации.

Кроме того, бытует своего рода народная легенда, согласно которой, так как SQL допускает любую форму доступа к любым данным в любых таблицах, то (ошибочный вывод!!!) не стоит слишком беспокоиться о том, как структурированы таблицы; мы всегда можем сформулировать SQL-запрос, который выдаст нужные нам данные. Этот вывод, действительно, может оказаться справедлив для небольших объемов данных, но по мере роста объема данных возникает необходимость в таких структурах данных, которые облегчили бы процедуру запросов к ним. Так появились реляционные хранилища данных – набор таблиц, обычно формируемых из одной или нескольких оперативных систем, информация которых комбинируется, объединяется и подытоживается так, чтобы упростить жизнь пользователям, которые запрашивают эту информацию или занимаются ее анализом.

В приведенном выше примере базы данных “Сведения о персонале” в реляционной модели данные могут быть размещены многими способами; в реляционном же хранилище данных типичной организацией данных является схема типа “звезда”.

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

Когда мы говорим о реляционной модели, состоящей из строк и столбцов, мы, тем не менее, не должны забывать, что имеем в виду только логическую модель, которая используется для понимания того, что мы можем делать с данными. На самом деле, данные хранятся на диске не в виде строк и столбцов, а образуют там некоторую упорядоченную структуру, которая отображается в строки и столбцы логической модели только при запросах пользователя. Отсюда следует важный вывод, что в многомерной системе данные должны быть представлены “по-многомерному” только при их выборке, храниться же они могут в каком угодно виде, лишь бы во время выборки мы могли отобразить их в многомерную модель, и, конечно, сам процесс выборки должен быть достаточно быстрым.

2.2 ДОВОДЫ ПРОТИВ ИСПОЛЬЗОВАНИЯ РЕЛЯЦИОННЫХ СУБД ДЛЯ МНОГОМЕРНЫХ ОПЕРАЦИЙ

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

2.2.1 ПРОИЗВОДИТЕЛЬНОСТЬ

“Так как реляционные базы данных управляют двумерными таблицами, при выполнении таких многомерных операций, как получение среза куба, возникают фундаментальные проблемы с производительностью. Для получения результатов необходимо часто проводить операции соединения таблиц и агрегирования данных, которые заметно понижают производительность. Пользователи OLAP (аналитики) могут заблокировать пользователей OLTP, а индексы таблиц не оптимизированы для выборки данных”.

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

2.2.2 SQL НЕ ГОДИТСЯ ДЛЯ МНОГОМЕРНЫХ ОПЕРАЦИЙ

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

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

Однако, нет причин, по которым пользовательский интерфейс для анализа данных должен напрямую отображаться на физические структуры, используемые для хранения данных. На самом деле, вследствие сложности схемы базы данных OLTP-приложений мы должны поступать как раз наоборот – даже если конечный пользователь и захочет использовать все возможности работы с данными, необходимо скрыть от него физическую структуру и механизм доступа к данным на уровне языка SQL. Продукты типа Discoverer/2000, чтобы скрыть от пользователя реляционную схему и представлять информацию не в технических терминах, а в терминах предметной области, используют уровень метаданных. Расширяя уровень метаданных и делая его не пассивным, а активным, мы можем обеспечить выполнение большинства многомерных операций непосредственно над реляционной базой данных. Подробнее это объясняется в следующем разделе.

2.2.3 SQL НЕ МОЖЕТ ВЫПОЛНЯТЬ НЕКОТОРЫЕ ВИДЫ МНОГОМЕРНЫХ ЗАПРОСОВ

“Некоторые многомерные операции, например, ранжирование (первые 10 значений, последние 10 значений), процентные изменения (рост по сравнению с аналогичным периодом прошлого года), скользящие средние и нарастающие итоги выглядят не очень естественно для SQL. SQL существенно непроцедурный язык, и не может быть использован для подобных форм анализа.”

Хотя подобные типы операций часто встречаются в продвинутых OLAP-средствах, в них нет ничего исключительно многомерного, и все эти операции могут быть с равным успехом выполняться и с помощью одномерных реляционных запросов. Так как в настоящее время эти операции непосредственно в языке SQL не поддерживаются, есть три способа их реализации для многомерного-реляционного подхода: Реализовать эти функции на клиентской части.

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

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

Расширить метаданные и тем самым обеспечить непосредственную поддержку требуемых функций.

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

2.2.4 ПОЛЬЗОВАТЕЛИ ДОЛЖНЫ РАЗБИРАТЬСЯ В СОЕДИНЕНИЯХ И СЛОЖНЫХ СХЕМАХ

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

И снова здесь исходят из ложного предположения, что пользовательский интерфейс при анализе данных ограничен схемой базы данных приложения. Используемые в Discoverer/2000 метаданные Уровня Конечного Пользователя (End User Layer) устраняет эти и другие подобные проблемы путем:

• группировки соответствующих данных по хорошо понятным пользователям предметным областям, таким как Кадры, Главная книга, Сведения об отделах
• предоставления пользователю списка объектов предметной области вместо понятий базы данных таких, как таблицы, представления, синонимы,
• переименования объектов и добавления комментариев для расшифровки смысла информации
• создания автоматических соединений между объектами с целью скрыть от пользователя реляционную схему базы данных,
• определения иерархических отношений (drill relationshi ps), с помощью которых можно автоматически получать из базы данных более детализированную информацию.

В разделе 3 описывается, каким образом уровень метаданных расширяется в проекте Odysseus и как он используется для поддержки многомерной функциональности.

2.3 ПРЕИМУЩЕСТВА ПРИМЕНЕНИЯ РЕЛЯЦИОННЫХ СУБД ДЛЯ МНОГОМЕРНЫХ ОПЕРАЦИЙ

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

• совмещения хранения данных OLTP и DSS в одной базе данных
• большей свободы выбора аппаратной платформы
• использования имеющегося опыта работы с базой данных
• сопровождения и архивации только одной базы данных
• предоставления пользователям только самых свежих данных
• открытого доступа к широкому спектру программных средств
• облегчения интеграции с другими промышленно эксплуатируемыми системами OLTP
• надежности и устойчивости при работе со сверхбольшими базами данных

3. РАСШИРЕНИЕ РЕЛЯЦИОННОЙ МОДЕЛИ

3.1 УРОВЕНЬ КОНЕЧНОГО ПОЛЬЗОВАТЕЛЯ

Если реляционная модель расширена за счет использования активного уровня метаданных, мы можем сохранить все преимущества использования этой модели, обеспечив в то же время дополнительный интерфейс к данным на основе многомерных запросов и средств анализа. В этом и состоит идея Уровня Конечного Пользователя в проекте Odysseus.

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

На уровне конечного пользователя упрощаются, соединяются, согласовываются и, при необходимости, агрегируются данные, содержащиеся в “нижележащей” реляционной базе данных. Здесь же определяются такие многомерные структуры, как иерархии, которые затем можно использовать для перемещения по различным ее уровням с генерацией соответствующего SQL-запроса для выборки информации с необходимой степенью детализации. Пользователь взаимодействует с данными при помощи простого навигатора в стиле Windows’95 для отбора информации и многомерного куба для выполнения операций вращения, среза, а также перемещения по уровням иерархии. Сведения о схеме базы данных, заложенные в уровне конечного пользователя, используются для генерации оптимального SQL-кода для реализации запроса.

3.2 УПРАВЛЕНИЕ АГРЕГИРОВАНИЕМ

Для описанного выше примера многомерной базы данных с тремя измерениями (“Сведения о персонале”), мы можем анализировать данные, выбирая любые комбинации измерений (“категория”, “месяц”, “отдел”) и получая тем самым различные варианты агрегации показателя (“количество сотрудников”). В нормализованной реляционной модели это всегда предполагает агрегирование данных, если только мы не хотим видеть все значения для всех трех измерений.

Мы можем задать следующие комбинации измерений:

• категория
• месяц
• отдел
• категория, месяц
• категория, отдел
• месяц, отдел
• категория, месяц, отдел.

В общем случае, для N измерений существует 2**(N)-1 возможных комбинаций измерений. Количество полученных в результате агрегированных строк зависит от числа допустимых комбинаций значений измерений. Ситуация усложняется еще больше, когда для одного или нескольких измерений определены многоуровневые иерархии (в нашем примере измерение “месяц” может быть укрупнено до “квартал” и даже “год”). Однако в этих случаях можно использовать так называемые методы сокращения (pruning techniques):

можно указывать, например, какие комбинации измерений и уровни бессмысленно использовать с точки зрения предметной области, или не выполнять агрегацию на всех уровнях, оставляя лишь минимальное суммирование данных нижнего уровня там, где это необходимо. Кроме того, комбинация, состоящая из одного измерения (например, “категория”) приводит к меньшему числу агрегированных строк и дают самый большой выигрыш по производительности за счет предварительного агрегирования.

Хотя такой подход приводит к дополнительным затратам памяти для хранения агрегированных данных, эти затраты можно уменьшить, позволяя АБД создавать предварительно агрегированные данные в тех случаях, когда это эффективно.

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

“Покажите общее количество сотрудников отдела 10 за
последние 3 года”

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

ВЫВОДЫ

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

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

В то же время мы можем сохранить все преимущества, присущие реляционным базам данных: гибкость, надежность при работе с большими базами данных, открытость, простота доступа к серверу, низкую стоимость сопровождения, удобное администрирование и защищенность данных.

ПЕРЕВОД ДОКЛАДА, ПРОЧИТАННОГО НА КОНФЕРЕНЦИИ EOUG97
ПЕРЕВОДЧИК — МИХАИЛ ГОРЕЛИК

ОТ РЕДАКЦИИ OM/RE:
Хранилища данных, OLAP — эти термины сейчас на слуху. Подтверждением возрастающего интереса к этим технологиям может служить тот факт, что на прошлогодней конференции РАПО по этой тематике было только одно выступление, а в этом году для этого направления была выделена специальная секция. Не обошла вниманием это направление и российская компьютерная пресса, можно выделить публикации в журналах СУБД (www.osp.ru) и OM/RE (www.oracle.ru).

Активную позицию в этой области занимает корпорация Oracle, предлагая для реализации OLAP линию продуктов Oracle Express, которая включает сервер многомерной базы данных и средства разработки приложений. С учетом появившейся недавно компоненты Relation Access Manager (RAM) эта линия может поддерживать не только MOLAP, но и ROLAP технологию.

В предлагаемой Вашему вниманию публикации описан продукт Oracle Discoverer 3.0. Тестовый центр еженедельника PC Week провел испытания этого продукта и признал его лучшим в своей категории (Discoverer опередил Business Objects компании Business Objects S.A. и Brio Query компании Brio Technology). Отчет об этом испытании вы можете прочитать в еженедельнике PC Week/RE, №24/1997 (см. “Discoverer готов к мощному старту”, стр. 15).