RAM - cвязка между OLAP и реляционным хранилищем данных

Ричард Поуп, Oracle Magazine/RE #2/1998

Разработанный корпорацией Oracle продукт Relational Access Manager представляет собой мощное средство для связи использующего OLAP инструментария Oracle Express с хранилищами данных. В данной статье описывается, как лучше структурировать приложения OLAP и хранилища данных, чтобы достичь оптимальных результатов. Мы предлагаем вниманию читателей информацию, используя которую проектировщики и разработчики могут научиться быстро создавать аналитический доступ к своим хранилищам данных, избегая при этом типичных ловушек и обеспечивая своих пользователей высокопроизводительными инструментальными средствами аналитической обработки.

Продукт корпорации Oracle Relational Access Manager (RAM) относится к уровню интерфейса приложения, расположенному между базой данных Oracle Express и реляционными таблицами хранилища данных. Для применения RAM необходимо иметь хранилище данных со схемой типа «звезда» или «снежинка», содержащее одну или несколько таблиц фактов (fact tables) и одну или более таблиц для просмотра (lookup tables) для каждого из ключей, которые вы планируете отобразить в модель данных Express. Поскольку RAM — это новый продукт Oracle, в нем задействованы методы, а также команды и функции Express, которые на протяжении нескольких лет использовались разработчиками Express для связи приложений Express с реляционными базами данных. Целью создания RAM было снижение трудоемкости при реализации связи приложения с реляционной базой данных. Наш опыт доказывает, что RAM прекрасно справляется со своей задачей, но для его успешного применения следует разобраться, какие требования к производительности системы и аналитическим возможностям предъявляются пользователями системы. Кроме того, мы пришли к выводу, что для достижения наилучших результатов может потребоваться внести изменения в структуру таблиц фактов и/или таблиц для просмотра. Можно назвать три основных компонента продукта Relation Access Manager:

• Relational administrator (реляционный администратор) - это клиентское инструментальное средство, используемое для планирования схемы базы данных Express и отображения структуры хранилища данных на базу данных Express.
  
• Build module (модуль-построитель) — этот модуль, используя полученную на предыдущем этапе информацию и информацию из хранилища данных, строит или обновляет базу данных Express. Обычно выполняется как фоновый процесс.
  
• Run time module (исполняемый модуль) — этот модуль осуществляет выборку данных из реляционной базы данных в БД Express во время обработки запроса. Он выполняется в тех случаях, когда для ответа на пользовательский запрос кроме информации, содержащейся в базе данных Express, необходима информация из реляционной базы данных.
  

Реализация приложения RAM/RAA включает следующие основные шаги:

1. Постройте ваше хранилище данных.
   
2. Спроектируйте модель данных Express.
   
3. Определите и постройте приложение RAM/RAA.
   
4. Проверьте приложение по критериям производительности, точности и удовлетворения требованиям пользователей.
   

Проектирование данных Express

