Вы находитесь на страницах старой версии сайта. Перейдите на новую версию OLAP.ru
|
Вы находитесь на страницах старой версии сайта. Перейдите на новую версию OLAP.ru |
 | ||||||
| Поиск по сайту | ||||||
| ||||||
| Новости | ||||||
| ||||||
| Основы OLAP | ||||||
| ||||||
| Продукты | ||||||
| ||||||
| Business Objects/ Crystal Decisions | ||||||
| ||||||
| Каталог | ||||||
| ||||||
| OLAP в жизни | ||||||
| ||||||
| Тенденции | ||||||
| ||||||
| Download | ||||||
| ||||||
| ||||||
 | ||||||
Попробуйте OLAP!Бернард Люпен, Oracle Magazine/RE, #9/2000 Источник:http://perso.wanadoo.fr/bernard.lupin/english Много лет реляционные базы данных главенствовали в сфере управления данными. Но в последнее время была разработана новая концепция в мире баз данных. Возможно, Вы уже слышали о многомерных базах данных и OLAP-инструментарии. Возможно, Вы даже понимаете значение этого термина, который так легко катится с языка, на каком бы языке Вы не говорили (или во всяком случае более легко, чем слова RDBMS или SGBDR - французский эквивалент RDBMS). Но, к сожалению, когда люди говорят с Вами об On Line Analytical Processing (оперативный анализ данных), Вы, даже если понимаете английский язык, вероятно, имеете не более чем смутное представление о возможностях баз данных OLAP. Ниже, при помощи простого (в 8 этапов) примера я намерен шаг за шагом построить маленькую базу данных OLAP. Меньше чем за 5 минут, измерения (dimensions), меры (measures), другие аггрегации (aggregations) не будут больше составлять для Вас никакой тайны. Конечно, в теории все это очень интересно, но как насчет практики? Я намерен построить базу данных OLAP для этого примера, используя Oracle Express. Если Вы знакомы с реляционными базами данных и языком SQL, то без труда заметите, что это абсолютно разные вещи! А если Вы уже знакомы с другими многомерными продуктами, то сможете и сравнить их между собой. Если Вам понравится этот пример, то прочитайте и другие подготовленные для Вас страницы:
Наконец, Вы можете послать мне свои предложения, критические или ободряющие замечания, использовав для этого мойemail-адрес или специальную форму. От редактора Russian Oracle Internet Magazine:
О Г Л А В Л Е Н И Е
От переводчика Известно, что разработчики приложений для традиционных СУБД, к числу которых ныне относится Oracle, несколько побаиваются многомерных систем, или, иначе – “OLAP-систем”. Уж больно там все необычно и непривычно. Учебников мало, а документация – не всегда хороший учебник. А ведь, несмотря на теоретическую неразличимость реляционной и многомерной модели, благодаря своему особому методу хранения и методу доступа многомерные системы весьма многообещающи. Они могут послужить хорошим дополнением к использованию традиционных СУБД в приложении, а иногда и играть самодостаточную роль. Но получается, что их возможности на практике востребованы явно недостаточно. Помочь исправить такое положение дел, хотя бы частично, способно хорошее доступное введение в тематику многомерных баз. Представляется, что Бернар Люпэн, консультант из Франции, сделал весьма полезное дело, разместив и Internet именно такое введение, вполне подходящее для начала пути “от простого – к сложному”. При этом важной особенностью текста Люпэна является то, что он разбит на две части: большую часть, в которой речь идет об основах построения многомерных баз, и меньшую, в которой решения, подготовленные в первой части, ложатся на практику применения конкретной системы – Oracle Express. Весьма педагогично, Люпэн, как бы, “подпускает к инструменту” в самый последний момент. Такое распределение материала очень важно – потому, что главную трудность обычно вызывает именно методология построения многомерной базы, – но, к сожалению, оно нетрадиционно. Автор любезно согласился на безвозмездное размещение русского перевода своего текста в Internet, за что ему следует выразить благодарность. Если вы соберетесь написать ему о своих впечатлениях, он будет только рад, но учтите, что нашего языка он не знает. И вот еще о чем нельзя не сказать: полупустая книжная полка разработчика многомерных баз на основе Oracle Express, все же, не абсолютно пуста. Те, кто с помощью Люпэна успешно сделал свои первые шаги в OLAP, могут обратиться для дальнейшего изучения этих систем к книге Сергея Архипенкова "Аналитические системы на базе Oracle Express OLAP" (рецензия по адресу http://www.oracle.ru/press/press2.htm), вышедшей на русском языке некоторое время назад. Поищите эту книгу в электронных или традиционных книжных магазинах ! Владимир Пржиялковский Знакомимся с OLAP: шаг за шагомШаг 1: Свойства таблицы SalesВ рамках этого шага мы намереваемся поэтапно построить классическую базу данных, то есть базу данных с таблицами и столбцами. Мы увидим с вами, что несмотря на очевидный интерес разработчиков к реляционным базам данных, этот подход не всегда оказывается наилучшим возможным. Компания "Best Foot Forward" хочет построить свою базу данных, с помощью которой она могла бы отслеживать продажи обуви по категориям и месяцам. Хорошая затея ! Представим себе следующую таблицу продаж Sales:
Здесь разные типы обуви собраны в таблице Style, и все, что нам нужно -- это включить соответствующее поле для внешнего ключа в таблицу Sales. Для анализа данных мы могли бы, например, соотнести месяцы строкам, а типы столбцам и сформировать таким образом две таблицы: количества продаж Quantity и общей стоимости без учета налогов Total Value Tax Exclusive. Эти таблицы позволят нам проводить моделирование и строить графики так, как мы пожелаем. Итак, у нас два простых отчета: один, показывающий число пар обуви, проданных за месяц, и второй -- общая стоимость. Продажи пошли как по-маслу (а до этого, все же, были больше !), компания выросла и со временем открыла несколько магазинов. Таблицу продаж придется переработать так:
В нашей реляционной базе данных теперь появилась таблица outlet магазинов с такими полями, как название, поле ключа и прочими характеристиками наподобие адреса. Теперь для анализа стало уже не хватать двумерного листка бумаги (или электронной таблицы). Если мы хотим посмотреть данные о работе магазина, нам нужно сначала их извлечь. А если нам нужно по очереди посмотреть работу всех магазинов в феврале, нам придется по очереди и извлекать данные. Теперь мы имеем уже шесть разных возможных отчетов :
Если мы захотим в отчетах поменять строки со столбцами, то их окажется уже не шесть, а двенадцать. Еще мы пришли к заключению, что нужно анализировать продажи и по другим критериям, таким как "род" Gender (мужская, женская, детская обувь), "размер" Size, а может быть и "цвет" Colour. При таком повороте событий возникает проблема обеспечения каждого табочего места, с которого будут анализироваться продажи, монитором с разрешением 1280 X 1024, чтобы можно было все эти продажи разглядеть. Таблица продаж стала очень большой, как по числу строк, так и столбцов. При анализе данных будут возникать промежуточные суммы по группам обуви, что может сказаться на времени реакции системы. Нам придется заняться индексированием и прочими уловками повышения производительности. |
|
Как мы уже знаем, компания "Best Foot Forward" намеревается достичь прогресса в показателях своих продаж, скажем, по месяцам, роду обуви и по магазинам. В терминологии OLAP эти критерии анализа носят название измерений, или иногда -- осей.
В нашем примере можно говорить об измерении Магазин. Оно может содержать несколько значений, наподобие "Paris Bastille". Эти значения являются положениями на шкале измерения Магазин.
В реляционной модели измерения соответствуют лучам схемы "звезда", которую мы видели на Шаге 1. Есть, однако, одно небольшое исключение: практика заведения таблицы с месяцами в реляционной модели отсутствует, потому что названия месяцев и их порядок присутствует в системе неявно. Здесь же нам абсолютно необходимо иметь явное измерение для месяцев, так чтобы положения на шкале этого измерения именовались как-нибудь наподобие "января 2000".
В общем случае одно измерение может содержать от двух до нескольких тысяч существующих в нем положений.
В нашем случае объектом внимания руководства фирмы служат два индикатора: количества проданной обуви и стоимость без учета налогов. Эти индикаторы носят названиемер, или, иногда, переменных.
Теперь мы можем сказать, что мера Количество имеет измерения Месяц, Род и Магазин.
Каждая мера может характеризоваться значениями числом от одного до нескольких миллионов. Все значения меры имеют одинаковый тип, например, целое или десятичное.
Куда нас занесло ! Теперь не остается никаких сомнений в том, что наша база данных стала по-настоящему многомерной. К нашему счастью мера "Количество" определяется только тремя измерениями. Это действительно счастье, хотя при отображении на двумерный экран нам придется рисовать куб. 850 пар ботинок с предыдущей страницы будут при этом выглядеть примерно так:
Каждая ячейка куба представляет собой значение. Измерения обозначены вдоль ребер куба. Каждая грань соответствует набору значений, соответствующему положению на одной из трех щкал измерений. К примеру, передняя грань относится к магазину Paris Bastille. И, наконец, куб целиком представляет собой всю меру, в данном случае количество проданных пар.
Если мы добавим общую стоимость без учета налогов Total Value TE, то получим уже другой объект, состоящий из четырех шкал измерений: Месяц, Род, Магазин и Индикатор, позиции на которых задают существующие значения мер. Этот новый объект называется гиперкуб.
Возможность помесячного изучения продаж, конечно, полезна, но, в тоже время, имеет свои ограничения. По этой причине мы переименуем измерение Месяц и назовем его, к примеру, Time. Положениями на шкале измерений Time могут быть, помимо месяцев, дни, периоды и годы. Таким образом, управляющий персонал сможет анализировать результаты работы разных магазинов как по более общим, так и более детальным отрезкам времени.
Чтобы нам самим было легче ориентироваться во всех этих позициях на шкале измерений, требуется создать иерархию. В нашем случае иерархия образована четырьмя уровнями, соответственно дню, месяцу, кварталу и году. Теперь мы имеем возможность вполне естественно соединить 18 мая 2000 года с маем 2000 года, и далее со вторым кварталом 2000 года и с самим 2000 годом. Для описания данных иерархии годятся выражения типа "прямой" или "дальний потомок", "родитель", "брат/сестра".
Точно таким же образом можно завести иерархию для шкалы измерений Магазин. К примеру, мы бы могли захотеть группировать магазины по району, области, стране. Обычно для одного измерения можно организовывать даже сразу несколько иерархий. Так, вторая иерархия для измерения времени могла бы иметь три уровня: день, неделя и год. В этом случае 18 мая 2000 года будет соединено с 19-й неделей 2000 года и с самим 2000 годом.
Единственным ограничением для создания иерархии служит то, что образована она должна быть каскадом отношений "один ко многим". То есть в любой иерархии каждая позиция на шкале должна иметь ровно одного родителя.
Предположим для примера, что мы захотели создать иерархию для магазинов, чтобы показывать с ее помощью, какие категории обуви (спортивная, прогулочная, детская) как продаются. Для этого нам потребуется ввести специализацию магазинов ! По этой причине лучшим решением будет расположить новую иерархию на шкале измерения стиля Style, так как стиль пары обуви принадлежит ровно одной категории.
Новая реляционная модель будет выглядеть так:
|
|
Теперь измерения количества Quantity и стоимости Total Value Tax Exclusive охарактеризованы измерениями Time, Style и Outlet. Каждый магазин предоставляет данные за день, а база OLAP отслеживает консолидацию данных в соответствии с разными иерархиями. Пока вся консолидация заключается в вычислении сумм, встроенные в систему функции обеспечивают этот процесс просто и незаметно для глаз.
Результаты осуществления такого агрегирования в соответствии с иерархиями хранятся в базе данных на более высоких уровнях иерархии.
Итак, наша база данных типа OLAP состоит сейчас из двух "кубов" данных (или же "мер", "замеров", "показателей"), именно данных о числе проданных пар обуви и их стоимости без учета налогов. Обе наши меры имеют в качестве шкал измерений время, род и магазин: Time, Style и Outlet.
Из этих двух показателей мы может получить и другие, но не путем хранения их в базе, а путем выполнения автоматического пересчета всякий раз, когда пользователям эти данные понадобятся. Такие показатели иногда называютформулами, имея в виду задающий их вычисления текст.
Для пользователя разницы между хранимым показателем и формулой нет. И те, и другие определяются шкалами измерений и типом. Так, формула Average Price, вычисляющая среднюю цену пары ботинок, имеет шкалы измерений Time, Style и Outlet и имеет десятичный тип. Это самая простая формула, и записывается она так:
Average Price = Total Value Tax Exclusive / Quantity,
то есть Средняя цена = Общая стоимость без учета налогов / Количество.
Всякий раз, когда пользователь запрашивает это значение, СУБД производит необходимое деление и выдает нужные данные.
Для формулы вовсе не обязательно, чтобы все ее элементы измерялись одинаково. Мы бы могли, например, определить новую формулу так:
Total Value tax Inclusive = Total Value Tax Exclusive x 1.206.
Здесь каждая ячейка индивидуально помножается на 1.206.
Так как налог на добавленную стоимость (VAT) изменяется (чрезмерно) часто, можно задать новую переменную VAT, шкалой измерения которой будет только время. Эта переменная будет указывать на рост налога VAT в любой точке шкалы времени Time. Тем самым мы, весьма интуитивно, получим:
Total Value Tax Inclusive = Total Value Tax Exclusive x (100+VAT)/100
Таким образом получится, что для каждой ячейки, к которой применилась эта формула, будет правильно вычислена общая сумма.
Далее, если налог VAT изменяется по-разному для разных товаров, то шкалами измерения для этой переменной должны стать Time и Product. Графически значения переменной в этом случае образуют не линию, а плоскость.
Хорошо, конечно, знать о том, сколько ботинок продано, но для процветания нашего объединения "Best Foot Forward" неплохо было бы знать к тому же, сколько именно ботинок какого сорта. Для этого каждый склад должен будет сообщать более детальную информацию и указывать, вдобавок, число проданных за день пар конкретной модели.
По это причине мы заменим шкалу Style шкалой Reference, артикул. Теперь мы знаем, что магазин "Paris Bastille" продал 18 августа 1998 года 7 пар ботинок артикула 215431324. Это весьма ценно для повышения качества управления заказами: нехватка или избыток товара на складе могут уйти в прошлое !
С другой стороны стало труднее понять состояние рынка. Невзирая на это, мы должны прямо сейчас определить атрибуты для каждого артикула ботинок. Значениями атрибутов могут стать Color (цвет: голубой, белый, красный), Substance (материал: кожа, ткань, синтетика), или Type (тип: мужская, женская, детская обувь). Если для каждого размера артикулы разные, то атрибутом следует также сделать и размер Size; иначе же Size станет новой шкалой измерения.
Теперь, когда мы предложили новое понятие артикула, администратору остается только занести его характеристики в систему. В OLAP-системе Color, Substance и Type составят новые шкалы измерений. А для определения атрибутов для каждого артикула состема строит отношения.
Имея эти отношения, мы можем построить новые формулы, шкалами размерности которым послужат какие-нибудь из этих атрибутов, а не шкала "артикул". Когда пользователь запросит данные, система запросит значения по артикулу и построит суммы по атрибутам.
Как вы, возможно, уже догадались, наша база данных OLAP теперь в состоянии отвечать на вопросы типа :
Теперь компания Best Foot Forward хочет прогнозировать свои действия на будущее. Предыдущие примеры в этом не помогут: нам нужно анализировать изменения в поступающих в базу данных и, по возможности, уметь готовиться к грядущим изменениям.
По части обработки запросов, связанных с временной шкалой, базы данных типа OLAP -- весьма мощный инструмент. Например, они дают возможность узнать, какой неделе года соответствует день 12 июня 2000 года; сколько дней имеется между 9 маем 1998 года и 15 июнем 2002 года; существует ли день 29 февраля 2000 года и так далее.
В некоторых системах для шкалы времени используются стандартные типы данных. Характеристикий для таких шкал служит понятие периодичности (день, неделя, семестр, ...), и существуют функции преобразования из одного типа периодичности в другой. OLAP-система хранит в себе все подобное описание календаря, так что разработчику нет нужды заботиться о сложных алгоритмах построения и поддержки иерархических структур описания времени.
Таким образом, для вопросов, приводимых ниже, нам достаточно простых и небольших программ :
В реляционных базах такие запросы потребуют очень ресурсоемких формулировок, так что ответа от системы пользователь рискует не получить никогда ...
И наконец, случилось ! Благодаря четкому управлению, фирма Best Foot Forward чувствует себя прекрасно, а предлагаемый ею выбор обуви безупречен. В продаже наименования более 12000 артикулов, и по всей стране открыто более 500 магазинов. Из каждого ежедневно в главную контору поступают цифры продаж. То есть, к концу года всего появляется 12000*500*365 ячеек с переменной типа 'Number', то есть более 2 мллиардов.
Но ведь не каждый магазин предлагает клиентам всю номенклатуру по каталогу. В среднем каждый магазин предлагает примерно 600 наименований, и при этом открыт для покупателей 250 дней в году. То есть реально будет заполнено только 600*500*250 ячеек, или 75 миллионов -- в 25 раз меньше максимального числа.
Это означает, что данные не распределены равномерно по нашей базе OLAP. Так, магазин 'Paris Bastille' никогда не продает ботинки с артикулом "23154". Значит для каждого дня в году показатель 'Number' для этого магазина будет пуст.
Из этого следует, что не все шкалы измерений имеют одинаковую важность для показателя . Для того, чтобы улучшить использование дискового пространства и доступ к данным, будет правильно сообщить OLAP-системе подобные свойства переменных.
В Oracle Express для этого требуется всего лишь указать, является ли шкала измерения плотной или разреженной. В нашем примере шкала времени плотна, а шкалы артикулов и магазинов разрежены Далее система сама автоматически соптимзирует управление данными. Так, в Oracle Express создается составная шкала измерения, в которой будут присутствовать все важнейшие пары "артикул -- магазин". Поддерживать эту специальную шкалу придется вручную. Такие шкалы носят название совмещенных (conjoint).
Для OLAP-системы теперь будет иметься всего две шкалы измерения, а для пользователя и разработчика эти детали останутся не видны.
Последний в списке, но не по значимости ( Last but not least). Я советую Вам реализовать на практике некоторые идеи, которые мы рассмотрели в этом примере.
"Таблица Pivot " в Microsoft Excel имеет некоторое сходство с OLAP-инструментарием.
Для того, чтобы убедить Вас в этом (если Вы не еще знакомы с этой функцией), пробуете создать маленькую таблицу с 5 колонками (время (time), стиль (style), магазин (shop), значение (value ), количество (quantity), как в нашем примере). Загрузите какие-нибудь данные в таблицу Pivot и запустите (launch) ее. Разместите измерения, как Вы пожелаете в строке (Row), столбце (Column) и на странице (Page) и поместите меры (Measures) в область данных. Тем самым, мы имеем инструмент, который позволит нам визуализировать в двух измерениях любую грань куба в нашем примере.
Если Вы не хотите ждать, пока получится результат, разгрузите себе этот файл: example.xls.
Тот поступит правильно, кто останется с нами и далее, а я рассчитываю на Вашу конструктивную критику.
До настоящего момента пример базы данных для "Best Foot Forward" из предыдущей части существовал лишь на бумаге. Теперь пора сделать его более "живым", воспользовавшись продуктами фирмы Oracle. Oracle Express я выбрал не случайно: я давно работаю с этой системой и знаю ее особенности.
Весьма быстро базу данных OLAP можно построить, пользуясь средой Oracle Express Administrator. На первом этапе создания базы данных для "Best Foot Forward" мы так и поступим.
Подсоединимся к Oracle Express (возможно, с другой машины), и в первом же окошке обнаружим возможность создать базу данных. Введем имя и описание и получим следующее:
Это окошко не вызывает у нас никаких затруднений, поскольку все важнейшие понятия -- шкала измерения, переменная-показатель, формула и отношение -- нам уже известны. Если что-то забыли, смело обращайтесь к словарю.
Нажатием правой кнопки на надписи "Dimension" мы попадем в диалоговое окошко, откуда можем создавать все шкалы базы данных:
Закладка "General" дает возможность определить тип каждой шкалы (идентификатор, число, текст, ...). Закладка "Labels" дает возможность определить для каждой шкалы длинную и короткую метки -- их будет видеть конечный пользователь. Прочие возможности этого окна позволяют задать вручную или оптимизировать совмещенные шкалы.
Нажав правой кнопкой на позицию "Variable", мы сможем завести переменные Quantity, TotalVTE и VAT. Для каждой из них укажем вид шкалы -- плотный или разреженный.
В этом примере для переменной TotalVTE будет указана плотная шкала Time, и разреженные шкалы Outlet и Reference (Магазин и Артикул).
Наконец, как и следовало ожидать, нажав правой кнопкой на "Formula", можно создавать формулы. Определи формулуTotalVTI следующим образом:
Сама формула (в нашем случае TotalVTE * TVA) записывается на специальном языке. За некоторыми примерами рекомендую обратиться к шагу 4.
Теперь структура базы данных построена. Общий вид базы данных представлен в главном окошке.
Теперь эту структуру нужно наполнить данными. Перейдем к следующему шагу !
У нас имеется два вида данных:
Для того, чтобы в Express Administrator заполнить шкалу измерений позициями, нам, как обычно, нужно нажать правой кнопкой на метку измерения и выбрать "Edit Values". В открывшемся окошке можно занести в систему все позиции, и, кроме того, задать иерархии для этой шкалы. В нашем примере это будут две шкалы для шкалы Time.
Далее нам нужно организовать ежедневную автоматическую загрузку плоских файлов. Для этого нам придется написать программу и сохранить эту программу в базе данных. Составить программу нам поможет помощник из среды Administrator. Действуя через него, нам понадобится описать формат плоского файла примерно в таком окошке :
Здесь сказано, что каждая строка файла содержит 5 полей. В зависимости от шкал перечисление полей завершается значением переменной Quantity или TotalVTE.
Теперь перейдем к средству построения соответствующей программы на 4GL. Начнем со следующего окошка :
Теперь ежедневные данные попадают в базу данных. Нам осталось сагрегировать эти данные вдоль шкалы времени. Свертку поможет построить специальный помощник в среде Administrator. Все, что от нас требуется -- указать, какие переменные агрегировать, иерархии и позиции на шкале, которые будут участвовать в свертке.
Использование этого помощника настолько просто, что нам неинтересно на нем останавливаться. Увы, но программы, которые он строит, очень длинные и сложные ввиду использования большого числа параметров. В рамках шага 4 я приведу очень простые примеры использования языка Oracle Express.
Теперь наше приложение стало самодостаточным : каждый день выполняется загрузка данных, сразу вслед за которой пересчитываются агрегаты. Конечные пользователи получили возможность подсоединяться к базе и анализировать свои данные. Как реализовать эту возможность, станет темой для нашего следующего шага.
Для анализа данных из нашей базы для "Best Foot Forward" существует много продуктов :
Для того, чтобы просматривать данные из Express с помощью Analyzer, нам требуется только указать нужные меры. Analyzer построит таблицу или график значений переменных и связанных с ними шкал. Выбранные меры -- это положения на специальной шкале под названием "Measure".
Для выбора нужных положений на каждой шкале используется средство Oracle, называемое Selector. С помощью этого средства можно делать достаточно сложный выбор: например, все месяцы в году; все артикулы обуви, проданной в сентябре в количестве не менее 10 пар; 5 наилучших магазинов. С помощью этого средства выборы можно сохранять и восстанавливать. Первое диалоговое окно средства для выбора Selector показано ниже.
Выбрав меры и отобрав позиции на шкале, можно посмотреть таблицу или график. Вот два примера для базы данных "Best Foot Forward" :
Когда на экран выводится рисунок, мы можем мышкой подтаскивать ту или иную шкалу в область строки, столбца или страницы (верхний левый угол). Мы можем перемещаться вверх или вниз по иерархии, нажимая на значок + или -, агрегировать шкалы и так далее. Все это выполняется быстро и прото, так что пользователь может выбирать форму анализа сам.
Я надеюсь, что приведенные примеры, весьма конкретного характера, помогли вам понять возможности баз данных OLAP.
Теперь те, кто поотважнее, могут перейти к следующему шагу, где приводятся некоторые примеры 4GL-языка Oracle Express и даются к этим примерам комментарии.
В Oracle Express имеется специальный язык, с помощью которого в базе можно делать все, что угодно. Это язык типа 4GL, и позволяет он:
Этот язык 4GL используют при взаимодействии с базой данных такие продукты, как Express Administrator или же Express Analyzer. На этом языке можно писать пакетные задания, для того, чтобы запускать их в ночное время, и так далее.
Я предлагаю вашему вниманию несколько примеров работы с базой данных Best Foot Forward. Примеры снабжены комментариями. Пожалуйста, обратите внимание на простоту примеров. Моею целью было продемонстрировать всего лишь некоторые особенности языка. Тем не менее, примеры нормально компилируются и исполняются в Oracle Express.
1. Создание базы данных для Best Foot Forward
Этот первый мой пример иллюстрирует возможность создания упрощенной версии базы данных Best Foot Forward. В ней имеются некоторые шкалы, переменные и формулы, но нет иерархии для шкалы времени Time
" Создаем базу данных
DATABASE CREATE 'BESTFOOTFORWARD.DB'
" Создаем размерности
" Указываем имена и типы данных
DEFINE CATEGORY DIMENSION ID
DEFINE COLOR DIMENSION ID
DEFINE OUTLET DIMENSION TEXT WIDTH 32
DEFINE SIZE DIMENSION ID
DEFINE REFERENCE DIMENSION INTEGER
DEFINE TIME DIMENSION ID
" Создаем переменные
" Указываем имена, типы данных и ассоциированные размерности
" Указываем плотные и разреженные размерности
DEFINE QUANTITY VARIABLE DECIMAL " Создаем формулы
" Указываем имена, типы данных и ассоциированные размерности
" Пишем текст формулы
DEFINE TOTALVTI FORMULA DECIMAL
2. Загрузка данных из файла
Эта программа загрузит данные из файла "exemple.txt", о котором шла речь в шаге 8 раздела "Знакомимся с OLAP: шаг за шагом". Этот сценарий создаст новый объект -- программу. Ее можно запустить на выполнение командой "call <имя программы>".
DEFINE LOAD_EXAMPLE PROGRAM
PROGRAM
variable _funit integer
variable _i integer
" Открываем файл данных
_funit = fileopen('exemple.txt' read)
" Первая строка - дескриптор, отбрасываем ее
fileread _funit stopafter 1
if not filenext(_funit)
" Ничего не делаем, если строка только одна
then goto DONE
" Для каждой строки файла
_i=0
while true
do
" Грузим данные в размерности и переменные
" Для файла известного типа, указываем размер и позицию каждого столбца
fileview _funit ruled -
_i = _i + 1 -
COL 1 WIDTH 4 STRIP APPEND REFERENCE -
COL 9 WIDTH 8 STRIP APPEND TIME -
COL 25 WIDTH 10 STRIP APPEND OUTLET -
COL 41 WIDTH 5 STRIP QUANTITY -
COL 49 WIDTH 6 STRIP TOTALVTE
" Здесь добавим немного специального кода для каждой строки файла
" Следующая запись
if not filenext(_funit)
then goto DONE
doend
DONE:
" Закрываем файл
fileclose _funit
update
" Выводим время дня и число записей
show joinchars (tod ' - ' _i ' records created')
END
3. Загрузка данных из реляционной базы
На этом примере показано, как можно загрузить номенклатуру артикулов из реляционной таблицы под названием "model". Многомерная база может обращаться к реляционной и динамически, в процессе работы приложения.
DEFINE LOAD_MODEL PROGRAM
PROGRAM
variable _i integer
" подключаемся к Oracle8i
sql.dbms='oracle'
sqlmessages=yes
sql connect 'admin' identified by 'pass'
if sqlcode ne 0
then signal err_connect joinchars('Connection problem ' sqlerrm)
" Объявляем курсор
sql declare C1 cursor for -
SELECT id_model, desc_model FROM model
if SQLCODE ne 0
then signal err_req1 joinchars('SQL error ' sqlerrm)
sql open C1
if SQLCODE ne 0
then signal err_req2 joinchars('SQL error ' sqlerrm)
" Для каждой строки в таблице MODEL
_i = 0
while SQLCODE eq 0
do
_i = _i + 1
sql FETCH C1 INTO APPEND modele, mod.longlabel
if sqlcode ne 0 and sqlcode ne 100
then signal err_req3 joinchars('SQL error ' sqlerrm)
doend
update
" Закрываем курсор и базу данных
sql close C1
sql disconnect
END
4. Агрегирование данных
Этот пример, последний, демонстрирует возможность выполнения свертки данных по имеющейся иерархии.
DEFINE ROLL PROGRAM
PROGRAM
arg vDay text " Параметр: дни для агрегации
" Перед rollup-ом, определяем все месяцы в году и
" все дни в месяце в размерности Time.
" Это делается командой limit для временной размерности и всех с ней связанных
limit time to vJours " Определяем дни в параметре
limit aute.hierdim to 'DMY' " Определяем иерархию Day-Month-Year
limit time to ancestors using aute.parent " Месяцы и годы дней
limit time to children using aute.parent " Дни месяцев и месяцы года
" Для других размерностей сохраняем все положения
limit outlet to all
limit reference to all
show joinchars(tod, ' - Rollup along time')
" аггрегируем
rollup quantity over time using aute.parent
rollup totalvte over time using aute.parent
END
Ну вот и все, для начала. Благодарю вас за то, что вытерпели мой английский. Хорошо, что вы оставались с нами все это время -- ведь я надеюсь на конструктивную критику от читателей. Написать мне можно либо по электронной почте, либо используя мою замечательную форму, которую я создал своими руками..
Когда появился OLAP?
Термин OLAP - On Line Analytical Processing (оперативная аналитическая обработка данных) возник в 1993. Его придумал E.F. Codd, отец реляционных баз данных ( в статье E.F. Codd, S.B. Codd (его жена) и C.T. Salley “Providing OLAP to User-Analysts: An IT Mandate”. ) С тех пор возникло множество новых акронимов: от ROLAP до MOLAP через DOLAP. Все эти термины приведены в глоссарии.
Правила OLAP
Первоначально было определено 12 правил OLAP, которые определяли эту технологию. Все OLAP-продукты должны были им следовать. Вот эти 12 правил:
В настоящее время эти 12 правил расширились до 18 главных правил, а всего их около 300!
Для чего применяется OLAP?
OLAP-технология может применяться в широком спектре областей:
Кому нужен OLAP?
Все управленцы (менеджеры) должны быть заинтересованы в применении OLAP:
OLAP технология использует значительное число точных терминов, обозначающих элементы многомерных структур. Кроме того, находясь в мире OLAP, Вы столкнетесь кое с какими специфическими аббревиатурами. Поэтому нужен глоссарий.
Этот глоссарий предназначен только для того, чтобы осветить первые шаги, он не претендует на статус полного и строгого источника ссылок. Ваша (конструктивная J !) критика поможет ему в его совершенствовании.
От редактора
Воспользуемся предложением автора и попросим прокомментировать эти термины Ольгу Горчинскую, технического консультанта Oracle CНГ по OLAP и хранилищам данных. Она скажет, как эти термины понимаются в русскоязычном OLAP. Я надеюсь, что все Вы присоединитесь с моей искренней благодарности Ольге. Ее замечания выделены особым цветом.
Cкачать статью в виде .pdf файла
© 2001 Interface Ltd
