Вход

OLAP технологии

Реферат* по праву и законодательству
Дата добавления: 19 июля 2008
Язык реферата: Русский
Word, rtf, 3 Мб
Реферат можно скачать бесплатно
Скачать
Данная работа не подходит - план Б:
Создаете заказ
Выбираете исполнителя
Готовый результат
Исполнители предлагают свои условия
Автор работает
Заказать
Не подходит данная работа?
Вы можете заказать написание любой учебной работы на любую тему.
Заказать новую работу
* Данная работа не является научным трудом, не является выпускной квалификационной работой и представляет собой результат обработки, структурирования и форматирования собранной информации, предназначенной для использования в качестве источника материала при самостоятельной подготовки учебных работ.
Очень похожие работы
Содержание: 1 Введение 3 2 Хранилища данных 5 2.1 Что такое хранилище данных? 5 2.2 Типичная структура хранилищ данных 6 2.2.1 Таблица фактов 7 2.2.2 Таблицы измерений 9 2.3 OLAP на клиенте и на сервере 13 2.4 Технические аспекты многомерного хранения данных 14 3 Основные понятия OLAP 16 3.1 Тест FAMSI 16 3.2 Многомерное представление информации 16 3.3 Кубы 16 3.3.1 “Разрезание” куба 17 3.3.2 Метки 18 3.3.3 Иерархии и уровни 18 3.3.4 Архитектура OLAP приложений 19 4 Заключение 21 5 Список использованной литературы 22 6 Список иллюстраций 23 1 Введение Трудно найти в компьютерном мире человека, который хотя бы на интуитивном уровне не понимал, что такое базы данных и зачем они нужны. В отличие от традиционных реляци онных СУБД, концепция OLAP Online Analytical Processing . не так широко известна, хотя загадочный термин "кубы OLAP" слышали, наверное, почти все. Что же такое Online Analytical Processing ? OLAP - это не отдельно взятый программный продукт, не язык программирования и даже не конкретная технология. Если постараться охватить OLAP во всех его проявлениях, то это совокупность концепций, принципов и требований, лежащих в основе программных продуктов, облегчающих аналитикам доступ к данным. Для начала мы выясним, зачем аналитикам надо как-то специально облегчать доступ к данным. Дело в том, что аналитики - это особые потребители корпоративной информации. Задача аналитика - находить закономерности в больших массивах данных. Поэтому аналитик не будет обращать внимания на отдельно взятый факт, что в четверг четвертого числа контр агенту Чернову была продана партия черных чернил - ему нужна информация о сотнях и ты сячах подобных событий. Одиночные факты в базе данных могут заинтересовать, к примеру, бухгалтера или начальника отдела продаж, в компетенции которого находится сделка. Ана литику одной записи мало - ему, к примеру, могут понадобиться все сделки данного филиала или представительства за месяц, год. Заодно аналитик отбрасывает ненужные ему подробно сти вроде ИНН покупателя, его точного адреса и номера телефона, индекса контракта и тому подобного. В то же время данные, которые требуются аналитику для работы, обязательно содержат числовые значения - это обусловлено самой сущностью его деятельности. Централизация и удобное структурирование - это далеко не все, что нужно аналитику. Ему ведь еще требуется инструмент для просмотра, визуализации информации. Традицион ные отчеты, даже построенные на основе единого хранилища, лишены одного - гибкости. Их нельзя “покрутить”, “развернуть” или “свернуть”, чтобы получить желаемое представление данных. Конечно, можно вызвать программиста , и он сделает новый отчет достаточно быс т ро - скажем , в течение часа . Получается, что аналитик может проверить за день не более двух идей. А ему (если он хороший аналитик) таких идей может приходить в голову по нескольку в час. И чем больше “срезов” и “разрезов” данных анали тик видит, тем больше у него идей, которые, в свою очередь, для проверки требуют все но вых и новых “срезов”. Вот бы ему т а кой инструмент, который позволил бы разворачивать и сворачивать данные просто и удобно! В качестве такого инструмента и выступает OLAP. Хотя OLAP и не представляет собой необходимый атрибут хранилища данных, он все чаще и чаще применяется для анализа накопленных в этом хранилище сведений. Компоненты, входящие в типичное хранилище, представлены на рис. 1. Рисунок 1 . Структура хранилища данных Оперативные данные собираются из различных источников, очищаются, интегрирую т ся и складываются в реляционное хранилище Хранилище данных — это интегрированный накопитель информации, собранной из других систем, на основе которого строятся процессы принятия решений и анализа данных. . При этом они уже доступны для анализа при помощи различных средств построения отчетов. Затем данные (полностью или частично) подготавливаются для OLAP-анализа. Они могут быть загружены в специальную БД OLAP или оставлены в реляционном хранилище. Важнейшим его элементом являются метаданные, т. е. информация о структуре, размещении и трансформации данных. Благодаря н им обесп е чивается эффективное взаимодействие различных компонентов хранилища. Подытоживая, можно определить OLAP как совокупность средств многомерного ан а лиза данных, накопленных в хранилище. Теоретически средства OLAP можно применять и непосредственно к оперативным данным или их точным копиям (чтобы не мешать операти в ным пользователям). Но мы тем самым рискуем наступить на уже описанные выше грабли, то есть начать анализировать оперативные данные, которые напрямую для анализа непр и годны. 2 Хранилища данных 2.1 Что такое хранилище данных? Информационные системы масштаба предприятия, как правило, содержат приложения, предназначенные для комплексного многомерного анализа данных, их динамики, тенденций и т.п. Такой анализ в конечном итоге призван содействовать принятию решений. Нередко эти системы так и называются — системы поддержки принятия решений. Принять любое управленческое решение невозможно не обладая необходимой для эт о го информацией, обычно количественной. Для этого необходимо создание хранилищ данных ( Data warehouses ), то есть процесс сбора, отсеивания и предварительной обработки данных с целью предоставления результирующей информации пользователям для статистического анализа (а нередко и создания аналитических отчетов). Ральф Кимбалл ( Ralph Kimball ), один из авторов концепции хранилищ данных, опис ы вал хранилище данных как "место, где люди могут получить доступ к своим данным" (см., например, Ralph Kimball , " The Data Warehouse Toolkit : Practical Techniques for Building D i mensional Data Warehouses ", John Wiley & Sons , 1996 и " The Data Web house Toolkit : Building the Web - Enabled Data Warehouse ", John Wiley & Sons , 2000). Он же сформулировал и осно в ные требования к хранилищам данных: · поддержка высокой скорости получения данных из хранилища; · поддержка внутренней непротиворечивости данных; · возможность получения и сравнения так называемых срезов данных ( slice and dice ); · наличие удобных утилит просмотра данных в хранилище; · полнота и достоверность хранимых данных; · поддержка качественного процесса пополнения данных. Удовлетворять всем перечисленным требованиям в рамках одного и того же продукта зачастую не удается. Поэтому для реализации хранилищ данных обычно используется н е сколько продуктов, одни их которых представляют собой собственно средства хранения данных, другие — средства их извлечения и просмотра, третьи — средства их пополнения и т.д. Типичное хранилище данных, как правило, отличается от обычной реляционной базы данных. Во-первых, обычные базы данных предназначены для того, чтобы помочь пользов а телям выполнять повседневную работу, тогда как хранилища данных предназначены для принятия решений. Например, продажа товара и выписка счета производятся с использов а нием базы данных, предназначенной для обработки транзакций, а анализ динамики продаж за несколько лет, позволяющий спланировать работу с поставщиками, — с помощью хран и лища данных. Во-вторых, обычные базы данных подвержены постоянным изменениям в процессе р а боты пользователей, а хранилище данных относительно стабильно: данные в нем обычно о б новляются согласно расписанию (например, еженедельно, ежедневно или ежечасно — в з а висимости от потребностей). В идеале процесс пополнения представляет собой просто д о бавление новых данных за определенный период времени без изменения прежней информ а ции, уже находящейся в хранилище. И, в-третьих, обычные базы данных чаще всего являются источником данных, попад а ющих в хранилище. Кроме того, хранилище может пополняться за счет внешних источников, например статистических отчетов. 2.2 Типичная структура хранилищ данных Как мы уже знаем, конечной целью использования OLAP является анализ данных и представление результатов этого анализа в виде, удобном для восприятия и принятия реш е ний. Основная идея OLAP заключается в построении многомерных кубов, которые будут д о ступны для пользовательских запросов. Однако исходные данные для построения OLAP-кубов обычно хранятся в реляционных базах данных. Нередко это специализированные р е ляционные базы данных, называемые также хранилищами данных ( Data Warehouse ). В отл и чие от так называемых оперативных баз данных, с которыми работают приложения, мод и фицирующие данные, хранилища данных предназначены исключительно для обработки и анализа информации, поэтому проектируются они таким образом, чтобы время выполнения запросов к ним было минимальным. Обычно данные копируются в хранилище из операти в ных баз данных согласно определенному расписанию. Типичная структура хранилища данных существенно отличается от структуры обычной реляционной СУБД. Как правило, эта структура денормализована (это позволяет повысить скорость выполнения запросов), поэтому может допускать избыточность данных. Для дальнейших примеров мы снова воспользуемся базой данных Northwind , входящей в комплекты поставки Microsoft SQL Server и Microsoft Access . Ее стру ктура данных прив е дена на рис. 2 . Рисунок 2 . Структура базы данных Northwind Основными составляющими структуры хранилищ данных являются таблица фактов ( fact t a ble ) и таблицы измерений ( dimension tables ). 2.2.1 Таблица фактов Таблица фактов является основной таблицей хранилища данных. Как правило, она с о держит сведения об объектах или событиях, совокупность которых будет в дальнейшем ан а лизироваться. Обычно говорят о четырех наиболее часто встречающихся типах фактов. К ним относятся: · факты, связанные с транзакциями ( Transaction facts ). Они основаны на отдельных с о бытиях (типичными примерами которых являются телефонный звонок или снятие д е нег со счета с помощью банкомата); · факты, связанные с «моментальными снимками» ( Snapshot facts ). Основаны на сост о янии объекта (например, банковского счета) в определенные моменты времени, например на конец дня, или месяца. Типичными примерами таких фактов являются объем продаж за день или дневная выручка; · факты, связанные с элементами документа ( Line - item facts ). Основаны на том или ином документе (например, счете за товар или услуги) и содержат подробную инфо р мацию об элементах этого документа (например, количестве, цене, проценте скидки); · факты, связанные с событиями или состоянием объекта ( Event or state facts ). Пре д ставляют возникновение события без подробностей о нем (например, просто факт продажи или факт отсутствия таковой без иных подробностей). Для примера рассмотрим факты, связанные с элементами документа (в данном случае счета, выставленного за товар). Таблица фактов, как правило, содержит уникальный составной ключ, объединяющий первичные ключи таблиц измерений. Чаще всего это целочисленные значения либо значения типа «дата/время» — ведь таблица фактов может содержать сотни тысяч или даже миллионы записей, и хранить в ней повторяющиеся текстовые описания, как правило, невыгодно — лучше поместить их в меньшие по объему таблицы измерений. При этом как ключевые, так и некоторые неключевые поля должны соответствовать будущим измерениям OLAP-куба. П о мимо этого таблица фактов содержит одно или несколько числовых полей, на основании к о торых в дальнейшем будут получены агрегатные данные. Пример таблицы фактов, которая может быть построена на основе базы данн ых Northwind, приведен на рис. 3 . Рисунок 3 . Пример таблицы фактов В данном примере измерениям будущего куба соответствуют первые шесть полей, а агрегатным данным — последние четыре. Отметим, что для многомерного анализа пригодны таблицы фактов, содержащие как можно более подробные данные (то есть соответствующие членам нижних уровней иерархии соответствующих измерений). В данном случае предпочтительнее взять за основу факты продажи товаров отдельным заказчикам, а не суммы продаж для разных стран — последние все равно будут вычислены OLAP-средством. Исключение можно сделать, пожалуй, только для клиентских OLAP-средств (о них мы поговорим чуть позже), поскольку в силу ряда ограничений они не могут манипулировать большими объемами данных. Отметим, что в таблице фактов нет никаких сведений о том, как группировать записи при вычислении агрегатных данных. Например, в ней есть идентификаторы продуктов или клиентов, но отсутствует информация о том, к какой категории относится данный продукт или в каком городе находится данный клиент. Эти сведения, в дальнейшем используемые для построения иерархий в измерениях куба, содержатся в таблицах измерений. 2.2.2 Таблицы измерений Таблицы измерений содержат неизменяемые либо редко изменяемые данные. В пода в ляющем большинстве случаев эти данные представляют собой по одной записи для каждого члена нижнего уровня иерархии в измерении. Таблицы измерений также содержат как м и нимум одно описательное поле (обычно с именем члена измерения) и, как правило, целочи с ленное ключевое поле (обычно это суррогатный ключ) для однозначной идентификации чл е на измерения. Если будущее измерение, основанное на данной таблице измерений, содержит иерархию, то таблица измерений также может содержать поля, указывающие на «родителя» данного члена в этой иерархии. Нередко (но не всегда) таблица измерений может содержать и поля, указывающие на «прародителей», и иных «предков» в данной иерархии (это обычно характерно для сбалансированных иерархий), а также дополнительные атрибуты членов и з мерений, содержавшиеся в исходной оперативной базе данных (например, адреса и телеф о ны клиентов). Каждая таблица измерений должна находиться в отношении «один ко многим» с та б лицей фактов. Отметим, что скорость роста таблиц измерений должна быть незначительной по сра в нению со скоростью роста таблицы фактов; например, добавление новой записи в таблицу измерений, характеризующую товары, производится только при появлении нового товара, не продававшегося ранее. Пример табл ицы измерений приведен на рис. 4 . Рисунок 4 . Пример таблицы измерений Одно измерение куба может содержаться как в одной таблице (в том числе и при нал и чии нескольких уровней иерархии), так и в нескольких связанных таблицах, соответству ю щих различным уровням иерархии в измерении. Если каждое измерение содержится в одной таблице, такая схема хранилища данных носит название «звезда» ( star schema ). Приме р такой схемы приведен на рис. 5 . Рисунок 5 . Пример схемы "звезда" Если же хотя бы одно измерение содержится в нескольких связанных таблицах, такая схема хранилища данных носит название «снежинка» ( snowflake schema ). Дополнительные таблицы измерений в такой схеме, обычно соответствующие верхним уровням иерархии и з мерения и находящиеся в соотношении «один ко многим» в главной таблице измерений, с о ответствующей нижнему уровню иерархии, иногда называют консольными таблицами ( ou t rigger table ). Пример схе мы «снежинка» приведен на рис. 6 . Рисунок 6 . Пример схемы "снежинка" Отметим, что даже при наличии иерархических измерений с целью повышения скор о сти выполнения запросов к хранилищу данных нередко предпочтение отдается схеме «зве з да». Однако не все хранилища данных проектируются по двум приведенным выше схемам. Так, довольно часто вместо ключевого поля для измерения, содержащего данные типа «д а та», и соответствующей таблицы измерений сама таблица фактов может содержать ключевое поле типа «дата». В этом случае соответствующая таблица измерений просто отсутствует. В случае несбалансированной иерархии (например, такой, которая может быть основ а на на таблице Employees базы данных Northwind, имеющей поле Employee ID , которое одн о временно является и первичным, и внешним ключом и отражает подчиненность одних с о трудников другим (см. рис. 6 ) в схему «снежинка» также следует вносить коррективы. В этом случае обычно в таблице измерений присутствует связь, аналогичная соответствующей связи в оперативной базе данных. Еще один пример отступления от правил — наличие нескольких разных иерархий для одного и того же измерения. Типичные примеры таких иерархий — иерархии для календа р ного и финансового года (при условии, что финансовый год начинается не с 1 января), или с различными способами группировки членов измерения (например, группировать товары можно по категориям, а можно и по компаниям-поставщикам). В этом случае таблица изм е рений содержит поля для всех возможных иерархий с одними и теми же членами нижнего уровня, но с разными членами верхних уровней (пример такой таблицы приведен на рис. 3). Как мы уже отмечали выше, таблица измерений может содержать поля, не имеющие отношения к иерархиям и представляющие собой просто дополнительные атрибуты членов измерений ( member properties ). Иногда такие атрибуты могут быть использованы при анализе данных. Следует сказать, что для создания реляционных хранилищ данных нередко применяю т ся специализированные СУБД, хранение данных в которых оптимизировано с точки зрения скорости выполнения запросов. Примером такого продукта является Sybase Adaptive Server IQ, реализующий нетрадиционный способ хранения данных в таблицах (не по строкам, а по столбцам). Однако создавать хранилища можно и в обычных реляционных СУБД. 2.3 OLAP на клиенте и на сервере Многомерный анализ данных может быть произведен с помощью различных средств, которые условно можно разделить на клиентские и серверные OLAP-средства. Клиентские OLAP-средства представляют собой приложения, осуществляющие вычи с ление агрегатных данных (сумм, средних величин, максимальных или минимальных знач е ний) и их отображение, при этом сами агрегатные данные содержатся в кэше внутри адре с ного пространства такого OLAP-средства. Если исходные данные содержатся в настольной СУБД, вычисление агрегатных да н ных производится самим OLAP-средством. Если же источник исходных данных — серверная СУБД, многие из клиентских OLAP-средств посылают на сервер SQL-запросы, содержащие оператор GROUP BY, и в результате получают агрегатные данные, вычисленные на сервере. Как правило, OLAP-функциональность реализована в средствах статистической обр а ботки данных (из продуктов этого класса на российском рынке широко распространены пр о дукты компаний Stat Soft и SPSS) и в некоторых электронных таблицах. В частности, непл о хими средствами многомерного анализа обладает Microsoft Excel 2000. С помощью этого продукта можно создать и сохранить в виде файла небольшой локальный многомерный OLAP-куб и отобразить его двух- или трехмерные сечения. Многие средства разработки содержат библиотеки классов или компонентов, позвол я ющие создавать приложения, реализующие простейшую OLAP-функциональность (такие, например, как компоненты Decision Cube в Borland Delphi и Borland C++Builder ). Помимо этого многие компании предлагают элементы управления ActiveX и другие библиотеки, ре а лизующие подобную функциональность. Отметим, что клиентские OLAP-средства применяются, как правило, при малом числе измерений (обычно рекомендуется не более шести) и небольшом разнообразии значений этих параметров, — ведь полученные агрегатные данные должны умещаться в адресном пространстве подобного средства, а их количество растет экспоненциально при увеличении числа измерений. Поэтому даже самые примитивные клиентские OLAP-средства, как прав и ло, позволяют произвести предварительный подсчет объема требуемой оперативной памяти для создания в ней многомерного куба. Многие (но не все!) клиентские OLAP-средства позволяют сохранить содержимое кэша с агрегатными данными в виде файла, что, в свою очередь, позволяет не производить их п о вторное вычисление. Отметим, что нередко такая возможность используется для отчуждения агрегатных данных с целью передачи их другим организациям или для публикации. Типи ч ным примером таких отчуждаемых агрегатных данных является статистика заболеваемости в разных регионах и в различных возрастных группах, которая является открытой информац и ей, публикуемой министерствами здравоохранения различных стран и Всемирной организ а цией здравоохранения. При этом собственно исходные данные, представляющие собой св е дения о конкретных случаях заболеваний, являются конфиденциальными данными медици н ских учреждений, которые ни в коем случае не должны попадать в руки страховых компаний и тем более становиться достоянием гласности. Идея сохранения кэша с агрегатными данными в файле получила свое дальнейшее ра з витие в серверных OLAP-средствах, в которых сохранение и изменение агрегатных данных, а также поддержка содержащего их хранилища осуществляются отдельным приложением или процессом, называемым OLAP-сервером. Клиентские приложения могут запрашивать подобное многомерное хранилище и в ответ получать те или иные данные. Некоторые кл и ентские приложения могут также создавать такие хранилища или обновлять их в соотве т ствии с изменившимися исходными данными. Преимущества применения серверных OLAP-средств по сравнению с клиентскими OLAP-средствами сходны с преимуществами применения серверных СУБД по сравнению с настольными: в случае применения серверных средств вычисление и хранение агрегатных данных происходят на сервере, а клиентское приложение получает лишь результаты запр о сов к ним, что позволяет в общем случае снизить сетевой трафик, время выполнения запр о сов и требования к ресурсам, потребляемым клиентским приложением. Отметим, что сре д ства анализа и обработки данных масштаба предприятия, как правило, базируются именно на серверных OLAP-средствах, например, таких как Oracle Express Server , Microsoft SQL Server 2000 Analysis Services , Hyperion Essbase , продуктах компаний Crystal Decisions , Business O b jects , Cognos , SAS Institute . Поскольку все ведущие производители серверных СУБД прои з водят (либо лицензировали у других компаний) те или иные серверные OLAP-средства, в ы бор их достаточно широк и почти во всех случаях можно приобрести OLAP-сервер того же производителя, что и у самого сервера баз данных. Отметим, что многие клиентские OLAP-средства (в частности, Microsoft Excel 2000, Seagate Analysis и др.) позволяют обращаться к серверным OLAP-хранилищам, выступая в этом случае в роли клиентских приложений, выполняющих подобные запросы. Помимо эт о го имеется немало продуктов, представляющих собой клиентские приложения к OLAP-средствам различных производителей. 2.4 Технические аспекты многомерного хранения данных В многомерных хранилищах данных содержатся агрегатные данные различной степени подробности, например, объемы продаж по дням, месяцам, годам, по категориям товаров и т.п. Цель хранения агрегатных данных — сократить время выполнения запросов, поскольку в большинстве случаев для анализа и прогнозов интересны не детальные, а суммарные данные. Поэтому при создании многомерной базы данных всегда вычисляются и сохраняются нек о торые агрегатные данные. Отметим, что сохранение всех агрегатных данных не всегда оправданно. Дело в том, что при добавлении новых измерений объем данных, составляющих куб, растет экспоненц и ально (иногда говорят о «взрывном росте» объема данных). Если говорить более точно, ст е пень роста объема агрегатных данных зависит от количества измерений куба и членов изм е рений на различных уровнях иерархий этих измерений. Для решения проблемы «взрывного роста» применяются разнообразные схемы, позволяющие при вычислении далеко не всех возможных агрегатных данных достичь приемлемой скорости выполнения запросов. Как исходные, так и агрегатные данные могут храниться либо в реляционных, либо в многомерных структурах. Поэтому в настоящее время применяются три способа хранения данных: · MOLAP ( Multidimensional OLAP) – — исходные и агрегатные данные хранятся в многомерной базе данных. Хранение данных в многомерных структурах позволяет манипулировать данными как многомерным массивом, благодаря чему скорость вычисления агрегатных значений одинакова для любого из измерений. Однако в этом случае многомерная база данных оказывается избыточной, так как многоме р ные данные полностью содержат исходные реляционные данные. · ROLAP ( Relational OLAP) — исходные данные остаются в той же реляционной базе данных, где они изначально и находились. Агрегатные же данные помещают в сп е циально созданные для их хранения служебные таблицы в той же базе данных. · HOLAP ( Hybrid OLAP) — исходные данные остаются в той же реляционной базе данных, где они изначально находились, а агрегатные данные хранятся в многоме р ной базе данных. Некоторые OLAP-средства поддерживают хранение данных только в реляционных структурах, некоторые — только в многомерных. Однако большинство современных серве р ных OLAP-средств поддерживают все три способа хранения данных. Выбор способа хран е ния зависит от объема и структуры исходных данных, требований к скорости выполнения запросов и частоты обновления OLAP-кубов. Отметим также, что подавляющее большинство современных OLAP-средств не хранит «пустых» значений (примером «пустого» значения может быть отсутствие продаж сезонного товара вне сезона). 3 Основные понятия OLAP 3.1 Тест FAMSI Технология комплексного многомерного анализа данных получила название OLAP ( On - Line Analytical Processing ). OLAP — это ключевой компонент организации хранилищ данных. Концепция OLAP была описана в 1993 году Эдгаром Коддом, известным исследов а телем баз данных и автором реляционной модели данных (см. E.F. Codd , S.B. Codd , and C.T.Salley , Providing OLAP (on-line analytical processing) to user-analysts: An IT mandate. Tec h nical report , 1993). В 1995 году на основе требований, изложенных Коддом, был сформулир о ван так называемый тест FASMI ( Fast Analysis of Shared Multidimensional Information — быстрый анализ разделяемой многомерной информации), включающий следующие требов а ния к приложениям для многомерного анализа: · Fast (Быстрый) - предоставление пользователю результатов анализа за приемлемое время (обычно не более 5 с), пусть даже ценой менее детального анализа; · Analysis (Анализ) - возможность осуществления любого логического и статист и ческого анализа, характерного для данного приложения, и его сохранения в д о ступном для конечного пользователя виде; · Shared (Разделяемой) - многопользовательский доступ к данным с поддержкой с о ответствующих механизмов блокировок и средств авторизованного доступа; · Multidimensional (Многомерной) - многомерное концептуальное представление данных, включая полную поддержку для иерархий и множественных иерархий (это — ключевое требование OLAP); · Information (Информации) - приложение должно иметь возможность обращаться к любой нужной информации, независимо от ее объема и места хранения. Следует отметить, что OLAP -функциональность может быть реализована различными способами, начиная с простейших средств анализа данных в офисных приложениях и зака н чивая распределенными аналитическими системами, основанными на серверных продуктах. 3.2 Многомерное представление информации 3.3 Кубы OLAP предоставляет удобные быстродействующие средства доступа, просмотра и ан а лиза деловой информации. Пользователь получает естественную, интуитивно понятную м о дель данных, организуя их в виде многомерных кубов ( Cubes ). Осями многомерной системы координат служат основные атрибуты анализируемого бизнес-процесса. Например, для пр о даж это могут быть товар, регион, тип покупателя. В качестве одного из измерений испол ь зуется время. На пересечениях осей - измерений ( Dimensions ) - находятся данные, колич е ственно характеризующие процесс - меры ( Measures ). Это могут быть объемы продаж в шт у ках или в денежном выражении, остатки на складе, издержки и т. п. Пользователь, анализ и рующий информацию, может “разрезать” куб по разным направлениям, получать сводные (например, по годам) или, наоборот, детальные (по неделям) сведения и осуществлять пр о чие манипуляции, которые ему придут в голову в процессе анализа. В качестве мер в трехмерном кубе, изображенном на рис. 2, использованы суммы пр о даж, а в качестве измерений - время, товар и магазин. Измерения представлены на опред е ленных уровнях группировки: товары группируются по категориям, магазины - по странам, а данные о времени совершения операций - по месяцам. Чуть позже мы рассмотрим уровни группировки (иерархии) подробнее. Рисунок 7 . Пример куба 3.3.1 “Разрезание” куба Даже трехмерный куб сложно отобразить на экране компьютера так, чтобы были видны значения интересующих мер. Что уж говорить о кубах с количеством измерений, большим трех? Для визуализации данных, хранящихся в кубе, применяются, как правило, привычные двумерные, т. е. табличные, представления, имеющие сложные иерархические заголовки строк и столбцов. Двумерное представление куба можно получить, “разрезав” его поперек одной или н е скольких осей (измерений): мы фиксируем значения всех измерений, кроме двух, - и получ а ем обычную двумерную таблицу. В горизонтальной оси таблицы (заголовки столбцов) пре д ставлено одно измерение, в вертикальной (заголовки строк) - другое, а в ячейках таблицы - значения мер. При этом набор мер фактически рассматривается как одно из измерений - мы либо выбираем для показа одну меру (и тогда можем разместить в заголовках строк и стол б цов два измерения), либо показываем несколько мер (и тогда одну из осей таблицы займут названия мер, а другую - значения единственного “неразрезанного” измерения). Взгляните на рис. 8 - здесь изображен двумерный срез куба для одной меры - Unit Sales (продано штук) и двух “неразрезанных” измерений - Store (Магазин) и Время ( Time ). Рисунок 8 . Двумерный срез куба для одной меры На рис. 9 представлено лишь одно “неразрезанное” измерение - Store , но зато здесь отображаются значения нескольких мер - Unit Sales (продано штук), Store Sales (сумма пр о дажи) и Store Cost (расходы магазина). Рисунок 9 . Двумерный срез куба для нескольких мер Двумерное представление куба возможно и тогда, когда “неразрезанными” остаются и более двух измерений. При этом на осях среза (строках и столбцах) будут размещены два или более измерений “разрезаемого” куба - см. рис. 10 . Рисунок 10 . Двумерный срез куба с несколькими измерениями на одной оси 3.3.2 Метки Значения, “откладываемые” вдоль измерений, называются членами или метками ( me m bers ). Метки используются как для “разрезания” куба, так и для ограничения (фильтрации) выбираемых данных - когда в измерении, остающемся “неразрезанным”, нас интересуют не все значения, а их подмножество, например три города из нескольких десятков. Значения м е ток отображаются в двумерном представлении куба как заголовки строк и столбцов. 3.3.3 Иерархии и уровни Метки могут объединяться в иерархии, состоящие из одного или нескольких уровней ( levels ). Например, метки измерения “Магазин” ( Store ) естественно объединяются в иера р хию с уровнями: All ( Мир ) Country ( Страна ) State ( Штат ) City ( Город ) Store (Магазин). В соответствии с уровнями иерархии вычисляются агрегатные значения, например об ъ ем продаж для USA (уровень “ Country ”) или для штата California (уровень “ State ”). В одном измерении можно реализовать более одной иерархии - скажем, для времени: Год, Квартал, Месяц, День и Год, Неделя, День . Отметим, что иерархии могут быть сбалансированными ( balanced ), как, например, ие рархия, представленная на рис. 11 , а также иерархии, основанные на данных типа "дата— время", и несбалансированными ( unbalanced ). Типичный пример несбалансированной иера р хии — иерархия типа "начальник— подчиненный" (ее можно построить, например, используя значения поля Salesperson исходного набора данных из рассмотренного выше примера), представлен на рис. 12 Рисунок 11 . Иерархия в измерении, связанном с географическим положением клиентов Рисунок 12 . Несбалансированная иерархия Иногда для таких иерархий используется термин Parent-child hierarchy . Существуют также иерархии, занимающие промежуточное положение между сбала н сированными и несбалансированными (они обозначаются термином ragged — "неровный"). Обычно они содержат такие члены, логические "родители" которых находятся не на неп о средственно вышестоящем уровне (например, в географической иерархии есть уровни Cou n try , City и State , но при этом в наборе данных имеются страны, не имеющие штатов или рег и онов между уровнями Country и City ; (рис. 13 ). Рисунок 13 . "Неровная" иерархия Отметим, что несбалансированные и "неровные" иерархии поддерживаются далеко не всеми OLAP-средствами. Например, в Microsoft Analysis Services 2000 поддерживаются оба типа иерархии, а в Microsoft OLAP Services 7.0 — только сбалансированные. Различным в разных OLAP-средствах может быть и число уровней иерархии, и максимально допустимое число членов одного уровня, и максимально возможное число самих измерений. 3.3.4 Архитектура OLAP приложений Все, что говорилось выше про OLAP, по сути, относилось к многомерному представл е нию данных. То, как данные хранятся, грубо говоря, не волнует ни конечного пользователя, ни разработчиков инструмента, которым клиент пользуется. Многомерность в OLAP-приложениях может быть разделена на три уровня: Ш Многомерное представление данных - средства конечного пользователя, обеспеч и вающие многомерную визуализацию и манипулирование данными; слой многоме р ного представления абстрагирован от физической структуры данных и восприним а ет данные как многомерные. Ш Многомерная обработка - средство (язык) формулирования многомерных запросов (традиционный реляционный язык SQL здесь оказывается непригодным) и проце с сор, умеющий обработать и выполнить такой запрос. Ш Многомерное хранение - средства физической организации данных, обеспечива ю щие эффективное выполнение многомерных запросов. Первые два уровня в обязательном порядке присутствуют во всех OLAP-средствах. Третий уровень, хотя и является широко распространенным, не обязателен, так как данные для многомерного представления могут извлекаться и из обычных реляционных структур; процессор многомерных запросов в этом случае транслирует многомерные запросы в SQL-запросы, которые выполняются реляционной СУБД. Конкретные OLAP-продукты, как правило, представляют собой либо средство мног о мерного представления данных, OLAP-клиент (например, Pivot Tables в Excel 2000 фирмы Microsoft или ProClarity фирмы Knosys ), либо многомерную серверную СУБД , OLAP- сервер ( например , Oracle Express Server или Microsoft OLAP Services). Слой многомерной обработки обычно бывает встроен в OLAP-клиент и/или в OLAP-сервер, но может быть выделен в чистом виде, как, например, компонент Pivot Table Service фирмы Microsoft . 4 Заключение В данной работе мы ознакомились с основами OLAP. Мы узнали следующее: · Назначение хранилищ данных — предоставление пользователям информации для статистического анализа и принятия управленческих решений. · Хранилища данных должны обеспечивать высокую скорость получения данных, во з можность получения и сравнения, так называемых срезов данных, а также непротив о речивость, полноту и достоверность данных. · OLAP ( On-Line Analytical Processing ) является ключевым компонентом построения и применения хранилищ данных. Эта технология основана на построении многомерных наборов данных — OLAP-кубов, оси которого содержат параметры, а ячейки — зав и сящие от них агрегатные данные. · Приложения с OLAP-функциональностью должны предоставлять пользователю р е зультаты анализа за приемлемое время, осуществлять логический и статистический анализ, поддерживать многопользовательский доступ к данным, осуществлять мног о мерное концептуальное представление данных и иметь возможность обращаться к любой нужной информации. Кроме того, мы рассмотрели основные принципы логической организации OLAP-кубов, а также узнали основные термины и понятия, применяемые при многомерном анал и зе. И наконец, мы выяснили, что представляют собой различные типы иерархий в измерен и ях OLAP-кубов. 5 Список использованной литературы 1. Материалы сайта http://www.softkey.info 2. Материалы сайта http://www.iemag.ru 3. Материалы сайта http://www.compress.r u 4. Материалы сайта www.olap.ru 5. Дюк В.А. Обработка данных на ПК в примерах. — СПб: Питер, 1997. 6 Список иллюстраций Рисунок 1. Структура хранилища данных 4 Рисунок 2. Структура базы данных Northwind 7 Рисунок 3. Пример таблицы фактов 8 Рисунок 4. Пример таблицы измерений 10 Рисунок 5. Пример схемы "звезда" 11 Рисунок 6. Пример схемы "снежинка" 12 Рисунок 7. Пример куба 17 Рисунок 8. Двумерный срез куба для одной меры 17 Рисунок 9. Двумерный срез куба для нескольких мер 17 Рисунок 10. Двумерный срез куба с несколькими измерениями на одной оси 18 Рисунок 11. Иерархия в измерении, связанном с географическим положением клиентов 18 Рисунок 12. Несбалансированная иерархия 19 Рисунок 13. "Неровная" иерархия 19
© Рефератбанк, 2002 - 2024