Для применения RAM необходимо иметь хранилище данных со схемой типа «звезда» или «снежинка». В обеих схемах в одной или нескольких таблицах фактов содержатся текущие значения данных и ассоциированные с ними значения ключей, которые однозначно идентифицируют строки с данными. Кроме того, в одной или нескольких таблицах просмотра (lookup tables) содержится дополнительная информация о размерностях — например, происхождение (parentage), описания и другие атрибуты. Часто удачным началом для проектирования схемы базы данных Express оказывается отображение столбцов, содержащих ключи (keys columns) в таблицах фактов, на измерения и столбцы с данными в кубах данных Express. Однако следует понимать, что такой вариант подходит не всегда. Нередко при проектировании базы данных Express приходится отказываться от включения в схему некоторых размерностей, которые присутствуют в хранилище данных, так как оказывается, что сообщество пользователей не заинтересовано в данных этого уровня детализации. Точно так же может понадобиться добавить новые размерности (или структуры свертки-развертки информации — roll-up structures), которых сейчас нет в хранилище данных, но они необходимы для поддержки анализа, производимого конечными пользователями. Поэтому для удачной реализации RAM необходимо провести исследование аналитических потребностей пользователей и соответствующим образом спроектировать базы данных, а затем получить у пользователей подтверждение приемлемости результата ваших действий. Схема базы данных Express является пользовательским представлением информации, содержащейся в хранилище данных. Для проектирования модели данных Express необходим аналитик, который хорошо знаком как со структурой реляционной БД вашей организации, так и с потребностями конечных пользователей в аналитической обработке. Основными объектами, которые необходимо определить на этапе проектирования базы данных Express, являются размерности, иерархии и кубы данных. Как уже упоминалось выше, размерности обычно связываются с содержащимися в таблицах фактов ключами, в то время как кубы данных — это, как правило, столбцы данных из таблиц фактов. Иерархии — это структуры свертки-развертки информации для некоторых или даже для всех размерностей. Иерархические структуры можно найти в таблицах просмотра. Типичный пример размерностей и кубов данных, которые можно найти в приложении для анализа продаж, приведен ниже.

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

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

Отображение на реляционные таблицы

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

Отображение этих итоговых таблиц осуществляется для каждой комбинации уровней в схеме базы данных Express, как это отражено на следующей схеме.
В этом примере для некоторых комбинаций уровней имеются постоянно хранящиеся таблицы фактов. Для других комбинаций уровней соответствующие им данные генерируются во время выполнения запроса на основании данных, содержащихся в хранимых таблицах фактов. Совершенно ясно, что такое отображение будет достаточно сложным, особенно в тех случаях, когда у задачи имеется много размерностей с большим количеством уровней для каждой. Принять верное решение о том, какие итоговые таблицы стоит занести в хранилище данных, а какие данные следует генерировать «на лету» — это, в определенном смысле слова, искусство. Помните, что RAM достаточно легко модифицируется, и всегда можно сообщить о наличии в вашей задаче дополнительных итоговых таблиц. Лучше всего придерживаться следующей стратегии: начать с минимального числа итоговых таблиц, а затем, используя опыт работы с приложением, постепенно добавлять их, чтобы сократить время выполнения долго обрабатываемых запросов. Обычно существует две различные модели создания иерархий в таблицах просмотра. В первом случае каждый уровень иерархии представляется как отдельный(-ые) столбец(-цы) в одномерной таблице(схема типа «звезда»). При использовании второго метода для каждого уровня иерархии создается собственная просмотровая таблица (схема типа «снежинка»). RAM одинаково хорошо работает со схемами, которые были созданы любым из этих методов. Тем не менее не следует забывать, что уровень, представляющий сумму всех допустимых значений, может быть либо представлен в хранилище, либо нет. В последнем случае, если этот уровень не представлен в хранилище, его следует добавить. Отметим также, что одним из требований системы Express является уникальность значений измерений (или ID) для каждого измерения, даже в тех случаях, когда эти значения встречаются на разных уровнях иерархии.

Заполняя пропуски

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

share=100 * sales/industry_volume

Эти дополнительные кубы данных Express можно добавить к БД после завершения процесса построения базы. RAM поддерживает гибридный способ действий. Это означает, что после завершения процесса построения можно настроить приложение так, чтобы оно записывало данные на постоянное хранение в кэш системы Express. Например, если какой-то запрос выполняется слишком медленно, можно организовать такой режим работы, при котором приложение Express будет каждую ночь записывать результаты выполнения этого запроса непосредственно в кэш Express. Ранее разработчики были вынуждены выбирать между строго реляционным или многомерным подходами к анализу данных. Использование RAM позволяет полностью задействовать все возможности хранения данных в реляционных базах и в то же время обеспечивает доступ ко всем инструментальным средствам аналитической обработки и моделирования, доступным в Express. Следуя приведенным в статье приемам проектирования,легко добиться успеха на пути полного использования всех преимуществ и возможностей продукта Relational Access Manager.