Основные данные о работеВерсия шаблона 2.1 Филиал Уфимский Вид работы Курсовая работа Название дисциплины Базы данных Тема Технология OLAP Фамилия студента Резванов Имя студента Дмитрий Отчество студента Талгатович № контракта 03300090609014
/>/>/>/>/>/>/>/>Введение
В наше время безсистем управления базами данных не обходится практически ни одна организация, особенносреди тех, которые традиционно ориентированы на взаимодействие с клиентами. Банки,страховые компании, авиа- и прочие транспортные компании, сети супермаркетов, телекоммуникационныеи маркетинговые фирмы, организации, занятые в сфере услуг и другие — все они собираюти хранят в своих базах гигабайты данных о клиентах, продуктах и сервисах. Ценностьподобных сведений несомненна. Такие базы данных называют операционными или транзакционными,поскольку они характеризуются огромным количеством небольших транзакций, или операцийзаписи-чтения. Компьютерные системы, осуществляющие учет операций и собственно доступк базам транзакций, принято называть системами оперативной обработки транзакций(OLTP — On-Line Transactional Processing)или учетными системами.
Учетные системынастраиваются и оптимизируются для выполнения максимального количества транзакцийза короткие промежутки времени. Обычно отдельные операции очень малы и не связаныдруг с другом. Однако каждую запись данных, характеризующую взаимодействие с клиентом(звонок в службу поддержки, кассовую операцию, заказ по каталогу, посещение Web-сайтакомпании и т.п.) можно использовать для получения качественно новой информации,а именно для создания отчетов и анализа деятельности фирмы.
Набор аналитическихфункций в учетных системах обычно весьма ограничен. Схемы, используемые в OLTP-приложениях,осложняют создание даже простых отчетов, так как данные чаще всего распределеныпо множеству таблиц, и для их агрегирования необходимо выполнять сложные операцииобъединения. Как правило, попытки создания комплексных отчетов требуют больших вычислительныхмощностей и приводят к потере производительности.
Кроме того, вучетных системах хранятся постоянно изменяющиеся данные. По мере сбора транзакцийсуммарные значения меняются очень быстро, поэтому два анализа, проведенные с интерваломв несколько минут, могут дать разные результаты. Чаще всего, анализ выполнятся поокончании отчетного периода, иначе картина может оказаться искаженной. Кроме того,необходимые для анализа данные могут храниться в нескольких системах.
Некоторые видыанализа требуют таких структурных изменений, которые недопустимы в текущей оперативнойсреде. Например, нужно выяснить, что произойдет, если у компании появятся новыепродукты. На живой базе такое исследование провести нельзя. Следовательно, эффективныйанализ редко удается выполнить непосредственно в учетной системе.
Системы поддержкипринятия решений обычно обладают средствами предоставления пользователю агрегатныхданных для различных выборок из исходного набора в удобном для восприятия и анализавиде. Как правило, такие агрегатные функции образуют многомерный (и, следовательно,нереляционный) набор данных (нередко называемый гиперкубом или метакубом), оси которогосодержат параметры, а ячейки — зависящие от них агрегатные данные — причем хранитьсятакие данные могут и в реляционных таблицах. Вдоль каждой оси данные могут бытьорганизованы в виде иерархии, представляющей различные уровни их детализации. Благодарятакой модели данных пользователи могут формулировать сложные запросы, генерироватьотчеты, получать подмножества данных.
Именно это и обусловило интереск системам поддержки принятия решений, ставших основной сферой применения OLAP (On-LineAnalytical Processing, оперативная аналитическая обработка, оперативный анализ данных),превращающей “руду” OLTP-систем в готовое “изделие”, которое руководители и аналитикимогут непосредственно использовать. Этот метод позволяет аналитикам, менеджерами руководителям «проникнуть в суть» накопленных данных за счет быстрогои согласованного доступа к широкому спектру представлений информации.
Целью курсовой работы являетсярассмотрение технологии OLAP.
многомерный аналитический обработка данный
/>/>/>/>Основная часть1 Основные сведения об OLAP
/>/>/>/>1.1 Оперативная аналитическая обработкаданных
В основе концепцииOLAP лежит принцип многомерного представления данных. В 1993 году термин OLAP ввел Эдгар Кодд. Рассмотрев недостатки реляционной модели, он в первую очередь указална невозможность «объединять, просматривать и анализировать данные с точки зрениямножественности измерений, то есть самым понятным для корпоративных аналитиков способом»,и определил общие требования к системам OLAP, расширяющим функциональность реляционныхСУБД и включающим многомерный анализ как одну из своих характеристик[1].
В большом числепубликаций аббревиатурой OLAP обозначается не только многомерный взгляд на данные,но и хранение самих данных в многомерной БД. Вообще говоря, это неверно, посколькусам Кодд отмечает, что «Реляционные БД были, есть и будут наиболее подходящейтехнологией для хранения корпоративных данных. Необходимость существует не в новойтехнологии БД, а, скорее, в средствах анализа, дополняющих функции существующихСУБД и достаточно гибких, чтобы предусмотреть и автоматизировать разные виды интеллектуальногоанализа, присущие OLAP». Такая путаница приводит к противопоставлениям наподобие«OLAP или ROLAP», что не совсем корректно, поскольку ROLAP (реляционныйOLAP) на концептуальном уровне поддерживает всю определенную термином OLAP функциональность.Более предпочтительным кажется использование для OLAP на основе многомерных СУБДспециального термина MOLAP. По Кодду, многомерное концептуальное представление (multi-dimensionalconceptual view) представляет собой множественную перспективу, состоящую из несколькихнезависимых измерений, вдоль которых могут быть проанализированы определенные совокупностиданных. Одновременный анализ по нескольким измерениям определяется как многомерныйанализ. Каждое измерение включает направления консолидации данных, состоящие изсерии последовательных уровней обобщения, где каждый вышестоящий уровень соответствуетбольшей степени агрегации данных по соответствующему измерению. Так, измерение.
Исполнитель можетопределяться направлением консолидации, состоящим из уровней обобщения «предприятие- подразделение — отдел — служащий». Измерение Время может даже включать дванаправления консолидации — «год — квартал — месяц — день» и «неделя- день», поскольку счет времени по месяцам и по неделям несовместим. В этомслучае становится возможным произвольный выбор желаемого уровня детализации информациипо каждому из измерений. Операция спуска (drilling down) соответствует движениюот высших ступеней консолидации к низшим; напротив, операция подъема (rolling up)означает движение от низших уровней к высшим.
Кодд определил12 правил, которым должен удовлетворять программный продукт класса OLAP[2].
1.2 Требования ксредствам оперативной аналитической обработки
Многомерное концептуальноепредставление данных (Multi Dimensional Conceptual View). Концептуальное представлениемодели данных в продукте OLAP должно быть многомерным по своей природе, то естьпозволять аналитикам выполнять интуитивные операции «анализа вдоль и поперек»(«slice and dice»), вращения (rotate) и размещения (pivot) направленийконсолидации. Прозрачность (Transparency). Пользователь не должен знать о том, какиеконкретные средства используются для хранения и обработки данных, как данные организованыи откуда берутся.
Доступность (Accessibility).Аналитик должен иметь возможность выполнять анализ в рамках общей концептуальнойсхемы, но при этом данные могут оставаться под управлением оставшихся от старогонаследства СУБД, будучи при этом привязанными к общей аналитической модели. То естьинструментарий OLAP должен накладывать свою логическую схему на физические массивыданных, выполняя все преобразования, требующиеся для обеспечения единого, согласованногои целостного взгляда пользователя на информацию.
Устойчивая производительность (Consistent Reporting Performance). С увеличением числа измерений и размеровбазы данных аналитики не должны столкнуться с каким бы то ни было уменьшением производительности.Устойчивая производительность необходима для поддержания простоты использованияи свободы от усложнений, которые требуются для доведения OLAP до конечного пользователя.
Клиент — серверная архитектура(Client-Server Architecture). Большая часть данных, требующих оперативной аналитическойобработки, хранится в мэйнфреймовых системах, а извлекается с персональных компьютеров.Поэтому одним из требований является способность продуктов OLAP работать в средеклиент-сервер. Главной идеей здесь является то, что серверный компонент инструментаOLAP должен быть достаточно интеллектуальным и обладать способностью строить общуюконцептуальную схему на основе обобщения и консолидации различных логических и физическихсхем корпоративных баз данных для обеспечения эффекта прозрачности.
Равноправие измерений (GenericDimensionality). Все измерения данных должны быть равноправны. Дополнительные характеристикимогут быть предоставлены отдельным измерениям, но поскольку все они симметричны,данная дополнительная функциональность может быть предоставлена любому измерению.Базовая структура данных, формулы и форматы отчетов не должны опираться на какое-тоодно измерение.
Динамическая обработка разреженныхматриц (Dynamic Sparse Matrix Handling). Инструмент OLAP должен обеспечивать оптимальнуюобработку разреженных матриц. Скорость доступа должна сохраняться вне зависимостиот расположения ячеек данных и быть постоянной величиной для моделей, имеющих разноечисло измерений и различную разреженность данных.
Поддержка многопользовательскогорежима (Multi-User Support). Зачастую несколько аналитиков имеют необходимость работатьодновременно с одной аналитической моделью или создавать различные модели на основеодних корпоративных данных. Инструмент OLAP должен предоставлять им конкурентныйдоступ, обеспечивать целостность и защиту данных.
Неограниченная поддержка кроссмерныхопераций (Unrestricted Cross-dimensional Operations). Вычисления и манипуляция даннымипо любому числу измерений не должны запрещать или ограничивать любые отношения междуячейками данных. Преобразования, требующие произвольного определения, должны задаватьсяна функционально полном формульном языке.
Интуитивное манипулированиеданными (Intuitive Data Manipulation). Переориентация направлений консолидации,детализация данных в колонках и строках, агрегация и другие манипуляции, свойственныеструктуре иерархии направлений консолидации, должны выполняться в максимально удобном,естественном и комфортном пользовательском интерфейсе[3].
Гибкий механизм генерацииотчетов (Flexible Reporting). Должны поддерживаться различные способы визуализацииданных, то есть отчеты должны представляться в любой возможной ориентации.
Неограниченное количествоизмерений и уровней агрегации (Unlimited Dimensions and Aggregation Levels). Настоятельнорекомендуется допущение в каждом серьезном OLAP инструменте как минимум пятнадцати,а лучше двадцати, измерений в аналитической модели.
2 Компоненты OLAP-систем
/>/>/>/>
2.1 Сервер. Клиент.Интернет
OLAP позволяетвыполнять быстрый и эффективный анализ над большими объемами данных. Данные хранятсяв многомерном виде, что наиболее близко отражает естественное состояние реальныхбизнес-данных. Кроме того, OLAP предоставляет пользователям возможность быстрееи проще получать сводные данные. С его помощью они могут при необходимости углубляться(drill down) в содержимое этих данных для получения более детализированной информации[4].
OLAP-система состоитиз множества компонент. На самом высоком уровне представления система включает всебя источник данных, OLAP-сервер и клиента. Источник данных представляет собойисточник, из которого берутся данные для анализа. Данные из источника переносятсяили копируются на OLAP-сервер, где они систематизируются и подготавливаются дляболее быстрого впоследствии формирования ответов на запросы. Клиент — это пользовательскийинтерфейс к OLAP-серверу. В этом разделе статьи описываются функции каждой компонентыи значение всей системы в целом. Источники. Источником в OLAP-системах являетсясервер, поставляющий данные для анализа. В зависимости от области использованияOLAP-продукта источником может служить Хранилище данных, наследуемая база данных,содержащая общие данные, набор таблиц, объединяющих финансовые данные или любаякомбинация перечисленного. Способность OLAP-продукта работать с данными из различныхисточников очень важна. Требование единого формата или единой базы, в которых быхранились все исходные данные, не подходит администраторам баз данных. Кроме того,такой подход уменьшает гибкость и мощность OLAP-продукта. Администраторы и пользователиполагают, что OLAP-продукты, обеспечивающие извлечение данных не только из различных,но и из множества источников, оказываются более гибкими и полезными, чем те, чтоимеют более жесткие требования.
Сервер. Прикладнойчастью OLAP-системы является OLAP-сервер. Эта составляющая выполняет всю работу(в зависимости от модели системы), и хранит в себе всю информацию, к которой обеспечиваетсяактивный доступ. Архитектурой сервера управляют различные концепции. В частности,основной функциональной характеристикой OLAP-продукта является использование дляхранения данных многомерной (ММБД, MDDB) либо реляционной (РДБ, RDB) базы данных.Агрегированные/Предварительно агрегированные данные
Быстрая реализациязапросов является императивом для OLAP. Это один из базовых принципов OLAP — способностьинтуитивно манипулировать данными требует быстрого извлечения информации. В целом,чем больше вычислений необходимо произвести, чтобы получить фрагмент информации,тем медленнее происходит отклик. Поэтому, чтобы сохранить маленькое время реализациизапросов, фрагменты информации, обращение к которым обычно происходит наиболее часто,но которые при этом требуют вычисления, подвергаются предварительной агрегации.То есть они подсчитываются и затем хранятся в базе данных в качестве новых данных.В качестве примера типа данных, который допустимо рассчитать заранее, можно привестисводные данные — например, показатели продаж по месяцам, кварталам или годам, длякоторых действительно введенными данными являются ежедневные показатели[5].
Различные поставщикипридерживаются различных методов отбора параметров, требующих предварительной агрегациии числа предварительно вычисляемых величин. Подход к агрегации влияет одновременнои на базу данных и на время реализации запросов. Если вычисляется больше величин,вероятность того, что пользователь запросит уже вычисленную величину, возрастает,и поэтому время отклика сократиться, так как не придется запрашивать изначальнуювеличину для вычисления. Однако, если вычислить все возможные величины — это нелучшее решение — в таком случае существенно возрастает размер базы данных, что сделаетее неуправляемой, да и время агрегации будет слишком большим. К тому же, когда вбазу данных добавляются числовые значения, или если они изменяются, информация этадолжна отражаться на предварительно вычисленных величинах, зависящих от новых данных.Таким образом, и обновление базы может также занять много времени в случае большогочисла предварительно вычисляемых величин. Поскольку обычно во время агрегации базаданных работает автономно, желательно, чтобы время агрегации было не слишком длительным.
Клиент. Клиент- это как раз то, что используется для представления и манипуляций с данными в базеданных. Клиент может быть и достаточно несложным — в виде таблицы, включающей всебя такие возможности OLAP, как, например, вращение данных (пивотинг) и углублениев данные (дриллинг), и представлять собой специализированное, но такое же простоесредство просмотра отчетов или быть таким же мощным инструментом, как созданноена заказ приложение, спроектированное для сложных манипуляций с данными. Интернетявляется новой формой клиента. Кроме того, он несет на себе печать новых технологий;множество интернет-решений существенно отличаются по своим возможностям в целоми в качестве OLAP-решения — в частности. В данном разделе обсуждаются различныефункциональные свойства каждого типа клиентов.
Несмотря на то,что сервер — это как бы «хребет» OLAP-решения, клиент не менее важен.Сервер может обеспечить прочный фундамент для облегчения манипуляций с данными,но если клиент сложен или малофункционален, пользователь не сможет воспользоватьсявсеми преимуществами мощного сервера. Клиент настолько важен, что множество поставщиковсосредотачивают свои усилия исключительно на разработке клиента. Все, что включаетсяв состав этих приложений, представляет собой стандартный взгляд на интерфейс, заранееопределенные функции и структуру, а также быстрые решения для более или менее стандартныхситуаций. Например, популярны финансовые пакеты. Заранее созданные финансовые приложенияпозволят специалистам использовать привычные финансовые инструменты без необходимостипроектировать структуру базы данных или общепринятые формы и отчеты. Инструментзапросов/Генератор отчетов. Инструмент запросов или генератор отчетов предлагаетпростой доступ к OLAP-данным. Они имеют простой в использовании графический интерфейси позволяют пользователям создавать отчеты перемещением объектов в отчет методом«drag and drop». Тогда как традиционный генератор отчетов предоставляетпользователю возможность быстро выпускать форматированные отчеты, генераторы отчетов,поддерживающие OLAP, формируют актуальные отчеты. Конечный продукт представляетсобой отчет, имеющий возможности углубления в данные до уровня подробностей, вращения(пивотинг) отчетов, поддержки иерархий и др… Add-Ins (дополнения) электронных таблиц.
Сегодня во многихнаправлениях бизнеса с помощью электронных таблиц производятся различные формы анализакорпоративных данных. В каком-то смысле это идеальное средство создания отчетови просмотра данных. Аналитик может создавать макросы, работающие с данными в выбранномнаправлении, а шаблон может быть спроектирован таким образом, что, когда происходитввод данных, формулы рассчитывают правильные величины, исключая необходимость неоднократноговвода простых расчетов.
Тем не менее,все это дает в результате «плоский» отчет, что означает, что как толькоон создан, трудно рассматривать его в различных аспектах. Например, диаграмма отображаетинформацию за некоторый временной период, — скажем, за месяц. И если некто желаетувидеть показатели за день (в противоположность данным за месяц), необходимо будетсоздать абсолютно новую диаграмму. Предстоит определить новые наборы данных, добавитьв диаграмму новые метки и внести множество других простых, но трудоемких изменений.Кроме того, существует ряд областей, в которых могут быть допущены ошибки, что вцелом уменьшает надежность. Когда к таблице добавляется OLAP, появляется возможностьсоздавать единственную диаграмму, а затем подвергать ее различным манипуляциям сцелью предоставления пользователю необходимой информации, не обременяя себя созданиемвсех возможных представлений. Интернет в роли клиента. Новым членом семейства OLAP-клиентовявляется Интернет. Существует масса преимуществ в формировании OLAP-отчетов черезИнтернет. Наиболее существенным представляется отсутствие необходимости в специализированномпрограммном обеспечении для доступа к информации. Это экономит предприятию кучувремени и денег.
Каждый Интернет-продуктспецифичен. Некоторые упрощают создание Web-страниц, но имеют меньшую гибкость.Другие позволяют создавать представления данных, а затем сохранять их как статическиеHTML-файлы. Все это дает возможность просматривать данные через Интернет, но неболее того. Активно манипулировать данными с их помощью невозможно.
Существует и другойтип продуктов — интерактивный и динамический, превращающий такие продукты в полнофункциональныеинструменты. Пользователи могут осуществлять углубление в данные, пивотинг, ограничениеизмерений, и др. Прежде, чем выбрать средство реализации Интернет, важно понять,какие функциональные возможности требуются от Web-решения, а затем определить, какойпродукт наилучшим образом воплотит эту функциональность[6].
Приложения. Приложения- это тип клиента, использующий базы данных OLAP. Они идентичны инструментам запросови генераторам отчетов, описанным выше, но, кроме того, они вносят в продукт болееширокие функциональные возможности. Приложение, как правило, обладает большей мощностью,чем инструмент запроса.
Разработка. Обычнопоставщики OLAP обеспечивают среду разработки для создания пользователями собственныхнастроенных приложений. Среда разработки в целом представляет собой графическийинтерфейс, поддерживающий объектно-ориентированную разработку приложений. К томуже, большинство поставщиков обеспечивают API, который может использоваться для интеграциибаз данных OLAP с другими приложениями.
2.2 OLAP — клиенты
OLAP-клиенты со встроеннойOLAP-машиной устанавливаются на ПК пользователей. Они не требуют сервера для вычислений,и им присуще нулевое администрирование. Такие клиенты позволяют пользователю настроитьсяна существующие у него базы данных; как правило, при этом создается словарь, скрывающийфизическую структуру данных за ее предметным описанием, понятным специалисту. Послеэтого OLAP-клиент выполняет произвольные запросы и результаты их отображает в OLAP-таблице.В этой таблице, в свою очередь, пользователь может манипулировать данными и получатьна экране или на бумаге сотни различных отчетов. OLAP-клиенты, предназначенные дляработы с РСУБД, позволяют анализировать уже имеющиеся в корпорации данные, напримерхранящиеся в БД OLTP[7]. Однако вторым их назначением может бытьбыстрое и дешевое создание хранилищ или витрин данных — в этом случае программистаморганизации нужно лишь создать совокупности таблиц типа «звезда» в реляционныхБД и процедуры загрузки данных. Наиболее трудоемкая часть работы — написание интерфейсовс многочисленными вариантами пользовательских запросов и отчетов — реализуется вOLAP-клиенте буквально за несколько часов. Конечному же пользователю для освоениятакой программы требуется порядка 30 минут. OLAP-клиенты поставляются самими разработчикамибаз данных, как многомерных, так и реляционных. Это SAS Corporate Reporter, являющийсяпочти эталонным по удобству и красоте продуктом, Oracle Discoverer, комплекс программMS Pivot Services и Pivot Table и др. Многие программы, предназначенные для работыс MS OLAP Services, поставляются в рамках кампании «OLAP в массы», которуюпроводит корпорация Microsoft. Как правило, они являются улучшенными вариантамиPivot Table и рассчитаны на использование в MS Office или Web-браузере. Это продуктыфирм Matryx, Knosys и т. д., благодаря простоте, дешевизне и эффективности приобретшиеогромную популярность на Западе.
3 Классификация продуктов OLAP
/>/>/>/>/>
3.1 Многомерный OLAP
В настоящее времяна рынке присутствует большое количество продуктов, которые в той или иной степениобеспечивают функциональность OLAP. Обеспечивая многомерное концептуальное представлениесо стороны пользовательского интерфейса к исходной базе данных, все продукты OLAPделятся на три класса по типу исходной БД.
1. Самые первые системыоперативной аналитической обработки (например, Essbase компании Arbor Software,Oracle Express Server компании Oracle) относились к классу MOLAP, то есть моглиработать только со своими собственными многомерными базами данных. Они основываютсяна патентованных технологиях для многомерных СУБД и являются наиболее дорогими.Эти системы обеспечивают полный цикл OLAP-обработки. Они либо включают в себя, помимосерверного компонента, собственный интегрированный клиентский интерфейс, либо используютдля связи с пользователем внешние программы работы с электронными таблицами. Дляобслуживания таких систем требуется специальный штат сотрудников, занимающихся установкой,сопровождением системы, формированием представлений данных для конечных пользователей.
2. Системы оперативнойаналитической обработки реляционных данных (ROLAP) позволяют представлять данные,хранимые в реляционной базе, в многомерной форме, обеспечивая преобразование информациив многомерную модель через промежуточный слой метаданных. К этому классу относятсяDSS Suite компании MicroStrategy, MetaCube компании Informix, DecisionSuite компанииInformation Advantage и другие. Программный комплекс ИнфоВизор, разработанный вРоссии, в Ивановском государственном энергетическом университете, также являетсясистемой этого класса. ROLAP-системы хорошо приспособлены для работы с крупнымихранилищами. Подобно системам MOLAP, они требуют значительных затрат на обслуживаниеспециалистами по информационным технологиям и предусматривают многопользовательскийрежим работы.
3. Наконец, гибридныесистемы (Hybrid OLAP, HOLAP) разработаны с целью совмещения достоинств и минимизациинедостатков, присущих предыдущим классам. К этому классу относится Media/MR компанииSpeedware. По утверждению разработчиков, он объединяет аналитическую гибкость искорость ответа MOLAP с постоянным доступом к реальным данным, свойственным ROLAP.
Помимо перечисленныхсредств существует еще один класс — инструменты генерации запросов и отчетов длянастольных ПК, дополненные функциями OLAP или интегрированные с внешними средствами,выполняющими такие функции. Эти хорошо развитые системы осуществляют выборку данныхиз исходных источников, преобразуют их и помещают в динамическую многомерную БД,функционирующую на клиентской станции конечного пользователя. Основными представителямиэтого класса являются BusinessObjects одноименной компании, BrioQuery компании BrioTechnology и PowerPlay компании Cognos. Обзор некоторых продуктов OLAP приведенв приложении.
В специализированныхСУБД, основанных на многомерном представлении данных, данные организованы не в формереляционных таблиц, а в виде упорядоченных многомерных массивов:
1) гиперкубов(все хранимые в БД ячейки должны иметь одинаковую мерность, то есть находиться вмаксимально полном базисе измерений) или
2) поликубов (каждаяпеременная хранится с собственным набором измерений, и все связанные с этим сложностиобработки перекладываются на внутренние механизмы системы).
Использованиемногомерных БД в системах оперативной аналитической обработки имеет следующие достоинства.
1. В случае использованиямногомерных СУБД поиск и выборка данных осуществляется значительно быстрее, чемпри многомерном концептуальном взгляде на реляционную базу данных, так как многомернаябаза данных денормализована, содержит заранее агрегированные показатели и обеспечиваетоптимизированный доступ к запрашиваемым ячейкам.
2. Многомерные СУБД легкосправляются с задачами включения в информационную модель разнообразных встроенныхфункций, тогда как объективно существующие ограничения языка SQL делают выполнениеэтих задач на основе реляционных СУБД достаточно сложным, а иногда и невозможным.
С другой стороны,имеются существенные ограничения.
1. Многомерные СУБД непозволяют работать с большими базами данных. К тому же за счет денормализации ипредварительно выполненной агрегации объем данных в многомерной базе, как правило,соответствует (по оценке Кодда) в 2.5-100 раз меньшему объему исходных детализированныхданных.
2. Многомерные СУБД посравнению с реляционными очень неэффективно используют внешнюю память. В подавляющембольшинстве случаев информационный гиперкуб является сильно разреженным, а посколькуданные хранятся в упорядоченном виде, неопределенные значения удаётся удалить толькоза счет выбора оптимального порядка сортировки, позволяющего организовать данныев максимально большие непрерывные группы. Но даже в этом случае проблема решаетсятолько частично. Кроме того, оптимальный с точки зрения хранения разреженных данныхпорядок сортировки скорее всего не будет совпадать с порядком, который чаще всегоиспользуется в запросах. Поэтому в реальных системах приходится искать компромиссмежду быстродействием и избыточностью дискового пространства, занятого базой данных.
Следовательно,использование многомерных СУБД оправдано только при следующих условиях.
1. Объем исходных данныхдля анализа не слишком велик (не более нескольких гигабайт), то есть уровень агрегацииданных достаточно высок.
2. Набор информационныхизмерений стабилен (поскольку любое изменение в их структуре почти всегда требуетполной перестройки гиперкуба).
3. Время ответа системына нерегламентированные запросы является наиболее критичным параметром.
4. Требуется широкоеиспользование сложных встроенных функций для выполнения кроссмерных вычислений надячейками гиперкуба, в том числе возможность написания пользовательских функций.
3.2Реляционный OLAP
Непосредственноеиспользование реляционных БД в системах оперативной аналитической обработки имеетследующие достоинства.
1. В большинстве случаевкорпоративные хранилища данных реализуются средствами реляционных СУБД, и инструментыROLAP позволяют производить анализ непосредственно над ними. При этом размер хранилищане является таким критичным параметром, как в случае MOLAP.
2. В случае переменнойразмерности задачи, когда изменения в структуру измерений приходится вносить достаточночасто, ROLAP системы с динамическим представлением размерности являются оптимальнымрешением, так как в них такие модификации не требуют физической реорганизации БД.
3. Реляционные СУБД обеспечиваютзначительно более высокий уровень защиты данных и хорошие возможности разграниченияправ доступа.
Главный недостатокROLAP по сравнению с многомерными СУБД — меньшая производительность. Для обеспеченияпроизводительности, сравнимой с MOLAP, реляционные системы требуют тщательной проработкисхемы базы данных и настройки индексов, то есть больших усилий со стороны администраторовБД. Только при использовании звездообразных схем производительность хорошо настроенныхреляционных систем может быть приближена к производительности систем на основе многомерныхбаз данных[8].
Описанию схемызвезды (star schema) и рекомендациям по ее применению полностью посвящены работы.Ее идея заключается в том, что имеются таблицы для каждого измерения, а все фактыпомещаются в одну таблицу, индексируемую множественным ключом, составленным из ключейотдельных измерений (Приложение А). Каждый луч схемы звезды задает, в терминологииКодда, направление консолидации данных по соответствующему измерению.
В сложных задачахс многоуровневыми измерениями имеет смысл обратиться к расширениям схемы звезды- схеме созвездия (fact constellation schema) и схеме снежинки (snowflake schema).В этих случаях отдельные таблицы фактов создаются для возможных сочетаний уровнейобобщения различных измерений (Приложение Б). Это позволяет добиться лучшей производительности,но часто приводит к избыточности данных и к значительным усложнениям в структуребазы данных, в которой оказывается огромное количество таблиц фактов.
Увеличение числатаблиц фактов в базе данных может проистекать не только из множественности уровнейразличных измерений, но и из того обстоятельства, что в общем случае факты имеютразные множества измерений. При абстрагировании от отдельных измерений пользовательдолжен получать проекцию максимально полного гиперкуба, причем далеко не всегдазначения показателей в ней должны являться результатом элементарного суммирования.Таким образом, при большом числе независимых измерений необходимо поддерживать множествотаблиц фактов, соответствующих каждому возможному сочетанию выбранных в запросеизмерений, что также приводит к неэкономному использованию внешней памяти, увеличениювремени загрузки данных в БД схемы звезды из внешних источников и сложностям администрирования.
Частично решаютэту проблему расширения языка SQL (операторы GROUP BY CUBE”, «GROUP BYROLLUP» и «GROUP BY GROUPING SETS»); кроме того, предлагается механизмпоиска компромисса между избыточностью и быстродействием, рекомендуя создавать таблицыфактов не для всех возможных сочетаний измерений, а только для тех, значения ячееккоторых не могут быть получены с помощью последующей агрегации более полных таблицфактов (Приложение В).
В любом случае,если многомерная модель реализуется в виде реляционной базы данных, следует создаватьдлинные и «узкие» таблицы фактов и сравнительно небольшие и «широкие»таблицы измерений. Таблицы фактов содержат численные значения ячеек гиперкуба, аостальные таблицы определяют содержащий их многомерный базис измерений. Часть информацииможно получать с помощью динамической агрегации данных, распределенных по незвездообразнымнормализованным структурам, хотя при этом следует помнить, что включающие агрегациюзапросы при высоконормализованной структуре БД могут выполняться довольно медленно.
Ориентация напредставление многомерной информации с помощью звездообразных реляционных моделейпозволяет избавиться от проблемы оптимизации хранения разреженных матриц, остростоящей перед многомерными СУБД (где проблема разреженности решается специальнымвыбором схемы). Хотя для хранения каждой ячейки используется целая запись, котораяпомимо самих значений включает вторичные ключи — ссылки на таблицы измерений, несуществующиезначения просто не включаются в таблицу фактов.
Заключение
/>/>/>/>/>Успешная компаниясегодня должна принимать множество различных решений. И чем более обоснованные решениябудут приняты, тем большего успеха и прибыли достигнет предприятие. Для многих лиц,играющих ключевую роль в принятии решений, способность быстрее и эффективнее конкурентаанализировать бизнес-процессы означает принятие более правильных решений, достижениебольшей прибыльности и большего успеха. Оптимизация реляционной базы данных предоставилакомпаниям возможность продуктивно собирать данные о транзакциях, поставляя информациилицам, принимающим решения.
Рассмотрев вопросы работыи применения технологии OLAP передкомпаниями возникают вопросы, ответы на которые позволят выбрать продукт наилучшимобразом отвечающий потребностям пользователя.
Это следующие вопросы:
Откуда поступают данные? –Данные, подлежащие анализу, могут находиться в различных местах. Возможно, что базаданных OLAP будет получать их из корпоративного Хранилища данных или из OLTP-системы.Если OLAP-продукт уже имеет возможность получить доступ к какому-то источнику данных,процессы категоризации и очистки данных сокращаются.
Какие манипуляции пользовательпроизводит над данными? —
Как только пользователь получил доступ к базе данных и начал выполнять анализ, важно,чтобы он был в состоянии оперировать данными соответствующим образом. В зависимостиот потребностей пользователя, может оказаться, что необходим мощный генератор отчетовили возможность создавать и размещать динамические web-страницы. Вместе с тем, можетбыть пользователю предпочтительнее иметь в своем распоряжении средство простогои быстрого создания собственных приложений.
Каков общий объем данных?- Это наиболее важный фактор при определении базы данных OLAP. Реляционные OLAP-продуктыспособны оперировать большими объемами данных лучше, чем многомерные. Если объемданных не требует использования реляционной базы, многомерный продукт может использоватьсяс не меньшим успехом.
Кем является пользователь?- При определении клиента OLAP-системы важен уровень квалификации пользователя.Некоторым пользователям удобнее интегрировать OLAP с таблицей, тогда как другиепредпочтут специализированное приложение. В зависимости от квалификации пользователярешается и вопрос о проведении обучения. Крупная компания может пожелать оплатитьтренинги для пользователей, компания меньшего размера может отказаться от них. Клиентдолжен быть таким, чтобы пользователи чувствовали себя уверенно и могли эффективноего использовать.
Сегодня большинство мировыхкомпаний перешли к использованию OLAP как базовой технологии для предоставленияинформации лицам, принимающим решениям. Поэтому принципиальный вопрос, которым необходимозадаться, не состоит в том, следует ли продолжать применять электронные таблицыв качестве основной платформы для подготовки отчетности, бюджетирования и прогнозирования.Компании должны спросить себя, готовы ли они терять конкурентные преимущества, используянеточную, неактуальную и неполную информацию, прежде чем они созреют и рассмотрятальтернативные технологии.
Так же, в заключение следуетотметить, что аналитические возможности технологий OLAP повышают пользу данных,хранящихся в корпоративном хранилище информации, позволяя компании более эффективновзаимодействовать со своими клиентами.
Глоссарий
№
п/п Понятие Определение 1
BI-инструменты
Инструменты и технологии, используемые для доступа к информации. Включают OLAP-технологии, data mining и сложный анализ; средства конечного пользователя и инструменты построения нерегламентированных запросов, инструментальные панели для мониторинга хозяйственной деятельности и генераторы корпоративной отчетности. 2
On-line Analitic Processing, OLAP (Оперативная аналитическая обработка)
Технология аналитической обработки информации в режиме реального времени, включающая составление и динамическую публикацию отчетов и документов. 3
Slice and Dice (Продольные и поперечные срезы, дословно — «нарезка на ломтики и кубики»)
Термин, использующийся для описания функции сложного анализа данных, обеспечиваемой средствами OLAP. Выборка данных из многомерного куба с заданными значениями и заданным взаимным расположением измерений. 4
Вращение (пивотинг) данных (Data Pivot)
Процесс вращения таблицы с данными, т. е. преобразования столбцов в строки и наоборот. 5
Вычисленный элемент (Calculated member)
Элемент измерения, чья величина определяется величинами других элементов (например, математическими или логическими приложениями). Вычисленный элемент может представлять собой часть OLAP сервера или быть описан пользователем в течение интерактивной сессии. Вычисленный элемент — это любой элемент, который не вводится, а вычисляется. 6
Глобальные бизнес-модели (Global Business Models)
Тип Хранилища данных, обеспечивающий доступ к информации, которая распределена по различным системам предприятия и находится под контролем различных подразделений или отделов с разными базами данных и моделями данных. Такой тип Хранилища данных труден для построения из-за необходимости объединения усилий пользователей различных подразделений для разработки общей модели данных для Хранилища. 7
Добыча данных (Data Mining)
Технические приемы, использующие программные инструменты, предназначенные для такого пользователя, который, как правило, не может заранее сказать, что конкретно он ищет, а может указать лишь определенные образцы и направления поиска. 8
Клиент/Сервер (Client/Server)
Технологический подход, заключающийся в разделении процесса на отдельные функции. Сервер выполняет несколько функций — управление коммуникациями, обеспечение обслуживания базы данных и др. Клиент выполняет индивидуальные пользовательские функции — обеспечение соответствующих интерфейсов, выполнение межэкранной навигации, предоставление функций помощи (help) и др. 9
Многомернаябазаданных, СУMБД(Multi-dimensional Database, MDBS and MDBMS)
Мощная база данных, позволяющая пользователям анализировать большие объемы данных. База данных со специальной организацией хранения — кубами, обеспечивающая высокую скорость работы с данными, хранящимися как совокупность фактов, измерений и заранее вычисленных агрегатов. 10
Углубление в данные (Drill Down)
Метод изучения детальных данных, используемый при анализе суммарного уровня данных. Уровни «углубления» зависят от степени детализации данных в [ранилище. 11
Центральное Хранилище (Central Warehouse)
1. База данных, содержащая данные, собираемые из операционных систем организации. Имеет структуру, удобную для анализа данных. Предназначена для поддержки принятия решений и создания единого информационного пространства корпорации.
2. Способ автоматизации, охватывающий все информационные системы, управляемые из одного места.
/>/>/>/>/>Список использованных источников
1 Голицина О.Л., Максимов Н.В.,Попов И.И. Базы данных: Учебное пособие. – М.: ФОРУМ: ИНФРА-М, 2003. – 352 с.
2 Дейт К. Введение в системы базданных. – М.: Hаука, 2005 г. – 246 с.
3 Елманова Н.В., Федоров А.А.Введение в OLAP-технологии Microsoft. – М.: Диалог-МИФИ, 2004. – 312 с.
4 Карпова Т.С. Базы данных:модели, разработка, реализация. – СПб.: Питер, 2006. – 304 с.
5 Коровкин С. Д., Левенец И. А.,Ратманова И. Д., Старых В. А., Щавелёв Л. В. Решение проблемы комплексногооперативного анализа информации хранилищ данных // СУБД. — 2005. — № 5-6. — 47-51 с.
6 Кречетов Н., Иванов П. Продуктыдля интеллектуального анализа данных ComputerWeek-Москва. — 2003. — № 14-15. — 32-39 с.
7 Пржиялковский В. В. Сложныйанализ данных большого объема: новые перспективы компьютеризации // СУБД. — 2006. — № 4. — 71-83 с.
8 Сахаров А. А. Концепцияпостроения и реализации информационных систем, ориентированных на анализ данных// СУБД. — 2004. — № 4. — 55-70 с.
9 Ульман Дж. Основы систем базданных. – М.: Финансы и статистика, 2003. – 312 c.
10 Хаббард Дж. Автоматизированноепроектирование баз данных. – М.: Мир, 2007. – 294 с.