Доступ к данным и обработка запросов

Oracle BI Server в части обработки запросов запросов выполняет две основные функции: компиляцию входящих запросов (от пользователей) в исполняемый код и непосредственно исполнение этого кода. Разбор и компиляция запроса состоит из пяти основных стадий: синтаксического анализа, генерации логического запроса, навигации, переписывании и генерации конечного кода. При этом основной и самой важной является именно стадия переписывания или оптимизации запросов. На этой стадии сервер занимается оптимизацией с учетом специфики каждого конкретного источника. Механизм объединения данных учитывает физическое расположение данных (таблица базы данных или, например, плоский файл), особенности функциональности SQL, поддерживаемого базой данных, а также аналитической сложности запроса.

В платформе Oracle BI Suite ЕЕ обработка запросов к данным максимально переносится, насколько это возможно, на серверы источников данных. Хотя аналитический сервер этой платформы может выполнять OLAP-вычисления и анализ, лучше все-таки использовать для этого выделенный OLAP-сервер, и, аналогично, при работе со сверхбольшими наборами данных лучше использовать высокопроизводительный сервер реляционной СУБД. Поэтому, когда возможно, для обработки используются именно эти технологии, а не аналитический сервер, роль которого в этом случае заключается в принятии запросов от инструмента (клиентского приложения) и их трансляции в предложения SQL (или MDX) к базам исходных данных. Когда эти базы возвращают результаты, аналитический сервер сводит данные, если нужно, сам выполняет некоторые вычисления, форматирует эти данные и возвращает их клиентскому приложению.

Сгенерированные предложения SQL оптимизируются, чтобы была возможность пользоваться преимуществами базы данных источника. Ее сервер может получать доступ к данным в агрегированных таблицах (aggregate tables), если он «знает» о таковых. Это может означать, например, что вы можете прямо отображать измерения на более высокий уровень агрегирования, до агрегированных таблиц в базе данных, которые можно использовать как замену для механизма перезаписи в запросе (query rewrite mechanism) в базе данных Oracle. Эту особенность можно задействовать, чтобы задать аналитическому серверу использование другого представления (view) SQL для аналитического пространства (analytic workspace) Oracle, если требуется агрегирование более высокого уровня.

 

Выбор продукта

Для успешного внедрения Хранилища Данных крайне важен правильный выбор поставщика. Предлагаемое им решение должно удовлетворять следующим критериям:

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

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

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

· Гарантированность — решение должно быть проверенным в смысле получаемых бизнес-преимуществ и качества технологии; поставщик должен иметь прочные финансовые позиции, значительную долю рынка, хорошую клиентскую базу и большое число партнеров, внедряющих его технологии.

Выбирая Oracle, организация получает решение, удовлетворяющие всем этим критериям. Оно включает в себя как интегрированный набор программных продуктов, поддерживающих полный цикл построения и эксплуатации Хранилища Данных, так и комплекс связанных с этим услуг. Продукты Oracle характеризуются высокой степенью ЭШештабируемости, работают на большинстве аппаратных платформ и с любыми источниками информации. Таким образом, можно создать аналитическую систему в любой среде и адаптировать ее к возможным изменениям. Наконец, все это уже не однажды сделано: на базе технологий Oracle внедрены тысячи систем поддержки принятия решений по всему миру, в том числе на территории СНГ [9].

По данным аналитической фирмы IDC Research на начало 2001 года, компания Oracle, крупнейший производитель программного обеспечения для электронного бизнеса, лидирует на рынке инструментального ПО для хранилищ данных (на долю компании приходится 21% этого рынка объемом 5,3 миллиардов долларов).

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

Отчет IDC охватывает три сегмента рынка инструментального ПО для хранилищ данных: средства управления, средства доступа к информации и средства генерации хранилищ данных. В 1999 году совокупный доход от продаж ПО этого типа во всем мире достиг 5,3 миллиардов долларов, а к 2004 году IDC прогнозирует его рост до 17 миллиардов долларов. Из трех указанных сегментов рынка два — средства управления хранилищами данных и средства доступа к информации — выросли в 1999 году по сравнению с 1998 годом особенно заметно: на 22,4 и на 38,6% соответственно. На рынке средств управления хранилищами данных Oracle лидировала в 1999 году почти с 10%-ным отрывом от ближайшего конкурента.

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

Комплекс инструментального ПО Oracle, решающий весь спектр задач интеллектуального электронного бизнеса, основан на открытых интерфейсах, поддерживающих Эмые разные приложения Oracle и независимых производителей. С помощью таких компонентов Oracle9i Application Server, как Oracle Discoverer и OracleReports, бизнес-аналитики выполняют сложные запросы и анализируют данные — и реляционные, и многомерные, публикуя затем отчеты в интра- и экстрасетях. В целом весь комплекс интеллектуальных бизнес-инструментов Oracle сокращает расходы на разработку и внедрение хранилищ данных и служит мощным средством анализа, без которого невозможно успешное развитие любого предприятия.

 

Многомерные кубы

В данном разделе мы более подробно рассмотрим концепцию OLAP и многомерных кубов. В качестве примера реляционной базы данных, который мы будем использовать для иллюстрации принципов OLAP, воспользуемся базой данных Northwind, входящей в комплекты поставки Microsoft SQL Server или Microsoft Access и представляющей собой типичную базу данных, хранящую сведения о торговых операциях компании, занимающейся оптовыми поставками продовольствия. К таким данным относятся сведения о поставщиках, клиентах, компаниях, осуществляющих доставку, список поставляемых товаров и их категорий, данные о заказах и заказанных товарах, список сотрудников компании. Подробное описание базы данных Northwind можно найти в справочных системах Microsoft SQL Server или Microsoft Access — здесь за недостатком места мы его не приводим.

Для рассмотрения концепции OLAP воспользуемся представлением Invoices и таблицами Products и Categories из базы данных Northwind, создав запрос, в результате которого получим подробные сведения о всех заказанных товарах и выписанных счетах:

SELECT dbo.Invoices.Country, dbo.Invoices.City, dbo.Invoices.CustomerName, dbo.Invoices.Salesperson, dbo.Invoices.OrderDate,dbo.Categories.CategoryName, dbo.Invoices.ProductName, dbo.Invoices.ShipperName, dbo.Invoices.ExtendedPriceFROM dbo.Products INNER JOIN dbo.Categories ON dbo.Products.CategoryID = dbo.Categories.CategoryID INNER JOIN dbo.Invoices ON dbo.Products.ProductID = dbo.Invoices.ProductID

В Access 2000 аналогичный запрос имеет вид:

SELECT Invoices.Country, Invoices.City, Invoices.Customers.CompanyName AS CustomerName, Invoices.Salesperson, Invoices.OrderDate, Categories.CategoryName, Invoices.ProductName, Invoices.Shippers.CompanyName AS ShipperName, Invoices.ExtendedPriceFROM Categories INNER JOIN (Invoices INNER JOIN Products ON Invoices.ProductID = Products.ProductID) ON Categories.CategoryID = Products.CategoryID;

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

Для удобства сохраним этот запрос в виде представления, назвав его Invoices1. Результат обращения к этому представлению приведен на рис. 8.

Рис. 8. Результат обращения к представлению Invoices1

 

Какие агрегатные данные мы можем получить на основе этого представления? Обычно это ответы на вопросы типа:

· Какова суммарная стоимость заказов, сделанных клиентами из Франции?

· Какова суммарная стоимость заказов, сделанных клиентами из Франции и доставленных компанией Speedy Express?

· Какова суммарная стоимость заказов, сделанных клиентами из Франции в 1997 году и доставленных компанией Speedy Express?

Переведем эти вопросы в запросы на языке SQL² (табл. 1).

Таблица 1

Вопрос	SQL-запрос
Какова суммарная стоимость заказов, сделанных клиентами из Франции?	SELECT SUM (ExtendedPrice) FROM invoices1 WHERE Country=’France’
Какова суммарная стоимость заказов, сделанных клиентами из Франции и доставленных компанией Speedy Express?	SELECT SUM (ExtendedPrice) FROM invoices1 WHERE Country=’France’ AND ShipperName=’Speedy Express’
Какова суммарная стоимость заказов, сделанных клиентами из Франции в 1996 году и доставленных компанией Speedy Express?	SELECT SUM (ExtendedPrice) FROM Ord_pmt WHERE CompanyName=’Speedy Express’ AND OrderDate BETWEEN ‘December 31, 1995’ AND ‘April 1, 1996’ AND ShipperName=’Speedy Express’

 

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

Country	SUM (ExtendedPrice)
Argentina	7327.3
Austria	110788.4
Belgium	28491.65
Brazil	97407.74
Canada	46190.1
Denmark	28392.32
Finland	15296.35
France	69185.48
Germany	209373.6
…	…

Полученный набор агрегатных значений (в данном случае — сумм) может быть интерпретирован как одномерный набор данных. Этот же набор данных можно получить и в результате запроса с предложением GROUP BY следующего вида:

SELECT Country, SUM (ExtendedPrice) FROM invoices1GROUP BY Country

Теперь обратимся ко второму из приведенных выше запросов, который содержит два условия в предложении WHERE. Если выполнять этот запрос, подставляя в него все возможные значения параметров Country и ShipperName, мы получим двухмерный набор данных следующего вида (ниже показан фрагмент):

	ShipperName
Country	Federal Shipping	Speedy Express	United Package
Argentina	1 210.30	1 816.20	5 092.60
Austria	40 870.77	41 004.13	46 128.93
Belgium	11 393.30	4 717.56	17 713.99
Brazil	16 514.56	35 398.14	55 013.08
Canada	19 598.78	5 440.42	25 157.08
Denmark	18 295.30	6 573.97	7 791.74
Finland	4 889.84	5 966.21	7 954.00
France	28 737.23	21 140.18	31 480.90
Germany	53 474.88	94 847.12	81 962.58
…	…	…	…

Такой набор данных называется сводной таблицей (pivot table) или кросс-таблицей (cross table, crosstab). Создавать подобные таблицы позволяют многие электронные таблицы и настольные СУБД — от Paradox для DOS до Microsoft Excel 2000. Вот так, например, выглядит подобный запрос в Microsoft Access 2000:

TRANSFORM Sum(Invoices1.ExtendedPrice) AS SumOfExtendedPriceSELECT Invoices1.CountryFROM Invoices1GROUP BY Invoices1.CountryPIVOT Invoices1.ShipperName;

Агрегатные данные для подобной сводной таблицы можно получить и с помощью обычного запроса GROUP BY:

SELECT Country,ShipperName, SUM (ExtendedPrice) FROM invoices1 GROUP BY COUNTRY,ShipperNameОтметим, однако, что результатом этого запроса будет не сама сводная таблица, а лишь набор агрегатных данных для ее построения (ниже показан фрагмент):

Country	ShipperName	SUM (ExtendedPrice)
Argentina	Federal Shipping	845.5
Austria	Federal Shipping	35696.78
Belgium	Federal Shipping	8747.3
Brazil	Federal Shipping	13998.26
…	…	…

Третий из рассмотренных выше запросов имеет уже три параметра в условии WHERE. Варьируя их, мы получим трехмерный набор данных (рис. 9).

Рис. 9. Трехмерный набор агрегатных данных

 

Ячейки куба, показанного на рис. 6, содержат агрегатные данные, соответствующие находящимся на осях куба значениям параметров запроса в предложении WHERE.

Можно получить набор двухмерных таблиц с помощью сечения куба плоскостями, параллельными его граням (для их обозначения используют термины cross-sections и slices).

Очевидно, что данные, содержащиеся в ячейках куба, можно получить и с помощью соответствующего запроса с предложением GROUP BY. Кроме того, некоторые электронные таблицы (в частности, Microsoft Excel 2000) также позволяют построить трехмерный набор данных и просматривать различные сечения куба, параллельные его грани, изображенной на листе рабочей книги (workbook).

Если в предложении WHERE содержится четыре или более параметров, результирующий набор значений (также называемый OLAP-кубом) может быть 4-мерным, 5-мерным и т.д.

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

Некоторые термины и понятия

Наряду с суммами в ячейках OLAP-куба могут содержаться результаты выполнения иных агрегатных функций языка SQL, таких как MIN, MAX, AVG, COUNT, а в некоторых случаях — и других (дисперсии, среднеквадратичного отклонения и т.д.). Для описания значений данных в ячейках, используется термин summary (в общем случае в одном кубе их может быть несколько), для обозначения исходных данных, на основе которых они вычисляются, — термин measure, а для обозначения параметров запросов — термин dimension (переводимый на русский язык обычно как «измерение», когда речь идет об OLAP-кубах, и как «размерность», когда речь идет о хранилищах данных). Значения, откладываемые на осях, называются членами измерений (members).

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

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

Рис. 10. Иерархия в измерении, связанном с географическим положением клиентов

 

Отметим, что иерархии могут быть сбалансированными (balanced), как, например, иерархия, представленная на рис. 10, а также иерархии, основанные на данных типа «дата—время», и несбалансированными (unbalanced). Типичный пример несбалансированной иерархии — иерархия типа «начальник—подчиненный» (ее можно построить, например, используя значения поля Salesperson исходного набора данных из рассмотренного выше примера), представлен на рис. 11.

Иногда для таких иерархий используется термин Parent-child hierarchy.

Рис. 11. Несбалансированная иерархия

 

Существуют также иерархии, занимающие промежуточное положение между сбалансированными и несбалансированными (они обозначаются термином ragged — «неровный»). Обычно они содержат такие члены, логические «родители» которых находятся не на непосредственно вышестоящем уровне (например, в географической иерархии есть уровни Country, City и State, но при этом в наборе данных имеются страны, не имеющие штатов или регионов между уровнями Country и City; рис. 12).

]

Рис. 12. «Неровная» иерархия

 

Отметим, что несбалансированные и «неровные» иерархии поддерживаются далеко не всеми OLAP-средствами. Например, в Microsoft Analysis Services 2000 поддерживаются оба типа иерархии, а в Microsoft OLAP Services 7.0 — только сбалансированные. Различным в разных OLAP-средствах может быть и число уровней иерархии, и максимально допустимое число членов одного уровня, и максимально возможное число самих измерений.

 

Заключение:

В данном разделе мы ознакомились с основами OLAP. Мы узнали следующее:

· Назначение хранилищ данных — предоставление пользователям информации для статистического анализа и принятия управленческих решений.

· Хранилища данных должны обеспечивать высокую скорость получения данных, возможность получения и сравнения так называемых срезов данных, а также непротиворечивость, полноту и достоверность данных.

· OLAP (On-Line Analytical Processing) является ключевым компонентом построения и применения хранилищ данных. Эта технология основана на построении многомерных наборов данных — OLAP-кубов, оси которого содержат параметры, а ячейки — зависящие от них агрегатные данные.

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

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

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